2:17 p.m.
On Thu, Apr 12, 2012 at 2:00 PM, Robert Jacobson
<robert.c.jacobson(a)nasa.gov> wrote:
On 4/12/2012 1:40 PM, James Cammarata wrote:
What did you upgrade from? If from 2.0.x, make sure you read this wiki page:
https://github.com/cobbler/cobbler/wiki/2.2.0
Thanks, going through that now.
A few questions:
Change $kickstart_start/_done to $SNIPPET('kickstart_start')/_done in the
default kickstart template.
Where is the "default kickstart template"? I thought it would be
/var/lib/cobbler/kickstarts/default.ks, but "$kickstart_start/_done"
doesn't
appear in that file (or any file in /var/lib/cobbler/kickstarts/)
sample.ks is the most complete. I believe if the RPM install doesn't
detect a difference in MD5 of the file it will replace it with the
most recent one, so you may not have to touch that. That directive is
more for people who may have copied the sample.ks or created versions
of their own with the old style of snippets or hard-coded variables.
There are several references to $SNIPPET('kickstart_start')
in those files,
but nothing to $SNIPPET('kickstart_start')/done or $kickstart_start/_done
In any case , as Jack Peterson mentioned, there appears to be a SELinux
issue. I ran setroubleshoot:
Apr 12 13:58:24 GS-444-E10285 setroubleshoot: SELinux is preventing
/usr/bin/python from write access on the directory
/var/www/cobbler/rendered. For complete SELinux messages. run sealert -l
528b9bb7-e539-4d67-a82a-c89fb7fbc01e
[root@GS-444-E10285 cobbler]# sealert -l
528b9bb7-e539-4d67-a82a-c89fb7fbc01e
SELinux is preventing /usr/bin/python from write access on the directory
/var/www/cobbler/rendered.
***** Plugin restorecon (99.5 confidence) suggests
*************************
If you want to fix the label.
/var/www/cobbler/rendered default label should be cobbler_var_lib_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/cobbler/rendered
***** Plugin catchall (1.49 confidence) suggests
***************************
If you believe that python should be allowed write access on the rendered
directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep cobblerd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
The directory /var/www/cobbler/rendered doesn't exist -- where'd it go? I
looked on my another test server (which still has cobbler 2.0) and the
rendered directory exists -- did updating to 2.2.1 delete it?
In any case, since /var/www/cobbler/rendered didn't exist I couldn't run
restorecon -- so I did the obvious:
- created /var/www/cobbler/rendered
- ran /sbin/restorecon -v /var/www/cobbler/rendered
Then I started cobblerd successfully. I also restarted httpd.
Now Iwhen I try to login to the web interface, the browser reports "Internal
server error"; setroubleshoot shows I'm getting SELinux errors on the
sessions:
Apr 12 14:48:54 GS-444-E10285 setroubleshoot: SELinux is preventing
/usr/sbin/httpd from write access on the directory
/var/lib/cobbler/webui_sessions/sessionidc784de1d76c5e28c949a78aaafb414de.
For complete SELinux messages. run sealert -l
5775d69f-80d1-4283-afa0-1860bb3aed60
# sealert -l 5775d69f-80d1-4283-afa0-1860bb3aed60
SELinux is preventing /usr/sbin/httpd from write access on the directory
/var/lib/cobbler/webui_sessions/sessionidc784de1d76c5e28c949a78aaafb414de.
***** Plugin restorecon (99.5 confidence) suggests
*************************
If you want to fix the label.
/var/lib/cobbler/webui_sessions/sessionidc784de1d76c5e28c949a78aaafb414de
default label should be httpd_sys_rw_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v
/var/lib/cobbler/webui_sessions/sessionidc784de1d76c5e28c949a78aaafb414de
***** Plugin catchall (1.49 confidence) suggests
***************************
If you believe that httpd should be allowed write access on the
sessionidc784de1d76c5e28c949a78aaafb414de directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
# ll /var/lib/cobbler/webui_sessions/
total 0
# ll -Zd /var/lib/cobbler/webui_sessions/
drwxrwxr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0
/var/lib/cobbler/webui_sessions//
I tried running restorecon on /var/lib/cobbler/webui_sessions/ but this did
not resolve the login issue.
I also tried running the SELinux-related commands from cobbler check:
# /usr/sbin/semanage fcontext -a -t httpd_sys_content_rw_t
"/var/lib/cobbler/webui_sessions/.*"
# /usr/sbin/semanage fcontext -a -t public_content_t
"/var/lib/tftpboot/.*" && /usr/sbin/semanage fcontext -a -t
public_content_t
"/var/www/cobbler/images/.*"
(NOTE: there is an error in the "cobbler check" output, the quotes are in
the wrong place:
/usr/sbin/semanage fcontext -a -t public_content_t "/var/lib/tftpboot/.*"
&&
/usr/sbin/semanage fcontext -a -t public_content_t
"/var/www/cobbler"/images/.*
)
In any case, that did not resolve the login issue. Any ideas?
Running cobbler check gives a command for fixing that:
/usr/sbin/semanage fcontext -a -t httpd_sys_content_rw_t
/var/lib/cobbler/webui_sessions/.*
The rendered directory may be a remnant of an old patch, I believe it
was supposed to hold pre-rendered config files that needed to be
generated but couldn't be served through the web interface. I'll look
through the code to see if that's used, but in the mean time I'd just
create it manually:
drwxr-xr-x. apache root system_u:object_r:httpd_cobbler_content_t:s0 rendered