[nycbug-talk] Noob networking question

[Bjorn Nelson]

Pete,

On Jul 21, 2006, at 12:09 PM, Peter Wright wrote:

>
>> On Fri, 21 Jul 2006, Brad Schonhorst wrote:
>>
>>>>> If your macs are running 10.4 there is no reason to use  
>>>>> appletalk.  i
>>>>> would suggest you disable it.  Bonjour is apple's 'replacement'  
>>>>> for
>>>>> apple talk for zeroconf networking (finding that lost network
>>>>> printer.)  Both Bonjour and AFP are using TCP/IP at this point  
>>>>> making
>>>>> appletalk severely outdated.
>>>>>
>>>> Hi Brad,
>>>>
>>>> Are you suggesting nfs on the FreeBSD shared server and Bonjour  
>>>> on the
>>>> clients ?  Not having looked at Bonjour at all, lets just say  
>>>> the name
>>>> doesn't inspire much confidence ... :)
>>>>
>>>
>>> I just re-read your original post and it looks like you are using
>>> atalk for file sharing right?  Your right, Bonjour probably isn't  
>>> the
>>> best solution for that situation.  Have you tried just using  
>>> NFS.  So
>>> NFS on server, NFS on client?  These days, mac's can almost be  
>>> thought
>>> of as unix boxes. You wouldn't use atalk to connect 2 freebsd  
>>> machines
>>> right?
>>
>> Just to be clear, Bonjour/Rendezvous is simply for autodiscovering  
>> hosts
>> and the services on them.  Some of those services may include file  
>> sharing
>> services...
>>
>> AppleTalk file sharing is really the preferred way to be working  
>> here.
>> Keep in mind that this does not mean using AFP over AppleTalk.   
>> AFP also
>> runs over TCP, and that's what current OS-X uses by default.
>>
>> AppleTalk File Sharing != AppleTalk network protocol.
>
>
> yea i tend to agree here, especially for smaller shops that have  
> been Mac
> houses for a while.  You most likely already have all your mac auth  
> stuff
> setup and the users are used to it.  FreeBSD can be set up to share
> AppleTalk volumes with decent performance - so I'd stick with it IMO.

Just wanted to add a caveat to this.  If you use afp, it's going to  
store resource forks on the server.  Unless you use server side  
utilities that respect this, these won't be kept for server side  
backups or when accessed using other protocols (ever want to smb  
share?).  With nfs, the resource fork will be kept in separate dot  
file that can be backed up and recovered safely.  I know that ufs2 is  
supposed to support meta data like resource forks, has there been any  
effort for netatalk to use this instead of the flat db files it keeps?

This also means that if you want to switch to nfs from afp, you will  
need to copy client side all the files to the new nfs exports.

-Bjorn