Mike Eisler wrote:
> "Nico Kadel-Garcia" wrote in message
> news:...
>> "Mike Eisler" wrote in message
>> news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
>>> "Nico Kadel-Garcia" wrote in message
>> news:...
>>>> Mike Eisler wrote:
>>>>
>>>>>> In this case the client machine (Solaris 9) does have a samba
>>>>>> client available. The only problem is that I'm not sure how
>>>>>> well samba
>>>>>
>>>>> An in-kernel SMB client? for Solari s9. I knew there
>>>>> were couple for Linux. Wow, I guess there's no need for NFSv4
>>>>> now. :-)
>>>>
>>>> Especially because AFS is available for Solaris, Linux, Windows,
>>>> and
>> MacOS
>>>> X, allowing a far more secure authentication structure and robust
>>>> file access for remotely connected sites.
>>>
>>> Kerberos V5 authentication, integrity, and
>>> privacy for NFS has been shipping since 1998.
>>
>> Friend, have you ever *tried* to integrate Kerberos into NFS in the
>> wild?
>
> Yes. I've even shipped implementations of it.
>
> ANyway, what do you mean by integrating Kerberos into NFS? Either
> the NFS client and server support RFC 2203 or they don't. Only one
> commerically supported UNIX client supports the RFC today, and
> several servers.

Getting a Kerberized login system actually running can be extremely painful.
Most UNIX vendors do not keep open source tools like this up to date in
their distributions, and thus tend to lack feature sets or compatibility
with other UNIX or other OS distributions with even slightly different
versions. This problem occurs with both Kerberos and NFS releases across
multipls OS releases. If you take advantage of subtle configurations to make
things work the way you want (such as using an NIS domain name that does not
match your network's default domain name, or using hostnames that are not
fully qualified because of people's old software that uses "$HOSTNAME" =
"non-fully-qualified-hostname" sorts of statements, it quickly becomes a
nightmare. And Kerberos used to be pretty fascist about insisting that the
first hostname returned by various "gethostby*" functions actually match
both the local $HOSTNAME and be a fully-qualified-hostname.

In fact, at the time, you could not *compile* Kerberos on a system that did
not have a FQHN and have its FQHN first in the normally setup /etc/hosts
lines. It's not required anywhere in the RFC's, but there was a little
compilation step that recorded the hostname for logging purposes, which
broke on this and required the entire thing to be recompiled from scratch
due to unnecessary creation of a TIMESTAMP file at compile time, designed to
force complete recompilation from scratch instead of permitting partial
compilation and Makefile dependencies in the development phase.

Oh, yeah, I've been through this with Solaris, OSF/1, and maybe a dozen
Linux variants. The Linux folks, fortunately, tend to clean out this kind of
silliniess.

>> It's..... pretty painful, at least the last couple of times *I*
>> tried it.
>
> Do tell.

See above. Compiling a new set of NIS tools is even worse, and more
dangerous, because so much of it is women into libc in the Solaris world.
Recent versions of NIS may finally incorporate these features for Solaris
releases, but a lot of work places these days have a stack of old Solaris
2.6 and up systems. Integrating newer releases into those environments is
extremely difficult without turning off the more sophisticated
functionality, especially with Sun's long-standing practice of forcing OS
upgrades by only releasing the new OS's with new architectures. Backporting
the feature sets is..... also painful.

>> And you missed the "robust" part. There is still no fix for the "if
>> you lose network connections of a hard-mounted NFS directory, you
>> often need to reboot both the server and the client to clean up the
>> mess" problem. This
>
> This is somethig I've never personally experienced, though I've tended
> to confine myself to good clients. Indeed, in the early days of NFS,
> my desktop ran completely diskless. In those days servers were less
> reliable than clients, and hard mounts meant the desk top was frozen.
> Then the server came back, the desktop came back to life, and
> everything continued. No mess.

I've run into it fairly frequently, for years. It's not so bad if you use
auto-mounting, and if you don't have processes that auto-generate files on
the hard-mounted or auto-mounted system frequently, and if your disconnect
time is quite short.

But if someone accidentally unplugs a fiber for an hour on a system logging
utility that generates files on an NFS mount every minute, you're
definitively screwed on both ends, at least in my experience. It also gets
much worse if you have the old AMD based automount tools, rather than the
more recent autofs tools, that do the symbolic link whackiness to auto-mount
things under /tmp_mnt and create symbolic links to them.

> Since then, at least one client has added a forced unmount option.

I can believe that. It's also deadly in when a process is holding an NFS
mount point open: in both the Linux and Solaris world, "fuser -m mountpoint"
is your friend for finding these and putting a bullet through them.

>> has been true for many years, and remains unchanged, especially
>> since a lot of NFS clients have built-in antique sources and lack
>> these resources but are expected to continue operating as modern
>> servers.
>>
>> OSF/1, anyone?
>
> OSF/1 is shipped by who now?

It's not shipped, anymore. DEC's previous releases of it for the Alpha got
taken over by Compaq, then by HP, and HP has end-of-lifed it, partially
because Alpha support and development is also pretty dead since the Alpha
technology got bought out by Intel in the wake of DEC's collapse.

But it's still heavily used in a lot of server class file server
environments. AdvFS running on SMP 64-bit Alphas does quite well with
extremely large amounts of RAM and extremely large amounts of disk, in the
many Terabyte range.

> Anyway, I've nothing against AFS, except that people can't find
> anyone to provide reliable commerical support for it now that IBM is
> EOLing the commercial product. I wish OpenAFS all the best, but I fear

Ohhh, shoot. I liked AFS, and had good success with WAN deployments of
OpenAFS over Linux/Windows setups.

> that just with the original CMU license, the
> OpenAFs license will prevent it from taking hold. It was because of
> the original license terms that AFS never made significant inroads,
> whereas,
> NFS source code, for $25K a copy, and an optional $250K buy out of the
> royalties, made it deal that no could refuse.

Corporations couldn't refuse. Individuals poking around, however, could not
even get started.

> I find it interesting that people are looking running CIFS on
> UNIX/Linux
> client and the file server.

Yeah, I caught a presentation by Jeff Schiller of MIT on the fun and games
of CIFS authentication a few years back. It was pretty nifty, and as CPU
overhead has continued to drop in price, it's become a much more acceptable
overhead. But I've never had the opportunity or incentive to get it running.

SMB is looking better and better for UNIX/Linux access. The resistance to
failures of occasional disconnections, and its ubiquity in the Windows
world, coupled with the helpful "reset all files in this directory to be
owned by foo with permissions bar" that is trivial to set up in the Samba
configurations is getting more and more appealing.