Re: Man page missing in latest Cobbler release (2.0.4-1.el5)
by Ian Ward Comfort
On 14 May 2010, at 2:35 AM, Roberto wrote:
> I'm using cobbler 2.0.4 and when I try to read the man page this is
> the result:
>
> gunzip: /usr/share/man/man1/cobbler.1.gz: unexpected end of file
> fgets: No such file or directory
> Error reading man page /usr/share/man/man1/cobbler.1.gz
> No manual entry for cobbler
On 20 May 2010, at 3:25 AM, Paul Maunders wrote:
> We are using the latest version of cobbler from the EPEL testing
> repository, and it seems the man page for Cobbler is missing from
> this version.
Yes, this is a problem with cobbler-2.0.4-1 in EPEL testing. Ccing -
devel for bugfix discussion.
This problem almost certainly due to commit f0b6e96 (Build the man
pages from the spec files, 2010-02-16). Probably the problem is that
the specfile's pod2man invocation fails (because docs/*.pod are not
present?) but rpmbuild doesn't notice because it collects the exit
status of gzip, which happily compresses nothing while truncating docs/
*.1.gz.
My guess is that this commit should just be reverted, because it seems
the "make rpms" target wants to generate the manpages, then have
"setup.py sdist" include them in the source distribution. But I'm
confused because there are so many (too many?) ways to build from
source -- "make rpms", "make sdist && rpmbuild -ta", "git archive &&
rpmbuild -ta", "setup.py sdist && rpmbuild -ta", ...
Cc also to Scott, the EPEL maintainer, who will know best.
--
Ian Ward Comfort <icomfort(a)stanford.edu>
Systems Team Lead, Academic Computing Services, Stanford University
13 years, 11 months
Smart tftp server...
by Douglas Kilpatrick
I've coded up a tftp server (using tornado's ioloop) that also talks
with cobbler. My hope is to use it to replace the system's tftp server,
to simplify sync operations and allow more flexibility in booting and
installing alternate operating systems.
Code is available at http://github.com/kilpatds/cobbler, changes are
limited to one file: scripts/tftpd.py
Right now, it just looks in template_files to see if it should perform
any templating, otherwise it loads files from /tftpboot (well, from the
"prefix" option, which defaults to /tftpboot). It expands templates via
templar, and uses XMLRPC to talk to cobbler.
If this is of interest, are there any suggestions about where to start
increasing integration? Long term, I'd like to have it handle
pxelinux.cfg stanzas, but I would also like to keep special-case
business logic outside the program.
Doug
--
Doug Kilpatrick
kilpatds(a)oppositelock.org
13 years, 11 months
prefered interface question...
by Douglas Kilpatrick
I'm writing a smart tftp server to do on-the-fly file templating and
substitutions.
(This is to make it easier to support multiple versions of FreeBSD,
which needs to boot by their pxeboot loader, which doesn't do
pxelinux-like tricks to get per-host files)
1. Should I use cobbler.api, or XMLRPC?
XMLRPC allows the tftp server to run on a different node than the
cobbler server, but adds authorization headaches. (bot-accounts, etc)
2. Using cobbler.api causes something that feels a lot like caching.
Client connects to my tftp server and the servers looks it up via
cobbler. I then use the web page to change something. Subsequent
lookups from the server result in the old information, but restarting
the server causes it to get new information
Is there a better solution that considering the cobbler-handle a per-
request resource?
3. I'm not quite sure I understand how Item.template_files is used. Is
this something I can use ("if the client asks for mfsroot.gz, give
then /var/www/cobbler/ks_mirror/$distro/boot/mfs-pxe.gz") or should I
add another similar attribute?
Doug
--
Doug Kilpatrick
kilpatds(a)oppositelock.org
13 years, 11 months
mod_wsgi breaks django web
by Vreman, Peter
The recent change in master to use mod_wsgi instead of mod_python breaks the django web interface that still requires mod_python. Especially the authentication requires some more changes than adding a .wsgi file. Can this be fixed by somebody with wsgi and django knowledge?
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
13 years, 11 months
moving kickstart_done and kickstart_start into snippets and out of kickgen.py
by Jonathan Sabo
List,
I wanted to be able to change the method used to signal cobbler
triggers and magic urls based on system breed in order to have them
work in VMware ESX. ESX's installer makes wget available during the
%pre section but then following install in the %post section only curl
is around. I moved kickstart_done and kickstart_start out of
kickgen.py and into snippets. This branch includes the two new
snippets to execute the kickstart_done and kickstart_start stuff and
I've updated the sample kickstarts and removed the two lines from
kickgen.py where it used to be executed from. Please check it out and
let me know if there are any concerns around going down this path for
the pre post trigger stuff.
http://github.com/jsabo/cobbler/tree/kickstart_done
Thanks,
Jonathan
13 years, 11 months
Unable to set "None" valued kernel param through XMLRPC
by Justin Sherrill
Hi,
So currently with satellite/spacewalk we use the XMLRPC interface to set
kernel params.
If you want to set something like foo=bar, it's as simple as passing
that key/value pair in a map as "foo":"bar". If you just want the
parameter "foo" though with no value, there is no way to do this. The
most sensible thing from a consumer of the XMLRPC interface is to pass
"foo":"" where the value is an empty string. Cobbler currently renders
this as:
foo=
Instead of just:
foo
I can easy change it to treat empty string the same as None when
rendering the kernel params, but I wanted to get feedback to see if it
would cause any issues. Is there any reason not to make this change?
Thanks!
-Justin Sherrill
--
Justin Sherrill, RHCA 1801 Varsity Drive.
Software Engineer Raleigh, NC 27603
Red Hat, Inc.
13 years, 11 months
[PROPOSAL] Using YUM/RPM repositories via 'mirrorlist'
by Niels Basjes
Hi,
If I look at the repo files created by cobbler I see the following effect.
Assume I initially add a repository as being hosted externally (not
mirrored locally). And after a while I choose to mirror the repository
locally because of ... lets say performance reasons or something like
that.
In the current situation this means that all clients need to be
updated because the configure URL have been distributed over all
nodes.
I think we could do better than that.
During installation the yum_repo_stanza will look like this:
repo --name=CentOS5-x86_64-EPEL
--baseurl=http://mirrors.kernel.org/fedora-epel/5/x86_64/
Which is fine because it is used only once (only at the time of installation)
The problem I have is that the config file generated for yum (i.e.
/etc/yum.repos.d/cobbler-config.repo ) has several blocks like this:
[CentOS5-x86_64-EPEL]
name=CentOS5-x86_64-EPEL
baseurl=http://mirrors.kernel.org/fedora-epel/5/x86_64/
enabled=1
priority=50
gpgcheck=0
Now if I choose to change the location of the actual repository then I
need some way of updating all clients.
( One possible way of doing this is by creating a daily cron script
that simply pulls the new version of the cobbler-config.repo .... YUCK
)
Now my proposal is a simpler and cleaner solution to this issue that
only takes a few minor changes in cobbler and simply starts using a
feature that is there for this purpose:
1) A new file is created for each repository that simply contains the
URL to the currently configured 'real' repository location:
I.e. a file like this
/var/www/cobbler/repo_mirror/CentOS5-x86_64-EPEL/mirror.list
which simply contains the URL of the configured mirror. In this example:
http://mirrors.kernel.org/fedora-epel/5/x86_64/
If we DO mirror this repository then this file will contain something like this:
http://192.168.1.1/cobbler/repo_mirror/CentOS5-x86_64-EPEL/
2) The cobbler-config.repo is now generated slightly different:
Instead of a baseurl we place a mirrorlist option in there with a
value that won't change.
[CentOS5-x86_64-EPEL]
name=CentOS5-x86_64-EPEL
mirrorlist=http://192.168.1.1/cobbler/repo_mirror/CentOS5-x86_64-EPEL/mirror.list
enabled=1
priority=50
gpgcheck=0
The overall effect is that there is no need to update the clients anymore.
What do you think of this proposal?
--
Met vriendelijke groeten,
Niels Basjes
13 years, 11 months
