cobbler.spec issues (with solution?)
by Larry Matter
Hi Everyone,
I'm new to Cobbler (and git). I tried to "make rpms" and got similar
error messages to what I already see on the email archive
(https://fedorahosted.org/pipermail/cobbler-devel/2009-June/000706.html).
The changes below allowed the make to succeed, although I don't know if
they are correct.
If they are, then maybe this is a good way for me to learn to patch with
git? Feedback appreciated.
Thanks,
Larry Matter
diff --git a/cobbler.spec b/cobbler.spec
index e992d78..4951375 100644
--- a/cobbler.spec
+++ b/cobbler.spec
@@ -4,7 +4,6 @@
%global debug_package %{nil}
Summary: Boot server configurator
Name: cobbler
-License: GPLv2+
AutoReq: no
Version: 1.7.0
Release: 1%{?dist}
@@ -363,8 +362,7 @@ Web interface for Cobbler that allows visiting
http://server
%files -n cobbler-web
%defattr(-,apache,apache)
%dir /usr/share/cobbler/web
-/usr/share/cobbler/web/*.py
-%dir /usr/share/cobbler/web/sessions
+/usr/share/cobbler/web/*.py*
%dir /usr/share/cobbler/web/cobbler_web
/usr/share/cobbler/web/cobbler_web/*
#%dir /usr/share/cobbler/web/cobbler_web/templates
14 years, 11 months
[PATCH] Removed duplicate license line from spec file
by James Cammarata
Small fix, not sure how this got in there but it was causing rpmbuild
failures.
commit 4583e405c17d800f76b74628a11cd2fa9b4b64a4
Author: James Cammarata <jimi(a)sngx.net>
Date: Sat Jun 20 08:39:59 2009 -0500
Removed duplicate license line from spec file
Some other things I've noticed about the rpm since we went to an
arch-specific package. I needed a 32-bit version for a server at work, and
since my sandbox is x86_64, I tried to do a --rebuild --target=i386. This
failed, saying it couldn't find the manpage .gz in the build root. So I
tried adding it to the Makefile (--target in rpms), and got the same result
there.
So there seems to be some small issue when trying to build cross-platform
targets (at least from an x86_64 system).
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
14 years, 11 months
[PATCH] netboot enabled checkbox in generic_edit
by Vreman, Peter
The checkbox for netboot enabled (and maybe also other checkboxes) was not working. The checkbox was always unchecked at start and the save value was also always False.
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.
14 years, 11 months
[Patch] Static IP's in network_config snippet
by Simon Woolsgrove
This was spotted by one of our users, the network snippet does not render correctly with static IP's defined the ks renders as
$ cobbler system --name=fred getks | grep ^network
network --bootproto=dhcp --hostname=fred --device=eth1 --onboot=on
network --bootproto=dhcp --hostname=fred --device=eth0 --onboot=on
after patch
$ cobbler system --name=fred getks | grep ^network
network --bootproto=static --ip=x.x.x.x --netmask=255.255.255.0 --gateway=x.x.x.x --nameserver=x.x.x.x hostname=fred --device=eth1 --onboot=on
network --bootproto=static --ip=x.x.x.x --netmask=255.255.254.0 --gateway=x.x.x.x --nameserver=x.x.x.x --hostname=fred --device=eth0 --onboot=on
I think this should be a boolean, not a string check ?
--- a/snippets/network_config
+++ b/snippets/network_config
@@ -38,7 +38,7 @@
#set $i = $i + 1
#end if
#if $mac != "" or $ip != "" and $is_vlan == "false"
- #if $static == "True":
+ #if $static == True:
#if $ip != "":
#set $network_str = "--bootproto=static"
#set $network_str = $network_str + " --ip=" + $ip
Cheers,
Simon
14 years, 11 months
[Patch] fix broken RHEL 2.1 registration in redhat_register snippet
by Justin Sherrill
Due to weird way that RHEL 2.1 has an 'up2date' and 'rhn_register'
config file, we need to set the SSL CA Cert in both of those files.
Passing it in on the command line will only set it in 'up2date', thus
causing the registration to fail. Here's a patch to set it in both
before the registration.
-Justin
--- a/snippets/redhat_register
+++ b/snippets/redhat_register
@@ -2,8 +2,10 @@
#if $redhat_management_type != "off" and $redhat_management_key != ""
mkdir -p /usr/share/rhn/
#if $redhat_management_type == "site"
- #set $mycert = "/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT"
+ #set $mycert_file = "RHN-ORG-TRUSTED-SSL-CERT"
+ #set $mycert = "/usr/share/rhn/" + $mycert_file
wget http://$redhat_management_server/pub/RHN-ORG-TRUSTED-SSL-CERT -O
$mycert
+perl -npe 's/RHNS-CA-CERT/$mycert_file/g' -i /etc/sysconfig/rhn/*
#end if
#if $redhat_management_type == "hosted"
#set $mycert = "/usr/share/rhn/RHNS-CA-CERT"
--
Justin Sherrill, RHCA 1801 Varsity Drive.
Software Engineer Raleigh, NC 27603
Red Hat, Inc.
14 years, 11 months
Re: [Patch] Static IP's in network_config snippet
by Simon Woolsgrove
>>On 06/18/2009 05:48 PM, Simon Woolsgrove wrote:
>> This was spotted by one of our users, the network snippet does not
render correctly with static IP's defined the ks renders as
>>
>> $ cobbler system --name=fred getks | grep ^network
>> network --bootproto=dhcp --hostname=fred --device=eth1 --onboot=on
>> network --bootproto=dhcp --hostname=fred --device=eth0 --onboot=on
>>
>> after patch
>>
>> $ cobbler system --name=fred getks | grep ^network
>> network --bootproto=static --ip=x.x.x.x --netmask=255.255.255.0
--gateway=x.x.x.x --nameserver=x.x.x.x hostname=fred --device=eth1
--onboot=on
>> network --bootproto=static --ip=x.x.x.x --netmask=255.255.254.0
--gateway=x.x.x.x --nameserver=x.x.x.x --hostname=fred --device=eth0
--onboot=on
>>
>> I think this should be a boolean, not a string check ?
>>
>Correct, thanks!
>Or just
>"#if $static:"
>If you find any more errors in network_config, please share. It doesn't
>get used that much, because it only kicks in when no MAC addresses are
>supplied (and for netboot purposes, most users seem to do this anyway,
>and for virtuals a random mac-address is one click away), but I'd like
>it to work as well as pre_install_network_config does.
>Michael:
>I corrected this in my capel-release16 and capel-master branches.
>-Jasper
Thanks, Jasper
The only other thing to note when using static ip's is the
--onboot=<dev>. When we do not know the MAC were just guessing the
interface (we have a live cd that attempts to find the best interface).
Anaconda as I understand will configure the interface you supply e.g.
say via the boot line as it has to find the ks file via http so adding a
dev makes no sense? unless I guess you have configured more than one
interface. Thoughts ?
Cheers,
Simon
14 years, 11 months
Debian: let's finish this
by Michael DeHaan
Ok, the way I see it, we have the following opens for 2.0 Debian/Ubuntu
support to be basically complete
(A) Flexible patching configuration. Use
installer_templates/defaults and installer_templates/settings to ship a
configuration file that uses the right paths for the right place, making
paths more configurable where they are not.
(B) Package koan and make sure the cobbler packaging is updated to
match the changes we've made in 2.0 (build scripts for packaging only
are ok, we don't need to worry about distro inclusion just yet).
(C) Test koan on Debian. Make sure both --replace-self and --virt
options work for supported virt types. Make tweaks where required.
(D) Take the apt-mirror integration and ship preseeds that associate
repos with the profiles that use them, as we currently do today to
auto-associate yum repos and profiles, such that the repos are usable
during (1) installation, and (2) configured to be used after installation.
(E) Provide alternate versions of snippets in /var/lib/cobbler/snippets
or otherwise make them do "if" logic around the OS breed to DRT on the
right platforms.
(F) ... What else ...
(G) Test DHCP, DNS, power, and other optional features to identify any
distribution-specifics we need to clean up.
There has been good progress in this area, but we need to go ahead and
finish it up. Who wants to sign up for what?
14 years, 11 months
Re: Debian development branch
by James Cammarata
On Sat, 13 Jun 2009 15:29:20 +0200, Javier Palacios <javiplx(a)gmail.com>
wrote:
> On Fri, Jun 12, 2009 at 12:27 PM, James Turnbull<james(a)lovedthanlost.net>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> I note an exchange a while back (1 May) about FHS, directories,
>> configuration and Debian/Ubuntu package submission. It talked about a
>> debian devel branch. I couldn't find the branch on the main git repo.
>> Is someone maintaining it?
>
> As Michael said, there is no debian branch. My own github
> (git://github.com/javiplx/cobbler-devel.git) is only for debian stuff,
> and probably the one from Jasper Capel also
> (git://bender.newnewyork.nl/cobbler)
>
> It could be a good idea to unify in some sense all these repositories
> (or at least create a list), but if you have a github account and want
> to use the repo I did create I have no problem giving you whichever
> permissions are required.
Taking this over to the devel list.
I'm going to start working on combing yours and Jasper's git repos, and
commit these up to mine as a unified repo.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
14 years, 11 months
A minimal example of using the task engine via XMLRPC / API compat
by Michael DeHaan
This is just something that I've been using in testing that kicks off a
long running operation.
[mdehaan@localhost cobbler]$ cat /tmp/test.py
#!/usr/bin/python
import xmlrpclib
import time
s = xmlrpclib.Server("http://127.0.0.1/cobbler_api")
token = s.login("testing","testing")
task1 = s.background_sync(token)
task2 = s.background_reposync(["r1","r2"], 3, token)
# new function names are subject to change until released
print s.get_task_status(task1)
while True:
print s.get_task_status(task2)
time.sleep(1)
====
As you can see it remains pretty simple to use.
We will keep the non-background version of "sync" around for backwards
compatibility.
Certain operations like the things that return the equivalent results of
"cobbler profile report" will not need to be backgrounded.
As part of our general XMLRPC API convenant, we only add new options on
the end of functions, and we always give new options default values.
This way old apps should continue to be happy.
The Python API will become unsuggested, however, as now we know that
users of that API will be out of sync with cobblerd, henceforth, it's
not really a "public" API but can be used if you know what you are
doing. We will still fight to keep it compatible though.
Right now all public apps using Cobbler that I know of are using the
XMLRPC APIs.
--Michael
14 years, 11 months