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: bjensen@example.com 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: ssmith@example.com 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 fatimah.indraswati@bppt.go.id 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: fatimah.indraswati@bppt.go.id 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

Email

- 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 ohayodinda@yahoo.com; <<** 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 linux­servers, 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: fatimah.indraswati@bppt.go.id 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 fulan.fulanah@bppt.go.id 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.

henry@nurulfikri.com

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/ldap-master.example.com@EXAMPLE.COM # 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