[PATCH] Munge template_file dest only when writing files
by Ian Ward Comfort
In attempting an "auxiliary use" of template_files (as suggested in the wiki
under BuiltinConfigManagement) I discovered that non-absolute paths are not
served correctly -- the relative destination is rewritten to a path under
rendered/, and subsequently lost to the calling code in api.py. I'm using
1.6.6, but it looks like the problem persists in master, so attached is a
patch against that.
Feel free to ignore if ongoing refactoring will make this irrelevant; I
haven't been paying sufficient attention to recent development(s).
IWC.
---
cobbler/pxegen.py | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/cobbler/pxegen.py b/cobbler/pxegen.py
index dbc13a2..96e6b10 100644
--- a/cobbler/pxegen.py
+++ b/cobbler/pxegen.py
@@ -682,11 +682,10 @@ class PXEGen:
# configs into the rendered directory to ensure that a user
# granted cobbler privileges via sudo can't overwrite
# arbitrary system files (This also makes cleanup easier).
- if os.path.isabs(dest_dir):
- if write_file:
- raise CX(" warning: template destination (%s) is an absolute path, skipping." % dest_dir)
- continue
- else:
+ if write_file:
+ if os.path.isabs(dest_dir):
+ raise CX(" warning: template destination (%s) is an absolute path, skipping." % dest_dir)
+ continue
dest_dir = os.path.join(self.settings.webdir, "rendered", dest_dir)
dest = os.path.join(dest_dir, os.path.basename(dest))
if not os.path.exists(dest_dir):
--
1.5.5.6
14 years, 9 months
[PATCH] Small modification to keep_ssh_host_keys snippet
by Leonid Flaks
This patch provides the delete of the mount points in case when mount
was not successful (attempt to mount swap partition, for example)
Patch is made against master branch. It is pushed into my clone branch
already (http://github.com/lflaks/cobbler/tree/master)
In that branch there is also another snippet keep_cfengine_keys which is
almost identical except for different keys.
--
Leon
diff --git a/snippets/keep_ssh_host_keys b/snippets/keep_ssh_host_keys
index ce1d939..be1d2d4 100644
--- a/snippets/keep_ssh_host_keys
+++ b/snippets/keep_ssh_host_keys
@@ -25,8 +25,10 @@ function findkeys
tmpdir=$(mktemp -d $name.XXXXXX)
mkdir -p /tmp/$tmpdir
mount $disk /tmp/$tmpdir
- [ $? -eq 0 ] || continue # Skip to the next partition if the mount fails
-
+ if [ $? -ne 0 ]; then # Skip to the next partition if the mount fails
+ rm -rf /tmp/$tmpdir
+ continue
+ fi
# Copy current host keys out to be reused
if [ -d /tmp/$tmpdir$SEARCHDIR ]; then
cp -a /tmp/$tmpdir$SEARCHDIR/${PATTERN}* /tmp/$TEMPDIR
14 years, 9 months
development-branch (master) CLI a bit more usable now, various comments
by Michael DeHaan
I have the following working again, which should make it much easier for
people with an interest in developing cobbler for 2.0 to work on it once
more:
cobbler list
cobbler report
cobbler <objecttype> list
cobbler <objecttype> report
cobbler <objecttype> report [options]
cobbler <objecttype> find [options]
cobbler <object> add [options]
cobbler <object> edit [options]
cobbler <object> remove
cobbler import [options]
Also, remote exceptions are better logged now.
As mentioned previously, making remote exceptions look better to the
user is still TBD.
Still left to test/complete are the rest of the "actions", such as sync,
reposync, etc. These, however, are pretty simple :)
I'm pretty happy with the way things are turning out with cli.py
remaining pretty small thus far. (350 lines)
Previously we had:
[mdehaan@mdehaan obsolete]$ cat commands.py | wc -l
516
[mdehaan@mdehaan obsolete]$ cat cli_*.py | wc -l
1098
Now all of that will grow some as we add the other commands/options, but
it should, as a continuing theme, make things a lot nicer to work on.
You're welcome to play around with the command line and try to break it,
just note that there are lot of unfinished pieces yet which should be
very shortly
cleaned up.
I don't expect code changes to extend far outside cli.py and remote.py
in any sort of intrusive way, so don't feel like you need to hold back
on patches. Anything
added to utils should merge very cleanly.
Barring any other features we want to add, and holding off on network
objects, I think this means 2.0 is moving closer.
I still want to explore web app improvements as I think that is the main
"marketable" feature for this release, though increasing ease of
contributions is certaintly huge.
--Michael
14 years, 9 months
Learn to Hack on Cobbler Week Post Mortem
by Michael DeHaan
0 patches!
It was a nice attempt, but I still haven't got anything yet that was
started that week, that I know of.
If you were working on something, how about a status update?
If you're done with something and haven't posted it, post it up! :)
Works in progress, even if unfinished, can be finished by others...
waiting around for something to be perfect usually results in it not
being released.
--Michael
14 years, 9 months
Fire in the hole ... the command line on master is being disassembled
by Michael DeHaan
I've started working on remoting the CLI and it's in a very much 75%
disassembled state. Imagine your car engine disassembled and strewn
all over a workbench and you get the idea.
If you want to use cobbler from the master branch, use the web app, not
the CLI for now.
Help building the CLI back together is welcome, of course.
It will no longer be constructed by modules in modules/cli_*.py, but
just by simple code in cli.py.
It will use the FIELDS data structure to populate fields for objects,
but options for commands that are not object based (such as import) will
still be manually added.
Right now we have only a limited amount of things in, for testing purposes:
* import
* cobbler distro add
This means "list", "report", and all of that, etc, anything but what is
above, don't work.
We also have not finished the code that tails background operations, or
the code that will format XMLRPC remote exceptions into something that
looks nicer.
This is not a /hard/ thing to do per se, just rather intrusive, as
cobbler has a complicated system of objects and so forth.
Where possible I'm going to try to rework things to allow some new
XMLRPC APIs, so we can create objects with all parameters set in one
call, etc, where it makes sense. I probably won't port the webapp to
use these immediately (not much point except in introducing bugs) but it
should make the CLI cleaner.
For instance, instead of:
obj = new_item(...)
modify_item(obj, ...)
modify_item(obj, ...)
save_item(obj)
I want:
xapi_create_and_save(object_type, {attributes}, token)
xapi_copy_and_save(object_type, name, {attributes}, token)
xapi_rename_and_save(object_type, name, {attributes}, token)
# etc
This should also add some efficiency rather than transmitting a ton of
extra XMLRPC requests.
The prefix "xapi" is probably not the best, but I want some namespace to
indicate that these are the easiest "macro" functions to use when
working with things.
We are left with a lot of unfortunate legacy stuff here and there, which
had I not the burdens of an awesome userbase (this means you!) I would
love to take out back and shoot... the XMLRPC API being one area where
I'd love to remove old things, the data model being another (see threads
from a year ago), but nearly all the things we do (and weirdness we
keep) is based on that need for backwards compatibility. Thus the old
API methods need to remain around forever (yes, forever).
Also this can be read as "don't panic" :)
Note that while I am looking to maintain /most/ of the look and feel of
the old API, I can't guarantee or try to perserve bit-by-bit output.
If you are parsing the output of cobbler in anything (i.e. cobbler
report), I think I've warned before, but expect breakage in your
scripts. XMLRPC API compatibility is something we /will/ ensure, however.
--Michael
14 years, 9 months
Re: Buildiso and "cobbler check" can now be done via the webapp
by Simon Woolsgrove
>--- yacketrj(a)potsdam.edu wrote:
>From: "Ronald J Yacketta" <yacketrj(a)potsdam.edu>
>To: "cobbler development list" <cobbler-devel(a)lists.fedorahosted.org>
>Subject: Re: Buildiso and "cobbler check" can now be done via the webapp
>Date: 15 Jul 2009 16:37:20 -0400
>>Sent from my iPhone
>>On Jul 15, 2009, at 4:06 PM, "Michael DeHaan" <mdehaan(a)redhat.com>
>>wrote:
>
>> Should the generated file name be unique to prevent possible
>> overwriting? maybe a combination of distro and date / time stamp IE:
>> Fedora_11_071509_153830.iso
>>
>> If I am reading correctly; one builds a f11 iso then a f10 iso, the
>> f10
>> iso would overwrite the f11 one?
>>
>
> It only builds one kind of ISO -- an ISO that includes all of your
> profiles on it, for all distributions, that hits cobbler
> for the latest kickstart without you having to reburn the ISO.
>
>Ah! I see, makes sense now :)
>For some reason I was thinking single distro iso build
>-Ron
> Yes, it will overwrite the file -- though I thought this was much
> better than having to write code to remove old files and
> otherwise fill up that directory with timestamped ISOs.
>
> --Michael
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel
_______________________________________________
>cobbler-devel mailing list
>cobbler-devel(a)lists.fedorahosted.org
>https://fedorahosted.org/mailman/listinfo/cobbler-devel
This is a great feature for us as we currently have a lot of static IP setup.
I would like to see the filter page or maybe even a selection box on systems like power/netboot option and say include the associated profile too. The only reason for this is size the CD image can become ? A SA here generally creates a system in the WebUI and then has to access the CLI to create the iso for there system. Though guess happy to take a look, I download and take a look.
On the web/css side did you select a javascript framework/library to include ? I think tabs for systems page would help and probably a better menu on left, jQuery is pretty kool for this kind of stuff.
Cheers,
Simon
Cheers,
Simon
14 years, 9 months
Fix for the keep_ssh_host_keys snippet
by Brooke A. Storm
Hello all,
This is my first ever post here, so forgive me if I don't quite get how
to go about this. At my site, we found that the keep_ssh_host_key code
snippet in the stable branch was causing anaconda to fail to format
disks. The reason is that the current version in both release16 and
master will not clean up directories that are created if the mount
command fails in certain ways. I changed the check for successful mount
to be an if statement that will allow that cleanup. The patch file is
attached. I'm new to git as well, so I hope it is correctly formatted.
Brooke A. Storm
Research IT Group <ritgroup(a)albany.edu>
University at Albany, SUNY
P: 518-442-3368
E: bstorm(a)albany.edu <mailto:bstorm@albany.edu>
14 years, 9 months
Buildiso and "cobbler check" can now be done via the webapp
by Michael DeHaan
The ISO just runs "buildiso" with the default parameters. If someone
would like to make an intermediate page for it where we can enter more
parameters (and needs this) let me know, though I didn't find it to be
something we really needed immediately -- the goal of the web app being
to be simpler and easier to use. I thought about doing the thing that
allows you to choose which profiles to include, but if we did the same
for systems it would be very hard to do for very large cobbler install
bases in any sort of sane way. We might decide to allow people to
choose what profiles and not systems? I am not sure.
Anyway, when cobbler finishes the ISO you not only get the "task done"
event but also an event with the link to download it.
The ISO pops out at /var/www/cobbler/pub/generated.iso, so it can be
downloaded by remote computers.
Cobbler check data is now visible in the web app as well.
I also sorted the settings display at the same time, though settings
currently remain not user-editable (which was done originally to keep
someone from breaking
cobblerd in a way that could not be fixed via the web app).
As I've done this, it becomes clear the menus are a little crowded now,
so things like the event log, tasks, settings, etc can also be cleaned
up I imagine by just making icons (with tooltips, of course) instead of
text.
We could probably also do this for some of the actions, leaving room for
the "filter/pager" settings on the list page to show up when we need to.
I think this basically finishes the functional things I really wanted to
do for the backend functionality of the web app, so I would appreciate
review/comments. I think there is still room for lots of things in
terms of usability, such as expanding/collapsing sections of fields to
not overwhelm users -- I think that would be a good thing, especially on
the systems page. I think we could probably be even more clever and
just do tabs for each property "type" ... which could eliminate vertical
scrolling altogether and make us look a little less like a web page from
1998 :)
If anyone has good CSS/web-development skills and also wants to do
little stuff like help with icons, layout, fonts, whatever... I'm
generally open to all sorts of improvements and would appreciate the help.
(OT: I still have the idea that a link to see how the objects are
associated to one another (and be able to click on them to launch the
edit pages) would be /really/ cool, not entirely sure how best to do it,
but I want to do this very much -- plus I like graphics/visualization
stuff in general :) ... ).
--Michael
14 years, 9 months
Added comments about how to add new fields
by Michael DeHaan
It is done.
From a git master checkout, pull, and then read the top of
item_distro.py. Note how it references field_info.py as well, which
has less comments. The other item_*.py files reference item_distro.py
to avoid repeating themselves.
Eventually we might move some of this to the Wiki but I didn't want it
to grow out of date.
Rather, the Wiki will probably just get an article that says "hey, read
this code file or two", just like this email says.
Let me know if you have questions. Adding a new field now is really
/exceptionally/ easy with the new system.
--Michael
14 years, 9 months
War on FIXMEs
by Michael DeHaan
Here's a war everyone can get behind.
I suspect most FIXME comments in Cobbler are about things that don't
matter anymore.
Some of these things are reminders for future bits -- like 2.0 features,
that may not be implemented that we need to implement.
I'm going to be working on removing the ones that don't, and fixing the
things that need to be fixed if they do.
[mdehaan@localhost cobbler]$ grep "FIXME" *.py | wc -l
118
[mdehaan@localhost cobbler]$ pwd
/home/mdehaan/cg/cobbler/cobbler
[mdehaan@localhost cobbler]$ cd modules
[mdehaan@localhost modules]$ grep "FIXME" *.py | wc -l
23
If you'd like to help us clean up the shop, help is welcome, though I
suspect I'm the one who would know which ones are most ignorable.
Mostly it would be about removing comments so that once again we can
tell by grepping for FIXME whether the code is "done", and we can use
that for a criteria about whether 2.0 is close to done or not.
--Michael
14 years, 9 months