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@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