[BrandoElFollito]

I use ansible and salt to provision servers. It works great.

It has limited to no use to manage users and their passwords or authorizations, their control over machines, remote access to a share and zillons other usages you need specialized software for. AD has it all natively.

[xorcist]

People with large environments that needs to be managed homogenously would beg to differ. How else would people manage these things large scale? It's exactly the kind of functionality that this software provides. Expressing rules in code might be radically different to someone used to a product like AD, but the learning curve is pretty quick and it is inherently more powerful.

[BrandoElFollito]

I do not know about products for large environments. Our is arguably medium (around 10,000 servers) and we use solutions where each does its thing, without any reasonable cooperation between the solutions:

- users management? NIS

- configuration management? ansible / salt

- machines management? none (we use a homebrew system based off salt)

- shared storage? NFS

- policies? salt or ansible if they are common to groups of machines, or NIS if for people

etc.

I would love to have a unified tool (similar to what Zen was trying to do 20 years ago) but I do not know any. What AD does for Windows is nice (though I do not use Windows servers but I see their management from the side), Linux was intended to be standalone and this is what there are so many specialized, but disconnected management systems.

[xorcist]

Right, but NIS and NFS are just protocols. You might as well have said DNS and IMAP. There are also services behind those protocols that needs to be managed. This is what Puppet(/Chef/Salt) does.

Take NFS as an example. Let's say all your users with meets certain criteria needs an NFS share named after their user and with an ACL that gives some running software access to drop files there. Maybe this share should be mounted on every machine where this software is present, regardless of who own it or where it runs. You write this rule in Puppet code and then it is guaranteed to be true for everyone forever.

Note that we didn't even need to feed Puppet any new information to do this. All the data required to implement the change was already in the configuration database. (Which is not even a real database but only the result of existing rules.)

Compare with a product such as AD. It doesn't really do the management for you. You can store the data there, but then you need to write a script to implement this change across your server farm. This need to be maintained, and regularly checked re-run to check for changes. Someone has to schedule this. When conditions change, the software which got access changes id, or is installed in another way, the script needs to be maintained accordingly.

Having this version controlled adds another aspect to this. Since everything is text, if you find this rule you can follow the commits and see exactly who brought this into production and when.

It's interesting that you refer to Linux as a standalone system. Linux and other unices have their roots not in single instance "personal computers" but in multi user environments. This is why to this day Linux admins treat everything as text and work mostly by text commands. Others may find this archaic but without this and without version control we could never maintain large homogenous environments. You might say that automation is built into the very way we use these systems.