Apakah skrip up OpenVPN berjalan terlalu awal, atau tidak pernah siap?

Skrip up berjalan, keluar dengan nol, dan tugas di dalamnya gagal menjangkau layanan privat yang dua detik kemudian berfungsi sempurna dari terminal. Naluri pertama adalah waktu, dan perbaikan biasanya adalah tidur, yang menyembunyikan perlombaan tanpa memahaminya. Bacaan yang lebih berguna adalah bahwa “up” menamai sebuah hook, bukan jaminan kesiapan. Ia menyala saat perangkat terowongan dikonfigurasi, yang lebih awal daripada rute, DNS, dan tentu lebih awal daripada aplikasi apa pun di balik terowongan.

Uji shell berhasil karena dijalankan setelah semuanya stabil. Hook berjalan pada satu momen tertentu.

Di mana up berada dalam urutan startup

OpenVPN mengonfigurasi perangkat terowongan lalu menjalankan hook up. Pemasangan rute adalah tahap berikutnya, dan ia punya hook sendiri, karena itu tugas yang bergantung pada rute yang ditempatkan di up bisa melihat perangkat tanpa jalur yang berguna. Letakkan pekerjaan rute di route-up dan masalah waktu biasanya hilang.

Manual mendokumentasikan urutan ini dan lingkungan yang diterima setiap hook. Urutan itu adalah seluruh penjelasan laporan klasik “berfungsi dari shell saya”, dan itu juga sebabnya skrip yang sama bisa lolos di satu mesin dan gagal di mesin lain dengan tahap rute yang lebih lambat. Tidak ada satu pun hasil yang mengatakan apa pun tentang kualitas skrip.

Kesiapan DNS dan aplikasi datang lebih lambat lagi. Bahkan rute yang terpasang bukan bukti bahwa ujung jauh mendengarkan, bahwa nama terurai, atau bahwa ada sesi desktop untuk tugas yang dibatasi pengguna.

Apa yang sebenarnya diwarisi hook

Hook berjalan di bawah akun dan lingkungan proses OpenVPN, yang tidak sama dengan shell interaktif Anda. Ia mungkin kekurangan bus sesi pengguna, lingkungan desktop, atau kredensial yang hanya terbuka saat login. Catat mana dari itu yang benar-benar dibutuhkan tugas.

Itu penting untuk tugas yang tampak seperti jaringan tetapi bergantung pada konteks pengguna: memasang berbagi pakai dengan kredensial pengguna, mengatur proksi per pengguna, atau mengonfigurasi printer. Hook terowongan dengan hak istimewa adalah tempat yang salah untuk itu, dan tidak ada jumlah penantian yang memperbaiki sesi yang hilang.

Saat tugas gagal di hook, catat akun, lingkungan, dan operasi pertama yang gagal. Itu memisahkan waktu yang terlalu dini dari masalah izin atau konteks, dan keduanya punya perbaikan yang sama sekali berbeda. Menebak di antara keduanya adalah bagaimana perbaikan lima menit menjadi sepanjang sore.

Mengapa menambahkan tidur bukan pemeriksaan kesiapan

Tidur menunda skrip dan menggeser jendela perlombaan. Pada hari cepat tugas berhasil; pada hari lambat ia gagal lagi, dan kegagalan menjadi lebih sulit direproduksi karena penundaan tampak berhasil. Penundaan yang hanya berhasil di bawah beban ringan adalah kebetulan, bukan perbaikan.

Jika ketergantungan adalah rute, gunakan hook yang sesuai dengan pemasangan rute. Jika ketergantungan adalah layanan di balik terowongan, gunakan pemeriksaan terbatas yang menunggu kondisi spesifik itu dan gagal dengan jelas saat tidak pernah datang.

Jaga kegagalan tetap eksplisit. Hook yang keluar dengan nol sementara pekerjaan sebenarnya gagal lebih buruk daripada hook yang gagal, karena manajer layanan mencatat sukses dan tidak ada yang melihat lagi. Satu baris log dari skrip itu sendiri adalah cara termurah untuk menjaganya jujur.

Pembersihan dan penyambungan ulang layak mendapat perhatian yang sama

Skrip yang mengubah keadaan bersama membutuhkan jalur pembatalan yang sesuai. Rute, entri resolver, dan tanda firewall yang ditambahkan hook harus idempoten dan dapat dibalik, atau penyambungan ulang akan menumpuk salinan kedua di atas yang pertama.

Penyambungan ulang juga dapat menjalankan hook lebih sering daripada start layanan penuh. Antarmuka persisten yang membangun kembali sesi dapat memicu siklus up dan route-up lagi, sehingga skrip yang mengasumsikan satu eksekusi per boot pada akhirnya akan salah berperilaku. Hitung eksekusi di log selama sehari flapping untuk melihat seberapa sering ia benar-benar berjalan. Lalu buat skrip aman untuk berjalan sebanyak itu.

Uji siklus hidup yang gagal, bukan perintah yang lebih akhir. Reproduksi boot atau penyambungan ulang, amati hook berjalan, dan pastikan tugas berhasil pada saat ia benar-benar berjalan. Keberhasilan dari shell interaktif setelahnya adalah bukti tentang ketergantungan, bukan bukti bahwa jalur startup berfungsi.

Namai peristiwa yang menjadi tempat bergantung setiap tugas, lalu kaitkan tugas itu ke peristiwa tersebut. Segala hal lain adalah penundaan yang berpura-pura menjadi pemeriksaan.