You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(196) |
Apr
(142) |
May
(143) |
Jun
(86) |
Jul
(177) |
Aug
(232) |
Sep
(196) |
Oct
(221) |
Nov
(211) |
Dec
(139) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(135) |
Feb
(124) |
Mar
(114) |
Apr
(127) |
May
(173) |
Jun
(184) |
Jul
(70) |
Aug
(140) |
Sep
(188) |
Oct
(146) |
Nov
(127) |
Dec
(178) |
2004 |
Jan
(83) |
Feb
(167) |
Mar
(172) |
Apr
(260) |
May
(210) |
Jun
(156) |
Jul
(64) |
Aug
(65) |
Sep
(116) |
Oct
(177) |
Nov
(156) |
Dec
(88) |
2005 |
Jan
(130) |
Feb
(82) |
Mar
(47) |
Apr
(51) |
May
(99) |
Jun
(80) |
Jul
(59) |
Aug
(57) |
Sep
(86) |
Oct
(40) |
Nov
(24) |
Dec
(14) |
2006 |
Jan
(52) |
Feb
(30) |
Mar
(32) |
Apr
(74) |
May
(35) |
Jun
(55) |
Jul
(79) |
Aug
(35) |
Sep
(32) |
Oct
(18) |
Nov
(27) |
Dec
(30) |
2007 |
Jan
(17) |
Feb
(33) |
Mar
(36) |
Apr
(46) |
May
(6) |
Jun
(15) |
Jul
(16) |
Aug
(10) |
Sep
(22) |
Oct
(21) |
Nov
(43) |
Dec
(25) |
2008 |
Jan
(9) |
Feb
(16) |
Mar
(32) |
Apr
(2) |
May
(3) |
Jun
(27) |
Jul
(23) |
Aug
(19) |
Sep
(5) |
Oct
(18) |
Nov
(15) |
Dec
(8) |
2009 |
Jan
(14) |
Feb
(14) |
Mar
(36) |
Apr
(4) |
May
(23) |
Jun
(5) |
Jul
(7) |
Aug
(44) |
Sep
(50) |
Oct
(16) |
Nov
(20) |
Dec
(67) |
2010 |
Jan
(10) |
Feb
(10) |
Mar
(30) |
Apr
(49) |
May
(104) |
Jun
(74) |
Jul
(32) |
Aug
(12) |
Sep
(16) |
Oct
(41) |
Nov
(26) |
Dec
(61) |
2011 |
Jan
(65) |
Feb
(16) |
Mar
(48) |
Apr
(22) |
May
(39) |
Jun
(15) |
Jul
(102) |
Aug
(43) |
Sep
(70) |
Oct
(87) |
Nov
(47) |
Dec
(25) |
2012 |
Jan
(39) |
Feb
(41) |
Mar
(53) |
Apr
(30) |
May
(22) |
Jun
(37) |
Jul
(42) |
Aug
(62) |
Sep
(26) |
Oct
(56) |
Nov
(33) |
Dec
(40) |
2013 |
Jan
(40) |
Feb
(40) |
Mar
(47) |
Apr
(77) |
May
(70) |
Jun
(50) |
Jul
(22) |
Aug
(22) |
Sep
(19) |
Oct
(24) |
Nov
(46) |
Dec
(27) |
2014 |
Jan
(10) |
Feb
(46) |
Mar
(36) |
Apr
(14) |
May
(27) |
Jun
(67) |
Jul
(59) |
Aug
(85) |
Sep
(13) |
Oct
(50) |
Nov
(9) |
Dec
(8) |
2015 |
Jan
(22) |
Feb
(20) |
Mar
(15) |
Apr
(3) |
May
(1) |
Jun
(17) |
Jul
(21) |
Aug
(1) |
Sep
(4) |
Oct
(13) |
Nov
(22) |
Dec
(25) |
2016 |
Jan
(18) |
Feb
(24) |
Mar
(16) |
Apr
(11) |
May
(21) |
Jun
(8) |
Jul
(12) |
Aug
(7) |
Sep
(36) |
Oct
(14) |
Nov
(20) |
Dec
(8) |
2017 |
Jan
(27) |
Feb
(14) |
Mar
(12) |
Apr
(3) |
May
(3) |
Jun
(13) |
Jul
(6) |
Aug
(1) |
Sep
(1) |
Oct
(25) |
Nov
|
Dec
(18) |
2018 |
Jan
(7) |
Feb
(9) |
Mar
(11) |
Apr
(11) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
(2) |
Feb
(11) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(11) |
Jun
(2) |
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2023 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(32) |
May
(7) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(11) |
Oct
(12) |
Nov
(10) |
Dec
(5) |
2024 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
From: Jason Q. <ja...@ma...> - 2002-03-18 12:00:46
|
Perhaps you can explain why it wouldn't, which would mean you'd have to read the AFP3 specifications. Why don't you contribute a little instead of whining. Ken Gillett wrote: > At 1:31 pm +0100 16/3/02, Jason Quigley wrote: > >> Ken Gillett wrote: >> >>> At 8:49 pm +0000 15/3/02, Matthew Keller wrote: >>> >>>> Simply ignoring filename length on an AFP<3 server is a shitty thing. >>> >>> >>> So you say. I don't agree. Actually that's not what I'm proposing, >>> but I assume you were simplifying it in order to make the point. >>> >> >> Again, I'll use the words "support nightmare." Just how many >> clients/boxes do you have to support? > > > > Well maybe you'd like to explain to me (us) exactly how you think AFP3 > will avoid these nightmares that you seem to suffer. |
From: Ken G. <keng@BTInternet.com> - 2002-03-18 10:40:44
|
At 1:31 pm +0100 16/3/02, Jason Quigley wrote: >Ken Gillett wrote: >> At 8:49 pm +0000 15/3/02, Matthew Keller wrote: >> >>> Simply ignoring filename length on an AFP<3 server is a shitty thing. >> >> So you say. I don't agree. Actually that's not what I'm proposing, >>but I assume you were simplifying it in order to make the point. >> > >Again, I'll use the words "support nightmare." Just how many >clients/boxes do you have to support? Well maybe you'd like to explain to me (us) exactly how you think AFP3 will avoid these nightmares that you seem to suffer. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/ |
From: Mic C. <mca...@ma...> - 2002-03-17 22:36:16
|
From: Thomas K. <Tho...@ph...> - 2002-03-17 12:05:24
|
On Fri, 15 Mar 2002 17:09:37 -0800 (PST), Bob Cent wrote: [connection attempts via AFPoverTCP] > Message: No response from the server. Please try again. First, I would check, whether AFPoverTCP is enabled at all on your server. You might want to use this tool <http://www.macula.se/serverinfo/index.htm> from one of your client macs to examine: - whether AFPoverTCP is enabled (check afpd.conf for -transall or -tcp) - on which ip address(es) *and* port afpd is listening (think about adding an '-ipaddr [an ip address that makes sense]' switch to afpd.conf) If Netatalk is advertising an AFPoverTCP connection method, than finally check whether you are able to connect to that ip address/port (by selecting the 'server ip address' button in chooser) and watch your syslog on the server simultaneously. If you have more than one server defined in your afpd.conf than it can also be a problem with the UAMs you allow. ('man afpd.conf' and a closer look into $NETATALK_SRCDIR/doc/CONFIGURE will be a good idea :-) Regards, Thomas |
From: Ron C. <ro...@pa...> - 2002-03-17 00:12:07
|
I'm about to put a netatalk server into production, but I'm looking for feedback on which is the better scheme to use (last, mtab, cnid)? This server will have 10-15 Mac clients, and if it matters, about 8 or so Win clients (via samba). The type of files are your typical macintosh stuff, photoshop, quark, .jpeg etc. It will be used rather heavily. I guess my priority is stability here, and I'm looking for feedback from fellow admins. Also I'm compiling from the 1.5.2 release tarball, is this the best version to use? Or would it be better to use the latest update from sourceforge? Thanks, -Ron |
From: Peter F. <p_...@ma...> - 2002-03-16 21:14:40
|
> This is a client problem caused when users select "mount volume at > startup" when logging in to the server. If the volume gets retired, the > Mac spends several minutes trying to find it, causing the hang. > cM Here are a few other (less likely) possibilities of why the client may be trying to access the old server volume, which would lead to the same symptom: (1) check the Startup items folder in the System Folder, for any aliases to items on the old server. (2) if you use font management software, make sure it is not attempting to load fonts off a server. (ANY server- doing this is a bad idea in any case.) (3) There could be an applescript or other program that's attempting to load the server. - pete - -------- |
From: Sak W. <sw...@ne...> - 2002-03-16 21:02:45
|
In reply to Ken Gillett's message of the 16/03/2002 at 09:41 +0000, >I'd just like to point out that various responses have indicated >they are not fully understanding what I'm suggesting, which is:- > >Switch ON 'allow long filenames' for OSX clients. This would NOT >affect OS9 (AFP2) clients and the result would be exactly analogous >to the current situation between OS9 and Samba clients. Netatalk can't just "turn on allow long filenames": in the response to an FPGetSrvrInfo request from a client, the server has to say what AFP spec it supports. There just isn't a way, as far as I know, for netatalk to say to the client "I'm an AFP 2 server, but I can also do long filenames". So, should it say that it's an "AFP 3" server? If so, the client is then entitled to say "aha, an AFP 3 server: then it can do long filenames and also this and also that" and it may start sending cmds that netatalk may not be able to handle. On the other hand, if it says it's an AFP 2 server, the client (even in OS X) is equally entitled to say "aha, this server will never send long filenames, so I'm going to allocate buffer space based on 31-char filenames". If the server sends long filenames regardless, it may cause buffer over-runs in the clients. Now I haven't examined the behaviour of AFP3 clients in the wild, so I don't know if this will be a problem in practice, nor does the dev team from the sound of it. What they are saying is that it's better that netatalk behaves like the AFP 2 server it says it is than to add extensions that have not been fully thought through. -- Sak Wathanasin Network Analysis Limited http://www.network-analysis.ltd.uk Phone: (+44) 24 76 41 99 96 Mobile: (+44) 79 70 75 19 12 Fax: (+44) 24 76 69 06 90 |
From: Christopher M. <chr...@to...> - 2002-03-16 21:00:00
|
It's entirely a Mac problem. Your suspicion that the Mac is trying to access the old server is correct. On the client Mac, open the system folder and empty the "Servers" folder. There's probably an alias in there referencing the old Apple server. In OS 8.x and below, which has no "Servers" folder, delete "Apple Share Prep." This is a client problem caused when users select "mount volume at startup" when logging in to the server. If the volume gets retired, the Mac spends several minutes trying to find it, causing the hang. cM On Friday, March 15, 2002, at 07:38 PM, netatalk-admins- re...@li... wrote: > --__--__-- > > Message: 13 > Date: Fri, 15 Mar 2002 17:40:57 +0100 (CET) > From: "Andreas K. Huettel" <And...@ph...> > Reply-To: "Andreas K. Huettel" <an...@ak...> > To: <net...@um...> > Subject: [Netatalk-admins] PowerPC hangs after boot for ca 3min > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Dear netatalk experts, > > since switching our network from a very old Apple server to a linux box > running netatalk (1.5pre7 as supplied by SuSE73), exactly one of our > Macs > hangs after booting. > > It asks for the password on the fileserver, the dialog box closes - > then no reaction on mouse clicks anymore. If you wait 3min, suddenly > every > mouseclick done in the meantime is executed, afterwards everything seems > normal. System is MacOS D1-9.0.4. > > Is there any way this could be related to netatalk? Other idea, might > the > computer still try to access the old server? How could I find this out? > > (Sorry, I don't have much experience with Macs, this is my first post > here...) > > kind regards, Andreas > > - --------------------------------------------------------------------- > Dipl.-Phys. Andreas K. Huettel tel. +49 89 2180 3349 (univ.) > Sektion Physik der LMU fax +49 89 2180 2069 (univ.) > LS Prof. J.P. Kotthaus hu...@lm... > Geschwister-Scholl-Platz 1 an...@ak... > 80539 Muenchen and...@ph... > Germany http://www.akhuettel.de/research/ > - --------------------------------------------------------------------- > Please use GNUPG or PGP for signed and encrypted email. My public key > can be found at http://www.akhuettel.de/pgp_key.html > - --------------------------------------------------------------------- > No trees were killed in the sending of this message. However a large > number of electrons were terribly inconvenienced. |
From: Tony <to...@sh...> - 2002-03-16 17:32:11
|
I am crossposting this, in hopes of more explicit experience with pam-winbind and netatalk, or netatalk use of secondary groups. The goal is to have a fileserver for both Win$ and Maco$ clients, with pass thru auth, so no accounts have to be maintained on the Linux system. Currently in production, we are using NIS to assemble/clearinghouse the auth. The Major Gotcha: Group permissions for secondary groups are not being tapped for Mac Clients. That is, group shares which have @primary_group for the user, show, and work. Shares which are shared to @secondary_group, to which the user is a member, in NIS (ypcat -k group | grep username shows all memberships) are not referenced by netatalk. So.... on a test system: Netatalk v1.5.0, compiled, pam from the rpm, on RH 7.2 Samba v2.2.2, also compiled, with pam and winbindd. Successfully (OK, why am I writing...) using the winbindd ( http://www.mandrakeuser.org/docs/connect/csamba5.html#winbind ) pam module to pass auth thru to an NT4 Domain. I have been very impressed with the work they have done, it worked even to the extent of creating the user's homedirectory on the fly. Now trying to get group shares up, using groups from the Domain. The logfile, when accessing a share auth'd to a group on the Domain, records: Mar 15 14:51:34 home2 afpd[23463]: uams_dhx_pam.c :PAM: User entered a null value -- Success but lies about the Success part ;) it always reports password or user account problems. The usernames which work in the homedir mount above are 'DOMAIN\logname' form. What /etc/pam.d/netatalk collections are you folks using with success? Mine: #%PAM-1.0 auth required /lib/security/pam_warn.so auth sufficient pam_winbind.so auth required /lib/security/pam_pwdb.so use_first_pass nullok account required pam_winbind.so password required pam_winbind.so session required pam_unix.so session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 # makes the homedir!!! easily impressed. TT Thanks, Tony |
From: Jason Q. <ja...@ma...> - 2002-03-16 12:31:31
|
Ken Gillett wrote: > At 8:49 pm +0000 15/3/02, Matthew Keller wrote: > > >> Simply ignoring filename length on an AFP<3 server is a shitty thing. > > > > So you say. I don't agree. Actually that's not what I'm proposing, but I > assume you were simplifying it in order to make the point. > Again, I'll use the words "support nightmare." Just how many clients/boxes do you have to support? > >> Netatalk is not lacking. Netatalk is an AFP2 server just like >> your OS9 or >> ASIP boxes. Netatalk is NOT an AFP3 server like OSX. > > > > In the current climate AFP2 IS lacking as it alone is incapable of > dealing with long filenames. > As Matthew has stated, Netatalk is an *AFP2* server. Just live with it. If you can't live with it, get yourself a Win2K Server box and use their hack, or, get OSXS. <snip> > > If someone could hack this as a patch I'd be happy to give it a try:-) Well, go out and buy a book on C programming, study the code a bit and put the patch together yourself. That's the point of open source. I have made PureFTPd play with Netatalk by going just this. Cheers, Jason. |
From: Kyle J. <kyl...@du...> - 2002-03-16 11:49:32
|
On 3/15/02 8:09 PM, "Bob Cent" <cent@u.washington.edu> had the following insightful comment: > All is well with a new installation of RH7.2 and > netatalk-1.5pre6-1rh7.i386, except that my users cannot login by > selecting the Server IP Address button in the Chooser. > > Message: No response from the server. Please try again. > > They can login with AppleTalk, however. I've got the IP address > right because I can FTP to the server. Does this make sense to > anyone? Doesn't 7.2 enable ipchains by default? If you don't have port 548 open, AFP over IP won't work. /kyle --- Kyle Johnson kyl...@du... Manager, Information Systems http://www.studentaffairs.duke.edu Duke University Student Affairs ----------------------------------------------------------------------- The Marketing Professional's Motto: We're not screwing the customers. All we're doing is holding them down while the sales people screw them. -from "The Dilbert Principle" by Scott Adams |
From: Ken G. <keng@BTInternet.com> - 2002-03-16 09:50:13
|
At 8:49 pm +0000 15/3/02, Matthew Keller wrote: >> I was lead to to believe from other postings on this list that >> allowing long filenames was a very easy change, just stop it >> filtering on names > 31 chars. (yes I know its bytes, but that's >> meaningless to most users) > > "Allowing" it, yes, "allowing it properly, no". "Allowing" long >file names is >as simple as stopping NOT allowing long filenames. Getting the Mac >Client to do >the Right Thing is another matter. What I am suggesting does NOT break anything for any client AFAIK. If I'm wrong about this then please correct me. OS9 clients would get to see exactly what they see now, nothing if the name is longer than 31. OSX clients would get the full name. User problems it is suggested this would generate is a spurious argument since this is EXACTLY the situation with ANY other network user accessing the same volume outside Netatalk and AFP3s (or any) name truncation scheme does not eliminate the problems anyway. One set of users sees something different from another set, so let's not waste time with the 'user problem' argument. >> If I had those sort of financial resources I would undoubtedly do so. >> The fact I am trying to encourage support on this list for a working >> solution is a direct result of the fact that I do not. > > For the cost of one or two of your overpriced MAc's, you could >probably find >a programmer willing to focus on that task. I'm not sure what you are insinuating by that, but I'll let it pass. >Simply ignoring filename length on an AFP<3 server is a shitty thing. So you say. I don't agree. Actually that's not what I'm proposing, but I assume you were simplifying it in order to make the point. > Netatalk is not lacking. Netatalk is an AFP2 server just like your OS9 or >ASIP boxes. Netatalk is NOT an AFP3 server like OSX. In the current climate AFP2 IS lacking as it alone is incapable of dealing with long filenames. >Apple gives out a nice >thick PDF on what AFP3 is, but they don't drop us any bones on how >to implement >it. Actually, to be honest, they don't even give out ALL of AFP3, >just the more >fundamental stuff. There's a lot of OSX chatter I've seen that is >not documented >in their AFP3 spec anywhere. I'm quite sure Apple have been less than helpful in this regard. I just thought (still think) there's a way to circumvent the difficulties they've put in your way. BTW, what IS on the TODO list above AFP3? I'd just like to point out that various responses have indicated they are not fully understanding what I'm suggesting, which is:- Switch ON 'allow long filenames' for OSX clients. This would NOT affect OS9 (AFP2) clients and the result would be exactly analogous to the current situation between OS9 and Samba clients. Offer a compile time switch so this feature can be enabled/disabled for any build. Even better include a runtime configuration parameter that can control it, but I'd guess that's a bit more involved. So, if you don't want it, don't have it, simple. But for those who need it, it's available. If someone could hack this as a patch I'd be happy to give it a try:-) -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/ |
From: Ken G. <keng@BTInternet.com> - 2002-03-16 08:20:22
|
I've been doing some testing with this and it would appear to be a bug in Netatalk. AFAICT, you CANNOT set (and have it stay static) the creation date if the modification date is earlier than 1/1/1970 12.00.00 am. IOW, if the year of the mod date is less than 1970, then trying to set the create date will result in some weird date that changes every time you even click on the disclosure triangle of that folder. I have been doing the testing with File Buddy, but the results support the symptoms I see from setting the dates with an Applescript. BTW, I can easily recover a folder with wacky create date by setting the mod date > 1969 and then the create date to what I want. That immediately sorts it out, so it's not some unrecoverable corruption in the .Parent file, or anything to do with .Parent IMO. Is this a known problem/bug? Has anyone else noticed this? Does it occur with anyone else's Netatalk shares? Thanks. At 7:29 pm +0100 15/3/02, Thomas Kaiser wrote: >> Since there's no entry in .AppleDouble for folders, > >Isn't there a file .Parent inside? > >> were does it store this data as unix/linux doesn't store this info about a >> file (at least the ext2 file system doesn't)? > >I believe the creation date is stored inside this file. Maybe one of the >developers can give some hints about the data structures of this file or you >take a look into CVS to do some research by yourself... -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/ |
From: Steve F. <sf...@ih...> - 2002-03-16 07:00:44
|
> All is well with a new installation of RH7.2 and > netatalk-1.5pre6-1rh7.i386, except that my users cannot login by > selecting the Server IP Address button in the Chooser. > > Message: No response from the server. Please try again. > > They can login with AppleTalk, however. I've got the IP address > right because I can FTP to the server. Does this make sense to > anyone? A few suggestions: 4. I'd upgrade that Netatalk when you get the chance. A lot of bugs have been fixed since pre6. Compiling 1.5.2 is quite easy. 3. Check to see if the afpd process is running. It ought to be. 2. Check to see (run "netstat -ta") if something is listening on port 548 (aka "afpovertcp"). 1. Check your firewall rules. If you enabled Redhat's default firewalling when you installed it, it may be blocking port 548. My guess is it's #1 that's causing your problem. Also, do you have more than one ethernet card in the machine? Doing any NAT or routing with that box? Anything funky? Once you get your TCP connections working, help the client Macs default to TCP by adding the right line to your /etc/hosts file. If your Netatalk server shows up as, say, "Dieter" in the Chooser, and has IP 9.8.7.6, then add this line to /etc/hosts: 9.8.7.6 dieter And Netatalk will now be able to tell the Macs which IP to use. Steve |
From: Steve F. <sf...@ih...> - 2002-03-16 06:47:57
|
Also Andreas, delete this file: System Folder -> Preferences -> AppleShare Prep > From: Tom Barrons <to...@by...> > Date: Fri, 15 Mar 2002 23:20:46 -0500 > To: "Andreas K. Huettel" <an...@ak...> > Cc: net...@um... > Subject: Re: [Netatalk-admins] PowerPC hangs after boot for ca 3min > > Andreas, > > This sounds familiar. Look in the System Folder for a folder called > "Servers" in here you might find an alias to the old server, remove this > alias. > > Good luck, > Tom > > On Friday, March 15, 2002, at 11:40 AM, Andreas K. Huettel wrote: > >> Dear netatalk experts, >> >> since switching our network from a very old Apple server to a linux box >> running netatalk (1.5pre7 as supplied by SuSE73), exactly one of our >> Macs >> hangs after booting. >> >> It asks for the password on the fileserver, the dialog box closes - >> then no reaction on mouse clicks anymore. If you wait 3min, suddenly >> every >> mouseclick done in the meantime is executed, afterwards everything seems >> normal. System is MacOS D1-9.0.4. >> >> Is there any way this could be related to netatalk? Other idea, might >> the >> computer still try to access the old server? How could I find this out? >> >> (Sorry, I don't have much experience with Macs, this is my first post >> here...) >> >> kind regards, Andreas > > > _______________________________________________ > Netatalk-admins mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netatalk-admins > |
From: Tom B. <to...@by...> - 2002-03-16 04:20:52
|
Andreas, This sounds familiar. Look in the System Folder for a folder called "Servers" in here you might find an alias to the old server, remove this alias. Good luck, Tom On Friday, March 15, 2002, at 11:40 AM, Andreas K. Huettel wrote: > Dear netatalk experts, > > since switching our network from a very old Apple server to a linux box > running netatalk (1.5pre7 as supplied by SuSE73), exactly one of our > Macs > hangs after booting. > > It asks for the password on the fileserver, the dialog box closes - > then no reaction on mouse clicks anymore. If you wait 3min, suddenly > every > mouseclick done in the meantime is executed, afterwards everything seems > normal. System is MacOS D1-9.0.4. > > Is there any way this could be related to netatalk? Other idea, might > the > computer still try to access the old server? How could I find this out? > > (Sorry, I don't have much experience with Macs, this is my first post > here...) > > kind regards, Andreas |
From: Wesley D C. <we...@um...> - 2002-03-16 02:40:37
|
On Fri, 15 Mar 2002, Thomas Kaiser wrote: > I believe the creation date is stored inside this file. Maybe one of the > developers can give some hints about the data structures of this file or you > take a look into CVS to do some research by yourself... The .Parent file is also an AppleDouble header file, like other files found in the .AppleDouble header. As you might imagine, the creation date is store as a 4 byte integer, not sure what time base recent version of afpd use... :wes |
From: Bob C. <cent@u.washington.edu> - 2002-03-16 01:09:41
|
Hi, All is well with a new installation of RH7.2 and netatalk-1.5pre6-1rh7.i386, except that my users cannot login by selecting the Server IP Address button in the Chooser. Message: No response from the server. Please try again. They can login with AppleTalk, however. I've got the IP address right because I can FTP to the server. Does this make sense to anyone? Thanks! _____________________________ Bob Cent University of Washington Box 357330 Seattle, WA 98195-7330 mailto: cent@u.washington.edu voice: 206.543.1433 fax: 206.685.0305 _____________________________ |
From: Matthew K. <kel...@po...> - 2002-03-15 20:49:55
|
> I was lead to to believe from other postings on this list that > allowing long filenames was a very easy change, just stop it > filtering on names > 31 chars. (yes I know its bytes, but that's > meaningless to most users) "Allowing" it, yes, "allowing it properly, no". "Allowing" long file names is as simple as stopping NOT allowing long filenames. Getting the Mac Client to do the Right Thing is another matter. > If I had those sort of financial resources I would undoubtedly do so. > The fact I am trying to encourage support on this list for a working > solution is a direct result of the fact that I do not. For the cost of one or two of your overpriced MAc's, you could probably find a programmer willing to focus on that task. > >The real mess is, that Apple didn't provided a new version of the AppleShare > >client for MacOS 9.x to support AFP 3.0 in MacOS 9 too. In many > >installations you will use MOSX and MacOS 9.x simutaneously and this name > >mangling issue will continually cause trouble. > > > You see, as a user in this instance I don't care 2 hoots for > conformance to some specification that Apple has stupidly not updated > in tune with progress. I just want it to work as I think it should. > Either long filenames is a good thing, or it's not. OSX has it (as > does Unix and Windows) so it is a good thing for the future except > for OS9, which remains the odd one out. Yet Netatalk is completely > hamstrung by OS9s shortcomings and that's a shame. Things are not as simple as "you think they should be", unfortunately. We're not trying to say that long filename support is bad- Hell it's something that nearly every Netatalk developer want's. Doing it Right is a bigger focus than just doing it, however. We're not Microsoft or Apple, we don't do shitty things. Simply ignoring filename length on an AFP<3 server is a shitty thing. > It seems to me that the pieces are all available to create an interim > solution until full AFP3 conformance can be completed. And when will > that be, within a year, 2 years, more? But everyone just seems to > want to make excuses as to why it's a bad idea. AFP compliance will probably be a couple years out. This of course depends on philanthropy, defections and emigration of coders, etc. It could be done in a week or two if someone wanted to do it. > To be honest, I had assumed that with an OSX client I WOULD be able > to see long filenames and it's a bit of a blow to discover that > Netatalk is so lacking in this respect. Netatalk is not lacking. Netatalk is an AFP2 server just like your OS9 or ASIP boxes. Netatalk is NOT an AFP3 server like OSX. Apple gives out a nice thick PDF on what AFP3 is, but they don't drop us any bones on how to implement it. Actually, to be honest, they don't even give out ALL of AFP3, just the more fundamental stuff. There's a lot of OSX chatter I've seen that is not documented in their AFP3 spec anywhere. - Matthew Keller Enterprise Systems Analyst Computing and Technology Services Information Services Division State University of New York College at Potsdam Potsdam, NY, USA http://mattwork.potsdam.edu/ |
From: Ken G. <keng@BTInternet.com> - 2002-03-15 20:20:25
|
At 7:45 pm +0100 15/3/02, Thomas Kaiser wrote: >> The above solution may not be 'true' AFP3 > >Ken, please read the AFP 3.0 specs, read about the representation of paths >in UNICODE (not MacRoman or the other available 'classic' encodings --> >Unicode is not part of AFP versions before 3.0), try to figure out, how >these paths have to be built (this is not documented by Apple according to >developers of other UNIX AFP server solutions --> UNIX path separator '/' >instead of the well-known colon amongst other details) and figure out >yourself, why this solutions has nothing do to with AFP 3.0 conformance! I wasn't trying to imply it was anything close to actual AFP3, just that it would provide the equivalent functionality pertinent to the discussion. >> but it works correctly with both client types, > >I don't believe so. If Netatalk would advertise that it is AFP 3.0 capable >then it has to implement AFP 3.0 *completely*. If it advertises, that it's >just AFP 2.2 capable, then it is a violation of AFP specs if you supply >longer filenames than 31 bytes (not characters) maybe causing buffer >underflows in MacOS 7.x/8.x/9.x and maybe other problems with MOSX (wrong >encoding for longer filenames and so on...) I was lead to to believe from other postings on this list that allowing long filenames was a very easy change, just stop it filtering on names > 31 chars. (yes I know its bytes, but that's meaningless to most users) >> so would its unorthodox methods be that bad? > >IMHO yes. If it is so important for you, then hire an expert and let him >join the development efforts for AFP 3.0 conformance. If I had those sort of financial resources I would undoubtedly do so. The fact I am trying to encourage support on this list for a working solution is a direct result of the fact that I do not. >The real mess is, that Apple didn't provided a new version of the AppleShare >client for MacOS 9.x to support AFP 3.0 in MacOS 9 too. In many >installations you will use MOSX and MacOS 9.x simutaneously and this name >mangling issue will continually cause trouble. You see, as a user in this instance I don't care 2 hoots for conformance to some specification that Apple has stupidly not updated in tune with progress. I just want it to work as I think it should. Either long filenames is a good thing, or it's not. OSX has it (as does Unix and Windows) so it is a good thing for the future except for OS9, which remains the odd one out. Yet Netatalk is completely hamstrung by OS9s shortcomings and that's a shame. It seems to me that the pieces are all available to create an interim solution until full AFP3 conformance can be completed. And when will that be, within a year, 2 years, more? But everyone just seems to want to make excuses as to why it's a bad idea. To be honest, I had assumed that with an OSX client I WOULD be able to see long filenames and it's a bit of a blow to discover that Netatalk is so lacking in this respect. Still, unless or until someone is prepared to do some coding, seems I'll just have to wait. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/ |
From: Peter A. <pe...@mp...> - 2002-03-15 19:08:17
|
on 3/15/02 1:45 PM, Thomas Kaiser at Tho...@ph... wrote: > The real mess is, that Apple didn't provided a new version of the AppleShare > client for MacOS 9.x to support AFP 3.0 in MacOS 9 too. Well said!!! This is the true root of the evil we Mac users are facing. We're presently transitioning from a Mac ASIP 6.3.3 server to OSXS. We also use netatalk. Being in the printing industry, we don't want to take someone's Quark 4.x (OS 9 native) file and open them in Quark 5 (OSX native), because we'll change their layout by doing so. But that means running lots of apps in classic mode. It makes more sense to just leave a number of Macs in OS9 for a while (as in, for a few more years!) Oh, and by he way, we do still use a number of PowerMacs too. The idea that all Mac networks will jump to OSX exclusively all at once is not realistic. I understand the difficulties in making an older OS forward compatible, but this is one instance where I'd just love Apple to spend the time to make it happen. We need an AFP 3.0 compatible OS 9 Appleshare client! -- Peter John Anton IT Manager, MicroPRINT Waltham, Mass., USA 781-890-7500 pe...@mp... |
From: Steve F. <sf...@ih...> - 2002-03-15 19:07:04
|
> Where do you recommend I get libcrypto.so.0? My boot-up log reports trouble > when starting netatalk: > > > atalkd: /usr/sbin/atalkd: error while loading shared libraries: > libcrypto.so.0: cannot open shared object file: No such file or directory libcrypto.so.0 is, on my systems at least, a symlink to libcrypto.so.0.9.5a, which is a part of the OpenSSL package. Steve |
From: Bob C. <cent@u.washington.edu> - 2002-03-15 18:54:32
|
Hi, Where do you recommend I get libcrypto.so.0? My boot-up log reports trouble when starting netatalk: atalkd: /usr/sbin/atalkd: error while loading shared libraries: libcrypto.so.0: cannot open shared object file: No such file or directory Thanks! _____________________________ Bob Cent University of Washington Box 357330 Seattle, WA 98195-7330 mailto: cent@u.washington.edu voice: 206.543.1433 fax: 206.685.0305 _____________________________ |
From: Thomas K. <Tho...@ph...> - 2002-03-15 18:46:11
|
am 15.03.2002 11:06 Uhr schrieb Ken Gillett: > The above solution may not be 'true' AFP3 Ken, please read the AFP 3.0 specs, read about the representation of paths in UNICODE (not MacRoman or the other available 'classic' encodings --> Unicode is not part of AFP versions before 3.0), try to figure out, how these paths have to be built (this is not documented by Apple according to developers of other UNIX AFP server solutions --> UNIX path separator '/' instead of the well-known colon amongst other details) and figure out yourself, why this solutions has nothing do to with AFP 3.0 conformance! > but it works correctly with both client types, I don't believe so. If Netatalk would advertise that it is AFP 3.0 capable then it has to implement AFP 3.0 *completely*. If it advertises, that it's just AFP 2.2 capable, then it is a violation of AFP specs if you supply longer filenames than 31 bytes (not characters) maybe causing buffer underflows in MacOS 7.x/8.x/9.x and maybe other problems with MOSX (wrong encoding for longer filenames and so on...) > so would its unorthodox methods be that bad? IMHO yes. If it is so important for you, then hire an expert and let him join the development efforts for AFP 3.0 conformance. The real mess is, that Apple didn't provided a new version of the AppleShare client for MacOS 9.x to support AFP 3.0 in MacOS 9 too. In many installations you will use MOSX and MacOS 9.x simutaneously and this name mangling issue will continually cause trouble. Regards, Thomas |
From: Thomas K. <Tho...@ph...> - 2002-03-15 18:29:54
|
On Thu, 14 Mar 2002 13:28:26 +0000, Ken Gillett wrote: > Since there's no entry in .AppleDouble for folders, Isn't there a file .Parent inside? > were does it store this data as unix/linux doesn't store this info about a > file (at least the ext2 file system doesn't)? I believe the creation date is stored inside this file. Maybe one of the developers can give some hints about the data structures of this file or you take a look into CVS to do some research by yourself... Regards, Thomas |