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 robert.c.jacob...@nasa.gov Lead System Admin Solar Dynamics Observatory (SDO) Bldg 14, E222 (301) 286-1591
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler