Hi,Sending the amandad.*.debug files from server and client, and an extract from the clients journalctl.
The extract from journalctl suggests report a bug and add a local policy:
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw |
audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Are there new functions in amanda-3.4, that requires extended permissions?
Where should I report a bug, amanda or Fedora?
There are an installed amanda-policy:
[root@uw000140 ~]# semodule -v -l | egrep amanda
amanda
Must I add the my-amandad policy after every reboot or when should I
remove it?
BR, Henrik On 2017-02-18 14:09, Jean-Louis Martineau wrote:
Henrik, It looks like the estimate worked, but there is no sendbackup debug files.Can you post the amandad.*.debug files, they are in /var/log/amanda/amandadDid you checked the system log for error? Jean-Louis On 18/02/17 03:07 AM, Henrik Johansson wrote: > Hi, > > Yesterday I upgraded to amanda-version 3.4.2, on my Fedora-24 client. > It has it has the same error as version 3.4.1, downgraded to 3.3.8 > once again. > > BR, > Henrik > > On 2017-02-01 19:32, Henrik Johansson wrote: >> Hi, >> >> I've stored the log- and debug-files in tree tar-files for each day. >> 2017-01-29 the client had amanda-version 3.4.1: >> From client /tmp/var_log_amanda_client_DailySet1_20170129.tgz >> From server /tmp/var_log_amanda_server_DailySet1_20170129.tgz >> From server /tmp/var_lib_amanda_DailySet1_20170129.tgz >> >> 2017-01-30, the client has amanda-version 3.3.8: >> From client /tmp/var_log_amanda_client_DailySet1_20170130.tgz >> From server /tmp/var_log_amanda_server_DailySet1_20170130.tgz >> From server /tmp/var_lib_amanda_DailySet1_20170130.tgz >> >> BR; >> Henrik >> >> On 2017-02-01 17:02, Jean-Louis Martineau wrote: >>> Post more information. >>> >>> The amdump.<timestamp>, log.<timestamp>.0 and all debug files. >>> >>> Jean-Louis >>> >>> On 01/02/17 03:11 AM, Henrik Johansson wrote: >>> > Hi, >>> > >>> > I have a server with CentOS-7 and one client with Fedora-24. >>> > The server runs amanda 3.3.8, the backups of the client stopped >>> > working, when the client was upgraded to 3.4.1. >>> > amcheck says that all is OK >>> > >>> > Extract from the backup report: >>> > DUMP SUMMARY: >>> > DUMPER >>> > STATS TAPER STATS >>> > HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s >>> > MMM:SS KB/s >>> > --------------------------------- >>> > -------------------------------------- -------------- >>> > ... >>> > <client> /boot 0 -- FLUSH >>> > <client> /home 0 -- FLUSH >>> > >>> > I found a temporary solution and downgraded amanda on the client to >>> > previous version 3.3.8. >>> > >>> > Are there any permanent solution? >>> > >>> > BR, >>> > Henrik >>> > >> >
-- Henrik Johansson E-mail: henrik.johansson.k...@mail.se Voice: +46 924 50129 Mobile: +46 70 555 9998 S Prästholm 799, S-955 91 Råneå, Sweden
var_log_amanda_amandad_20170218_client.tgz
Description: application/compressed-tar
var_log_amanda_amandad_20170218_server.tgz
Description: application/compressed-tar
Feb 18 00:45:04 uw000140 xinetd[927]: START: amanda pid=3056 from=::ffff:192.168.1.7
Feb 18 00:45:53 uw000140 xinetd[927]: EXIT: amanda status=0 pid=3056 duration=49(sec)
Feb 18 00:45:54 uw000140 xinetd[927]: START: amanda pid=3099 from=::ffff:192.168.1.7
Feb 18 00:45:54 uw000140 audit[3099]: AVC avc: denied { write } for pid=3099 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:45:54 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3099 duration=0(sec)
Feb 18 00:45:57 uw000140 dbus-daemon[802]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.38' (uid=0 pid=791 comm="/usr/sbin/sedispatch " label="system_u:system_r:audisp_t:s0") (using servicehelper)
Feb 18 00:45:57 uw000140 dbus-daemon[802]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Feb 18 00:45:57 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:45:58 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:45:58 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:45:58 uw000140 xinetd[927]: START: amanda pid=3110 from=::ffff:192.168.1.7
Feb 18 00:45:58 uw000140 audit[3110]: AVC avc: denied { write } for pid=3110 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:45:58 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3110 duration=0(sec)
Feb 18 00:46:01 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:46:01 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:46:01 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:46:12 uw000140 xinetd[927]: START: amanda pid=3114 from=::ffff:192.168.1.7
Feb 18 00:46:12 uw000140 audit[3114]: AVC avc: denied { write } for pid=3114 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:46:12 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3114 duration=0(sec)
Feb 18 00:46:15 uw000140 python3[3101]: detected unhandled Python exception in '/usr/sbin/setroubleshootd'
Feb 18 00:46:15 uw000140 abrt-server[3115]: Deleting problem directory Python3-2017-02-18-00:46:15-3101 (dup of Python3-2016-11-13-19:10:44-1625)
Feb 18 00:46:15 uw000140 dbus-daemon[802]: [system] Activating service name='org.freedesktop.problems' requested by ':1.345' (uid=0 pid=3120 comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v" label="system_u:system_r:abrt_t:s0-s0:c0.c1023") (using servicehelper)
Feb 18 00:46:15 uw000140 dbus-daemon[802]: [system] Successfully activated service 'org.freedesktop.problems'
Feb 18 00:46:32 uw000140 xinetd[927]: START: amanda pid=3128 from=::ffff:192.168.1.7
Feb 18 00:46:32 uw000140 audit[3128]: AVC avc: denied { write } for pid=3128 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:46:32 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3128 duration=0(sec)
Feb 18 00:46:35 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:46:35 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:46:35 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:46:45 uw000140 xinetd[927]: START: amanda pid=3136 from=::ffff:192.168.1.7
Feb 18 00:46:45 uw000140 audit[3136]: AVC avc: denied { write } for pid=3136 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:46:45 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3136 duration=0(sec)
Feb 18 00:50:10 uw000140 xinetd[927]: START: amanda pid=3148 from=::ffff:192.168.1.7
Feb 18 00:50:10 uw000140 audit[3148]: AVC avc: denied { write } for pid=3148 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:50:10 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3148 duration=0(sec)
Feb 18 00:50:13 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:50:13 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:50:13 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:50:15 uw000140 xinetd[927]: START: amanda pid=3152 from=::ffff:192.168.1.7
Feb 18 00:50:15 uw000140 audit[3152]: AVC avc: denied { write } for pid=3152 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:50:15 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3152 duration=0(sec)
Feb 18 00:50:18 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:50:19 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:50:19 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:50:20 uw000140 xinetd[927]: START: amanda pid=3156 from=::ffff:192.168.1.7
Feb 18 00:50:20 uw000140 audit[3156]: AVC avc: denied { write } for pid=3156 comm="amandad" name="/" dev="tmpfs" ino=11565 scontext=system_u:system_r:amanda_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0
Feb 18 00:50:20 uw000140 xinetd[927]: EXIT: amanda status=1 pid=3156 duration=0(sec)
Feb 18 00:50:23 uw000140 setroubleshoot[3101]: failed to retrieve rpm info for /dev/shm
Feb 18 00:50:23 uw000140 setroubleshoot[3101]: SELinux is preventing amandad from write access on the directory /dev/shm. For complete SELinux messages. run sealert -l 3c13c038-a41e-434d-ab9b-c665203b7659
Feb 18 00:50:23 uw000140 python3[3101]: SELinux is preventing amandad from write access on the directory /dev/shm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that amandad should be allowed write access on the shm 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:
# ausearch -c 'amandad' --raw | audit2allow -M my-amandad
# semodule -X 300 -i my-amandad.pp
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: SystemExit
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: During handling of the above exception, another exception occurred:
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: Traceback (most recent call last):
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: File "/usr/lib64/python3.5/site-packages/dbus/service.py", line 647, in _message_cb
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: if not isinstance(message, MethodCallMessage):
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: SystemError: <built-in function isinstance> returned a result with an error set
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: SystemExit
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: During handling of the above exception, another exception occurred:
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: Traceback (most recent call last):
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: File "/usr/lib64/python3.5/site-packages/dbus/service.py", line 647, in _message_cb
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: if not isinstance(message, MethodCallMessage):
Feb 18 00:50:43 uw000140 org.fedoraproject.Setroubleshootd[802]: SystemError: <built-in function isinstance> returned a result with an error set
Feb 18 00:53:46 uw000140 udisksd[817]: Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/KINGSTON_SUV400S37240G_50026B766800E8ED: Error updating SMART data: sk_disk_smart_read_data: Input/output error (udisks-error-quark, 0)
