Upload
truongcong
View
214
Download
0
Embed Size (px)
Citation preview
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
ii
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
iii
iv
v
LEMBAR PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-
BENAR 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
vi
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
vii
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)
viii
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
ix
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
x
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
xi
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
xii
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
xiii
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
xiv
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
xv
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
xvi
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
xvii
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)
xviii
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.
1
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
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.
8
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 tukar-
menukar 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.
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
Tabel 2.1 Lapisan OSI No Lapisan Tugas 1 Physical Bertanggung jawab atas proses data menjadi bit
dan mentransfernya melalui media, seperti kabel, dan menjaga koneksi fisik antar sistem.
2 Data Link Menyediakan hubungan fisik dan kebutuhan untuk mengaktifkan, memperbarui, dan mengaktifkan kembali koneksi.
3 Network Mengelola kebutuhan untuk mentransfer informasi diantara sistem akhir sampai ke beberapa jaringan komunikasi.
4 Transport 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.
5 Session Menyediakan transaksi komunikasi antara dua atau lebih peralatan jaringan.
6 Presentation. Menyediakan format data yang akan ditukar ke application layer, menyediakan sintaks yang digunakan dalam application layer.
7 Application 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
Tabel 2.2 Lapisan TCP / IP Lapisan Tugas
Network 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 Contoh
commonName, cn Cls Nama umum dari sebuah entry
John Smith
surname, sn Cls Nama belakang dari seseorang
Smith
telephoneNumber Tel Nomor telepon 021-7326389 organizationalUnit Name, ou
Cls Nama dari unit organisasi
Tivoli
Owner Dn DN dari orang yang memiliki entry
cn=John Smith, o=IBM,c=us
Organization, o Cls Nama dari organisasi
IBM
jpegPhoto Bin Gambar foto dalam format JPEG
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 bertingkat-
tingkat 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, masing-
masing 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 semi-
otomatis 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)
ntimeAveragedowimeAverageupt
uptime AveragetyAvailabili
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).
Keterangan : A = availability
Tabel 2.4 Perbandingan availability dan downtime
Availability Downtime 90% (1-sembilan) 36.5 hari/tahun 99% (2- sembilan) 3.65 hari/tahun 99.9% (3- sembilan) 8.76 hari/tahun 99.99% (4- sembilan) 52 menit/tahun 99.999% (5- sembilan) 5 menit/tahun 99.9999% (6- sembilan) 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
%100xtotaltimeuptimeA
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 Availability Downtime
X 99% (2-sembilan) 3.65 hari/tahun Y 99.99% (4-sembilan) 52 menit/tahun Gabungan XY 98.99% 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) 3.65 hari/tahun Y 99.99% (4-sembilan) 52 menit/tahun Gabungan XY 99.9999% (6-sembilan) 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 Availability
Konstan Berkurang/ Bertambah Bertambah Bertambah Berkurang Berkurang
2.4 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 dokumen-
dokumen 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 lain-
lain.
Aplikasi tingkat informasi (Apache, Postfix, LDAP, Citrix, dan lain-lain).
8
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.
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 pihak-
pihak 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
59
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.
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 Value Keterangan
Cn Fatimah Indraswati Nama lengkap Sn Indraswati Nama belakang Uid fatimah.indraswati Username Mail [email protected] Email UserPassword e01ENX10cFpxbzBwbmNIYU
hsWE0zR0g5eUhBPT0= Password
GivenName Fatimah Nama depan DisplayName Fatimah Indraswati S.Kom Nama lengkap
dan gelar EmployeeType Staff Status pegawai EmployeeNumber 198910082012011001 NIP pegawai Bussinesscategory
Biro Sumberdaya Manusia dan Organisasi
Divisi
Jika disusun dalam bentuk LDIF maka data di atas akan menjadi:
61
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 yaitu
zimbraAuthLdapURL dan zimbraAuthLdapBindDn.
# 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
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 paket-
paket 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 paket-
paket 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 Spesifikasi perangkat keras Spesifikasi perangkat lunak
LDAP master
- Intel Core 2 Quad @2.33 GHz
- RAM 2 GB - HD 500 GB
- CentOS release 5.5 (Final) - OpenLDAP 2.3.43-12.e15
LDAP slave
- 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) - ZCS-
6.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 Requirement
CentOS-5.6-x86_64 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 nagios-3.2.3]# make install [root@localhost nagios-3.2.3]# make install-init [root@localhost nagios-3.2.3]# make install-config [root@localhost nagios-3.2.3]# make 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 :
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-plugins-1.4.15.tar.gz
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 }
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 –with-nagios-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
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 linux-servers ; The name of the
hostgroup alias Linux Servers ; Long name of the
group members localhost, ldapmaster ; Comma
separated list of hosts that belong to this group }
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 }
72
Selanjutnya edit file /usr/lib/nagios/etc/nagios.cfg, untuk menambahkan
direktori tempat ldapmaster berada dibawah baris
cfg_file=/usr/lib/nagios/etc/objects/localhost.cfg, sehingga 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 = 168.744s
Total time = 32d 12h 28m 6s = 2.809.686s
77
Ditanya : Availability?
Jawab :
%100xtotaltimeuptimetyAvailabili
%100686.809.2942.640.2 xtyAvailabili
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.
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.
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema pidfile /var/run/openldap/slapd.pid argsfile /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 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
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 hirarki direktori
database dengan cara membuat 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 –x –W –D
“cn=adminbppt,dc=bppt,dc=go,dc=id” –f 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 konfigurasi LDAP server
(/etc/openldap/slapd.conf)
database ldbm suffix "dc=bppt,dc=go,dc=id"
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.
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.
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
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 DN’ diisi dengan
‘cn=adminbppt,dc=bppt,dc=go,dc=id’. Lalu ‘Bind 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 field-
field 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
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.
# 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
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 di browser
http://10.1.82.241/phpldapadmin/htdocs/index.php. Isilah 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 rata-
rata 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 plugin-
plugin 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.
96
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 provider-
consumer 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:
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 Business-
Oriented 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.
Saptono, H. Sinkronisasi/ Replikasi Database Direktori LDAP.
http://overflow.web.id. 18 Juli 2011, pkl. 15.03 WIB.
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 me-
monitoring 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. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /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 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 # 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 /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. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /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 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 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 {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/phpldapadmin-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