[PATCH] path to cert in redhat_register snippet
by Mike McCune
---
snippets/redhat_register | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/snippets/redhat_register b/snippets/redhat_register
index 6a20448..5c64776 100644
--- a/snippets/redhat_register
+++ b/snippets/redhat_register
@@ -4,7 +4,7 @@
mkdir -p /usr/share/rhn/
#if $redhat_management_type == "site"
#set $mycert = "/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT"
-wget http://$redhat_management_server/pub/rhn/RHN-ORG-TRUSTED-SSL-CERT
-O $mycert
+wget http://$redhat_management_server/pub/RHN-ORG-TRUSTED-SSL-CERT -O
$mycert
#end if
#if $redhat_management_type == "hosted"
#set $mycert = "/usr/share/rhn/RHNS-CA-CERT"
--
1.5.6.5
15 years, 4 months
[KOAN 1.2.X PATCH] SELinux: set correct security context for lvm partitions
by Anton Arapov
Hello crew,
On SELinux enabled system:
# cobbler system add --name vguest --profile F-10-x86_64 \
--virt-type qemu \
--virt-bridge virbr0 \
--virt-path vg
# koan --server 'host' --virt --system vguest2
These will fail to run, because koan did not set the correct security context
for created lvm partition.
It must execute something like:
# chcon -t virt_image_t /dev/mapper/%lvm_partition%
Patch addressed to the ticket #321:
https://fedorahosted.org/cobbler/ticket/321
I've added also some concerns, about already implemented in cobbler
selinux check. So please, read the ticket and leave feedback. :)
Cheers!
==
diff -urpN koan-1.2.6.orig/koan/app.py koan-1.2.6/koan/app.py
--- koan-1.2.6.orig/koan/app.py 2008-12-10 09:04:12.082359000 +0100
+++ koan-1.2.6/koan/app.py 2008-12-10 09:18:59.765607726 +0100
@@ -1213,8 +1213,23 @@ class Koan:
if lv_create != 0:
raise InfoException, "LVM creation failed"
+ # partition location
+ partition_location = "/dev/mapper/%s-%s" % (location,name.replace('-','--'))
+
+ # check whether we have SELinux enabled system
+ args = "/usr/sbin/selinuxenabled"
+ selinuxenabled = sub_process.call(args)
+ if selinuxenabled == 0:
+ # permissive or enforcing or something else, and
+ # set appropriate security context for LVM partition
+ args = "/usr/bin/chcon -t virt_image_t %s" % partition_location
+ print "%s" % args
+ change_context = sub_process.call(args, shell=True)
+ if change_context != 0:
+ raise InfoException, "SELinux security context setting to LVM partition failed"
+
# return partition location
- return "/dev/mapper/%s-%s" % (location,name.replace('-','--'))
+ return partition_location
else:
raise InfoException, "volume group needs %s GB free space." % virt_size
15 years, 4 months
edit and copy does not do duplicate ip check
by Vreman, Peter
Is it by design that a system edit+copy does not do any duplicate ip checks? It will at least make editing the original and new copy afterwards report and error of a duplicate ip.
Also the error to the WebUI is not informative enough. You need to look in the log why the save failed.
Regards,
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.
15 years, 4 months
[BUG] cobbler acl issues w/ cobbler reposync
by Adam Rosenwald
With cobbler-1.3.4, I had added an acl group privilege:
* *cobbler aclsetup --addgroup=mygroup*
I executed the above command after ensuring the mounted ext3 filesystems
involved were sane
* *mount -o remount,acl,user_xattr /var*
Now when I execute *cobbler reposync --only=test-64*, I receive the
following output
### BEGIN OUTPUT ###
[me@host ~]$ rsync -rltDv --delete --delete-excluded
--exclude-from=/etc/cobbler/rsync.exclude /opt/repos/test/x86_64/
/var/www/cobbler/repo_mirror/test-64
building file list ... done
./
rsync: failed to set times on "/var/www/cobbler/repo_mirror/test-64/.":
Operation not permitted (1)
base/
rsync: failed to set times on
"/var/www/cobbler/repo_mirror/test-64/base": Operation not permitted (1)
repodata/
rsync: failed to set times on
"/var/www/cobbler/repo_mirror/test-64/repodata": Operation not permitted (1)
rsync: failed to set times on "/var/www/cobbler/repo_mirror/test-64/.":
Operation not permitted (1)
rsync: failed to set times on
"/var/www/cobbler/repo_mirror/test-64/base": Operation not permitted (1)
rsync: failed to set times on
"/var/www/cobbler/repo_mirror/test-64/repodata": Operation not permitted (1)
### END OUTPUT ###
/var/www/cobbler/repo_mirror/* has owner:group=apache:apache. I tried
changing the group recursively to 'mygroup' with write permission. No luck.
After scouring through numerous search results, I concluded that rsync
does not modify standard mtime stats using the normal system call; it
uses its own algorithm -- /*which ultimately requires changing
"ownership" of the repos*/.
This seems to defeat the purpose of using ACLs in conjunction w/ cobbler.
In order to write files without worrying about rsync time oddities, I
inserted *-O* *(--omit-dir-times)* into the "action_reposync.py" file:
* 'cmd = "rsync -rltDvO %s --delete --delete-excluded
--exclude-from=/etc/cobbler/rsync.exclude %s %s" % (spacer,
repo.mirror, dest_path)'
The question remains, however, whether the rsync time synchronizations
are needed. If so, this patch will not work, and there will have to be
some workaround - e.g. setuid bit?
---
I would *love* to hear that this is a non-issue and someone sees right
through this logic.
---
But... we're not done yet. There's another 'acl gotcha' in
action_reposync.pl: *chown -R root:apache*.
I don't see how this can be done without setuid/setguid root or some
additional acl magic.
### BEGIN OUTPUT ###
...
...
...
chmod: changing permissions of
`/var/www/cobbler/repo_mirror/test-64/base/test-1.1-1.x86_64.rpm':
Operation not permitted
chmod: changing permissions of
`/var/www/cobbler/repo_mirror/test-64/base/a-1-2.noarch.rpm': Operation
not permitted
...
...
...
### END OUTPUT ###
Any thoughts?
Thanks,
- A.
15 years, 4 months
Virtualbox & greetings
by Dale Reagan
Greetings Folks,
I've been lurking for a few days - I started out using Cobbler for bare
metal but wound up using Cobbler and VMs for a test-bed. During the
process I used some simple scripting to populate Cobbler structures from
Virtualbox structures (i.e. created Cobbler command lines from the
Virtuabox VM data.) Michael indicated that creating a new 'virtual type'
might be a less cumbersome solution - so here I am.
Anyone working with/on Virtualbox/Cobbler/Koan?
Python coding will be a new experience so feel free to direct me (off list)
to the code pieces that I should review.
All the best,
:)
Dale
= = = = = = = = = = = = = = = = = = = =
Dale E. Reagan | (912) 920-9299
Photographer / Consultant | Dale(a)DaleReagan.Com
http://www.dalereagan.com/
PO Box 15336, Savannah, Ga 31416 USA
15 years, 4 months
Re: LDAP Serializer Patch
by James Cape
That's fine to have a set of scripts to update cobbler from LDAP. Is there any resistance to maintaining a common-use version of those scripts in a contrib dir in cobbler?
--
James Cape
http://jcape.ignore-your.tv/
"If there’s one thing I know, it’s that managers have the least
information about every technical issue, and they are the last
people who should be deciding anything"
-- Joel Spolsky
----- "Michael DeHaan" <mdehaan(a)redhat.com> wrote:
> James M. Cape wrote:
> > Here is the most common use case for LDAP:
> >
> > I am a senior administrator of a mid-sized company. I want to use
> LDAP to store a variety of data about a host: the puppet classes it
> should use for configuration, DNS records related to the object, my
> own proprietary inventory control information, and notes about quirks
> on the box. So I create a custom LDAP structural object which contains
> the following records for a host:
> >
> > name
> > owner
> > jcapeInventoryTag
> > description
> >
> > and then use the auxiliary classes provided by PowerDNS, Puppet, and
> Cobbler to add additional information. Once you've created an object,
> you can't remove structural object classes without effectively
> recreating the object. Further, each object class will have it's own
> notion of MAY and MUST fields. My on proprietary jcapeSystem class
> will have a jcapeInventoryTag as a MUST, so I can't enter a new system
> without having an inventory tag. Further, I'm not going to want to
> have multiple records in multiple places describing a single "system",
> because I don't have to and that's dumb.
> >
> > So if cobbler wants to write to LDAP (which is likely a non-starter
> to begin with, because I'm not going to risk it barfing all over my
> directory that I'm using to handle DNS and configuration management),
> it will need to take into account all the object classes that I as the
> administrator want it to use---and all the required fields that those
> object classes want it to use as well. Which means defining LDAP
> templates for cobbler to use when creating a new record and all the
> assorted madness of that, which will likely conflict with the
> already-existing system I have for entering hosts (either via
> PhpLdapAdmin or some scripted RYO solution).
> >
> > So telling me that cobbler *has* to write to LDAP is great, except
> that it's a real nightmare to actually do that in a way that is
> acceptable to people who use LDAP (like me)---far worse of a nightmare
> than factoring the assumptions you're making about the writer from the
> reader.
> >
> >
>
> This seems like it might be easier to have a way to sync cobbler from
> LDAP, in that case, which I think a few folks have done.
>
> The serializers, especially in 1.4, need to save updated data -- in
> particular, the modification times of objects and their ID's are going
> to become increasingly important internally.
>
> Also if the storage format is read only there is no way to upgrade
> cobbler and have things work effectively, due to the way things like
> deserialize_raw work for XMLRPC and the Web app (which are also
> growing
> in importance -- even if you don't use the webapp, cobbler does use
> XMLRPC to generate kickstart files).
>
> I think populating and updating cobbler from LDAP may be a better way
> to
> go in this instance.
>
> --Michael
>
> > --
> > James Cape
> > http://jcape.ignore-your.tv/
> >
> > "If there’s one thing I know, it’s that managers have the least
> > information about every technical issue, and they are the last
> > people who should be deciding anything"
> > -- Joel Spolsky
> >
> > ----- "Michael DeHaan" <mdehaan(a)redhat.com> wrote:
> >
> >
> >> James M. Cape wrote:
> >>
> >>> I'm attaching a patch against cobbler git (stable) to support an
> >>>
> >> LDAP-backed serializer.
> >>
> >>> It's mode of operation is as follows:
> >>>
> >>> 1. Read-only from inside the cobbler TUI/WUI
> >>> - Users must handle adding the desired values to LDAP
> >>>
> >>>
> >> In all fairness, I can't see this as being something many people
> would
> >>
> >> use, when there is an extensive amount of validation and other
> logic
> >> in
> >> Cobbler that does not get executed if you do not use one of
> Cobbler's
> >>
> >> APIs to add that data. It would seem to cause lots of support
> problems
> >>
> >> with users entering invalid data. Also, adding data in such a
> manner
> >> would not execute any of the sync code for particular objects, nor
> >> triggers. The serializer would need to also /populate/ LDAP, IMO.
> If
> >> the
> >> logic to validate input is not part of Cobbler, it would have to be
> >> implemented in a higher level application, and at that point, it's
> >> going
> >> to be a lot of work for minimal gain.
> >>
> >> Ultimately I think it comes down to what sort of functionality that
> we
> >>
> >> are getting that we didn't have before, and what sort of
> applications
> >>
> >> need to be manipulating Cobbler that can't use it's XMLRPC API.
> >>
> >>
> >>
> >>> 2. Custom schema must be manually installed into LDAP server(s),
> >>>
> >> but you can customize the mappings between LDAP attributes and the
> >> cobbler object variables (e.g. rather than "name" = "cn", you can
> have
> >> "name" = "uid" or something).
> >>
> >>> There are some gotchas regarding the way inheritance/overlays work
> >>>
> >> with LDAP, though. In particular, it doesn't handle the the NULL =
> ""
> >> mapping that the YAML serializers do.
> >>
> >>>
> >>>
> >> Kind of. Empty string is just empty string. Rather it's more of a
> >> policy
> >> of not storing anything as Null, ever, for any reason. This is easy
> to
> >>
> >> think about if you think of Null/None as being a memory management
> >> concept. There's as a good reason for doing this too -- XMLRPC
> >> transmission of None is non-standard (though reasonably widely
> >> supported). To make things easier on XMLPRC consumers, we never
> >> store/transmit anything as None/Null.
> >>
> >>
> >>
> >>> It also doesn't completely handle the way "<<inherit>>" and
> default
> >>>
> >> values work in the YAML serializers yet, so cobbler sync doesn't
> >> really work. This is the showstopper, but I don't know what kind of
> >> policy to pursue here:
> >>
> >>> Do I emulate the behavior of the TUI/WUI inside the LDAP
> serializer,
> >>>
> >> or depend on the user to do so by setting "<<inherit>>" manually?
> >>
> >>>
> >>>
> >> The serializers are supposed to be pretty braindead ways to save a
> >> datastructure in a file format. In the webapp itself, the templates
> >> are
> >> there to ensure "<<inherit>>" is loaded as the default value for
> when
> >>
> >> it's appropriate.
> >>
> >> They will get marginally more complicated if we ever support SQL
> >> DB's.
> >>
> >> Ultimately I think implementing domain logic outside of Cobbler to
> >> simulate what Cobbler does is a bit of a design problem -- we have
> to
> >>
> >> ask what we want to achive with this in terms of interoperability
> that
> >>
> >> we could not do before.
> >>
> >> I think Cobbler /has/ to be able to manipulate the LDAP records for
> it
> >>
> >> to be a useful interface/tool in this context.
> >>
> >>> --
> >>> James Cape
> >>> http://jcape.ignore-your.tv/
> >>>
> >>> "If there’s one thing I know, it’s that managers have the least
> >>> information about every technical issue, and they are the last
> >>> people who should be deciding anything"
> >>> -- Joel Spolsky
> >>>
> >>>
> >>>
> >>
> ------------------------------------------------------------------------
> >>
> >>> _______________________________________________
> >>> cobbler mailing list
> >>> cobbler(a)lists.fedorahosted.org
> >>> https://fedorahosted.org/mailman/listinfo/cobbler
> >>>
> >> _______________________________________________
> >> cobbler mailing list
> >> cobbler(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/cobbler
> >>
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
15 years, 4 months
[PATCH] Ooops, don't forget to create the yaboot binary and config directories.
by James Laska
From: James Laska <jlaska(a)dell-t5400.test.redhat.com>
---
cobbler/action_sync.py | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py
index 68b5b45..40e5c44 100644
--- a/cobbler/action_sync.py
+++ b/cobbler/action_sync.py
@@ -136,6 +136,8 @@ class BootSync:
utils.rmtree_contents(path)
pxelinux_dir = os.path.join(self.bootloc, "pxelinux.cfg")
images_dir = os.path.join(self.bootloc, "images")
+ yaboot_bin_dir = os.path.join(self.bootloc, "ppc")
+ yaboot_cfg_dir = os.path.join(self.bootloc, "etc")
s390_dir = os.path.join(self.bootloc, "s390x")
rendered_dir = os.path.join(self.settings.webdir, "rendered")
if not os.path.exists(pxelinux_dir):
@@ -144,9 +146,15 @@ class BootSync:
utils.mkdir(images_dir)
if not os.path.exists(rendered_dir):
utils.mkdir(rendered_dir)
+ if not os.path.exists(yaboot_bin_dir):
+ utils.mkdir(yaboot_bin_dir)
+ if not os.path.exists(yaboot_cfg_dir):
+ utils.mkdir(yaboot_cfg_dir)
utils.rmtree_contents(os.path.join(self.bootloc, "pxelinux.cfg"))
utils.rmtree_contents(os.path.join(self.bootloc, "images"))
utils.rmtree_contents(os.path.join(self.bootloc, "s390x"))
+ utils.rmtree_contents(os.path.join(self.bootloc, "ppc"))
+ utils.rmtree_contents(os.path.join(self.bootloc, "etc"))
utils.rmtree_contents(rendered_dir)
--
1.6.0.4
15 years, 4 months
LDAP Serializer Patch
by James Cape
I'm attaching a patch against cobbler git (stable) to support an LDAP-backed serializer.
It's mode of operation is as follows:
1. Read-only from inside the cobbler TUI/WUI
- Users must handle adding the desired values to LDAP
2. Custom schema must be manually installed into LDAP server(s), but you can customize the mappings between LDAP attributes and the cobbler object variables (e.g. rather than "name" = "cn", you can have "name" = "uid" or something).
There are some gotchas regarding the way inheritance/overlays work with LDAP, though. In particular, it doesn't handle the the NULL = "" mapping that the YAML serializers do.
It also doesn't completely handle the way "<<inherit>>" and default values work in the YAML serializers yet, so cobbler sync doesn't really work. This is the showstopper, but I don't know what kind of policy to pursue here:
Do I emulate the behavior of the TUI/WUI inside the LDAP serializer, or depend on the user to do so by setting "<<inherit>>" manually?
--
James Cape
http://jcape.ignore-your.tv/
"If there’s one thing I know, it’s that managers have the least
information about every technical issue, and they are the last
people who should be deciding anything"
-- Joel Spolsky
15 years, 4 months
(devel) new easier registration for Red Hat Network, Satellite Server, and Spacewalk
by Michael DeHaan
Hi folks,
So it's /always/ been possible to use Cobbler in conjunction with RHN or
Satellite/Spacewalk, but you would always have to get the details right.
New in Cobbler 1.4, we're going to have lots of bits to make this much
easier. It's of course still totally not required to do this, but for
those users with RHEL,
or those users wanting to try Spacewalk with Fedora or CentOS, this
should be highly useful.
----
(1) For starters, new variables in /var/lib/cobbler/settings:
redhat_management_type = "off", "hosted", or "site"
# Hosted means RHN, site means Satellite or Spacewalk. This is
explained in the config file comments.
redhat_management_server = "foosball.example.org"
# This is the address of your Satellite/Spacewalk install, or is left as
"xmlrpc.rhn.redhat.com" for Hosted RHN
redhat_management_key = ""
# This is the default authentication key to use when installing
systems. If you have this blank, they won't attempt to register at
all. This is the default.
-----
(2) The key can be set at any level of Cobbler and can be overriden on
the way down:
cobbler distro edit --name=foo --redhat-management-key=ALPHA
cobbler profile edti --name=bar --redhat-management-key=BETA
cobbler system edit --name=baz --redhat-management-key=GAMMA
In the above example, "GAMMA" would be used when booting directly to the
system install.
-----
(3) A new snippet, which is /automatically/ included in the sample
kickstart files (/var/lib/cobbler/kickstarts) called "redhat_register"
that automatically writes out your
configuration for you.
For example, if configured to use Satellite/Spacewalk, it might write out:
# begin Red Hat management server registration
mkdir -p /usr/share/rhn
wget
http://spacewalk.example.redhat.com/pub/rhn/RHN-ORG-TRUSTED-SSL-CERT -O
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
rhnreg_ks --serverUrl=https://spacewalk.example.redhat.com/XMLRPC
--sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=GAMMA
# end Red Hat management server registration
If configured instead for hosted:
# begin Red Hat management server registration
mkdir -p /usr/share/rhn
rhnreg_ks --serverUrl=https://xmlrpc.rhn.redhat.com/XMLRPC
--sslCACert=/usr/share/rhn/RHNS-CA-CERT --activationkey=GAMMA
# end Red Hat management server registration
All of this is done for you so you don't have to remember what the
arguments to RHN register are, or remember how to add them to your
kickstarts.
-----
Choose "off" (default), "hosted", or "site" as needed and all things
will be set up for you. If you have /some/ systems you want to
register with Satellite/RHN (for example, RHEL systems) and you have
some you don't (for example, Fedora systems), just leave the
--redhat-management-key blank for the ones you don't want to register.
Disclaimer: this is currently untested with live registration and I'm
going to be relying on my Spacewalk friends for that, shortly, but
should be good to go. I also still have to add this to the web app
so the keys are editable there also, look for this shortly.
--Michael
15 years, 4 months
selinux: security context of the logical volumes of the LVM
by Anton Arapov
Oh, well...
It turns out that just to do 'chcon -t context /dev/mapper/volume'
is not enough, the security context will be reset to default one at
the next reboot.
To make it permanent we need to use:
# semanage fcontext -a -t virt_image_t /dev/mapper/volume
But, at the moment it is impossible to put it to the sub_process.call()
just because the execution of semanage tool will be prohibited be
SELinux rules. The script, that executes semanage should have the
appropriate context='semanage_t' as well... Futhermore, because of
implementation, selinux wants this context on %HOME%/.koan and/or
%HOME%/.koan/koan.log that means crap,....
Ohh .... does this ring the bell to anybody? Will try to invent
something ...
But, anyway, we must to let users of selinux systems know, that
making the context to LVM partition is necessary, by semanage tool.
-- Anton
15 years, 4 months
