[patch] fix un-escaped bash variable in post_install_network_config
by Justin Sherrill
Hi,
in a recent patch i submitted, i did not escape the $ in the bash
variable $IFNAME. Below is a patch to do that.
-Justin
--- a/snippets/post_install_network_config
+++ b/snippets/post_install_network_config
@@ -107,7 +107,7 @@ fi
IFNAME=\$(ifconfig -a | grep -i '$mac' | cut -d ' ' -f 1)
## Rename this interface in modprobe.conf
## FIXME: if both interfaces startwith eth this is wrong
-if [ -f "/etc/modprobe.conf" ] && [ $IFNAME ]; then
+if [ -f "/etc/modprobe.conf" ] && [ \$IFNAME ]; then
grep \$IFNAME /etc/modprobe.conf | sed "s/\$IFNAME/$iname/" >>
/etc/modprobe.conf.cobbler
grep -v \$IFNAME /etc/modprobe.conf >> /etc/modprobe.conf.new
rm -f /etc/modprobe.conf
--
Justin Sherrill, RHCA 1801 Varsity Drive.
Software Engineer Raleigh, NC 27603
Red Hat, Inc.
15 years, 1 month
Solution for JSON+unicode on python 2.3 (such as EL4)
by Michael DeHaan
This is in reference to the problem Tom Brown reported that on older
platforms we're still having unicode problems -- though we already had
them addressed for EL 5 and Fedora.
http://git.fedorahosted.org/git/cobbler?p=cobbler;a=commitdiff;h=f8be7272...
This will be included in 1.6.5. The general plan is to release 1.6.5
approximately one week from now, giving us some time to pick up other
fixes if required.
So far this patch is of interest to you if you are running the cobbler
server on EL 4, and otherwise is not important.
The basics are that this version will convert json files back down to
PyYAML and use PyYAML on python versions 2.3 and before, and will use
json (which is ~300x faster) on python
2.4 and above.
Extra testing is much appreciated.
For performance reasons, yes, this does mean that it is much preferred
that you run Cobbler on at least EL 5. We'll continue to support
Cobbler on EL 4, though it will just not be
as efficient if you have a very large number of system records in it
(i.e 500-1000+). If you are running those configs, definitely look
into upgrading.
This is on the master branch now, and I'm in the process of applying it
to devel.
--Michael
15 years, 1 month
[PATCH 2/2] Cleanup waitlist initialization and also upload bootloader configuration files (grub.conf, yaboot.conf, zipl.conf and elilo.conf)
by James Laska
---
aux/anamon | 28 ++++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/aux/anamon b/aux/anamon
index 481b2ee..affe96f 100644
--- a/aux/anamon
+++ b/aux/anamon
@@ -170,17 +170,28 @@ def anamon_loop():
scrlog = WatchedFile("/tmp/ks-script.log", "ks-script.log")
dump = WatchedFile("/tmp/anacdump.txt", "anacdump.txt")
mod = WatchedFile("/tmp/modprobe.conf", "modprobe.conf")
- ilog = WatchedFile("/mnt/sysimage/root/install.log", "install.log")
- ilog2 = WatchedFile("/mnt/sysimage/tmp/install.log", "tmp+install.log")
- ulog = WatchedFile("/mnt/sysimage/root/upgrade.log", "upgrade.log")
- ulog2 = WatchedFile("/mnt/sysimage/tmp/upgrade.log", "tmp+upgrade.log")
+
+ # Setup '/mnt/sysimage' watcher
sysimage = MountWatcher("/mnt/sysimage")
+ # Monitor for {install,upgrade}.log changes
+ package_logs = list()
+ package_logs.append(WatchedFile("/mnt/sysimage/root/install.log", "install.log"))
+ package_logs.append(WatchedFile("/mnt/sysimage/tmp/install.log", "tmp+install.log"))
+ package_logs.append(WatchedFile("/mnt/sysimage/root/upgrade.log", "upgrade.log"))
+ package_logs.append(WatchedFile("/mnt/sysimage/tmp/upgrade.log", "tmp+upgrade.log"))
+
+ # Monitor for bootloader configuration changes
+ bootloader_cfgs = list()
+ bootloader_cfgs.append(WatchedFile("/mnt/sysimage/boot/grub/grub.conf", "grub.conf"))
+ bootloader_cfgs.append(WatchedFile("/mnt/sysimage/boot/etc/yaboot.conf", "yaboot.conf"))
+ bootloader_cfgs.append(WatchedFile("/mnt/sysimage/boot/efi/efi/redhat/elilo.conf", "elilo.conf"))
+ bootloader_cfgs.append(WatchedFile("/mnt/sysimage/etc/zipl.conf", "zipl.conf"))
+
# Were we asked to watch specific files?
+ watchlist = list()
+ waitlist = list()
if watchfiles:
- watchlist = []
- waitlist = []
-
# Create WatchedFile objects for each requested file
for watchfile in watchfiles:
if os.path.exists(watchfile):
@@ -191,7 +202,8 @@ def anamon_loop():
# Use the default watchlist and waitlist
else:
watchlist = [alog, slog, dump, scrlog, mod, llog, kcfg, storage_log, prgm_log, vnc_log]
- waitlist = [ilog, ilog2, ulog, ulog2]
+ waitlist.extend(package_logs)
+ waitlist.extend(bootloader_cfgs)
# Monitor loop
while 1:
--
1.6.2.2
15 years, 1 month
Restructuring fields and internals / CLI and Django update
by Michael DeHaan
It's been a good week as I've managed to gut TONS of code all over
cobbler in the last several days, making it infinitely easier to add new
fields. We're not there yet, but it's getting
quite close, and this is the only thing I'm working on in Cobbler until
it's done.
50 files changed, 2955 insertions(+), 5603 deletions(-)
I have the "FIELDS" behavior pretty well as I would like in item_*.py
right now. There are a few hints the webapp needs missing that I need
to add next week.
The new fields structures didn't conform to /generic_edit/list/etc/ so
forth in the Wiki, so I'll probably be having to overhaul that a small bit.
I admit I completely do not understand the "do_multi" code and so forth
in the web app -- it's missing comments and risks being a casuality if I
can't figure it out.
AFAIK, this handles some of the batch options but is not generalized as
there aren't templates for that sort of thing.
I also have to go back through the code and re-add the "is valid"
checker code, that looks for inconsistencies between multiple fields on
the same object, right now that
was a bit of a casuality of the field cleanup.
I also suspect I might have broke minor options to the CLI like "delete
interface", "clobber", and "in place" ... delete-interface being rather
important, the others, if lost
in the architecture shuffle, not so important.
I think as we go on further, cobbler will have a much better web app,
and we'll need obscure CLI options (for things like editing a small part
of a hash) a bit less.
Anyway, the web UI is /rather/ torn up at the moment, though I noted
that if the actual web app doesn't point to the generic listing
templates, no one is going to test
them, so it was better to force them to point to the templates, and fix
what was there, rather than still point to any of the old pages.
This should ensure we are using all of the newness, and none of the oldness.
Perhaps after all of these gets done, snippets and ksfiles can be
similarly edited behind the scenes so they work as collections, even if
they do not actually
have CLI functions for manipulating them and really aren't collections.
(after all, settings is kind of a pseudo-collection). In which case,
snippet editing
and kickstart file editing could also be handled by the common templates.
From Peter's original work, several fields are going away -- we won't
have width and height info. I imagine each field will have a CSS class
field to assign
to it (optional) and that is about it. Keeps things simple. I also
need to go back through the fields and add two things -- the name of the
HTML element
to use for it, and for radio buttons, a list of valid choices. We may
also add back in the concept of a field grouping, when done, which would
affect both CLI
sorting and color coding of like fields in the WUI, for instance,
keeping power options color coded differently than virt options.
Anyway, stay tuned... I suspect by the end of next week it should be
mostly reassembled and back together in a rather nice state.
For those with outstanding patches, you are not forgotten -- I'll look
at these once all of this gets applied. This will take precedence
since until it's done, nothing really works
and there is no base to test patches against :)
--Michael
15 years, 1 month
Expansion on conserver integration ideas (for later)
by Michael DeHaan
Bill Peck and I did a good bit of talking yesterday in Westford, and we
have more expanded ideas for conserver integration in Cobbler.
Given, I've said the next release is plenty busy, so I'm not sure when
this would hit -- but it's a new feature as opposed to messing with an
existing one so it may not be too disruptive. TBD.
Anyway, the plan is to not only keep track of which console label you
have in cobbler but also generate the connserver configuration from a
template.
We'll add new fields to keep track of:
the console management address
the console type
etc
And each "sync" will generate a new connserver config (if installed) and
HUP conserver.
Since cobbler also has power management integration, if configured, the
cobbler conserver config can reference "cobbler power" commands,
allowing for power control via "console" without having to be logged
into the cobbler box via escape sequences.
Anyway, discussion/ideas welcome. We can probably elaborate more if
needed and maybe this will spark some ideas. I thought Bill's idea
about being able to map conserver back to cobbler power commands was a
need idea, and this would allow for some rather automagical synergy (TM)
between power and consoles and cobbler.
Also from koan (not cobbler) we'll be able to say:
koan --console --system=foo
to ask cobbler what the conserver label is and launch console. This
way you don't have to remember what the actual parameters to connect to
console are, if they are for some reason different from the FQDN (though
ordinarily they wouldn't be, this is just sugar at this point).
--Michael
15 years, 1 month
Re: Fire in the hole...
by Jasper Capel
> Sorting?
>
> Do you mean like namespacing them based on OS? (I wouldn't call that
> sorting, but I remember that discussion).
>
> The latter is problematic, and I can explain if needed.
>
I was thinking of separating snippets by breed they're meant for,
so /var/lib/cobbler/snippets is the base directory.
the current pre_install_network_config could then become
redhat/pre/network_config
for example
And Debian or any other distro could have it's own snippets that could
live under their respective breeds.
But yes, this is problematic because moving snippets around breaks
people. It's just my opinion that sooner or later we'll need more
structure in that directory. If we're going to ship a cobbler version
that takes a little effort to upgrade to anyway, then it would be a good
moment to introduce such a change as well.
-Jasper
15 years, 1 month
Re: Fire in the hole...
by Michael DeHaan
Michael DeHaan wrote:
> Do not expect the devel branch to work at this time.
>
> We're in the process of doing some /extremely/ cool things, for
> instance, I deleted some 2000 lines of code yesterday and the program
> still did what it originally did. Today I hope to delete close to
> the same amount.
>
> However it's going to take a little while to get things going again.
>
> The end result is it's going to be a TON easier to add new fields, and
> Cobbler is going to be a lot leaner of a program.
>
> The Python API itself (not api.py, but below) may experience slight
> changes, though we will ensure the XMLRPC API remains compatible.
>
> This does, effectively, make 1.8 very "2.0-ey" in spirit. We might
> in fact call this 2.0.
>
> --Michael
>
sorry, this ALSO should have gone to the devel list. I'll get this
right one of these days.
Anyway, it's worth mentioning ... if you haven't upgraded to 1.6, please
do so before 1.8 comes out.
--Michael
15 years, 1 month
[PATCH] Added ability to list errors generated by cheetah during templating
by James Cammarata
This is a little messy, but it's kind of unavoidable with the way
validateks was working before (calling an outside application to do the
validation).
I also noticed a way to considerably speed up validation time, which is to
cache the kickstart paths in an array and to check that before doing too
much work. After all, why validate the same kickstart file over and over
again?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
15 years, 1 month
Re: get-fields cleanup
by Michael DeHaan
Michael DeHaan wrote:
> I'm currently fixing up the get fields infrastructure, to simply things
> and keep from having hundreds of lines of sprawl in each file if i
> can. This was honestly stuff I wanted to look at for 2.0, but I think
> we need to contain the complexity before it gets to be too much.
>
> I'll also try to get these features working for images and repos, and
> also the CLI.
>
> I will probably be removing the concept of "order" among other things.
>
> Anyway, it is probably not a good time to be working on the above, for
> fear merging will become "interesting".
>
> Fair warning.
>
> --Michael
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
This was meant for -devel too.
Everybody likes extra email though, so it's all good :)
15 years, 1 month
