Re: NIS or NIS + setup

From: Chris Cox (ccox_nopenotthis@airmail.net)
Date: 01/15/03 

From: Chris Cox <ccox_nopenotthis@airmail.net>
Date: Tue, 14 Jan 2003 17:09:05 -0600

Nico Kadel-Garcia wrote:
> "Chris Cox" <ccox_nopenotthis@airmail.net> wrote in message
> news:413FCADDE080BAE6.46A16F699C362ABD.6C119970466EEB0F@lp.airnews.net...
>
>>Nico Kadel-Garcia wrote:
>>
>>>"sandra" <sandra@ccuec.unicamp.br> wrote in message
>>>news:3E1C60D3.601E72A9@ccuec.unicamp.br...
>>>
>>>
>>>>Hi ALL,
>>>>
>>>> I wonder if NIS+ development on Linux is realy stopped. And if
>>>>someone out there has any clue to give me about athoner software
>>>>that could substitute NIS/NIS+ function.
>>>> Thanks a lot.
>>>
>>>
>>>Only if we're lucky: NIS has had a lot of issues for a long time, and
>>>they've never gotten better, only more complicated.
>>
>>You need to be more specific. My guess is that you are referring
>>to weaknesses in the security. NIS isn't great, NIS+ isn't great
>>either (but makes you think it is). There are some automounter
>>limitations with Linux, but in general, nothing you just have
>>to have. NFS (not NIS) performance still needs some improvement,
>>but it does seem to function reasonably.
>
>
> NIS=No Internal Security
> NFS=No Fucking Security
>
> In particular, NFS in most configurations allows the user to become root
> locally, then su to become the other use and gain access to that user's
> files.
>
> NIS has horrid issues with poor implementations and subtle incompatibilities
> between systems breaking things at awkward moments. (Linux, Tru64, SunOS and
> Solaris [ which really were distinct operating systems due to the large
> differences in fundamental packeges between them]: cross-platform has been
> fun, and convincing stodgy old-timers to use the more flexible and
> compatible Linux servers was non-trivial)

I operate a network consisting of all the platforms mentioned (plus
many more... 100's of hosts). The ones you mentioned have no major
difficulties with NIS. However, I did have the "pleasure" of working on
an NCR host recently. Though is is SVR4 based, the NIS was a throw back
to yesteryear in that it could only work via broadcast. Therefore, we
were forced to configure it as an NIS slave since it sits in a different
net segment. That was probably the most difficult thing I've had to do
recently with regards to NIS.

>
>
>>>LDAP is your friend.
>>>
>>>
>>
>>Lack of management interfaces and numerous interoperability issues
>>make cross platform LDAP a bit difficult currently, but we all
>>believe that will get better with time. I haven't seen too
>>many cross platform signon systems using LDAP that weren't
>>difficult to setup and maintain.
>
>
> As opposed to maintaining the cross-platform support for NIS or NFS to our
> dreaded Windows colleages, or getting group. And I genuinely challenge you
> to name good management interface for NIS.

YaST setup tool is pretty good for managing server/slave/client setup.
useradd/make for users.
groupadd/make for groups.
vi/make for the rest.

Unlike LDAP, a good percentage of what you administer in NIS is
using formats that already exist (just add the make typically don
in /var/yp on the master). Choose you're favorite user add tool...
just slap a make onto the end to push it out (for example).

>
>
>>If you want to include Windows 2000 (and the Windows clients),
>>I'd have Windows 2000 manage the users and use samba
>>and pam_smb for authentication (together with NIS on Linux).
>
>
> I've proposed it and done test cases. Unfortunately, getting some
> proprietary Windoze compatible tools to deal with Samba as a PDC was
> non-trivial. *Japanese* Windoze was a deal breaker, bloody Unicode based
> login tools with proprietary keyboard interfaces that *LIE* about what
> they're sending.....

Again, I wasn't referring to a Samba based PDC, but merely
authenticating the Unix hosts through the Windoze PDC.
I agree that Windows really doesn't like anything but
Windows. Unix hosts are pretty easy about integrating
with Windows.. the opposite is definitely anything but
true. I use Samba to point to the PDC (Windoze) Password
Server and use pam_smb for PAM enabled services.

Using this technique, Windows users can neigborhood to their
NIS home directory (which could be NFS mounted via the
automouter) from their Windoze client. Likewise, they
can log into the *ix host using their Windows password.
Not quite as good as some sort of floating credential
(as far as ease of use goes), but keeps the account
management primarily centralized on one host... even
if it's Windoze. Many services will require that a
password be intialized on the *ix side (NIS) for the
users... but that should be a secure password since
the users will simply use their Domain password.

>
>
>>This will work across Solaris, HPUX, Linux and AIX (Note: AIX
>>4 requires a special modified pam_smb that works with its pluggable
>>authentication framework). This way accounts only have
>>to be created/destroyed under Windows (the NIS ones will
>>only operate if there is a valid user under the Windows
>>domain). Note: I'm not talking about using winbindd.
>>
>>I'd also avoid cross posting to so many newsgroups .. hint.
>
>
> I was following up. Feel free to reset Follup-to....
>
>

Sorry... really meant for the OP.