Teks

Dua Mesin, Satu Utas

Ditulis oleh Gustama Dimas

Saya punya dua mesin yang penting.

msi-server yang lebih baru — MSI Cubi 5 kecil yang menjalankan Ubuntu Server, dan kotak tempat gateway asisten saya tinggal. .185 adalah desktop lama, masih bekerja berguna, masih menyimpan beberapa hal yang belum saya migrasikan.

Untuk waktu yang lama satu-satunya saluran antara keduanya adalah saya sendiri. Saya melihat sesuatu di satu mesin, berjalan ke mesin lain, dan mengetik ulang. Itu berjalan baik sampai tidak.

Jadi saya membangun relay. Bukan yang pintar — dua pipa satu arah.

Pipa satu: .185 → saya

Skrip kecil di .185 mengirim pesan ke endpoint HTTPS di gateway. Terautentikasi token, dibatasi ke satu agen, dan dikirim ke ponsel saya dengan label 📡 .185 supaya saya selalu tahu mesin mana yang sedang bicara.

Bagian pentingnya adalah apa yang tidak dilakukannya. Tidak ada apa pun di .185 yang mendengarkan koneksi masuk untuk ini. Mesin itu hanya membuat permintaan keluar. Tidak ada port baru, tidak ada permukaan serangan baru.

Pipa dua: saya → .185

Ini bagian yang menarik, karena desain yang jelas terlihat benar justru salah.

Pendekatan cermin adalah endpoint HTTP di .185 yang saya kirimi permintaan. Saya menolaknya. Mesin itu punya sejarah: proses gateway yang kadang menggantung, dan basis data agen yang sudah cukup besar untuk melampaui jendela konteksnya saat kerja nyata. Menambahkan permukaan masuk yang selalu mendengarkan ke kotak dengan sifat seperti itu adalah cara Anda berakhir dengan layanan yang mati pukul 3 pagi tanpa jejak kenapa.

Sebagai gantinya saya memakai ulang sesuatu yang sudah dipercaya dan sudah teruji: SSH.

Alurnya satu perintah:

  1. Saya memutuskan mengirim sesuatu ke .185
  2. Skrip di msi-server membuka koneksi SSH
  3. Ia menjalankan CLI agen di sana terhadap session key yang tetap
  4. Balasan agen kembali lewat stdout
  5. Saya teruskan ke utas obrolan

Satu perjalanan pulang-pergi. Tidak ada port baru yang terbuka di mana pun.

Bentuknya saat berhasil

Empat tes, semuanya end to end:

transport smoke     → PONG-185-FASE2
simple message      → FASE2-V2-OK
tool use on .185    → returned hostname, uptime, version
final               → FASE2-FINAL-OK

Yang ketiga yang paling penting. Ia tidak hanya membuktikan pipa bisa membawa teks — ia membuktikan bahwa permintaan yang berasal dari satu mesin bisa mencapai mesin lain, menyebabkan mesin itu menjalankan perintah shell di sana, dan membawa keluaran aslinya kembali. Itu bedanya notifikasi dengan kendali jarak jauh.

Batasannya, dinyatakan jujur

Relay ini sinkron. Permintaan menunggu balasan, dan timeout-nya 300 detik secara default. Untuk obrolan dan kueri pendek itu cukup lega. Untuk apa pun yang berat — build sepuluh menit, tugas coding panjang — ia akan timeout, dan pekerjaannya jadi yatim.

Perbaikannya adalah varian async: tembak permintaan, dapat konfirmasi, kirim hasilnya saat siap. Saya belum membangunnya, karena belum ada yang membutuhkannya. Menulisnya sekarang berarti menulis kode untuk masalah yang belum saya punya.

Yang saya ambil dari ini

Antarmuka terbaik antara dua mesin biasanya yang sudah ada di sana.

SSH sudah dipercaya, sudah berkunci, sudah dipahami. Endpoint HTTP akan lebih modern dan kurang andal. Pertanyaannya bukan "apa cara yang benar untuk melakukan ini" — tapi "apa hal baru terkecil yang bisa saya tambahkan supaya ini bekerja."

Di sini jawabannya ternyata: tidak ada, di sisi penerima. Hanya skrip dan kunci yang sudah ada.