Subject: Re: [netatalk-admins] samba/netatalk
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Sat Jan 23 1999 - 01:42:45 EST
Wagner One said in [netatalk-admins] samba/netatalk at 23/Jan/1999 (Sat)
05:13:22.
> I've been happily running netatalk for quite some time now. I would like
> to set up an area wherein mac and pc users can share files occasionally.
> Currently, I do not run samba (I guess that is what I need to share part
> of the disks to pc users). Would someone mind giving me a quick rundown
> of what I would need to do to set these two systems up together? I've
> seen talk occasionally regarding this subject, but would like to hear
> from someone doing it to find out success stories and/or problems of them
> coexisting, etc.
Well, I run samba 1.9.18p10, and netatalk asun2.1.2.... they work rather well
together, though I recommend doing the Network Trash workaround [making the
Net Trash directory read-only, and pre-creating individual trash folders
owned by each user account, mode 0600].
They co-exist quite well, but I have some advice:
1) Setup your .ext mappings correctly, and be SURE .pdf files are *NOT*
mapped to 'TEXT', but rather 'PDF ' [treat all pdfs as binaries, even if
they're ASCII encoded -- Postscript is CRLF format tolerant anyway]. If you
use Word 5.1 (as we do, eschewing the viral and bloated Office 97/98 garbage,
do setup .mcw as "Word pre-6 for Macintosh" and educate your Winbloze users
to employ that extension for Word 5 files. (You cannnot prevent them from
using their office 97 crap, so let that be .doc)
2) The only real "problem" with file interchange [aside from the app version
issues themselves] tend to be with text files. If you use BBEdit on the
Macintosh, you'll never have a problem. Likewise, on the PC, using PFE or
UltraEdit, you are fine. "Problems" start when you use dumb text programs
like Simpletext on the Macintosh, or Notepad on the PC. If you also use
"smart" text tools, then I'd actually recommend setting .txt to a BINARY
transmission mode [that is, never convert CRLFs].
I'll paste my original posting to this mailing list on the interchange issues
of text files:
----------- Repasting -----------
Hrm, I guess I've been lucky (or I setup things correctly)... but I don't
have any file translation issues, EXCEPT for text files (more later). BTW, I
recommend you setup PDF files as "PDF " "CARO" *NOT* the normal TEXT/CARO....
many PDFs are not TEXT, and in my experiences of dealing with hundreds of
web-borne (as well as locally generated (Distiller) PDF files, even the text
ones are OK if treated as "binary" types.
Anyhow, my text file issues are follows: I have samba/mac/linux shared
zones..... I'll summarise with a Matrix:
Creator
UNIX + MAC + SAMBA/PC
Accessor +----------------------------
UNIX ! OK OK MAYBE(2)
MAC ! OK OK NEVER(3)
SAMBA/PC ! MAYBE(1) MAYBE(1) OK
(1) Most programming editors (PFE, say) are tolerant of alternate platform
text line ends. Most "dumb" DOS tools can't deal with it. I'm not that
worried about this "dysfunction".
(2) This one is also pretty minor... Most unix tools seems to ignore the
extra character, though some display the CR as ^M (some text editors do) --
others like joe happily munch them silently.
(3) This is the annoying one. ALWAYS end up with double-spaced text when
accessing PC-created text objects. This would be a minor annoyance at
best... EXCEPT I happed to use CSV (Excel-type command-separated-values),
which gets a bit damaged in the translation (well, not data-loss damaged, but
annoying "double-spaced" spreadsheets, which most of my users require a
person like me to "undo").
The long and short of it is that MAC<->UNIX, things are pretty happy. It's
when you have SAMBA/PCs into the mix, the shit hits the fan. (Isn't that
always the case?)
I know the problem is this: PC's use CR/LF, and the translation in
netatalk+asun only converts the LF->CR... which leads to the double-spacing I
observe - that's not rocket science. I also know where the translation code
is performed - but I have a worry/question... what if I 'eat' the LF of a
detected CRLF pair (just passing CR's unmodified) in a text file stream? I
worry because the file advertises itself as say, 2000 bytes, but in actual
fact would be "smaller" because of the eaten LF's. Replacing it with a NUL
isn't the right approach either, because some apps go psycho when binary-like
data is encountered in an otherwise ASCII stream.
----------- End of Repasting -------------
3) *DO* setup your samba shares to both "veto" and "hide" files.... (to
conceal the .AppleDouble and other "crap" that netatalk makes to create the
2-fork files and stuff on unix systems. They only confuse winbloze users,
and tempt them to "delete" them, which is BAD if the files are Macintosh
resource-laden files such as applications.
I *highly* recommend you segregate application shares, however. (Make a
winbloze only one for samba, and a netatalk only for Macintosh). Use the
shared zones for data/scraps/Public common usage, really. Things get weird
when a windoze user starts browsing through Macintosh applications things.
(no .ext, etc)
Here is my veto/hide list (used for samba in smb.conf, in the [global]
section):
veto files =
/.?Desktop/.HoldDirectoryFinderInfoForMacNFS/.finderinfo/*Deskt
op DB*/resource.frk/.AppleDouble/.bin/.AppleDesktop/Network Trash
Folder/Icon*/*
OpenFolderList*/
hide files = /.*/DesktopFolderDB/Trash-For%m/resource.frk/*Desktop
DB*/*
Desktop DF*/*OpenFolderList*/*Network Trash Folder*/Network Trash
Folder*/Icon*/
%Icon*/.AppleDouble/
Also, for sanity's sake, *DO* enable "delete veto files = yes", otherwise if
a Winbloze user tries to kill an otherwise empty directory, they'll get very
mysterious "that directory isn't empty" errors.... (the .AppleDouble stuff
wouldn't be seen because it's hidden/veto'ed, but it'd prevent the deletion
from occurring).
Those are the major issues I've encountered and had to deal with. Generally
speaking, file locking just works, though is often inelegant in its
user-feedback. I've never lost data, but had programs issue strange errors.
So if different users attempt to edit the same file (one on samba, one on
netatalk), the unix file locking prevents anything really nasty from
happening... though since it's a "lower-level" error condition that
guardposts it, either server kinda panics a bit and returns status codes that
often cause "alarm" in the users' clients.
Also one more thing... it would be VERY NICE for netatalk asun to have some
of the group force and mode force directives samba has. For shared areas, it
would be nice to clamp the created files' groups and modes to smooth things
like permissions... I do often have to waste my time fixing permissions
issues in shared areas, and making entries "sticky" doesn't always fix the
problems.
BTW: Samba 2.0 was just released... it should offer an even more mature
level of NT Domain integration, and have even more configurability. Samba is
a shining star for configurability and cross-platform compatibility. And
Adrian's patches to netatalk make the possibility of a largely painfree
cross-platform server solution that's just plain fast and reliable more than
a dream, but a useful and well-behaved reality. Bravo to both teams.
Good luck!
=Rob=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:14 EST