Senarai semak penyelenggaraan pelayan Linux berkala

Apakah maksud sebenar penyelenggaraan pelayan Linux

Penyelenggaraan pelayan Linux ialah senarai semak ringkas yang dijalankan mengikut jadual tetap, bukannya projek yang mempunyai titik tamat. Secara mingguan, anda perlu mengesahkan bahawa kemas kini telah dipasang, cakera mempunyai ruang yang mencukupi, tiada servis yang terhenti, dan tugasan sandaran telah selesai. Secara bulanan, anda perlu menguji pemulihan data, menyemak tarikh luput sijil, mengaudit akaun dan kunci, serta membersihkan kernel dan log lama. Sekali bagi setiap keluaran pengedaran (distribution release), anda perlu merancang naik taraf versi dan melakukan but semula (reboot) yang sering anda tangguhkan.

Membina pelayan adalah tugas yang berbeza, dan sepuluh minit pertama pada VPS baharu merangkumi bahagian tersebut. Halaman ini adalah untuk tahun-tahun berikutnya. Setiap item di bawah menamakan kegagalan yang dicegahnya, kerana senarai semak tanpa akibat adalah senarai yang akan diabaikan oleh pengguna secara senyap.

Perintah di sini adalah sebagai ilustrasi dan bertujuan untuk dibaca sebelum dijalankan. Bandingkan outputnya dengan pelayan anda sendiri, kerana nilai yang sihat bagi ruang bebas atau bilangan proses bergantung pada fungsi pelayan tersebut. Di mana sesuatu semakan berbeza antara pengedaran, teks akan menyatakannya. Contoh menggunakan Debian dan Ubuntu dengan apt. Bagi keluarga RHEL, alatan yang digunakan ialah dnf dan beberapa laluan (paths) adalah berbeza.

Cara memilih jadual penyelenggaraan pelayan Linux yang boleh anda kekalkan

Pemeriksaan mingguan meliputi perkara yang berubah tanpa tindakan anda: pakej, penggunaan cakera, status servis dan tugasan berjadual. Perkara ini berubah dengan sendirinya, jadi seminggu adalah tempoh paling lama anda boleh membiarkannya tanpa dipantau.

Pemeriksaan bulanan meliputi kemerosotan perlahan: sijil yang hampir tamat tempoh, akaun yang tidak dibuang, kernel yang terkumpul dalam /boot, serta fail log yang membesar melebihi peraturan putaran yang tidak lagi sepadan. Tiada satu pun daripada perkara ini akan rosak esok. Namun, semuanya akan rosak akhirnya.

Pemeriksaan keluaran adalah berdasarkan kalendar. Keluaran pengedaran adalah satu-satunya item penyelenggaraan dengan tarikh akhir luaran, kerana sokongan untuk versi semasa anda akan berakhir sama ada anda sudah bersedia atau tidak.

Tetapkan masa pelaksanaan dalam slot tetap, contohnya pagi Isnin untuk pemeriksaan mingguan dan hari pertama setiap bulan untuk pemeriksaan bulanan. Senarai semak yang dilakukan "apabila ada masa" bukanlah senarai semak yang sebenar. Jika anda menguruskan lebih daripada beberapa buah mesin, jalankan tugas ini dari satu lokasi pusat dan bukannya secara manual, yang merupakan topik bagi mengurus berbilang pelayan Linux dari satu lokasi.

Mingguan: adakah kemas kini benar-benar dipasang?

Mendayakan unattended-upgrades tidak sama dengan memastikan ia telah dijalankan. Servis boleh di-mask, konfigurasi boleh dihadkan kepada origin yang tidak anda gunakan, dan satu pakej yang di-hold boleh merosakkan setiap pelaksanaan selepasnya. Pemasangannya diliputi dalam kemas kini keselamatan automatik pada Ubuntu. Tugasan mingguan adalah untuk membuktikan bahawa apa yang anda pasang telah melaksanakan tugasnya.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable ialah ukuran yang jujur, kerana ia melaporkan keadaan semasa dan bukannya niat. Kemas kini keselamatan yang masih tersenarai di situ bermakna automasi tidak menjalankan tugasnya, jadi baca log sebelum menganggap mesin telah ditampal (patched). Pakej yang di-pin dengan apt-mark hold akan dilangkau selama-lamanya dan tidak melaporkan apa-apa, itulah sebabnya apt-mark showhold perlu disertakan dalam langkah yang sama.

Kegagalan yang dapat dielakkan oleh langkah ini: menjalankan pakej yang diketahui mempunyai kerentanan selama berbulan-bulan sedangkan anda percaya kemas kini berjalan secara automatik.

Mingguan: ruang cakera dan inode

Sistem fail root yang penuh akan menyebabkan kerosakan pada fungsi yang kelihatan tidak berkaitan dengan cakera. Pangkalan data menolak penulisan, pengelogan terhenti, naik taraf pakej gagal semasa konfigurasi, dan pada sesetengah tetapan, anda tidak boleh membuka sesi baharu kerana sistem tidak dapat menulis failnya sendiri.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i ialah bahagian yang sering diabaikan oleh kebanyakan orang. Inode ialah struktur berkiraan tetap yang menyimpan metadata fail, dan sistem fail boleh kehabisan inode walaupun df -h masih melaporkan baki gigabait yang banyak. Penulisan kemudiannya gagal dengan ralat No space left on device walaupun output menunjukkan ruang masih ada, situasi yang membuang masa selama sejam pada kali pertama ia berlaku. Berjuta-juta fail kecil, daripada baris gilir mel yang tersangkut atau direktori sesi yang tidak dibersihkan, adalah punca biasa.

du -xh kekal pada satu sistem fail, iaitu apa yang anda perlukan pada pelayan dengan bind mounts atau storan yang dipasang. Pada hos Docker, jawapannya biasanya terletak pada lapisan imej dan volum yang tidak digunakan, yang boleh dibersihkan seperti yang diterangkan dalam pembersihan penggunaan cakera Docker pada VPS.

Ruang kosong memberitahu anda tentang kapasiti. Storan di bawahnya akan gagal mengikut jadualnya sendiri, yang merupakan pemeriksaan berasingan yang diliputi dalam pemantauan kesihatan cakera pada VPS.

Mingguan: apa yang terhenti tanpa memberitahu anda?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Unit yang terhempas dan mencapai had mulakan semula (restart limit) akan berada dalam keadaan gagal dan kekal di situ tanpa sebarang notifikasi. Tiada e-mel yang akan dihantar kepada anda mengenainya. list-timers merupakan bahagian yang lebih berguna: ia menunjukkan bila setiap pemasa (timer) terakhir dijalankan dan bila ia akan diaktifkan seterusnya. Oleh itu, nilai LAST yang lebih lama daripada selang masa pemasa itu sendiri bermakna tugasan tersebut tidak dijalankan langsung.

Baca jurnal untuk unit tersebut sebelum memulakan semulanya dengan journalctl -u <unit> -n 100 --no-pager. Memulakan semula hanya akan menghilangkan simptom, dan anda tidak mempunyai sebab untuk menyemaknya semula sehingga perkara yang sama berlaku pada waktu yang lebih kritikal.

Kegagalan yang dapat dielakkan dengan cara ini: ejen pemantauan, pekerja baris gilir (queue worker) atau servis sandaran yang telah mati sejak lonjakan memori tiga minggu yang lalu.

Mingguan: adakah tugasan sandaran benar-benar selesai?

Tugasan sandaran yang dijadualkan dan tugasan sandaran yang selesai adalah dua perkara berbeza, dan hanya satu daripadanya boleh digunakan untuk pemulihan. Sahkan penyelesaiannya.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Sahkan dua perkara. Larian terakhir keluar dengan kod sifar, dan arkib terbaharu adalah terkini serta mempunyai saiz yang dijangkakan. Fail sandaran yang tiba-tiba menjadi satu persepuluh daripada saiz biasa merupakan satu kegagalan dump yang masih menghasilkan fail. Ini adalah bentuk kegagalan sandaran yang paling berbahaya kerana semua proses hiliran kelihatan normal.

Jika skrip anda menyalurkan (pipe) dump ke dalam pemampat, tambahkan set -o pipefail di bahagian atas. Tanpanya, status keluar bagi pipeline tersebut adalah status pemampat, dan pemampat itu berjaya: ia memampatkan mesej ralat. Tugasan tersebut kemudiannya melaporkan kejayaan setiap malam walaupun sebenarnya menulis arkib kecil yang kosong.

Bulanan: pulihkan sandaran di lokasi lain

Ini adalah perkara yang paling kerap diabaikan oleh pengguna, namun ia merupakan penentu sama ada senarai selebihnya berguna atau tidak.

Pulihkan sandaran ke mesin yang berbeza atau kontena baharu, jangan sekali-kali menimpa data yang sedang aktif. Kemudian, buka data yang telah dipulihkan dan sahkan kandungannya. Kira baris dalam jadual. Buka dokumen. Log masuk ke aplikasi yang dipulihkan. Proses pengekstrakan yang selesai hanya membuktikan arkib boleh dibaca, tidak lebih daripada itu.

Alat repositori mempunyai mekanisme pengesahan tersendiri: restic check --read-data-subset=5% dan borg check --verify-data membaca data yang disimpan dan bukannya indeks. Jalankan arahan ini, dan anggap ia sebagai ujian awal (smoke test) dan bukannya pengganti kepada pemulihan sebenar. Pengesahan hanya memastikan bait data terselamat. Pemulihan memastikan bait tersebut adalah data yang diperlukan oleh aplikasi anda.

Dua perincian yang sering dipelajari melalui pengalaman pahit. Uji frasa laluan penyahsulitan pada mesin yang tidak menyimpan kunci dalam ejen, kerana sandaran yang tidak boleh dinyahsulit bukanlah sandaran. Selain itu, ambil masa proses pemulihan tersebut, kerana tempoh itu adalah masa pemulihan sebenar anda, dan waktu yang paling biasa untuk menyedarinya adalah semasa gangguan sistem berlaku.

Bulanan: sijil mana yang akan tamat tempoh tidak lama lagi?

Automasi pembaharuan gagal secara senyap. Pemasa certbot boleh memperbaharui fail pada cakera sementara pelayan web terus menghidangkan sijil lama daripada memori, kerana cangkuk (hook) penggunaan yang memuatkan semula servis tidak dijalankan. Oleh itu, tanya pelayan yang sedang berjalan tentang apa yang dihidangkannya, dari luar kotak.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Flag -servername menetapkan SNI (server name indication), yang diperlukan pada mana-mana alamat yang mengehoskan lebih daripada satu tapak, jika tidak, anda akan diberikan sijil lalai dan bukannya sijil anda. Jika certbot dipasang daripada snap, pemasa dinamakan secara berbeza, jadi padankan berdasarkan perkataan dan bukannya unit yang anda andaikan.

Ingat sijil yang tidak mempunyai automasi langsung: pelayan mel, VPN, pihak berkuasa sijil dalaman. Itu adalah sijil yang tamat tempoh pada hujung minggu, dan pelayar serta klien akan menolaknya secara terus dan bukannya memberi amaran.

Bulanan: pengguna, akses sudo dan kunci SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T mencetak konfigurasi berkesan selepas setiap Include digabungkan, iaitu konfigurasi yang sebenarnya akan digunakan oleh daemon. Imej Ubuntu terkini menyertakan fail drop-in dalam /etc/ssh/sshd_config.d/, dan fail tersebut boleh mengatasi fail utama, jadi membaca sshd_config sahaja boleh memberikan maklumat yang salah. Dalam keluarga RHEL, kumpulan pentadbiran ialah wheel dan bukannya sudo, jadi laraskan baris getent.

Kemudian, baca fail authorized_keys itu sendiri. Akses diberikan melalui kunci, bukan melalui akaun, jadi kunci yang ditinggalkan oleh kontraktor yang telah tamat tempoh enam bulan lalu merupakan log masuk yang aktif yang tidak akan dikesan oleh mana-mana senarai pengguna. Kunci mempunyai medan komen. Gunakannya, dan padamkan apa-apa yang anda tidak dapat kaitkan dengan seseorang.

Untuk sejarah log masuk, journalctl -t sshd --since "30 days ago" | grep -i accepted memadankan pengecam syslog dan bukannya nama unit. Ini penting kerana Ubuntu 24.04 mengaktifkan SSH melalui soket, jadi setiap sambungan direkodkan di bawah unit per-sambungan yang dijana, dan journalctl -u ssh biasa mungkin terlepas maklumat tersebut.

Bulanan: kernel lama dan /boot yang penuh

/boot sering kali merupakan partition berasingan dengan saiz beberapa ratus megabait pada imej VPS standard. Setiap kemas kini kernel akan menambah satu imej dan satu initramfs ke dalamnya. Apabila ia penuh, naik taraf seterusnya akan gagal di pertengahan jalan dan menyebabkan pakej tidak dikonfigurasikan, satu keadaan yang sukar untuk dihadapi secara mengejut pada hari Jumaat.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r dahulu, sentiasa: ia menamakan kernel yang sedang anda jalankan sekarang, dan kernel tersebut mesti dikekalkan walau apa pun yang anda buang. apt autoremove mengendalikan kes biasa pada Debian dan Ubuntu, memandangkan kernel ditandakan sebagai dipasang secara automatik dan kernel semasa dilindungi. Kes-kes luar biasa, seperti kernel yang dipasang secara manual atau /boot yang sudah terlalu penuh sehingga menyekat apt itu sendiri, diterangkan dalam membersihkan kernel lama pada Ubuntu.

Bulanan: pertumbuhan log dan jurnal systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug ialah larian percubaan dan tidak menulis apa-apa, jadi ia selamat digunakan pada pelayan yang sedang berjalan. Ia berbaloi untuk dijalankan kerana peraturan putaran (rotation) dipadankan berdasarkan laluan: aplikasi yang menukar lokasi log semasa naik taraf tidak lagi dilindungi oleh peraturannya sendiri, dan fail tersebut kini akan membesar tanpa had sehingga memenuhi cakera.

Jurnal dihadkan oleh systemd, tetapi mengikut pecahan sistem fail dan bukannya nombor yang anda pilih. Tetapkan SystemMaxUse= dalam /etc/systemd/journald.conf dan mulakan semula systemd-journald jika anda mahukan had maksimum yang khusus. sudo journalctl --vacuum-time=14d menuntut semula ruang dengan serta-merta, dan ia merupakan tindakan sekali sahaja dan bukannya polisi, jadi gabungkan ia dengan perubahan konfigurasi tersebut.

Setiap keluaran: but semula yang anda asyik tangguhkan

Pakej kernel yang dikemas kini pada cakera bukanlah kernel yang sedang berjalan. Sehingga but semula dilakukan, mesin masih menjalankan kernel lama, dan live patching, di mana ia tersedia, hanya meliputi sebahagian kecil daripada pembaikan.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Fail flag tersebut merupakan konvensyen Debian dan Ubuntu yang ditulis oleh skrip pakej. Sistem keluarga RHEL tidak menciptanya, dan soalan yang setara di sana dijawab oleh needs-restarting -r, yang datang daripada dnf-utils. needrestart, yang dipasang secara lalai pada imej pelayan Ubuntu terkini, menjawab tahap di bawah kernel: ia menyenaraikan proses yang masih memetakan pustaka yang telah digantikan pada cakera, itulah sebabnya OpenSSL yang telah ditampal tidak berkuat kuasa sehingga servis yang menggunakannya dimulakan semula.

Jadualkan but semula dan bukannya mengelakkannya. Dalam /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; dan Unattended-Upgrade::Automatic-Reboot-Time "03:00"; serahkan keputusan itu kepada masa yang anda pilih. But semula yang dirancang juga merupakan satu-satunya ujian sama ada kotak tersebut kembali hidup, kerana entri fstab yang rosak atau servis yang tidak pernah anda aktifkan akan menunjukkan dirinya semasa but dan bukan di tempat lain.

Setiap keluaran: merancang naik taraf pengedaran

Keluaran Ubuntu LTS membawa sokongan standard selama lima tahun dan keluaran interim membawa sembilan bulan, jadi pilihan anda menentukan beban kerja naik taraf untuk tahun-tahun mendatang. Pertukaran tersebut diterangkan dalam LTS berbanding keluaran interim pada pelayan.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade membaca fail tersebut, dan Prompt=lts mengehadkannya kepada peralihan LTS-ke-LTS. Laluan LTS-ke-LTS biasanya dibuka pada keluaran titik pertama versi baharu dan bukannya pada hari keluaran, jadi semak apa yang ditawarkan kepada mesin anda dan bukannya merancang berdasarkan tarikh yang anda andaikan. Mekanisme peralihan tersebut ada dalam naik taraf Ubuntu 24.04 ke 26.04.

Rancang margin selama tiga bulan. Ambil snapshot yang telah anda uji pemulihannya, senaraikan repositori apt pihak ketiga anda (naik taraf akan menyahdayakannya, dan setiap satu memerlukan sasaran baharu untuk keluaran baharu), dan tentukan pelan rollback sebelum anda bermula. Sehingga Ogos 2026, Ubuntu 24.04 LTS mempunyai sokongan standard sehingga April 2029, jadi ini adalah penjadualan dan bukannya kecemasan.

Perkara yang perlu diautomasikan dan perkara yang perlu dikekalkan secara manual

Automasikan keputusan yang telah anda buat: kemas kini keselamatan, penggiliran log, pembaharuan sijil dan tugasan sandaran. Automasikan juga sistem amaran, kerana pemeriksaan yang bergantung pada ingatan anda adalah pemeriksaan yang tidak akan berlaku pada pukul 2 pagi. Pemantau luaran, seperti pemantauan status layan diri dengan Uptime Kuma, mengesan satu perkara yang tidak dapat dilaporkan oleh skrip dalam pelayan, iaitu apabila pelayan itu sendiri tidak dapat dicapai.

Kekalkan dua perkara secara manual: ujian pemulihan dan audit akaun. Kedua-duanya memerlukan seseorang untuk menentukan sama ada hasilnya betul. Jika anda lebih suka membaca status mesin dalam pelayar berbanding terminal, Cockpit berbanding Webmin untuk pengurusan pelayan membandingkan dua konsol web yang biasa digunakan.

Automasi kemudiannya memerlukan semakannya sendiri, itulah sebabnya item mingguan pertama dalam senarai ini adalah mengesahkan pengemas kini. Automasi yang gagal secara senyap adalah lebih buruk daripada tiada automasi langsung, kerana ia menghilangkan kegagalan tersebut dan tabiat untuk memeriksanya pada masa yang sama.

Senarai semak lengkap di satu lokasi

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Berapa kerap saya perlu melakukan penyelenggaraan pelayan Linux?

Lakukan setiap minggu untuk perkara yang berubah secara automatik: status kemas kini, ruang cakera dan inode, unit yang gagal, serta sama ada tugasan sandaran telah selesai. Lakukan setiap bulan untuk kerosakan perlahan: ujian pemulihan, tamat tempoh sijil, audit akaun dan kunci SSH, kernel lama, serta pertumbuhan log. Lakukan sekali bagi setiap keluaran pengedaran untuk naik taraf versi dan but semula ke dalam kernel semasa. Pemeriksaan mingguan hanya mengambil masa beberapa minit pada pelayan yang sihat; itulah sebabnya ia perlu dilakukan setiap minggu dan bukannya menunggu sehingga sesuatu kelihatan tidak kena.

Mengapa perlu menguji pemulihan jika tugasan sandaran melaporkan kejayaan?

Kerana tugasan tersebut melaporkan status keluarannya sendiri, dan status itu boleh menjadi benar walaupun arkib tersebut tidak berguna. Fail dump yang disalurkan ke dalam pemampat tanpa set -o pipefail akan mengembalikan status pemampat tersebut, jadi dump yang gagal dan hanya menghasilkan mesej ralat masih akan keluar dengan kod sifar serta menulis fail yang kecil. Lakukan pemulihan ke mesin yang berbeza, buka data tersebut, dan buat pengiraan. Ujian pemulihan juga mengukur masa, dan tempoh tersebut merupakan masa pemulihan sebenar anda.

Adakah saya perlu but semula selepas setiap kemas kini kernel?

Anda perlu but semula sebelum kernel baharu menjadi kernel yang sedang berjalan. Pada Debian dan Ubuntu, kehadiran /var/run/reboot-required menunjukkan bahawa pakej telah memintanya, dan /var/run/reboot-required.pkgs menyatakan pakej yang mana. Dalam keluarga RHEL, fail tersebut tidak wujud, dan needs-restarting -r daripada dnf-utils menjawab soalan yang sama. Tetapkan tetingkap but semula automatik dalam /etc/apt/apt.conf.d/50unattended-upgrades dan bukannya menangguhkannya selama-lamanya, kerana mesin yang tidak but semula selama setahun mempunyai laluan but yang tidak diuji serta kernel yang lama.

Pemeriksaan yang manakah boleh saya automasikan dengan selamat?

Automasikan tindakan yang keputusannya telah pun dibuat: kemas kini keselamatan, putaran log, pembaharuan sijil, dan sandaran berjadual. Automasikan juga pemberitahuan supaya unit yang gagal atau cakera yang hampir penuh sampai kepada anda tanpa perlu seseorang menjalankan arahan. Pastikan ujian pemulihan dan audit kunci dilakukan secara manual, kerana setiap satunya memerlukan seseorang untuk menilai sama ada hasilnya betul. Kemudian, tambahkan satu pemeriksaan pada automasi itu sendiri, kerana kegagalan pengemaskini yang senyap kelihatan sama seperti sistem yang berfungsi dengan baik.