| 2010-03-10 14:02:17 |
C de-Avillez |
description |
Binary package hint: netatalk
Description: Ubuntu 9.10
Release: 9.10
ii netatalk 2.0.4~beta2-5ubuntu2 AppleTalk user binaries
NetATalk fails to generate a unique server signature. Analysis of client/server communication reveals that both NetATalk servers here report the signature 01017F0001017F0001017F0001017F00 . This confuses Mac clients, resulting in them apparently randomly directing AFP requests to one server or the other. Users will connect to SERVER1 and get a volume list from SERVER2 or vice versa.
The netatalk code for generating server signatures (etc/afpd/status.c:191) uses the libc gethostid() call to obtain a 32-bit unique identifier for the host.
GNU Libc's man page for gethostid(3) notes that:
"In the glibc implementation, the hostid is stored in the file /etc/hostid. (In glibc versions before 2.2, the file /var/adm/hostid was used.)
"In the glibc implementation, if gethostid() cannot open the file containing the host ID, then it obtains the hostname using gethostname(2), passes that hostname to gethostbyname_r(3) in order to obtain the host's IPv4
address, and returns a value obtained by bit-twiddling the IPv4 address. (This value may not be unique.)"
Ubuntu systems do not have any /etc/hostid by default, so glibc falls back on gethostbyname_r(3). However, Ubuntu systems' /etc/hosts files map the hostname to 127.0.0.1:
127.0.0.1 localhost
127.0.1.1 HOSTNAME.localnet HOSTNAME
so gethostbyname_r for the hostname in /etc/hostname will always return 127.0.0.1 . gethostid(3) will therefore always return the same value, and NetATalk's system id will always be the same on different Ubuntu hosts. |
Binary package hint: netatalk
Description: Ubuntu 9.10
Release: 9.10
ii netatalk 2.0.4~beta2-5ubuntu2 AppleTalk user binaries
NetATalk fails to generate a unique server signature. Analysis of client/server communication reveals that both NetATalk servers here report the signature 01017F0001017F0001017F0001017F00 . This confuses Mac clients, resulting in them apparently randomly directing AFP requests to one server or the other. Users will connect to SERVER1 and get a volume list from SERVER2 or vice versa.
The netatalk code for generating server signatures (etc/afpd/status.c:191) uses the libc gethostid() call to obtain a 32-bit unique identifier for the host.
GNU Libc's man page for gethostid(3) notes that:
"In the glibc implementation, the hostid is stored in the file /etc/hostid. (In glibc versions before 2.2, the file /var/adm/hostid was used.)
"In the glibc implementation, if gethostid() cannot open the file containing the host ID, then it obtains the hostname using gethostname(2), passes that hostname to gethostbyname_r(3) in order to obtain the host's IPv4
address, and returns a value obtained by bit-twiddling the IPv4 address. (This value may not be unique.)"
Ubuntu systems do not have any /etc/hostid by default, so glibc falls back on gethostbyname_r(3). However, Ubuntu systems' /etc/hosts files map the hostname to 127.0.0.1:
127.0.0.1 localhost
127.0.1.1 HOSTNAME.localnet HOSTNAME
so gethostbyname_r for the hostname in /etc/hostname will always return 127.0.0.1 . gethostid(3) will therefore always return the same value, and NetATalk's system id will always be the same on different Ubuntu hosts.
WORKAROUND:
To each line in your afpd.conf, append an
explicit:
-signature user:SERVERNAME
(if you have more than one line in afpd.conf, make sure the signature is
unique for each one).
|
|
