Michael DeHaan wrote:
It seems that Cobbler's usage of restorecon is also not only
slow, but
it's also unneccessary.
Right now I think this is the cause of the "slow sync" problem.
So, my current plan, unless this turns out to /not/ work is:
(A) have cobbler check warn if the following semanage rules aren't
set, and tell the user to run them:
/usr/sbin/semanage fcontext -a -t public_content_t
"/var/www/cobbler/images/.*"
/usr/sbin/semanage fcontext -a -t public_content_t
"/var/lib/tftpboot/images/.*"
/usr/sbin/semanage fcontext -a -t public_content_t "/tftpboot/images/.*"
(B) Remove the logic in cobbler that calls restorecon, as copies should inherit the
SELinux context of the directory in question. (Move's dont, but we don't use
move).
This should speed up things considerably.
--Michael
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
To add data to this:
make test with restorecon being called --- 134 seconds
make test without restorecon -- 55 seconds
Unless I get a report back saying "sync is slow without selinux
enabled", I'm pretty sure that's it.
It's also the most likely culprit seeing the way restorecon is being
invoked by Cobbler repeatedly (Cobbler's fault, not restorecon's). The
bonded interface thing being relevant does not seem likely, what most
likely happens (I /think/) is that cobbler sync wasn't timed until after
upgrading, and that's the first thing folks might have been playing with.
Reasonable diagnosis?
--Michael