OPTIMASI AVAILABILITY MAIL SERVER DENGAN LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP) STUDI KASUS : PUSAT DATA INFORMASI DAN STANDARDISASI BADAN PENGKAJIAN DAN PENERAPAN TEKNOLOGI
Fatimah Indraswati 107091000065
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UIN SYARIF HIDAYATULLAH JAKARTA 2011 M/ 1432 H
Optimasi Availability Mail Server dengan Lightweight Directory Access Protocol (LDAP) Studi Kasus : Pusat Data Informasi dan Standardisasi Badan Pengkajian dan Penerapan Teknologi
Skripsi Sebagai Salah Satu Syarat untuk Memperoleh Gelar Sarjana Komputer Pada Fakultas Sains dan Teknologi UIN Jakarta
Oleh : Fatimah Indraswati 107091000065
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UIN SYARIF HIDAYATULLAH JAKARTA 2011 M/ 1432 H
ii
iii
iv
LEMBAR PERNYATAAN DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENARBENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI ATAU LEMBAGA MANAPUN.
Jakarta, 31 Oktober 2011
Fatimah Indraswati Penulis
v
ABSTRAK FATIMAH INDRASWATI, “Optimasi Availability Mail Server dengan Lightweight Directory Access Protocol (LDAP) Studi Kasus : Pusat Data Informasi dan Standardisasi Badan Pengkajian dan Penerapan Teknologi”, dibimbing oleh KHODIJAH HULLIYAH, M.Si dan FERI FAHRIANTO, M.Sc. Badan Pengkajian dan Penerapan Teknologi (BPPT) telah menggunakan Lighweight Directory Access Protocol (LDAP) server untuk manajemen user Zimbra mail server, physical topology LDAP yang telah diterapkan saat ini hanya menggunakan sebuah server eksternal LDAP. Jika server tersebut mengalami kegagalan, maka layanan email yang terintegrasi ke LDAP tidak dapat mengakses username dan password. Penggunaan LDAP karena sudah diterapkan di BPPT dan LDAP memiliki fitur jauh lebih lengkap, murah serta saat ini semakin populer juga karena redundan harus identik dengan master-nya. Optimasi availability LDAP dengan replikasi, merancang dan menerapkan sebuah LDAP eksternal server sebagai redundan yang dipasang secara paralel sehingga tercipta high availability. Replikasi yang digunakan adalah dengan pendekatan single master replication dengan replikasi syncrepl refreshAndPersist (provider push), yang merupakan model replikasi terbaru yang saat ini dimiliki oleh OpenLDAP versi 2.4 tetapi sudah dapat digunakan pada OpenLDAP versi 2.3. Penelitian menggunakan metode NDLC, Tahap analisis dan monitoring (pengujian) yang dilakukan sebelum dan setelah penerapan sebuah redundan selama masing-masing sekitar 1 bulan menggunakan NMS tools nagios untuk mendapat nilai availability. Tahap simulasi prototipe menyajikan perhitungan matematis secara manual dengan data yang didapat dari nagios. Availability LDAP provider sebelum replikasi adalah sebesar 93%. Setelah dilakukan replikasi availability gabungan LDAP provider-consumer server mencapai 99.958%.
Keyword : LDAP, Zimbra mail Server, availability, replikasi, openLDAP, Nagios, syncrepl refreshAndPersist
vi
KATA PENGANTAR Segala puji bagi Allah SWT penulis penjatkan karena berkat rahmat-Nya penulis mampu menyelesaikan skripsi ini dengan sebaik-baiknya, sehingga terlaksana sesuai dengan harapan. Shalawat dan salam selalu dilimpahkan kepada Nabi Muhammad SAW, keluarga dana para sahabat-sahabatnya Penulisan skripsi ini dibuat sebagai syarat kelulusan dalam menempuh pendidikan jenjang Strata-1 (S1) di Universitas Islam Negeri Syarif Hidayatullah Jakarta. Selain itu juga penulis berharap apa yang penulis teliti, yang dijelaskan di dalam skripsi ini, dapat dipergunakan dengan baik oleh semua pihak yang membutuhkan. Pada kesempatan ini, penulis mengucapkan terima kasih kepada pihak-pihak yang telah membantu penulis menyelesaikan skripsi ini : 1. Bapak DR. Syopiansyah Jaya Putra, M.Sis selaku Dekan Fakultas Sains dan Teknologi yang telah memberikan suatu komitmen, dorongan, dan program pendidikan sesuai kebutuhan mahasiswanya. 2. Bapak Yusuf Durachman, M.Sc, MIT dan Ibu Viva Arifin, MMSI selaku Ketua dan Sekretaris Program Studi Teknik Informatika. 3. Ibu Khodijah Hulliyah, S.Kom, M.Si dan Bapak Feri Fahrianto, M.Sc yang telah rela meluangkan waktunya untuk mendukung dan membimbing penulis dalam menyelesaikan skripsi ini. 4. Bapak dan Ibu penguji yang memberikan kritik dan saran pada skripsi ini. 5. Ibu Kuwati dan Bapak Sukur, kedua orang tua yang selalu memberikan cinta kasih, dukungan moril serta materil yang selamanya tidak akan pernah dapat terbalas. Momito dan Papito <3 6. Kakak-kakak penulis Mba Endah, Mas Rizal, terima kasih atas semuanya.dan Abdurrahman Farras Alfatih, penghibur hati di saat penulisan skripsi ini terasa menjenuhkan. 7. Bapak Dr.Ir.Taslim Rochmadi, Dipl.Ing, selaku Kepala Sub Bidang Sistem dan Jaringan, Bapak Ir. Amir Dahlan, M.Kom, Bapak Agung Septiadi, Bapak Imam Cartealy, dan Bapak Ardhiyan, serta seluruh staff Pusat Data Informasi dan Standardisasi (PDIS) Badan Pengkajian dan Penerapan Teknologi (BPPT)
vii
yang telah membantu dan menyediakan data pendukung pada penulisan skripsi ini. 8. Bapak Andrew Fiade, M.Kom dan Ibu Arini, MT selaku penguji skripsi yang telah memberikan saran-saran untuk penulisan skripsi ini. 9. Segenap dosen dan pegawai Fakultas Sains dan Teknologi serta semua pihak yang tidak dapat disebutkan satu persatu, yang telah banyak membantu dalam penulisan skripsi ini. 10. Teman-teman TI A 2007, TI B Networking, CISCO Angkatan 05, kakak adik kelas yang selalu memberi semangat, dan seluruh kawan-kawan angkatan 2007 yang sama-sama berjuang dalam masa perkuliahan ini. 11. Sahabat dupa khususnya doetcom citra, putri, icha, endang, dan nyun. Sahabat liqo dan alumni SMAN 3 TANGERANG. Sahabat dari kampus tercinta maryam, hana, juni, tika, ming, siti, fahra, ika, ade, voly, shalihah,dede, inge dan semuanya. Terima Kasih 12. Keluarga Khuntorian, Khuntorialurve, Khuntoriapantip, Khuntoriaeffects,para subber, dan KhunToria. Teman-teman social networking, terutama mbah derma terima kasih telah menghibur penulis dengan kutipan-kutipannya. Penulis menyadari masih terdapat banyak kekurangan dalam penulisan maupun penelitian di skripsi ini. Oleh karena itu penulis mengharapkan saran dan kritik membangun agar skripsi ini lebih baik lagi. Akhir kata, penulis mengucapkan banyak terima kasih. Semoga skripsi ini dapat bermanfaat bagi semua pihak yang berkepentingan.
Tangerang, 31 Oktober 2011
Fatimah Indraswati
viii
DAFTAR ISI
Halaman Halaman Judul .............................................................................................. ii Lembar Persetujuan Pembimbing .................................................................. iii Lembar Pengesahan Ujian ............................................................................ iv Lembar Pernyataan ....................................................................................... v Abstrak ......................................................................................................... vi Kata Pengantar ............................................................................................. vii Daftar Isi ...................................................................................................... ix Daftar Gambar .............................................................................................. xiv Daftar Tabel.................................................................................................. xvi Daftar Lampiran ........................................................................................... xvii Daftar Istilah ................................................................................................. xviii
BAB I PENDAHULUAN 1.1 Latar Belakang .................................................................................. 1 1.2 Rumusan Masalah ............................................................................. 3 1.3 Batasan Masalah ............................................................................... 3 1.4 Tujuan Penelitian .............................................................................. 4 1.5 Manfaat Penelitian ............................................................................ 4 1.6 Metodologi Penelitian ....................................................................... 4 1.6.1 Metode Pengumpulan Data .................................................... 4
ix
1.6.2 Metode Pengembangan Sistem .............................................. 5 1.7 Sistematika Penulisan ........................................................................ 6
BAB II TINJAUAN PUSTAKA 2.1 Teori Umum .................................................................................... 8 2.1.1 Jaringan Komputer ................................................................ 8 2.1.2 Lapisan OSI (Open System Interconnection) .......................... 9 2.1.3 Lapisan TCP/IP (Transmission Control Protocol) .................. 10 2.1.4 Macam Jaringan .................................................................... 11 2.1.5 Client-Server ......................................................................... 13 2.1.6 NDLC (Network Development Life Cycle Network) ............... 14 2.1.6.1 Analisis ............................................................................ 16 2.1.6.2 Desain............................................................................. 16 2.1.6.3 Simulasi Prototipe .......................................................... 16 2.1.6.4 Implementasi .................................................................. 16 2.1.6.5 Monitoring ...................................................................... 17 2.1.6.6 Manajemen .................................................................... 17 2.2 LDAP ............................................................................................... 18 2.2.1 Lightweight ............................................................................ 18 2.2.2 Directory ............................................................................... 19 2.2.3 Access Protocol ..................................................................... 21 2.2.4 Model LDAP ......................................................................... 21 2.2.5 DIT........................................................................................ 24
x
2.2.6 LDIF ..................................................................................... 25 2.2.7 Replication ............................................................................ 26 2.2.7.1 Strategi Replikasi ........................................................... 28 2.3 Availability....................................................................................... 32 2.3.1 Availability (Ketersediaan) .................................................... 32 2.3.1.1 Reliability (Keandalan) ................................................. 36 2.4 OpenLDAP ....................................................................................... 36 2.4.1 Replikasi OpenLDAP ............................................................ 38 2.4.1.1
Replikasi dengan Slurpd ............................................... 39
2.4.1.2
Replikasi dengan Syncrepl ............................................ 40
a. Replikasi refreshOnly (Consumer Pull) ......................... 41 b. Replikasi refreshAndPersist (Provider Push) ................ 42 2.5 Centos ............................................................................................... 43 2.6 Zimbra Mail Server ........................................................................... 45 2.7 Nagios............................................................................................... 48
BAB III METODOLOGI PENELITIAN 3.1 Waktu dan tempat Penelitian ............................................................. 52 3.2 Jenis Penelitian.................................................................................. 52 3.3 Metode Pengumpulan Data ............................................................... 53 3.3.1 Studi Pustaka dan Literatur Sejenis ........................................ 53 3.3.2 Observasi............................................................................... 55 3.3.3 Wawancara ............................................................................ 55
xi
3.4 Metode Pengembangan Sistem .......................................................... 56 3.4.1 Analisis ................................................................................. 56 3.4.2 Desain ................................................................................... 56 3.4.3 Simulasi Prototipe ................................................................. 56 3.4.4 Implementasi ......................................................................... 57 3.4.5 Monitoring ............................................................................ 57 3.4.6 Manajemen ............................................................................ 57
BAB IV HASIL DAN PEMBAHASAN 4.1 Analisis ............................................................................................. 59 4.1.1 Analisis Sistem yang Sedang Berjalan ................................... 59 4.1.2 Analisis Topologi/ Jaringan ................................................... 62 4.1.3 Analisis Permasalahan ........................................................... 66 4.1.3.1
Instalasi Nagios............................................................. 66
4.2 Desain/ Perancangan ......................................................................... 73 4.2.1 Desain Topologi Fisik ............................................................ 74 4.2.2 Desain Topologi Logis........................................................... 75 4.3 Simulasi prototipe ............................................................................. 76 4.4 Implementasi..................................................................................... 78 4.4.1 Instalasi OpenLDAP .............................................................. 85 4.4.2 Replikasi ............................................................................... 81 4.4.2.1 Provider .................................................................. 81 4.4.2.2 Consumer ............................................................... 85
xii
4.4.2.3 Integrasi Zimbra+LDAP Consumer Server .............. 87 4.5 Monitoring ....................................................................................... 91 4.5.1 Pengujian proses replikasi direktori LDAP ....................... 91 4.5.2 Pengujian Login Email..................................................... 93 4.5.3 Evaluasi ........................................................................... 94 4.6 Manajemen ..................................................................................... 95 BAB V PENUTUP 5.1 Kesimpulan ...................................................................................... 96 5.2 Saran ................................................................................................. 96
DAFTAR PUSTAKA ................................................................................ 98 LAMPIRAN-LAMPIRAN
xiii
DAFTAR GAMBAR
Gambar 2.1 Siklus NDLC ............................................................................. 14 Gambar 2.2 Diagram Skema LDAP .............................................................. 22 Gambar 2.3 Contoh Pohon Direktori LDAP .................................................. 25 Gambar 2.4 Single-Master Replication ......................................................... 29 Gambar 2.5 Replication Options – Referrals ................................................. 30 Gambar 2.6 Replication Options – Chaining ................................................. 31 Gambar 2.7 Multimaster Replication ............................................................ 32 Gambar 2.8 Sistem Pemasangan Seri ............................................................ 34 Gambar 2.9 Sistem Pemasangan Paralel ........................................................ 35 Gambar 2.10 Diagram keempat komponen OpenLDAP ............................... 38 Gambar 2.11 Slurpd Style Replication........................................................... 39 Gambar 2.12 Replikasi refreshOnly .............................................................. 41 Gambar 2.13 Replikasi refreshAndPersist ..................................................... 42 Gambar 3.1 Ilustrasi Metodologi Penelitian .................................................. 58 Gambar 4.1 Topologi logis jaringan .............................................................. 62 Gambar 4.2 Topologi fisik jaringan............................................................... 64 Gambar 4.3 Nagios Interface ........................................................................ 70 Gambar 4.4 Grafik Availability LDAP master 11 Juli s.d 12 Agustus 2011 ... 72 Gambar 4.5 Desain penambahan 1 buah replika LDAP server dalam topologi fisik jaringan BPPT ........................................................................ 74 Gambar 4.6 Desain topologi logik replikasi LDAP master-slave server ........ 75
xiv
Gambar 4.7 Sistem Pemasangan Paralel ........................................................ 76 Gambar 4.8 Pencarian file instalasi OpenLDAP ............................................ 79 Gambar 4.9 Proses instalasi OpenLDAP ....................................................... 79 Gambar 4.10 Instalasi OpenLDAP berhasil ................................................... 80 Gambar 4.11 Membuat password LDAP ....................................................... 80 Gambar 4.12 Perintah menyalin file DB_CONFIG........................................ 81 Gambar 4.13 Memulai LDAP ....................................................................... 81 Gambar 4.14 Konfigurasi client LDAP ......................................................... 84 Gambar 4.15 Memasukan data ke LDAP ...................................................... 85 Gambar 4.16 Authentication Setting .............................................................. 87 Gambar 4.17 Tambah LDAP url di Authentication Setting ............................ 88 Gambar 4.18 Membuat password bind .......................................................... 89 Gambar 4.19 Authentication Setting Zimbra ................................................. 89 Gambar 4.20 Authentication Test Succesful.................................................. 90 Gambar 4.21 Domain Configure Complete ................................................... 90 Gambar 4.22 Login dengan phpLDAPadmin ................................................ 92 Gambar 4.23 Sukses Login ke server LDAP ................................................. 92 Gambar 4.24 Hentikan layanan LDAP .......................................................... 93 Gambar 4.25 Login Email ............................................................................. 94 Gambar 4.26 Halaman Akun Email............................................................... 94 Gambar 4.27 Data Availability tanggal 12 Agustus s.d 12 September 2011 .. 95
xv
DAFTAR TABEL
Tabel 2.1 Lapisan OSI .................................................................................. 10 Tabel 2.2 Lapisan TCP / IP ........................................................................... 11 Tabel 2.3 Atribut yang Umum Digunakan..................................................... 23 Tabel 2.4 Perbandingan availability dan downtime ....................................... 35 Tabel 2.5 Perbandingan Komponen Individu dan Gabungan Seri .................. 35 Tabel 2.6 Perbandingan Komponen Individu dan Gabungan Paralel ............. 36 Tabel 2.7 Hubungan antara Availability dan Reliability................................. 37 Tabel 4.1 Atribut pada LDAP di BPPT ......................................................... 60 Tabel 4.2 Spesifikasi perangkat keras dan perangkat lunak ........................... 65 Tabel 4.3 Minimum Requirement ................................................................. 65
xvi
DAFTAR LAMPIRAN
LAMPIRAN A ( Surat Keterangan Riset) LAMPIRAN B (Wawancara) LAMPIRAN C (Konfigurasi Provider & Consumer Server) LAMPIRAN D (Instalasi Centos & phpLDAPadmin) LAMPIRAN E (Analisis dan Monitoring dengan Nagios)
xvii
DAFTAR ISTILAH Istilah
Arti
Availability
Probabilitas bahwa suatu produk beroperasi dan dalam bagian yang ditentukan bila diperlukan. Dalam kata lain, probabilitas bahwa item tidak gagal atau tidak mengalami perbaikan.
LDAP
Layanan menyediakan bermacam-macam mekanisme untuk otentikasi yang merupakan sebuah direktori digital yang menyerupai direktori address book, jenis database dimana data dapat diatur seperti struktur pohon dengan sebuah hirarki sistem file.
Optimasi
Memaksimalkan atau mengoptimalkan sesuatu hal yang bertujuan untuk mengelola sesuatu yang dikerjakan, optimasi bisa dianggap baik sebagai ilmu pengetahuan dan seni menurut tujuan yang ingin dimaksimalkan.
Reliability
Probabilitas komponen atau bagian dari sistem untuk melakukan fungsinya pada waktu tertentu tanpa kegagalan.
Replikasi
Proses mempertahankan beberapa salinan data direktori di lokasi yang berbeda.
Zimbra Mail Server
server khusus yang mengelola seluruh isi mailbox, termasuk pesan, kontak, kalender, dan attachment.
xviii
BAB I PENDAHULUAN
1.1 Latar Belakang Perkembangan pertukaran informasi dimana sangat banyak pemakai teknologi yang menggunakan layanan dan data yang sama dengan tingkat akses yang berbeda. Sama halnya pada teknologi jaringan internet yang terus bergerak maju seiring dengan perkembangan teknologi. Jaringan internet saat ini merupakan suatu hal yang penting dalam sebuah perusahaan atau instansi. Dengan adanya jaringan internet, kegiatan komunikasi yang dilakukan menjadi lebih mudah, efektif, hemat waktu dan berbagai manfaat lainnya. Ketika suatu jaringan sudah dibuat dan diaplikasikan, selanjutnya diperlukan optimasi agar jaringan yang sudah diaplikasikan semakin baik dan maksimal kinerjanya. Selain itu, perkembangan teknologi jaringan komputer juga sangat pesat, suatu model komputer tunggal yang melayani seluruh tugas-tugas komputasi suatu organisasi sekarang telah digantikan oleh sekumpulan komputer yang terpisah-pisah dan saling berhubungan dalam menyelesaikan tugasnya. Badan Pengkajian dan Penerapan Teknologi (BPPT) merupakan salah satu instansi nonkementrian yang memiliki sekitar tiga ribu orang pegawai. Pada penelitian skripsi sebelumnya, BPPT telah menggunakan sistem email baru bagi seluruh pegawainya. Sistem email baru ini berbasis Zimbra dan
1
2
manajemen user-nya diintegrasikan dengan Lighweight Directory Access Protocol (LDAP), dengan sistem email yang baru ini maka diharapkan seluruh pegawai hanya menggunakan email dengan domain bppt.go.id untuk keperluan dinas, akun email tersebut menjadi satu-satunya akun yang dimiliki oleh user pegawai BPPT, untuk mengakses layanan-layanan lain yang akan dikembangkan di BPPT. Pada dasarnya, LDAP merupakan layanan yang biasa digunakan pada perkembangan terakhir ini yang berkaitan dengan teknologi informasi dimana sering terjadinya otentikasi informasi dalam berbagai layanan. LDAP dirancang untuk menyediakan sebuah direktori digital yang menyerupai direktori address book, jenis database dimana data dapat diatur seperti struktur pohon dengan sebuah hirarki sistem file. LDAP menyediakan bermacam-macam mekanisme untuk otentikasi dengan lapisan yang kuat dari layanan seperti mencari dengan filter yang kompleks, menunjukan data yang kompleks dengan atribut, yang memungkinkan akses parsial dan terbatas ke data sehingga penanganan kontrol akses yang lengkap dan login informasi pengguna. (Salim et al, 2009:1) Latar belakang adanya permasalahan dalam penulisan skripsi ini adalah karena telah diterapkannya otentikasi dan otorisasi LDAP dalam jaringan di BPPT. Physical topology LDAP yang telah diterapkan saat ini hanya menggunakan sebuah server. Jika terjadi error, maka server tidak dapat diakses dan layanan email yang terkoneksi ke LDAP juga tidak tidak akan bisa diakses. Pada skripsi ini menggunakan LDAP karena LDAP
sudah
diterapkan di BPPT dan memiliki fitur jauh lebih lengkap, murah serta saat
3
ini semakin populer. Untuk lebih meningkatkan fungsi LDAP maka topologi yang sudah berjalan perlu diinvestigasi sehingga penggunaanya lebih optimal dalam hal availability agar jaringan internet menjadi lebih terjamin.
1.2 Rumusan Masalah Dari penjelasan pada latar belakang diatas, maka ditetapkan suatu rumusan masalah yang juga sekaligus menjadi pertanyaan penelitian sebagai berikut : Bagaimana
cara
mengoptimasi
availability
LDAP
dengan
replikasi
(merancang LDAP slave untuk redundancy) sehingga tercipta high availability ?
1.3 Batasan Masalah Dalam penulisan skripsi ini, penulis membatasi masalah sebagai berikut : a. Daerah kerja dilakukan di BPPT Thamrin pada unit kerja Pusat Data Informasi dan Standardisasi (PDIS). b. Investigasi dan optimasi LDAP dalam hal availability. c. Hanya menggunakan 1 redundancy/ replika. d. Penggunakan Network Management System (NMS) tools yaitu Nagios dalam memonitoring jaringan. e. Kedua server dalam keadaan menyala, saat pengujian mematikan layanan LDAP master.
4
f. Metode pengembangan sistem menggunakan NDLC, tahap analisis & monitoring dilakukan masing-masing selama sebulan. Tahap implementasi belum diimplementasikan oleh BPPT tetapi uji coba dilakukan dengan perangkat yang real. g. Komunikasi client-server yang dibahas yaitu sistem operasi Centos 5.6 sebagai server. 1.4 Tujuan Mengoptimasi
kinerja
LDAP
yang
sudah
diterapkan
untuk
meningkatkan availability sehingga dapat bekerja dengan lebih baik dan semakin bermanfaat.
1.5 Manfaat Penelitian Adapun manfaat dari penelitian dan penyusunan skripsi ini adalah sebagai berikut : 1. Mengembangkan lebih lanjut topologi LDAP yang sudah diterapkan sebelumnya. 2. Memaksimalkan resource hardware yang ada dan telah digunakan pada penerapan LDAP sebelumnya.
1.6 Metode Penelitian 1.6.1 Metode Pengumpulan Data 1) Studi Pustaka dan Literatur Sejenis
5
Pengumpulan data yang bersumber dari berbagai buku, jurnal, karya ilmiah baik dari media cetak maupun media elektronik yang berkaitan dengan LDAP. 2) Observasi atau pengamatan langsung Pengambilan data dan informasi serta pengamatan langsung terhadap fasilitas dan perangkat jaringan di BPPT. 3) Wawancara 1.6.2 Metode Pengembangan Sistem Metode pengembangan sistem yang digunakan pada penulisan ini adalah NDLC (Network Development Life Cycle), dimana metode pengembangan ini mempunyai enam tahapan yaitu: 1. Analisis, pada tahap awal ini dilakukan analisis kebutuhan, analisis permasalahan yang muncul, analisis kebutuhan user, dan analisis topologi / jaringan yang sudah ada saat ini. 2) Desain,
dari
data-data
yang
didapatkan
sebelumnya,
tahap
perancangan ini akan membuat gambar desain topologi jaringan interkoneksi yang akan dibangun secara fisik dan logis, diharapkan dengan gambar ini akan memberikan
gambaran seutuhnya dari
kebutuhan yang ada. 3) Simulasi Prototipe, pada tahap ini akan dibuat dalam bentuk simulasi dengan perhitungan matematis dengan rumus. 4) Implementasi, tahapan ini penulis akan menerapkan semua yang telah direncanakan dan dirancang sebelumnya pada server sebenarnya.
6
5) Monitoring, setelah implementasi tahapan monitoring merupakan tahapan yang penting, agar jaringan komputer dan komunikasi dapat berjalan sesuai dengan keinginan dan tujuan awal dari user pada tahap awal analisis, maka perlu dilakukan kegiatan monitoring. 6) Manajemen, tahapan terakhir ini salah satu yang menjadi perhatian khusus adalah masalah policy, kebijakan perlu dibuat untuk membuat/ mengatur agar sistem yang telah dibangun dan berjalan dengan baik dapat berlangsung lama dan unsur reliability terjaga. Proses manajemen akan dilakukan sesuai dengan Standard Operating Procedure (SOP) yang ada di unit kerja PDIS.
1.7 Sistematika Penulisan Penulisan skripsi dibagi menjadi lima bab. Adapun sistematika dalam penyusunan adalah sebagai berikut : BAB I
PENDAHULUAN Dalam bab ini dibahas tentang latar belakang, perumusan masalah, batasan masalah, tujuan penelitian, manfaat penelitian, metodologi dan sistematika penulisan.
BAB II
TINJAUAN PUSTAKA Bab ini menguraikan teori umum yang berkaitan dengan jaringan LDAP, availability, dan hal lain yang terkait dengan pembahasan.
BAB III
METODOLOGI PENELITIAN
7
Bab ini penulis menerangkan tentang metodologi penelitian yang digunakan serta langkah-langkah yang digunakan terkait dengan penelitian yang dilakukan. BAB IV
HASIL DAN PEMBAHASAN Bab ini berisi penjelasan untuk implementasi sistem, hasil evaluasi secara umum dari sistem yang dikembangkan dan penjelasannya.
BAB V
KESIMPULAN DAN SARAN Bab ini merupakan akhir dari hasil evaluasi yang berisi tentang kesimpulan dan saran. Pada bab penutup ini yang diakhiri dengan beberapa lampiran.
BAB II TINJAUAN PUSTAKA
Pada bab ini, akan diuraikan tinjauan pustaka yang berkaitan dengan skripsi ini. Penjelasan mengenai teori umum tentang jaringan komputer, lapisan OSI, lapisan TCP/IP, macam jaringan, dan metode NDLC. Selain itu juga akan diuraikan mengenai teori tentang LDAP, availability, openLDAP, sistem operasi Centos, Zimbra Mail Server, dan Nagios.
2.1 Teori Umum 2.1.1 Jaringan Komputer Jaringan komputer adalah kumpulan sejumlah peripheral yang terdiri dari beberapa komputer, printer, LAN card, dan peralatan lain yang saling terintegrasi satu sama lain. Sehingga kita dapat melakukan aktivitas tukarmenukar data atau informasi dengan mudah dan dalam waktu yang singkat dan cepat. (Kurniawan, 2007:2). Banyak manfaat yang dapat diperoleh apabila komputer kita terhubung dengan jaringan, diantaranya adalah :
Dapat saling berbagi pemakaian file data (data sharing) dengan komputer rekan.
Tukar-menukar data antar komputer dapat kita lakukan secara cepat.
Memungkinkan kita untuk memakai satu printer yang terhubung dengan jaringan secara bersama-sama dalam area jaringan. 8
9
Lebih menghemat biaya.
Efisiensi kerja menjadi meningkat.
File-file dapat lebih mudah dipelihara dan diproteksi.
Kinerja sistem dapat ditingkatkan sesuai dengan beban pemakaian komputer di jaringan. Kita hanya cukup menambah kemampuan processor jika membutuhkan peningkatan kinerja.
2.1.2 Lapisan OSI (Open Systems Interconnection) Model ini dikembangkan oleh International Organization for Standardization (ISO) sebagai langkah pertama menghadapi standardisasi internasional dari protokol yang digunakan di berbagai macam lapisan. Semua subsistem komunikasi dibagi menjadi tujuh lapisan. Pembagian ini untuk menentukan berbagai macam fungsi dan sistem operasi. Tujuan pembagian lapisan ini adalah mempermudah pelaksanaan aturan standar secara praktis. Pembagian ini juga memmungkinkan fleksibilitas, artinya apabila terjadi perubahan pada salah satu lapisan maka tidak berpengaruh pada lapisan lain.(Kurniawan, 2007:5)
10
No 1
Lapisan Physical
2
Data Link
3
Network
4
Transport
5
Session
6
Presentation.
7
Application
Tabel 2.1 Lapisan OSI Tugas Bertanggung jawab atas proses data menjadi bit dan mentransfernya melalui media, seperti kabel, dan menjaga koneksi fisik antar sistem. Menyediakan hubungan fisik dan kebutuhan untuk mengaktifkan, memperbarui, dan mengaktifkan kembali koneksi. Mengelola kebutuhan untuk mentransfer informasi diantara sistem akhir sampai ke beberapa jaringan komunikasi. Menerima data dari layer di atasnya, memecahnya menjadi unit-unit yang lebih kecil, lalu meneruskannya ke layer network, dan memastikan bahwa semua bagian diterima dengan baik. Menyediakan transaksi komunikasi antara dua atau lebih peralatan jaringan. Menyediakan format data yang akan ditukar ke application layer, menyediakan sintaks yang digunakan dalam application layer. Menyediakan berbagai macam protokol yang biasa digunakan oleh user, misalnya HTTP.
2.1.3 Lapisan TCP/IP (Transmission Control Protocol / Internet Protocol) TCP/IP dipakai karena bersifat fleksibel dan mudah digunakan. Model lapisan ini dikembangkan oleh U.S. Departement of Defense (DoD) pada tahun 1970-an untuk mendukung pembangunan jaringan internet di seluruh dunia. Model TCP/IP sudah berkembang dan dinikmati secara luas sebelum ISO menetapkan model ini sebagai protokol alternatif selain OSI. Dalam penerapannya, TCP/IP menggunakan protokol sampai dengan 4 level fungsi lapisan dalam arsitektur protokol seperti dapat dilihat pada tabel dibawah ini.
11
Lapisan Network
Tabel 2.2 Lapisan TCP / IP Tugas Sebagai jalur untuk mengirimkan paket-paket IP antara host dengan network.
Internet
Menentukan format paket yang dikirimkan dan mengirimkannya melalui satu atau lebih jaringan yang terkoneksi.
Transport
Menerima data dari layer di atasnya, memecahnya menjadi
unit-unit
yang
lebih
kecil,
lalu
meneruskannya ke layer intenet, dan memastikan bahwa semua bagian diterima dengan baik. Application
Menyediakan berbagai macam protokol yang biasa digunakan oleh user, misalnya HTTP.
2.1.4
Macam Jaringan
Macam jaringan komputer bila dilihat berdasarkan lingkup dan luas jangkauannya, dibedakan menjadi beberapa macam : 1) LAN (Local Area Network) LAN merupakan suatu jaringan yang masih berada di dalam gedung atau ruangan. Dalam membuat jaringan LAN, minimal kita harus menyediakan dua buah komputer yang masing-masing memiliki kartu jaringan.
Keuntungan
menggunakan
LAN
diantaranya
dapat
menghubungkan komputer dalam jumlah banyak, akses antar komputer berlangsung cepat dan mudah, dapat saling bertukar informasi dengan pengguna di luar area apabila terhubung dengan internet, back up data
12
tanpa harus bongkar harddisk, hemat waktu dan biaya dalam pengiriman paket data. 2) MAN (Metropolitan Area Network) Sebuah jaringan komputer, membentang di wilayah geografis yang besar seperti daerah perkotaan dan menyediakan jasa komunikasi terpadu seperti data, suara, dan video. (IEEE 802-2002: 4) Letak jaringan ini bisa saling berjauhan tergantung dari panjang kabel yang digunakan. Jaringan ini juga dapat menjangkau lokasi yang berbeda tempat. MAN biasanya digunakan oleh sebuah perusahaan dalam suatu kota, antar kampus atau universitas, dan lain-lain. 3) WAN (Wide Area Network) MAN merupakan bentuk jaringan komputer yang terdiri dari LAN dan MAN. Jaringan WAN telah memenuhi berbagai kebutuhan system jaringan. MAN menggunakan protokol internet berupa Network Service Provider (NSP). Tanpa NSP maka jaringan MAN tidak akan bekerja. Dengan adanya NSP yang dihubungkan dengan WAN, maka akan membentuk suatu jaringan internet yang bersifat global. Kelebihan jaringan WAN diantaranya apabila terhubung dengan internet transfer file pada tempat yang saling berjauhan dapat dilakukan dengan cepat menggunakan email dan FTP (File Transfer Protocol), cakupan jaringan yang luas, dan lain-lain.
13
4) Internet Internet merupakan gabungan dari berbagai LAN dan WAN yang berada di seluruh jaringan komputer dunia, sehingga terbentuk jaringan dengan skala yang lebih luas dan global. (Kurniawan, 2007:20). Jaringan internet biasanya menggunakan protokol TCP/IP dalam pengiriman paket data.
2.1.5 Client-Server Menurut Agus Mulyanto (2009 : 41), mendefinisikan client-server sebagai arsitektur yang paling banyak digunakan saat ini. Dimana client dapat melakukan proses sendiri, ketika client meminta data, server akan mengirimkan data sesuai yang diminta, kemudian proses akan dilakukan di client. Arsitektur client-server memiliki kelebihan sebagai berikut : 1. Pemrosesan dapat dilakukan di komputer client, sehingga data dapat diproses sesuai dengan kebutuhan client. 2. Proses bisnis tetap akan berjalan meskipun terjadi kemacetan mesin. 3. Pada arsitektur client-server hanya dibutuhkan mesin-mesin yang sederhana, sehingga dapat mengurangi biaya dalam membangun sistem. 4. Mudah dalam melakukan upgrade pada perangkat sistem. 5. Dapat menggunakan berbagai platform aplikasi pada client.
14
2.1.6 NDLC (Network Development Life Cycle)
Gambar 2.1 Siklus NDLC (Sumber : Goldman et al, 2004: 470) Kata cycle atau siklus di dalam NDLC menunjukkan bahwa perkembangan jaringan akan berlangsung secara terus menerus. Selain itu, sebuah jaringan yang didesain dari awal, pasti harus dimulai di satu titik, yaitu tahap analisis. Jaringan yang sudah ada juga terus mengalami perkembangan dari satu tahap ke tahap yang lain dalam NDLC. Misalnya, tahap monitoring dari jaringan yang sudah ada akan menyebabkan terjadinya tahap manajemen dan menghasilkan statistik performa dengan menggunakan protokol manajemen jaringan seperti SNMP. Kemudian, analis jaringan akan menganalisis statistik performa dari jaringan yang sudah ada tersebut. Hasil dari analisis jaringan statistik performa
ini
akan
menentukan
apakah
desain
jaringan
akan
diimplementasikan atau tidak. Dari data-data yang didapatkan sebelumnya, tahap perancangan ini akan membuat gambar desain topologi jaringan interkoneksi yang akan dibangun secara fisik dan logis, diharapkan dengan gambar ini akan memberikan gambaran seutuhnya dari kebutuhan yang ada.
15
Desain
jaringan
yang
berubah,
pertama-tama
akan
disimulasikan
menggunakan perangkat lunak simulasi jaringan yang canggih atau dibuat prototype-nya
untuk
dilakukan
tes,
sebelum
dikembangkan
atau
diimplementasikan. Implementasi, tahapan ini mulai diterapkan semua yang telah direncanakan dan dirancang sebelumnya pada server sebenarnya. Siklus dari analisis, desain, simulasi, implementasi, monitoring, dan manajemen ini bersifat terus-menerus. Ini merupakan tuntutan dari sebuah jaringan yang berada pada kondisi terus-menerus berubah karena perubahan dalam bisnis, aplikasi, atau kebutuhan data, sehingga desain jaringan sendiri harus bersifat dinamis supaya bisa mendukung perubahan-perubahan kebutuhan ini. (Goldman, 2004:378). Berkaitan dengan penelitian ini, penerapan dari setiap tahapan NDLC adalah sebagai berikut : 2.1.6.1 Analisis Model pengembangan sistem NDLC dimulai pada fase analisis. Pada tahap ini meliputi : a. Identify Kegiatan mengidentifikasi permasalahan yang dihadapi sehingga dibutuhkan proses penerapan sistem. b. Understand Kegiatan untuk memahami mekanisme kerja sistem yang akan dibangun.
16
c. Analyze Menganalisis sejumlah elemen atau komponen dan kebutuhan sistem yang akan dibangun. d. Report Kegiatan mempresentasikan proses hasil analisis. 2.1.6.2 Desain Tahapan
selanjutnya
adalah
desain.
Jika
tahap
analisis
mendefinisikan apa yang harus dilakukan oleh sistem, maka pada tahap desain mendefinisikan “Bagaimana cara sistem tersebut melakukannya?”. 2.1.6.3 Simulasi Prototipe Tahapan selanjutnya adalah simulasi prototipe dimana penulis membuat prototipe sistem yang akan dibangun sebagai simulasi dan implementasi. Sehingga penulis dapat mengetahui gambaran umum dari proses komunikasi, saling keterkaitan dan mekanisme kerja dari interkoneksi keseluruhan elemen sistem yang akan dibangun. 2.1.6.4 Implementasi Pada tahap ini, rancangan yang dilakukan pada tahap desain digunakan sebagi panduan instruksi untuk implementasi. Kegiatan pada tahap ini meliputi implementasi konsep sistem yang akan digunakan.
17
2.1.6.5 Monitoring Pada metode NDLC, proses pengujian digolongkan pada tahap ini dikarenakan sudah melalui aktifitas pengoperasian dan pengamatan sistem yang sudah dibangun dan dikembangkan serta sudah diimplementasikan untuk memastikan penerapan sistem yang sudah berjalan. 2.1.6.6 Manajemen Kegiatan perawatan, pemeliharaan, dan pengelolaaan dikategorikan pada tahap ini karena proses pengelolaan sejalan dengan kegiatan pemeliharaan sistem yaitu meliputi pengelolaan sistem untuk digunakan secara luas sebagai solusi yang lebih ekonomis untuk berbagai
keperluan
sehingga
akan
menjamin
kemudahan,
fleksibilitas dan pengelolaan serta pengembangan sistem.
2.2 LDAP (Lightweight Directory Access Protocol) LDAP
merupakan
layanan
yang
biasa
digunakan
dalam
perkembangan terakhir ini yang berkaitan dengan teknologi informasi dimana sering terjadinya otentikasi informasi dalam berbagai layanan. LDAP dirancang untuk menyediakan sebuah direktori digital yang menyerupai direktori address book, jenis database dimana data dapat diatur seperti struktur pohon dengan sebuah hirarki sistem file. LDAP menyediakan bermacam-macam mekanisme untuk otentikasi dengan lapisan layanan yang kuat dari layanan seperti mencari dengan filter yang kompleks,
18
menunjukan data yang kompleks dengan atribut, yang memungkinkan akses parsial dan terbatas ke data dan sehingga penanganan kontrol akses lengkap dan login informasi pengguna. (Salim et al, 2009:1). LDAP dapat menyatukan layanan-layanan yang ada menjadi sebuah direktori tunggal yang bisa diakses oleh client LDAP dari berbagai macam vendor. Client tersebut dapat berupa web browsers, mail servers, email clients, atau berbagai macam aplikasi lainnya. Dengan mengorganisasi informasi-informasi dengan dengan baik dan berpikir hati-hati tentang informasi yang biasa dibutuhkan oleh aplikasi client, redundansi data dalam direktori dapat dikurangi dan dengan begitu mengurangi biaya administrasi yang diperlukan untuk memelihara data serta dapat menyederhanakan manajemen direktori dan total biaya kepemilikan.
2.2.1 Lightweight LDAP dikatakan lightweight karena LDAP berakar dari X.500 yang mendapat gelar heavyweight. X.500 adalah sebuah layanan directory yang lebih besar dan lebih kompleks daripada LDAP. LDAP sebenarnya didesain sebagai Directory Access Protocol (DAP) untuk layanan directory X.500 karena sumber daya yang dibutuhkan oleh X.500 terlalu berat. Selain itu, LDAP juga menyederhanakan beberapa operasi X.500 dan menghilangkan beberapa fitur yang hanya dimengerti oleh orang-orang tertentu saja. Pada X.500, client dan server berkomunikasi menggunakan protokol stack Open Systems Interconnection (OSI). Stack dengan tujuh layer ini
19
memang bagus untuk mendesain rangkaian protokol jaringan tapi ketika dibandingkan dengan rangkaian protokol TCP/IP, OSI 7 layer menjadi terlihat sangat berat. LDAP menggunakan pesan udara tingkat rendah yang dipetakan secara langsung ke dalam layer TCP (biasanya port 389) dari stack protokol TCP/IP. Karena X.500 adalah protokol layer aplikasi, ini membawa lebih banyak beban karena header jaringan dibungkus di sekeliling paket di setiap layer sebelum akhirnya ditransmisikan ke jaringan. (Carter, 2003:14).
2.2.2 Directory Directory secara umum berarti sebuah daftar dari informasi tentang obyek-obyek yang tersusun dalam urutan tertentu dan memberikan detail dari setiap obyek. Contohnya adalah buku telepon, di mana daftar obyeknya adalah orang-orang dengan nama yang tersusun secara alfabet dan detailnya adalah alamat dan nomor telepon. Dalam istilah komputer, directory adalah sebuah database spesial, atau biasa disebut data repository, yang memiliki karakteristik yang membedakannya dengan database relasional secara umum. Salah satu karakteristik spesialnya adalah directory diakses (dibaca atau dicari) lebih sering daripada diperbarui (ditulis). Contohnya, ratusan orang akan mencari nomor telepon tapi nomor telepon jarang berubah. Directory dioptimasikan untuk akses pembacaan karena directory harus mampu melayani permintaan pembacaan dalam jumlah banyak. Akses penulisan / perubahan terbatas hanya pada administrator sistem atau pemilih
20
dari setiap informasi. Berbeda dengan database relasional secara umum yang mendukung aplikasi seperti aplikasi perbankan, yang mengalami pembaruan dengan intensitas yang tinggi. Karena itu, directory yang bertujuan untuk menyimpan informasi statis, tidak cocok untuk menyimpan informasi yang berubah secara cepat. Perbedaan lain antara directory dan database relasional secara umum adalah cara informasi diakses. Sebagian besar database mendukung metode yang sudah terstandardisasi dan memiliki akses yang sangat kuat yaitu Structured Query Language (SQL). SQL mengizinkan pembaruan dan fungsi query yang kompleks sebagai harga dari ukuran program dan kompleksitas aplikasi. Di sisi lain, directory menggunakan access protocol yang sederhana dan teroptimasi sehingga bisa digunakan dalam program yang berukuran kecil dan aplikasi yang relatif sederhana. Karena directory memang tidak dimaksudkan untuk menyediakan banyak fungsi seperti database relasional secara umum, directory dapat dioptimasikan secara ekonomis untuk menyediakan banyak aplikasi dengan akses cepat menuju directory data dalam lingkungan distribusi yang besar. Sebuah permintaan biasanya dilakukan oleh directory client dan proses pencarian informasi dalam directory disebut directory server. Secara umum, server melayani layanan tertentu pada client. Terkadang, server bisa menjadi client dari server lainnya untuk mengumpulkan informasi supaya bisa memproses permintaan. (Tuttle et al, 2004:5). 2.2.3 Access Protocol
21
LDAP cukup diketahui sebagai protokol client-server yang berbasis pesan dan ditentukan oleh RFC 2251. LDAP bisa dibilang asinkron (walaupun banyak alat pengembangan yang menyediakan API baik yang blocking maupun yang nonblocking), yang berarti bahwa client bisa melakukan banyak permintaan tapi urutan respon yang dilakukan oleh server bisa berbeda dengan urutan permintaan dari client.
2.2.4 Model LDAP Model LDAP mewakili layanan yang disediakan oleh server, yang bisa dilihat oleh client. Modal LDAP ini merupakan model abstrak yang mendeskripsikan berbagai macam segi dari direktori LDAP. Model LDAP terbagi menjadi empat komponen (Carter, 2003:17): 1. Model Informasi Model informasi menyediakan struktur dan tipe data yang diperlukan untuk membangun sebuah pohon direktori LDAP, juga mendeskripsikan apa saja yang dapat diletakkan di dalam direktori. Sebuah entry adalah unit dasar dari direktori LDAP. Sebuah entry mengandung informasi tentang suatu hal dari satu atau lebih objectClass. ObjectClass ini mempunyai atribut tertentu baik yang wajib maupun yang tidak. Tipe atribut telah menetapkan aturan tentang persandian dan aturan kesesuaian yang mengatur hal-hal seperti tipe data atribut dapat mempertahankan dan bagaimana membandingkan data saat pencarian.
22
Contohnya, sebuah entry mungkin memiliki atribut. Sintaks yang dikaitkan dengan tipe atribut ini akan menentukan apakah nilai dari nomor telepon ditunjukkan dengan string yang bisa dicetak, diikuti oleh kata kunci yang mendeskripsikan ukuran kertas dan karakteristik resolusi. Ini mungkin bahwa entry direktori untuk sebuah organisasi akan mengandung banyak nilai dalam atribut, sehingga sebuah organisasi atau orang yang diwakilkan oleh entity akan memiliki banyak nomor fax.
Gambar 2.2 Diagram Skema LDAP (Sumber: Arkills, 2003) Berikut adalah tabel dari beberapa atribut yang umum digunakan. Beberapa atribut memiliki nama alias yang dapat digunakan dimanapun ketika nama lengkap atribut telah digunakan. Contohnya, cn dapat digunakan untuk merujuk pada atribut commonName.
23
Tabel 2.3 Atribut yang Umum Digunakan Atribut, Alias
Sintaks
Deskripsi
commonName, cn
Cls
surname, sn
Cls
telephoneNumber organizationalU nit Name, ou
Tel Cls
Owner
Dn
Organization, o
Cls
jpegPhoto
Bin
Nama umum dari sebuah entry Nama belakang dari seseorang Nomor telepon Nama dari unit organisasi DN dari orang yang memiliki entry Nama dari organisasi Gambar foto dalam format JPEG
Contoh John Smith Smith 021-7326389 Tivoli cn=John Smith, o=IBM,c=us IBM Foto dari John Smith
2. Model Penamaan Model penamaan mendefinisikan bagaimana entry dan data di Directory Information Tree (DIT) dirujuk secara unik. Setiap entry memiliki sebuah atribut yang unik diantara semua saudaranya dari satu single parent. Atribut yang unik ini disebut Relative Distinguised Name (RDN). Setiap entry apapun di dalam direktori bisa diidentifikasi secara unik dengan mengikuti RDN dari semua entry di path dari node yang diinginkan sampai ke root dari pohon. String dibuat dengan mengkombinasikan RDN untuk membentuk sebuah nama unik yang disebut node’s distinguished name (DN). 3. Model Fungsi Model fungsi mendeskripsikan apa saja yang bisa dilakukan dengan data direktori. Model fungsi adalah protokol LDAP itu sendiri. Protokol ini menyediakan sarana untuk mengakses data pada pohon direktori. Akses
24
diimplementasikan oleh operasi otentikasi (binding), operasi query (search dan read), dan operasi pembaharuan (write). 4. Model Keamanan Model keamanan
mendeskripsikan
bagaimana data direktori
dilindungi dari akses yang tidak terotorisasi. Model keamanan ini menyediakan sebuah mekanisme bagi client untuk membuktikan identitas mereka (otentikasi) dan bagi server untuk mengontrol akses terotentikasi client menuju data (otorisasi).
2.2.5 DIT ( Directory Information Tree) Data entry disimpan secara hirarki terstruktur seperti bentuk pohon yang dikenal dengan sebutan Directory Information Tree. Dengan bentuk namespace yang konsisten dan seragam, data selalu ditampilkan untuk menjawab kebutuhan.
Untuk mengerti struktur namespace, global
namespace dibagi menjadi tiga bagian secara logis:
Suffix, adalah root (bagian atas) dari sebuah bagian global namespace. Seharusnya server-server lain dapat masuk kedalam suffix karena pada suffix tersimpan sebagian informasi.
Dengan kata lain, suffix
menempati posisi paling atas dari entri yang tersimpan, server suffix dapat melayani lebih dari satu suffix.
Struktur Organisasi, tersimpan di bawah suffix, biasanya bertingkattingkat membentuk hirarki sesuai dengan kebutuhan.
25
Data Direktori, disimpan secara flat atau hirarki dengan memanfaatkan dua bagian logic tersebut (suffix dan struktur organisasi).
Gambar 2.3 Contoh Pohon Direktori LDAP (Sumber: Carter, 2003) Pada gambar 2.3 entry direktori yang berada di dalam kotak memiliki sebuah RDN dari cn=gerald carter. Bisa dilihat bahwa nama atribut dan nilai juga termasuk dalam RDN. DN untuk node ini adalah cn=gerald carter, ou=people, dc=plainjoe, dc=org.
2.2.6 LDIF (LDAP Data Interchange Format) LDIF merupakan sebutan untuk format lingo atau bahasa yang dapat dibaca oleh manusia. LDIF bukan satu-satunya cara manusia berinteraksi dengan klien, data klien LDAP dapat diteruskan melalui comma delimited strings atau bahasa XML 11. LDIF merupakan format text dan binary (untuk memasukkan images) dengan ASN dan di kodekan dengan BAR (Basic Encoding Rule) untuk lewat ke jaringan. version: 1 dn: uid=bjensen, ou=people, dc=example, dc=com objectclass: top
26
objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen givenName: Barbara sn: Jensen uid: bjensen mail:
[email protected] telephoneNumber: +1 408 555 1212 description: Manager, Switching Products Division dn: uid=ssmith, ou=people, dc=example, dc=com objectclass: topobjectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Steve Smith cn: Stephen Smith givenName: Stephen sn: Smith uid:ssmith mail:
[email protected] telephoneNumber: +1 650 555 1212 description: Member of Technical Staff.
2.2.7 Replication (Replikasi) Pengertian replikasi menurut : 1) Replikasi adalah proses mempertahankan beberapa salinan data direktori di lokasi yang berbeda. (Howes et al, 2003:29) 2) Replikasi adalah teknik duplikasi data antara beberapa direktori untuk kinerja, skalabilitas dan redundansi. Ini adalah cara untuk membawa beberapa daerah geografis bersama menjadi satu direktori perusahaan. Salinan-salinan tersebut disimpan secara sinkron dengan satu atau lebih server direktori utama yang disebut master server atau writable server dan sebuah server replika atau biasa disebut read-only server. Melalui replikasi, perubahan dibuat untuk satu direktori disebarkan ke satu atau lebih tambahan direktori. Akibatnya, perubahan ke satu direktori muncul ganda di direktori berbeda. (Tuttle et al, 2004:318)
27
Berikut adalah beberapa alasan untuk melakukan replikasi, yaitu :
Reliability (Keandalan). Jika salah satu salinan direktori down karena hardware atau software gagal, salinan lain masih bisa diakses.
Availability (Ketersediaan). Client lebih cenderung untuk mencari replika yang tersedia, bahkan jika bagian dari jaringan telah gagal.
Locality (Lokalitas). Latency dan variasi dalam kinerja berkurang jika klien berada mendekati replika direktori.
Performance (Kinerja). Query lebih lanjut dapat ditangani sebagai replika
tambahan
yang
ditambahkan,
dengan
demikian
akan
meningkatkan troughput keseluruhan layanan direktori. Direktori
replikasi
melindungi
dari
situasi
yang
tidak
menguntungkan dengan membuat direktori tersedia di beberapa server data. Juga meningkatkan kinerja dengan memungkinkan untuk membuat lebih banyak salinan data direktori yang tersedia dan menempatkan mereka dekat dengan pengguna dan aplikasi yang menggunakannya. Replikasi akan meningkatkan keandalan dan kinerja direktori layanan. Dengan membuat direktori data yang tersedia di lebih dari satu lokasi, akan meningkatkan keandalan layanan direktori. Jika satu server gagal, direktori client dan program aplikasi direktori-enabled dapat menghubungi server yang berbeda untuk layanan direktori mereka. Fitur replikasi memungkinkan update DIT LDAP untuk disalin ke satu atau lebih sistem LDAP untuk backup dan/ alasan kinerja. Dalam konteks ini patut ditekankan replikasi yang beroperasi pada tingkat DIT
28
bukan tingkat server LDAP. Jadi dalam single server menjalankan beberapa DIT setiap DIT dapat direplikasi ke server yang berbeda. Replikasi terjadi berkala dalam waktu siklus replikasi. Historis OpenLDAP menggunakan daemon yang terpisah (slurpd) untuk melakukan replikasi, tetapi dengan versi 2.3 fitur baru diperkenalkan (umum dikenal sebagai syncrepl) dan memang untuk versi 2.4 replikasi slurpd telah dianggap usang. Ada dua konfigurasi replikasi dan beberapa variasi pada setiap jenis konfigurasi. 2.2.7.1 Strategi Replikasi Strategi replikasi merujuk pada aliran cara update dari server ke server dan cara berinteraksi update server ketika menyebarkan update. Ada dua pendekatan utama: single-master replication dan multimaster replication.
1. Single-Master Replication Dalam single-master replication, hanya satu server berisi writable copy dari suatu direktori yang diberikan entri. Semua replika berisi salinan read-only entri tersebut. Sedangkan hanya master server yang dapat melakukan operasi write, server apapun dapat melakukan search, compare, atau bind.
29
Gambar 2.4 Single-Master Replication (Sumber : Howes et al, 2003:329) Ciri khas dari direktori adalah melakukan operasi pencarian lebih banyak dari memodifikasi operasi, itu menguntungkan bagi penggunaan replika read-only. Server replika read-only bisa menangani operasi pencarian seperti master server write. Jika client mencoba untuk melakukan operasi penulisan pada server read-only (misalnya, menambahkan, menghapus, memodifikasi,atau mengubah nama entri), kita memerlukan beberapa cara untuk mengatur agar operasi yang akan diserahkan kepada read/write server. Ada dua kemungkinan: yang pertama adalah submit operasi melalui rujukan, yang hanya merupakan cara bagi server untuk mengatakan kepada client.
30
a. Replication Options - Referrals
Gambar 2.5 Replication Options - Referrals (Sumber : Howes et al, 2003:393) Keterangan : (1) Client mengirim modifikasi data ke replika / slave. (2) Replika menunjuk pointer data secara referral master ke client. (3) Client mengirimkan kembali modifikasi yang telah diarahkan ke master. (3) Master memberikan hasil yang diminta kepada client. (4) Master mengupdate replika. b. Replication Option-Chaining
Gambar 2.6 Replication Options - Chaining (Sumber : Howes et al, 2003:394)
31
Keterangan : (1) Client mengirimkan
modifikasi ke replika. (2)
Replika meneruskan permintaan ke master server. (3) Master mengembalikan hasilnya ke replika. (4) Replika meneruskan hasil yang dicari ke client. (5) Master mengupdate data replika. Konfigurasi Master-Slave memiliki dua kekurangan, yaitu:
Beberapa lokasi. Jika semua atau sebagian besar client memiliki kebutuhan untuk memperbarui DIT maka salah satu dari mereka akan harus mengakses satu server (menjalankan DIT slave) untuk akses baca normal dan server lain (menjalankan DIT master) untuk melakukan update. Atau client selalu dapat mengakses server menjalankan DIT master. Dalam kasus terakhir, replikasi menyediakan fungsionalitas cadangan saja.
Ketahanan. Karena hanya ada satu server yang berisi DIT master maka itu merupakan titik tunggal kegagalan.
2. Multimaster Replication Pada sistem multimaster replication, lebih dari satu salinan entri read/write selalu tersedia. Client akan menyampaikan operasi update pada beberapa replika read/write. Kemudian, client akan bertanggung jawab pada sekumpulan server yang bekerjasama untuk memastikan perubahan tersebut secepatnya disebar ke semua server dan konsistensinya terpelihara.
32
Tentunya lebih dari sartu server dengan akses writable copy data. Adanya proses server-server bertanggung jawab untuk menyakinkan bahwa data tersimpan dengan benar. Membutuhkan cara atau aturan yang memecahkan konflik antar server. Semua server mengambil writer terakhir sebagai aturan pemenang/ memegang data. Otomatis dapat terjadi kesalahan ketika satu buah server tidak bisa diakses atau down. Sungguh kompleks dan rumit untuk diimplementasikan. Gambar dibawah ini akan menunjukan dua replika read/write servers mampu menangani write request client.
Gambar 2.7 Multimaster Replication (Sumber : Howes et al, 2003:395)
2.3
Availability 2.3.1 Availability (Ketersediaan) Suatu pendekatan sederhana untuk menciptakan highly available directory service (walaupun menggunakan solusi aplikasi-independen dengan highly availability hardware dan / atau implementasi software)
33
adalah untuk menciptakan sebuah master dan server direktori slave, masingmasing satu pada mesin fisik sendiri. Dengan replikasi data, telah menghilangkan satu titik kegagalan untuk kedua kegagalan hardware dan software. Mekanisme harus ditambahkan untuk menangani pengalihan client jika satu server gagal. Hal ini dapat dilakukan secara manual atau semiotomatis oleh sebuah DNS switch atas, atau secara otomatis dengan teknik load-balancing dengan menggunakan router yang dirancang untuk ini (seperti eNetwork IBM Dispatcher). Router tersebut melanjutkan permintaan klien ke salah satu server berdasarkan kriteria dikonfigurasi. Hal ini juga terkait masalah bandwidth jaringan dan reliability untuk mempertimbangkan.
Dalam beberapa kasus,
mungkin perlu untuk
mendistribusikan replika ke jaringan lain dengan koneksi jaringan yang lambat untuk master. Komponen dari LDAP yang dibutuhkan adalah partisi dan replikasi. Availability dapat didefinisikan sebagai probabilitas bahwa suatu produk beroperasi dan dalam bagian yang ditentukan bila diperlukan. Dalam kata lain, probabilitas bahwa item tidak gagal atau tidak mengalami perbaikan. Langkah ini mempertimbangkan account item reliability dan maintainability. Sebuah rumus untuk availability dapat ditulis sebagai rasio dari rata-rata nilai uptime sistem untuk jumlah dari nilai rata-rata uptime dan downtime.( Benbow et al,2008)
Availabili ty
Average uptime Averageuptime Averagedowntime
34
Availability biasanya ditentukan dalam notasi sembilan. Sebagai contoh 3-sembilan availability ditulis 99,9%. Sebuah availability 5-sembilan ditulis 99,999% Dalam persentase, availability dapat didefinisikan sebagai waktu operasional dibagi dengan waktu keseluruhan, dan hasilnya dikalikan (Held, 2004). Suatu komponen jaringan dapat dikatakan dalam kategori high availability, jika memiliki nilai persentase availability (A%) lebih besar dari 99% (Cisco,2004). A
uptime x100% totaltime
Keterangan : A = availability
Tabel 2.4 Perbandingan availability dan downtime Availability 90% (1-sembilan) 99% (2- sembilan) 99.9% (3- sembilan) 99.99% (4- sembilan) 99.999% (5- sembilan) 99.9999% (6- sembilan)
Downtime 36.5 hari/tahun 3.65 hari/tahun 8.76 hari/tahun 52 menit/tahun 5 menit/tahun detik/tahun
a. Seri : Dua bagian X dan Y dianggap beroperasi secara seri jika kegagalan salah satu bagian mengakibatkan kegagalan gabungan.
Gambar 2.8 Sistem Pemasangan Seri
A= Ax * Ay Implikasi dari persamaan di atas adalah bahwa availability gabungan dari dua komponen dalam seri selalu lebih rendah dari availability komponen individu. Tabel di bawah menunjukkan
35
availability dan downtime untuk komponen individu dan kombinasi seri. Sistem yang dipasang seri mempunyai keandalan sistem yang kecil karena kegagalan satu unit berarti kegagalan seluruh sistem. Tabel 2.5 Perbandingan Komponen Individu dan Gabungan Seri Komponen X Y Gabungan XY
Availability 99% (2-sembilan) 99.99% (4-sembilan) 98.99%
Downtime 3.65 hari/tahun 52 menit/tahun 3.69 hari/tahun
b. Paralel : Dua bagian dianggap beroperasi secara paralel jika kombinasi tersebut dianggap gagal ketika kedua bagian gagal. Sistem gabungan operasional jika salah satu tersedia. Oleh karena itu, availability gabungan adalah 1 - (kedua bagian tidak tersedia).
Gambar 2.9 Sistem Pemasangan Paralel
Implikasi dari persamaan di atas adalah bahwa availability gabungan dari dua komponen secara paralel akan lebih tinggi dari availability komponen individu. Tabel di bawah menunjukkan availability dan downtime untuk komponen individu dan gabungan paralel. Tabel 2.6 Perbandingan Komponen Individu &Gabungan Paralel Komponen
Availability
Downtime
36
X 99% (2-sembilan) Y 99.99% (4-sembilan) Gabungan XY 99.9999% (6-sembilan)
3.65 hari/tahun 52 menit/tahun 31detik/tahun
2.3.1.1 Reliability (Keandalan) Reliability menghadirkan probabilitas komponen atau bagian dari sistem untuk melakukan fungsinya pada waktu tertentu tanpa kegagalan. Reliability tidak melaporkan perbaikan yang terjadi tetapi melaporkan waktu suatu komponen atau sistem gagal ketika beroperasi. Hal ini bukan berarti mengggambarkan berapa lama waktu yang diperlukan unit yang diperbaiki kembali ke kondisi semula. Jika salah satu salinan direktori down karena hardware atau software gagal, salinan lain masih bisa diakses. Reliability tidak pernah mencapai 100% (tidak ada atau pernah terjadi kegagalan atau kerusakan). Tabel 2.7 Hubungan antara Availability dan Reliability Reliability Konstan Bertambah Berkurang 2.4
Availability Berkurang/ Bertambah Bertambah Berkurang
OpenLDAP OpenLDAP adalah Open Source server yang menyediakan jaringan klien dengan direktori layanan. Server direktori dapat digunakan untuk menyimpan informasi organisasi dalam lokasi terpusat, dan membuat informasi ini tersedia untuk aplikasi yang berwenang. Aplikasi klien dapat terhubung ke OpenLDAP menggunakan Lightweight Directory Access
37
Protocol (LDAP). Komponen yang terdapat dalam OpenLDAP dibagi menjadi empat komponen (Butcher, 2007: 22), yaitu : a. Servers, server utama dari rangkaian LDAP adalah Stand-Alone LDAP Daemon (SLAPD). Server ini menyediakan akses menuju satu atau lebih pohon direktori informasi. Client terhubung dengan server melalui protokol LDAP, biasanya dengan menggunakan sebuah koneksi berbasis jaringan (walaupun SLAPD juga menyediakan sebuah socket listener UNIX). Sebuah server dapat menyimpan data direktori secara lokal atau hanya mengakses (atau akses proxy) ke sumber-sumber eksternal. Secara khas, server menyediakan otentikasi dan pencarian layanan, dan juga mendukung penambahan, penghapusan, dan perubahan data direktori. Ini juga menyediakan kontrol akses fine-grained ke direktori. b. Clients, klien mengakses server LDAP melalui protokol jaringan LDAP. Klien berfungsi dengan meminta bahwa server melakukan operasi untuk kepentingan mereka. Secara khas, klien akan pertama kali terhubung dengan server direktori, kemudian melakukan bind (otentikasi), dan kemudian melakukan nol atau lebih operasi lain (mencari, mengubah, menambah, menghapus, dan lain-lain) sebelum akhirnya melakukan unbinding dan memutuskan koneksi. c. Utilities, tidak seperti klien, utilities tidak melakukan operasi menggunakan protokol LDAP. Sebagai gantinya, utilities memanipulasi data di tingkatan yang lebih rendah dan tanpa penghubung oleh server. Utilities digunakan terutama untuk membantu memelihara server.
38
d. Libraries, ada beberapa library OpenLDAP yang dibagi diantara aplikasi-aplikasi LDAP. Library ini menyediakan fungsi-fungsi LDAP pada aplikasi-aplikasi. Klien, utilities, dan server, semuanya membagi akses pada beberapa library. Application Programming Interfaces (APIs) disediakan untuk mengizinkan para pengembang perangkat lunak menulis aplikasi LDAP mereka sendiri tanpa menulis ulang kode dasar LDAP. Jika API yang disediakan untuk OpenLDAP ditulis dalam bahasa C, proyek OpenLDAP juga menyediakan dua Java API. Library dari Java ini tidak termasuk dalam rangkaian OpenLDAP tapi bisa didapatkan dari http://openldap.org.
Gambar 2.10 Diagram keempat komponen OpenLDAP (Sumber : Butcher,2007:21) 2.4.1 Replikasi OpenLDAP Replikasi terjadi pada tingkat DIT dan menggambarkan proses menyalin update dari DIT pada satu server LDAP ke DIT yang sama pada satu atau lebih server lainnya. Konfigurasi replikasi dapat berupa master-slave (salinan slave selalu read-only) atau multimaster.
39
Replikasi OpenLDAP sebelumnya menggunakan slurpd dan file sementara. Dengan versi 2.3 dari OpenLDAP metode baru yang dikenal sebagai syncrepl ( RFC 4533 ) diperkenalkan sementara terus mendukung replikasi gaya slurpd. OpenLDAP versi 2.4 telah menghentikan dukungan untuk replikasi gaya slurpd. 2.4.1.1 Replikasi dengan Slurpd OpenLDAP Replikasi Slurpd adalah 'push' replikasi (dan usang untuk versi 2.4). Hal ini dikonfigurasi dan dikendalikan seperti yang terlihat pada gambar 2.12
Gambar 2.11 Slurpd Style Replication (Sumber : http://www.zytrax.com/books/ldap/ch7/#ol-replication) Ketika slapd (1) menjalankan DIT master (7) menerima sebuah operasi memodifikasi (9) memperbarui DIT dan transaksi salinan timestamped ditulis ke file log (2) didefinisikan dalam slapd.conf master (5) berkas replogfile direktif. Slurpd (3) ketika pada awalnya dimuat, memperoleh parameter operasional dari slapd.conf (5). Pada waktu periodik ditetapkan oleh replicationinterval slurpd akan membaca file log (2) ditetapkan oleh replogfile direktif dan menulis update (10) untuk
40
satu (atau lebih) DIT slave (8) didefinisikan oleh replika direktif (s) dalam slapd. conf (5). DIT slave (8) adalah salinan read-only untuk semua client, kecuali client yang mengikat menggunakan DN yang didefinisikan oleh updatedn . Server slave (4) mengembalikan URI LDAP didefinisikan oleh updateref untuk semua operasi modifikasi dari client (kecuali yang dimulai menggunakan DN dalam updatedn). Baik updatedn maupun updateref didefinisikan dalam file slapd.conf (6). DN didefinisikan dalam updatedn dalam (6) HARUS sama dengan yang didefinisikan dalam replika direktif (binddn = parameter) dalam (5) untuk contoh slave ini. 2.4.1.2 Replikasi dengan Syncrepl OpenLDAP OpenLDAp versi 2.3 memperkenalkan dukungan untuk protokol baru Konten Sinkronisasi LDAP dan dari versi 2.4 hanya replikasi ini yang didukung (slurpd sudah usang). Protokol Konten Sinkronisasi LDAP didefinisikan oleh RFC 4533 dan pada umumnya dikenal dengan nama pengendali direktif slapd.conf - syncrepl . Syncrepl menyediakan kedua replikasi master-slave klasik dan memungkinkan untuk multi-master replikasi sejak versi 2.4 muncul. Protokol ini menggunakan istilah penyedia (bukan master) untuk menentukan sumber update replikasi dan istilah konsumen (bukan slave) untuk menentukan tujuan update.
41
Dalam replikasi syncrepl, konsumen selalu memulai proses update, tidak seperti seperti slurpd dimana master (penyedia) yang memulai update. Konsumen memungkinkan dikonfigurasi secara berkala menarik update dari penyedia (refreshOnly) atau meminta penyedia untuk mendorong pembaruan (refreshAndPersist). Dalam semua kasus, agar tegas merujuk pada entri server harus mempertahankan sejumlah universal unik (entryUUID) untuk setiap entri dalam DIT. Proses sinkronisasi ditunjukkan pada Gambar 2.12 (refreshOnly) dan Gambar 2.13 (refreshAndPersist). a. Replikasi refreshOnly (Consumer Pull)
Gambar 2.12 Replikasi refreshOnly (Sumber : http://www.zytrax.com/books/ldap/ch7/#ol-replication) Sebuah slapd server (1) yang ingin mereplikasi DIT (8) (konsumen ) dikonfigurasi menggunakan direktif syncrepl pada file slapd.conf nya (6). Direktif syncrepl mendefinisikan lokasi (nama) dari slapd server penyedia (3) yang berisi salinan master DIT. Penyedia (3) dikonfigurasi menggunakan direktif overlay syncprov di file slapd.conf nya (5).
42
Pada tipe refreshOnly, replikasi konsumen (1) memulai koneksi (2) dengan penyedia (2) - sinkronisasi DIT mengambil tempat dan koneksi rusak. Konsumen secara berkala (1) terhubung kembali (2) dengan penyedia (3) dan menyinkronisasi. b. Replikasi refreshAndPersist (Provider Push)
Gambar 2.13 Replikasi refreshAndPersist (Sumber : http://www.zytrax.com/books/ldap/ch7/#ol-replication) Sebuah slapd server (1) yang ingin mereplikasi DIT (7) dari server (3) (penyedia ), dikonfigurasi menggunakan direktif syncrepl di file slapd.conf nya (6). Direktif syncrepl mendefinisikan lokasi (nama) dari server slapd (3) (penyedia) yang berisi salinan DIT master. Penyedia (3) dikonfigurasi dengan menambahkan overlay syncprov direktif pada file slapd.conf (5). Dalam refreshAndPersist jenis replikasi konsumen (1) memulai koneksi (2) dengan penyedia (3) - sinkronisasi (12) dari DIT segera mengambil tempat dan pada akhir proses ini koneksi dipertahankan (persist). Perubahan selanjutnya (4) ke penyedia (3) segera disebarkan ke konsumen (1).
43
2.5
CentOS CentOS adalah sistem operasi bebas yang didasarkan pada Red Hat Enterprise Linux (RHEL). Proyek ini berusaha untuk 100% binari kompatibel dengan produk terdahulunya (RHEL). Arsip perangkat lunak tambahan menyediakan versi terbaru paket-paketnya, berbasis paket RPM. CentOS singkatan dari Community ENTerprise Operating System yang merupakan proyek independen yang bertujuan untuk menyediakan distribusi GNU/Linux yang stabil untuk institusi dan perseorangan yang tidak sangat memerlukan dukungan untuk menjalankan sistem yang mereka miliki. CentOS memiliki beberapa keunggulan antara lain:
Mudah dipelihara
Distribusi yang mandiri, maksudnya adalah distribusi ini bisa dikembangkan
tanpa
bantuan
yang
lainnya
dalam
proses
pembangunannya
Sangat cocok untuk penggunaan jangka panjang, terutama untuk lingkungan produksi bukan eksperimental dan lainnya
Mudah digunakan bagi pemelihara paket software dan para pengguna
Dukungan jangka panjang dari para developernya
Pengembangan yang aktif
Infrastruktur berbasis komunitas
Manajemen yang terbuka
Model bisnis yang terbuka
Dukungan komersial, diberikan oleh vendor-vendor partner.
44
Distro CentOS didukung dari banyak software yang sangat baik dalam dunia open source. Jika menggunakan CentOS sebagai server, maka software yang mendukung diantaranya :
ApacheWeb Server (http://httpd.apache.org), HTTP server yang paling populer .
Samba (www.samba.org), paket aplikasi untuk sharing files, printer dan informasi yang terkait menggunakan protokol yang mendukung Windows, OS/2, PC-based systems lainnya.
Sendmail (www.sendmail.org), sebuah email server yang dapat mengirim dan menyimpan dan dapat diakses menggunakan berbagai email client.
CUPS (www.cups.org), terdiri dari software untuk mengkonfigurasi print servers pada UNIX Printing System.
vsFTPd (http://vsftpd.beasts.org), sebuah File Transfer Protocol (FTP) server yang dapat digunakan untuk mengunggah dan mengunduh file dalam jaringan.
MySQL (www.mysql.com), sebuah SQL database server yang multiuser.
BIND (www.isc.org/products/BIND), server Berkeley Internet Name Domain (BIND) mengimplementasikan protokol Domain Name System (DNS) untuk mengubah hostname ke IP address pada internet (atau jaringan yang sama).
2.6
Zimbra Mail Server
45
Zimbra Mail Server adalah server khusus yang mengelola seluruh isi mailbox, termasuk pesan, kontak, kalender, dan attachment. Pesan akan diterima dari Zimbra MTA server dan kemudian dilewatkan melalui filter yang telah dibuat. Pesan ini kemudian diindeks dan disimpan ke mailbox yang benar. Selain manajemen konten, Zimbra mailbox server telah mendedikasikan volume untuk cadangan dan file log. Setiap Zimbra mailbox server dalam sistem hanya dapat melihat volume penyimpanan sendiri. (http://www.zimbra.com/). Pada dasarnya aplikasi Zimbra Mail Server dibangun oleh komunitas yang peduli akan kebutuhan mail server yang stabil, menjadi alternatif dan mungkin lebih baik dari aplikasi sekelas Microsoft Exchange Server. Aplikasi Zimbra mail server saat ini tersedia dalam 2 versi yaitu Open Source Edition dan Network Edition, dimana hanya berbeda dalam pilihan backup data. Versi Open Source menggunakan lisensi Mozilla Public License yang salah satu butir lisensinya menyatakan bahwa perubahan atau modifikasi yang dilakukan pada kode sumber Zimbra harus dikembalikan pada komunitas. Beberapa software Open Source yang tergabung menjadi satu kesatuan menjadi aplikasi Zimbra mail server adalah MySQL, Postfix , OpenLDAP, Anti Virus Clamav, Anti Spam SpamAssassin. Secara umum fitur yang dimiliki oleh Zimbra Mail Server yaitu berbasis Open Source (tidak ada biaya Lisensi Software, siapapun dapat menggunakan), beroperasi menggunakan sistem operasi LINUX, antivirus dan AntiSpam Handal dan termasuk secara dalam kesatuan mail server,
46
kapasitas user account dan mailbox tidak terbatas, pengaturan dan pemeliharaan sangat mudah dengan Web Administration console, memiliki kemampuan Multi Domain, memiliki pembatasan Quota MailBox per User, dapat digabungkan dengan Fitur Spooling Mail. (Zimbra NE Admin: 2010). Protokol email yang ada pada Zimbra Mail Server adalah SMTP (Simple Mail Transport Protocol), SSMTP (Secure Simple Mail Transport Protocol), POP3 (Post Office Protocol), POP3S (Secure Post Office Protocol), IMAP (Internet Mail Application Protocol), dan IMAPS (Secure Internet Mail Application Protocol). Zimbra server menggunakan 3 pilihan akses webmail berdasarkan kecepatan koneksi internet yang dimiliki user:
Advanced Client (AJAX), untuk kecepatan koneksi user tinggi misalnya minimal 512 kbps ke atas
Standard (HTML), untuk kecepatan koneksi user sedang misalnya minimal 256 kbps s/d 384 kbps
Mobile, jika menggunakan smartphone atau kecepatan koneksi GPRS atau dial-up. Fitur dan menu yang tersedia pada web client terdiri dari fitur standar
mail seperti (compose, read, reply, forward, dll), tag mail ke grup pesan dengan mudah untuk referensi, Basic dan Advanced Search, Address Book Sharing, Address Book Export dan Import, Calendar Sharing, Tasks, Scheduling, Documents Sharing, File Sharing (Briefcase), dan Web Instant Messaging. Zimbra mail server kompatibel dengan email client seperti Zimbra Dekstop, Outlook Express, Microsoft Outlook, Mozilla Thunder
47
Bird, dll. Zimbra Webmail server juga dapat berjalan di semua Web Browser seperti IE, Mozilla FireFox, Safari, Google Chrome, dan Opera. Spesifikasi Minimal PC untuk Zimbra Mail Server skala sedang maupun besar menggunakan IBM, Compaq, HP dan lain-lain dengan spesifikasi processor Intel/AMD 3 Ghz – 64bit, memory 8 s/d 32 GB, harddisk 1 TB SCSI, LAN card 10/100/1000 Mbps, tanpa monitor namun perlu casing dan power supply-nya untuk PC. Selain itu dibutuhkan koneksi internet minimal memiliki kecepatan Link Upload ke internet sebesar 128Kbps, sedangkan rekomendasi memiliki kecepatan Link Upload ke internet sebesar 512Kbps atau lebih, memiliki nama domain usaha atau organisasi, mendaftarkan ke Spooling server untuk backup email bila koneksi internet offline, namun bila tidak mail server tetap dapat di gunakan. Kelebihan Zimbra 1) Zimbra adalah pilihan terbaik bagi perusahaan yang menginginkan aplikasi mail server sekelas Exchange Server namun tanpa biaya lisensi. 2) Zimbra sangat powerful. Dibangun dengan teknologi AJAX, aplikasi webmail Zimbra mendukung rich application dan bisa dikolaborasikan dengan sistem lain. 3) Zimbra web mail dapat diakses dengan berbagai pilihan, apakah akses dalam bentuk AJAX, HTML atau akses mobile. 4) Zimbra datang dengan feature administrasi yang komplit dan bisa diakses melalui web dalam modus SSL.
48
5) Zimbra menyediakan fitur webmail terkini, seperti briefcase, task & schedule, instant messaging /local chat, sharing folder email, kalender, dan lain-lain. 6) Dukungan otomatis untuk anti virus (menggunakan engine ClamAV) dan anti spam (SpamAssasin).
2.7
Nagios Nagios adalah sebuah tool open source dirilis di bawah ketentuan GNU General Public License (GPL). Ethan Galstad adalah pencipta Nagios sedangkan Karl DeBisschop, Subhendu Ghosh, Ton Voon, dan Stanley Hopcroft merupakan pengembang plugin yang utama. Nagios adalah network
monitoring system open source yang terbaik. Nagios bersifat
modular, mudah digunakan, dan memiliki skalabilitas tinggi. Modul atau plugin pada nagios sangat sederhana. Untuk mendownload source nagios melalui www.nagios.org/download. Nagios awalnya didesain untuk berjalan pada sistem operasi Linux karena awalnya ditulis untuk berjalan di bawah Linux, tetapi harus bekerja di bawah hampir semua varian Unix dengan C compiler. Selain itu, mesin harus memiliki server HTTP dan TCP stack yang tersedia. Namun, dapat juga berjalan dengan baik hampir disemua sistem operasi UNIX. Bahkan saat ini sudah keluar versi beta Nagios untuk Windows. Beberapa fitur yang tersedia pada nagios diantaranya adalah :
Memonitor network services (SMTP, POP3, HTTP, NNTP, PING, dll).
49
Memonitor sumber daya host (processor load, disk usage, dll).
Desain
plugin
yang
simpel
memungkinkan
user
untuk
mengembangkan service checks sendiri dengan mudah.
Memparalelkan service checks.
Kemampuan untuk menentukan jaringan hirarki host dengan menggunakan "parent" host, yang memungkinkan deteksi dan perbedaan antara hosts yang down dan mereka yang unreachable.
Terdapat contact notifications ketika layanan atau host masalah ini terjadi dan bisa diselesaikan (melalui email, pager atau metode userdefined).
Kemampuan untuk mendefinisikan event handler untuk dijalankan selama acara layanan atau host untuk penyelesaian masalah proaktif.
Dukungan untuk melaksanakan pemantauan host redundant.
Web interface untuk melihat status jaringan saat ini, pemberitahuan dan sejarah masalah, file log, dll. Nagios berjalan pada server, biasanya sebagai daemon (atau jasa).
Daemon pemantauan berjalan cek berkala pada host dan services yang ditentukan menggunakan eksternal "plugin" yang hasil informasi status ke Nagios.
Saat
masalah
yang
dihadapi,
daemon
dapat
mengirim
pemberitahuan ke kontak administratif dalam berbagai cara yang berbeda (email, pesan instan, SMS, dll). Status informasi, sejarah log, dan laporan semua dapat diakses melalui web browser.( www.nagios.org).
50
Menurut Burgess (2005: 2), Nagios dapat melakukan lebih dari ini, namun demikian inilah daftar hal-hal umum yang digunakan untuk nagios :
Memeriksa apakah server nyala dan berjalan.
Memberikan notifikasi jika server sedang down (melalui email / pager / SMS).
Memeriksa apakah service berjalan (mail, HTTP, POP, SSH).
Memeriksa apakah suatu proses (atau layanan Windows) berjalan.
Mengumpulkan statistik kinerja pada server.
Mengizinkan tanda spesifik untuk kelompok-kelompok tertentu / perorangan.
Mendapatkan laporan downtime pada server.
Konfigurasi File Mayoritas dari konfigurasi di Nagios ditangani melalui dokumen teks dalam /etc/nagios direktori server. Meskipun ada banyak dokumendokumen tambahan dan pilihan, yang benar-benar diperlukan untuk implementasi dasar:
hosts.cfg
hostgroups.cfg
contacts.cfg
contactgroups.cfg
services.cfg
Kelebihan Nagios
Open source
51
Kuat dan handal
Sangat dikonfigurasi
Mudah extensible
Pengembangan yang aktif
Komunitas yang aktif
Nagios berjalan pada banyak Operating System
Kekurangan Nagios
Nagios banyak menggunakan plug-in yang agak rumit dalam konfigurasinya.
Tidak adanya trend prediction.
Nagios dapat digunakan untuk memonitor segala macam hal, berikut adalah beberapa hal umum biasanya dipantau:
Ping untuk melihat apakah host dapat dicapai
Layanan seperti DHCP, DNS, FTP, SSH, Telnet, HTTP, NTP, POP3, IMAP, SMTP, dan lain-lain.
Database server seperti MySQL, Postgres, Oracle, SQL Server, dan lainlain.
Aplikasi tingkat informasi (Apache, Postfix, LDAP, Citrix, dan lain-lain).
BAB III METODOLOGI PENELITIAN
Pada bab ini akan diuraikan metode penelitian yang digunakan oleh penulis dalam penyusunan skripsi. 3.1
Waktu dan Tempat Penelitian Penelitian dilakukan pada bulan Juni 2011 s.d September 2011 di Pusat Data Informasi dan Standardisasi Badan Pengkajian dan Penerapan Teknologi (BPPT) Jalan MH Thamrin 8 Jakarta Pusat.
3.2
Jenis Penelitian Jenis penelitian yang digunakan penulis adalah jenis penelitian kuantitatif. Penelitian kuantitatif adalah penelitian ilmiah yang sistematis terhadap bagian-bagian dan fenomena serta hubungan-hubungannya. Tujuan
penelitian
kuantitatif
adalah
mengembangkan
dan
menggunakan model-model matematis, teori-teori dan/atau hipotesis yang berkaitan dengan fenomena alam. Proses pengukuran adalah bagian yang sentral dalam penelitian kuantitatif karena hal ini memberikan hubungan yang fundamental antara pengamatan empiris dan ekspresi matematis dari hubungan-hubungan kuantitatif.
8
53
3.3
Metode Pengumpulan Data 3.3.1 Studi Pustaka dan Literatur dan Sejenis Studi Pustaka, yakni mengumpulkan data primer dan referensi melalui literatur, buku, artikel maupun secara online menggunakan media internet untuk mendapatkan referensi yang berhubungan dengan penulisan skripsi ini. Studi literatur merupakan langkah penting di dalam penulisan ini. Studi literatur terhadap karya-karya sebelumnya yang bertema sejenis. Penulis mendapatnya informasi yang didapatkan dari buku-buku, jurnal, situs-situs di internet yang berkaitan dengan permasalahan yang dibahas khususnya berkaitan dengan optimalisasi availability dengan OpenLDAP dari berbagai sumber. Setelah melakukan studi pustaka dan literatur sejenis, penulis menemukan beberapa karya ilmiah yang berisi informasi sejenis berkaitan dengan LDAP. Karya ilmiah ini berupa skripsi dan jurnal. Berikut diantaranya:
Panji Adiprabowo, Eva Kusmiyati, Sylvia Astri Wulandari Rahardjo (2011), dalam tugas akhir yang berjudul “Penggunaan Single Sign On (SSO) Pada Jaringan Internet Pada Badan Pengkajian Dan Penerapan Teknologi
(BPPT)”.
Tujuan
penelitian
ialah
merancang
dan
mengimplementasikan sistem Single Sign On yang berfungsi untuk menyederhanakan akun dan memudahkan user dalam mengakses layanan yang tersedia. Metode penelitian yang digunakan dalam
54
skripsi ini adalah metode pengumpulan data dan metode perancangan. Metode pengumpulan data meliputi observasi sistem, wawancara, dan studi kepustakaan. Metode perancangan menggunakan Network Development
Life Cycle (NDLC)
yang terdiri dari analisis,
desain/perancangan, simulasi/prototyping, implementasi, monitoring, dan manajemen. Hasil yang dicapai berupa sistem Single Sign On yang menggunakan protokol Lightweight Directory Access Protocol (LDAP) dan Remote Authentication Dial-In User Service (RADIUS) serta sesuai dengan kebutuhan perusahaan yaitu akun yang disederhanakan, fitur-fitur email yang lebih baik, dan adanya pengawasan dalam internet. Simpulan dari hasil penulisan skripsi ini adalah sistem Single Sign On telah berjalan dengan baik dan dapat memberikan kemudahan bagi user untuk menggunakan layanan yang ada,
memberikan
identitas email
bagi user,
dan
membantu
administrator untuk melihat daftar user yang mencoba login.
Indra Permana (2010), dalam tugas akhirnya yang berjudul “Analisis Otentikasi terpusat Dengan OpenLDAP Studi Kasus File, Email, FTP, dan Proxy Server (Centos 5). Metode pengumpulan data yang dilakukan adalah studi lapangan, studi pustaka, dan studi literatur sejenis. Metode perancangan menggunakan Network Development Life Cycle (NDLC) yang terdiri dari analisis, desain/perancangan, simulasi/prototyping, implementasi, monitoring, dan manajemen. Pada tahap analisis menggunakan faktor kualitas ISO 9126 yaitu
55
functionality dalam hal kesesuaian dari fungsi perangkat lunak (suitability), kemampuan sistem dalam berinteraksi dengan sistem yang lainnya (interoperability) dan keamanan (security), serta salah satu faktor nonteknis ISO 9126 yaitu cost. Hasil yang dicapai berupa sistem dengan OpenLDAP dapat membantu administrator dan user dalam mengatur dan menggunakan sumber daya jaringan dengan biaya yang murah dan memudahkan administrator dan user. OpenLDAP adalah salah satu solusi hemat dan berkualitas untuk otentikasi user terpusat pada jaringan komputer.
3.3.2 Observasi Observasi merupakan teknik pengumpulan data yang efektif untuk mempelajari sebuah sistem. Dalam observasi, dilakukan teknik penemuan fakta dimana analisis sistem turut berpartisipasi atau menyaksikan seseorang yang sedang melakukan aktivitas untuk mempelajari sistem (Whitten, 2004:234). Penulis melakukan pengamatan langsung terhadap sistem yang sekarang bekerja di BPPT secara langsung.
3.3.3 Wawancara Wawancara dilakukan dengan mengajukan beberapa pertanyaan pada pihakpihak yang terkait untuk mengetahui sistem yang sedang berjalan dan sistem baru yang diinginkan oleh BPPT (hasil wawancara terlampir).
56
3.4
Metode Pengembangan Sistem Metode pengembangan sistem yang digunakan pada penulisan ini adalah NDLC (Network Development Life Cycle), dimana metode pengembangan ini mempunyai enam tahapan yaitu: 3.4.1 Analisis Pada tahap awal ini dilakukan analisis sistem yang sedang berjalan, analisis topologi/ jaringan yang sudah ada saat ini, analisis masalah. Pada tahapan ini penulis menggunakan Network Management System (NMS) tools yaitu Nagios untuk mendapatkan nilai availability pada server yang saat ini sedang berjalan. Hal ini dilakukan selain agar penulis memahami keadaan sistem yang telah berjalan tetapi juga agar penulis mengetahui tingkat availability sistem sebelum dilakukan redundancy. 3.4.2 Desain Dari data-data yang didapatkan pada tahap sebelumnya, tahap desain ini akan membuat gambar desain topologi jaringan interkoneksi yang akan dibangun secara fisik dan desain sistem secara logis menggunakan Microsoft Office Visio, diharapkan dengan gambar ini akan memberikan gambaran seutuhnya dari kebutuhan yang ada. 3.4.3 Simulasi Prototipe Pada tahap ini akan dibuat perhitungan availability dengan rumus-rumus yang ada untuk menyamakan dengan nilai availability yang didapat dalam NMS tools Nagios.
57
3.4.4 Implementasi Tahapan ini penulis akan menerapkan semua yang telah direncanakan dan dirancang sebelumnya pada server sebenarnya. Proses implementasi yang dilakukan berupa instalasi dan konfigurasi. 3.4.5 Monitoring Pada metode pengembangan sistem NDLC, tahap pengujian (aktivitas pengoperasian dan pengamatan sistem) terdapat pada tahap ini. Pemantauan sistem juga menggunakan Nagios tools. 3.4.6 Manajemen Tahapan terakhir ini salah satu yang menjadi perhatian khusus adalah masalah policy, kebijakan perlu dibuat untuk membuat / mengatur agar sistem yang telah dibangun dan berjalan dengan baik dapat berlangsung lama dan unsur reliability terjaga. Proses manajemen akan dilakukan sesuai dengan Standard Operating Procedure (SOP) yang ada di unit kerja PDIS.
58
Gambar 3.1 Ilustrasi Metodologi Penelitian
BAB IV HASIL DAN PEMBAHASAN
Pada bab ini penulis akan menguraikan secara rinci dari awal pembangunan sistem ini sampai akhir pengimplementasian sehingga sistem dapat berjalan sesuai dengan tujuan penelitian. Setelah pengumpulan data melalui observasi, wawancara, dan studi literatur sejenis kemudian mempelajari hal tersebut, penulis melakukan pengembangan sistem dengan metode NDLC.
4.1
Analisis Analisis yang dilakukan pada tahap ini berupa analisis sistem yang sedang berjalan, analisis topologi/ jaringan, dan analisis permasalahan. 4.1.1 Analisis Sistem yang Sedang Berjalan Berdasarkan hasil wawancara dengan Bapak Amir Dahlan ST, M.Kom dan Bapak Agung Septiadi ST, bagian Sub Bidang Sistem Aplikasi, Badan Pengkajian dan Penerapan Teknologi (BPPT), sebagai salah satu institusi pemerintah nonkementrian, memiliki sekitar tiga ribu orang pegawai yang terbagi menjadi beberapa unit kerja. LDAP Server sudah diterapkan di BPPT sejak Januari 2011. Sistem LDAP server yang saat ini berjalan di BPPT adalah hanya terdapat satu buah server eksternal fisik LDAP, yaitu LDAP master. LDAP server digunakan untuk memberikan layanan otentikasi dan direktori server atau penyimpanan data terpusat.
59
60
Bentuk informasi yang ada di dalam hirarki LDAP disebut directory information tree (DIT). Stuktur paling atas (top) dari tree tersebut adalah domain perusahaan itu sendiri, atau disebut juga domain components (dc). Struktur di bawahnya adalah organizational unit (ou). Data pada direktori disimpan pada sebuah database. Database yang digunakan yaitu BDB (Berkeley Database). Schema standar yang terdapat pada OpenLDAP ada tiga, yaitu core.schema, cosine.schema, dan inetorgperson.schema. Schema yang digunakan pada sistem ini adalah inetorgperson.schema. Tiap schema memiliki atributnya masing-masing. Atribut-atribut tersebut digunakan untuk menyusun LDIF (LDAP Data Interchange Format). LDIF berisikan record/informasi yang dipisahkan oleh baris. Setiap record terdiri dari beberapa atribut yang digunakan untuk menyusun entitas direktori. Atribut-atribut yang digunakan antara lain: Tabel 4.1 Atribut pada LDAP di BPPT Attribut Cn Sn Uid Mail UserPassword GivenName DisplayName
Value Fatimah Indraswati Indraswati fatimah.indraswati
[email protected] e01ENX10cFpxbzBwbmNIYU hsWE0zR0g5eUhBPT0= Fatimah Fatimah Indraswati S.Kom
Keterangan Nama lengkap Nama belakang Username Email Password Nama depan Nama lengkap dan gelar Status pegawai NIP pegawai Divisi
EmployeeType Staff EmployeeNumber 198910082012011001 Bussinesscategor Biro Sumberdaya Manusia dan y Organisasi Jika disusun dalam bentuk LDIF maka data di atas akan menjadi:
61
# fatimah.indraswati, People, bppt.go.id dn: uid=fatimah.indraswati,ou=People,dc=bppt,dc=go,dc=id cn: Fatimah Indraswati displayName: Fatimah Indraswati,S.Kom uid: fatimah.indraswati givenName: Fatimah sn: Indraswati objectClass: inetOrgPerson objectClass: top userPassword:: e01ENX10cFpxbzBwbmNIYUhsWE0zR0g5eUhBPT0= mail:
[email protected] employeeNumber: 198910082012011001 employeeType: staff businessCategory: Biro Sumberdaya Manusia dan Organisasi
Komunikasi Mail ke LDAP Master Mekanisme otentikasi yang digunakan menggunakan mekanisme LDAP eksternal dimana LDAP sebagai database penyimpanan username dan password yang digunakan oleh Zimbra mail server. Zimbra
mail
server
menggunakan
LDAP
sebagai
database
penyimpanan daftar accountnya. LDAP yang berisi data user akan melakukan sinkroninasi pada Zimbra, dimana saat tersinkronisasi Zimbra secara otomatis akan membuat mail box dengan alamat email yang sudah tertera pada data di LDAP. Mekanisme otentikasi eksternal mencoba bind ke server direktori menggunakan username dan password yang disediakan. Jika proses binding berhasil, koneksi ditutup dan password dianggap sah. Dua atribut domain tambahan yang
diperlukan
untuk
mekanisme
eksternal
zimbraAuthLdapURL dan zimbraAuthLdapBindDn.
yaitu
62
4.1.2 Analisis Topologi/ Jaringan Saat
client/
user
ingin
mengakses
email,
Zimbra
akan
mengotentikasi username dan password pada LDAP. Jika username dan password terotentikasi, Zimbra akan memberikan izin akses email pada user. Misalkan user yang akan mengakses email harus melakukan login terlebih dulu dengan memasukkan alamat email dan password-nya. Setelah itu, mail server akan mengecek username dan password yang telah dimasukkan di LDAP. LDAP akan mencocokkan data yang dimasukkan oleh user dengan yang ada di direktori. Berikutnya, jika data sesuai, user dapat membuka mail. Jika tidak, user harus melakukan login ulang.
Gambar 4.1 Topologi logis jaringan BPPT memiliki dua gedung, dimana kedua gedung tersebut terhubung melalui suatu jaringan internal yang besar. Topologi fisik jaringan yang saat ini sedang berjalan di BPPT dapat dilihat pada gambar 4.2 Komputer-komputer
di
setiap
lantai
dalam
gedung
BPPT
dihubungkan oleh kabel UTP (Unshielded Twisted Pair) ke sebuah hub,
63
dimana hub tersebut terhubung dengan access switch. Access switch merupakan switch yang bekerja pada Access Layer yang menjamin paketpaket data diterima oleh komputer end user. Access switch kemudian terhubung pada distribution switch. Setiap distribution switch lalu terhubung pada core switch. Setiap gedung memiliki masing-masing satu core switch yang terhubung satu sama lain. Jika fiber optic utama mengalami gangguan koneksi maka sambungan internet akan dialihkan ke fiber optic redundan. Untuk mengakses internet, core switch akan mengirimkan paketpaket data melalui firewall. Firewall akan meneruskan paket data tersebut menuju DMZ (server farm) yang terhubung dengan proxy server, DNS Server, Mail Server, Accelerator. Proxy server bertugas untuk menyaring paket-paket data dari dan menuju ke internet dan membatasi hak akses user. DNS server digunakan sebagai pelengkap dari web server, dimana server ini mempunyai fungsi untuk memberi nama domain dari setiap alamat web. Mail server berfungsi untuk mengatur arus email, termasuk di dalamnya menyimpan data user dan data mail box. Accelerator berfungsi layaknya proxy, namun dilihat dari sisi internet. Tahap
analisis
jaringan
menggunakan
tools
Nagios
untuk
mendapatkan nilai availability LDAP server. Pengambilan sampel dilakukan selama kurang lebih 30 hari kemudian diambil sampel kembali pada saat sudah dilakukan tahap implementasi selama 30 hari.
64
Gambar 4.2 Topologi fisik jaringan Sumber: Dokumentasi Internal Jaringan PDIS, BPPT
65
Spesifikasi perangkat keras dan perangkat lunak yang saat ini dipakai di BPPT adalah sebagai berikut: Tabel 4.2 Spesifikasi perangkat keras dan perangkat lunak Keterangan
LDAP master
LDAP slave
Email
Spesifikasi perangkat keras
Spesifikasi perangkat lunak
- Intel Core 2 Quad @2.33 GHz - RAM 2 GB - HD 500 GB
- CentOS release 5.5 (Final) - OpenLDAP 2.3.43-12.e15
- Intel pentium 4 @3.00 GHz - RAM 1 GB - HD 80 GB
- CentOS release 5.6 (Final) - OpenLDAP 2.3.43-12.e15
- Intel Xeon E5405 @2.00 GHz - 4GB - 1.5 TB
- CentOS release 5.5 (Final) - ZCS6.0.10_GA_2692.RHEL5_64
Minimum requirement menjelaskan hardware dan software yang perlu diinstal dalam menjalankan sistem ini. Tabel 4.3 Minimum requirement Software CentOS-5.6-x86_64
Requirement
Processor Pentium 4/Barton/Sempron Maximum memory 256GB/1TB Maximum filesize 2TB Maximum filesystem size (Ext3) 8TB/16TB Minimum Memory 512M Minimum diskspace 1.2GB OpenLDAP 2.3.43 SSL/TLS libraries (seperti paket OpenSSL) Dukungan POSIX, baik oleh sistem operasi atau external library Database manager library yang mendukung tipe penyimpanan fasilitas DBM. Sumber: http://www.centos.org/product.html & (Carter, 2003: 38)
66
4.1.3 Analisis Permasalahan Berdasarkan data-data yang sudah dikumpulkan, permasalahan yang terdapat pada sistem yang sedang berjalan di BPPT saat ini. Saat ini terdapat satu server LDAP, yaitu LDAP eksternal yang menyimpan direktori akun pegawai BPPT. Dengan hanya terdapat satu LDAP server eksternal yang menyimpan direktori akun pegawai dimana bila terjadi down maka mail tidak dapat melakukan otentikasi pada server LDAP sehingga akan mengganggu proses otentikasi pada direktori LDAP server. Selain itu, tidak adanya Network Monitoring System (NMS) yang terpasang untuk memantau jaringan yang berjalan, maka dipasang sebuah tools untuk memantau host yang terhubung dalam jaringan BPPT. Maka untuk itu dipasang sebuah Network Monitoring System (NMS) tools Nagios. Untuk tahap instalasi CentOS tersedia di lampiran, berikut tahap-tahap instalasi disertai konfigurasi penambahan host yang dimonitor dalam nagios. 4.1.3.1 Instalasi Nagios Sebelum memulai instalasi siapkan paket nagios dan plugin terbaru dan paling stabil (nagios-3.2.3.tar.gz dan plugin nagios-plugins-1.4.15.tar.gz). Kemudian install terlebih dahulu aplikasi Apache HTTP server dan GD library serta library lainnya yang dibutuhkan saat instalasi dan saat nagios dijalankan nantinya. Berikut ini instruksi-instruksi instalasi nagios (instalasi CentOS terdapat dalam lampiran)
Instalasi Apache HTTP dengan perintah yum cara yum install httpd.
Instalasi GD library dengan cara yum install gcc
67
Membuat user dan group nagios, sebagai berikut : [root@localhost~]# useradd -s /bin/false -d /usr/lib/nagios nagios
Membuat grup baru dengan nama nagcmd untuk memungkinkan external command di-submit melalui web interface. Tambahkan user nagios dan user apache ke group nagcmd. [root@localhost~]# groupadd nagcmd [root@localhost~]# usermod -G nagcmd nagios [root@localhost~]# usermod -G nagcmd apache
Kemudian ekstrak nagios sebagai berikut (diasumsikan
nagios
hasil
download terletak di /root/Desktop). [root@localhost~]#
tar -xzvf /root/Desktop/nagios-
3.2.3.tar.gz
Selanjutnya mengkompilasi nagios sebagai berikut, [root@localhost~]# cd nagios-3.2.3 [root@localhost nagios-3.2.3]# ./configure -prefix=/usr/lib/nagios --with-command-group=nagcmd [root@localhost nagios-3.2.3]# make all
Instalasi binaries, init script, contoh konfigurasi dan men-setting permissions pada direktori external command, sebagi berikut: [root@localhost [root@localhost [root@localhost [root@localhost
nagios-3.2.3]# nagios-3.2.3]# nagios-3.2.3]# nagios-3.2.3]#
make make make make
install install-init install-config install-commandmode
Pada saat instalasi diatas, semua sampel file konfigurasi nagios dikopikan ke direktori /usr/lib/nagios/etc. Dengan sampel file konfigurasi ini seharusnya nagios sudah dapat berjalan, tetapi harus disesuaikan dengan kebutuhan.
File
konfigurasi
yang
perlu
disesuaikan
yaitu
file
68
/usr/lib/nagios/etc/objects/contacts.cfg.
Definisikan
contact
dan
contactgroup seperti berikut : define contact{ contact_name nagiosadmin ; Short name of user use generic-contact ; Inherit default values from generic-contact template (defined above) alias Nagios Admin ; Full name of user email
[email protected]; <<** isi dengan email Anda } define contactgroup{ contactgroup_name admins alias Nagios Administrators members nagiosadmin }
Konfigurasi web interface. Menginstal file konfigurasi web nagios ke dalam /etc/httpd.conf.d dengan cara sebagai berikut: [root@localhost nagios-3.2.3]# make install-webconf
Membuat user account nagiosadmin untuk dapat login ke web interface nagios [root@localhost nagios-3.2.3]# htpasswd -c /usr/lib/nagios/etc/htpasswd.users \ nagiosadmin
Kemudian restart service apache http server agar membaca konfigurasi terbaru [root@localhost nagios-3.2.3]# service httpd restart
Kompilasi dan Instalasi Nagios Plugin
Ekstrak nagios plugin sebagai berikut ( diasumsikan nagios plugin hasil download ada di /root/Desktop) [root@localhost~]# tar -xzvf /root/Desktop/nagios-plugins1.4.15.tar.gz
69
Selanjutnya mengkompilasi dan menginstal nagios sebagai berikut [root@localhost ~]# cd nagios-plugins-1.4.15 [root@localhost nagios-plugins-1.4.15]#./configure – prefix=/usr/lib/nagios \--with-nagios-user=nagios –withnagios-group=nagios [root@localhost nagios-plugins-1.4.15]# make [root@localhost nagios-plugins-1.4.15]# make install
Mengaktifkan Nagios
Tambahkan atau daftarkan Nagios ke dalam system service dan setting Nagios agar diaktifkan secara otomatis saat booting [root@localhost ~]# chkconfig --add nagios [root@localhost ~]# chkconfig nagios on
Verifikasi atau periksa file konfigurasi [root@localhost ~]# /usr/lib/nagios/bin/nagios -v /usr/lib/nagios/etc/nagios.cfg
Jika dari verifikasi tidak ada pesan error , selanjutnya aktifkan nagios [root@localhost ~]# service nagios start
Selanjutnya web
interface
nagios
dapat
diakses
melalui
url http://localhost/nagios/. Jika konfigurasi nagios sudah benar kemudian login dengan username dan password yang sebelumnya telah dibuat, maka akan terlihat seperti gambar berikut.
70
Gambar 4.3 Nagios Interface
Menambah host yang akan dimonitoring Pada konfigurasi default, nagios hanya memonitor sebuah host yaitu localhost. Untuk dapat memonitor LDAP master perlu dilakukan penambahan host dengan cara membuat file konfigurasi monitoring host tersebut. Caranya sebagai berikut:
Salinlah file konfigurasi untuk memonitoring host localhost.cfg, beri nama sesuai ldapmaster.cfg. [root@localhost~]#cp /usr/lib/nagios/etc/objects/localhost.cfg \ /usr/lib/nagios/etc/objects/ldapmaster.cfg
Kemudian ubah dan sesuaikan konfigurasi untuk ldapmaster. Misalkan service yang diinginkan adalah ping, http, ssh, dll. [root@localhost~]#vi usr/lib/nagios/etc/objects/ldapmaster.cfg
Sesuaikan isi file ldapmaster.cfg seperti berikut :
71
define host{ use linux-server ; Name of host template to use ; This host definition will inherit all variables that are defined ; in (or inherited by) the linux-server host template definition. host_name ldapmaster alias ldapmaster address 202.46.240.78 } define service{ use local-service ; Name of service template to use host_name ldapmaster service_description PING check_command check_ping!100.0,20%!500.0,60% } define service{ use local-service ; Name of service template to use host_name ldapmaster service_description SSH check_command check_ssh notifications_enabled 0 } define service{ use local-service ; Name of service template to use host_name ldapmaster service_description HTTP check_command check_http notifications_enabled 0 }
Kemudian dengan skenario bahwa ldapmaster adalah masuk dalam hostgr oup linuxservers, maka perlu diedit bagian definisi hostgroup yang ada pada localhost.cfg dengan menambahkan ldapmaster sebagai member dari hostgroup linux-server, sebagai berikut : [root@labtop1~]#vi /usr/lib/nagios/etc/objects/localhost.cfg define hostgroup{ hostgroup_name hostgroup alias group members separated list of hosts }
linux-servers
;
The
name
of
the
Linux Servers ; Long name of the localhost, ldapmaster that belong to this group
;
Comma
72
Selanjutnya edit file /usr/lib/nagios/etc/nagios.cfg, untuk menambahkan direktori
tempat
ldapmaster
berada
dibawah
cfg_file=/usr/lib/nagios/etc/objects/localhost.cfg, sehingga
baris menjadi
sebagai berikut: # Definitions for monitoring the local (Linux) host cfg_file=/usr/lib/nagios/etc/objects/localhost.cfg cfg_file=/usr/lib/nagios/etc/objects/ldapmaster.cfg
Selanjutnya, verifikasi apakah konfigurasi yang dilakukan sudah benar dengan cara sebagai berikut: [root@labtop1~]# /usr/lib/nagios/bin/nagios -v usr/lib/nagios/etc/nagios.cfg
Setelah diinstal dan dilakukan penambahan host LDAP master akan didapatkan sebuah laporan mengenai availability host tersebut.
Gambar 4.4 Grafik Availability LDAP master 11 Juli s.d 12 Agustus 2011
73
Berdasarkan analisis menggunakan Nagios sejak tanggal 11 Juli 2011 sampai dengan 12 Agustus 2011, LDAP server memiliki tingkat availability sebesar 93 %.
4.2
Desain/ Perancangan Tahap analisis menghasilkan rincian spesifikasi kebutuhan dari sistem yang akan dibangun. Tahap perancangan menjadikan rincian spesifikasi kebutuhan untuk menghasilkan spesifikasi rancangan sistem yang akan dibangun. Berdasarkan analisis permasalahan diatas, maka untuk menyelesaikannya dilakukan desain fisik dan desain logis dengan menambahkan sebuah replika pada server eksternal LDAP sebagai redundan.(Gambar 4.5)
74
4.2.1 Desain Topologi Fisik
Gambar 4.5 Desain penambahan 1 buah replika LDAP server dalam topologi fisik jaringan BPPT
75
4.2.2 Desain Topologi Logis
Gambar 4.6 Desain topologi logik replikasi LDAP master-slave server User/ client yang akan mengakses email harus melakukan login terlebih dulu dengan memasukkan alamat email dan password-nya. Setelah itu, mail server akan mengecek username dan password yang terdapat di LDAP master server. Jika LDAP master server tidak dapat diakses, maka secara otomatis mail server akan mengecek username dan password ke LDAP slave server. LDAP akan mencocokkan data yang dimasukkan oleh user dengan yang ada di direktori. Berikutnya, jika data sesuai, user dapat membuka mail. Jika tidak, user harus melakukan login ulang. Dalam sistem ini menggunakan single-master replication, hanya satu server berisi writable copy dari suatu direktori yang diberikan entri. Semua replika berisi salinan read-only entri tersebut. Sedangkan hanya master server yang dapat melakukan operasi write, server apapun dapat
76
melakukan search, compare, atau bind. Model pemasangan master-slave server dilakukan secara paralel.
Gambar 4.7 Sistem Pemasangan Paralel
Ciri khas dari direktori adalah melakukan operasi pencarian lebih banyak dari memodifikasi operasi, itu menguntungkan bagi penggunaan replika read-only. Server replika read-only bisa menangani operasi pencarian seperti master server write. Dalam replikasi refreshAndPersist, jenis replikasi slave yang memulai koneksi dengan master, sinkronisasi dari DIT segera mengambil tempat dan kemudian pada akhir proses ini koneksi tetap dipertahankan (persist). Perubahan yang terjadi pada master selanjutnya akan disebarkan ke slave.
4.3
Simulasi Prototipe Pada tahap ini dilakukan perhitungan availability secara matematis, sebelumnya telah dilakukan analisis availability selama tiga puluh dua hari menggunakan NMS tools Nagios. Diketahui : Uptime
= 30d 13h 35m 42s
= 2.640.942s
Downtime
= 1d 22h 52m 24s
=
Total time
= 32d 12h 28m 6s
= 2.809.686s
168.744s
77
Ditanya : Availability? Jawab
: Availability
uptime x100% totaltime
Availability
2.640.942 x100% 2.809.686
Availability = 0.939 x 100% = 93.9% Berdasarkan perhitungan, availability LDAP master selama 32 hari adalah sebesar 93.9%. Perhitungan Availability Provider-Consumer Server Sistem availability dihitung berdasarkan pemodelan sistem sebagai keterkaitan bagian dalam seri dan paralel. Aturan berikut ini dipakai untuk memutuskan apakah komponen harus ditempatkan secara seri atau paralel:
Jika kegagalan sebagian mengarah ke gabungan menjadi tidak dapat beroperasi, kedua bagian itu dianggap sebagai beroperasi secara seri.
Jika kegagalan sebagian mengarahkan bagian lainnya untuk mengambil alih pengoperasian dari bagian yang gagal, dua bagian ini dianggap beroperasi secara paralel. Maka dalam hal ini, LDAP master-slave server dianggap beroperasi
secara paralel. Sebagaimana dinyatakan di atas, dua bagian dianggap beroperasi secara paralel jika kombinasi tersebut dianggap gagal ketika kedua bagian gagal. Perhitungan berikut ini, diasumsikan LDAP slave server memiliki availability yang sama dengan availability LDAP master server yang di dapat sebelumnya.
78
Availability
= 1 – (1- Ax)2 = 1 – {(1-A1)*(1-A2)} = 1 – {(1-0.93)*(1-0.93)}
`
= 1 – {(0.07)*(0.07)} = 1 – (0.0049) = 0.9951 → 99.51%
Berdasarkan perhitungan, ketika dilakukan replikasi dengan 1 redundan menggunakan sistem paralel maka availability gabungan akan meningkat 5.61%. Implikasi dari persamaan di atas adalah bahwa gabungan availability dari dua komponen secara paralel selalu jauh lebih tinggi dari availability komponen individu.
4.4
Implementasi 4.4.1 Instalasi OpenLDAP Sebelumnya diasumsikan, konfigurasi LDAP master sudah berjalan. Namun, agar lebih jelas maksud yang disampaikan, maka pengaturan root directory pada LDAP master server pun disertakan. Sedangkan slave server belum terinstal. Jika slave server yang akan diinstal openLDAP sudah terhubung dengan internet, maka untuk instalasi openLDAP cukup menggunakan langkah-langkah sebagai berikut : 1.
Pada terminal ketikan yum search openldap untuk mengetahui file OpenLDAP apa saja yang harus diunduh.
79
Gambar 4.8 Pencarian file instalasi OpenLDAP 2. Setelah OpenLDAP paket-paket yang harus diunduh ditemukan, maka proses instalasi dimulai dengan memasukkan perintah yum install openldap*.
Gambar 4.9 Proses instalasi OpenLDAP
80
3.
Ketik ‘Y’ untuk memulai proses instalasi.
Gambar 4.10 Instalasi OpenLDAP berhasil
Membuat password LDAP dengan menggunakan enkripsi MD5, perintahnya adalah slappasswd –s 1234567 –h {MD5}. Salin password yang di dapat di tempat lain, password ini dapat dimasukkan ke konfigurasi slapd.conf
Gambar 4.11 Membuat password LDAP
4.
Menyalin file DB_CONFIG.example yang terletak di direktori /etc/openldap ke direktori /var/lib/ldap/ lalu nama file tersebut diganti
81
menjadi
DB_CONFIG.
Perintah
yang
digunakan:
cp
etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG.
Gambar 4.12 Perintah menyalin file DB_CONFIG
5.
Untuk memulai layanan LDAP digunakan perintah service ldap start. Setelah itu, dimasukkan perintah chkconfig ldap on supaya
layanan LDAP otomatis dijalankan pada saat startup.
Gambar 4.13 Memulai LDAP
4.4.2 Replikasi Metode replikasi yang dilakukan adalah syncrepl RefreshAndPersist karena untuk openLDAP versi 2.3 keatas, penggunaan replikasi slurpd dianggap sudah usang. Bahkan untuk openLDAP versi 2.4 penggunaan replikasi slurpd sudah ditinggalkan. Pada replikasi syncrepl, istilah master diganti menjadi provider (penyedia) dan untuk slave menjadi consumer (konsumen). 4.5.2.1 Provider (Penyedia) 1. Setelah kedua server LDAP telah ter-install aplikasi atau program LDAP server ataupun client, masuklah ke folder /etc/openldap/
dengan
menggunakan
perintah
cd
/etc/openldap lalu konfigurasikan pada file slapd.conf dengan
82
memasukkan perintah nano slapd.conf. Sesuaikan konfigurasi slurpd.conf provider dan konfigurasi consumer.
include include include include
/etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema
pidfile argsfile
/var/run/openldap/slapd.pid /var/run/openldap/slapd.args
modulepath /usr/lib64/openldap access to * by self write by dn.children="ou=Administrator,dc=bppt,dc=go,dc=id" write by dn.children="ou=Manager,dc=bppt,dc=go,dc=id" write by * read ##################################################### # ldbm and/or bdb database definitions ##################################################### database bdb suffix "dc=bppt,dc=go,dc=id" rootdn "cn=adminbppt,dc=bppt,dc=go,dc=id" rootpw {MD5}D522YT4/P4RD5xFIx5OzfA== index index index index index
objectClass ou,cn,mail,surname,givenname uidNumber,gidNumber,loginShell uid,memberUid nisMapName,nisMapEntry
eq,pres eq,pres,sub eq,pres eq,pres,sub eq,pres,sub
2. Membuat struktur hirarki direktori database LDAP, dengan mendefinisikannya dalam slapd.conf database bdb suffix "dc=bppt,dc=go,dc=id"
3. Mendefinisikannya
rootdn,
yaitu
sebuah
entry
DN(Distinguished Name) untuk seorang user yang tidak dibatasi oleh akses kendali atau seorang administrator direktori LDAP.
83
rootdn
"cn=adminbppt,dc=bppt,dc=go,dc=id"
4. Mendefinisikan password rootpw, yaitu password untuk rootdn sebagai berikut rootpw
{MD5}D522YT4/P4RD5xFIx5OzfA==
5. Mendefinisikan direktori tempat berisi seluruh data direktori LDAP untuk struktur database ini directory /var/lib/ldap
6. Provider diimplementasikan sebagai overlay, sehingga overlay itu sendiri harus terlebih dahulu dikonfigurasi di slapd.conf sebelum dapat digunakan. Provider hanya memiliki dua perintah konfigurasi, yaitu untuk pengaturan checkpoints di contextCSN dan untuk konfigurasi log sesi. overlay syncprov syncprov-checkpoint 100 10
7. Log sesi dikonfigurasi dengan syncprov-sessionlog <size> direktif, dimana <size> adalah jumlah maksimum entri-entri log sesi yang dapat merekam. Ketika log sesi dikonfigurasi, maka secara otomatis digunakan untuk semua pencarian LDAP Sync dalam database. syncprov-sessionlog 100
8. Selanjutnya, melakukan konfigurasi pada file client yang berguna sebagai identitas LDAP bagi server lain yang ingin terhubung ke LDAP dengan menggunakan perintah nano ldap.conf.
84
Gambar 4.14 Konfigurasi client LDAP
9. Mengaktifkan LDAP provider server dengan perintah service ldap restart
10. Menambahkan
menambahkan entri root
database dengan cara membuat
hirarki direktori
file ldif yang diberi nama
base.ldif lalu masuk ke direktori openldap dengan memasukkan perintah cd /etc/openldap. Kemudian untuk menambahkan entri yang berada di dalam base.ldif ke LDAP, user harus login sebagai manajer LDAP dan melalui proses otentikasi sederhana dengan
menggunakan
perintah
ldapadd
“cn=adminbppt,dc=bppt,dc=go,dc=id”
–f
–x
–W
–D
base.ldif.
Perintah –x meminta server untuk melakukan proses otentikasi sederhana. Perintah –W meminta pada client untuk memasukkan password LDAP. –D “cn=adminbppt,dc=bppt,dc=go,dc=id” menentukan DN mana yang digunakan untuk terhubung dengan direktori. –f untuk menentukan file mana yang akan ditambahkan.
85
Gambar 4.15 Memasukan data ke LDAP
11. Kemudian untuk menambahkan entri yang berada di dalam migration.ldif
digunakan
perintah
ldapadd
–x
–W
–D
“cn=adminbppt,dc=bppt,dc=go,dc=id” –f migration.ldif,
lalu masukkan password LDAP.
12. Cek dan tampilkan isi database direktori LDAP provider server dan backup ke sebuah file bernama contents.ldif #ldapsearch -x -b "dc=bppt,dc=go,dc=id" #ldapsearch
-x
-b
"dc=bppt,dc=go,dc=id
"
>
contents.ldif
13. Salin file backup (contents.ldif) database direktori LDAP provider server ke LDAP consumer server.
4.5.2.2 Consumer (Konsumen) 1. Membuat struktur hirarki direktori database LDAP, dengan mendefinisikannya
dalam
file
(/etc/openldap/slapd.conf) database ldbm suffix "dc=bppt,dc=go,dc=id"
konfigurasi
LDAP
server
86
2. Mendefinisikannya
rootdn,
yaitu
sebuah
entry
DN
(Distinguished Name) untuk seorang user yang tidak dibatasi oleh akses kendali atau seorang administrator direktori LDAP, sebagai berikut: rootdn
"cn=adminbppt,dc=bppt,dc=go,dc=id"
3. Mendefinisikan password rootpw, yaitu password untuk rootdn rootpw
{MD5}X03MO1qnZdYdgyfeuILPmQ==
4. Mendefinisikan direktori tempat berisi seluruh data direktori LDAP untuk struktur database ini directory /var/lib/ldap
5. Menambahkan # syncrepl directives, provider diisi dengan ip address LDAP provider server. syncrepl rid=100 provider=ldap://202.46.240.78:389 type=refreshAndPersist #reconnect/re-sync every 15 minutes interval=00:00:15:00 retry="5 5 300 +" searchbase="dc=bppt,dc=go,dc=id" filter="(objectClass=*)" attrs="*,+" bindmethod=simple binddn="cn=adminbppt,dc=bppt,dc=go,dc=id" credential=secret
6. Selanjutnya, melakukan konfigurasi pada file client yang berguna sebagai identitas LDAP bagi server lain yang ingin terhubung ke LDAP dengan menggunakan perintah nano ldap.conf. Salin ldap.conf yang terdapat dalam provider server.
87
7. Mengaktifkan LDAP consumer server dengan perintah service ldap start
8. Menambahkan entri baru ke dalam LDAP consumer server dengan entri yang ada dalam file hasil backup (contents.ldif) database direktori LDAP provider server sebagai berikut: #ldapadd -x -D "cn=adminbppt,dc=bppt,dc=go,dc=id" -f contents.ldif -W
Masukan password LDAP consumer server jika diminta
4.4.3 Integrasi Zimbra - LDAP Consumer Server Langkah-langkah untuk mengintegrasikan email dengan LDAP Consumer Server adalah sebagai berikut:
Menu yang harus dipilih di Zimbra-nya adalah Configuration > Domains > bppt.go.id > Configure Authentication. Perhatikan, Authentication mechanism : External LDAP.
Gambar 4.16 Authentication Settings
88
Tambahkan sebuah LDAP url dengan menekan tombol “add URL”. Isilah field yang tersedia. Field ‘ldap://’ diisi dengan IP address LDAP consumer server dengan port 389. Pada ‘LDAP filter:’ diisi dengan (&(uid=%u)(employeeType=staff)). Lalu pada ‘LDAP search base:’ diisi dengan ou=People,dc=bppt,dc=go,dc=id. Kemudian pilih tombol Next.
Gambar 4.17 Tambah LDAP url di Authentication Settings
Setelah
itu,
field
‘Bind
‘cn=adminbppt,dc=bppt,dc=go,dc=id’.
DN’ Lalu
‘Bind
diisi
dengan
password:’
dan
‘Confirm bind password:’ digunakan untuk membuat password bagi proses bind. Pilih tombol Next.
89
Gambar 4.18 Membuat Password Bind
Kemudian akan ditampilkan data-data yang telah diisikan ke dalam fieldfield yang diminta. Username dan password salah satu user dimasukkan untuk mengetes setting otentikasinya. Pilih tombol Test.
Gambar 4.19 Authentication Settings Zimbra
Jika proses otentikasi berhasil, maka akan ditampilkan halaman “Authentication Test Result” > Authentication test successful . Pilih tombol Next.
90
Gambar 4.20 Authentication Test Succesful
Kemudian pilih tombol Next untuk menampilkan halaman “Domain Configuration Complete”. Lalu pilih tombol Finish untuk menyimpan dan menyelesaikan konfigurasi.
Gambar 4.21 Domain Configure Complete
91
4.5
Monitoring 4.5.1 Pengujian Proses Replikasi Direktori LDAP Untuk menguji apakah proses replikasi direktori LDAP provider-consumer server sudah berjalan, lakukan cara berikut ini:
Tambahkan entri data pada LDAP provider server dengan sebelumnya membuat file ldif yang berisi # fatimah.indraswati, People, bppt.go.id dn: uid=fatimah.indraswati,ou=People,dc=bppt,dc=go,dc=id cn: Fatimah Indraswati displayName: Fatimah Indraswati,S.Kom uid: fatimah.indraswati givenName: Fatimah sn: Indraswati objectClass: inetOrgPerson objectClass: top userPassword:: e01ENX10cFpxbzBwbmNIYUhsWE0zR0g5eUhBPT0= mail:
[email protected] employeeNumber: 198910082012011001 employeeType: staff businessCategory: Biro Sumberdaya Manusia dan Organisasi
Simpan file ini dengan nama update.ldif dan lakukan proses penambahan entri ke LDAP provider server #ldapadd
-x
-D
"cn=adminbppt,dc=bppt,dc=go,dc=id"
-f
update.ldif –W
Cari dan tampilkan entri yang baru ditambahkan kedalam database direktori provider server pada consumer server dengan perintah ldapsearch #ldapsearch -x – b"uid=fatimah.indraswati,dc=bppt,dc=go,dc=id"
Jika berhasil, hasilnya adalah provider server menyebarkan perubahan yang terjadi sehingga entri direktori consumer server ter-update.
92
Lakukan
instalasi
phpLDAPadmin
(terdapat
dalam
lampiran),
phpLDAPadmin berguna untuk mengelola direktori LDAP dalam bentuk web. Sekarang cobalah login ke direktori LDAP consumer server dengan
mengetikan
alamat
http://10.1.82.241/phpldapadmin/htdocs/index.php.
di Isilah
browser login
DN
dengan “cn=adminbppt, dc=bppt,dc=go,dc=id” kemudian isi password dengan password LDAP consumer server.
Gambar 4.22 Login dengan phpLDAPadmin
Jika berhasil, maka akan masuk ke halaman akun “adminbppt” yang akan menampilkan hirarki LDAP. Hal tersebut perlu dilakukan, untuk memastikan LDAP consumer server sudah berjalan dengan baik, dan sama dengan provider server.
Gambar 4.23 Sukses login ke server LDAP
93
4.5.2 Pengujian Login Email Tahap ini merupakan bagian yang penting, setelah dilakukan pengujian server dengan phpLDAPadmin, maka akan coba untuk login email. Lakukan langkah-langkah berikut ini:
Matikan layanan LDAP provider server dengan perintah service ldap stop pada terminal linux. Saat user ingin mengakses email, Zimbra
akan mengotentikasi username dan password pada LDAP provider server, karena layanan di provider server dimatikan. Maka Zimbra akan mencari ke consumer server. Jika username dan password terotentikasi, Zimbra akan memberikan izin akses email pada user. Jika tidak maka harus login ulang.
Gambar 4.24 Hentikan layanan LDAP
Setelah service LDAP provider server dimatikan. Bukalah browser dan ketikan “mail.bppt.go.id”, isilah dengan akun yang ada, misalkan dengan alamat email
[email protected] maka username: fulan.fulanah password: bppt1234.
94
Gambar 4.25 Login email
Jika berhasil maka akan dibawa ke halaman akun fulan.fulanah seperti di gambar di bawah ini.
Gambar 4.26 Halaman Akun email
4.5.3 Evaluasi Setelah implementasi provider-consumer server, kedua server tersebut dipantau kembali availability-nya menggunakan tools Nagios. Berikut ini adalah hasil pemantauan LDAP provider server dan LDAP consumer server pada tanggal 12 Agustus 2011 sampai dengan 12 September 2011.
95
Gambar 4.27 Data Availability tanggal 12 Agustus s.d 12 September 2011 Pada gambar di atas dapat dilihat bahwa, availability LDAP provider server
setelah ada redundan menjadi 99.873% meningkat sekitar 6%
dibandingkan saat tidak menggunakan redundan. Sedangkan LDAP consumer server sendiri juga memiliki availability yang sempurna yaitu 100%. Nilai ratarata availability yang didapat oleh kedua server tersebut menjadi 99.958% atau mengalami downtime sekitar 3.5 jam/tahun. (gambar selengkapnya terdapat di lampiran)
4.6
Manajemen Tahapan monitoring telah dilakukan, pada tahap manajemen
kegiatan
perawatan, pemeliharaan, dan pengelolaaan dikategorikan pada tahap ini. Proses pengelolaan sejalan dengan kegiatan pemeliharaan sistem yaitu meliputi pengelolaan sistem dengan menggunakan NMS tools Nagios dan membuat cek availability secara berkala, Nagios telah menyediakan pluginplugin yang memadai untuk memberikan informasi jaringan. Perawatan hardware juga harus dilakukan penjadwalan, kebijakan tersebut perlu dibuat untuk membuat/ mengatur agar sistem yang telah dibangun dan berjalan dengan baik dapat berlangsung lama dan unsur reliability terjaga.
BAB V PENUTUP
Berdasarkan uraian dan hasil pembahasan yang telah diuraikan pada bab-bab sebelumnya, maka dapat ditarik kesimpulan dan saran. 5.1 Kesimpulan 1. Merancang dan mengimplementasikan replikasi direktori merupakan cara untuk mengoptimasi kinerja LDAP provider server untuk meningkatkan availability sehingga ketika salah satu server down maka server lain akan mengambil alih tugasnya dalam manajemen user mail server sehingga layanan email dapat terus berjalan. 2. Availability LDAP provider sebelum replikasi adalah sebesar 93%. Setelah dilakukan replikasi gabungan availability LDAP providerconsumer server mencapai 99.958%. 3. Sistem pemasangan secara paralel dapat meningkatkan availability, gabungan availability dari dua komponen secara paralel dapat melebihi availability komponen individu. Oleh sebab itu, semua sistem mesin kritis dirancang dengan komponen redundan.
5.2 Saran Dibuatnya sistem ini tidak terlepas dari beberapa kekurangan. Berikut beberapa saran yang dapat diberikan untuk perkembangan lebih lanjut dari kemampuan sistem di masa yang akan datang:
96
97
1. Saat ini, protokol yang digunakan oleh OpenLDAP di BPPT masih menggunakan default protokol yaitu port 389. Maka, untuk penelitian selanjutnya disarankan menggunakan protocol-protokol jaringan yang memiliki tingkat security lebih baik seperti pengunaaan TLS (Transport Layer Security) atau SSL (Secure Socket Layer) maupun FTPS (FTP Secure). 2. Saat ini LDAP yang digunakan merupakan server LDAP eksternal padahal Zimbra itu sendiri memiliki layanan Zimbra LDAP. Sehingga ini membuat penggunaan hardware kurang efisien karena seharusnya server Zimbra mail dapat digabung dengan LDAP. 3. Untuk penelitian selanjutnya yang menggunakan OpenLDAP, diharapkan mengembangkan dan memodifikasi hal yang terkait dalam hal biaya (cost) dan keamanan (security).
DAFTAR PUSTAKA
Adiprabowo, P. Kusmiyati, E. Rahardjo, S.A.W.2011. Penggunaan Single Sign On (SSO) Pada Jaringan Internet Pada Badan Pengkajian Dan Penerapan Teknologi (BPPT). Anonim. 2011. Replication. http://www.openldap.org/. 10 Agustus 2011, pkl.14.42 WIB. Anonim. 2011. System Reliability and Availability. http://eventhelix.com/. 25 Agustus 2011, pkl.08.18 WIB. Arkills, B. 2003. LDAP Directories Explained: An Introduction and Analysis. Addison-Wesley. Boston: 330 hlm. Benbow, D.W. & Broom,
H.W. 2008. The Certified Reliability Engineer
Handbook. ASQ Quality Press. Wisconsin: 362 HLM. Boronczyk,T. & Negus C. 2009 . CentOS Bible . Wiley Publishing, Inc.Indiana: 947 hlm. Butcher, M. 2007. Mastering OpenLDAP. Packt Publishing Ltd. Birmingham : 459 hlm. Burgess, C. 2005. The Nagios Book. Preview pre-release.44 hlm. Carter, G. 2003. LDAP System Administration. O'Rei lly.California:308 hlm. Goldman, J.E & Rawles, P.T. 2004. Applied Data Communications: A BusinessOriented Approach. John Wiley & Sons Inc. 608 hlm.
Howes, T.A., M.C. Smith, & G.S.Good. 2003. Understanding and Deploying LDAP Directory Services, Second Edition. Addison Wesley. Boston : 936 hlm. IEEE Computer Society. 2007 . IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. The Institute of Electrical and Electronics Engineers, Inc. USA: 33 hlm. Djunawidjaja, J., 2005. Integrasi User Account dengan LDAP. Majalah Info Linux . 7: 62-65. Johner, H., M.Melot, H.Stranden, & P. Widhiasta. 1999 . LDAP Implementation Cookbook. First Edition. IBM Corp . Texas: 293 hlm. Kurniawan,W. 2007. Jaringan Komputer. Penerbit Andi.Yogyakarta:211 hlm. Malère, L. E.P. 2007. LDAP Linux HOWTO. 37 hlm. Muslikhah. 2011. Studi dan Implementasi Nagios Studi Kasus PEMDA JAKARTA. Perpustakaan FST Oggerino, C. 2001. High availability network fundamentals. Cisco Press. Indianapolus: 237 hlm. Salim, M., Akhtar, M.S., & Qadeer,M.A. 2009. Data Retrieval and Security using Lightweight Directory Access Protocol. Second International Workshop on Knowledge Discovery & Data Mining: 4 hlm. Saptono,
H.
2008.
Network Monitoring System dengan Nagios.
[email protected] Saptono,
H.
Sinkronisasi/
Replikasi
Database
http://overflow.web.id. 18 Juli 2011, pkl. 15.03 WIB.
Direktori
LDAP.
Tuttle, S., A. Ehlenberger, R. Gorthi, J. Leiserson, R.Macbeth, N. Owen, S. Ranahandola, M.Storrs, & Chunhui Yang. 2004. Understanding LDAP Design and Implementation. Second Edition.IBM Corp:735 hlm. Web-master
at
zytrax.
2011.
Chapter
7
Replication
&
Referral.
http://www.zytrax.com/. 10 Agustus 2011, pkl.12.18 WIB. Web-master Kambingui. Pemilihan Tingkatan RAID Bab 20. Sistem Penyimpanan Masal. http://kambing.ui.ac.id. 11 Agustus 2011, pkl.13.17 WIB. Permana, Indra. 2010. Analisis Implementasi Otentikasi User Terpusat untuk file, Email, FTP dan Proxy Server Menggunakan OpenLDAP pada Centos 5. Perpustakaan Utama UIN Syarif Hidayatullah Jakarta.
Hasil Wawancara
Tanggal
: Rabu, 27 Maret 2011
Tempat
: Kantor Pusat Data Informasi dan Standardisasi (PDIS)
Narasumber
: Bapak Agung Septiadi, ST
Jabatan
: Staff Aplikasi dan Sistem Jaringan
Hasil Wawancara 1. Q : Bagaimana topologi jaringan di BPPT saat ini? A : Router yang terletak di BPPT Gedung 1 terhubung dengan firewall yang kemudian dari firewall akan terhubung dengan dua buah switch, yaitu switch dan core switch gedung 1. Core switch gedung 1 akan terhubung dengan core switch gedung 2, kemudian kedua core switch tersebut saling terhubung dengan dua core yang redundan. Baru distribution switch terhubung dengan core switch di tiap gedung. Access switch terhubung dengan distribution switch. Setiap komputer di tiap lantai terhubung dengan hub, lalu hub dihubungkan dengan access switch.
2. Q : Apa saja spesifikasi perangkat keras dan perangkat lunak LDAP server yang digunakan di BPPT sekarang? A : Perangkat keras LDAP server menggunakan processor berupa Intel Core 2 Quad @2.33 Ghz dengan memori 2 GB dan kapasistas harddisk
200GB, sedangkan untuk Operating System menggunakan CentOS release 5.5 (Final) dan OpenLDAP 2.3.43-12.e15
3. Q: Bagaimana proses kerja sistem LDAP yang sedang berjalan saat ini terkait availability di BPPT? A : Saat ini LDAP yang sudah ada saat ini dimana hanya terdapat sebuah server eksternal LDAP secara fisik yaitu hanya LDAP master saja. Jika terjadi error, maka server tidak dapat diakses dan semua layanan single sign on yang terkoneksi ke LDAP juga akan mengalami kegagalan. Untuk mencegah hal tersebut maka dibutuhkan sistem yang memiliki availability yang cukup dengan solusi merancang LDAP slave sebagai redundan.
4. Q : Apa saja yang menjadi kebutuhan sistem di BPPT? A : Sebuah sistem yang terjaga availability-nya . Peningkatan personil, baik jumlah dan keahlian, untuk dapat mengoptimalkan distribusi pekerjaan dalam berbagai kegiatan. Pemasangan sebuah tools untuk memonitoring sistem. (Jaringan) Penerapan aturan yang berkaitan dengan sistem informasi, sehingga dapat mengoptimalkan layanan yang diberikan kepada pegawai.
LDAP Provider Server slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema # Allow LDAPv2 client connections. allow bind_v2
This is NOT the default.
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile argsfile
/var/run/openldap/slapd.pid /var/run/openldap/slapd.args
# Load dynamic backend modules: modulepath /usr/lib64/openldap # # # # # # # # # # # # # # # # # #
Modules available in openldap-servers-overlays RPM package Module syncprov.la is now statically linked with slapd and there is no need to load it here moduleload accesslog.la moduleload auditlog.la moduleload denyop.la moduleload dyngroup.la moduleload dynlist.la moduleload lastmod.la moduleload pcache.la moduleload ppolicy.la moduleload refint.la moduleload retcode.la moduleload rwm.la moduleload smbk5pwd.la moduleload translucent.la moduleload unique.la moduleload valsort.la
# modules available in openldap-servers-sql RPM package: # moduleload back_sql.la # sizelimit punya pak Rudi sizelimit 4096 # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # # # # # # # # # # # # # # # # # # # #
Sample access control policy: Root DSE: allow anyone to read it Subschema (sub)entry DSE: allow anyone to read it Other DSEs: Allow self write access Allow authenticated users read access Allow anonymous users to authenticate Directives needed to implement policy: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth if no access controls are present, the default policy allows anyone and everyone to read anything but restricts updates to rootdn. (e.g., "access to * by * read") rootdn can always read and write EVERYTHING!
access to * by self write by dn.children="ou=Administrator,dc=bppt,dc=go,dc=id" write by dn.children="ou=Manager,dc=bppt,dc=go,dc=id" write by * read ################################################################## ##### # ldbm and/or bdb database definitions ################################################################## ##### database bdb suffix "dc=bppt,dc=go,dc=id" rootdn "cn=adminbppt,dc=bppt,dc=go,dc=id" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret rootpw {MD5}D522YT4/P4RD5xFIx5OzfA==
# The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass index ou,cn,mail,surname,givenname index uidNumber,gidNumber,loginShell index uid,memberUid index nisMapName,nisMapEntry
eq,pres eq,pres,sub eq,pres eq,pres,sub eq,pres,sub
# Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/
[email protected] # Replicas of this database #note : # the provider configuration contains no reference to any consumers #define the provider to use the syncprov overlay #(last directives in database section) overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://ldap.bppt.go.id BASE dc=bppt,dc=go,dc=id BINDDN cn=adminbppt,dc=bppt,dc=go,dc=id SIZELIMIT 0 TIMELIMIT 0 #TLS_CACERTDIR /etc/openldap/cacerts
LDAP Consumer Server slapd.conf # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. include include include include
/etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. allow bind_v2
This is NOT the default.
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
pidfile argsfile
/var/run/openldap/slapd.pid /var/run/openldap/slapd.args
# Load dynamic backend modules: modulepath # # # # # # # # # # # # # # # # # # # #
/usr/lib64/openldap
Modules available in openldap-servers-overlays RPM package Module syncprov.la is now statically linked with slapd and there is no need to load it here moduleload accesslog.la moduleload auditlog.la moduleload denyop.la moduleload dyngroup.la moduleload dynlist.la moduleload lastmod.la moduleload pcache.la moduleload ppolicy.la moduleload refint.la moduleload retcode.la moduleload rwm.la moduleload smbk5pwd.la moduleload translucent.la moduleload unique.la moduleload valsort.la modules available in openldap-servers-sql RPM package: moduleload back_sql.la
# sizelimit punya pak Rudi sizelimit 4096 # The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. client software # # # # # # # #
Your
may balk at self-signed certificates, however. TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem Sample security restrictions Require integrity protection (prevent hijacking) Require 112-bit (3DES or better) encryption for updates Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! access to * by dn.children="ou=Administrator,dc=bppt,dc=go,dc=id" write by dn.children="ou=Manager,dc=bppt,dc=go,dc=id" write
################################################################## ##### # ldbm and/or bdb database definitions ################################################################## #####
database suffix rootdn
bdb "dc=bppt,dc=go,dc=id" "cn=adminbppt,dc=bppt,dc=go,dc=id"
# Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {MD5}X03MO1qnZdYdgyfeuILPmQ==
# The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub syncrepl rid=100 provider=ldap://202.46.240.78:389 type=refreshAndPersist #reconnect/re-sync every 15 minutes interval=00:00:15:00 retry="5 5 300 +" searchbase="dc=bppt,dc=go,dc=id" filter="(objectClass=*)" attrs="*,+" bindmethod=simple binddn="cn=adminbppt,dc=bppt,dc=go,dc=id" credential=secret updateref ldap://202.46.240.78
ldap.conf # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://ldap.bppt.go.id BASE dc=bppt,dc=go,dc=id TLS_CACERTDIR /etc/openldap/cacerts
Instalasi Centos Sistem operasi linux yang digunakan disini adalah CentOS 5.6. Berikut ini instruksi-instruksi instalasi CentOS:
Unduh CentOS 5.6 DVD atau 6 CD CentOS dari sebebuah link mirror (daftar mirror dapat ditemukan disini http://centos.biz.net.id/)
Pertama, boot CD 1 CentOS 5.6 atau DVD 5.6. Tekan <Enter> pada prompt boot.
Lewatkan tahap selanjutnya karena tahap ini memakan waktu cukup lama.
Muncul welcome screen CentOS, tekan next
Pilih bahasa, tekan next
Pilih layout keyboard kemudian tekan next
Muncul peringatan untuk partisi harddisk. Jika menginstal pada server yang masih kosong maka pilihlah jawaban “Yes” pada pertanyaan “Would you like to initialize this drive erasing ALL DATA?”
Sekarang kita harus memilih skema partisi untuk instalasi. Agar lebih mudah pilih “Remove linux partitions on selected drives and create default layout”. Hal ini akan mengakibatkan /boot dan partisi serta partisi swap. Partisikan harddisk sesuai dengan kebutuhan kemudian tekan next
Jawab pertanyaan ini dengan “yes”
Aktifkan pengaturan jaringan, pengaturan default disini adalah untuk mengkonfigurasi interface secara DHCP. Pilih DHCP untuk memudahkan, konfigurasi IP statis nanti dapat dilakukan setelah tahap instalasi CentOS selesai. Tekan next
Pilihlah zona waktu kemudian tekan next
Berikan password root kemudian tekan next
Sekarang pilihlah software yang ingin diinstal. Pilih server (hapus centang kecuali server), juga hapus centang “Packages from CentOS Extras.”
Selanjutnya akan ada pilihan grup paket yang ingin diinstal. Hapus semua centang kemudian tekan next. Installer memeriksa dependensi paket yang dipilih kemudian tekan next
Tekan next untuk mulai instalasi
Harddisk diformat dan proses instalasi berjalan dalam waktu beberapa menit.
Instalasi selesai dan secara otomatis CD/DVD akan dikeluarkan dan komputer akan reboot.
Instalasi phpLDAPadmin
1. install web server untuk manajemen ldap server, jalankan perintah ini di terminal # yum install httpd php-mbstring php-ldap
2. Download phpldapadmin dari website http://phpldapadmin.sourceforge.net/download.php, cari versi yang terakhir #wget http://internode.dl.sourceforge.net/sourceforge/phpldapadmin/ph pldapadmin-1.1.0.5.zip
3. install phpldapadmin sebagai halaman utama dari webserver di /var/www/html #unzip phpldapadmin-1.1.0.5.zip -d /var/www/ #cp /var/www/phpldapadmin-1.1.0 /var/www/html -R
4. Konfigurasi phpLDAPadmin #cp /var/www/htm/config.php.example /var/www/html/config/config.php #vi /var/www/html/config/config.php
5. Lakukan editing bagian server agar terhubung ke server ldap: /*********************************************/ /* Define your LDAP servers in this section */ /*********************************************/ $i=0; $ldapservers = new LDAPServers; $ldapservers->SetValue($i,’server’,’name’,’LDAP Slave Server); $ldapservers->SetValue($i,’server’,’host’,’10.1.82.241′); $ldapservers->SetValue($i,’server’,’port’,’389′); $ldapservers->SetValue($i,’server’,’base’,array(”)); $ldapservers->SetValue($i,’server’,’auth_type’,’cookie’); $ldapservers>SetValue($i,’login’,’dn’,’cn=adminbppt,dc=bppt,dc=go,dc=id’); $ldapservers->SetValue($i,’login’,’pass’,”); # $ldapservers->SetValue($i,’login’,’pass’,’secret’); $ldapservers->SetValue($i,’server’,’tls’,false);
6. Masukan alamat http://10.1.82.241/localhost/phpldapadmin untuk mencoba koneksi
Analisis LDAP Provider Server dengan Nagios
Monitoring LDAP Provider Server dengan Nagios Setelah Implementasi
Monitoring LDAP Consumer Server dengan Nagios Setelah Implementasi
