Subject: .AppleDouble tests on OpenBSD (long...)

From: Karen A Swanberg <[email-masked]>
Date: Mon, 23 Apr 2001 17:20:33 -0500 (CDT)

Ok, I'm doing my best to run a thorough set of tests to figure out when
the .AppleDouble permissions tank on OpenBSD.

First of all, I only ever get the errors on the server. From the client
side, the usage is seamless, Joe MacUser would never know there was a
problem.

The client is a PowerMac G3, running OS 8.0. I also have access to the
same computer model with 8.1 and 8.6, if that will help, and I also have
blue G4's running 9.0.4. I choose this one because it was physically
closest, and I could see the console on the BSD machine. However, the
9.0.4 machines have SSH, so I can log in and watch /var/log/messages from
there as well if necessary.

For testing purposes, I created two new test directories:

/home2/sticky_no 	chmod 0777; chown geology;chgrp guest
/home2/sticky_yes 	chmod 1777; chown geology;chgrp guest

in order to see if the sticky bit had anything to do with this. These are
brand new directories, so no legacy .AppleDouble or .Parent files.

I added them to /usr/local/etc/AppleVolumes.default, and sighuped inetd.

They're being accessed under the general test account, which in this case
is geology/guest (I don't allow the actual guest account).

With sticky_no, I log in from the client, create a new directory
(sticky-no-2), and copy in a file from the client desktop. No errors. I
then dismounted the directory, remounted it, and launched the file (it's a
gif opening in Photoshop). No errors. I then threw the file away, and got
these errors:

Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown 16777216/-1
.AppleDouble/.Parent: Operation not permitted 
Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown 16777216/-1
.AppleDouble: Operation not permitted 
Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown 16777216/-1
.: Operation not permitted 
Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown -1/0
.AppleDouble/.Parent: Operation not permitted 
Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown -1/0 
.AppleDouble/.Parent: Operation not permitted

I have not yet emptied the trash.

epidote# pwd
/home2/sticky_no
ls -als
1 drwxrwxrwx  6 geology  guest  512 Apr 23 16:30 .
1 drwxr-xr-x  8 root     wheel  512 Apr 23 16:23 ..
1 drwxrwxrwx  3 geology  guest  512 Apr 23 16:29 .AppleDesktop
1 drwxrwxrwx  2 geology  guest  512 Apr 23 16:29 .AppleDouble
1 drwx--Srwx  4 geology  guest  512 Apr 23 16:30 Network Trash Folder
1 drwxrwsrwx  3 geology  guest  512 Apr 23 16:30 sticky-no-2

(note, I did not set the perms on Network Trash Folder, netatalk did, and
I don't know why the stickybit is on sticky-no-2. It shouldn't be there.
Hm...Didn't notice this until way late, right before I sent this message.)

I'll do the same process with /home2/sticky_yes now.

Exact same sequence, same errors, with sticky_yes

epidote# pwd
/home2/sticky_ye

1 drwxrwxrwt 5 geology guest 512 Apr 23 16:56 . 
1 drwxr-xr-x 8 root    wheel 512 Apr 23 16:23 .. 
1 drwxrwxrwx 2 geology guest 512 Apr 23 16:56 .AppleDouble 
1 drwx--Srwx 3 geology guest 512 Apr 23 16:56 Network Trash Folder 
1 drwxrwsrwx 3 geology guest 512 Apr 23 16:52 sticky-yes-2

-------

I'll see if I can get errors without involking the Trashcan.

I'm totally cleaning out /home2/sticky_yes and /home2/sticky_no.

I mounted /home2/sticky_no, and created a new subdirectory, sticky-no-2.
No errors. I opened up simpletext and created a simple text file. As soon
as I tried to save it to sticky-no-2 (even before I hit 'save' but after
going into the mounted subdirectroy in the save dialog) I got these
errors:

Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown 16777216/-1
.AppleDouble/.Parent: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown 16777216/-1
.AppleDouble: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown
16777216/-1 .: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown -1/0
.AppleDouble/.Parent: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown
16777216/-1 .AppleDouble/.Parent: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown 16777216/-1 
.AppleDouble: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown 16777216/-1 
.: Operation not permitted 
Apr 23 16:48:01 epidote afpd[13868]: setdirowner: chown -1/0
.AppleDouble/.Parent: Operation not permitted

The exact same thing happens with Stick_yes.

----

So I left the test file, and unmounted sticky_yes. I remounted it, and got
one instance of:

Apr 23 16:54:11 epidote afpd[22793]: setdirowner: chown -1/0
.AppleDouble/.Parent: Operation not permitted

And to make absolutely sure, the errors are occurring exactly when I
choose the netatalk-volume in the save-as dialog. I checked again.

---

Well, I don't know how useful that is, and as my roof is leaking at home,
I'm off to battle the buckets. However, I am more than willing to test
this ad nauseum for whomever wants to direct my tests, as I'm just
shooting in the dark here, albeit carefully and methodically. If someone
would like me to run specific tests, with specific Mac OS's or
whathaveyou, I will.

Cheers!

-Karen

*                                                     *
Karen Swanberg              |                         
Network Admin.              | Error: Sector not found-- 
Dept. of Geology/Geophysics |search behind couch? (Y/N)
206 Pillsbury Hall          |                         
310 Pillsbury Ave. SE       |                         
University of Mn            |  Enter any 11-digit prime
Minneapolis, MN 55455       |     number to continue...
(612) 624-6541              |                         
*                                                     *

---

From: Matthew Keller <[email-masked]>
Date: 23 Apr 2001 18:45:16 -0400

Good stuff here- Good luck with the buckets!

-- 

Matthew Keller
Enterprise System Analyst
Computing & Technology Services
Information Services Division
State University of NY at Potsdam
Potsdam, NY USA

http://mattwork.potsdam.edu/

---

From: charlie wood <[email-masked]>
Date: Fri, 07 Sep 2001 14:18:39 -0700

Yo atalk brethren and sistren.

I've got a problem that I'm sure someone has discovered (he said,
hopefully):

I've got two separate servers, each have unique network.node addresses. For
illustrative purposes, we'll call one Bob and the other Sally (names changed
to protect the innocent). Whenever one of Bob's volumes are mounted on the
client desktop, and then an attempt is made by that client to connect to
Sally, via the Chooser, instead of Sally's login dialog, the "already
connected to "Bob"" dialog comes up. Selecting "OK" takes the user to Bob's
volumes list. The only way to actually connect to Sally, under these
circumstances, is to either unmount all of Bob's volumes, or make the
connection to Sally via afp (clicking the IP Address button in the Chooser
window, typing in the IP address, etc.).

Anybody else run across this? Fixed? Solutions? Ideas? It looks like
something with atalkd, and not afpd.

I'm:
RH Linux 7.1 running on Intel-based hardware
1.5pre6 (although the problem has been around since 1.4b2)

Clients:
G3 & G4 desktops, all running OS9.1

thanks in advance.

</charlie>

_____________________________
Charlie Wood

IT Manager
ID, Incorporated
1620 SW Taylor St Suite 100 Portland, OR 97205
{v} 503-223-7737   {f} 503-223-2719
{e} [email-masked]   {w} http://www.id-inc.com

--

---

From: James Litwin <[email-masked]>
Date: Mon, 10 Sep 2001 09:44:58 -0600

Ya , I have seen it before ..... not to sure what caused the problem ... only
way that I could solve the problem was to rebuild the server from scratch ....
then everything worked ........

Sorry could not be or more help..

---

From: Thomas Schierle <[email-masked]>
Date: Mon, 10 Sep 2001 21:04:26 +0200

The problem has been discussed more than a year ago, I believe.
Unfortunately I didn't find the thread in my mail archives.

If memory doesn't fail, the solution was to change the order of appearance
of the localhost entry and the servers real IP within the hosts file.
Real IP has to be the first entry.

Background (from memory): a netatalk server creates some kind of
unique ID at (its first?) startup, and that ID is based on its IP.
If that ID is based on the localhost IP, it of cause isn't unique.

-Thomas

On 2001-09-10 17:44 +0200, James Litwin wrote:

>> [ ... ]
-- 
Thomas Schierle, Munich, Germany

PGP key [DSS/DH] 0xA23CDA1D available at various public key servers

---

From: charlie wood <[email-masked]>
Date: Mon, 10 Sep 2001 12:30:55 -0700

Excellent. Thank you for this. Yes, this turned out to be the problem. For
anyone else interested in the solution, here's what I did:

First, I checked the hexadecimal host ID on both servers with the command:

hostid

...they were identical, which indicated that I was on to the problem.

I then corrected the default /etc/hosts file for each server to read:

192.168.x.x       hostname.domain.org   hostnameAlias
127.0.0.1           localhost

...correcting the localhost entry to read as above, and moving it down one
level, putting the correct IP address/hostname entry in the first level. I
then rebooted (because rebooting is fun and profitable for the whole family!
;-)  ). 

Worked like a charm.

Apparently, atalkd uses the Unix system's hostid output instead of the real
IP address (obtainable from the /etc/hosts file) to identify the server. In
my particular case, because both hosts were essentially "localhost", with
the loopback address creating identical hexadecimal "hostnames", atalkd
assumed that when I was connected to one server, I was connected to both.

thanks again!

</charlie>

IT Manager
ID, Incorporated

--

> From: Thomas Schierle <[email-masked]>
> Date: Mon, 10 Sep 2001 21:04:26 +0200
> To: Netatalk-Admins <[email-masked]>
> Subject: Re: problem mounting two servers
> Resent-From: [email-masked]
> Resent-Date: Mon, 10 Sep 2001 15:10:16 -0400 (EDT)
>

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 10 Sep 2001 22:02:24 +0200

On Mon, 10 Sep 2001 15:31:00 -0400 (EDT), charlie wood wrote:

> IP address (obtainable from the /etc/hosts file) to identify the server.

Hmm ... I think it has _nothing_ to do with atalkd. atalkd provides basic
AppleTalk services (and does not depend on tcp/ip). Your communication
involved the AppleShare Client on mac and afpd on your netatalk server.
                                          ^^^^
You will have your problems even if AppleTalk isn't in use at all
(deactivate atalkd, try to establish the connections via AFP over TCP and
try it again)

The next thing: The hostid is normally read from /etc/hostid.

| If no such file exists, it resolves the host IP address and uses it, but
| not as the typical dotted-quad. Instead, it uses hex in network order.
| 
| IP address 204.178.40.224
| 
| 0xb2cce028
| | | | |_______ 40
| | | |_________ 224
| | |___________ 204
| |_____________ 178
| 
| (explanation courtesy Dick Johnson -- quoted from
| <http://www.cs.helsinki.fi/linux/linux-kernel/2001-11/0510.html>)

I wonder why reassigning entries in the hosts file will have the effect of
different ip addresses for the first network interface in the linux box?

Regards,

Thomas

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 10 Sep 2001 23:25:44 +0200

> ...they were identical, which indicated that I was on to the problem.

I did some quick research:

With AFP 2.2 the FPGetSrvrInfo command has been changed. Now it supports a
server¹s unique identifier: 16 byte ServerSignature ("a 16-byte number that
uniquely identifies the server" -- page 50, AFP Specs Version 2.1/2.2 -->
http://developer.apple.com/techpubs/macos8/pdf/ASAppleTalkFiling2.1_2.2.pdf)

ASun has implemented this in netatalk-1.4b2+asun-2.0a7 (take a look at
<http://www.umich.edu/~rsug/netatalk/archive/admins/1997/0070.html>)

It would be interesting whether afpd creates this Server Signature from
hostid's output, the first entry in the hosts file or from somewhere else?

If I compare the sources of 1.4b2+asun-2.1.3 and 1.5pre7 it seems the
relevant lines in etc/afpd/status.c haven't changed:

|   /* 16-byte signature consists of copies of the hostid */
| #if defined(BSD4_4) && defined(USE_GETHOSTID)
|   mib[0] = CTL_KERN;
|   mib[1] = KERN_HOSTID;
|   len = sizeof(hostid);
|   sysctl(mib, 2, &hostid, &len, NULL, 0);
| #else /* BSD4_4 && USE_GETHOSTID */
|   hostid = gethostid();
| #endif /* BSD4_4 && USE_GETHOSTID */
|   if (!hostid) {
|     if (dsi)
|       hostid = dsi->server.sin_addr.s_addr;
|     else {
|       struct hostent *host;
|       
|       if ((host = gethostbyname(hostname)))
|         hostid = ((struct in_addr *) host->h_addr)->s_addr;
|     }
|   }
| 
|   /* it turns out that a server signature screws up separate
|    * servers running on the same machine. to work around that,
|    * i add in an increment */
|   hostid += id;
|   id++;
|   for (i = 0; i < 16; i += sizeof(hostid)) {
|     memcpy(data, &hostid, sizeof(hostid));
|     data += sizeof(hostid);
|   }

I'm not a programmer, so I'm not sure, when hostid will be used and when
'gethostbyname'. Any help appreceated.

Regards,

Thomas

---

From: charlie wood <[email-masked]>
Date: Mon, 10 Sep 2001 14:44:22 -0700

> (deactivate atalkd, try to establish the connections via AFP over TCP and

Really? Sitting here, working with these servers, and supporting an office
of roughly 45 clients, I'm pretty sure of my problem, which was the ability
for my clients to connect to uniquely identified atalkd servers. I had no
trouble with clients mounting the servers uniquely with afpd. The issue has
nothing to do with afpd, nor the AFP protocol or the manner in which AFP
resolves its hostid or name (which is different than the way that atalk does
its resolutions. I'm pretty certain I was clear about my problem in my
original post.

I did some extensive research over the weekend regarding the Unix command
/bin/hostid, and also how atalk and AppleTalk register names. Coupled with
my prior knowledge of how Unix and Mac systems identify themselves, I'm
pretty certain that I won't be having these problems in the future.

Thanks for your comments.

cheers,

</charlie>

---

From: Thomas Kaiser <[email-masked]>
Date: Tue, 11 Sep 2001 01:32:28 +0200

am 10.09.2001 23:44 Uhr schrieb charlie wood:

> The issue has nothing to do with afpd, nor the AFP protocol or the manner in
> which AFP resolves its hostid or name

I think, you got me wrong ;-)

I just wanted to make clear, that your problem has nothing do to with atalkd
itself.

I think the problem is the following:

Due to the fact that both of your servers had obviously the same
ServerSignature, your mac's AppleShare clients thought that there was an
connection attempt to an already mounted server (setting up an FPGetSrvrInfo
request to the chosen afp server will result in an identical ServerSignature
--> the AppleShare client 'recognizes' that this server is already mounted
by the mac)

> IP address (obtainable from the /etc/hosts file) to identify the server.

AFAIK atalkd uses none of them. atalkd publishes the server via nbprgstr
with a defined string (_maybe_ derived from the machine's hostname: "nbprgst
-p 4 `hostname`:Workstation". And afpd will use the string that is supplied
in afpd.conf or with the '-n' switch to publish itself as type "AFPServer"
with nbp.

atalkd != hostid or etc/hosts

> In my particular case, because both hosts were essentially "localhost", with
> the loopback address creating identical hexadecimal "hostnames",

Well, that is the funny thing, I don't understand at all.

I tried 'hostid' on different hosts (even on a redhat box with only one line
in /etc/hosts --> "127.0.0.1    localhost"). I got always a hostid
corresponding to the eth0's ip address, regardless which entries were
present in /etc/hosts.

So I wondered how this ServerSignature is being created -- I don't
understand the sources :(

> atalkd assumed that when I was connected to one server, I was connected to
> both.

IMO this has nothing to do with atalkd at all.

When you choose the second server in the chooser, an afp call will be send
out (maybe over ddp, maybe over tcp -- in the latter case you won't even
need atalkd running). This FPGetSrvrInfo request will then be answered by
the server. If the afp server supports afp 2.2 or never it will supply its
ServerSignature. Now the AppleShare client decides that this server is
already mounted (avoiding the logon dialog). It's the client's choice not
the servers (especially not atalkd's ;-)

Hope this was more precise than my first attempt :-)

Best regards,

Thomas