By calling my heart and working in Digital Design as a systems engineer, I often have to deal with over-complicated software products and architectural designs. This causes a passionate desire to minimize and simplify everything that comes handy, and leads to the delight of human decisions, just doing their job. without registration and sms .
So I got to know Alpine Linux.
You may like this distribution for the following reasons:
- If you like minimalism and tools, focused on the task without any extra whistles and decorations;
- If you notice that the existing “mainstream” distributions are a bit (?) Bloated and redundant;
- If you want to solve an existing problem in a simple way.
By "mainstream", I mean the CentOS-Debian-Ubuntu trio (of course, the world doesn’t end with them), may all those who believe in these wonderful distributions forgive me. When they are used, periodically, on the border of perception, a poignant thought arises - “can it be possible easier?”
Do we really need it?
$ holywar mode disable
Does all this require you to solve your small task:
Remarkable systemd. System initialization (not quite), which can give the impression of a control system of the shuttle?
No no no!Nobody says that it is impossible to understand its management, but its unrestrained growth can start to frighten, and the number of concepts clearly exceeds the minimum necessary set. Is all this really necessary for the implementation of a simple task and a very infrequent server reboot?
The journaling / auditing subsystem, built on a bunch like journald → rsyslogd + auditd?
Sure, that's great!One can guess why this is done exactly this way, but is it really necessary for my simple task to have such a chain?
Duplication of the functionality of periodic task execution in both systemd and crond?
Oh, this cron!Do I miss his classic mechanism? Perhaps its syntax may not be entirely obvious, but are the timers in sd obvious?
The coexistence of several network management subsystems in different combinations: classic networking / networkd / NetworkManager?
Manage the network need a lot!This combination, yes on the server system, but with several management interfaces for all tastes. Although no, let's add here also netplan, which “solves” the configuration problem for the listed subsystems. Do you want to start your own service, or often change the orbit by reconfiguring network interfaces?
Services like tuned and firewalld?
How without them?Are they needed for your task? In principle, it is good to consider firewalld as an attempt to escape from the iptables syntax, but as a result, instead of one syntax, you will understand the other and be perplexed by the size of the firewall-cmd commands. And do you really need a python interpreter and its processes in the base system? No, I love python, but not in this case.
Local mail service. Will you use it for sure?
Since we remembered minimalism, we can very roughly compare our leading distribution kits in their minimal installation:
- The leader of redundancy in terms of disk space and the number of packages is Ubuntu 18.04 ( 2.8 GB of disk space, 342 packages, 31 systemd active services, 15 processes at the entrance). The systemd family is represented here in the maximum amount - systemd, networkd, timesyncd, resolved, logind, there is dbus.
- CentOS 7.5.1804 loses by disk and number of packages, but the leader in probably-redundant services (1.1 GB of disk space, 299 packages, 34 active systemd services, 19 processes at the entrance, including NetworkManager, firewalld, tuned, postfix, polkitd auditd, journald + rsyslogd, dbus).
- Debian 9.4.0 tried not to inflate much: 940 MB, 334 packages, 25 active systemd services, 14 processes at the entrance. Of course, systemd is also here (as well as journald, timesyncd and the accompanying dbus), but without much fanaticism in terms of network management.
holywar: cannot change mode to 'disable': Permission denied
I want a strange
From the part of the above, you can (try) to get rid of manually, but suddenly everything is already invented for us? Ideally, from the distribution of the general purpose server operating system I would like to see:
- Oddly enough, the boot loader, which will reach us to the core;
- The OS kernel itself (in this case, linux);
- The initialization system that the kernel will launch when ready. It is desirable, by simplicity, not far from the ax;
- The minimum set of processes that the initialization system will run. Well, for example:
- Finalization of devices and determination of additional kernel parameters;
- Providing journaling (with text logs? Well, please);
- Network configuration (it would be nice, with a smaller number of control layers);
- Time synchronization (ntpd / chronyd);
- Several local consoles;
- Optional - periodic execution of tasks (crond);
- Optional - remote access to the system (sshd);
- It would be nice to save and restore the firewall configuration.
And that's about it, the rest is up to the package manager. Less executable code and configuration — fewer bugs, fewer bugs — fewer bugs. And the system is still running and available over the network. The idea looks good, now let's see how close the Alpine Linux distribution is to it.
About Alpine
What can fascinate Alpine, especially after CentOS? Desperate minimalism!
And, of course, the absence of the need for certification " Linux Systemd Certified Voldemort ".
What the authors did:
- Reduced the number of basic components used;
- Chose modules smaller and more transparent;
- Simplified system configuration process.
Namely:
- Extremely concise installation process using the console utility setup-alpine;
- Extlinux is taken from the syslinux project as a boot loader;
- A small build tool mkinitfs to create a temporary file system used at boot;
- The openrc initialization system with the definition of dependencies between services, launch levels and a pinch of scripting;
- Replacing the standard GNU libc library with a more lightweight musl libc;
- Instead of the GNU coreutils package, most of the standard system utilities in a somewhat curtailed version are part of the busybox package, which may be familiar to you from embedded solutions;
- The default is the ash command interpreter in busybox. Of course, no one bothers to put bash if necessary.
well systemd ; - Own package manager apk and its own package distribution infrastructure.
In addition, the authors implemented a number of measures aimed at increasing the level of security of the basic system:
The grsecurity / PaX kernel patches were applied (opinions differ on their effectiveness, but still); Already not, thanks to a colleague from the comments. Just on June 26, version 3.8.0 was released .- We collected packages using modes that reduce the likelihood of exploiting a number of possible vulnerabilities.
As a result, we get a system equipped with a number of additional protection mechanisms, allowing to solve the existing problem and occupies about 130 MB . The running system has 41 packages installed and 13 user processes are running, you can knock on ssh.
And nothing more. It remains to add what you need (and iptables with the ability to restore the configuration at startup, put it).
Open the lid
Please note - Alpine can be useful as a learning platform when learning about Linux! To see the logic of the components is subjectively easier than trying to cover CentOS or Ubuntu right away:
- The loader of our installed system is simple, its configuration fits in 12 lines:
- Yes, and in / boot is not too crowded:
- And here is the running bootloader without fashionable wallpapers:
- The kernel boots, picks up the initramfs, runs its own initialization steps and invokes the init command (which, in fact, also comes as part of busybox). Init uses the / etc / inittab file:
- And here it is explicitly stated that you need to run to initialize the system:
- Start 6 getty processes waiting on 6 virtual consoles for user local login.
- Start the openrc initialization system in order to achieve the required initialization levels one by one (openrc does not use the classic initialization levels 0-6, but its own sysinit levels / groups - boot - default).
Further, the state of the system depends on the openrc configuration, namely:
- Variables defined in the /etc/conf.d directory;
- Startup scripts in the /etc/init.d directory;
- Binding startup scripts to "initialization groups":
It remains to read the startup scripts and process them based on the launch levels and dependencies.
We can use the example of syslog (/etc/init.d/syslog) to see what the openrc startup script looks like.
As you can see, these are not always your unloved "footcloths":
Variables used during script execution are defined in the corresponding /etc/conf.d/syslog file. In our case, the variable SYSLOGD_OPTS = "- Z" is defined in the file.
Please note that the script declaratively defines the dependencies of this service.
Openrc honestly iterates the startup scripts in a given order, reaches the level of “default” - and here it is, the working system!
Demons under the hood
What exactly is hidden under the openrc startup scripts? Oddly enough - a set of tasks and demons listed below.
First, at the sysinit level:
- dmesg - set the logging level for messages from the kernel;
- devfs - mounted and configured / dev;
- mdev - starts the device manager;
- hwdrivers - load device modules based on information from / sys and / dev;
The next level is boot:
- modules - kernel modules are loaded, the list of which is defined in / etc / modules;
- hwclock - real time hardware clock is configured;
- sysctl - set the kernel parameters defined by us in /etc/sysctl.conf;
- swap - swap partition is connected;
- bootmisc - temporary directories are cleared;
- urandom - customizable random number generator;
- keymaps - initialized keyboard layout;
- hostname - sets the name of the machine, which is defined in / etc / hostname;
- networking - searching and initializing interfaces using information from / etc / network / interfaces;
- syslog — starts the logging daemon from the busybox;
And finally, the default level:
- chrony - starts the NTP service;
- crond - the scheduled task execution service starts;
- acpid — the power event tracking service starts;
- sshd - the remote access service is started.
Hooray, after completing these steps, the system is ready to go! Do not forget about the dependencies on the above services, which were specified in the init.d files:
- sysfs - mount / sys;
- fsck - check and repair file systems;
- root - mount the root system for writing / reading;
- localmount - mount all file systems listed in / etc / fstab;
- klogd - logging kernel events.
Open one of the local consoles where getty waits for us, enter the login, then pass the password to the login process and get access to the running ash shell (when started, the contents of the / etc / profile, /etc/profile.d/* and /.profile to prepare the user environment).
Hooray, no additional entities (of course, useful in some cases, like PAM) - and we are in the system!
It remains to use the package manager apk, and look for the packages we need for our task. (Are they there? You can evaluate it through a web portal ).
And also
- Distribution authors have created their own add-on over iptables called “Alpine Wall”. And it does not constantly hang as a separate process in the system;
- For those who like to manage the server through a web interface, the package “Alpine Configuration Framework” has been prepared. Without PHP or Perl, but with Lua;
- For those who wish to desktop, there is the possibility of installing a graphical environment (although it may be painful at the beginning);
- For special connoisseurs, there is an “installation” of Alpine in memory with configuration storage on external storage (see the description of the lbu tool).
Total
The Alpine distribution is not perfect, but its conciseness really impressed me, especially as a container (only 6 processes - init, 4 * getty, syslogd). For me, it looks like what the minimal server operating system should look like (forgive me, CentOS!).
In addition, it is quite suitable for the role of the training platform, which allows you to see what a modern distribution kit consists of, without plunging immediately into the abyss of whateverd services and multiple duplication of functionality in superbly-multi-level configurable tools for all occasions.