Untuk materi slide lainnya akan coba saya upload secara bertahap dalam kesempatan berikutnya.

Saya memerlukan waktu beberapa hari menyesuaikan materi presentasi agar selaras dengan keseluruhan tema, merapikan screenshot, mengarang note untuk setiap slide yang disampaikan dan melakukan ujicoba presentasi apakah waktunya terlewat atau tidak, apakah ada yang kurang jelas dan apakah ada informasi yang perlu diperbaiki.

Sebelum membangun Excellent, saya bekerja sebagai staff IT di perusahaan. Ada beberapa mindset yang saat itu saya pegang namun setelah sekian waktu, saya melihat bahwa mindset tersebut perlu disesuaikan.

Misalnya yang pertama soal Good Admin is Everything. Ada pemikiran bahwa Admin yang bagus adalah Admin yang bisa segalanya. Timbul kesan, jika pekerjaan diserahkan pada vendor, lantas apa fungsi kita sebagai team IT.

Padahal ukurannya adalah keberhasilan implementasi. Pada result atau hasil akhir. Jika kita memiliki berbagai pengetahuan teknis tapi hasil akhir ternyata tidak berjalan sesuai harapan, tetap saja kita dianggap sebagai team IT yang gagal. Perlu diingat, vendor itu adalah partner, bukan musuh. Akan jauh lebih baik jika kerjasama yang terjalin memberikan dorongan pada kelancaran proses implementasi. Kita sebagai team internal bisa banyak belajar, menambah pengetahuan sekaligus bisa fokus pada aspek monitoring dan supervisi.

Ada kalimat, “Serahkan suatu pekerjaan pada ahlinya, jadi jika hendak melakukan implementasi Zimbra dan merasa ada banyak hal yang harus dilakukan dan khawatir tidak kuat, biar Excellent saja yang melakukannya . Nanti prestasi implementasi tetap merupakan prestasi team IT yang mampu menjamin keberhasilan berjalannya pekerjaan, bukan prestasi vendor seperti Excellent.

Yang kedua mengenai Budget. “Jika menggunakan Zimbra Network Edition, berarti harus keluar biaya?” Iya, karena memang ada kebutuhan biaya lisensi.

“Wah kalau keluar biaya, sayang dong, kan pakai open source juga bisa”.

Benar bisa, tapi apakah sesuai dengan kebutuhan perusahaan?

Tidak semua pengeluaran uang itu pemborosan. Investment worth the risk. Jika kita tidak keluar biaya sama sekali tapi data email hilang atau perusahaan terkena penipuan hingga rugi ratusan juta atau miliaran rupiah; tender gagal terkirim karena informasinya terhambat di komunikasi email; itu namanya bukan cerdas melainkan celaka. Siapa yang salah? Ya kita sebagai IT yang merasa uang yang dikeluarkan adalah uang milik pribadi.

Jadi, serba berhemat untuk segala hal tidak selalu benar. Melakukan pengeluaran biaya untuk budget keperluan tertentu juga tidak selalu salah. Yang salah itu jika mengeluarkan uang bukan untuk keperluannya. Jika pengeluaran uang untuk kebaikan perusahaan dan untuk mendukung kelancaran operasional perusahaan, itu justru prestasi, karena bisa mencegah kerugian dan meningkatkan peluang keberhasilan.

Yang terakhir soal mindset, “Perusahaan belum butuh karena atasan atau pimpinan atau user juga belum minta”. Sebagai IT kita seharusnya one step ahead. Satu langkah didepan. Jika perlu 10 langkah didepan. Sebelum pimpinan atau atasan minta, kita sudah melakukan riset. Sudah ada usaha. Jangan seperti paku, saat digetok baru berjalan.

Bisa jadi pimpinan belum minta karena belum tahu atau belum terbayang pentingnya feature tersebut.

Misalnya, “buat apa pakai digital signature?”. Oh itu penting untuk memastikan identitas rekanan yang berkomunikasi dan mencegah pemalsuan identitas.

“Mengapa pakai 2 factor?”, agar email account lebih aman.

“Mengapa pakai delegated admin?”, supaya ada pembagian wewenang yang jelas. 

Jika kita mau berusaha memperbaiki diri dan kualitas, nanti ada perbedaan. Ada jarak dari kondisi sebelumnya. Berbeda jika kita statis dan menikmati keamanan semu, nanti baru sadar saat sudah terlambat atau saat pimpinan tahu dari pihak lain.

Pihak klien berlangganan paket layanan SMTP Relay Excellent. Layanan ini berfungsi sebagai relay server, yang akan meneruskan email dari server klien ke tujuan.

Berdasarkan pesan error tersebut, team Excellent menginformasikan bahwa email di tujuan tidak ada (unavailable) dan pihak klien bisa menginformasikannya pada pihak rekanan.

Pihak klien bersikukuh bahwa email di tujuan ada dan baik-baik saja, karena jika dikirim via Gmail, emailnya bisa diterima. Atas dasar itu, saya membantu team support untuk melakukan investigasi lebih jauh dan meminta izin pada pihak klien untuk melakukan simulasi dan test ke tujuan email yang dimaksud.

MENGECEK MX RECORDS
Langkah pertama yang saya lakukan adalah mencoba mengirimkan email via telnet. Jika menggunakan CLI, favorit saya adalah menggunakan telnet dan menggunakan aplikasi swaks. Untuk tahap awal saya menggunakan telnet karena sifatnya masih diagnosa.

Untuk melakukan telnet, saya harus mengetahui MX records domain tujuan. Nantinya saya akan melakukan telnet ke port 25 pada server yang tercantum dalam list MX records.

Saya bisa menggunakan website DNS check (misalnya https://dnscheck.id) namun karena saya sedang melakukan investigasi via CLI, saya menggunakan perintah CLI : dig.

dig namadomain.de mx

;; ANSWER SECTION:
namadomain.de. 3600 IN MX 10 mx01.namadomainserver.de.
namadomain.de. 3600 IN MX 10 mx00.namadomainserver.de.

Ada 2 MX records yang terdaftar dan masing-masing memiliki priority 10. Asumsi pertama saya adalah, jangan-jangan salah satu server bermasalah yang menjadikan error tersebut intermittent. Misalnya sebagian server berhasil berkomunikasi namun yang lainnya gagal. Sebagai contoh koneksi dari SMTP Relay Excellent gagal terhubung ke salah satu server yang bermasalah, sedangkan Gmail dan lain-lain berhasil terhubung karena koneksinya terhadap server yang tidak bermasalah.

Asumsi tersebut hanya dugaan dan harus diuji dengan mencoba mengirimkan email.

UJICOBA KONEKSI PORT PENERIMAAN EMAIL
Port SMTP ada bermacam-macam, misalnya port 465 untuk koneksi SMTP SSL dan port 587 untuk Submission port TLS. Namun, untuk penerimaan email, default portnya adalah port 25 dan saya bisa menggunakan telnet kemudian bicara dengan bahasa mesin ke server tujuan.

telnet mx00.namadomainserver.de 25

Trying 212.227.xx.xx…
Connected to mx00.namadomainserver.de.
Escape character is ‘^]’.
220 namadomainserver.de (mxeue011) Nemesis ESMTP Service ready

Pesan diatas menunjukkan bahwa port 25 disisi server tujuan terbuka dan server mereka siap menerima koneksi. Hal itu dinamakan dengan HELO. Jadi saya membalas pesan tersebut dengan perintah EHLO. EHLO adalah bahasa prokem dari HELO. Ini salah satu kebiasaan dari para ahli IT yang tidak mau repot-repot mencari istilah, hehehe…

ehlo namadomainserver.de

250-namadomain.de Hello namadomainserver.de
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

Baris diatas adalah pemberitahuan dari server setelah saya “kulonuwun” menjawab helo mereka dengan ehlo. Server memberitahukan bahwa mereka mendukung koneksi 8-bit karakter, dengan maksimum attachment 157286400 (150 MB) dan siap menerima koneksi dengan protokol secure TLS.

Setelah server tujuan menginformasikan hal tersebut, saya bisa mengirimkan email dengan menyebutkan email pengirim, email tujuan, subject dan isi email. Saya mulai dengan menyebutkan email pengirim :

mail from:namauser@perusahaan-indo.com

550-Requested action not taken: mailbox unavailable
550 invalid DNS MX or A/AAAA resource record

Ternyata jawabannya langsung error, sama dengan pesan error yang disampaikan pihak klien.

Karena penasaran, saya coba sekali lagi dan hasilnya sama.

Berarti server mx00.namadomainserver.de gagal dihubungi. Saya mencoba ke server kedua, yaitu mx01.namadomainserver.de, ternyata hasilnya sama.

Kesimpulan pertama : Server tujuan memiliki konfigurasi yang sama dan keduanya sama-sama menghasilkan pesan error. Setelah ini, apa yang akan dilakukan? Premis atau asumsi kedua saya adalah, ada masalah dengan si pengirim. Jadi saya melanjutkan investigasi, kali ini menggunakan alamat email saya sebagai pengirim.

UJICOBA PENGIRIMAN EMAIL MENGGUNAKAN DOMAIN LAIN

Untuk keperluan ini, saya menggunakan perintah telnet yang sama.

telnet mx00.namadomainserver.de 25

Trying 212.227.xx.xx…
Connected to mx00.namadomainserver.de.
Escape character is ‘^]’.
220 namadomainserver.de (mxeue010) Nemesis ESMTP Service ready
ehlo namadomainserver.de
250-namadomainserver.de Hello namadomainserver.de
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

mail from:hosokawa.fujitaka@excellent.co.id

250 Requested mail action okay, completed

Berhasil. Ternyata menggunakan domain excellent.co.id berhasil lolos dari pengecekan server tujuan. Ada kemungkinan masalahnya benar disisi domain pengirim.

Untuk memastikannya, saya mencoba koneksi ke MX server kedua :

telnet mx01.namadomainserver.de 25

Trying 217.72.xx.xx…
Connected to mx01.namadomainserver.de.
Escape character is ‘^]’.
220 namadomainserver.de (mxeue110) Nemesis ESMTP Service ready
ehlo namadomainserver.de
250-namadomainserver.de Hello namadomainserver.de
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

mail from:vavai@excellent.co.id
250 Requested mail action okay, completed

Hasilnya sukses kembali. Dari hal diatas, bisa disimpulkan kesimpulan awal sebagai berikut :

1. Server tujuan valid dan tidak ada issue. Hal ini karena kedua server mereka memberikan respon yang sama
2. Problem terjadi pada domain pengirim : namaperusahaan-indo.com karena jika mengirim email menggunakan domain excellent.co.id (atau domain lain yang normal) tidak ada kendala
3. Jika merujuk pesan error : 550-Requested action not taken: mailbox unavailable 550 invalid DNS MX or A/AAAA resource record pesan ini kemungkinan besar bukan berarti alamat email tujuan tidak ada sesuai asumsi semula, melainkan adanya mekanisme pengecekan sender domain (biasanya sebagai bagian dari proteksi anti spam) dan domain namaperusahaan-indo.com gagal memenuhi kriteria ini, sedangkan domain excellent.co.id berhasil memenuhi kriteria

PENGECEKAN INTEGRITAS DNS
Berdasarkan hasil analisa point 3, saya melanjutkan investigasi dengan mencoba mengecek integritas DNS domain namaperusahaan-indo.com melalui alamat https://intodns.com dan menemukan hasil sebagai berikut :

MX A request returns CNAME WARNING: MX records points to a CNAME. CNAMEs are not allowed in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3. The problem MX record(s) are: mail.namaperusahaan-indo.com points to [‘namaperusahaan-indo.com’] This can cause problems

Hasil pengecekan diatas membuktikan premis tersebut, menunjukkan bahwa ada kesalahan konfigurasi DNS untuk domain namaperusahaan-indo.com dimana seharusnya MX records merujuk pada nama yang ditranslasikan ke A records.

Pada kasus domain klien namaperusahaan-indo.com, MX records benar merujuk pada nama mail.namaperusahaan-indo.com namun nama mail.namaperusahaan-indo.com merujuk pada alias (cname) dari namaperusahaan-indo.com.

Kemungkinan besar hal diatas terjadi karena email namaperusahaan-indo.com menggunakan layanan email hosting bagian dari web hosting dan pihak ISP mengambil cara mudah melakukan setting MX menggunakan alias name. Hal ini tidak sesuai RFC dan kaidah konfigurasi mail server.

Sesuai RFC 1912 : [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
974] explicitly states that MX records shall not point to an alias
defined by a CNAME. This results in unnecessary indirection in
accessing the data, and DNS resolvers and servers need to work more
to get the answer.

Referensi : https://tools.ietf.org/html/rfc1912

SOLUSI

Sebagai solusi, saya meminta pada pihak klien untuk menghubungi ISP hosting mereka dan menyesuaikan isian records mail.namaperusahaan-indo.com dari awalnya CNAME terhadap namaperusahaan-indo.com menjadi A records

$ nslookup mail.namaperusahaan-indo.com

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:

mail.namaperusahaan-indo.com canonical name = namaperusahaan-indo.com.

Name: namaperusahaan-indo.com

Address: 203.201.XXX.XXX

Berikut adalah contoh permintaan penggantian records DNS tersebut :

/*Hi NOC ISP

Mohon dapat dilakukan penggantian/penyesuaian records DNS pada domain kami namaperusahaan-indo.com untuk records mail.namaperusahaan-indo.com sebagai berikut :

Sebelumnya

mail.namaperusahaan-indo.com IN CNAME namaperusahaan-indo.com

Menjadi

mail.namaperusahaan-indo.com IN A 203.201.XXX.XXX

Jika sudah dilakukan, harapa menginformasikannya kepada kami agar dapat kami check dan validasi kembali.

*/

Setelah pihak ISP melakukan pengubahan, pihak klien bisa melakukan pengetesan apakah error seperti yang ditunjukkan pada : https://intodns.com masih ada atau sudah diperbaiki.

HASIL AKHIR
Setelah dilakukan penyesuaian MX records oleh pihak ISP hosting klien, saya melakukan testing ulang dengan telnet port 25. Hasilnya, domain klien mendapat pesan sukses :

250 Requested mail action okay, completed

Setelah mengkonfirmasi hasil tersebut di kedua server MX tujuan, saya menginformasikan kembali pada pihak klien mengenai hasil akhir dan meminta mereka melakukan pengiriman email dengan di cc-kan ke alamat team support Excellent.

Hasil pengiriman email dari pihak klien mendapat balasan dari rekanan mereka di Jerman bahwa email berhasil diterima dengan baik.

Mission accomplished.

CATATAN :
Sebagai email services provider (ESP), Excellent menyediakan layanan lengkap terkait email sebagai berikut

1. Layanan Excellent Managed Services Mail Server : https://www.excellent.co.id/vps
2. Layanan SMTP Relay : https://www.excellent.co.id/smtp
3. Layanan Anti Spam dan Anti Virus : https://www.excellent.co.id/asav
4. Layanan SSL
5. Layanan lisensi email server berbasis Zimbra
6. Dan lain-lain

Markas Excellent DJ dan markas Excellent Premier Serenity merupakan lokasi data center kecil-kecilan, ditambah dengan data center kecil juga di Gedung Tifa Jakarta. Untuk melakukan pengelolaan sistem di lokasi berbeda ini, saya kerap menggunakan aplikasi SSH, Remote Desktop (RDP), Team Viewer atau AnyDesk.

Karena koneksinya timbul tenggelam, pengalaman remote berbasis desktop ini kurang menyenangkan. Saya lebih memilih untuk mengaktfikan akses VPN.

Kebetulan di masing-masing markas Excellent ada Synology yang digunakan sebagai shared storage, media penyimpanan file sekaligus backup data. Synology memiliki feature yang cukup komplit dan konfigurasinya relatif mudah.

AKTIVASI VPN SERVER

Untuk mengaktifkan VPN pada Synology, berikut adalah prosesnya :

• Login ke Synology
• Masuk ke menu Package Center dan search VPN
• Aplikasi VPN ada pada group Utilities. Klik Install untuk melakukan instalasi package-nya
• Setelah package terinstall, pilih menu Open
• Aktifkan salah satu atau beberapa pilihan VPN server. Ada VPN server berbasis PPTP, OpenVPN dan L2TP. Sebagai contoh, saya menggunakan OpenVPN. Lakukan setting terkait OpenVPN termasuk maksimum koneksi, authentikasi, port dan lain-lain

• Setelah selesai, klik Apply
• Pastikan port 1194 UDP disisi firewall sudah diopen
• Scroll ke bagian bawah konfigurasi dan pilih menu Export Configuration. File konfigurasi dalam format .zip ini berisi file konfigurasi OpenVPN, readme dan file SSL Certificate dan bisa dipergunakan sebagai media import konfigurasi koneksi menggunakan VPN Client

KONEKSI KE VPN SERVER

• Download aplikasi OpenVPN Client sesuai dengan sistem operasi yang dipergunakan. Jika menggunakan Windows bisa menggunakan aplikasi VPN dari website OpenVPN sedangkan jika menggunakan Linux bisa melakukan instalasi paket OpenVPN melalui repo Linux masing-masing. Karena saya menggunakan Mac, saya memilih aplikasi TunnelBlick.
• Pada aplikasi yang digunakan, pilih menu import file .opvn yang ada dalam file .zip. Jangan lupa sesuaikan alamat server pada file konfigurasi tersebut. Jika menggunakan Linux, bisa menggunakan perintah : openvpn –config client.ovpn
• Jika sudah terkoneksi, test akses IP lokal disisi VPN server, seharusnya sudah bisa diakses

Contoh diatas saya menggunakan OpenVPN namun aktivasi PPTP dan L2TP secara prosedur hampir sama. Sedikit perbedaan hanya disisi klien saja.

Dengan menggunakan VPN, saya bisa bekerja dengan mudah dan memiliki banyak pilihan akses terhadap server yang ada disisi remote. Karena server disisi data center Tifa memiliki spesifikasi yang cukup tinggi, saya bisa menggunakannya sebagai server simulasi untuk keperluan penulisan update buku VMware vSphere 6.7.

Disisi lain, saya juga tidak perlu selalu melakukan remote GUI, baik ke data center Tifa maupun ke markas Excellent lainnya karena bisa melakukannya dengan mekanisme SSH atau akses via Web tanpa perlu melakukan setting port forwarding berbagai macam port.

CATATAN

• Dalam beberapa kasus, segmen IP lokal disisi VPN server tetap tidak bisa diakses/ping meski sudah memilih menu “Allow clients to access servers LAN”. Jika ini yang terjadi, jangan berputus asa atau mutung melainkan cari solusinya, hehehe… Solusinya, edit file konfigurasi .opvn dan hilangkan tanda pagar (#) dari baris berikut : redirect-gateway def1

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)
redirect-gateway def1

• Secara default, OpenVPN akan menggunakan authentikasi yang dipergunakan untuk login ke Synology. Kita bisa mengatur list user yang diberikan akses melalui menu Privilege

Rencana awal, upgrade dilakukan pada pertengahan bulan Desember 2018, namun atas pertimbangan fleksibilitas waktu dan mengingat ada kegiatan stock opname akhir tahun, akhirnya proses upgrade diundur menjelang akhir tahun.

Dengan mempertimbangkan skala upgrade dan tingkat kesulitan yang cukup tinggi, saya meminta engineer senior untuk mengawalnya. Itu sebabnya Ahmad Imanudin dan Rizky Pratama yang diset sebagai Person In Charge (PIC) dengan pertimbangan kapabilitas, jam terbang dan pengalaman mereka melakukan hal yang mirip di klien lain.

Beberapa minggu sebelum pelaksanaan upgrade, kami melakukan meeting bersama mengenai skenario dan strategi upgrade, termasuk berdiskusi mengenai preliminary check dan kemungkinan implikasi dari proses upgrade. Setelah skenario dan strategi disepakati, kami membuat sandbox server, yaitu salinan server production untuk dijadikan sebagai media simulasi upgrade.

Masalah yang muncul saat simulasi langsung dicarikan solusinya. Kami juga berdiskusi dengan pihak prinsipal untuk beberapa masalah yang tidak bisa langsung dieskalasikan. Persiapan dan simulasi yang dilakukan membuat kami bisa mencegah kemungkinan adanya masalah saat upgrade.

Meski hati berdebar-debar, dengan persiapan yang dilakukan sebaik mungkin, akhirnya schedule waktu definitif untuk upgrade ditentukan.

Seminggu menjelang proses upgrade, saya bersama keluarga melakukan perjalanan liburan sekaligus kondangan ke Brebes-Kebumen-Salatiga-Semarang. Perjalanan ini sebagai bagian dari liburan keluarga, namun sebagian pikiran saya masih tertuju pada rencana upgrade dan kemungkinan resikonya.

Karena sudah disiapkan sebaik-baiknya, saya pikir apa yang terjadi, terjadilah. Jadi di Sabtu selepas maghrib, saya meluncur ke kawasan Sudirman, bergabung dengan Ahmad dan Rizky yang terlebih dahulu meluncur kesana.

Sampai di kantor klien, kami shalat Isya terlebih dahulu, kemudian mengecek persiapan upgrade yang sudah direncanakan. Proses kick off upgrade akan dilaksanakan tepat pukul 23.00 WIB, namun beberapa jam sebelumnya ada schedule proses snapshot dan finalisasi backup.

Tepat pada pukul 23.00 WIB proses upgrade dilaksanakan, dimulai dengan mematikan seluruh services cluster server, melakukan snapshot akhir dan kemudian menjalankan proses upgrade sesuai dengan timeline yang sudah ditetapkan. Rizky bertindak sebagai eksekutor dan Ahmad sebagai supervisor. Saya sebagai team hore yang mengawasi proses upgrade sambil berbincang dengan IT pihak klien.

Meski sudah disiapkan sebaik-baiknya, masih ada beberapa hal diluar dugaan yang muncul. Meski demikian, dengan latar belakang pengalaman yang mumpuni, Rizky bisa mengatasinya dengan baik. Ahmad hanya sesekali memberikan arahan sementara saya mulai mengantuk dan mencoba berjalan-jalan sambil sesekali mengecek pekerjaan Rizky.

Beberapa jam sebelum waktu yang disediakan habis, Rizky sudah berhasil melakukan upgrade. Tahap selanjutnya adalah melakukan sampling pengecekan sesuai dengan timeline dan ujicoba akses menggunakan beberapa account. Ada beberapa hal yang perlu disesuaikan namun secara umum proses upgrade dapat dengan mulus dilakukan.

Setelah proses upgrade selesai dan pengecekan dinyatakan OK oleh pihak klien, kami bisa berpamitan untuk pulang kembali ke Bekasi.

Keluar dari kantor klien, jalan Jenderal Sudirman dipenuhi dengan masyarakat yang sedang berolahraga pagi menikmati Car Free Day. Kami berdua berjalan melawan arah menuju stasiun Sudirman, sambil terkantuk-kantuk dan Rizky membawa 1 dus oleh-oleh dari pihak klien dengan gaya seperti orang pulang kampung hehehe…

Pengalaman upgrade ini menjadi salah satu pengalaman yang menarik dan mendewasakan, dalam arti bahwa meski cukup beresiko dan cukup berat dilakukan, kita bisa tetap menjalankannya dengan persiapan yang matang dan dilakukan sebaik-baiknya.

Salah satu layanan utama di Excellent adalah layanan SMTP Relay. Layanan ini berfungsi sebagai server relay/penerus email dari klien yang ditujukan pada pihak eksternal. Pengguna layanan ini terdiri dari berbagai latar belakang, antara lain :

1. Pengguna layanan Excellent Managed Services Mail Server. Untuk meningkatkan kualitas dan performa sistem, kami memisahkan layanan SMTP routing ke eksternal termasuk layanan anti spam agar spesifikasi sistem secara penuh digunakan untuk layanan email
2. Klien yang IP public-nya terkena blacklist pihak tujuan
3. Klien yang hanya punya IP dynamic
4. Klien yang terkena limit pengiriman email oleh pihak ISP
5. Klien yang capek karena email terkadang tidak sampai ditujuan dan tidak diketahui penyebabnya
6. Klien yang sebel karena email yang dikirim malah masuk ke folder spam di pihak tujuan
7. Klien yang ingin menyembunyikan posisi server mereka atas pertimbangan keamanan sistem. Port-port yang dibuka dibatasi hanya untuk IP tertentu, misalnya port incoming hanya diperbolehkan untuk email yang berasal dari layanan anti spam Excellent, port 25 outgoing diblock dan koneksi ke server SMTP Excellent diset menggunakan port yang tidak umum

Layanan SMTP Relay ini awalnya dimulai dari 1-2 server. Menggunakan server yang ditempatkan di co-location server. Awal-awal diimplementasikan, domain Excellent sendiri yang menjadi kelinci percobaan. Sebelum menjadi produk untuk dijual, kami harus memastikannya bisa berjalan sesuai harapan. Bagaimana mungkin kami menjual produk terkait email kalau email kami sendiri kerap bermasalah.

Layanan yang awalnya ditujukan untuk kepentingan internal ini terus dimonitor stabilitas dan performanya. Setelah cukup percaya diri, layanan ini kemudian mulai diimplementasikan disisi server managed services. Perlu berbagai langkah preventif dan korektif untuk memastikan bahwa IP public server selalu terjaga aman tanpa mengurangi fleksibilitas sistem. Jumlah server terus ditambah seiring dengan penambahan jumlah klien. Kami juga menyiapkan server pada posisi lokasi geografis berbeda sebagai antisipasi jika ada gangguan di lokasi tertentu.

INISIASI AWAL

Setelah berjalan beberapa lama, pada sesi brainstorming internal ada usulan untuk membuat dashboard smtp relay, dengan beberapa latar belakang pertimbangan, antara lain :

1. Dengan dashboard smtp relay, klien bisa melakukan tracking log pengiriman email secara mandiri, tidak perlu melakukan request ke team support Excellent. Klien terpenuhi kebutuhannya dan disisi lain team support Excellent terlepas dari pekerjaan yang tidak memberikan nilai tambah
2. Lebih mudah mengecek perkembangan kualitas layanan. Data-data klien tercatat lebih rapi, dilengkapi dengan detail nama perusahaan,  contact person, no kontak/HP/telp, alamat email dan lain-lain. Mudah juga melakukan broadcast pemberitahuan ke seluruh klien
3. Pembuatan laporan bisa lebih mudah dilakukan. Mengetahui klien mana yang over usage, klien mana yang terkena lock karena melakukan spamming maupun klien yang terkena suspend karena overdue tagihan lebih mudah dikelompokkan
4. Bisa membuat skema level layanan, misalnya klien level premium bisa melakukan attachment sekian MB namun klien level silver hanya bisa mengirim attachmen lebih kecil. Demikian juga untuk trafik email, bisa dicheck dengan mudah
5. Lebih mudah diintegrasikan. Bisa dibuat standard knowledge base untuk proses setup disisi klien, termasuk nantinya dikembangkan untuk API aplikasi. Team juga bisa membuat script auto install untuk mempermudah setting disisi klien
6. Klien bisa mengecek status pengiriman email per jam, per hari, per minggu hingga per bulan. Berapa email yang terkirim dan berapa yang gagal termasuk data user-user yang mengirim email terbanyak yang bisa menjadi informasi awal indikasi spamming (atau melakukan blast)
7. Bisa dilengkapi dengan feature pengecekan SPF, DKIM, DMARC dan lain-lain yang bisa meningkatkan kualitas reputasi pengiriman email pihak klien

Untuk merealisasikan hal ini, ada 2 pilihan yang tersedia, yaitu merekrut team developer aplikasi atau meminta pihak vendor software membuatkannya untuk Excellent. Kedua pilihan memiliki kelebihan dan kekurangan masing-masing. Jika merekrut team developer, mungkin akan butuh waktu untuk pengembangan namun bisa lebih fleksibel dalam menentukan prioritas dan cakupan pekerjaan yang akan dilakukan, sedangkan jika diserahkan kepada pihak vendor, prosesnya diharapkan bisa lebih cepat namun tentu saja harus ditentukan Scope of Works-nya secara lebih detail.

Setelah mempertimbangkan kelebihan dan kekurangan masing-masing, kami memilih vendor software untuk membuatkannya. Kebetulan saya mengenal seorang rekan yang memiliki kapabilitas mengenai hal ini. Ia sering membaca tulisan saya di blog, kemudian tertarik untuk resign dari kantor dan membangun usaha dibidang software development. Setelah berjalan beberapa lama, overhead cost-nya tidak bisa ditutup dari pendapatan sehingga akhirnya ia kembali bekerja di sebuah perusahaan. Meski demikian ia terus keep contact dengan saya. Tahun lalu ia berdiskusi kembali dengan saya mengenai problem dikantornya, dimana sebagian besar uang perusahaan dipakai founder untuk mengembangkan usaha lain sampai-sampai usaha utama terseok-seok dan banyak team programmernya yang resign.

Mendengar hal itu, saya tawarkan padanya, bagaimana jika saya berinvestasi saja. Saya berinvestasi pada kualitas personal dia. Selain mencari order dari pihak eksternal, sekalian saja perusahaan yang baru ia bangun mendapat order dari Excellent. Jadi meski saya memiliki investasi di kedua perusahaan, hubungan ordernya murni professional. Ia setuju dan saya diberikan alokasi sekitar 40% saham. Dengan skema ini, pengembangan dashboard smtp relay Excellent dimulai.

EKSEKUSI IDE

Untuk mendapatkan gambaran mengenai aplikasi dashboard smtp relay yang akan dikembangkan, saya meminta team Excellent mengadakan pertemuan beberapa kali membahas skema dan featurenya. Ada banyak usulan dan saran termasuk diskusi teknis saat sesi ini. Misalnya jika script robot monitoring Excellent melakukan lock account klien yang terindikasi spamming, maka datanya harus bisa ditangkap oleh aplikasi dan diinformasikan ke pihak klien. Diskusi juga mencakup pembahasan mengenai skema aplikasi master-klien, yaitu berupa 1 dashboard untuk team Excellent sebagai admin dan 1 dashboard untuk pihak klien.

Setelah beberapa waktu, dibuatkan 1 buah mockup yang kemudian ditest dan divalidasi terus menerus. Semua kekurangan diperbaiki. Feature yang penting dilengkapi. Menu yang kurang jelas dikoreksi. Mungkin saat-saat seperti ini membuat team developer sebel karena requestnya jadi banyak. Apalagi ada juga request-request dari pihak klien yang ingin suatu laporan tertentu yang jika ditelusuri lebih jauh, muaranya bisa disiapkan via aplikasi.

Setelah dirasa mencapai level beta, aplikasi mulai difungsikan. Untuk kelinci percobaan, team membuat mail server dengan domain masing-masing dan digenerate account relay-nya via dashboard. Informasi yang terkirim via email dicheck ulang apakah narasinya sudah tepat. Apakah deskripsinya tidak membingungkan. Apakah display name sender-nya sudah benar. Pengecekan juga dilakukan di dua sisi dashboard. Disisi dashboard admin sudah benar, apakah disisi klien sudah benar juga.

Testing dilanjutkan dengan pengiriman email. Apakah lognya sudah terpusat. Apakah lognya bisa diparsing dengan benar. Bagaimana cara tahu suatu email dianggap bounced atau delivered. Disini team engineer Excellent yang masih muda berdiskusi dengan team software devs agar algoritma yang ada dan dijelaskan oleh team engineer bisa diterjemahkan ke logika programming.

Setelah fase beta selesai ditest, prosesnya dilanjut dengan memasukkan beberapa list klien prioritas kedalam dashboard smtp relay. Proses pengecekan diulangi dan hal-hal yang masih bermasalah terus diperbaiki sampai kami cukup puas untuk menerapkannya secara massal.

Yang pertama dimasukkan kedalam dashboard  adalah klien-klien yang murni langganan smtp relay. Setelah capek harus memasukkan data satu persatu, team engineer berdiskusi lagi dengan team software devs untuk menyediakan menu bulk import. Untuk menu disiapkan dan team engineer diminta membuat list klien dalam bentuk spreadsheet dengan format tertentu. Setelah semua dimasukkan, sistem dimonitoring kembali selama beberapa waktu.

Setelah sistem berjalan lancar, seluruh klien Excellent managed services dimasukkan kedalam database dashboard. Dengan demikian, secara resmi dashboard smtp relay Excellent diluncurkan.

Masukan-masukan dari pengguna layanan mulai muncul. Misalnya ada kebutuhan tambahan informasi subject agar proses tracking log lebih mudah dilakukan. Team engineer Excellent mengaktifkan feature ini disisi mail server, kemudian mencari cara untuk melakukan parsing datanya. Data yang sudah diparsing nantinya akan diolah oleh team software devs untuk diproses menjadi log tracking disisi aplikasi.

Saat ini dashboard smtp relay sudah berjalan selama beberapa waktu. Proses pengembangan dan monitoring aplikasi tetap dijalankan. Ibarat bayi baru lahir, team Excellent merawatnya secara hati-hati dan belajar melakukan scaling seiring dengan penambahan jumlah klien. Hidup team Excellent jadi lebih berwarna dengan adanya dashboar smtp relay

Jika tertarik mencobanya atau mengalami kendala pengiriman email atau berjuang mengatasi spam yang sering melakukan broadcast ke pihak eksternal, bisa kok melakukan trial aplikasi. Silakan meluncur ke sini : Layanan Excellent SMTP Relay

Beberapa server yang dikelola Excellent juga menggunakan openSUSE atau varian SLES-nya. Salah satunya adalah server backup yang juga difungsikan sebagai Docker host. Server tersebut tidak secara default disetting auto upgrade, sehingga saat saya check masih menggunakan versi openSUSE Leap 42.1 dengan isi repositori campuran. Repo campuran ini maksudnya repo utama (oss dan non-oss) beserta repo aplikasi 3rd party.

Sepertinya karena pernah diupdate parsial dengan repo campuran, package aplikasinya tercampur-campur dan sebagian tidak bisa dijalankan. Sedemikian parahnya, sampai-sampai menjalankan zypper dan yast saja tidak bisa, dengan pesan error sebagai berikut :

zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb

Kira-kira seperti itu pesan errornya. Saya coba wget juga tidak bisa. Saya sudah sampai pada tahapan hendak melakukan proses reinstall namun karena ada 6 TB data di server tersebut, saya mencoba cara lain yang mungkin bisa berhasil.

Target utama saya adalah bisa menjalankan zypper dan yast. Jika kedua aplikasi utama ini bisa dijalankan, saya bisa melakukan update untuk aplikasi lainnya. Masalahnya, karena keduanya tidak bisa dijalankan, saya harus melakukan download file package aplikasi dan melakukan instalasi secara manual.

Untuk mendownload package zypper, saya harus menentukan dulu versi openSUSE leap yang hendak diambil. Saya memilih openSUSE leap 42.3 yang masih disupport di repo openSUSE baru kemudian nantinya diupgrade ke versi terkini. Saya mengambil binary zypper melalui https://software.opensuse.org/search menggunakan curl -0 dengan parameter –output (karena wget tidak bisa dijalankan) kemudian mencoba install menggunakan rpm -ivh atau rpm -Uvh.

Ternyata binary zypper ini conflict dengan versi yang sudah ada dan terinstall (dan tidak berjalan ). Jadi saya melakukan proses remove aplikasi zypper berikut file-file yang menyertainya. Saat mencoba install kembali, ternyata butuh file libzypp. Saya mencari binary libzypp dan mencoba install terlebih dahulu sebelum install zypper. Ternyata libzypp butuh file libmodman. Saat coba install libmodman butuh libsolv-tools. Setelah keduanya diinstall, ternyata masih butuh file libproxy. Saya sudah hampir mengurungkan niat melanjutkan proses recovery sistem ini karena jadi panjang prosesnya. Inilah repotnya install manual karena harus melakukan instalasi file dependency terlebih dahulu. Jadi ingat saat-saat pakai openSUSE kala zypper belum diciptakan dan yast dianggap kurang familiar

Namun karena saya lagi ada banyak waktu dan saya juga punya hobi ngoprek, saya lanjutkan terus prosesnya. Library apapun yang diminta, saya cari di repo openSUSE. Sampai akhirnya zypper bisa terinstall dengan baik. Karena zypper terinstall dengan baik, yast bisa saya install. Karena keduanya bisa diinstall, saya bisa melakukan perintah zypper mr -da untuk melakukan disable semua repo, kemudian menambahkan repo openSUSE leap 42.3 dengan perintah zypper ar baru setelah itu melakukan perintah zypper up untuk melakukan update seluruh package.

Setelah semua package terupdate, saya bisa melakukan instalasi package lainnya seperti wget. Saya check sekarang server sudah berjalan dengan normal dan aktif kembali.

Karena waktu ngoprek masih banyak, saya mendisable semua repo openSUSE leap 42.3 kemudian menambahkan repo openSUSE leap 15.1 dan melakukan perintah zypper dup (zypper distribution upgrade) untuk melakukan uppgrade major ke versi openSUSE leap 15.1.

Proses upgrade ini berjalan dengan mulus dan sekarang si server sudah pakai openSUSE leap 15.1.

# cat /etc/os-release
NAME=”openSUSE Leap”
VERSION=”15.1 Alpha”
ID=”opensuse-leap”
ID_LIKE=”suse opensuse”
VERSION_ID=”15.1″
PRETTY_NAME=”openSUSE Leap 15.1Alpha”
ANSI_COLOR=”0;32″
CPE_NAME=”cpe:/o:opensuse:leap:15.1″
BUG_REPORT_URL=”https://bugs.opensuse.org”
HOME_URL=”https://www.opensuse.org/”

Setelah baca-baca kembali, ternyata saya terlalu update mengambil versinya . Versi stabil untuk Leap ada di versi 15.0 kalau menurut https://en.opensuse.org/Portal:Leap. Saya juga sebenarnya bisa memilih Tumbleweed jika ingin versi rolling-release, jadi tidak harus upgrade versi hanya untuk mendapatkan software versi terbaru. Namun karena tujuan awal saya adalah menyelamatkan sistem Leap yang ada, ditambah lagi ini memang server backup plus development berbasis Docker, saya masih oke pakai versi alpha sekalipun

Buat jaga-jaga, data backup yang 6 TB siap-siap saya salin ke bucket storage lain, jadi ada cadangan emergency jika saya hendak bermain-main dengan openSUSE leap 15.1 atau mau switch ke openSUSE Tumbleweed.