Description of problem: I'm running a custom amanda 3.3.6 on EL6 and get: type=AVC msg=audit(1405719159.849:257884): avc: denied { write } for pid=8744 comm="amidxtaped" name="changer" dev=dm-0 ino=16008 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:amanda_config_t:s0 tclass=file trying to run amrecover. I'm using a fairly standard "tpchanger chg-disk:" configuration, and I'm not specifying the location of this "/etc/amanda/Data/changer" file, so I think it's pretty standard amanda. It would be nice to get this into all released versions EL6+, though I think this is new sometime between amanda 3.3.1 and 3.3.6.
What does # rpm -qf /etc/amanda/Data
file /etc/amanda/Data is not owned by any package When using Amanda, you create arbitrary configurations in /etc/amanda/<configname>. It ships with a default /etc/amanda/DailySet1, but generally users will create their own configs, hence: /etc/selinux/targeted/contexts/files/file_contexts: /etc/amanda/.*/index(/.*)? system_u:object_r:amanda_data_t:s0 /etc/amanda/.*/tapelist(/.*)? system_u:object_r:amanda_data_t:s0
Why does amanda write own config files?
That's just how it works. I can't say that it's remotely intelligent, but amanda stores several things under /etc/amanda that should really be in /var/lib/amanda. Things I've seen amanda write under /etc/amanda/CONF: changer-access changer-barcodes changer-clean changer-slot tapelist tapelist.amlabel tapelist.yesterday I'm sure there are more. It is almost certainly possible to patch these, but I suppose someone should instead pressure upstream to allow specifying a separate path for these writable "configuration files".
So is there a change to move it?
Well, on the base of configure script directive --with-configdir could be used for this issues. But I have to clarify whether it is used for our case.
Well, response from upstream is that directive can be used for this issue. http://archives.zmanda.com/amanda-archives/viewtopic.php?t=7274 I will test that soon.
Created attachment 951765 [details] Patch for movement /etc/amanda/.. to /var/lib/amanda This is the patch which should solved the issues. It would be good to test especially %post section
Question for this is that if we change the location for amanda configurations to /usr/lib/amanda/... then /etc/amanda won't be used for backups anymore. Do you think that this is a correct propose? If admin uses /etc/amanda directory then this directory will not be used by amanda software.
What do you think about my proposal? See my comments above?
No, I don't think this is the way to go. Configuration still belongs in /etc/amanda. The problem is that amanda puts some state information into configdir - specifically the tapelist* and changer files. This is going to need to be addressed upstream.
Looks like the easy solution is: amanda.conf: changerfile "/var/lib/amanda/DailySet1/changer"
Probably should set tapelist while we're at it too.
Changing the default location will break every configuration that upgrade. If the default location is changed, code that verify and FAIL if the files are not in the right location must be added. PS. The tapelist and all others paths can be set in the configuration file. Also check the indexdir, logdir and infofile.
It is perfectly acceptable to change the default location in between Fedora releases; breakage is permitted there though a release note would be pretty important. It is not necessary to try and do automatic conversion, and certainly never appropriate to fail an upgrade in that way (because you can't actually fail an upgrade; scriptlet failure at best does nothing and at worst just screws up the system state). If these are specified in the configuration file, you can certainly change the default any time you like because configuration files aren't overwritten on package upgrades (assuming they're marked %config(noreplace) as amanda.conf is.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Closing as WONTFIX, the solution from #c12 should be sufficient. Feel free to reopen this bug, if you think, that provided solution is not sufficient.