WEB SERVER Sederhana Berbahanbaku REXX untuk z/OS

25 Jul 2011 WEB SERVER Sederhana Berbahanbaku REXX untuk z/OS

Rexx atau Restructured Extended eXecutor pertama kali dimunculkan adalah di sistem VM pada awal 1980an. Awalnya hanyalah script untuk system interpreter untuk menyusun rangkaian OS command mirip BAT file di Windows. Yang memakai biasanya para sysadmin dan technical support untuk menyusun prosedur rutinitas pekerjaannya. Namun Rexx memiliki struktur dan kekayaan sarana setara bahasa komputer pada saat itu. Sehingga ada juga yang tertarik membuat aplikasi sedarhana dengan Rexx.

Hari ini Rexx sudah diperkaya dengan berbagai sarana programming termasuk TCP/IP Socket Application Program Interface (API) dan APPC/MVS communication API. Dengan demikian Rexx sudah mampu untuk menangani networking baik berbasis TCP/IP maupun SNA.

Socket API dalam Rexx dipanggil dengan fungsi socket(). Mekanismenya sama seperti ketika menggunakan bahasa lain: Dalam hal ini yang kita bahas adalah server. Maka mekanisme tahapannya harus mengikuti skenarion sbb:

  1. Initialize API
  2. Obtain socket description number
  3. Set necessary options
  4. Bind selected socket desc num to a port
  5. Listen the port (establish event notification path)
  6. Accept connection request (actually wait for connection request)
  7. Handle interaction (receive and send data)
  8. Close connection
  9. Back to 6 to allow another connection request or go to 10 shutdown is requested
  10. Terminate API

Server biasanya loop dari tahap 6 ke 9 biasanya dilakukan terus-menerus tanpa batas sampai diperintahkan berhenti. Program server yang serius, pada tahap 7 umumnya dilakukan dalam program terpisah agar bisa simultan. Prakteknya bisa dengan thread terpisah, task terpisah maupun subtask. Untuk sistem mainframe, khususnya z/OS, semua cara tersedia dan kita bisa pilih salah satu atau kombinasi. Biasanya dipilih subtask karena model multitasking dalam satu address space paling mudah dan efisien. Intinya, interaksi dengan setiap client dilakukan dalam unit proses terpisah, agar server melayani banyak client secara simultan.

Sayang sekali Rexx belum dibekali dengan kemampuan memanfaatkan fasilitas multitasking.yang luwes seperti bahasa yang lain. Meskipun dengan Rexx kita bisa membangkitkan subtask dengan perintah address ATTACH, namun belum ada sarana bagaimana memantau dan mengirim sinyal ECB dari maupun ke program Rexx. Sehingga harus dikombinasi dengan aditif yang sulit dipahami oleh pembaca awam disini. Oleh karena itu saya pilih single thread saja.

Web server memiliki ciri tingkahlaku yang berbeda dengan server pada umumnya. Protokol HTTP tidak pernah menggantung koneksi dalam waktu lama seperti aplikasi network lain (CICS, POP, FTP dll). Meskipun HTTP juga menyediakan sarana koneksi persistent, namun bukan berarti untuk menggantung koneksi untuk menuntaskan semua transaksi. Koneksi persistent HTTP hanya untuk menuntaskan satu transaksi. Dalam HTTP versi lama (1.0 dan sebelumnya), satu koneksi hanya berlaku untuk sekali interaksi send/receive saja. Padahal satu transaksi kadang melibatkan lebih dari sekali interaksi. Sejak HTTP versi 1.1, transaksi yang terdiri dari beberapa putaran send/receive dapat diselenggarakan dalam sekali koneksi.

Tingkah laku HTTP yang transaksinya cukup singkat ini memungkinkan server dibuat menggunakan algoritma iteratif. Tentu saja harus menunggu layanan lebih lama ketika sejumlah client (browser) mengakses secara bersamaan. Namun tidak separah jika FTP atau POP dibuat iteratif. Hal ini memberi kesempatan bagi Rexx programmer untuk membuat HTTP server dengan Rexx. Sepuluh tahapan di atas dalam Rexx disusun sbb:

src = socket("INITIALIZE","zBogor")
#IP_host = WORD(src,2)
src = socket("SOCKET","AF_INET","STREAM")
$sockid = WORD(src,2)
$sockname = "AF_INET " || #IP_port || " INADDR_ANY"
opt = socket("SETSOCKOPT",$sockid,"SOL_SOCKET","SO_REUSEADDR",1)
src = socket("BIND", $sockid, $sockname)
src = socket("LISTEN", $sockid)
alldone = 0
do until alldone
src = socket("ACCEPT", $sockid)
if word(src,1) = 0 then,
call Handle_Peer
else,
alldone = 1
end
src = socket("CLOSE",$sockid)
ENDPROGRAM:
src = socket("TERMINATE","zBogor")
exit 0

Interaksi dengan browser (tahap 7) ditangani dalam subrutin Handle_Peer secara berurutan (sinkron) mengikuti putaran loop (du until / end). Dalam subrutin tersebut intinya hanya send, wait dan receive berulang sampai satu transaksi tuntas. Lantas koneksi diputus dengan close dan kontrol kembali ke loop utama untuk menunggu transaksi berikutnya dari peer yang lain (accept). Detil program Rexx-nya dapat disimak langsung pada modul source code yang tersedia dalam paket freeware zBogor.

zBogor© – contoh web server paling sederhana

Kali ini topiknya adalah Web Server Sederhana. Kebetulan saya sedang menangani pelatihan Rexx di BII, terilhami untuk membahas Socket API ini dalam workshop. Karena dengan materi ini, para peserta tidak melulu berkutat memahami fungsi Rexx dalam kandang mainframe, melainkan membuka wacana nyata bahwa Rexx juga bagian dari onderdil enterprise. Oleh karena itu saya pilih HTTP agar bisa diprakekan dengan platform lain tanpa harus membuatkan client program di luar mainframe, karena disana sudah ada browser. Program ini saya namai zBogor dan karena ini versi paling awal maka saya tandai dengan 1.0.0. Siapa saja boleh men-download-nya melalui laman NSI ini dan ikuti petunjuk di dalamnya.

Sekali lagi, zBogor 1.0.0 adalah web server sangat sederhana (WSSS). Jadi jangan dibayangkan seperti Apache apalagi Websphere. zBogor 1.0.0 hanya mampu meladeni GET request dan hanya untuk menampilkan halaman index atau salah halaman. Itupun mungkin masih belum 100% bener. Namun demikian setidaknya sudah bisa digunakan untuk memberi pemahaman awal kepada orang-orang yang mempelajari Rexx, bahwa Rexx bisa digunakan untuk itu.

Namun bukan berarti Rexx mumpuni digunakan sebagai programming tools untuk menangani protokol HTTP. Hingga hari ini, sayang sekali Rexx belum mampu melakukan multitasking. Sehingga untuk interaksi HTTP yang umumnya sangat pendek, Rexx hanya mampu menanganinya bergilir. Request baru dilayani setelah request terkini selesai. Untuk lebih jelasnya serta tertarik untuk mencobanya, silakan klik ini. Lain kali saya akan memikirkan untuk membuatkan sarana agar Rexx mampu menangani multitasking atau multithreading.

HFS vs PDS/PDSE dalam hal Keamanan

zBogor hanyalah sebuah contoh dan fokusnya hanya untuk mempelajari bagaimana aplikasi Rexx untuk Socket API, bukan bagaimana membuat HTTP server di mainframe. Oleh karena itu dipilih hierarchical filesystem (HFS) untuk memudahkan pemahaman bagaimana server me-retrieve obyek manakala URI menunjuk nama file sesuai konvensi yang berlaku. Misal URI-nya /hallo, maka dengan mudah server me-retrieve file hallo di home directory. Jika URI-nya /abc/berita.txt maka server dengan mudah melacak file berita.txt di direktori /abc di home directory.

HFS di mainframe sama persis dengan HFS di platform lain. Orang usil yang ingin membobolnya bisa melakukannya dengan cara yang sama dengan yang biasa mereka lakukan. Yang penting menemukan path ke home directory-nya, lantas menembus permission mode-nya. Palling-paling mereka akan merasakan bagaimana menembus proteksi RACF atau ACF2 dibandingkan proteksi lain yang biasa mereka tembus. Sekali proteksi tembus, maka langkah selanjutnya tidak ada yang aneh.

Mengingat zBogor berada di mainframe, meskipun hanya WSSS, namun bisa dibuat jauh lebih aman dibanding server populer namun berada di luar mainframe. Caranya dengan menggantikan penggunaan HFS dengan partitioned dataset (PDS) atau partitioned dataset extended (PDSE). Dengan PDS/PDSE tentu tidak ada lagi home directory. Yang ada hanyalah definisi himpunan nama dataset mana yang digunakan sebagai wadah setiap jenis obyek. Misalnya untuk wadah dipilih nama dataset ZBOGORLIB diakses sebagai file dan ZBOGOR.JPEGLIB diakses sebagai file JPEG untuk mewadahi semua file jpg. Benisinya bisa melalui JCL (/ DD DSN=ZBOGORLIB) atau dinamik baik dengan ALLOC command (melibatkan TSO) maupun SVC 99 (tanpa TSO). Sehingga manakala datang permintaan dengan URI /hallo maka server mencarinya bukan di home directory, melainkan mencari member HALLO di file (DDname). Seolah-olah ada konversi URI dari /hallo menjadi /DD,MEMBER=HALLO. Ini akan sangat sulit dilacak jika konversinya dilakukan dengan compiled program dan keyword-nya dirahasiakan. Terlebih jika alokasi DD dilakukan secara dinamik, andaikan ada yang berhasil masuk lewat telnet dengan password curian pun akan kehabisan ide untuk melacak seluruh katalog untuk menemukan apa yang dicarinya. Hacker yang menguasai mainframe pun tidak mudah menemukannya, karena harus terlebih dulu menemukan parameter yang mendefinisikan bahwa file dengan extensi berada di dataset ZBOGORLIB. Katakanlah ada hacker yang tebakannya beruntung menemukannya, dia harus berhadapan dengan sekuriti RACF atau ACF2 yang belum pernah bobol sepanjang sejarah mainframe kecuali oleh adminnya sendiri.

Menjajal Ampuhnya Sekuriti Mainframe

Untuk menjajal keampuhan metode ini, silakan gunakan prosedur ASWEBX yang ada di zBogor.rar. Baca readme.txt dengan cermat untuk mempersiapkannya. Setelah up, anda bisa menjajal membobolnya. Memang kurang fair karena karena anda yang mempersiapkannya, tentu anda sudah tahu nama-nama PDS yang harus dibobol. Sehingga sangat tergantung bagaimana anda mempersiapkan security rule-nya. Tapi jika ada teman anda yang tidak ikut campur semasa persiapan, mungkin akan lebih baik. Pembobolan harus dilakukan dari luar TSO, karena TSO hanya diperuntukan kru server.

Server ini sangat sederhana, tidak menyediakan sarana login. Artinya, setiap browser yang konek dengan ASWEBX otomatis login dengan userid ASWEBX. Adilnya, userid ASWEBX harus memiliki akses read/write/execute terhadap semua PDS milik zBogor, agar kebobolan tidak mustahil. Selamat mencoba.

Kelemahan PDS/PDSE dapat meningkatkan Keamanan

PDS/PDSE lebih aman ketimbang HFS. Namun PDS/PDSE juga memiliki kelemahan, yaitu nama member yang terbatas (max) hanya 8 byte dan tidak adanya subdirectory. URI /goodmorning jelas menjadi kesulitan karena meskipun tidak ada subdirectory, tetapi tidak mungkin GOODMORNING bisa dijadikan nama member pada dataset PDS maupun PDSE. Demikian pula URI /a/toy.gif, akan sulit karena A/TOY tidak mungkin sah dijadikan nama PDS/PDSE member.

Semua kelemahan di atas sebenarnya jika kita mau mencermatinya dan menanganinya dengan teknik programming yang jitu, justru akan menjadi sebaliknya. Nama member PDS/PDSE memang tidak boleh lebih dari 8 byte. Subdirectory juga tidak ada dalam PDS/PDSE. Tetapi kita bisa membuatkan interface khusus untuk menjadikan kelemahan tersebut menjadi kelebihan. Kita bisa bikin formula untuk mengkonversi text panjang termasuk tanda garis miring maupun upper/lower case menjadi susunan 8 karakter yang sah sebagai nama member. Mirip long name dan short name di Windows. Dengan demikian, keberadaan obyek semakin sulit dilacak oleh yang tak berhak. Interface semacam ini juga disediakan oleh IBM untuk sistem z/OS, tetapi tidak mencakup subdirectory.

Topik-topik terkait

  1. Komputer Mainframe
  2. OS Mainframe
  3. GDPS – Konfigurasi Sistem Komputer Antar Kota Antar Propinsi
  4. Downsize – Manfaat apa Mudharat?
  5. Mainframe z/Enterprise, Cara Jitu Beternak Server
  6. Capacity Planning untukVirtualisasi
  7. Mainframe Solusi Paling Jitu untuk e-Gov
  8. Virtualisasi dengan z/VM makin Heboh

wpuser
dewi.sekarsari@yahoo.com
No Comments

Post A Comment