How to properly manage a fleet of Unix servers?

Question

linux

Good afternoon, working in a windows environment, I have no idea how to manage a fleet of servers on unix based OSes, in particular, it is not clear how updates and policies are managed.
for example, Windows has AD, and group policy, vsus, + server tools like DAC, in other words, everything is controlled through 2-3 windows.
here is the question
1. how is the update in linux, if the network has different versions of linux, redhat, debian, with different kernel versions, software.?
2. How can the security policy be managed centrally? I understand you can write a script and run it through ansible, but I think this is a crutch.
3. How is account management centralized?
only not samba4 and ldap, imitation of HELL, this is a crutch.
4. let's say the server is spinning, they released an update, is it worth updating the core? after all, when updating, there is a possibility that the subd will not work.
how all this is monitored in order to know that on some server the password policy has not been updated.
expect a friendly response.

Answer 1

Greetings.
First of all, you should not imagine the solution of the problem as a "big button", because our understanding of infrastructure management is somewhat distorted by experience with MS products. The interface hides from us the stack of software used to achieve the goal. For example, WSUS. Under its hood is a set of services, each of which plays a specific role - bits for uploading to the server and delivering packages to the client, a web server for control commands, a database for storing client state and patches, a .net application that brings it all together. For a fleet of nix machines, you have to build a similar architecture yourself, each time choosing a tool that will play a particular role.
In the second step, you need to look at the task. If you have a dozen infrastructure servers, then Ansible is a really good choice. But only not "script". A "script" is a language that tells how to achieve a result. But configuration management tools save you from this, with the help of a declarative language you describe the end result itself (this is the key point) and do not think about which distribution kit (read package manager, configuration file location) is installed on the managed system.
If you need to give access to a large number of users to a large number of machines, then in the first step you need to choose two tools:
1. configuration management.
2. sudo control.
The first tool at a stretch may give you the opportunity to solve point 2, because in this second paragraph, you need to manage the same policies: give a group of users access to a group of machines and allow them to execute a group of commands. This is where Identity Manager comes into play and this question is at least open for me. The current trend is to deploy two directories (MS AD and a directory for the NIX fleet), but I'm not sure if that's the right thing to do. You can do without the second directory and, if you discard the husk, then the key problem, in this case, is the mapping of user security identifiers in MS AD and in nix systems (it's easy when there is one domain, it's more difficult when a forest, it's not at all easy in the case of manually created trust relationships ). Previously, this issue was solved by winbind with a set of libraries, implementing one or another matching algorithm, now it is SSSD, which implements two algorithms. Again, the issue with the execution of privileged commands in this configuration is not solved. RedHat offers tools compiled into a single product that supposedly solve these problems. Support from this very redahat costs a lot of money for us, but look at what solutions such as Sattelit and IdM consist of, these are open products (FreeIPA, candlepin, pulp, katello, puppet and, finally, foreman.) which, perhaps, you need .

Answer 2

I can only share my experience: first, get rid of the zoo of distributions. Which one to stop at - this is up to everyone to decide for themselves, but the main thing is to choose one. Next, make a local repository if it is a rolling release distribution, and even if not, but just a lot of machines - it will be many times faster from the local one. Well, then automate everything through Ansible. Of course, first test the update on a test virtual machine, then roll it out to production. I, in fact, have desktop Linux (it is the same on all office desktops, respectively, and I have a virtual machine on my computer with exactly the same system on which I check for updates), there is a basic server template (from which all server virtual machines are created) , I also have a copy of it on the virtual machine and I'm testing it on it.
Thus, you always have a system everywhere, about which you yourself are sure that it is working and there are no pitfalls like "here is one distribution, and here is another." I have several services in php, for example, php 7 came out - I cloned all these machines, tested them, the programmers corrected everything - I rolled up all the machines in php 7 production in 1 time. Etc. etc.
Accounts via LDAP, Samba, why, when Linux? Just one LDAP and that's it.
About the security policy - this is a Windows concept, in Linux it is slightly different. Updated the config everywhere via ansible and that's it, if he couldn't change it somewhere, he'll write about it. But if you took care at first and eliminated the zoo of distributions, everything will work clearly in the future, without headaches.

Answer 3

how is the update in Linux, if the network has different versions of Linux, redhat, debian, with different versions of the kernel, software.?

first in testing, then in production.
yum update/upgrade
apt-get update/upgrade
there are test servers for this, on which updates for the OS and DBMS are checked.
why do you think that ldap is a crutch? Because not from MSofta?
The same 389 Directory Server has a history since 1995.
It has a fairly advanced web and cmd interfaces with sufficient functionality.
And to get a friendly answer, you need to ask a friendly question.

Answer 4

1. How is the update in Linux, if the network has different versions of Linux, redhat, debian, with different versions of the kernel, software.?

Each one has its own package manager. Debian has apt-get, hatline (Red Hat, CentOS, Fedora) has yum
What is your understanding of "security policy"? GPO Default Domain Policy? File permissions? Something else?

3. How is account management centralized?
only not samba4 and ldap, imitation of HELL, this is a crutch.

Well, right now. This is AD - an add-on for LDAP, scripts and programs for LDAP servers work great with it. There are alternative implementations of Directory Server
In Windows - yes, quite often, they updated the kernel, the DBMS disappeared. In Linux, this happens much less often. And besides, the kernel is entirely in memory, and even if the physical file on the disk is replaced, the old kernel is used until the reboot.

Answer 5

1. First of all, you shouldn't fence the zoo of distros, you need to stop at one and use it everywhere. And then there are a bunch of options for updates, from yum-updatesd, to ansible yum: name="*" state=latest, to satellite/spacewalk, etc. There, management is already not only the level of updates, but also their varieties () security, system software, applications, etc.
2. The IPA covers all of these issues.
3. also IPA, although you can use any LDAP or NIS
4. just like in Windows - we check it on a test bench before launching updates in production. you can still take an lvm snapshot, roll, and roll back if anything, but this will require downtime.

Answer 6

"I understand you can write a script and run it through ansible, but I think it's a crutch."
"in windows...everything is managed through 2-3 windows."
First you need to discard the thought patterns that are typical for those working under Windows - that you need one powerful window that you click on and it will do everything. Unix has a completely different concept, and in Unix server technologies, the basis of the interface is TEXT, for example, the same "script" - a logical glue that connects the elements of the system into a single logic we need. In Unix, we have ready-made "modules" and a high-level programming interface to these "modules", and everyone is free to choose the interface language to their taste, for example, I like Python. Those working with Windows solutions are used to the fact that they have already glued everything, sold it, all that remains is to open a window with a couple of super buttons, and they want to see the same familiar super window in Unix. Eee. and why all of a sudden? If you like the window interface, please Windows world is yours. If you want a text interface, then the unix world is for you. But do not say that if the interface is text, then this is a crutch.