Bug in parsing users.conf
by Paul Company
Running Cobbler 1.6.6 on RHEL 5.3
Here's the configuation:
# vi /etc/cobbler/modules.conf
[authentication]
module = authn_configfile
[authorization]
module = authz_ownership
:wq!
# htdigest /etc/cobbler/users.digest "Cobbler" pcompany
Adding user pcompany in realm Cobbler
New password: yaba
Re-type new password: yaba
# htdigest /etc/cobbler/users.digest "Cobbler" pcompany(a)EXAMPLE.COM
New password: daba
Re-type new password: daba
# vi /etc/cobbler/users.conf
[admins]
admin = ""
cobbler = ""
pcompany = ""
pcompany(a)EXAMPLE.COM = ""
:wq!
# vi /etc/httpd/conf.d/cobbler.conf
<Directory "/var/www/cobbler/web/">
AuthType Basic
AuthName Cobbler
Require valid-user
SetHandler mod_python
PythonAuthenHandler index
PythonHandler index
PythonPath "sys.path + ['/var/www/cobbler/web/']"
PythonDebug on
</Directory>
:wq!
# /etc/init.d/cobblerd restart
# /etc/init.d/httpd restart
Browse to the Web UI and login as (A) pcompany and (B) pcompany(a)EXAMPLE.COM:
(A1) Logging in as pcompany works fine. Authentication works.
(A2) Authorization for pcompany works.
pcompany has full permissions to
list/copy/modify/new/remove/save on distros, profiles, systems, repos,
kickstarts
This is because user.conf is parsed correctly and it finds pcompany.
(B1) Logging in as pcompany(a)EXAMPLE.COM works fine. Authentication works.
(B2) Authorization for pcompany(a)EXAMPLE.COM fails!
This is because user.conf is parsed incorrectly and it can not
find pcompany(a)EXAMPLE.COM
Here's what's left in the log, see line 1044
# cat /var/log/cobbler/cobblerd.log
2009-08-13 17:37:56,905 - api - login attempt; user(pcompany(a)EXAMPLE.COM)
2009-08-13 17:37:56,905 - api - authenticate; ['pcompany(a)EXAMPLE.COM',
'big long encryption string']
2009-08-13 17:37:56,906 - api - login succeeded; user(pcompany(a)EXAMPLE.COM)
2009-08-13 17:37:57,035 - api - calling authorize for resource
['new_system', None, None]; user(pcompany(a)EXAMPLE.COM)
2009-08-13 17:37:57,035 - api - Exception occured: cobbler.cexceptions.CX
2009-08-13 17:37:57,035 - api - Exception value: 'user does not have
access to resource: new_system'
2009-08-13 17:37:57,036 - api - Exception Info:
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line
1000, in check_access_no_fail
self.check_access(token,resource,arg1,arg2)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line
1013, in check_access
rc = self.__authorize(token,resource,arg1,arg2)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line
1044, in __authorize
raise CX(_("user does not have access to resource: %s") % resource)
Can anyone think of a quick fix?
I'm assuming it's choking on the @ symbol.
I tried quoting it, but that didn't work.
We probably have to modify /usr/lib/python2.4/site-packages/cobbler/remote.py?
Or whatever python module parses users.conf?
14 years, 9 months
[PATCH] fixing --static-interface errors when called with --profile
by Peter Halliday
---
koan/app.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/koan/app.py b/koan/app.py
index 8a8196f..ad20044 100755
--- a/koan/app.py
+++ b/koan/app.py
@@ -314,6 +314,10 @@ class Koan:
self.virt_type = "xenpv"
raise InfoException, "--virt-type should be qemu, xenpv, xenfv, vmware, vmwarew, or auto"
+ # if --specific-interface and --profile was called together, then fail
+ if self.specific_interface is not None and self.profile is not None:
+ raise InfoException, "--specific-interface option is incompatible with --profile option use --system instead"
+
# perform one of three key operations
if self.is_virt:
self.virt()
--
1.6.2.5
14 years, 9 months
[PATCH 2650/2650] bug # 451 - cobbler check complains about -l flag whether it's there or not
by Peter Halliday
---
cobbler/action_check.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cobbler/action_check.py b/cobbler/action_check.py
index e6799ce..bf1f4a9 100644
--- a/cobbler/action_check.py
+++ b/cobbler/action_check.py
@@ -126,7 +126,7 @@ class BootCheck:
status.append(_("reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?"))
if not os.path.exists("/usr/bin/yumdownloader"):
status.append(_("yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?"))
- if self.settings.yumreposync_flags.find("\-l"):
+ if self.settings.yumreposync_flags.find("-l"):
if self.checked_dist == "redhat" or self.checked_dist == "suse":
yum_utils_check = sub_process.Popen("/usr/bin/rpmquery --queryformat=%{VERSION} yum-utils", shell=True, close_fds=True, stdout=sub_process.PIPE)
yum_utils_ver = yum_utils_check.communicate()[0]
--
1.6.4
14 years, 9 months
events per system and kickstart status
by Vreman, Peter
Can the events system be extended to include a reference of the system? Including also the kickstart status creates audit information per system. Adding a unique identifier per deployment extends it with additional audit per kickstart.
The format of the event log can look like:
<systemname>,<time>,<user>,<unique deployid/taskid>,<msg>,<comments>
For the node independent actions a special Nodename field like "<<task>>" can be added.
Node1,08-08-09_01:00:00,admin,3214343432,"Kickstart start",""
Node1,08-08-09_01:30:00,admin,3214343432,"Kickstart end" ,"See /var/log/cobbler/anamon/node1/ for log files"
Node1,08-08-09_01:40:00,admin,3214343432,"Reboot done" ,""
Node1,08-08-09_01:42:00,admin,3214343432,"Final configuration start" ,""
Node1,08-08-09_01:45:00,admin,3214343432,"Final configuration end" ,""
<<task>>,08-08-09_01:30:00,testing,3214343456,"Sync start"," See /var/log/cobbler/tasks/3214343456/ for log files"
<<task>>,08-08-09_01:31:00,testing,3214343456,"Sync end",""
<<task>>,08-08-09_01:32:00,testing,3214343487,"Buildiso start"," See /var/log/cobbler/tasks/3214343487/ for log files"
<<task>>,08-08-09_01:33:00,testing,3214343487,"Buildiso end","ISO now available for <A HREF=\"/cobbler/pub/generated.iso\">download</A>"
Work that I see that needs to be done:
- Event list shall be made persistent
- Add systemname field to event list
- Add an unique identifier in the kickstart template to indicate a new (re)deployment
- Extend services to allow POST data for the message to support generating an event message from the node with wget:
$ wget -post-data "msg=Final configuration start" http://`echo<http://%60echo> $COBBLER_SERVER`/cblr/svc/event/node1" -o /dev/null
Thoughts?
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, 9 months
[PATCH 3046/3046] Setting default priorities for distro repos.
by Peter Halliday
---
cobbler/action_import.py | 2 +-
cobbler/settings.py | 1 +
installer_templates/settings.template | 4 ++++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/cobbler/action_import.py b/cobbler/action_import.py
index 9ffc535..be6b763 100644
--- a/cobbler/action_import.py
+++ b/cobbler/action_import.py
@@ -481,7 +481,7 @@ class Importer:
config_file.write("baseurl=http://@@http_server@@/cobbler/ks_mirror/%s\n" % (urlseg))
config_file.write("enabled=1\n")
config_file.write("gpgcheck=0\n")
- config_file.write("priority=1\n")
+ config_file.write("priority=$yum_distro_priority\n")
config_file.close()
# don't run creatrepo twice -- this can happen easily for Xen and PXE, when
diff --git a/cobbler/settings.py b/cobbler/settings.py
index 83d52c9..6c38ecd 100644
--- a/cobbler/settings.py
+++ b/cobbler/settings.py
@@ -105,6 +105,7 @@ DEFAULTS = {
"xmlrpc_port" : 25151,
"yum_post_install_mirror" : 1,
"createrepo_flags" : "-c cache -s sha",
+ "yum_distro_priority" : 1,
"yumdownloader_flags" : "--resolve",
"reposync_flags" : "-l -m -d"
}
diff --git a/installer_templates/settings.template b/installer_templates/settings.template
index b513c85..6cec9e6 100644
--- a/installer_templates/settings.template
+++ b/installer_templates/settings.template
@@ -353,6 +353,10 @@ webdir: /var/www/cobbler
# port option to koan if it is not the default.
xmlrpc_port: 25151
+# the default yum priority for all the distros. This is only used
+# if yum-priorities plugin is used. Use with caution
+yum_distro_priority: 1
+
# "cobbler repo add" commands set cobbler up with repository
# information that can be used during kickstart and is automatically
# set up in the cobbler kickstart templates. By default, these
--
1.6.4
14 years, 9 months
[REGRESSION] - new_subprofile
by Bill Peck
Hello,
XMLRPC call new_subprofile doesn't exist in version 1.7. Even though
new_profile can handle creating sub_profiles in the new code we should
provide the old method for backwards compatibility.
http://fedorapeople.org/gitweb?p=bpeck/public_git/cobbler.git;a=commit;h=...
commit 801fcfe895ffa328ca42232a405e94f84382f522
Author: Bill Peck <bpeck(a)redhat.com>
Date: Tue Aug 11 13:08:55 2009 -0400
backwards compatible new_subprofile call
diff --git a/cobbler/remote.py b/cobbler/remote.py
index e46e34b..f951acd 100644
--- a/cobbler/remote.py
+++ b/cobbler/remote.py
@@ -717,6 +717,7 @@ class CobblerXMLRPCInterface:
return self.new_item("distro",token)
def new_profile(self,token):
return self.new_item("profile",token)
+ new_subprofile = new_profile
def new_system(self,token):
return self.new_item("system",token)
def new_repo(self,token):
14 years, 9 months
The question? When is 2.0 coming out
by Michael DeHaan
Answer: soon!
Here's the present TODO file, as stored in git:
- HIGH PRIORITY:
- Test interfaces in CLI and webapp thoroughly
- make authz_ownership work for all of the new commands (require admin
group?)
- verify duplicate hostname and ip code works
- yum SHA knowledge for F11/F12 from older OS (reposync/import)
- MODERATE PRIORITY:
- Look over old webapp and ensure tooltips in new version are good
enough or better
- Replicate improvements
- reinstate reports with formatted output options
I think the biggest challenge here is the ownership one, as that
requires some testing, and well, testing in general.
If you are interested in helping with testing/fixing, some of the code
that is in lesser used corners needs the most attention:
* manage_dhcp/manage_dns for both ISC/named and dnsmasq
* power management (?) which has had some cleanup lately
I still have yet to redo replicate, so no point in testing that just
yet. Most other things should be fair game.
If someone wants to go ahead and add the "-s sha" stuff to the
createrepo calls so working with Fedora 11/12 from EL-4/5 works
*without* installing python-hashlib, that would be an easy one. I'll
knock it out eventually if no one else does this week.
Getting the advanced formatting report commands to work would be nice,
but may take an overhaul, I don't think I was kind to the present
implementation when doing the XMLRPC based CLI. I think it would be
nice if these could also be generated in the web app (with URLs that
were easily formed to generate them) -- but no major item of
importance. Would also be nice if "cobbler status" worked via the
webapp, though PV and I were talking about potential overhaul some today
-- that might wait for 2.1
Anything else? Comments? Questions?
If you are currently working on something, plan on being finished up and
ready for testing in the next 2 weeks. Unfinished things are fine, but
this means we'll be putting them on a branch.
Since 2.0 was the big refactor/cleanup to make contributions easier for
everyone, I suspect future releases will be able to come out at greater
frequency, and will also be more focused around individual usable items
-- like the deployment features, or maybe network objects, depending on
interest.
(Sidenote -- Debian stuff seems to be ongoing on IRC but I've heard
little actual details. Please post and link to your repos with what
you are doing. Thanks! I would like to have this to be a major
theme of 2.1 (most likely) though it will be entirely fueled by your
contributions. By major theme I mean get it completely done. Koan
support, import, repo support, etc. Let's make it good, and do share
what you have so far. If it's not done by then, I don't want a
half-finished implementation in a stable codebase, and we need to look
at whether it belongs in there. So, good reason to knock it out of the
park once and for all.)
--Michael
14 years, 9 months
Removal of settings from settings
by Michael DeHaan
One of the defects in my queue is a bug that says the default DHCP.conf
path is different in Fedora-11 (or was it 12? Anyway...)
We have a bunch of settings like this in ... settings.
"bind_bin" : "/usr/sbin/named",
"dhcpd_bin" : "/usr/sbin/dhcpd",
"dnsmasq_bin" : "/usr/sbin/dnsmasq",
"httpd_bin" : "/usr/sbin/httpd",
"omshell_bin" : "/usr/bin/omshell",
"restart_bin" : "/sbin/service",
"tftpd_bin" : "/usr/sbin/in.tftpd",
"vsftpd_bin" : "/usr/sbin/vsftpd",
I'm suggesting we remove all of these and use default distribution
paths, always.
Yes, this breaks people who are doing something weird. I am not sure
this bothers me though.
On the plus side, it cuts down a lot on a really verbose settings file
that should have less settings in it.
Does someone want to give me the path settings for Debian?
Basically we'll have a function in utils that, depending on the OS,
returns the correct path for these various files.
This should prevent the need to have different versions of settings for
various distributions, which could be infinitely many, the way these
things like to move.
We already do this with finding the TFTP boot location, so it shouldn't
be too controversial.
--Michael
14 years, 9 months