Menambal dan memperbarui sistem adalah langkah kunci dalam mengurangi kemungkinan vektor serangan terhadap infrastruktur Anda. Ketika ada sistem di lingkungan Anda yang tidak up to date dengan patch, mungkin ada vektor serangan yang tidak Anda ketahui berpotensi mempengaruhi seluruh organisasi Anda. Namun, langkah-langkah apa yang Anda miliki ketika acara tambalan tidak berjalan seperti yang diharapkan?
[ Pembaca juga menyukai: Mengamankan sistem Linux yang diwariskan ]
Misalnya, dependensi mungkin tidak terpenuhi, mungkin ada versi yang tidak cocok pada RPM i686 dan x86_64, versi paket baru mungkin tidak berfungsi seperti yang diharapkan, atau ada yang tidak beres. Ketika terjadi kesalahan, penting untuk memiliki rencana tentang bagaimana melanjutkannya. Ini akan mengurangi tingkat stres dan memastikan bahwa semua orang yang mengerjakan tugas mengetahui apa yang dilakukan orang lain.
Tambalan uji
Saat menambal, penting untuk menguji tambalan terlebih dahulu di lingkungan pengujian yang cocok dengan lingkungan produksi your Anda . Jika Anda menguji patch pada perangkat keras yang berbeda, dengan versi perangkat lunak yang berbeda, atau dengan beban kerja atau proses yang berbeda dari lingkungan produksi Anda, tidak ada jaminan bahwa hasil pengujian patch akan mencerminkan apa yang akan terjadi dalam produksi. Setelah Anda memiliki lingkungan pengujian tempat Anda dapat memverifikasi bahwa bundel tambalan tertentu harus diinstal, Anda akan sangat mengurangi kemungkinan masalah saat menginstal pembaruan.
Tambalan gagal
Jika pembaruan gagal dipasang, hal pertama yang harus dilakukan adalah menangkap keluaran apa pun di konsol atau di log. Ini mungkin hanya menyalin file log ke lokasi terpisah, atau bisa juga menyalin teks yang ditampilkan di layar konsol. Bergantung pada bagaimana penambalan dicoba, Anda mungkin ingin mencoba menjalankan kembali pembaruan, kali ini dengan keluaran verbose diaktifkan. Setelah Anda memiliki output kesalahan, Anda akan ingin melihat perbedaan antara lingkungan pengujian Anda versus apa yang Anda miliki dalam produksi. Anda juga perlu memverifikasi semua tambalan diterapkan dalam pengujian dan tidak ada tambalan atau kesalahan yang terlewatkan secara tidak sengaja. Satu item penting yang harus diperiksa adalah daftar RPM yang terpasang di server pengujian Anda untuk dibandingkan dengan versi di server produksi Anda.
Misalnya, di server produksi:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Anda kemudian dapat membandingkannya dengan output yang dikumpulkan di server pengujian Anda di /tmp/rpm-qa.dev.output.txt .
Anda juga harus memeriksa untuk memastikan bahwa yum . yang tersedia repositori sama di kedua sistem. Anda dapat melakukannya dalam tiga langkah sederhana.
Pertama, bersihkan cache:
# yum clean all
# rm /var/cache/yum/* -rf Selanjutnya, segarkan pengelola langganan:
# subscription-manager refresh
Ketiga, daftarkan repositori di yum dengan -v argumen sehingga Anda dapat melihat informasi tambahan seperti repodate dan jumlah paket dalam repositori:
# yum repolist -v Dalam contoh berikut, kita akan melihat rhel-8-for-x86_64-appstream-rpms repositori yang digunakan oleh klien ke server Red Hat Satellite saya:
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Baris kunci di sini adalah repo-id , diperbarui ulang , repo-pkgs , dan repo-baseurl . Jika pengujian dan sistem produksi saya menunjukkan informasi yang berbeda untuk repositori upstream mereka, maka ada kemungkinan bahwa dependensi mungkin tidak terpenuhi atau sesuatu yang lain mungkin gagal. Jika demikian, Anda perlu menyelidiki mengapa sistem melihat informasi yang berbeda.
Setelan lainnya
Misalkan sistem pengujian dan produksi memiliki RPM yang diharapkan dan repositori yang sama, tetapi patching masih gagal. Dalam hal ini, kemungkinan penyebab lainnya adalah pengaturan keamanan yang salah diterapkan, ruang disk yang rendah, atau mungkin izin pengguna yang salah. Untuk menyelidikinya, periksa log seperti /var/log/messages , /var/log/secure , dan /var/log/audit/audit.log mungkin bisa membantu, serta menggunakan perintah df -h untuk memeriksa ruang disk. Selain itu, pelanggan Red Hat dipersilakan untuk membuka tiket dukungan untuk bantuan dalam menyelesaikan masalah.
[ Kursus online gratis:Tinjauan teknis Red Hat Enterprise Linux. ]
Menutup
Ada banyak kemungkinan penyebab patch yang gagal dipasang dengan benar, tetapi kemampuan untuk membandingkan lingkungan pengujian Anda dengan lingkungan produksi Anda akan membuat pemecahan masalah menjadi lebih mudah. Konfigurasi, dependensi, beban kerja, dan repositori semua harus sama di kedua lingkungan.