Description of problem:
Netatalk can't load uams libraries
Version-Release number of selected component (if applicable):
(with option : log file = /var/log/netatalk.log)
look at the logs
Steps to Reproduce:
3.look at the logs
Should be fixed with netatalk-3.1.12-2.1.mga7 in Core/Updates_testing repo!
- remove no more needed 'nodlopen' ldflags hack (fixes mga#26347)
- move uams path from atalk to netatalk
- enable D-Bus support
- enable quota support
- enable dtrace support
- add patch to port afpstats to python3
Updated packages in core/updates_testing:
Netatalk 3.1.12 =>
MGA7-64 Plasma on Lenovo B50
No installation issues
Ref to bug 24072 for tests, so updated /etc/netatalk/afp.conf, it reads now
; Netatalk 3.x configuration file
; Global server settings
basedir regex = /home
; [My AFP Volume]
path = /home/tester7
; [My Time Machine Volume]
; path = /path/to/backup
; time machine = yes
# systemctl start netatalk
[root@mach5 ~]# systemctl -l status netatalk
● netatalk.service - Netatalk AFP fileserver for Macintosh clients
Loaded: loaded (/usr/lib/systemd/system/netatalk.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2020-03-18 10:48:38 CET; 3s ago
Process: 19633 ExecStart=/usr/sbin/netatalk (code=exited, status=0/SUCCESS)
Main PID: 19635 (netatalk)
├─19636 /usr/sbin/afpd -d -F /etc/netatalk/afp.conf
└─19637 /usr/sbin/cnid_metad -d -F /etc/netatalk/afp.conf
Mar 18 10:48:38 mach5.hviaene.thuis systemd: Starting Netatalk AFP fileserver for Macintosh clients...
Mar 18 10:48:38 mach5.hviaene.thuis systemd: netatalk.service: Can't open PID file /var/lock/netatalk (yet?) after star>
Mar 18 10:48:38 mach5.hviaene.thuis netatalk: Netatalk AFP server starting
Mar 18 10:48:38 mach5.hviaene.thuis cnid_metad: CNID Server listening on localhost:4700
Mar 18 10:48:38 mach5.hviaene.thuis systemd: Started Netatalk AFP fileserver for Macintosh clients.
Mar 18 10:48:38 mach5.hviaene.thuis netatalk: Registered with Zeroconf
Mar 18 10:48:38 mach5.hviaene.thuis afpd: Netatalk AFP/TCP listening on 192.168.2.5:548
Downloaded pea.py file (will attach it) for test, but that fails connectiong to my own laptop:
$ python pea.py -i 192.168.2.5 -lv
[+] Attempting connection to 192.168.2.5:548
[+] Sending exploit to overwrite preauth_switch data.
[+] Listing volumes
Traceback (most recent call last):
File "pea.py", line 288, in <module>
File "pea.py", line 116, in list_volumes
afp_data = parse_dsi(resp, 1)
File "pea.py", line 87, in parse_dsi
(flags, command, req_id, error_code, length, reserved) = struct.unpack_from('>BBHIII', payload)
struct.error: unpack_from requires a buffer of at least 16 bytes
Created attachment 11555 [details]
testing connection script
Herman, I read through Bug 24072 (which was eventually validated mostly on the basis of a clean install) and I see that both you and Lewis saw messages that resembled the following:
jan 10 14:54:18 mach6.hviaene.thuis afpd: uam: uams_dhx.so load failure
jan 10 14:54:18 mach6.hviaene.thuis afpd: uam_load(uams_dhx2.so): failed to load: /usr/lib/at
Someone please correct me if I am wrong, but it appears to me from the description that this update is meant to address those failure messages, and indeed I do not see them in Comment 3 here. That makes it look like the fault for which the bug was reported has been corrected.
Going by that logic, I'm inclined to OK and validate this bug. Are there any objections?
Validating. Advisory in Comment 2.
An update for this issue has been pushed to the Mageia Updates repository.