cobbler cli user doesn't work after 1.x to 2.0.1 upgrade
by Chris Kelly
Hello-
I upgraded from 1.x to 2.0.1 and the cobbler cli user no longer works.
example:
[root@admin1 ~]# cobbler system add --name=foobar
cobbler.cexceptions.CX:'user <DIRECT> does not have access to
resource: xedit_system'
[root@admin1 ~]#
Looking around in the source code, I see:
/usr/lib/python2.4/site-packages/cobbler/modules/authz_ownership.py
def authorize(api_handle,user,resource,arg1=None,arg2=None):
"""
Validate a user against a resource.
All users in the file are permitted by this module.
"""
if user == "<DIRECT>":
# CLI should always be permitted
return True
...
so that should fall through fine. However, we are using LDAP
([authentication] module = authn_ldap) and I don't see any such code
in the LDAP module. It doesn't seem that adding similar code to the
authn_ldap.py file (and clearing pyo and pyc files and restarting
cobblerd) does the trick.
We are using the config file to manage users ([authorization] module =
authz_configfile) and adding <DIRECT> as a user there doesn't let root
on the command line back in.
Any ideas? Thanks!
-Chris
13 years, 11 months
cobblerd and umask(0) (#535)
by Mattias Slabanja
Hi.
I noted that cobblerd is running with umask(0) and hence are creating
files that are world writable (e.g. files under /tftboot/ or config
files under /etc/ such as rsyncd.conf).
IMHO that is wrong. Files should not be created world writable as
default, so I created a ticket for it, #535.
As a tentative fix, I simply removed os.umask(0) from scripts/cobblerd,
which restored the umask for cobblerd to root-default (typically 022).
However, that had the side effect that mod_python (which is invoked by
apache) failed due to file permissions since service.py import utils.py
which unconditionally tries to create a clogger.Logger-object using
/var/log/clobber/clobber.log as default log file (which, when no longer
world writable, is not writable by apache).
Just to be more clear, I have made my own temporary work around for
the issue available at http://github.com/slabanja/cobbler/commits/slabanja/.
The work around, as it is, is maybe not suitable as a patch though.
Questions:
* Were/are there any special reason for having cobblerd running with
umask=0?
* Does (the mod_python invoked) service.py really need the
clogger.Logger-object that is created in utils.py? Or could the creation
simply be conditionally left out for e.g. mod_python running as apache?
Best regards,
Mattias
14 years, 4 months
Correct improper import of recent i386 Fedora/RHEL distros
by James Laska
Greetings,
When importing an Fedora/i386 or newer RHEL/i386 builds, cobbler was only importing the PAE kernel. The attached patch corrects this behavior and imports both the regular, and PAE kernel/initrd. I've also updated cobbler/codes.py to add 'fedora12' and 'fedora13'.
This patch is against 'origin', but should also be applied to cobbler-2.0 branch. Comments appreciated.
Thanks,
James
--
==========================================
James Laska -- jlaska(a)redhat.com
Quality Engineering -- Red Hat, Inc.
==========================================
14 years, 4 months
Anyone still working esx support?
by Aaron Lippold
Hi all
I know with RHEV this may be sinful to utter but is anyone still
looking at ESX server provisioning?
Thanks,
Aaron Lippod
lippold(a)gmail.com
AIM/YAHOO: aaronlippold
14 years, 4 months
Re: Anyone still working esx support?
by Aaron Lippold
Hi,
Here is a link to the docs.
http://libvirt.org/drvesx.html
- Aaron
On Mon, Nov 16, 2009 at 8:39 AM, Tim Scully <tim.scully(a)jackpinetech.com> wrote:
>
> possibly. need to look at the updates to libvirt to see what they're calling to ESX
>
> Tim Scully
> tim.scully(a)jackpinetech.com
> 978.263.6025 Office / 603.943.0823 Mobile
> www.jackpinetech.com
>
>
>
>
>
> On Nov 15, 2009, at 11:25 PM, Aaron Lippold wrote:
>
>> Good news?
>>
>> A
>>
>>
>> ---------- Forwarded message ----------
>> From: Jeff Schroeder <jeffschroed(a)gmail.com>
>> Date: Fri, Nov 13, 2009 at 7:32 PM
>> Subject: Re: Anyone still working esx support?
>> To: cobbler development list <cobbler-devel(a)lists.fedorahosted.org>
>>
>>
>> On Fri, Nov 13, 2009 at 4:18 PM, Corey Osman <cosman2001(a)me.com> wrote:
>>> I was actually thinking of making a java cli app for general vmware
>>> control. This could be used for things like server provisioning. I
>>> don't know how much time I'll have but I could lay out the groundwork
>>> and open source it and hopefully vmware programmers will contribute.
>>
>> FYI: Libvirtd has support for working with ESX via the remote api in
>> 0.7.2. That means you should be able to use the virsh* suite of tools
>> from the cli.
>>
>> It should be somewhat trivial to make cobbler / koan support it if
>> libvirt supports it.
>>
>>> Sent from my iPhone
>>>
>>> On Nov 13, 2009, at 6:24 PM, Aaron Lippold <lippold(a)gmail.com> wrote:
>>>
>>>> Hi all
>>>>
>>>> I know with RHEV this may be sinful to utter but is anyone still
>>>> looking at ESX server provisioning?
>>>>
>>>> Thanks,
>>>>
>>>> Aaron Lippod
>>>> lippold(a)gmail.com
>>>> AIM/YAHOO: aaronlippold
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Jeff Schroeder
>>
>> Don't drink and derive, alcohol and analysis don't mix.
>> http://www.digitalprognosis.com
>> _______________________________________________
>> cobbler-devel mailing list
>> cobbler-devel(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/cobbler-devel
>>
>
>
14 years, 4 months
A couple of questions about trac tickets
by Scott Henson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
There are a couple of requests in trac that I would like to discuss.
The first is trac#513. The request is to rename the subnet field to
netmask. I agree that netmask is the far more well known term for this
field, but I'm wondering how deep we want to make this change if we make
it at all.
If we were to make an alias on the command line and add some text about
it in the web interface, people might get confused when it doesn't come
out as netmask and instead comes out as subnet.
Making the change any deeper would have to wait for a major release as
this would disrupt the api in any situation where interface data is
being edited.
The second one is trac#519. The fact that you can't see the parent of a
profile on the command line nor in the web interface. The simple fix is
to set the parent field as a public field and let people track things
down on their own. The other way is to blend the objects before display
and display all the actual data instead of inherit.
Any thoughts on either of these would be much appreciated.
- --
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJK/cCyAAoJEN/U2xG4t+kAIvQP/iFUQQDe9iojVCX+ZNPy1ZK6
LbGJZfcgwZKen5Uyt6K9IcqT+AP+SPULvMxhXj+tHAfjIjcO3xGhNB21MQkiwhgb
9jyn3noDwhcW4NLJ6mHKKWzFxm0eni7IImrZUxyVFw/+2twretnj4H52cD1h7w5T
eBQNn2O4TeT8kn2TDVeIchZxUivrxM5Yi/NbiSIYhzzeCYtjEFo4Tqh7ovng2HNI
JruCicoVIJcTkdXFpQY7R7DMCmndj2BIFc3/YVFqIoFAMOAsDo8I4pJUarT4L4yW
kuYWHbj64b4Shu69edp6ThFMq2L6gam57cVJraGfKdOrPk78Sl9c0A3RlINM48YO
gjvcO7IwSzIxIALhSXE5txBrubAN16nqZjshPplOoAX9H9Tt0pHCxWIFgf7SAdmB
yNKqHy10SrJYS2pGGBeduZ7zxSF3KlO4JweZq69QgI3lXvZ2+H/FbjA31kM3goSZ
BdSbmj4i2ivRXh7AVcs3JmIlyD6BjrsVnPjOuEKdeMRBAq1A3g7KQKRZaahm/PZP
doLUANSMIrIsouThDDDolIG1NKccCbxGYNGRjj29+ZUDL53JP7XSlTqUa5wmWNfh
MqzhedvOSjjCmnQxvg6Ejso0GYZUZ9lfYkoiRSZwZEIfL15G6dJtGdnCjfEvHz8S
PhWYppM+tmQID3IRwis2
=p7sv
-----END PGP SIGNATURE-----
14 years, 4 months
[PATCH] Logging and cli error patches for master
by Vreman, Peter
I have the following list of patches for master available at http://github.com/pvreman/cobbler/commits/master/.
Koan:
+ afda8a88249ed3a124651a25fc52e9f78d1ab414 update string_to_hash and hash_to_string from cobblerd to support multiple kernel options with the same name
Logging improvements for background tasks:
+ 90c00b3abba0d15a2e6857469ea24fad00f95b0b make sync actions always verbose, before the copy actions were only logged without context
+ 1a09c11eb2c546d53c366b26ab4acce96d3bc314 logging for creation of dhcp and dns configurations
+ 9867963dc8eb11052ec3521c5baf18803fe826e9 log creation of pxe files
+ 9ee3887130fe2beb49d332a3420166398595242d log updates, add criteria to find_items and make more debug
CLI error handling:
+ e9d0cf90df35dd351c954c097a28ddf752edeb6b exit with error code 1 if command fails
+ 92ba9bb9c5594223083029cc8676b5c20d826c33 raise error in blended data if profile or system not found
WebUI redundant code:
+ efbc6519b34e9b9c95a9298d68fbf340b0a82c1d remove duplicate code
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.
14 years, 4 months
Re: [PATCH] Logging and cli error patches for master
by Garrett Holmstrom
From: "Cristian Ciupitu" <cristian.ciupitu(a)yahoo.com>
Date: Friday, November 13, 2009 4:09 PM
To: "cobbler development list" <cobbler-devel(a)lists.fedorahosted.org>
Subject: Re: [PATCH] Logging and cli error patches for master
> I've noticed too that there is some code shared (copied) between koan and
> cobbler. Maybe it's time to extract a common package for this code,
> something
> like cobbler-common. I would like to hear other opinions regarding this.
Less copied code means less likelihood of mistakes, in my book. A single
extra rpm shouldn't break anything on an installed system anyway, and
symlinks are giant hacks that should probably be avoided.
--
Garrett Holmstrom
University of Minnesota
School of Physics and Astronomy
Systems Staff
14 years, 4 months
"Multi-System" Profile Development / Deployment
by Aaron Lippold
Hello,
I was wondering if anyone had suggestion and or lessons on building
and deploying a "profile set" that has multiple systems / profiles. I
would assume this would be scripting the API or a set of inherited
sub-profiles. The driver / use case for this is a deployment that has
three to four machines ( app, db, svn, directory ) that combine to
make the total deployment. This is easy on a single profile, has
anyone looked at the "multi-machine" profile case?
Thanks,
Aaron
14 years, 4 months