Bofcana Teknologi UUCP

Pendahuluan

Berikut ini merupakan BOFCANA perihal teknologi UUCP. Bofcana merupakan kombinasi antara Bird Of a Feather dan Wacana. Hasil akhir diharapkan berupa rekomendasi TETE (Tertulis dan Terbuka). Tulisan ini merupakan hasil cut and paste dari beberapa milis; sehingga bukan sepenuhnya merupakan karya dari editor.

Tak kenal, maka tak sayang; kalau sudah kenal, maka jadi benci: "Seberapa dalam kita sebetulnya mengenal teknologi UUCP ini?" Apakah pembahasan berikut ini berdasarkan "DATA" dan pengalaman sendiri, ataukah hanya berdasarkan "katanya" yang tidak jelas asal usul informasinya? Pembahasan UUCP ini dapat saja berdasarkan FANTASI, seperti halnya yang biasa dilakukan oleh yang terhormat para pakar selebritis kita. Atau pun bisa berdasarkan INFORMASI yang berasal dari Data, Communications, dan Knowledge. Pendekatan kedua ini masih sangat kurang lazim di Indonesia.

UUCP (Unix to Unix Copy) merupakan sebuah keluarga protokol untuk menyalin berkas dari satu mesin ke mesin lainnya. Anggota keluarga UUCP ini termasuk program "UUCICO" (Unix to Unix Copy In Copy Out) yang bertugas memindahkan berkas antar komputer yang berbeda. Sistem UUCP ini memiliki beberapa keunggulan yang boleh diadu dengan teknologi lainnya:

Universitas Indonesia pernah memanfaatkan teknologi tersebut -- operasional 24 jam sehari, 7 hari seminggu -- selama bertahun-tahun sejak 1986. Selain itu, memang ada selebritis yang mengaku pernah menjalankan sistem email di tahun 1980-an; namun sebagian besar merupakan sistem demo yang dioperasikan secara insidensial.

Bahkan ditahun 1990-an yang lalu, UI tetap memanfaatkan teknologi UUCP untuk link Salemba - Depok. Secara teknis, transfer email Salemba Depok dengan uucp:

Potensi Pasar

Pilihan apa saja yang dapat dilaksanakan, jika tinggal di sebuah negara yang nyata-nyata merupakan "a hopeless piece of sh*t"?? Pilihan yang paling mudah ialah dengan hengkang, lalu memilih "padang rumput yang lebih hijau" dekat saluran OC-192, dan berbahagia happily ever after. Pilihan alternatif, umpamanya tetap bertahan dengan memikirkan cara mengoptimasi semua teknologi yang ada. Teknologi UUCP ini masih memiliki daya pikat yang cukup untuk:

Sebaliknya, perlu dipertimbangkan matang-matang; apakah masih belum terlambat, jika memulai pengkajian baru setelah awal abad 21 ini? Selain itu, yang berkenaan dengan marketing UUCP ada 2 issue, yaitu;

Dukungan, Dukungan, dan Dukungan

Teknologi UUCP ini cukup realistik. Namun besar kemungkinan, proyek UUCP ini hanya akan berakhir di Bofcana ini. Dibutuhkan sekurangnya 4 aktivis dengan waktu luang yang cukup, plus sekitar 12 penggembira agar proyek ini dapat direalisasikan.

Langkah pertama kegiatan proyek ini ialah menghimpun dan mengkemas program-program yang terkait dengan UUCP tersebut. Perlu ada petunjuk praktis "langkah demi langkah" untuk menginstallnya. Dan yang penting, "user agent" sebaiknya perangkat lunak yang biasa digunakan, umpama Netscape, atau Pegasus Mail. Para user tidak boleh direpotkan dengan kerumitan teknologi UUCP tersebut.

Paralel dengan langkah tersebut ialah menyusun strategi marketing usaha (minimum) nirlaba. Target utama ialah LSM di daerah, agar mereka ikut berpartisipasi memberdayakan masyarakat dengan teknologi murah ini. Jika, target potensial ialah instansi pemerintah yang sekarang ini masih "satu yahoo mail rame-rame".

Masalah hosting merupakan hal penting, namun tidak genting. Tentu saja, langkah ini tidak dapat diabaikan; namun pelaksanaannya dapat ditunda.

Yang perlu disiapkan ialah set disket "plug and play"; dan langsung "boom" (jadi inget disketnya Dialix ). Mungkin juga bisa memanfaatkan paket UUCP. MUA bisa pakai pegasus dengan (tidak harus) atau tanpa taxis School Networking. Yang ini bahkan pernah coba via dial-up line, lagi-lagi dari mesin sendiri.

Orang nggak paham UUCP, SMTP juga bisa langsung pakai.. padahal di dalamnya pakai UUCP, NNTP dan mbuh apa lagi.. dengan tools MTA seperti rmail atau rsmtp (untuk batched/half-baked smtp).

Tindak Lanjut

Jika persyaratan 4/12 dipenuhi, bisa dilanjutkan dengan membuat pokja UUCP dan milisnya. Tentunya, setelah itu, bukan lagi menjadi wacana milis DICK dan MDGR. Secara teknis, UUCP lewat TCP udah kelar tuh. dialin-nya sebentar lagi akan dipasang modem.

Hal ini dapat menarik, jika beginian dapat menggantikan peranan maildrop atawa serialmail atawa mdaemon yang memusingkan. Akan tetapi sungguh menggetarkan jiwa jikalau ada program dari dua sisi (client/server) yg sudah langsung bisa jalanken fungsi tsb out of the box.

Katanya MD@MT, mari kita bikin aja deh kalo ga ada dan bila ada waktu yangg luang dan mungkin akan ikut daftar di list oknum2 yg terlibat deh. Yang bikin semangat mau ikutan jadi oknum proyek ini. Kerasa kalau si klien langganan isp yang routingnya sering main dampu (loncat2) sdgkan mailboxnya ada di tempat yang agak lelet, lalu ditimpa tangga berupa kiriman kado SirCam. koneksi putus, reconnect lagi, nge-POP lagi, tengah2 putus lagi ulang lagi. sungguh bikin pusingpala

Asal jangan disuruh nulis, kemungkinan besar ada punya tenaga untuk 'proyek' ini. OK, tulis-menulis menjadi urusan vLSM.org :-).

Untuk uucp via ssl. Ada yang sudah berencana memberikan service ini. Bila ada yang berminat mengetahui bisa via japri.

UUCP sempat "ditawarkan" dibeberapa wilayah luar Jakarta. Tapi, yang didapatkan justru pertanyaan: "uucp bisa dipakai buat browsing gak?"

Apakah UUCP dapat dibisniskan? Apakah perlu milis khusus? Atau untuk sementara cukup menggunakan MDGR? Yang perlu dibahas diantaranya:

Teknologi Alternatif

Sebagian besar bagian ini ditulis oleh P.Y. Adi Prasaja dan Haydin Syafrudin.

Teknologi tepat guna alternatif UUCP, untuk sesuatu yang mungkin bisa disebut "Email Perintis", yang punya ciri:

Seberapa jauh, MX + SMTP ETRN dapat menggantikan UUCP? SMTP + ETRN jalan disembarang TCP/IP, jadi jalan bisa di atas Dial-Up PPP atau Dial-Up SLIP, cuma saya belum seberapa kalah hemat dibanding UUCICO via Dial-Up langsung. Perlu dihitung berapa overhead header PPP + header SMTP dibanding "header" / control file-nya UUCICO.

ETRN bisa menggantikan UUCP bila, client (server lembaga) selalu mendapat ip statik (syarat ini *penting*). Dan ini berarti *tidak* bisa berpindah-pindah ISP. Dan sejauh masih 'speak SMTP' belum ada implementasi compression on the fly seperti yang bisa dilakukan via uucp.

ETRN menyaratkan ip static. Justru ini kelebihan transfer mail dengan UUCP (via tcp/ip), karena yang perlu memiliki ip static hanyalah 'server'. Penantang kuat metode trasnfer mail via uucp (alternatif) adalah ESMTP ATRN/ODMR. Yang sampai saat ini pun jarang dipakai orang.

Dalam soal keluwesan antrian, antrian SMTP pada dasarnya juga bisa kita miripkan seperti antrian UUCP, yaitu dibagi ke beberapa direktori menurut ke host mana antrian tersebut akan dikirim (belum tentu ini alamat akhir), tergantung kepada MTA yang digunakan. Saya kira untuk postfix ini bisa dilakukan dengan relatif mudah. Namun memang perlu diuji apakah mungkin misalnya antrian tadi untuk jalur A kita pindahkan ke jalur B, hal yang sudah teruji di UUCP.

By design, SMTP *tidak* mengimplementasikan per host/domain queue directories. Setidaknya dari implementasi yang ada (sendmail, zmailer, smail, exim, qmail, postfix, mmdf), tidak melakukan queue per destination/hostname/domain. Adanya queue directory semata-mata sebagai jaminan bahwa mail sudah safe sebelum smtp receiver announce OK ke smtp sender.

Memindahkan queue dir di postfix tidak mungkin. Hal ini hanya mungkin dilakukan pada qmail, bukan pada queue directory per se (tentu, karena nama disesuaikan dengan inode), tapi bisa pakai serial mail. Tapi implementasi AutoTURN+serialmail ini tidak jauh berbeda dengan ETRN dalam soal syarat yaitu: perlu ip statik.

Mestinya, sendmail dan exim lebih 'mudah' dipindahkan. Tentunya tidak dengan, misalnya 'cp' atau 'mv' karena ini memungkinkan terjadinya colliosion ID (mail bisa hilang).

Barangkali yang mau dipindahkan adalah spool mail yang sudah merupakan proses deliver *terakhir* (sebelum dibaca langsung oleh MUA atau melalui POP3/IMAP atau yang lain). Biar tidak capek merevisi, ETRN lebih tepat diganti ATRN/ODMR. (ATRN = authenticated TURN, ODMR = On Demand Mail Relay).

Tabemakasih

Bung P.Y. Adi Prasaja memulai membahas bofcana ini di milis DICK (Data Information Communications Knowledge) pada tanggal 5 Agustus 2001. Selanjutnya, didiskusikan di milis MDGR (Masyarakat Digital Gotong Royong). Sebetulnya, tulisan ini merupakan rangkuman hasil pengeroyokan dari oknum-oknum berikut ini: Abdullah Koro, Abdul Latip, Haydin Syafrudin, I Made Wiryana, Judhi Prasetyo, Louis Larry, MD@MT, Muhamad Carlos Patriawan, P.Y. Adi Prasaja, Rahmat M. Samik-Ibrahim, Wahyu Kelik Cahyadi, terimakasih yang mana dari pada, yang lainnya yang nggak sengaja belum kesebut.

Referensi:

<<<PREV | ^^TOP^^ | NEXT>>>

MILIS