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/)
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?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson [email protected]
Lead System Admin Solar Dynamics Observatory (SDO)
Bldg 14, E222 (301) 286-1591
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
