Description of problem: When BackupPC is upgraded, it runs restorecon over /var/lib/BackupPC. This takes 12 hours on my machine, and it is not a very large pool. Version-Release number of selected component (if applicable): BackupPC-3.1.0-9.fc12.noarch How reproducible: When /var/lib/BackupPC has some content, after a few machines have been backed up. Steps to Reproduce: 1. Back up some machines. 2. Wait for a new BackupPC. 3. yum upgrade Actual results: Takes 12 hours to run restorecon. Expected results: Does not take 12 hours.
I really do not know what you want me to do... If restorecon takes too long, that's not BackupPC related. Anyways, I've already run restorecon (on F-11, i'm not using rawhide) against Gigas of datas and thousands of files, that takes much time, but not 12 hours... Does running manually restorecon on you backup directory takes 12 hours ?
Running "find /var/lib/BackupPC" takes 20 minutes and returns 4123986 lines. 4 million filesystem objects is a lot to process. How long does "time find /var/lib/BackupPC | wc" take on your machine? restorecon could take several times that. Why is restorecon run in the postinst script anyway? In most cases the files should be correctly labelled already, yes? Almost no packages do this, why does BackupPC?
$ time find /var/lib/BackupPC/ | wc 5498440 5914320 650213286 real 35m7.903s user 1m5.754s sys 3m8.160s Files should be correctly labelled, but they're not... I've recently fixed a bug concerning the embedded selinux module, and relabelling should be required. Relabelling should probably not be required each time, anyways ; I should consider to remove the restorecon from the package, user would be responsible to launch it in that case. Also consider that BackupPC is not upgraded so frequently.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can confirm that on some volumes the relabel will take 12 hours or more. I don't know if this is possible, but would it be possible to put out a notice that this is what is happening and that you just need to wait. Another weird option might be to put a job in the cron system to do this that self deletes. But I am not in favor of this.
Is restorecon in need of some optimization? I don't have a good handle on whether we should expect it to take as long as it does. In any case, updating an RPM is not an operation which anyone will expect to take more than a few minutes---so it warning the use that updating BackupPC could take ages might be wise if neither making restorecon faster nor avoiding it altogether are feasible.
Running "find /var/lib/BackupPC" takes 20 minutes. If restorecon takes 12 hours, that's only 36 times slower. Does restorecon do 36 times the amount of work of find? Maybe.
The only way I can "solve" that in the BackupPC RPM is to disable restorecon while upgrading but I'm affraid that should cause "SELinux issues" if a relabel were really required and the user is not aware of that...
Is it possible to detect the conditions under which a relabel is necessary, and only do it under those conditions? That would mitigate the problem somewhat.
(In reply to comment #9) > Is it possible to detect the conditions under which a relabel is necessary, and > only do it under those conditions? That would mitigate the problem somewhat. I do not think such a thing is possible. On the other hand, for those that do not use /var/lib/BackupPC to store their backups (as I do), backup directory will never be relabelled by the package ; so I guess that disabling relabel at update time should not be a such bad idea. Other opinions?
My thoughts on this is that this would be much better done as a script. The script could be distributed as a part of the package, and then if needed run. It could default to the /var/lib/BackupPC tree, and could be overriden with a parameter for whatever the real root is if someone is using a different one. If you would post here or send me the relabel command I would be willing to take on the task of writing and documenting this script.
So, Comment 10 says > I do not think such a thing is possible. in reply to my question about detecting the conditions under which relabelling needs to happen. And Comment 11 suggests that relabelling "would be much better done as a script". > The script could be distributed as a part of the package, and then if needed run. Either we can detect the conditions under which such a script would need to run, and then the RPM post-install script should do it for us, or we can't, in which case the user won't know when to run the proposed script, either.
Alternatively, is it just a bad idea to have BackuPC default to /var/lib/BackuPC for its storage? If it defaulted to, say, /home/BackupPC, then restorecon wouldn't need to be run at all, right?
The problem is not related to the path where are stored backups, all files owned by the package are relabelled actually. I've asked the relabelling question on #selinx on IRC, and the response I get was: "Just restorecon on any files that it has special labels for.". Package does not specify any specific context on /var/lib/BackupPC, so it does not have to relabel that directory. I'll comit the change quickly.
BackupPC-3.1.0-10.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/BackupPC-3.1.0-10.fc12
BackupPC-3.1.0-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/BackupPC-3.1.0-8.fc11
BackupPC-3.1.0-8.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0668
BackupPC-3.1.0-10.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0692
The update still runs "restorecon -R /var/lib/BackupPC".
BackupPC-3.1.0-11.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/BackupPC-3.1.0-11.fc12
BackupPC-3.1.0-5.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/BackupPC-3.1.0-5.el5
BackupPC-3.1.0-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/BackupPC-3.1.0-9.fc11
(In reply to comment #19) > The update still runs "restorecon -R /var/lib/BackupPC". Indeed, I made a mistake, sorry. I've just pushed again an update to fix that.
(In reply to comment #23) > (In reply to comment #19) > > The update still runs "restorecon -R /var/lib/BackupPC". > > Indeed, I made a mistake, sorry. I've just pushed again an update to fix that. Thanks! This update installs in <3 minutes instead of multiple hours.
BackupPC-3.1.0-5.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0079
BackupPC-3.1.0-9.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0713
BackupPC-3.1.0-11.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0741
BackupPC-3.1.0-5.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.1.0-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.1.0-11.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.