On Thu, Apr 12, 2012 at 2:00 PM, Robert Jacobson
<[email protected]> 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
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
