On Mon, 29 Dec 2003, srinivasp wrote: > Does netatalk support utmp logging? i.e can it record every connection / > login to the utmp file. Thank you. No, it doesn't at the moment. -- -- Alistair Riddell - BOFH IT Manager, George Watson's College, Edinburgh Tel: +44 131 446 6070 Fax: +44 131 446 6090 Microsoft - because god hates us
I experienced major file and directory corruption when accessed from Mac OS X 10.3 (Panther) using Netatalk 1.5.5-6 that came with my RedHat 9 distro. OS 9 clients as well as older version of OS X worked fine. Strangely, my YellowDog 3.0 running netatalk 1.5.3.1-4 on an old PwerBase seems to work just fine with Mac OS 10.3 clients... Since we're transitioning to Panther, I decided to roll out my own compile of the latest Netatalk version hoping it would solve the problem. I am now running netatalk 1.6.4 built as RPM for Red Hat 9 using mandrake's modified spec file and Berkeley DB version 4.0.12-20 that came with RH9 distro. I basically got rid of Mandrake's specific requirements in the spec file. RPM installed fine. I configured AppleVolumes.default to include: /home/files/ "$h-OS X sandbox" Directory /home/files/ contains a copy of netatalk-stored files from when server ran v. 1.5.5. When I mount it from my OS 9 client, I don't see any files. The share looks empty. The system log shows successful login of my client and then: [cnid_open.c:338] E:Default: cnid_open: dbenv->open of /home/files/.AppleDB failed: No such file or directory [enumerate.c:83]: E:AFPDaemon: adddir: Incorrect parameters passed to cnid_add I checked, there is a /home/files/.AppleDB. I set it's permissions to 2777 as part of my tests - didn't help. Then I made sure that both /home and /home/files are set to 777 just in case that's the problem. Didn't help either. I shut down the server, deleted the .AppleDB dir, started the server(Continue reading)
As a longtime Netatalk user, I have to ask hopefully not too stupid of a question: Why not choose the SMB protocol that Samba provides to serve shares to OS X clients instead of Netatalk? It's a much more mature product and has way more developers. Are there pitfalls that I'm not aware of? I appreciate the information and go easy on me-Dan
That's not a bad question. Take a look at the Baltra patches for Netatalk which allow the files to be shared between protocols and Macs of different versions (9 and X) without losing things like resource forks: http://www.baltra.org/ Phil > As a longtime Netatalk user, I have to ask hopefully not too stupid of a > question: > > Why not choose the SMB protocol that Samba provides to serve shares to OS > X clients instead of Netatalk? It's a much more mature product and has way > more developers. Are there pitfalls that I'm not aware of? > > I appreciate the information and go easy on me(Continue reading)
Daniel E. Lautenschleger wrote: > As a longtime Netatalk user, I have to ask hopefully not too stupid of a > question: > > Why not choose the SMB protocol that Samba provides to serve shares to OS > X clients instead of Netatalk? It's a much more mature product and has way > more developers. Are there pitfalls that I'm not aware of? Lots. I've done this. Trouble is the Mac meta data is different between NetAtalk and what MacOSX simulates on an SMB volume so all the finder info and resource forks get lost. So you can't swicth between connection methods. If they still use OS9 they will be switching and confusion results - Mac users are used to 'magic' happening when they click on a file and the type and application associations are missing they get confused and unhappy. In most versions of MacOSX shortcuts to SMB volumes doesn't work (at least not for us) so it's difficult for the users to connect to the server and if they do it manually they are just as likely to connect as afp:// instead of smb:// and meta data based confusion as above results.
On Sun, 28 Dec 2003, Sebastian Rittau wrote: > Hi! > > To fix the compilation issue on SuSE 9.0 I would like to release a new > version of Netatalk soon (around the first weekend of the next year). Sorry, I can't make it compile on various Slackware Linux boxes. error looks something like this: make[4]: Entering directory `/home/ali/netatalk-1.6.5/etc/afpd' source='nfsquota.c' object='nfsquota.o' libtool=no \ depfile='.deps/nfsquota.Po' tmpdepfile='.deps/nfsquota.TPo' \ depmode=gcc /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../sys -D_PATH_AFPDDEFVOL=\"/usr/local/etc/netatalk/AppleVolumes.default\" -D_PATH_AFPDSYSVOL=\"/usr/local/etc/netatalk/AppleVolumes.system\" -D_PATH_AFPDPWFILE=\"/usr/local/etc/netatalk/afppasswd\" -D_PATH_AFPDCONF=\"/usr/local/etc/netatalk/afpd.conf\" -D_PATH_AFPDUAMPATH=\"/usr/local/etc/netatalk/uams/\" -D_PATH_AFPDNLSPATH=\"/usr/local/etc/netatalk/nls/\" -DAFPD_MTAB_FILE=\"/usr/local/etc/netatalk/afpd.mtab\" -DAPPLCNAME -I../../include -g -O2 -I../../sys -c `test -f 'nfsquota.c' || echo './'`nfsquota.c In file included from nfsquota.c:54: unix.h:97: warning: `struct if_dqblk' declared inside parameter list unix.h:97: warning: its scope is only this definition or declaration, which is probably not what you want. nfsquota.c:108: warning: `struct if_dqblk' declared inside parameter list(Continue reading)
That's right. You need something like the Baltra version of Netatalk to keep the meta information consistent. Phil http://www.baltra.org/ Matthew Geier wrote: > Daniel E. Lautenschleger wrote: > >> As a longtime Netatalk user, I have to ask hopefully not too stupid of a >> question: >> >> Why not choose the SMB protocol that Samba provides to serve shares >> to OS >> X clients instead of Netatalk? It's a much more mature product and >> has way >> more developers. Are there pitfalls that I'm not aware of? > > > Lots. > > I've done this. Trouble is the Mac meta data is different between > NetAtalk and what MacOSX simulates on an SMB volume so all the finder > info and resource forks get lost. So you can't swicth between > connection methods. > > If they still use OS9 they will be switching and confusion results - > Mac users are used to 'magic' happening when they click on a file and > the type and application associations are missing they get confused(Continue reading)
Thanks for writing. I will have to get more info from this poster: http://www.linuxquestions.org/questions/showthread.php?s=&threadid=129292 Looks like he might have a solution for me, although shouldn't netatalk fail to compile if it was missing something? > From: "Joerg Lenneis" <lenneis <at> wu-wien.ac.at> >> I've looked at cnid_open.c. It looks like it tries to create the .AppleDB >> directory if it isn't already there and then attempts to use it to store >> database files. Obviously, creation of .AppleDB worked, because the dir is >> there. Seems to me that something goes wrong around the call to: >> rc = db->dbenv->open(db->dbenv, path, DBOPTIONS, 0666 & ~mask) and the other >> two db->dbenv->open that follow it. Somehow they fail to create the >> environment. > > I do not really understand, why that error message happens AFTER you > set all of the permissions to 777. Which user owns .AppleDB? Do you > compile --with-cdb? To you maybe specify the dbpath option in > AppleVolumes? > When .AppleDB gets created by the daemon, it is: drwxr-sr-x nobody nobody The directory in which it is created is drwsrwsrwx nobody nobody and so is it's parent. I didn't originally compile with-cdb, but I just did now and got same result.(Continue reading)
Artur Jasowicz: > Thanks for writing. > I will have to get more info from this poster: > http://www.linuxquestions.org/questions/showthread.php?s=&threadid=129292 > Looks like he might have a solution for me, although shouldn't netatalk fail > to compile if it was missing something? [...] I see. If the afpd executeable uses another version of the Berkeley DB shared libraries than it was compiled with, all bets are off. You should check that before anything else. One easy way to see what shared library is actually used is lsof. Start up afpd and use "lsof -p <pid of netatalk afpd>". That will list all open files of the afpd process, including the Berkeley DB libraries. Recent versions of the upcoming Netatalk 2.0 release include a check to prevent afpd using another version of the Berkeley DB libraries than the one used at compile time. >>> Btw. won't >>> #if DB_VERSION_MAJOR >= 4 || (DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR > 1) >>> around line 312 of cnid_open.c always eval to true if DB_VERSION_MAJOR = 4 >> >> If you look closely, there is an #if 0 right under that line: That >> code does nothing right now (and has disappeared in development >> versions). > My bad, sorry, didn't mean to step on anybody's toes. I guess I got so(Continue reading)
> From: "Joerg Lenneis" <lenneis <at> wu-wien.ac.at> > > Artur Jasowicz: > >> Thanks for writing. >> I will have to get more info from this poster: >> http://www.linuxquestions.org/questions/showthread.php?s=&threadid=129292 >> Looks like he might have a solution for me, although shouldn't netatalk fail >> to compile if it was missing something? > > [...] > > I see. If the afpd executeable uses another version of the Berkeley DB > shared libraries than it was compiled with, all bets are off. You That was user named "lukebeales" on linuxquestions that was having this problem, not me. What lukebeales is saying is that his version of Berkeley DB he originally had on his machine had to be upgraded to a newer one for the files to become visible to a Mac client. He mentions that "The berkeley db library wasn't compiled with the necessary tags". I am wondering if my RPMs were compiled with whatever functionality is needed by netatalk. I've checked the source RPM for BDB to see what options were used to build the RPM that I am using and the only difference that I can see compared to what lukebeales used for his compile is that mine does not have --enable-diagnostic and --prefix=/usr enabled. Does netatalk care about these two? > should check that before anything else. One easy way to see what > shared library is actually used is lsof. Start up afpd and use "lsof(Continue reading)
RSS Feed10 | |
|---|---|
6 | |
29 | |
20 | |
28 | |
11 | |
13 | |
22 | |
20 | |
52 | |
7 | |
26 | |
41 | |
19 | |
147 | |
45 | |
39 | |
33 | |
17 | |
9 | |
24 | |
18 | |
48 | |
4 | |
6 | |
7 | |
33 | |
4 | |
59 | |
2 | |
18 | |
9 | |
2 | |
7 | |
12 | |
76 | |
45 | |
107 | |
45 | |
92 | |
162 | |
113 | |
169 | |
67 | |
66 | |
41 | |
70 | |
98 | |
98 | |
81 | |
55 | |
51 | |
57 | |
21 | |
13 | |
3 | |
3 | |
18 | |
4 | |
12 | |
30 | |
30 | |
44 | |
7 | |
1 | |
1 | |
10 | |
9 | |
2 | |
1 | |
2 | |
1 | |
1 | |
4 | |
7 | |
29 | |
14 | |
11 | |
12 | |
4 | |
13 | |
11 | |
6 | |
4 | |
6 | |
18 | |
26 | |
12 | |
15 | |
24 | |
20 | |
7 | |
22 | |
25 | |
9 | |
73 | |
33 | |
45 | |
124 | |
52 | |
63 | |
43 | |
111 | |
53 | |
49 | |
57 | |
22 | |
56 | |
33 | |
78 | |
35 | |
42 | |
45 | |
61 | |
78 | |
88 | |
198 | |
168 | |
153 | |
155 | |
166 | |
178 | |
173 | |
184 | |
120 | |
293 | |
227 | |
340 | |
408 | |
373 | |
436 | |
595 | |
409 | |
197 | |
237 | |
119 | |
231 | |
128 | |
129 | |
200 | |
58 | |
38 | |
36 | |
40 | |
48 | |
68 | |
116 | |
3 |
