Description of problem: Netatalk can't load uams libraries Version-Release number of selected component (if applicable): How reproducible: install netatalk configure /etc/netatalk/afp.conf (with option : log file = /var/log/netatalk.log) start netatalk look at the logs Steps to Reproduce: 1.install netatalk 2.start netatalk 3.look at the logs
Should be fixed with netatalk-3.1.12-2.1.mga7 in Core/Updates_testing repo!
CC: (none) => geiger.david68210
Advisory: ----------------------------------------- - 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-2.1.mga7 libnetatalk18-3.1.12-2.1.mga7 libnetatalk-devel-3.1.12-2.1.mga7 from netatalk-3.1.12-2.1.mga7.src.rpm
Assignee: bugsquad => qa-bugsSource RPM: Netatalk 3.1.12 => netatalk-3.1.12-2.mga7.src.rpm
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] ; Global server settings ; [Homes] basedir regex = /home ; [My AFP Volume] path = /home/tester7 ; [My Time Machine Volume] ; path = /path/to/backup ; time machine = yes then # 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 Docs: man:afp.conf(5) man:netatalk(8) man:afpd(8) man:cnid_metad(8) man:cnid_dbd(8) http://netatalk.sourceforge.net/ Process: 19633 ExecStart=/usr/sbin/netatalk (code=exited, status=0/SUCCESS) Main PID: 19635 (netatalk) Memory: 3.8M CGroup: /system.slice/netatalk.service ├─19635 /usr/sbin/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[1]: Starting Netatalk AFP fileserver for Macintosh clients... Mar 18 10:48:38 mach5.hviaene.thuis systemd[1]: netatalk.service: Can't open PID file /var/lock/netatalk (yet?) after star> Mar 18 10:48:38 mach5.hviaene.thuis netatalk[19635]: Netatalk AFP server starting Mar 18 10:48:38 mach5.hviaene.thuis cnid_metad[19637]: CNID Server listening on localhost:4700 Mar 18 10:48:38 mach5.hviaene.thuis systemd[1]: Started Netatalk AFP fileserver for Macintosh clients. Mar 18 10:48:38 mach5.hviaene.thuis netatalk[19635]: Registered with Zeroconf Mar 18 10:48:38 mach5.hviaene.thuis afpd[19636]: 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 [+] Connected! [+] Sending exploit to overwrite preauth_switch data. [+] Listing volumes Traceback (most recent call last): File "pea.py", line 288, in <module> list_volumes(sock) 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
CC: (none) => herman.viaene
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[5228]: uam: uams_dhx.so load failure jan 10 14:54:18 mach6.hviaene.thuis afpd[5228]: 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?
CC: (none) => andrewsfarm
No objections.
Validating. Advisory in Comment 2.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: (none) => MGA7-64-OK
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0126.html
Status: NEW => RESOLVEDResolution: (none) => FIXED