sudo, &, -b atau --daemon: cara meletakkan klien OpenVPN di latar belakang

Frasa ‘jalankannya di latar belakang’ menyembunyikan dua soalan. Yang pertama ialah sama ada pengguna ini boleh memulakan proses istimewa sama sekali; yang kedua ialah sama ada sesi boleh diteruskan tanpa sesiapa menaip dalam terminal. Ampersand shell tidak menjawab kedua-duanya, dan skrip yang menyimpan kata laluan sudo dalam pemboleh ubah menjawab yang pertama dengan buruk sambil membiarkan yang kedua tidak tersentuh. Pisahkan kedua-duanya dan pilihan menjadi mudah dibandingkan.

Bandingkan ketiga-tiga calon dari segi pemilikan, bukan kemudahan.

Tiga cara meninggalkan terminal, tiga pemilik berbeza

Menambah ampersand pada arahan meminta shell menjalankannya sebagai tugas latar belakang, dan tugas itu masih milik shell tersebut. sudo mungkin bertanya sebelum program bermula, dan OpenVPN mungkin bertanya selepas itu untuk frasa laluan kunci atau log masuk. Meletakkan arahan yang menunggu input di latar belakang menghasilkan proses yang menunggu terminal yang tiada siapa memerhati. Terminal dibebaskan; interaksi tidak.

Itulah pilihan paling murah dan yang gagal paling mengelirukan, kerana prompt muncul di tempat yang telah ditinggalkan pengendali.

sudo -b bukan pengendali kelayakan

sudo -b menjalankan arahan di latar belakang dari sudut pandangan sudo sendiri, yang kedengaran seperti ciri yang hilang dan sebenarnya bukan. Menurut manual sudo, arahan interaktif biasanya berkelakuan buruk dalam mod itu, dan kawalan tugas shell tidak dapat mengurus proses yang diciptanya. Ia memindahkan proses tanpa memberinya cara menjawab soalan. Tiada apa-apa di dalamnya yang menyediakan frasa laluan kunci peribadi atau log masuk gerbang.

Jika sambungan memerlukan interaksi, penyelesaiannya ialah susunan pengesahan bukan interaktif yang disokong, bukan cara lain untuk melancarkan prompt yang sama.

--daemon mengubah program, bukan log masuk

--daemon meminta OpenVPN sendiri melepaskan diri selepas permulaan. Manual versi 2.6 menyatakan bahawa pengubahsuaian syslog berlaku semasa pilihan dihuraikan, walaupun pelepasan berlaku kemudian, jadi mesej boleh berhenti muncul di terminal lebih awal daripada dijangka. Kesunyian selepas titik itu tidak membuktikan apa-apa tentang terowong. Tambah --log atau --log-append yang eksplisit supaya output mendarat di tempat yang boleh anda baca.

Mod daemon juga membuang konsol secara kekal. Kunci peribadi yang dilindungi memerlukan askpass dalam mod itu, dan kelayakan yang dimasukkan dari konsol digabungkan dengan pilihan cache boleh meninggalkan pengesahan semula kemudian tanpa tempat untuk bertanya. Semak model pengesahan terhadap versi yang dipasang sebelum menganggap permulaan latar belakang akan bertahan melalui pembaharuan kunci pertamanya.

Apa yang dibeli pengesahan sudo dan apa yang tidak

sudo -v mengesahkan atau menyegarkan kelayakan tempatan yang di-cache, melakukan pengesahan jika dasar memerlukannya. Ia tidak memulakan OpenVPN, tidak mengesahkan dengan gerbang dan tidak menjamin arahan kemudian dalam skrip dibenarkan. sudo -n bermaksud sebaliknya: jangan bertanya, gagal. Itu menjadikan kegagalan kebenaran tempatan eksplisit, yang berguna, dan ia tidak mengatakan apa-apa tentang apa yang OpenVPN akan minta kemudian.

Tiada satu pun pilihan itu menjadi sebab memberi arahan tanpa kata laluan kepada semua orang atau menyalurkan kata laluan pentadbir ke dalam skrip.

Utamakan pemilik yang boleh diperhatikan

Untuk terowong milik mesin, gunakan instans perkhidmatan yang disokong oleh distribusi. Pemilik sedemikian menyediakan mula, henti, status dan log, dan ia bertahan selepas sesi anda tamat. Menggabungkan latar belakang shell, pendemonan dan gelung mula semula antara satu sama lain mencipta tiga pemilik untuk satu terowong dan tiada jawapan jelas yang mana sedang berjalan.

Apa pun yang anda pilih, sahkan sumber yang terowong itu wujud untuknya. Permintaan mula yang berjaya ialah peristiwa proses, bukan bukti sambungan yang berfungsi.