Atas panggilan hati saya dan bekerja sebagai insinyur sistem dalam Desain Digital, saya sering harus berurusan dengan produk perangkat lunak yang canggih dan desain arsitektur. Hal ini menyebabkan keinginan untuk meminimalkan dan menyederhanakan segala sesuatu yang ada di tangan, dan mengarah pada kesenangan keputusan manusia yang hanya melakukan pekerjaan mereka. , tanpa registrasi dan SMS .

Jadi saya bertemu dengan Alpine Linux.

Anda mungkin menyukai distribusi ini karena alasan berikut:

• Jika Anda menyukai minimalis dan alat yang berorientasi untuk menyelesaikan tugas tanpa peluit dan dekorasi yang tidak perlu;
• Jika Anda memperhatikan bahwa distribusi "arus utama" yang ada sedikit (?) Kembung dan berlebihan;
• Jika Anda ingin menyelesaikan masalah yang ada dengan cara sederhana.

Dengan "arus utama," maksud saya trio CentOS-Debian-Ubuntu (tentu saja, dunia tidak berakhir di sana), maafkan saya semua yang percaya pada distribusi yang luar biasa ini. Ketika mereka digunakan, secara berkala, di perbatasan persepsi, sebuah gagasan tajam muncul - "mungkin ini bisa lebih mudah?".

Apakah kita benar-benar membutuhkannya?

Mode $ holywar nonaktifkan
Sungguh untuk solusi tugas kecil Anda semua ini diperlukan:

• Sistem yang luar biasa. Sistem inisialisasi (tidak sepenuhnya sama sekali) yang mungkin memberi kesan sistem kontrol shuttle?

  Nenen!

  Tidak ada yang mengatakan bahwa Anda tidak dapat memahami cara mengelolanya, tetapi pertumbuhannya yang merajalela dapat mulai menakut-nakuti, dan jumlah konsep jelas melebihi jumlah minimum yang disyaratkan. Apakah semua ini benar-benar diperlukan untuk implementasi tugas sederhana dan reboot server yang sangat jarang?
  
  

• Subsistem logging / audit dibangun di atas sekelompok seperti journald -> rsyslogd + auditd?

  
  
  Ini tidak diragukan lagi hebat!

  Orang bisa menebak mengapa ini dilakukan sedemikian rupa, tetapi apakah rantai seperti itu benar-benar diperlukan untuk tugas sederhana saya?

  
  

• Duplikasi fungsi eksekusi tugas berkala di systemd dan crond?

  Oh, Cron itu!

  Apakah saya benar-benar kehilangan mekanisme klasiknya? Mungkin sintaksnya mungkin tidak sepenuhnya jelas, tetapi apakah timer di sd begitu jelas?
  
  

• Koeksistensi beberapa subsistem manajemen jaringan dalam kombinasi berbeda: jaringan klasik / networkd / NetworkManager?

  Anda perlu banyak mengatur jaringan!

  Kombinasi ini, ya, pada sistem server, dan dengan beberapa antarmuka manajemen untuk semua selera. Meskipun tidak, mari kita tambahkan di sini juga netplan, yang "memecahkan" masalah konfigurasi untuk subsistem yang terdaftar. Apakah Anda ingin memulai layanan Anda, atau sering mengubah orbit karena konfigurasi ulang antarmuka jaringan?
  
  

• Layanan seperti disetel dan firewalld?

  Bagaimana tanpa mereka?

  Apakah mereka dibutuhkan untuk tugas Anda? Pada prinsipnya, senang mempertimbangkan firewalld sebagai upaya untuk menghindari sintaks iptables, tetapi sebagai hasilnya, alih-alih satu sintaks, Anda akan memahami yang lain dan bingung dengan ukuran perintah firewall-cmd. Dan apakah Anda benar-benar membutuhkan juru bahasa python dan prosesnya dalam sistem basis? Tidak, saya suka python, tetapi tidak dalam hal ini.
  
  

• Layanan surat lokal. Apakah Anda yakin akan menggunakannya?

  
  

Karena kami ingat minimalis, kami dapat membandingkan distribusi utama kami dalam pemasangan minimal :

• Pemimpin redundansi dalam ruang disk dan jumlah paket adalah Ubuntu 18,04 (ruang disk 2,8 GB , 342 paket, 31 layanan systemd aktif, 15 proses saat masuk). Keluarga systemd di sini diwakili sampai batas maksimum - systemd, networkd, timesyncd, diselesaikan, logind, ada dbus.
• CentOS 7.5.1804 hilang oleh disk dan jumlah paket, tetapi pemimpin dalam layanan yang mungkin berlebihan (1,1 GB ruang disk, 299 paket, 34 layanan systemd aktif, 19 proses saat masuk, termasuk NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
• Debian 9.4.0 berusaha sangat keras untuk tidak mengembang: 940 MB, 334 paket, 25 layanan systemd aktif, 14 proses saat login. Tentu saja, ada juga systemd di sini (serta journald, timesyncd dan dbus yang menyertainya), tetapi tanpa banyak fanatisme mengenai manajemen jaringan.

holywar: tidak dapat mengubah mode menjadi 'disable': Izin ditolak

Saya ingin yang aneh

Anda dapat (mencoba) untuk menyingkirkan bagian di atas secara manual, tetapi tiba-tiba semuanya telah ditemukan untuk kita? Idealnya, saya ingin melihat dari distribusi sistem operasi server serba guna:

• Anehnya, bootloader, yang akan mencapai kita ke kernel;
• Kernel OS itu sendiri (linux dalam hal ini);
• Sistem inisialisasi yang akan diluncurkan oleh kernel saat siap. Diinginkan, dalam kesederhanaan, tidak jauh dari kapak;
• Set minimum proses yang akan dimulai oleh sistem inisialisasi. Nah, misalnya:
  
  • Inisialisasi perangkat akhir dan definisi parameter kernel tambahan;
  • Memberikan penjurnalan (mungkinkah dengan majalah teks? Baiklah, tolong);
  • Konfigurasi jaringan (akan menyenangkan, dengan lapisan kontrol lebih sedikit);
  • Sinkronisasi waktu (ntpd / chronyd);
  • Beberapa konsol lokal;
  • Opsional - pelaksanaan tugas secara berkala (crond);
  • Opsional - akses jarak jauh ke sistem (sshd);
  • Akan lebih baik untuk menyimpan dan mengembalikan konfigurasi firewall.

Dan itu saja, sisanya terserah manajer paket. Kode dan konfigurasi yang kurang dapat dieksekusi - lebih sedikit bug, lebih sedikit bug - lebih sedikit bug. Dan sistem juga berjalan dan dapat diakses melalui jaringan. Idenya terlihat bagus, sekarang mari kita lihat seberapa dekat distribusi Alpine Linux .

Tentang Alpine

Apa yang bisa memikat Alpine, terutama setelah CentOS? Minimalis yang putus asa!
Yah dan, tentu saja, kurangnya kebutuhan untuk sertifikasi " Linux Systemd Certified Voldemort ".

Apa yang penulis lakukan:

• Mengurangi jumlah komponen dasar yang digunakan;
• Kami memilih modul yang lebih kecil dan lebih transparan;
• Proses konfigurasi sistem yang disederhanakan.

Yaitu:

• Proses instalasi yang sangat singkat menggunakan utilitas konsol setup-alpine;
• Extlinux dari proyek syslinux diambil sebagai loader;
• Alat bantu pembuatan mkinitf kecil untuk membuat sistem file sementara yang digunakan saat boot;
• Sistem inisialisasi Openrc dengan definisi dependensi antara layanan, runlevel dan sejumput scripting;
• Mengganti perpustakaan libc GNU standar dengan libc musl yang lebih ringan;
• Alih-alih paket GNU coreutils, sebagian besar utilitas sistem standar dalam versi yang agak terpotong adalah bagian dari paket busybox, yang mungkin Anda kenal dalam solusi embedded;
• Secara default, shell ash digunakan sebagai bagian dari busybox. Tentu saja, tidak ada yang mengganggu jika perlu bash , well, dan systemd ;
• Manajer paket apk asli dan infrastruktur distribusi paket milik.

Selain itu, penulis menerapkan sejumlah langkah yang bertujuan untuk meningkatkan tingkat keamanan sistem dasar:

• Kami menerapkan patch kernel grsecurity / PaX (pendapat berbeda tentang efektivitasnya, tetapi masih); Tidak lagi, terima kasih kepada kolega dari komentar. Baru 26 Juni, versi 3.8.0 dirilis .
• Paket dikumpulkan menggunakan mode yang mengurangi kemungkinan mengeksploitasi sejumlah kemungkinan kerentanan.

Sebagai hasilnya, kami mendapatkan sistem yang dilengkapi dengan sejumlah mekanisme perlindungan tambahan, yang memungkinkan kami untuk menyelesaikan masalah yang ada dan menempati sekitar 130 MB . Pada sistem yang sedang berjalan, 41 paket diinstal dan 13 proses pengguna berjalan, Anda dapat mengetuk ssh.

Dan tidak lebih. Tetap menambahkan apa yang Anda butuhkan (dan menempatkan iptables dengan kemampuan untuk mengembalikan konfigurasi saat startup).

Buka sedikit tutupnya

Harap dicatat - Alpine dapat berguna sebagai tempat pelatihan ketika membiasakan diri dengan Linux! Secara subyektif lebih mudah untuk melihat logika komponen daripada mencoba untuk menutupi CentOS atau Ubuntu:

• Bootloader sistem terinstal kami sederhana, konfigurasinya terbagi menjadi 12 baris:

• Ya, dan di / boot tidak terlalu ramai:

• Dan inilah bootloader yang diluncurkan tanpa wallpaper mewah:

• Kernel boot, mengambil initramfs, memenuhi langkah inisialisasi sendiri dan memanggil perintah init (yang, pada kenyataannya, juga dilengkapi dengan busybox). Init menggunakan file / etc / inittab:

• Dan di sini secara eksplisit dijelaskan apa yang perlu diluncurkan untuk menginisialisasi sistem:
  
  • Jalankan 6 proses getty menunggu pada 6 konsol virtual untuk login pengguna lokal.
  • Jalankan sistem inisialisasi openrc untuk secara bergantian mencapai level inisialisasi yang diperlukan (openrc tidak menggunakan level inisialisasi klasik 0-6, tetapi level / grup sysinitnya sendiri - boot-default).

Lebih lanjut, keadaan sistem tergantung pada konfigurasi openrc, yaitu:

• Variabel yang didefinisikan dalam file direktori /etc/conf.d;
• Jalankan skrip yang terletak di direktori /etc/init.d;
• Mengikat skrip startup ke "grup inisialisasi":

Tetap membaca skrip startup dan memprosesnya dengan mempertimbangkan tingkat peluncuran dan dependensi.
Dengan menggunakan contoh syslog (/etc/init.d/syslog), kita dapat melihat seperti apa bentuk skrip startup openrc.

Seperti yang Anda lihat, ini tidak selalu ini dari tas kaki yang tidak Anda cintai:

Variabel yang digunakan saat menjalankan skrip didefinisikan dalam file yang sesuai /etc/conf.d/syslog. Dalam kasus kami, variabel SYSLOGD_OPTS = "- Z" didefinisikan dalam file.
Harap perhatikan bahwa skrip mendeklarasikan dependensi layanan ini secara deklaratif.

Openrc dengan jujur ​​mengulangi skrip startup dalam urutan yang diberikan, mencapai level "default" - dan ini dia, sistem yang berfungsi!

Setan di bawah tenda

Apa sebenarnya yang disembunyikan di bawah skrip startup openrc? Anehnya - satu set tugas dan setan yang tercantum di bawah ini.

• Pertama, di tingkat sysinit:

  
  
  • dmesg - atur level logging untuk pesan dari kernel;
  • devfs - mount dan konfigurasikan / dev;
  • mdev - manajer perangkat dimulai;
  • hwdrivers - modul perangkat dimuat berdasarkan informasi dari / sys dan / dev;
  
  

• Berikutnya adalah level boot:

  
  
  • modules - modul kernel dimuat, daftar yang didefinisikan di / etc / modules;
  • hwclock - jam perangkat keras real-time dikonfigurasi;
  • sysctl - mengatur parameter kernel yang kita definisikan di /etc/sysctl.conf;
  • swap - partisi swap terhubung;
  • bootmisc - direktori sementara dihapus;
  • urandom - generator nomor acak dikonfigurasi;
  • keymaps - tata letak keyboard diinisialisasi;
  • hostname - mengatur nama mesin, yang didefinisikan di / etc / hostname;
  • jaringan - pencarian dan inisialisasi antarmuka menggunakan informasi dari / etc / network / interfaces;
  • syslog - memulai daemon logging dari busybox;
  
  

• Dan akhirnya, level default:

  
  
  • chrony - layanan NTP dimulai;
  • crond - layanan pelaksanaan tugas yang dijadwalkan diluncurkan;
  • acpid - layanan pelacakan peristiwa daya dimulai;
  • sshd - layanan akses jarak jauh dimulai.
  
  

Hore, setelah menyelesaikan langkah-langkah ini, sistem siap untuk pergi! Jangan lupa tentang ketergantungan pada layanan di atas yang ditentukan dalam file init.d:

• sysfs - mount / sys;
• fsck - memeriksa dan memperbaiki sistem file;
• root - mount sistem root untuk menulis / membaca;
• localmount - mount semua sistem file yang terdaftar di / etc / fstab;
• klogd - mencatat kejadian kernel.

Kami membuka salah satu konsol lokal di mana getty sedang menunggu kami, masukkan login, setelah itu kami meneruskan kata sandi ke proses login dan mendapatkan akses ke shell ash yang sedang berjalan (ketika diluncurkan, isi file / etc / profile, /etc/profile.d/* dan ~ /. profil untuk mempersiapkan lingkungan pengguna).

Hore, tidak ada entitas tambahan (pasti berguna dalam beberapa kasus, seperti PAM) - dan kami berada dalam sistem!

Tetap menggunakan pengelola paket apk, dan mencari paket yang kami butuhkan untuk tugas kami. (Apakah mereka ada di sana? Anda dapat mengevaluasi ini melalui portal web ).

Dan juga

• Penulis distribusi membuat add-on iptables mereka sendiri yang disebut "Dinding Alpine". Dan itu tidak menggantung secara konstan sebagai proses terpisah dalam sistem;
• Bagi mereka yang suka mengelola server melalui antarmuka web, paket Kerangka Konfigurasi Alpine telah disiapkan. Tanpa PHP atau Perl, tetapi dengan Lua;
• Bagi mereka yang menginginkan desktop, ada kemungkinan menginstal lingkungan grafis (meskipun ini mungkin terasa menyakitkan di awal);
• Untuk penikmat khusus ada "instalasi" Alpine dalam memori dengan konfigurasi yang disimpan di penyimpanan eksternal (lihat deskripsi alat lbu ).

Ringkasan

Distribusi Alpine tidak sempurna, tetapi singkatnya benar-benar membuat saya terkesan, terutama dalam peran wadah (hanya 6 proses - init, 4 * getty, syslogd). Bagi saya, sepertinya sistem operasi server minimal harus seperti (maafkan saya, CentOS!).

Selain itu, sangat cocok untuk peran platform pelatihan, yang memungkinkan Anda untuk melihat apa yang terdiri dari kit distribusi modern, tanpa langsung terjun ke jurang apa pun layanan-d dan berulang kali menggandakan fungsionalitas dalam alat luar biasa yang dapat dikonfigurasi multi-level untuk semua kesempatan.