[TUHS] YP / NIS / NIS+ / LDAP

Grant Taylor gtaylor at tnetconsulting.net
Tue Nov 6 09:07:49 AEST 2018


On 11/05/2018 01:48 PM, A. P. Garcia wrote:
> Yes, that's exactly what Active Directory does and does well, so why 
> shun it? I'd be interested in knowing where a pure unix environment 
> exists, beyond my imagination and dreams that is.

Ah.  Let me describe it this way:

LAN with a mixture of Windows and Linux /workstations/ that doesn't 
include a Windows /server/ to provide the AD resources (DNS, LDAP, 
Kerberos, etc.)

I guess it could be said that Samba4 acting as an AD DC might be the 
proper choice here.  But that sounds like some hassle without the 
typical Windows GUI tools for administering AD.  -  I've also never done 
that, so the unknown quantity is a bit deterrent.

I can also see having multiple Linux machines in a network without any 
other OS.  Possibly a cluster of Raspberry Pi Zeros on a Cluster Hat. 
}:-)  Use the underlying Pi as the gateway and infrastructure device, 
including the directory.

The point being, there are environments with multiple Linux (Unix) 
machines that don't have ready access to AD.  Thus my asking about the 
Unix (Linux) native method.

> Linux is pretty much a first class citizen in a Windows world 
> today. Samba4 can act as a domain controller, but I don't know how 
> practical that solution is, how well it scales, or what kind of support 
> exists. It uses the same standard protocols as AD.

I feel like standing up AD, be it on Windows Server or Linux with 
Samba4, is applying a Windows centric solution to Linux (Unix) systems. 
I think this is acceptable if there is already Windows ~> AD in the mix. 
  But that's not always the case.

I also loath the idea that Unix (Linux) doesn't have a stand alone 
central directory server solution.  Or if LDAP + Kerveros is said 
solution, so be it.  -  That's sort of what I'm trying to figure out.

> I do dread the day that Microsoft introduces "Group Policy for Linux", 
> if they haven't already.

I'm fairly certain that group policy objects do exist for Linux AD 
clients.  I think they are just simpler and can do far fewer things.  I 
think they also effectively map to the standard things that we could 
already do in Linux.  It's just behind a Microsoft MMC snap-in to edit GPOs.

> Also, I like Powershell and was stoked when they introduced it to Linux, 
> but I've personally been resisting its use to manage Linux servers, 
> perhaps for no good reason.

I know a couple of people that have messed with PowerShell on Linux. 
One of whom actually prefers PowerShell to Bash (et al) for scripting. 
He stated that things are stored in data structures in PowerShell, and 
as such were easier to manipulate and work with, compared to 
unstructured data in STDIN / STDOUT.

He also stated that PowerShell was functionally just another shell for 
doing things on Linux.  In some ways, quite similar to moving between 
/bin/sh, /bin/bash, /bin/zsh, etc.  Obviously interacting with the shell 
is different.  But you're still calling Linux commands to do core 
things.  The glue is just different.

> Yesterday I read that MS is starting to develop SysInternals-like tools 
> for Linux. They own GitHub. Like it or not, they're not going away. 
> They're going to continue diluting the waters between Windows and Linux 
> more and more. Resistance is futile.

I was more meaning environments that don't include Windows Server, not 
meaning to shun Windows.

Translation:  What is the current Unix (Linux) method to provide central 
user directory / authentication for about a dozen Unix (Linux / Solaris 
/ *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't 
own a license for any version of Windows Server that supports AD.  Nor 
do I feel compelled to buy one.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/2ccc44c3/attachment.bin>


More information about the TUHS mailing list