Pengantar Sistem Operasi: Sebuah Pendekatan Praktis Dengan Menggunakan Proyek OpenSolaris Buku Pedoman Siswa

Pengantar Sistem Operasi: Sebuah Pendekatan Praktis Dengan Menggunakan Proyek OpenSolaris Buku Pedoman Siswa

Qui ckTi m e™ and a de com p re s sor are needed to s ee thi s pi cture.

SunMicrosystems,Inc. 4150NetworkCircle SantaClara,CA95054 USA

Copyright 2007 SunMicrosystems, Inc. 4150Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. SunMicrosystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more U.S. patents or pending patent applications in the U.S. and in other countries. U.S. Government Rights – Commercial software. Government users are subject to the SunMicrosystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. This distribution may include materials developed by third parties. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, SunMicrosystems, the Sun logo, the Solaris logo, the Java Coffee Cup logo, docs.sun.com, Java, and Solaris are trademarks or registered trademarks of SunMicrosystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. TheOPEN LOOK and SunTM Graphical User Interface was developed by SunMicrosystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun's licensees who implementOPEN LOOK GUIs and otherwise comply with Sun's written license agreements. Products covered by and information contained in this publication are controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries.Nuclear, missile, chemical or biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited. DOCUMENTATIONIS PROVIDED “AS IS” AND ALL EXPRESSOR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTYOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSEORNON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCHDISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

Copyright 2007 SunMicrosystems, Inc. 4150Network Circle, Santa Clara, CA 95054 U.S.A. Tous droits réservés. SunMicrosystems, Inc. détient les droits de propriété intellectuelle relatifs à la technologie incorporée dans le produit qui est décrit dans ce document. En particulier, et ce sans limitation, ces droits de propriété intellectuelle peuvent inclure

Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

i

un ou plusieurs brevets américains ou des applications de brevet en attente aux Etats-Unis et dans d'autres pays. Cette distribution peut comprendre des composants développés par des tierces personnes. Certaines composants de ce produit peuvent être dérivées du logiciel Berkeley BSD, licenciés par l'Université de Californie. UNIX est une marque déposée aux Etats-Unis et dans d'autres pays; elle est licenciée exclusivement par X/Open Company, Ltd. Sun, SunMicrosystems, le logo Sun, le logo Solaris, le logo Java Coffee Cup, docs.sun.com, Java et Solaris sont des marques de fabrique ou des marques déposées de SunMicrosystems, Inc. aux Etats-Unis et dans d'autres pays. Toutes les marques SPARC sont utilisées sous licence et sont des marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par SunMicrosystems, Inc. L'interface d'utilisation graphiqueOPEN LOOK et Sun a été développée par SunMicrosystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept des interfaces d'utilisation visuelle ou graphique pour l'industrie de l'informatique. Sun détient une licence non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent en place l'interface d'utilisation graphiqueOPEN LOOK et qui, en outre, se conforment aux licences écrites de Sun. Les produits qui font l'objet de cette publication et les informations qu'il contient sont régis par la legislation américaine en matière de contrôle des exportations et peuvent être soumis au droit d'autres pays dans le domaine des exportations et importations. Les utilisations finales, ou utilisateurs finaux, pour des armes nucléaires, des missiles, des armes chimiques ou biologiques ou pour le nucléaire maritime, directement ou indirectement, sont strictement interdites. Les exportations ou réexportations vers des pays sous embargo des Etats-Unis, ou vers des entités figurant sur les listes d'exclusion d'exportation américaines, y compris, mais de manière non exclusive, la liste de personnes qui font objet d'un ordre de ne pas participer, d'une façon directe ou indirecte, aux exportations des produits ou des services qui sont régis par la legislation américaine en matière de contrôle des exportations et la liste de ressortissants spécifiquement designés, sont rigoureusement interdites. LADOCUMENTATIONEST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES EXPRESSESOUTACITES SONT FORMELLEMENT EXCLUES,DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRISNOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LAQUALITEMARCHANDE, A L'APTITUDE A UNE UTILISATIONPARTICULIEREOUA L'ABSENCEDE CONTREFACON.


ii


iii

Daftar Isi Daftar Isi .....................................iii Apa itu Proyek OpenSolaris? ......................1 Portal Regional..................................3 Situs-Situs OpenSolaris..........................4 Diskusi........................................5 Komunitas......................................6 Proyek.........................................8 Repositori Kode Pemograman.....................9 OpenGrok......................................10 Advokasi OpenSolaris.............................11 Mengapa Menggunakan OpenSolaris?................12 Harga.........................................13 Fitur-fitur Inti Yang Inovatif................14 Kompatibilitas Balik..........................15 Netralitas Platform Perangkat Keras...........16 Piranti Pengembangan..........................17 Pernyatan Tanda Terima Kasih....................19 Mempersiapkan Lingkungan Kerja

OpenSolaris......20

Konfigurasi Perangkat Keras dan Perangkat Lunak.22 Jaringan........................................26 Daemon Auto-Configuration Jaringan..............27 Tinjauan Umum Zona..............................28 Administrasi Zona...............................29 Memulai Administrasi Zona.....................31 Virtualisasi Server Web dengan Zona.............35 Pembuatan Zona Non-Global.....................36 Pembuatan Pool Penyimpan Data dan Sistem File ZFS ................................................41 Membuat Pool Penyimpan Data ZFS Ter-mirror......42 Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

iii

Membuat Sistem File ZFS Sebagai Direktori Kerja Pengguna........................................44 Membuat Konfigurasi RAID-Z .....................48 Konsolidasi Area Pengguna........................50 Konsolisidasi Area Pengguna dan Deskripsinya....51 Fitur Inti Sistem Operasi Solaris ...............53 Proses Pengembangan dan Metode Penulisan Kode...54 Tinjauan .......................................60 FireEngine......................................61 Sinkronisasi .................................62 TCP, IP, dan UDP..............................63 GLDv3.........................................64 Virtualisasi..................................65 Least Privilege (Hak Istimewa Terbatas).........66 Filtrasi Paket..................................67 Filter IP.....................................68 Mengaktifkan Filtrasi Paket Sederhana.........69 Beberapa Contoh Kaidah Filtrasi Paket.........70 Zona (Zones)....................................73 Zona Bertanda-identitas (Branded Zones - BrandZ) ................................................76 Jaringan Didalam Zona...........................79 Identitas Zona, Akses terhadap CPU dan Instalasi Paket.........................................81 Perangkat Didalam Zones.......................82 Prakiraan Penyembuhan-Diri (Predictive SelfHealing)........................................83 Arsitektur Manajemen Kegagalan (Fault Management Architecture - FMA)...........................84 Fasilitas Manajemen Layanan (Services Management Facility - SMF)...............................86 Perunut Dinamis (Dynamic Tracing - DTrace)......87 Pen-debug Modular (Modular Debugger - MDB)......88 Sistem File ZFS.................................89 Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

iv

Penggunaan Checksum dan Perbaikan Data........90 RAID-Z........................................91 Konsep Pemograman................................92 Manajemen Proses dan Sistem.....................93 Pemograman Thread...............................96 Sinkronisasi..................................99 Penjadwalan CPU................................101 Tinjauan Umum Kernel...........................105 Perbedaan Antara Eksekusi Modul Kernel dan Program Pengguna.............................106 Perbedaan Struktural antara Modul Kernel Modules dan Program Pengguna.........................108 Men-debug Proses...............................110 Memulai Penggunaan DTrace.......................112 Mengaktifkan Probe DTrace Sederhana............113 Menampilkan Probe Perunut......................116 Pemograman Bahasa D............................120 Men-debug Aplikasi dengan DTrace................124 Mengaktifkan Probe Didalam Moda Pengguna.......125 Merunut Aplikasi Dengan DTrace.................126 Men-debug Aplikasi C++ dengan DTrace............131 Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++ .....................132 Manajemen Memori dengan DTrace dan MDB..........147 Perangkat lunak Untuk Manajemen Memori.........148 Pengujian Memori Virtual dengan DTrace dan MDB.149 Men-debug Program Penggerak Perangkat Dengan DTrace ................................................173 Memindahkan Program Penggerak smbfs Dari Linux Ke Solaris OS.....................................174 Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

v

Sumber Bacaan Tambahan OpenSolaris..............186


vi

1 M

O

D

U

L

Apa itu Proyek OpenSolaris? Tujuan Tujuan umum dari pelatihan ini adalah agar peserta memperoleh pengetahuan tentang Sistem Operasi sebagai bagian dari sistem komputasi dengan memanfaatkan kode pemograman Sistem Operasi Solaris yang secara bebas bisa diperoleh melalui proyek OpenSolaris. Tip - Lakukan pendaftaran di Internet melalui situs http://get.opensolaris.org, agar secara gratis dapat menerima OpenSolaris Starter Kit yang terdiri dari materi-materi pelatihan, kode pemograman dan piranti untuk pengembangan. Di bagian awal peserta diperkenalkan bagaimana mengakses kelompok pengguna (user group), situssitus dan dokumentasi yang berhubungan dengan OpenSolaris sehingga peserta dapat segera mengenal komputasi berbasis UNIX. Berikutnya disajikan dimana peserta bisa mengakses lebih jauh informasi-informasi lain yang berhubungan dengan Proyek OpenSolaris seperti kode pemograman (source code), komunitas, proyek-proyek yang sedang berjalan dan penjelajah kode pemograman (source browser). Langkah selanjutnya, peserta diperlihatkan bagaimana mengkonfigurasi zonas, ZFS, jaringan dan beberapa fitur lain. Di bagian akhir, terdapat latihan-latihan bagi peserta untuk dapat Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

1

mempelajari bagaimana menggunakan DTrace untuk mendebug proses, aplikasi, kegagalan halaman memori (page faults), dan program penggerak perangkat (drivers).


2

Apa itu Proyek OpenSolaris?

Proyek OpenSolaris diluncurkan pada tanggal 14 Juni 2005 untuk menghasilkan sebuah upaya membangun komunitas dengan menggunakan kode pemograman Solaris sebagai langkah awalnya. Proyek ini merupakan sebuah tempat dimana upaya pengembangan komunitas saling terkait, tempat dimana para kontributor dari Sun dan siapa pun dapat berkolaborasi demi perkembangan dan kemajuan teknologi Sistem Operasi. Ketersediaan kode pemograman OpenSolaris dapat dimanfaatkan untuk banyak hal antara lain sebagai dasar untuk versi mendatang produk Sistem Operasi Solaris, proyek-proyek Sistem Operasi lainnya, produk pabrikan pihak-ketiga dan distribusidistribusi aplikasi yang diminati oleh komunitas. Hingga saat ini, Sun Microsystems, Inc. yang mensponsori proyek ini. Hingga 2 tahun pertama, lebih dari 60.000 peserta telah terdaftar sebagai anggota. Komunitas para rekayasawan ini terus bertumbuh dan berubah untuk memenuhi kebutuhan para pengembang perangkat lunak, sistem administrator dan pengguna Sistem Operasi Solaris. Pembelajaran Sistem Operasi dengan proyek OpenSolaris memiliki banyak keuntungan dibandingkan pembelajaran instruksional:  Mendapatkan akses ke kode pemograman dari Sistem Operasi Solaris 10 yang revolusioner.  Mendapatkan akses ke kode pemograman dari Sistem Operasi komersial yang digunakan secara luas di banyak lingkungan bisnis kecil dan besar.  Keunggulan perangkat lunak untuk melakukan observasi dan debug.  Dukungan perangkat keras yang meliputi arsitektur SPARC, x86 dan x64.  Kepemimpinan Solaris di lingkungan komputasi 64Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

1

Apa itu Proyek OpenSolaris?

bit.  Pemanfaatan perangkat lunak tak terbatas secara gratis.  Kode pemograman yang menantang, inovatif, lengkap, konsisten, tangguh dan bisa diperoleh secara bebas.  Adanya CommonDevelopment and Distribution License (CDDL), sebuah aturan lisensi yang disetujui oleh OSI, yang membolehkan pemanfaatan yang bebas royaliti, modifikasi dan kegiatan ikutan lainnya


2

Portal Regional

Portal Regional Komunitas Internationalization and Localization sebagian bagian dari Proyek OpenSolaris adalah komunitas yang bertugas membantu untuk menerjemahkan situs OpenSolaris yang berbahasa Inggris kedalam bahasa-bahasa yang lain. Sejauh ini, terdapat 8 portal dengan bahasa pengantar lokal yang masih terus dikembangkan:  Portal India – http://in.opensolaris.org  Portal

Cina – http://cn.opensolaris.org

 Portal

Jepang – http://jp.opensolaris.org

 Portal

Polandia – http://pl.opensolaris.org

 Portal

Perancis – http://fr.opensolaris.org

 Portal Brasil – http://opensolaris.org/os/project/br  Portal Spanyol – http://opensolaris.org/os/project/es Portal berbahasa pengantar Jerman, Rusia, Repulik Czech, Spanyol, Korea dan Meksiko masih dalam status perencanaan. Kunjungi portal OpenSolaris untuk bisa ikut berpartisipasi, atau chat di salah satu dari tujuh fasiltas chat OpenSolaris dengan menggunakan IRC di irc.freenode.net. Kunjungi http://opensolaris.org/os/chat/untuk informasi lebih lanjut.


3

Situs-situs OpenSolaris

Situs-Situs OpenSolaris Untuk mendownload kode pemograman OpenSolaris, membaca lisensi dan mengakses petunjuk bagaimana mengkonstruksi kode pemograman (building source) dan menginstal salinan file-file biner prakonstruksi yang terkompresi (arsip prakonstruksi/pre-built archive) kunjungi situs: http://www.opensolaris.org/os/downloads. Ikon-ikon di kanan-atas halaman situs OpenSolaris menyediakan akses ke halaman diskusi, komunitas, proyek, download, dan penjelajah kode pemograman. Selain itu, situs OpenSolaris juga tersedia fasilitas pencarian isi situs dan kumpulan blog.


4


Diskusi Halaman Diskusi menyediakan akses untuk berkomunikasi dengan para ahli yang berkecimpung dengan teknlogi kode pemograman terbuka (open source). Halaman Diskusi juga menyediakan pencarian arsip dari diskusi-diskusi yang pernah dilakukan sebelumnya untuk topik tertentu. Kunjungi http://www.opensolaris.org/os/discussions untuk mendapatkan daftar lengkap forum yang akan dipilih untuk berlangganan.


5


Komunitas Halaman komunitas merupakan tempat dimana pengunjung dengan minat tertentu yang sama terhadap proyek OpenSolaris bisa saling terhubung. Halaman komunitas merupakan gabungan dari kelompok peminat teknologi, dukungan, piranti, and kelompok pengguna:  Lembaga Akademik dan Penelitian: http://www.opensolaris.org/os/community/edu  DTrace: www.opensolaris.org/os/community/dtrace

http://

 ZFS: http://www.opensolaris.org/os/community/zfs  Jaringan: http://www.opensolaris.org/os/community/networkin g  Zona: http://www.opensolaris.org/os/community/zones  Dokumentasi: http://www.opensolaris.org/os/community/documenta tion  Penggerak Perangkat: http://www.opensolaris.org/ os/community/device_drivers


6


 Piranti: http://www.opensolaris.org/os/community/tools  Advokasi: http://www.opensolaris.org/os/community/advocacy  Keamanan: http://www.opensolaris.org/os/community/security  Kinerja: http://www.opensolaris.org/os/community/performan ce  Penyimpan Data: http://www.opensolaris.org/os/community/storage  Administrasi Sistem: http://www.opensolaris.org/os/community/sysadmin Terdapat sekitas 30 komunitas yang berjalan secara aktif di OpenSolaris. Kunjungi http://www.opensolaris.org/os/communities untuk informasi lengkap.


7


Proyek Proyek-proyek yang ada di situs http://www.opensolaris.org/ merupakan upaya kerjasama yang menghasilkan obyek seperti perubahan kode pemograman, dokumen, grafik atau produk gabungan berapa pengembang perangkat lunak. Proyek memiliki repositori dan komisi yang menguji dan menyetujui kode pemograman. Proyek bisa berasal dari komunitas atau berdiri sendiri di luar komunitas. Proyek baru diajukan oleh para peminatnya dengan mengajukan permintaan melalui fasilitas diskusi. Proyek yang diajukan dan diterima oleh setidaknya satu peminat lain di dalam komunitas yang mensposorinya akan disediakan ruang untuk halaman proyek sehingga proyek dapat dimulai. Kunjungi http://www.opensolaris.org/os/projects untuk melihat daftar proyek-proyek yang sedang berjalan.  Piranti Visualisasi Harmonik untuk DTrace : http://www.opensolaris.org/ os/project/dtracechime  Kode Google Summer: http://www.opensolaris.org/os/project/powerPC  Indiana: http://www.opensolaris.org/os/project/indiana  OpenGrok: http://www.opensolaris.org/ os/project/opengrok  Kontes Pemograman: http://www.opensolaris.org/os/project/contest  Starter Kit: http://www.opensolaris.org/ os/project/starterkit  Solaris iSCSI Target: http://www.opensolaris.org/ os/project/iscsitgt


8


Repositori Kode Pemograman Repositori kode pemograman yang terpusat dan terdistribusi tersedia di situs opensolaris.org. Model manajemen kode pemograman terpusat ini menggunakan program manajemen yang disebut Subversion (SVN) source control. Sedangkan manajemen repositori terdistribusi menggunakan program manajemen yang disebut kontrol kode pemograman Mercurial (hg). Pembuatan repositori kode pemograman di opensolaris.org dilakukan oleh Pemimpin Proyek di halaman proyek yang bersangkutan. Pengembang dengan hak commit bisa mengakses repositori dengan menggunakan akun yang terdaftar di opensolaris.org. Hak commit sendiri diatur oleh Pemimpin Proyek. Untuk mengakses repositori dengan hak commit selain memiliki akun juga diperlukan kunci publik Secure Shell (SSH). Akun bisa diperoleh setelah melakukan pendaftaran terlebih dahulu. Kunjungi halaman komunitas piranti di http://opensolaris.org/os/community/tools untuk mendapat informasi terbaru tentang kontrol terhadap kode pemograman, download dan petunjuk-petunjuk lainya.


9


OpenGrok OpenGrokTM adalah mesin pencari kode pemograman dan referensi silang yang cepat dan praktis yang digunakan oleh OpenSolaris. Kunjungi http://cvs.opensolaris.org/sourceuntuk mencobanya. OpenGrok adalah proyek yang pertama kali ada di opensolaris.org. Kunjungi http://www.opensolaris.org/os/project/opengrok untuk mengetahui perkembangan lanjutan proyek ini. Coba gunakan perangkat lunak ini dan temukan begitu rapinya kode pemograman tertulis, penuh dengan deskripsi seolah seperti membaca sebuah buku. Jika tertarik berpartisipasi mengembangkan proyek OpenSolaris, silakan mendownload kode pemograman lengkapnya. Jika hanya sekedar ingin mengetahui cara kerja fitur tertentu Solaris, piranti alternatif lebih nyaman digunakan adalah penjelajah kode pemograman. OpenGrok memahami berbagai format file program dan version control history seperti SCCS, RCS, and CVS sehingga memudahkan pemahaman terhadap prinsipprinsip kode pemograman terbuka.


10

2 M

O

D

U

L

Advokasi OpenSolaris Tujuan Keberadaan Komunitas Advokat bertujuan untuk membantu berbagai kalangan dari penjuru dunia untuk ikut berpartisipasi dalam Komunitas OpenSolaris. Komunitas ini terbuka bagi semua orang dari semua bahasa dan kebudayaan dan mereka dengan latar belakang teknis ataupun tidak. Setiap orang memiliki sesuatu untuk ikut berkontribusi. Kunjungi http://opensolaris.org/os/community/advocacy/ Di dalam komunitas Advokat bisa ditemui proyekproyek dari kelompok pengguna yang berdiri sendiri, presentasi, berita, artikel, blog, halaman yang berisi informasi teknis & non-teknis, video dan podcast, seminar dan konferensi. Tersedia juga berbagai proyek untuk keperluan promosi seperti atribut komunitas, pernak-pernik, lencana, pin dan lain-lain.


11

Mengapa Menggunakan OpenSolaris?

Mengapa Menggunakan OpenSolaris? Bagian ini menjelaskan alasan-alasan praktis yang menjadi pertimbangan pemilihan OpenSolaris sebagai platform pengembangan perangkat lunak.


12


Harga Popularitas Sistem Operasi Solaris 10 meledak sejak ketersediaannya di bulan Januari 2005. Hingga Juli 2007, sudah terdaftar lebih dari 8.7 juta salinan, ini jauh lebih besar dibandingkan gabungan versiversi Solaris sebelumnya. Kondisi ini makin terpicu dengan diluncurkannya OpenSolaris pada bulan Juni 2005. Lonjakan luar biasa jumlah pengguna Solaris ini, membuat semakin banyak pengembang perangkat lunak (komersial atau kode pemograman terbuka) melirik Sistem Operasi Solaris sebagai sasaran yang berkelanjutan bagi perangkat lunak mereka. Salah satu alasan Sistem Operasi Solaris mengalami percepatan popularitas yang luar biasa adalah karena harganya: $ 0 untuk setiap orang, pemanfaatan apa pun (komersial atau non-komersial), di semua platform (SPARC atau x86). Alasan lain adalah jaminan Sun (dan Sun melaksanakan jaminan ini) untuk membuat kode pemograman OpenSolaris tersedia bagi publik dibawah lisensi CommonDevelopment and Distribution License (CDDL). CDDL sendiri adalah sebuah pengaturan lisensi kode pemograman terbuka yang telah mendapat persetujuan OSI.


13


Fitur-fitur Inti Yang Inovatif Sebenarnya, alasan terpenting bagi naik popularitas Solaris adalah kekayaan tak terbatas dari fiturfitur yang ditawarkannya. Fitur-fitur tersebut adalah:  Zona Solaris – Menawarkan kemampuan untuk mempartisi sebuah komputer menjadi beberapa sistem komputasi virtual, yang masing-masing saling terisolasi.  DTrace – Sebuah perangkat perunut (tracing) yang dinamis dan komprehensif untuk menginvestigasi perilaku system dan aman untuk digunakan lingkungan produksi  Tumpukan IP (IP stacks) Baru – Menyediakan peningkatan kinerja yang luar biasa  ZFS – Sebuah pencapaian tertinggi bagi sistem file 128 bit, dengan deteksi dan koreksi kesalahan end-to-end, antar muka perintah-baris yang sederhana dan secara virtual kapasitas penyimpan yang tidak terbatas.


14


Kompatibilitas Balik Semua fitur-fitur baru ini di kembangkan di atas platform yang telah lama dinantikan oleh para pengguna Sistem Operasi Solaris dengan karakteristik: stabilitas yang tangguh, skalabilitas yang besar, kinerja tinggi, dan jaminan kompatibilitas balik. Kompatibilitas balik merupakan hal penting terutama bagi pengembang perangkat lunak komersial karena menjaga kontinuitas perangkat lunak memerlukan biaya tinggi. Dengan jaminan kompatibilitas balik, pabrikan perangkat lunak mengetahui bahwa perangkat lunak (dengan menggunakan API yang dirilis) yang dibuat untuk Solaris ke-N akan berjalan mulus di Solaris ke-N+1 dan versi-versi berikutnya. Berbeda dengan beberapa Sistem Operasi lain, dimana perubahan-perubahan yang tidak kompatibel pada komponen sistem – misalnya, libraries – dibuat tanpa mempertimbankan efek samping pada applikasi. Efek keseluruhan adalah kerusakan aplikasi yang menyebabkan tinggi biaya untuk menjaga kontinuitas perangkat lunak dan rasa frustasi bagi pabrikan dan pengguna.


15


Netralitas Platform Perangkat Keras Paragraf sebelumnya menjelaskan beberapa alasan mengapa kita seharusnya mengembangkan Sistem Operasi Solaris, tetapi masih ada alasan-alasan lain untuk melakukan pengembangkan platform Solaris. Salah satunya adalah bahwa Solaris adalah Sistem Operasi multi-platform, mendukung baik arsitektur SPARC dan x86 (sebuah port ke Power yang dimotori oleh sebuah komunitas masih berjalan). Meskipun dulu beberapa tahun yang lalu muncul keraguan berkaitan Solaris untuk platform x86, pada kenyataanya sekarang Sun telah memperkenalkan jajaran server dan workstation berbasis AMD yang membuktikan kesungguhan Sun terhadap teknologi x86. Dari sudut pandang para pengembang perangkat lunak, versi Solaris untuk platform SPARC dan x85 memilki himpunan fitur dan API yang sama. Ini artinya para pengembang dapat lebih berkonsentrai dengan isu-isu lain untuk memperluas pengembangan antar-platform, seperti CPU endianness. Platform SPARC adalah big-endian dan x86 adalah little-endian sehingga sebuah aplikasi yang dikembangkan dan ditest diatas platform Solaris memiliki kemungkinan besar untuk terbebas masalah yang berhubungan endian. Solaris juga mendukung aplikasi 32 bit dan 64 bits di kedua platform tersebut, sehingga membantui menghilangkan bugs akibat asumsi-asumsi sekitar ukuran word. Mungkin alasan yang paling tak terbantahkan untuk mengembangkan perangkat lunak di Solaris adalah tersedianya piranti pengembangan perangkat lunak yang profesional.


16


Piranti Pengembangan Salah satu fitur terpenting sebuah Sistem Operasi dari sudut pandang pengembang perangkat lunak adalah tersedianya piranti pengembang perangkat lunak yang beragam dan berkualitas. Pengkompilasi/Compiler dan pen-debug/debugger adalah contoh yang paling lazim dari piranti seperti ini, selain pengetest kode pemograman/code checkers (untuk memastikan kode pemograman terbebas dari kesalahan yang tidak bisa ditemukan oleh compiler), pembangkit referensi-silang/crossreference generators (untuk melihat fungsi mana yang mereferesensi ke fungsi lain atau), dan penganalisa kinerja/performance analyzers. Sun Studio telah menjadi produk plihan bagi pengembang Solaris. Tersedia untuk diunduh secara gratis dari situs http://developers.sun.com, perangkat lunak Sun Studio adalah gabungan dari pengkompilasi dan piranti lain yang berkualitas profesional. Lengkapnya terdiri dari pengkompilasi C, C++, and FORTRAN; piranti penganalisa kode pemograman; sebuah antar muka lingkungan pengembangan terintegrasi (integrated development environment, IDE); dbx sebuah pen-debug di tingkat kode pemograman; dan program pengolah teks (editors). Piranti lain yang tergabung dalam Sun Studio adalah cscope (penjelajah kode pemograman interaktif), ctrace (piranti untuk membangkitkan self-tracing version dari sebuah program), cxref (program pembangkit referensi-silang C), dmake (program bantu untuk mengkonstruksi kode pemograman secara paralel dan terdistribusi), and lint (pemeriksa program C). Solaris dilengkapi dengan pengkompilasi GNU C , gcc, and pelengkap berupa pen-debug di tingkat kode pemograman, gdb. Solaris juga dilengkapi dengan penPengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

17


debug modular yang sangat berguna, mdb. Namun, mdb bukan pen-debug di tingkat kode pemograman. Piranti ini sangat berguna untuk men-debug kode kernel, atau melakukan analisa gejala tertentu yang mengikuti sebuah peristiwa pada sebuah program yang biasanya tidak tersedia pada level kode pemograman. Informasi lebih lengkap tentang mdb tersedia di buku Solaris Modular Debugger Guide and Solaris Performance and Tools yang ditulis oleh McDougall, Mauro dan Gregg.


18

Pernyataan Tanda Terima Kasih

Pernyatan Tanda Terima Kasih Anggota-anggota Komunitas OpenSolaris berikut ini telah mengevaluasi dan memberikan saran perbaikan untuk dokumen ini:  Boyd Adamson  PradhapDevarajan  Alan Coopersmith  Brian Gupta  RainerHeilke  Eric Lowe  Ben Rockwood  Cindy Swearingen Anggota-anggota Komunitas OpenSolaris berikut ini telah menyumbangkan materi baru yang luar biasa:  Dong-HaiHan  Narayana Janga  Shivani Khosa  Rich Teer  Sunay Tripathi  Yifan Xu Ucapan terima kasih juga kepada Steven Cogorno, David Comay, Teresa Giacomini, StephenHahn, Patrick Finch, and Sue Weber atas kerja kerasnya yang memungkinkan lahirnya versi awal dokumen ini. Untuk berpartisipasi melakukan evaluasi mendatang terhadap dokumen ini, lakukan instruksi-instruksi seperti terdapat di situs: http://www.opensolaris.org/os/community/documentati on/reviews Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

19

3 M

O

D

U

L

Mempersiapkan Lingkungan Kerja OpenSolaris Tujuan Tujuan dari modul ini adalah agar peserta memahami kebutuah sistem, informasi pendukung, dokumentasi yang tersedia ketika melakukan instalasi dan konfigurasi proyek OpenSolaris.

Sumber Bacaan Lain  Solaris Express Developer Edition Installation Guide: Laptop Installations. Sun Microsystems, Inc., 2007.  Sumber Bacaan untuk menjalankan Solaris OS di laptop: http://www.sun.com/bigadmin/features/articles/lap top_resources.html  Komunitas Laptop OpenSolaris: http://opensolaris.org/os/community/laptop  OpenSolaris Starter Kit: http://opensolaris.org/os/project/starterkit  System Administration Guide: IP Services, SunMicrosystems, Inc., 2007  Komunitas Jaringan OpenSolaris: http://www.opensolaris.org/os/community/networkin g Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

20

 Administrasi ZFS dan halaman manual: http://opensolaris.org/os/community/zfs/docs


21

Konfigurasi Perangkat Keras dan Perangkat Lunak

Konfigurasi Perangkat Keras dan Perangkat Lunak Mendapatkan pengalaman praktis secara langsung untuk mempelajari kode pemograman Sistem Operasi dan akses langsung modul-modul kernel merupakan hal yang tidak tergantikan. Bagaimana memenuhi tantangan unik pengembangan kernel dan mendapatkan hak akses root ke sebuah sistem telah dibuat lebih mudah oleh piranti, forum dan dokumentasi yang disediakan oleh proyek OpenSolaris. Tip - Lakukan pendaftaran di Internet melalui situs http://get.opensolaris.org, agar secara gratis dapat menerima OpenSolaris Starter Kit yang terdiri dari materi-materi pelatihan, kode pemograman dan piranti untuk pengembangan. Pertimbangkan fitur-fitur OpenSolaris berikut ini ketika mempersiapkan perangkat keras dan perangkat lunak: Tabel 3-1 Konfigurasi Pendukung Komponen Lab Komponen Perangkat Keras

Dukungan Dari Proyek OpenSolaris OpenSolaris mendukung sistem dengan jajaran prosesor berarstitektur SPARC dan x86: UltraSPARC®, SPARC64, AMD64, Pentium, and Xeon EM64T. Daftar sistem yang didukung, bisa didapatkan pada Solaris OS Hardware Compatibility List di http://www.sun.com/bigadmin/hcl File Kode Kunjungi Pemograman http://opensolaris.org/os/downloads untuk instruksi lengkap bagaiman mengkonstruksi kode pemograman Instalasi Distibusi Pre-built OpenSolaris hanya Sistem dapat digunakan di Solaris Express: Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

22


Operasi

Community Edition [DVD Version], Build 32 atau lebih, Solaris Express: Developer Edition, Nexenta, Schillix, Martux and Belenix. Untuk kernel OpenSolaris kernel dengan lingkungan pengguna GNU, tersedia di http://www.gnusolaris.org/gswiki/Downloadform Tabel 3-1 Konfigurasi Pendukung Komponen Lab (Lanjutan) Komponen BFU archives Build tools Compilers and tools

Kebutuhan Memori/Disk

Dukungan Dari Proyek OpenSolaris File on-bfu-DATE.PLATFORM.tar.bz2 tersedia jika ingin men dari arsip pra-konstruksi. File SUNWonbld-DATE.PLATFORM.tar.bz2 tersedia jika akan mengkonstruksi dari kode pemograman sumbernya. Pengkompilasi dan piranti lain Sun Studio 11 terse digunakan secara bebas oleh pengembang OpenSolaris http://www.opensolaris.org/os/community/tools/sun_ untuk instruksi bagaimana mengunduh dan menginstal terbarunya. Untuk komunitas gcc, kunjungi http://www.opensolaris.org/os/community/tools/gcc  Kebutuhan Memori: 256M minimum (mode teks instal  1GB direkomendasikan  Kebutuhan Memory : 768M minimum untuk instalasi Express Developer Edition  Kebutuhan ruang Disk: 350M bytes

Lingkungan OS Virtual

Zona and Zona Bertanda-identitas di OpenSolaris me lingkungan Sistem Operasi yang virtual dan terlind sebuah instan Solaris. Ini memungkinkan satu atau berjalan secara terisolasi dari aktifitas proses y system.

Open Solaris mendukung XEN, sebuah pemonitor syste virtual dari komunitas kode pemograman terbuka yan dikembangkan oleh tim XEN dari Laboratorium Komput Universitas Cambridge. Kunjungi http://www.opensolaris.org/os/community/xen/ untuk informasi lebih lanjut tentang proyek XEN. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

23


OpenSolaris juga dapat diinstall dalam lingkungan kunjungi http://www.opensolaris.org/os/project/con mendapat artikel terbaru bagaimana melakukannya.


24


Lihat di Modul 4 untuk informasi lebih lanjut bagaimana Zona and Zona Bertanda-identitas memungkinkan pengembangan Solaris kernel atau user mode dan aplikasi Linux dapat dilakukan tanpa mempengaruhi pengembang yang bekerja di zona yang terpisah. Dengan berpartisipasi menggunakan proyek OpenSolaris akan memperbaiki kinerja keseluruhan sistem dan jaringan dengan teknologi terbaru. Lingkungan lab menjadi lebih menguntungkan dengan menggunakan OpenSolaris karena sistem selalu berada di lingkungan komputasi termutakhir dan luar biasa.


25


Jaringan Proyek OpenSolaris memenuhi tantangan masa depan teknologi jaringan dengan secara radikal memperbaiki performa jaringan tanpa memerlukan perubahan-perubahan terhadap aplikasi yang sudah ada.  Kenaikan kinerja aplikasi hingga 50% dengan melakukan perbaikan lapisan TCP/IP  Dukungan terhadap banyak teknologi jaringan mutakhir, seperti 10 Gigabit Ethernet, jaringan nir-kabel dan hardware offloading  Mengakomodasi fitur jaringan seperti highavailability, streaming, and Voice over IP (VoIP) melalui dukungan extended routing dan protocol.  Dukungan terhadap spesifikasi IPv6 terbaru. Informasi lebih lanjut tentang pengembangan teknologi jaringan di komunitas OpenSolaris dapat dilihat di: http://www.opensolaris.org/os/community/networking.


26

Daemon Auto-Configuration Jaringan

Daemon Auto-Configuration Jaringan Proses boot pada rilis Solaris Express Developer Edition 5/07 menjalankan sebuah daemon baru, disebut nwamd. Daemon ini merupakan instan alternatif dari layanan SMF, svc:/network/physical, yang memungkinkan pengkonfigurasian jaringan secara otomatis dengan intervensi minimal. Daemon nwamd memonitor port Ethernet dan secara otomatis mengkonfigurasi kartu jaringan dengan DHCP. Jika kabel Ethernet tidak terpasang ke jaringan kabel, daemon nwamd melakukan pemindaian jaringan nirkabel dan mengirimkan permintaan untuk terhubung dengan titik akses WiFi. Tidak perlu lagi membuang banyak waktu untuk mengkonfigurasi kartu jaringan Ethernet secara manual. Konfigurasi otomatis juga sangat mempermudah administrasi karena pengkonfigurasianulang alamat-alamat jaringan bisa dilakukan dengan intervensi minimal. Untuk melihat status NWAM, ketikan perintah berikut di jendela terminal. # svcs nwam STATE STIME FMRI online 11:29:50 svc:/network/physical:nwam

Di halaman Network Auto-Magic Phase 0 pada situs OpenSolaris dan manual nwamd terdapat keterangan lebih rinci, termasuk bagaimana mematikan mematikan nwamd. Untuk informasi lebih jauh dan link ke halaman manual nwamd(1M), kunjungi http://www.opensolaris.org/os/project/nwam.


27

Tinjauan Umum Zone

Tinjauan Umum Zona Zona dapat dibayangkan seperti sebuah wadah dimana didalamnya satu atau lebih aplikasi berjalan secara terisolasi dari semua aplikasi yang ada di sistem. Semua perangkat lunak yang berjalan di OpenSolaris bisa berjalan, tanpa dimodifikasi, didalam zona. Karena zona tidak tidak mengubah OpenSolaris Application Programming Interface (APIs) or Application Binary Interface (ABI) maka aplikasi tidak perlu dikompilasi ulang agar bisa berjalan didalam zona.


28

Administrasi Zone

Administrasi Zona Administrasi zona terdiri dari perintah-perintah berikut:  zonecfg – Membuat zona, mengkonfigurasi zona (menambah sumber daya dan properti), menyimpan konfigurasi zona didalam per-zona file XML yang ada di /etc/zones.  zoneadm – Melakukan langkah-langkah administratif untuk zona seperti: menampilkan, menginstal, (re)boot dan halt.  zlogin – Memungkinkan pengguna log in kedalam zona untuk melakukan tugas-tugas administrasi.  zonename – Menampilkan nama zona dimana user berada. Berikut adalah properti-properti dengan lingkup global yang digunakan dengan didalam konfigurasi zona:  zonepath – Lokasi direktori didalam zona global yang menjadi direktori root dimana zona akan diinstall  autoboot – Menentukan apakah sebuah zona ikut boot atau tidak ketika zona global boot  pool – Menentukan pool sumber daya yang diberikan untuk sebuah zona Sumber Daya dapat digolongkan sebagai berikut:  fs – sistem file  Inherit-pkg-dir – Direktori-direktori didalam zona yang memiliki keterterkaitan dengan paket yang berasal dari zona global Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

29

Administrasi Zone

 net – Perangkat jaringan  device – Perangkat-perangkat 


30

Memulai Administrasi Zone

Memulai Administrasi Zona Pada latihan lab berikut diperkenalkan proses pembuatan zona.

Ringkasan Latihan berikut, menggunakan contoh-contoh yang rinci sehingga diharapkan mempercepat pemahaman proses pembuatan, instalasi dan boot zona. Catatan – Prosedur berikut tidak dapat digunakan untuk zona dengan atribut lx (BrandZ)


31


Membuat, Menginstal dan Boot Zona 1.Gunakan perintah berikut ini untuk mengkonfigurasikan sebuah zona baru: Catatan – Contoh di bawah ini menggunakan tumpukan IP-berbagi, ini adalah standar untuk sebuah zona. # zonecfg -z Apache Apache: No such zone configured Use ’create’ to begin configuring a new zone. zonecfg:Apache> create zonecfg:Apache> set zonepath=/export/home/Apache zonecfg:Apache> add net zonecfg:Apache:net> set address=192.168.0.50 zonecfg:Apache:net> set physical=bge0 zonecfg:Apache:net> end zonecfg:Apache> verify zonecfg:Apache> commit zonecfg:Apache> exit

2.Gunakan perintah berikut ini untuk menginstall dan boot zona yang telah terkonfigurasikan: # zoneadm -z Apache install Preparing to install zone <Apache>. Creating list of files to copy from the global zone. Copying <6029> files to the zone. Initializing zone product registry. Determining zone package initialization order. Preparing to initialize <1038> packages on the zone. Initialized <1038> packages on zone. Zone <Apache> is initialized. Installation of these packages generated warnings: .... The file contains a log of the zone installation. The necessary directories are created. The zone is ready for booting.


32


3.Lihat isi root direktori-nya: # ls /export/home/Apache/root bin etc home mnt platform tmp var dev export lib proc system usr

sbin opt

Paket-paket berikut tidak diinstall-ulang. # /etc/mount /export/home/Apache/root/lib on /lib read only /export/home/Apache/root/platform on /platform read only /export/home/Apache/root/sbin on /sbin read only /export/home/Apache/root/usr on /usr read only /export/home/Apache/root/proc on proc read/write/setuid/nodevices/zone=Apache

4.Boot zona-nya. # ifconfig -a lo0: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge0: flags=1004803 mtu 1500 index 2 inet 192.168.0.4 netmask ffffff00 broadcast 192.168.0.255 ether 0:c0:9f:61:88:c9 # zoneadm -z Apache boot # ifconfig -a lo0: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 lo0:1: flags=2001000849 mtu 8232 index 1 zone Apache inet 127.0.0.1 bge0: flags=1004803 inet 192.168.0.4 netmask ffffff00 broadcast 192.168.0.255 ether 0:c0:9f:61:88:c9 bge0:1: flags=1000803mtu 1500 index 2 zone Apache inet 192.168.0.50 netmask ffffff00 broadcast 192.168.0.255


33


5.Buat konfigurasi zona dan login: # zlogin -C Apache [Connected to zone ’Apache’ pts/5] # ifconfig -a lo0:2: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge0:2: flags=1000803 inet 192.168.0.50 netmask ffffff00 broadcast 192.168.0.255 # ping -s 192.168.0.50 64 bytes from 192.168.0.50: icmp_seq=0. time=0.146 ms # exit [Connection to zone ’Apache’ pts/5 closed]


34

Virtualisasi Server Web dengan Zone

Virtualisasi Server Web dengan Zona Setiap zona memiliki karakteristik tersendiri, contohnya, nama zona, alamat IP, nama komputer, naming services, akun root dan non-root. Sesuai standarnya, Sistem Operasi berjalan didalam zona global. Administrator dapat memvirtualisasikan lingkungan eksekusi aplikasi dengan mendifinisikan satu satu lebih zona non-global. Layanan-layanan jaringan dapat dijalankan untuk membatasi kerusakan yang terjadi akibat kejadian serangan keamanan. Karena zona diimplementasikan di dalam perangkat lunak, zona tidak dibatasi granularitasnya berdasarkan batasan-batasan yang didefinisikan oleh perangkat keras. Tetapi sebaliknya zona menawarkan granularitas sub-CPU.


35

Pembuatan Zone Non-Global

Pembuatan Zona Non-Global Latihan lab berikut ini mendemostrasikan bagaimana membuat dua kelompok pengguna server web yang berbeda dalam satu sistem komputer.

Ringkasan Akses secara bersamaan ke kedua server web tersebut dikonfigurasikan sedemikan rupa sehingga masingmasing server web dan sistem akan terlindungi meskipun salah satunya telah mendapat serangan keamanan.


36


Membuat Dua Zona NonGlobal 1.Membuat zona non-global Apache1: # zonecfg -z Apache1 info zonepath: /export/home/Apache1 autoboot: false pool: inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr net: address: 192.168.0.100/24 physical: bge0

2.Membuat zona non-global Apache2: # zonecfg -z Apache2 info zonepath: /export/home/Apache2 autoboot: false pool: inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr net: address: 192.168.0.200/24 physical: bge0

3.Log in ke Apache1 dan menginstall aplikasinya: # zlogin Apache1 # zonename Apache1 # ls /Apachedir apache_1.3.9 apache_1.3.9-i86pc-sun-solaris2.270.tar # cd /Apachedir/apache_1.3.9; ./install-bindist.sh /local

Sekarang server Apache HTTP 1.3.9 sudah terinstall.


37


4.Log in ke Apache2 dan menginstall aplikasinya: # zlogin Apache2 # zonename Apache2 # ls /Apachedir httpd-2.0.50 httpd-2.0.50-i386-pc-solaris2.8.tar # cd /Apachedir/httpd-2.0.50; ./install-bindist.sh /local You now have successfully installed the Apache 2.0.50 HTTP server.

5.Jalankan aplikasi Apache1: # zonename Apache1 # hostname Apache1zone # /local/bin/apachectl start /local/bin/apachectl start: httpd started

6.Jalankan aplikasi Apache2: # zonename Apache2 # hostname Apache2zone # /local/bin/apachectl start /local/bin/apachectl start: httpd started

7.Didalam zona global , edit /etc/hosts file: # cat /etc/hosts # # Internet host table # 127.0.0.1 localhost 192.168.0.1 loghost 192.168.0.100 Apache1zone 192.168.0.200 Apache2zone


38


8.Buka penjelajah web dan and kunjungi URL berikut: http://apache1zone/manual/index.html

Server web Apache1 aktif dan jalan. 9.Buka penjelajah web dan and kunjungi URL berikut: http://apache2zone/manual/

Server web Apache2 aktif dan jalan.


39


Diskusi Pengguna melihat masing-masing zona sebagai sistem yang berbeda. Masing-masing server web memiliki name services masing-masing:  File /etc/nsswitch.conf  File /etc/resolv.conf Serangan jahat terhadap server web dibatasi hanya terjadi didalam zona. Konflik port juga tidak pernah terjadi!


40

Pembuatan Pool Penyimpan Data dan Sistem File ZFS

Pembuatan Pool Penyimpan Data dan Sistem File ZFS Masing-masing pool penyimpan data ZFS terdiri dari satu atau lebih perangkat virtual, yang menggambarkan susunan fisik penyimpan data dan karakteristik penanganan kegagalannya. Dalam modul ini, pembahasan dimulai dengan mempelajari konfigurasi pool penyimpan data termirror. Kemudian, akan diperlihatkan bagaimana membuat konfigurasi sebuah pool RAID-Z.


41

Membuat Storage Pool ZFS Mirrored

Membuat Pool Penyimpan Data ZFS Termirror Tujuan latihan lab ini adalah untuk membuat dan menampilkan pool penyimpan data ter-mirror dengan perintah zpool. Untuk mendapatkan informasi, bagaimana memilih antara pool penyimpan data ZFS dengan konfigurasi ter-mirror atau RAID-Z yang sesuai dengan lingkungan komputasi tertentu, kunjungi: http://www.solarisinternals.com/wiki/index.php/ZFS_ Best_Practices_Guide

Ringkasan ZFS adalah mudah, mulailah mencobanya! Sekarang waktunya membuat pool untuk pertama kali. .


42

Membuat Storage Pool ZFS Mirrored

Membuat Pool Penyimpan Data Termirror 1.Buka jendela terminal 2.Buatlah sebuah pool penyimpan data ter-mirror bernama tank. Kemudian tampilkan informasi pool penyimpan data tersebut: # zpool create tank mirror c1t1d0 c2t2d0 # zpool status tank pool: tank state: ONLINE scrub: none requested config: NAME tank mirror c1t1d0 c2t2d0

STATE ONLINE ONLINE ONLINE ONLINE

READ 0 0 0 0

WRITE 0 0 0 0

CKSUM 0 0 0 0

errors: No known data errors

Kapasitas disk c1t1d0 dan c2t2d0 masing-masing adalah 36 Gbytes each. Karena kedua disk tersebut di-mirror, maka kapasitas total pool merefleksikan kurang lebih ukuran salah satu disknya. Metadata untuk pool menghabiskan ruang disk dengan jumlah yang kecil. Sebagai contoh: # zpool list NAME tank

SIZE USED AVAIL CAP HEALTH ALTROOT 33.8G 89K 33.7G 0% ONLINE –


43

Membuat Sistem File ZFS Sebagai Direktori Kerja Pengguna

Membuat Sistem File ZFS Sebagai Direktori Kerja Pengguna Tujuan dari latihan lab ini adalah untuk mempelajari bagaimana membuat sebuah sistem file ZFS sebagai beberapa direktori kerja (home directory) pengguna. Dengan menggunakan fitur sistem file ZFS, yang tersedia di proyek OpenSolaris, memungkinkan dilakukannya penyederhanaan proses pengembangan kernel dengan memanfaatkan fitur snapshots dan rollback.

Ringkasan Didalam lab ini, digunakan perintah zfs untuk membuat sebuah sistem file ZFS dan menentukan direktori aksesnya (mount point).


44


Membuat Sistem File ZFS Sebagai Direktori Kerja Pengguna 1.Tampilkan file sistem standar yang telah dibuat secara otomatis ketika pool penyimpan data dibuat. # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 86K 33.2G 24.5K /tank

2.Buat sistem file tank/home: # zfs create tank/home

3.Kemudian, ubah direktori akses sistem file tank/home seperti berikut ini: # zfs set mountpoint=/export/home tank/home

4.Kemudian, buat sistem file – sistem file tank/home untuk beberapa pengguna: # # # #

zfs zfs zfs zfs

create create create create

tank/home/developer1 tank/home/developer2 tank/home/developer3 tank/home/developer4

Properti mountpoint akan digunakan secara berkelanjutan untuk menentukan awalan nama direktori (pathname prefix). Sehingga direktori akses tank/home/developer1 secara otomatis akan menjadi /export/home/developer1 karena direktori akses tank/home telah diubah menjadi /export/home. 5.Periksa apakah sistem file ZFS telah dibuat: # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 246K 33.2G 26.5K /tank tank/home 128K 33.2G 29.5K /export/home tank/home/developer1 24.5K 33.2G 24.5K /export/home/developer1 tank/home/developer2 24.5K 33.2G 24.5K /export/home/developer2 tank/home/developer3 24.5K 33.2G 24.5K /export/home/developer3 tank/home/developer4 24.5K 33.2G 24.5K /export/home/developer4 Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

45



46


Lakukan snapshot secara rekursif untuk sistem file tank/home. Kemudian, tampilkan informasi snapshot tersebut: # zfs snapshot -r tank/home@today # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 252K 33.2G 26.5K /tank tank/home 128K 33.2G 29.5K /tank/home tank/home@today 0 - 29.5K tank/home/developer1 24.5K 33.2G 24.5K tank/home/developer1@today 0 - 24.5K tank/home/developer2 24.5K 33.2G 24.5K tank/home/developer2@today 0 - 24.5K tank/home/developer3 24.5K 33.2G 24.5K tank/home/developer3@today 0 - 24.5K tank/home/developer4 24.5K 33.2G 24.5K tank/home/developer4@today 0 - 24.5K -

/tank/home/developer1 /tank/home/developer2 /tank/home/developer3 /tank/home/developer4

Untuk informasi lebih lanjut, lihat zfs.1m.


47

Membuat Konfigurasi RAID-Z

Membuat Konfigurasi RAID-Z Tujuan dari latihan lab ini adalah sebagai pengenalan terhadap konfigurasi RAID-Z.

Ringkasan Konfigurasi RAID-Z dibuat sebagai konfigurasi alternatif terhadap konfigurasi pool penyimpan data ter-mirror untuk kebutuhan memaksimalkan ruang disk.


48

Membuat Konfigurasi RAID-Z

Membuat Konfigrurasi RAID-Z 1.Buka jendela terminal. 2.Buat sebuah pool dengan sebuah perangkat tunggal RAID-Z yang terdiri dari 5 disk. Kemudian, perlihatkan informasi tentang pool penyimpan data tersebut. # zpool create tank raidz c1t1d0 c2t2d0 c3t3d0 c4t4d0 c5t5d0 # zpool status tank pool: tank state: ONLINE scrub: none requested config: NAME tank raidz1 c1t1d0 c2t2d0 c3t3d0 c4t4d0 c5t5d0

STATE READ WRITE CKSUM ONLINE 0 0 0 ONLINE 0 0 0 ONLINE 0 0 0 ONLINE 0 0 0 ONLINE 0 0 0 ONLINE 0 0 0 ONLINE 0 0 0

errors: No known data errors

Disk bisa diakses dengan nama pendek atau nama lengkapnya. Contohnya, /dev/dsk/c4t4d0 adalah identik dengan c4t4d0. Dimungkinkan juga untuk menggunakan partisi disk sebagai pool penyimpan data ter-mirror dan RAID-Z, tapi konfigurasi seperti ini tidak direkomendasikan untuk lingkungan produksi. Untuk informasi lebih lanjut tentang penggunaan ZFS di lingkungan produksi, kunjungi: http://www.solarisinternals.com/wiki/index.php/ZFS_ Best_Practices_Guide.


49

4 M

O

D

U

L

Konsolidasi Area Pengguna Tujuan Tujuan modul ini adalah untuk memperkenalkan konsolidasi area pengguna (userland consolidations) dari OpenSolaris. Secara umum, konsolidasi area pengguna dapat dianggap sebagai kumpulan perangkat lunak yang berada diluar kernel dan sebagai komponen dimana denganya pengguna berinteraksi. Masing-masing konsolidasi mendistribusikan filefile kode pemogramannya ke situs opensolaris.org or sentra download Sun. Untuk mengakses masing-masing konsolidasi, kunjung URL berikut: http://opensolaris.org/os/downloads/.


50

Konsolidasi Area Pengguna dan Deskripsinya

Konsolisidasi Area Pengguna dan Deskripsinya Server Applikasi

Server Aplikasi Glassfish

Piranti Pengembangan Produk (DevPro)

Librari matematika, library media, librari microtasking, librari SCCS, make, dan C++ runtime.

Dokumentasi (Docs)

Dokumentasi teknis pengembangan dan administrasi.

Dukungan Globalisasi (G11N)

Dukungan Internationalisasi and lokalisasi.

Dukungan Instalasi (Install)

Dukungan instalasi and piranti pembuat paket.

Solusi JavaDesktop (JDS). Perangkat lunak desktop korporat yang aman dan komprehensif. Java Platform, Standard Edition (Java SE)

Distribusi JavaDevelopment Kit (JDK) and Java Runtime Environment (JRE).

Halaman Manual

Kode pemograman untuk Halaman Manual Referensi SunOS.

Message Queue.

Sun Java SystemMessage Queue

Penyimpan Data dalam Jaringan (NWS)

Dukungan perangkat penyimpan data dalam


51

Konsolidasi Area Pengguna dan Deskripsinya

jaringan. SFW (Solaris FreeWare)

Perangkat lunak dengan kode pemograman terbuka yang tersedia di Solaris/ OpenSolaris.

Dukungan Grafik SPARC

Konsolidasi grafik SPARC memiliki file-file biner untuk penggeraknya.

Test

Piranti dan kumpulan perangkat lunak pengujian OpenSolaris.

X Window System (X11)

Perangkat lunak X11


52

5 M

O

D

U

L

Fitur Inti Sistem Operasi Solaris Tujuan Tujuan dari modul ini adalah untuk memberikan gambaran fitur utama dari Solaris dan bagaimana fitur-fitur tersebut secarna fundamental telah mengubah komputasi Sistem Operasi

Sumber Bacaan Lain

 Proses Pengembangna OpenSolaris; http://www.opensolaris.org/os/community/onnv/os_d ev_process/  Standarisasi C Style dan Penulisan Kode untuk SunOS; http://www.opensolaris.org/os/community/documenta tion/getting_started_docs/


53

Proses Pengembangan dan Metode Penulisan Kode

Proses Pengembangan dan Metode Penulisan Kode Langkah-langkah proses pengembangan dan metode penulisan kode (coding style), yang digunakan oleh konsolidasi OS/Net (ON), dibuat untuk mendistribusikan komponen utama Sistem Operasi dan komponen Jaringan. Komponen Operating System and Networking terdiri dari kode pemograman kernel untuk semua platform (untuk semua arsitektur), sekumpulan kode pemograman penggerak perangkat, sistem file, librari utama dan perintah dasar yang biasa terdapat di sistem Solaris. Proses pengembangan proyek OpenSolaris mematuhi langkah-langkah umum berikut: 1.Ide Pertama, seseorang yang memiliki sebuah ide untuk perbaikan /penambahan atau memiliki ketidaknyamanan akibat adanya cacat. Lakukan pencarian informasi terlebih dahulu untuk kemungkinan keberdaan bug tersebut atau mengajukan sebagai kasus bug baru atau meminta request for enhancement (RFE) dengan menggunakan fasilitas yang ada di halaman http://bugs.opensolaris.org/. Berikutnya, mengumumkan hal tersebut kepada pengembangpengembang lain melalui E-mail list. Penyebaran pengumuman ini memiliki keuntungan-keuntungan sebagai berikut:  Memicu dengan segera adanya diskusi untuk pengubahan atau perbaikan  Menentukan kompleksitas dari pengubahanpengubahan yang diajukan Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

54


 Memperkirakan ketertarikan komunitas  Mengidentikasikan calon anggota tim yang potensial


55


2.Desain Fase desain menentukan apakah diperlukan atau tidak adanya tinjauan desain secara formal. Jika diperlukan tinjauan desain secara formal, maka lengkapi langkah-langkah berikut ini:  Mengidentifikasi peninjau (reviewers) bagi desain dan arsitektur yang akan diajukan  Membuat dokumen desain  Membuat rencana pengujian  Melakukan tinjauan desain dan meminta persetujuan dengan benar 3.Implementasi Fase implementasi terdiri dari hal-hal berikut:  Menuliskan kode yang akan menjadi solusi sesuai dengan ketentuan dan standar. Unduh Standar C Style and Coding untuk SunOS disini: http://www.opensolaris.org/os/community/documen tation/getting_started_docs/.  Membuat kumpulan pengujian  Melewati dan lulus berbagai unit and praintegrasi pengujian  Menuliskan atau memperbaharui dokumentasi pengguna, jika diperlukan  Mengindentifikasi peninjau kode pemograman dalam rangka persiapan untuk integrasi 4.Integrasi Integrasi terjadi setelah semua peninjau telah menyelesaiakan proses penijauan dan izin untuk melakukan integrasi telah diberikan. Fase integrasi diperlukan untuk memastikan bahwa Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

56


semua prosedur telah dipenuhi; memiliki fakta yang lengkap yang artinya telah ditinjau kode pemograman-nya, dokumentasi dan kelengkapannya.


57


Dokumen proses resmi untuk OpenSolaris menjelaskan langkah-langkah diatas lebih rinici, disertai diagram alir yang mengilustrasikan setiap fase-fase pengembangan. Dokumen tersebut juga menjelaskan secara rinci prinsip-prinsip desain dan nilai-nilai utama yang diterapkan terhadap pengembangan kode pemograman untuk proyek OpenSolaris:  Kehandalan – OpenSolaris harus melakukan fungsinya secara benar, menyediakan hasil kerja yang akurat tanpa kehilangan data atau terkorupsi.  Ketersediaan – Layanan-layanan harus didisain dengan kemampuan distart-ulang jika terjadi kegagalan aplikasi dan OpenSolaris sendiri harus berkemampuan memulihkan diri dari kegagalan perangkat keras yang tidak fatal  Kemampuan Servis – Kemampuan untuk mendiagnosa baik masalah-masalah yang fatal dan transien dan jika memungkinkan, mengotomasasi diagnosanya.  Keamanan – Keamanan OpenSolaris harus didisain sebagai bagian dari Sistem Operasi dengan menyediakan mekanisme agar dapat melakukan audit terhadap perubahan-perubahan yang dilakukan di sistem dan siapa yang melakukannya.  Kinerja – Kinerja OpenSolaris harus yang teratas dibandingkan Sistem Operasi lain yang berjalan di lingkungan yang sama.  Kemudahan Manajemen – Manejemen komponen individu perangkat keras atau perangkat lunak yang konsisten dan cara yang mudah.  Kompatibilitas – Sub-sistem dan antar-muka baru harus bisa diperluas dan dibuatkan versi terbarunya agar memungkinkan perbaikan atau perubahan di masa mendatang tanpa mengkuatirkan kompatibilitas.


58


 Kemudahan Perawatan – OpenSolaris harus berarsitektur sedemikian rupa sehingga subrutinsubrutin umum dapat dikombinasikan kedalam librari atau modul kernel yang kemudian dapat digunakan sebanyak-banyaknya pengguna.  Netralitas Platform –OpenSolaris harus tetap netral terhadap semua platform perangkat keras dan abstraksi level bawah harus selalu didisain dengan pertimbangan sebagai Sistem Operasi untuk banyak platform dan platform masa depan. Kunjungi http://www.opensolaris.org/os/community/onnv/os_dev _process/ untuk informasi lebih detail tentang bagaimana proses yang digunakan untuk pengembangan secara kolektif kode pemograman OpenSolaris. Seperti proyek-proyek lainnya, Open Solaris mengatur secara ketat metode penulisan kode untuk kode pemograman yang didistribusikan, darimana pun sumbernya. Hal ini dijelaskan secara rinci di situs http://opensolaris.org/os/community/onnv/. Ada 2 piranti untuk pengecekan elemen-elemen dari metode penulisan kode yang tersedia sebagai bagian dari distribusi OpenSolaris. Piranti tersebut adalah cstyle(1) untuk melakukan verifikasi kepatuhan sebuah kode pemograman terhadap pedoman metode penulisan kode umum, dan hdrchk(1) untuk pengecekan metode penulisan header C dan C++.


59

Tinjauan

Tinjauan Setelah mengenal lingkungan pengembangan, tahaptahap pengembangan dan prinsip-prinsip yang diterapkan oleh pengembang OpenSolaris, berikutnya dibahas lebih dalam fitur-fitur Sistem Operasi OpenSolaris untuk membuktikan keunggulannya dari sisi kinerja, keamanan, kemampuan servis dan kemudahan manajemen:  Kinerja  FireEngine  Nemo  Crossbow  Keamanan  Least Privilege  Packet Filtering  Zones  Branded Zones (BrandZ)  Kemampuan Servis  Predictive Self-Healing  Dynamic Tracing Facility (DTrace)  ModularDebugger (MDB)  Kemudahan Manajemen  ServicesManagement Facility (SMF)  ZFS


60

Tinjauan

FireEngine Fitur "FireEngine" yang ada di Solaris 10 adalah sebuah pendekatan yang menggabungkan semua lapisan protokol TCP/IP kedalam satu modul STREAMS yang secara penuh multithread. Didalam module yang tergabung ini, dibandingkan metode penguncian perstruktur data, sebuah mekanisme sinkronisasi perCPU yang disebut “perimeter vertikal” (vertical perimeter) digunakan. Mekanisme perimeter vertikal diimplementasikan dengan menggunakan abstraksi antrian secara serial yang disebut "squeue." Masing-masing squeue dilekatkan ke sebuah CPU, dan masing-masing koneksi secara bergantian dilekatkan ke sebuah squeue yang menyediakan metode sinkronisasi dan mutual exclusion yang diperlukan oleh struktur data perkoneksi.


61

Tinjauan

Sinkronisasi Karena lapisan TCP/IP secara penuh adalah multithread (dimana hanya serialiasasi per-CPU yang dilakukan oleh sebuah perimeter vertikal), metode ini menggunakan skema berbasiskan-referensi untuk memastikan bahwa instan koneksi selalu tersedia ketika diperlukan. Untuk koneksi TCP yang terjadi, tiga referensi diberikan kepadanya. Masing-masing lapisan protokol memiliki sebuah referensi untuk setiap instan koneksi (satu untuk lapisan TCP dan satu untuk lapisan IP) dan classifier sendiri memiliki satu referensi karena classifier berfungsi mewakili setiap koneksi yang telah dibuat. Setiap kali sebuah paket datang untuk koneksi tertentu dan classifier mencari instan koneksinya, sebuah referensi tambahan ditempatkan, yang kemudian referensi tersebut dibuang ketika lapisan protokol selesai memproses paket tersebut.


62

Tinjauan

TCP, IP, dan UDP Solaris 10 OS menyediakan sudut pandang yang sama terhadap TCP seperti terdapat pada versi-versi sebelumnya – yaitu TCP muncul sebagai sebuah perangkat terduplikasi (clone device) meskipun sebenarnya TCP adalah sebuah gabungan (composite), dimana kode TCP and IP dileburkan kedalam satu modul D_MP STREAMS. Bagian operasional TCP dilindungi secara penuh oleh perimeter vertical yang dimasukan melalui primitif squeue. FireEngine mengubah antar-muka antara TCP dan IP dari antar-muka yang ada sekarang yaitu penerusan pesan berbasiskan-STREAMS (STREAMS-based message passing) menjadi sebuah antar-muka berbasiskan-panggilan fungsional (functional callbased), baik untuk pengiriman informasi kontrol dan data. Terdapat juga modul UDP yang secara penuh multithread, yang berjalan dibawah domain perlindungan yang sama seperti IP. Meskipun UDP and IP berjalan didalam domain perlindungan yang sama, keduanya tetap merupakan modul-modul STREAMS yang terpisah. Sehingga, penempatan STREAMS secara vertikal (STREAMS plumbing) tetap tidak berubah dan sebuah instan modul UDP selalu didorong diatas modul IP. Platform Solaris 10 menyediakan dua mode penempatan secara vertikal (plumb modes) sebagai berikut:  Normal – IP dibuka terlebih dahulu kemudian UDP didorong secara langsung diatasnya. Ini adalah aksi standar yang terjadi ketika sebuah soket UDP atau perangkat dibuka.  SNMP – UDP didorong diatas modul selain IP. Ketika ini terjadi, hanya semantik SNMP yang akan didukung. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

63

Tinjauan

GLDv3 Solaris 10 memperkenalkan sebuah kerangka kerja baru untuk program penggerak perangkat (new device driver framework) disebut GLDv3 disertai dengan lapisan fungsional baru. Sebagian besar program penggerak perangkat utama sudah menggunakan ke struktur ini, dan semua program penggerak perangkat masa depan dan perangkat jaringan 10 Gb akan berdasarkan kerangka ini. Kerangka kerja ini juga menyediakan sebuah lapisan DLPI berbasiskan-STREAMS untuk kompatibilitas balik, sehingga modul-modul ekstenal dan modul non-IP dapat terus bekerja. Arsitektur GLDv3 mem-virtulisasikan lapisan kedua dari lapisan protokol jaringan. Korespondesi satulawan-satu antara antar-muka jaringan dan lapisan fungsional perangkat diatasnya tidak diperlukan lagi. Kunjungi Proyek Nemo di situs opensolaris.org untuk informasi lebih lanjut yang berkaitan dengan kerangka kerja ini , modul layanan MAC, modul DataLink Services.


64

Tinjauan

Virtualisasi Proyek Crossbow merupakan sebuah proyek yang bertujuan untuk membuat lapisan protokol virtual dari semua layanan jaringan (HTTP, HTTPS, FTP, NFS, dsb), protokol utama (TCP, UDP, SCTP, dsb.), atau Teknologi Kontainer Solaris. Lapisan protokol virtual ini dipisahkan berdasarkan klasifikasi perangkat keras artinya trafik untuk satu lapisan protokol tertentu tidak akan mempengaruhi lapisan protokol virtual yang lain. Masing-masing lapisan protokol virtual ini dapat diberikan prioritas dan lebarpita yang berbeda meskipun hanya menggunakan satu kartu Ethernet tanpa menimbulkan penurunan kinerja terhadap sistem atau layanan/kontainer. Aristektur ini secara dinamis mengatur prioritas dan alokasi lebar-pita, selain itu juga menyediakan pertahanan yang lebih baik terhadap serangan denial-of-service yang ditujukan kepada layanan atau kontainer tertentu; yaitu dengan pengisolasian dampak serangan hanya pada layanan atau kontainer tersebut.


65

Tinjauan

Least Privilege (Hak Istimewa Terbatas) Dari sejak dulu, UNIX memiliki model hak istimewa didalam sistem yang bersifat “berikan semuanya atau tidak sama sekali” (all-or-nothing) yang memaksakan pembatasan-pembatasan berikut:  Hak istimewa root tidak dapat dibatasi  Pengguna non-root tidak bisa melakukan kegiatan administratif terhadap sistem yang memerlukan hak istimewa karena tidak cara untuk membagi hak istimewa ke pengguna non-root  Aplikasi yang sebenarnya hanya memerlukan sedikit kegiatan dengan hak istimewa harus dijalankan sebagai root  Sangat sedikit hal yang bisa dipercaya dengan hak-hak istimewa root dan secara virtual tidak ada pengguna non-root yang begitu sangat dipercaya. Di dalam Solaris OS telah dikembangkan fine-grained privileges. Fine-grained privileges memungkinkan aplikasi dan proses login users untuk berjalan hanya dengan hak-hak istimewa yang mereka butuhkan. Sebagai ilustrasi, hak istimewa terbatas memungkinkan mahasiswa untuk diberikan hak-hak istimewa terbatas yang mereka butuhkan untuk menyelesaikan kuliah mereka, berpartisipasi dalam riset dan melakukan perawatan sebagian dari infrastruktur kampus atau departemen.


66

Tinjauan

Filtrasi Paket Solaris IP Filter berfungsi menyediakan stateful packet filtering and network address translation (NAT). Solaris IP Filter berasal dari perangkat lunak kode pemograman terbuka IP Filter. IP Filter dapat menyaring paket berdasarkan alamat IP, port, protokol, atau antarmuka jaringan berdasarkan kaidah-kaidah filter tertentu.


67

Tinjauan

Filter IP Packet Filtering Hooks (PFHooks) API telah diperkenalkan sejak Solaris 10 Update 4, untuk menggantikan implementasi berbasiskan-STREAMS dari IP Filter. Dengan menggunakan kerangka kerja PFHooks, kinerja perangkat lunak firewall seperti IP Filter secara luar biasa mengalami peningkatan. PFhooks juga menyediakan kemampuan untuk mencegat trafik loopback dan inter-zona. Perangkat lunak firewall pihak ketiga dikembangkan dan diregistrasi dengan PFHooks API menggunakan the net_register_hook(info, event, hook); hook.


68

Tinjauan

Mengaktifkan Filtrasi Paket Sederhana Tujuan latihan ini untuk mempelajari filtrasi paket. Solaris IP Filter telah terinstall didalam Sistem Operasi Solaris, namun, sesuai standarnya filtrasi paket tidak diaktifkan. IP Filter dapat mem-filter berdasarkan alamat IP, port, protokol, atau antar muka jaringan berdasarkan kaidah-kaidah filter tertentu. Berikut ini adalah sebuah contoh kaidah filter: block in on ce0 proto tcp from 192.168.0.0/16 to any port = 23

Untuk menggunakan Solaris IP Filter, caranya sederhana yaitu dengan memasukan kaidah filter kedalam file /etc/ipf/ipf.conf. Kemudian, aktifkan dan start-ulang layanan svc:network/ipfilter dengan perintah svcadm. Catatan – Perintah ipf juga dapat digunakan untuk membuat kaidah-kaidah IPFilter. Solaris IP Filter dapat melakukan juga pengkonversian alamat jaringan (NAT, Network Address Translation) untuk sebuah alamat IP pengirim atau sebuah alamat IP tujuan berdasarkan kaidah NAT. Berikut adalah sebuah contoh kaidah NAT: map ce0 192.168.1.0/24 -> 10.1.0.0/16

Agar dapat melakukan pengkonversian alamat jaringan, simpan kaidah-kaidah NAT kedalam file /etc/ipf/ipnat.conf. Kemudian aktifkan dan start-ulang layanan svc:/network/ipfilter dengan perintah svcadm. Catatan – Perintah ipnat juga dapat digunakan untuk membuat kaidah-kaidah NAT. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

69

Tinjauan

Beberapa Contoh Kaidah Filtrasi Paket Pada bagian ini diberikan beberapa contoh kaidah pembentukan filter. Mengaktifkan kaidah filter adalah dengan menambahkanya kedalam file /etc/ipf/ipf.conf. Kemudian, aktifkan Solaris IP Filter and reboot komputer seperti dijelaskan secara detail pada latihan sebelumnya. Me-log semua paket masuk di le0 dengan opsi IP aktif. log in on le0 from any to any with ipopts

Memblokir semua paket masuk di le0 yang terfragment dan terlalu pendek untuk dilakukan perbandingan tertentu. Ini sebenarnya hanya bisa diterapkan untuk paket TCP yang bisa mengalami kehilangan flag/port (tergantung kondisi fragment yang terlihat). block in log quick on le0 from any to any with short frag

Me-log semua paket masuk TCP hanya jika bendera SYN aktif. Catatan – Jika paket masuk TCP memiliki bendera SYN yang aktif dan memiliki opsi IP yang aktif maka kaidah ini menyebabkan paket di-log sebanyak dua kali. log in on le0 proto tcp from any to any flags S/SA


70

Tinjauan

Memblokir dan me-log semua paket masuk ICMP unreachable: block in log on le0 proto icmp from any to any icmp-type unreach

Memblokir dan me-log semua paket masuk UDP di le0 yang menuju ke port 2049 (portnya NFS): block in log on le0 proto udp from any to any port = 2049

Segera membolehkan semua paket ke/dari sebuah pasangan komputer tertentu: pass pass pass pass

in in in in

quick quick quick quick

from from from from

any to 10.1.3.2/32: any to 10.1.0.13/32 10.1.3.2/32 to any 10.1.0.13/32 to any

Memblokir (dan berhenti mencari kaidah lain yang cocok) semua paket dengan opsi IP aktif: block in quick on le0 from any to any with ipopts

Meneruskan semua paket yang lewat: pass in from any to any


71

Tinjauan

Memblokir semua paket masuk UDP yang ditujukan ke subnet tertentu: block in on le0 proto udp from any to 10.1.3.0/24 block in on le0 proto udp from any to 10.1.1.0/24 block in on le0 proto udp from any to 10.1.2.0/24

Memblokir semua paket masuk TCP jika hanya bendera SYN aktif dan ditujukan ke subnet-subnet berikut: block in on le0 proto tcp from any to 10.1.3.0/24 flags S/SA block in on le0 proto tcp from any to 10.1.2.0/24 flags S/SA block in on le0 proto tcp from any to 10.1.1.0/24 flags S/SA

Memblokir semua paket masuk ICMP yang ditujukan ke subnet-subnet berikut: block in on le0 proto icmp from any to 10.1.3.0/24 block in on le0 proto icmp from any to 10.1.1.0/24 block in on le0 proto icmp from any to 10.1.2.0/24


72

Tinjauan

Zona (Zones) Zona adalah sebuah abstraksi Sistem Operasi virtual yang menyediakan lingkungan komputasi terproteksi dimana didalamnya aplikasi dapat berjalan. Didalam zona, aplikasi tertentu diproteksi dari aplikasi lainnya untuk menyediakan isolasi terhadap kegagalan perangkat lunak. Untuk memudahkan pekerjaan mengontrol banyak aplikasi dan lingkunganya, semua aplikasi berjalan bersaman dalam satu Sistem Operasi, dan biasanya dikontrol sebagai satu unit. Sejumlah kecil aplikasi yang biasanya dijalankan sebagai root proses atau dengan hak-hak istimewa tertentu tidak diperbolehkan untuk berjalan didalam zona jika aplikasi-aplikasi tersebut berkemampuan mengakses atau mengubah sumber daya global. Sebagai contoh, kemampuan untuk mengubah penghitung waktu harian sistem. Aplikasi-aplikasi seperti ini sebaiknya tetap digunakan hanya didalam zona global tetapi jika diperlukan berjalan didalam zona nonglobal maka harus dikonfigurasikan dengan sangat hati-hati. Berikut beberapa pedoman:  Aplikasi yang mengakses layanan jaringan, filefile tertentu dan tidak melakukan aktivitas I/O yang lain, seharusnya dapat bekerja dengan benar didalam zona.  Aplikasi yang memerlukan akses langsung ke perangkat tertentu, contohnya: sebuah partisi disk, dapat dilakukan jika zona tersebut dikonfigurasikan dengan benar. Namun demikian, dalam kasus-kasus tertentu hal ini meningkatkan resiko gangguan keamanan.  Aplikasi yang memerlukan akses langsung perangkat Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

73

Tinjauan

tertentu seperti berikut ini mungkin perlu dimodifikasi untuk dapat berfungsi secara benar. Sebagai contoh, /dev/kmem, atau perangkat jaringan. Aplikasi seharusnya hanya menggunakan satu layanan IP dalam setiap zona.


74

Tinjauan

Zona dapat dikombinasikan dengan fasilitas manajemen sumber daya yang tersedia di OpenSolaris untuk menyediakan lingkungan komputasi yang lebih lengkap dan terisolasi. Berbeda dengan zona yang lebih berfungsi menyediakan keamanan, isolasi identitas dan isolasi kegagalan, fasilitas manajemen sumber daya digunakan untuk mencegah proses yang ada didalam sebuah zona menghabiskan terlalu banyak sumber daya atau untuk menjamin agar proses mendapatkan sumber daya sesuai dengan tingkat layanan yang diinginkannya. Zona dan manajement sumber daya keduanya sering disebut sebagai kontainer. Kunjungi http://opensolaris.org/os/community/zones/ faq untuk mendapatkan jawaban dari pertanyaanpertanyaan umum tentang zona dan alamat-alamat situs lain menyimpan dokumentasi terbarunya. Zona menyediakan lingkungan komputasi yang terlindungi bagi aplikasi-aplikasi Solaris. Sedangkan untuk lingkungan komputasi non-Solaris yang terlindungi dan terpisah tersedia melalui proyek OpenSolaris lain yang disebut BrandZ .


75

Tinjauan

Zona Bertanda-identitas (Branded Zones - BrandZ) BrandZ merupakan sebuah kerangka kerja yang memperluas infrastrukur zona yang ada sekarang untuk menciptakan Zona Bertanda-identitas, yang merupakan zona dengan lingkungan komputasi nonSolaris ada didalamnya. Zona Bertanda-identitas bisa berupa lingkungan komputasi sederhana dimana didalamnya perintahperintah standar Solaris digantikan oleh perintah GNU yang sama tanpa dimodifikasi, atau lingkungan yang kompleks berupa lingkungan pengguna Linux lengkap. BrandZ memperluas infrastruktur Zona di tingkat lingkungan pengguna dengan beberapa cara berikut ini:  Sebuah tanda-identitas adalah sebuah atribut yang melekat pada sebuah zona, diberikan pada saat mengkonfigurasi zona.  Setiap tanda-identitas menyediakan program dan prosedur instalasi sendiri, sehingga memiliki kemampuan untuk menginstal perangkat lunak apa pun didalam zona bertanda-identitas.  Masing-masing tanda-identitas menyediakan skrip pra-boot dan pasca-boot untuk keperluan penyelesaian pengaturan atau konfigurasi pada saat boot.  Perintah zonecfg dan zoneadm dapat digunakan untuk pengaturan dan memberikan informasi tipe tandaidentitas sebuah zona.


76

Tinjauan

BrandZ menyediakan beberapa titik inter-posisi dalam lingkungan kernel:  Titik ini berada di jalur syscall, jalur pemuatan proses dan jalur penciptaan thread, dll.  Titik inter-posisi hanya diterapkan terhadap proses-proses didalam zona Bertanda-identitas.  Di titik ini, sebuah tanda-identitas dapat memilih untuk memodifikasi atau mengganti perilaku standar Solaris OS.  Pada dasarnya setiap tanda-identitas yang berbeda memerlukan titik inter-posisi baru. Tanda-identitas “lx” memungkinkan aplikasi biner Linux dapat dijalankan tanpa dimodifikasi diatas Solairs, didalam zona yang menjalankan lingkungan penggunak Linux lengkap. Tanda-identitas lx memungkinakn perangkat lunak Linux di tingkatpengguna dapat berjalan dengan kernel OpenSolaris kernel, dan termasuk didalamnya adalah piranti yang diperluka untuk menginstal distribusi Linux CentOS atau RedHat Enterprise didalam zona diatas sistem Solaris. Tanda-identitas lx berjalan di sistem x86/x64 dan boot dengan kernel 32-bit atau 64-bit. Tetapi hanya aplikasi Linux 32-bit bisa berjalan. Hingga sekarang, fitur ini baru tersedia untuk arsitektur x86 dan AMDx64. Namun, memindahkannya ke sistem berarsitektur SPARC mungkin bisa menjadi proyek komunitas yang menarik karena BrandZ lx masih terus dikembangkan. Kunjungi http://opensolaris.org/os/community/brandz/installu ntuk mendapatkan informasi kebutuhan instalasi dan petunjunknya Proyek OpenSolaris memang ditujukan untuk mencari tantangan unik dalam pengembangan Sistem Operasi dan pengujian kinerja aplikasi yang menggunakan Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

77

Tinjauan

fitur tertentu misalnya zona.


78

Tinjauan

Jaringan Didalam Zona Berdasarkan cara yang dipilih untuk memberikan alamat IP pada sebuah zona Solaris maka zona terbagi sebagai berikut:  Zona dengan IP-Eksklusif  Zona dengan IP-Berbagi Zona dengan IP-Eksklusif memiliki lapisan fungsional IP mandiri, antarmuka jaringan fisik mandiri dan antarmuka VLAN mandiri. Konfigurasi jaringan zona dengan IP-Eksklusif identik dengan konfigurasi jaringan komputer fisik. Zona dengan IP-Berbagi berbagi lapisan fungsional IP dengan zona global, sehingga tertutup dari rincian konfigurasi perangkat jaringan, rute jaringan dan sebagainya. Masing-masing zona IPberbagi dapat diberikan alamat IPv4/IPv6. Meskipun berbagi lapisan fungsional IP, masing-masing zona IP-berbagi memiliki ketersediaan port yang mandiri. Aplikasi dapat mengikat diri ke INADDR_ANY dan hanya menerima lalulintas data yang ditujukan ke zona tersebut. Di dalam kedua tipe zona ini, pengamatan terhadap lalulintas data milik sebuah zona yang lain tidak dapat dilakukan. Paket yang berasal dari sebuah zona akan memiliki alamat IP pengirim yang dimiliki zona tersebut. Zona dengan IP-berbagi hanya dapat mengirim paket melalui antarmuka dengan alamat IP yang diberikan kepada zona tersebut. Zona dengan IP-berbagi hanya bisa menggunakan router default jika router tersebut dapat dijangkau secara langsung dari zona. Router default harus berada dalam sub-jaringan yang sama dengan zona-nya.


79

Tinjauan

Zona IP-berbagi tidak dapat mengubah konfigurasi jaringan atau tabel informasi rute dan tidak dapat mengakses konfigurasi jaringan milik zona yang lain. Perangkat logis /dev/ip tidak tersedia didalam zona IP-berbagi. Sebagai akibatnya agen SNMP harus mengakses /dev/arp bukan /dev/ip. Beberapa zona IPberbagi secara bersamaan dapat berbagi alamat IP broadcast dan bergabung di group multicast yang sama. Zona IP-berbagi juga memiliki keterbatasan kemampuan jaringan yang lain, seperti:  Ketersediaan antarmuka jaringan fisik didalam zona tidak dimungkinkan  IPFilter tidak dapat digunakan untuk menyaring paket diantara dua atau lebih zona  Pemberian alamat IP untuk zona tidak bisa menggunakan DHCP  Routing secara dinamis tidak dapat dilakukan Zona dengan IP-eksklusif tidak memiliki keterbatasan seperti diatas, dan dapat mengubah konfigurasi jaringan atau tabel informasi rute. Perangkat logis /dev/ip tersedia didalam zona dengan IP-eksklusif.


80

Tinjauan

Identitas Zona, Akses terhadap CPU dan Instalasi Paket Masing-masing zona mengontrol sendiri nama komputer, zona waktu dan layanan identitas seperti LDAP dan NIS. Program sysidtool yang dapat melakukan ini semua. Terpisahnya file /etc/passwd memungkinkan hak-hak khusus root didelegasikan ke masing-masing zona. Nomor ID pengguna yang sama dapat digunakan oleh nama pengguna yang berbeda ketika mereka ada di domain yang berbeda. Berdasarkan standar, semua zona bisa mengakses semua sumber daya CPU. Pembatasan akses terhadap sumber daya secara otomatis dilakukan ketika pool sumber daya dibuat. Didalam zona dapat diinstal paket hanya didalam zona yang bersangkutan. Patch juga dapat diinstall untuk paket tersebut. Patch Sistem diinstal didalam zona global. Kemudian, di dalam zona non-global secara otomatis dilakukan boot -s agar patchnya dapat berfungsi. Parameter paket SUNW_PKG_ALLZONES sebaiknya digunakan secara konsisten diantara zona global dan semua zona non-global. Parameter SUNW_PKG_HOLLOW menyebabkan nama paket muncul didalam zona non-global (NGZ) tetapi hanya untuk kelengkapan informasi ketergantungan paket karena sebenarnya paket tersebut tidak terinstal.


81

Tinjauan

Perangkat Didalam Zones Masing-masing zona memiliki akses ke perangkat masing-masing yang berbeda. Setiap zona memiliki akses terhadap sekumpulan bagian dari perangkat pseudo didalam direktori /dev. Aplikasi mengakses nama perangkat logis berdasarkan perangkatperangkat yang disajikan didalam direktori /dev. Direktori /dev tersedia didalam masing-masing zona non-global, tetapi direktori /devices tidak ada. Ketersediaan perangkat seperti random, console, and null dibolehkan jika tersedia didalam zona tetapi yang lainnya seperti /dev/kmem tidak dianjurkan dapat diakses dari zona non-global. Didalam zona izin akses terhadap perangkat dapat dimodifikasi tetapi perangkat baru tidak dapat dibuat, misalnya dengan fungsi mknod(2). Ketersediaan akses secara raw terhadap disk didalam zona harus dilakukan dengan hati-hati. Berbagi perangkat diantara beberapa zona juga bisa dilakukan tetapi tetap dengan mempertimbangan keamanan. Sebagai contoh, diasumsikan akses ke beberapa perangkat tertentu telah diberikan ke beberapa zona sekaligus. Dengan mengizinkan pengguna biasa mengakses secara block terhadap disk memungkinkan terjadinya panik sistem, ter-resetnya bus atau efek merugikan lainnya. Dengan penempatan sebuah perangkat fisik yang sama didalam beberapa zona, sebuah saluran koneksi tersembunyi dapat dibuat antara zona-zona yang bersangkutan. Aplikasi di zona global yang juga mengakses perangkat yang sama memiliki resiko datanya terubah atau rusak akibat serangan dari zona non-global.


82

Tinjauan

Prakiraan Penyembuhan-Diri (Predictive Self-Healing) Pra-kiraan Penyembuhan-Diri diimplementasi menjadi 2 bagian di dalam Solaris 10 yaitu Arsitektur Manajemen Kegagalan dan Fasilitas Manajemen Layanan.


83

Tinjauan

Arsitektur Manajemen Kegagalan (Fault Management Architecture FMA) Sistem Operasi Solaris menyediakan arsitektur baru, FMA, untuk menciptakan mekanisme penanganan kegagalan yang fleksibel, telemetri kegagalan, diagnosa perangkat lunak secara otomatis, agen yang akan bertindak jika terjadi kesalahan, dan model yang konsisten terhadap kegagalan sistem di setiap tingkat manajemen. Banyak komponen dari Solaris yang sudah terlibat kedalam FMA, termasuk diantaranya penangan kegagalan CPU dan Memori untuk UltraSPARC III dan IV; kartu antarmuka PCI untuk UltraSPARC dan Opteron. Berbagai proyek juga sedang berjalan, antara lain untuk dukungan penuh terhadap kegagalan CPU, Memori, and I/O di lingkungan komputasi Opteron, konversi penggerak perangkat utama dan integrasi dengan berbagai tingkat manajemen. Ketika sebuah subsistem dikonversikan agar bisa terlibat dalam Manajemen Kegagalan, mekanisme penanganan kegagalannya dibuat secara fleksibel sehingga sistem dapat dapat terus bekerja meskipun beberapa kegagalan ditingkat bawah terjadi, dan sebuah kejadian telemetri dibuat untuk memicu diagnosa dan tanggapan perbaikan secara otomatis. Piranti dan arsitektur Manajemen Kegagalan memungkinkan dikembangkannya mekanisme penyembuhandiri terhadap kegagalan perangkat lunak dan perangkat keras, baik untuk sumber daya yang berskala mikro atau makro, semuanya dengan sudut pandang yang seragam dan sederhana bagi administrator dan perangkat lunak manajemen sistem. Kunjungi http://opensolaris.org/os/community/fm untuk mendapatkan informasi agar bisa Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

84

Tinjauan

berpartisipasi dalam komunitas Manajemen Kegagalan atau mengunduh MIB unutk Manajemen Kegagalan yang hingga sekarang masih terus disempurnakan.


85

Tinjauan

Fasilitas Manajemen Layanan (Services Management Facility SMF) SMF menciptakan sebuah model yang terintegrasi dan terus berkembang untuk kemudahan manajemen layananlayanan yang jumlahnya semakin besar di proyek OpenSolaris. Layanan-layanan tersebut antara lain: pengiriman surat elektronik, permintaan ftp dan eksekusi perintah secara remote. Kerangka kerja smf(5) menggantikan mekanisme startup init.d(4) yang ada sekarang dan termasuk juga perbaikan fitur inetd(1M). Bagi pengembang, SMF menyediakan keuntungan berikut:  Secara otomatis me-restart layanan sesuai dengan urutan saling ketergantungannya. Banyak hal yang menyebabkan layanan berhenti antara lain: kegagalan administratif, kegagalan perangkat lunak atau kerusakah perangkat keras yang permanen.  API yang sama untuk kebutuhan manajemen layanan, konfigurasi dan observasi  Akses terhadap manajemen sumber daya yang berbasiskan layanan  Men-debug proses boot menjadi lebih mudah Kunjungi http://opensolaris.org/os/community/smf/scfdot untuk melihat grafik layanan-layanan SMF dan ketergantungannya pada sebuah sistem x86 yang baru saja terinstal Sistem Operasi Solaris Nevada.


86

Tinjauan

Perunut Dinamis (Dynamic Tracing DTrace) DTrace menyediakan sebuah infrastruktur kokoh yang dapat digunakan oleh administrator, pengembang dan teknisi operasional untuk secara cepat menjawab berbagai pertanyaan tentang perilaku Sistem Operasi dan program pengguna. DTrace memiliki kemampuan seperti berikut ini:  Secara dinamis mengaktifkan dan mengatur ribuan probe  Secara dinamis menghubungkan predikat dan aksi dengan probe  Secara dinamis mengatur kapasitas penyangga saat merunut dan beban kerja probe Menguji data hasil merunut yang diperoleh dari sistem secara langsung atau dari file yang tersimpan setelah sistem mengalami kegagalan ditingkat kernel (system crash dump)  Mengimplementasikan penyedia data tambahan untuk perunutan baru yang dipasangkan kedalam DTrace  Mengimplementasi konsumen data hasil merunut yang akan menyajikan data  Mengimplementasikan piranti untuk mengkonfigurasi probe DTrace Temukan situs komunitas DTrace di http://opensolaris.org/os/community/dtrace. Selain DTrace, proyek OpenSolaris juga menyediakan fasilitas pen-debug untuk pengembangan perangkat lunak di tingkat-bawah, misalnya pengembangan penggerak perangkat.


87

Tinjauan

Pen-debug Modular (Modular Debugger - MDB) MDB adalah sebuah pen-debug yang dirancang untuk menyediakan analisa masalah perangkat lunak yang memerlukan fasilitas pen-debug-an di tingkat-bawah, misalnya pengujian file core; dan pengetahuan tentang bahasa assembly diperlukan agar bisa melakukan diagnosa dan memperbaikinya. Umumnya, para pengembang kernel dan perangkat mengandalkan mdb untuk mencari jawaban mengapa dan dimana terjadi kesalahan pada kode pemograman mereka. MDB tersedia dalam dua perintah berbeda yaitu mdb dan kmdb, namun keduanya memiliki beberapa kesamaan fitur umum. Perintah mdb digunakan secara interaktif atau didalam skrip untuk mendebug proses di tingkat pengguna yang sedang berjalan, file core dari proses di tingkat pengguna, kernel crash dump, file object Sistem Operasi yang sedang berjalan dan file lainnya. Sedangkan kmdb digunakan untuk men-debug proses di tingkat kernel dan penggerak perangkat yang sedang berjalan, juga diperlukan untuk mengontrol dan menghentikan eksekusi intruksi didalam kernel. Terdapat komunitas yang aktif mendiskusikan MDB sebagai tempat untuk bertanya kepada para pakar atau melihat berbagai percakapan dan pertanyaan yang pernah disampaikan sebelumnya. Kunjungi http://opensolaris.org/os/community/mdb


88

Tinjauan

Sistem File ZFS Sistem file ZFS merupakan sistem file yang tidak dibatasi oleh perangkat keras tertentu, sehingga begitu mudah dan cepat untuk dibuat seperti membuat sebuah direktori, dan sistem file ini bertambah kapasitasnya secara otomatis sesuai dengan kapasitas maksimum yang dialokasikan didalam pool penyimpan datanya.


89

Tinjauan

Penggunaan Checksum dan Perbaikan Data Dengan ZFS, semua data dan metadata diproteksi dari kesalahan dengan checksum dimana algoritma yang akan digunakannya bisa dipilih. Semua perhitungan checksum dan perbaikan kesalahan data dilakukan di level sistem file dan semuanya transparan bagi aplikasi. Selain itu, ZFS juga berkemampuan memperbaiki-sendiri data dari kerusakan. ZFS mendukung pool penyimpan data berkemampuan redundansi data yaitu mirror dan sebuah variasi RAID-5. Ketika terdeteksi sebuah data blok rusak maka ZFS mengambil data yang masih utuh dari lokasi lain yang berisi data yang sama kemudian memperbaiki data blok yang rusak tersebut yaitu dengan menggantinya oleh data blok yang masih utuh. ZFS menyajikan model pool penyimpan data dimana model ini membuang konsep volume beserta masalahnya. Masalah-masalah tersebut meliputi: perlunya mempartisi, melakukan provision, kinerja yang tidak maksimal dan pemakaian kapasitas penyimpan yang tidak optimal Gabungan kapasitas I/O dari semua perangkat keras di dalam pool tersedia untuk untuk semua sistem file sepanjang waktu. Masing-masing pool penyimpan data terdiri dari satu atau lebih perangkat virtual yang menggambarkan disain penyimpan data fisiknya dan karakteristik kemampuan bertahan terhadap kerusakan. Kunjungi http://opensolaris.org/os/community/zfs/demos/basic s untuk menyaksikan demo administrasi sistem file ZFS yang berjudul “100 Mirrored Filesystems in 5 Minutes”.


90

Tinjauan

RAID-Z Selain konfigurasi penyimpanan data tunggal dalam sebuah pool, ZFS juga menyediakan konfigurasi penyimpanan data redundansi ter-mirror dan redundansi RAID-Z yang memberikan perlindungan sangat baik terhadap kehilangan data. Konfigurasi RAID-Z merupakan perangkat penyimpan data virtual yang menyimpan data dan pariti secara tersebar di banyak disk sekaligus, mirip dengan RAID-5. Berbeda dengan RAID-5, RAID-Z menggunakan ukuran RAID stripe yang tidak tetap sehingga setiap operasi tulis selalu menjad operasi tulis fullstripe. Fitur ini hanya ada di ZFS karena ZFS mengintegrasikan manajemen sistem file dan perangkat keras. Pengintegrasian ini menyediakan suatu cara dimana metadata dari sistem file selalu memiliki cukup informasi tentang pondasi dari model replikasi datanya untuk menangani ukuran RAID stripe yang tidak tetap. RAID-Z merupakan solusi berbasis perangkat lunak pertama yang mengatasi kelemahan operasi tulis dari RAID-5.


91

6 M

O

D

U

L

Konsep Pemograman Tujuan Modul ini menyajikan deskripsi umum tentang konsepkonsep dasar lingkungan pemograman OpenSolaris, yang meliputi:  Manajemen Proses dan Sistem  Pemograman Thread  Fungsi-fungsi Dasar Kernel  Penjadwalan CPU  Men-debug Proses

Sumber Bacaan Lain  Solaris Internals (2nd Edition), PrenticeHall PTR (May 12, 2006) by Jim Mauro and RichardMcDougall  Solaris Systems Programming, PrenticeHall PTR (August 19, 2004), by Rich Teer  Multithreaded Programming Guide. SunMicrosystems, Inc., 2005.  STREAMS Programming Guide. SunMicrosystems, Inc., 2005.  Solaris 64-bit Developer’s Guide. SunMicrosystems, Inc., 2005.


92

Manajemen Proses dan Sistem

Manajemen Proses dan Sistem Unit dasar beban kerja sistem komputasi adalah proses. Setiap proses diberi tanda pengenal berupa nomor identifikasi proses (PID), nomor ini dibuat secara berurutan didalam sistem. Sesuai standarnya, setiap setiap pengguna akan diberikan sebuah proyek oleh sistem administrator, proyek merupakan sebuah identitas administratif yang bersifat global. Setiap login ke sebuah proyek akan menciptakan sebuah tugas (task), tugas merupakan mekanisme pengelompokan proses. Sebuah tugas terdiri dari proses login dan anak proses lain yang mengikutinya. Fasilitas pool sumber-daya menggabungkan beberapa sumber-daya yang tersedia bagi proses kedalam sebuah abstraksi umum disebut pool. Himpunan prosesor dan sumber-daya lain dikonfigurasikan, dikelompokan dan diberi label sedemikian rupa sehingga menjadi komponen beban-kerja yang terkait sebagai himpunan bagian dari total sumber-daya yang dimiliki sistem. Jika fasilitas pool tidak aktif maka semua proses akan dimiliki oleh pool yang sama yaitu pool_default, dan himpunan prosesor diatur melalui panggilan fungsi sistem pset(). Ketika fasilitas pool diaktifkan, himpunan proses harus diatur dengan menggunakan fasilitas pool. Sebuah pool baru diciptakan dan dilekatkan dengan himpunan prosesor tertentu. Berikutnya, proses dilekatkan dengan pool yang memiliki himpunan sumber-daya tertentu. Dengan menggunakan OpenGrok untuk melihat sumber kode pemograman pool.c, dapt dilihat komentar yang menjelaskan hubungan antara tugas, pool, proyek dan proses, seperti berikut ini: “Tindakan untuk melekatkan tugas dan proyek dengan Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

93


pool bersifat atomik. Artinya, baik itu semua proses yang ada didalam sebuah tugas atau proyek akan dilekatkan ke sebuah pool baru, atau tetap melekat di pool sebelumnya (jika terjadi kegagalan). Proses yang ada didalam sebuah tugas atau proyek hanya bisa dilekatkan ke pool yang berbeda jika proses-proses tersebut masing-masing dilekatkan-ulang satu-persatu sebagai proses tunggal.


94


Threads atau LWPs dari proses yang sama bukan merupakan obyek yang dilekatkan pada sebuah pool, dan keduanya dilekatkan dengan himpunan sumber-daya yang sama yang terkait dengan pool sumber-daya dari proses yang bersangkutan. Proses dapat juga dijalankan didalam zona. Zona diciptakan oleh adminstrator sistem, biasanya untuk alasan keamanan, agar dapat mengisolasi sekelompok pengguna atau proses dari yang lainnya.”


95


Pemograman Thread Sejauh ini telah dipelajari proses dalam konteksnya dengan tugas, proyek, pool sumber daya, zona dan zona bertanda-identitas, berikutnya akan dipelajari proses dalam konteksnya dengan thread. UNIX sejak dulu sudah mendukung konsep thread. Masing-masing proses memiliki setidaknya satu thread, sehingga pemograman dengan banyak proses berarti pemograman dengan banyak thread. Tetapi, proses juga memerlukan area alamat memori, sehingga penciptaan sebuah proses berarti juga melibatkan penciptaan sebuah area alamat memori baru. Komunikasi antar thread dalam satu proses merupakan komunikasi yang sederhana karena semua thread berbagi banyak hal, termasuk area alamat memori dan deskriptor file terbuka yang sama. Sehingga data yang dihasilkan oleh satu thread dengan segera tersedia untuk diakses oleh thread yang lain. File librari yang tersedia untuk permograman banyak-thread (Multithreading) yaitu libpthread untuk thread POSIX dan libthread untuk thread OpenSolaris. Pemograman banyak-thread menyediakan fleksibilitas dengan memisahkan sumber daya di tingkat-kernel dengan sumber daya di tingkat-pengguna. Di OpenSolaris, pemograman banyak-thread mendukung himpunan antarmuka yang disediakan oleh librari C standar. Gunakan fungsi pthread_create(3C) untuk menambahkan thread pengontrol baru kedalam sebuah proses. int pthread_create(pthread_t *tid, const pthread_attr_t *tattr, void*(*start_routine)(void *), void *arg);

Fungsi pthread_create() dipanggil dengan attr yang telah memiliki kondisi status yang diperlukan. Fungsi start_routine merupakan fungsi yang berfungsi Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

96


untuk memacu sebuah thread baru untuk memulai eksekusi. Ketika fungsi start_routine selesai dipanggil, thread tersebut keluar dengan status keluaran yang ditentukan oleh nilai-balik yang dikembalikan oleh fungsi start_routine.


97


Fungsi pthread_create() menghasilkan nilai-balik nol jika panggilan fungsi tersebut berhasil diselesaikan tanpa kesalahan. Nilai-balik selain nol menandakan adanya kesalahan. Lihat informasi yang tersedia di /on/usr/src/lib/libc/spec/threads.spec dengan OpenGrok untuk mendapat daftar lengkap fungsi-fungsi pthread dan cara deklarasinya. Sinkronisasi thread diperlukan untuk mengontrol aliran program dan akses ke data yang digunakan secara bersamaan oleh beberapa thread yang sedang dieksekusi. Ada empat metode sinkronisasi obyek yaitu penguncian mutex, penguncian baca/tulis, variabel kondisi, and penghitungan tanda bendera.  Penguncian mutex (Mutex locks) mengizinkan hanya satu thread pada saat tertentu mengeksekusi area kode tertentu atau mengakses data tertentu.  Penguncian baca/tulis (Read/write locks) mengizinkan pembacaan data secara bersamaan tetapi penulisan data diberikan secara eksklusif terhadap sumber daya terproteksi yang digunakan secara bersama. Agar dapat melakukan penulisan data, sebuah thread harus mendapatkan dulu pengunci penulisan eksklusif. Pengunci penulisan eksklusif tidak akan diberikan lagi sampai semua kunci pembacaan telah dilepaskan oleh thread yang lain.  Variabel kondisi (Condition variables) memblokir thread hingga kondisi tertentu memiliki nila benar.  Penghintungan tanda bendera (Counting semaphores) biasanya digunakan untuk mengkoordinasikan akses sebuah sumber daya. Penghitungan tanda bendera akan menentukan batas berapa banyak thread dapat memiliki akses ke sebuah tanda bendera. Ketika limit penghitungan tercapai; thread lain yang mencoba mengakses sumber daya akan diblokir.


98


Sinkronisasi Obyek sinkronisasi merupakan variabel didalam memori yang dapat diakses datanya. Thread yang berasal dari proses yang berbeda dapat saling berkomu-nikasi melalui obyek sinkronisasi yang tersimpan didalam memori-bersama yang terkontrol oleh masing-masing thread. Thread dapat saling berkomunikasi meskipun sebenarnya thread yang berasal dari proses yang berbeda secara umum tidak saling terlihat. Obyek sinkroniasi juga dapat disimpan dalam file. Obyek sinkronisasi dapat memiliki waktu hidup yang lebih lama daripada waktu hidup penciptaan proses. Gunakan OpenGrok untuk menemukan kode pemograman libthread dan informasi penting lain didalam mutex.c, perhatikan juga informasi berikut yang diambil dari sebagian komentar sebuah kode pemogramman: Implementation of all threads interfaces between ld.so.1 and libthread. In a non-threaded environment all thread interfaces are vectored to noops. When called via _ld_concurrency() from libthread these vectors are reassigned to real threads interfaces. Two models are supported: TI_VERSION == 1 Under this model libthread provides rw_rwlock/rw_unlock, through which we vector all rt_mutex_lock/rt_mutex_unlock calls. Under lib/libthread these interfaces provided _sigon/_sigoff (unlike lwp/libthread that provided signal blocking via bind_guard/bind_clear. TI_VERSION == 2 Under this model only libthreads bind_guard/bind_clear and thr_self interfaces are used. Both libthreads block signals under the bind_guard/bind_clear interfaces. Lower level locking is derived from internally bound _lwp_ interfaces. This removes recursive problems encountered when obtaining locking interfaces from libthread. The use of mutexes over reader/writer locks also enables the use of Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

99

Manajemen Proses dan Sistem condition variables for controlling thread concurrency (allows access to objects only after their .init has completed).

Setelah memahami bagaimana obyek sinkronisasi didefinisikan dalam pemograman banyak-thread, berikutnya dijelaskan bagaimana obyek-obyek ini diatur dengan kelas-kelas penjadwalan.


100


Penjadwalan CPU Proses dieksekusi didalam sebuah kelas penjadwalan tertentu yang masing-masing memiliki kebijakan penjadwalan yang berbeda, seperit dijelaskan berikut ini:  Realtime (RT) – Kelas penjadwalan dengan prioritas tertinggi yang menyediakan kebijakan penjadwalan untuk proses yang memerlukan tanggapan cepat dan pengontrolan prioritas penjadwalan secara mutlak oleh pengguna atau aplikasi. Penjadwalan RT dapat diberikan kepada seluruh proses atau kepada satu atau lebih lightweight processes (LWPs) dari sebuah proses. Diperlukan hak istimewa proc_priocntl untuk dapat menggunakan kelas Realtime. Informasi lebih lanjut dapat diperoleh di manual privileges (5).  System (SYS) – Kelas penjadwlan dengan prioritas menengah, kelas ini tidak dapat diberikan kepada proses pengguna.  Timeshare (TS) – Kelas penjadwalan dengan prioritas terendah dan menjadi kelas standar untuk proses pengguna. Kebijakan TS adalah mendistribusikan sumber daya CPU secara merata diantara proses-proses dengan karakteristik konsumsi CPU yang berbeda. Proses-proses lain milik Kernel dapat memonopoli prosesor dalam jangka waktu yang singkat tanpa menyebabkan penurunan waktu-tanggap yang dirasakan oleh pengguna.  Inter-Active (IA) – Kebijakan IA adalah selain mendistribusikan sumber daya CPU secara merata diantara proses-proses dengan karakteristik konsumsi CPU yang berbeda tetapi juga menyediakan waktu-tanggap yang baik untuk berinteraksi dengan pengguna.  Fair Share (FSS) – Kebijakan FSS adalah Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

101


mendistribusikan sumber daya CPU secara merata diantara beberapa proyek, tidak tergantung jumlah proses yang dimiliki proyek bersangkutan. Setiap proyek mendapatkan besar presentase tertentu untuk mengontrol hak pemanfaatan sumber daya CPU. Besarnya pemanfaatan sumber daya CPU selalu dicatat setiap waktu, sehingga jatah hak pemanfaatannya semakin dikurangi untuk proyek yang dengan pemakaian CPU besar dan akan ditambahkankan untuk proyek dengan pemakaian CPU kecil.


102


 Fixed-Priority (FX) – Kebijakan FX menyediakan penjadwalan preemptive dengan prioritas tetap bagi proses yang memerlukan prioritas penjadwalan yang tidak secara dinamis disesuaikan oleh sistem dan pengguna atau aplikasi yang bisa mengontrol sendiri prioritas penjadwalannya. Kelas ini dapat digunakan untuk memulai pengubahan kebijakan pengalokasian CPU. Kelas penjadwalan diberikan kepada masing-masing LWP. Setiap thread mendapatkan kelas penjadwalan dan prioritas dari LWP dimana thread tersebut berasal. Masing-masing LWP dalam sebuah proses dapat memiliki kelas penjadwalan dan prioritas unik yang diperlakukan berbeda oleh kernel. Prioritas thread akan menentukan persaingan untuk mendapatkan obyek sinkronisasi. Kelas penjadwalan RT dan TS keduanya memanggil fungsi priocntl(2) untuk menentukan tingkat prioritas sebuah proses atau LWP dalam sebuah proses. Gunakan OpenGrok mencari dasar kode pemograman fungsi priocntl, dari file rtsched.c dapat diketahui variabelvariabel yang digunakan oleh kelas penjadwalan RT and TS sebagai berikut: 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

#pragma ident "@(#)rtsched.c 1.10 05/06/08 SMI" #include #include #include #include #include #include #include #include

"lint.h" "thr_uberdata.h" <sched.h> <sys/priocntl.h> <sys/rtpriocntl.h> <sys/tspriocntl.h> <sys/rt.h> <sys/ts.h>

/* * The following variables are used for caching information * for priocntl TS and RT scheduling classs. */ struct pcclass ts_class, rt_class;


103

Manajemen Proses dan Sistem 44 45 46 47 48 49 50

static static static static static static static

rtdpent_t *rt_dptbl; /* RT class parameter table */ int rt_rrmin; int rt_rrmax; int rt_fifomin; int rt_fifomax; int rt_othermin; int rt_othermax;

Dengan mengetikan perintah man priocntl di sebuah jendela terminal, diperlihatkan rincian informasi yang berhubungan dengan masing-masing kelas penjadwalan, atribut, dan pemakaiannya. % man priocntl Reformatting page. Please Wait... done User Commands

priocntl(1)

NAME priocntl - display or set scheduling parameters of specified process(es) SYNOPSIS priocntl -l priocntl -d [-i idtype] [idlist] priocntl -s [-c class] [ class-specific options] [-i idtype] [idlist] priocntl -e [-c class] [ class-specific options] command [argument(s)] DESCRIPTION The priocntl command displays or sets scheduling parameters of the specified process(es). It can also be used to display the current configuration information for the system’s process scheduler or execute a command with specified scheduling parameters. Processes fall into distinct classes with a separate scheduling policy applied to each class. The process classes currently supported are the real-time class, time-sharing class, interactive class, fair-share class, and the fixed priority class. The characteristics of these classes and the classspecific options they accept are described below in the USAGE section under the headings Real-Time Class, Time- Sharing Class, Inter-Active Class, Fair-Share Class, and --More--(4%)


104


Tinjauan Umum Kernel Setelah memiliki pemahaman di tingkat-atas tentang proses, thread dan penjadwalan, berikutnya akan disajikan penjelasan tentang kernel dan bagaimana modul kernel berbeda dengan program pengguna. Kernel Solaris berperan melakukan hal-hal berikut:  Manajemen sumber daya sistem, termasuk diantaranya sistem file, proses dan perangkat keras.  Menyediakan layanan sistem kepada aplikasi seperti manajemen I/O, memori virtual dan penjadwalan.  Mengkoordinasikan interaksi antara proses pengguna dan sumber daya sistem.  Memberikan prioritas, melayani permintaan atas sumber daya, melayani interupsi perangkat keras dan eksepsi.  Menjadwalkan dan mengganti thread, area memori dan men-swap proses.  Pada bagian berikut ini dijelaskan beberapa perbedaan penting antara modul kernel dan program pengguna.


105


Perbedaan Antara Eksekusi Modul Kernel dan Program Pengguna Berikut adalah karakteristik-karakteristik modul kernel yang membedakannya dengan program pengguna pada saat dieksekusi:  Modul kernel memiliki area alamat memori yang terpisah. Sebuah modul berjalan di area kernel. Aplikasi berjalan di area pengguna. Perangkat lunak sistem diproteksi dari program pengguna. Area kernel dan area pengguna masing-masing memiliki area alamat memori sendiri.  Modul kernel memiliki hak eksekusi lebih tinggi. Kode pemograman yang berjalan di area kernel memiliki lebih banyak hak istimewa daripada kode pemograman yang berjalan di area kernel.  Modul kernel tidak dieksekusi secara berurutan. Program pengguna biasanya dieksekusi secara berurutan dan melakukan satu tugas tunggal sejak awal hingga berhenti. Modul kernel tidak dieksekusi secara berurutan. Modul kernel mendaftarkan diri sebagai komponen kernel agar bisa melayani permintaan layanan yang akan datang.  Modul kernel dapat diinterupsi. Bebarapa proses dapat secara bersamaan mengirimkan permintaan kepada sebuah modul kernel. Contohnya, sebuah program kernel bertugas menangani interupsi bisa saja mengirimkan permintaan kepada sebuah modul kernel yang sedang melayani panggilan sistem pada saat yang sama. Didalam sistem berprosesor-banyak simetrik (Symmetric Multiprocessor, SMP), sebuah modul kernel dapat dieksekusi secara bersamaan oleh beberapa CPU.


106


 Modul kernel harus bersifat preemptive. Meskipun sebuah program penggerak tidak dapat memblokir sebuah modul kernel, ini tidak berarti kernel modul ini aman. Rancanglah sebuah program penggerak dengan asumsi bahwa kernel modul yang bersangkutan bersifat preemptive.  Modul kernel dapat berbagi data. Thread yang berbeda dari sebuah program aplikasi tidak perlu untuk berbagi data. Berlawanan dengan struktur data dan kode pemograman rutin sebagai komponen program penggerak yang digunakan secara bersamaan oleh semua thread yang ada dalam program penggereak tersebut. Sebuah program penggerak harus dapat menangani masalah perebutan sumber daya sebagai akibat permintaan yang banyak. Rancanglah struktur data program penggerak dengan penuh pertimbangan untuk menjaga agar beberapa thread tetap dieksekusi secara terpisah.


107


Perbedaan Struktural antara Modul Kernel Modules dan Program Pengguna Berikut adalah karakteristik-karakteristik struktur modul kernel yang membedakannya dengan struktur program pengguna:  Modul kernel tidak mendefinisikan program utama. Modul kernel, termasuk program penggerak perangkat tidak memiliki fungsi rutin utama main(). Sebaliknya, modul kernel merupakan kumpulan fungsi sub-rutin dan data.  Modul kernel hanya di-link ke komponen librari kernel. Modul kernel tidak di-link ke librari yang digunakan oleh program pengguna. Kernel module hanya bisa memanggil fungsi-fungsi yang telah dieksport oleh kernel.  Modul kernel menggunakan file header yang berbeda. Modul kernel memerlukan himpunan file header yang berbeda dengan file header yang diperlukan oleh program pengguna. Daftar file header yang diperlukan dapat dilihat di halaman manual masing-masing fungsi. Modul kernel bisa saja mengikutkan file header yang digunakan bersama oleh program pengguna jika antarmuka antara kode di area user dan area kernel didalam header file tersebut didefinisikan secara kondisional dengan makro _KERNEL.  Modul kernel sebaiknya menghindari pemakaian variabel global. Penghindaran variabel global didalam kernel modul jauh lebih penting dibandingkan penghindaran variabel global didalam program pengguna. Sebisa mungkin, deklarasikan simbol sebagai statik. Ketika penggunaan simbol global tidak dapat dihindari, tambahkan prefix ke nama simbol global tersebut agar unik didalam kernel. Penggunan prefix untuk simbol private dalam modul juga merupakan kebiasaan yang baik. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

108


 Modul kernel dapat dibuat berdasarkan kebutuhan spesifik perangkat keras. Modul kernel dapat menggunakn register proses secara khusus hanya untuk melakukan fungsi yang specifik. Modul kernel dapat dioptimalisasikan untuk jenis prosesor tertentu. Librari juga dapat dibuat berdasarkan kebutuhan spesifik tertentu, seperti di OpenSolaris memiliki librari untuk sistem x86/ x64 and UltraSPARC. Jadi, jika kernel dapat menggunakan register untuk fungsi tertentu maka kode pemograman dapat dibuat sesuai kebutuhan kernel dan pengguna/librari.  Modul kernel dapat dimuatkan dan dibongkarmuatkan sesuai permintaan. Kumpulan fungsi sub-rutin dan data yang merupakan bagian program penggerak perangkat dapat dikompilasi menjadi sebuah kode obyek dari sebuah module tunggal yang dapat dimuatkan. Modul ini berikutnya dapat secara dinamis atau statik di-link kedalam kernel dan di-unlink dari kernel. Penambahan fungsi baru kedalam kernel dapat dilakukan pada saat kernel aktif dan berjalan. Pengujian versi terbaru sebuah program penggerak dapat dilakukan tanpa me-reboot sistem.


109


Men-debug Proses Men-debug proses pada semua tingkat dari tahap pengembangannya merupakan bagian kunci dari pembuatan modul kernel. Pencarian kode pemograman libthread dengan OpenGrok, mengarahkan kita ke file mdb_tdb.c yang menjelaskan hubungan antara multi-threaded debugging dan bagaimana mdb bekerja: In order to properly debug multi-threaded programs, the proc target must be able to query and modify information such as a thread’s register set using either the native LWP services provided by libproc (if the process is not linked with libthread), or using the services provided by libthread_db (if the process is linked with libthread). Additionally, a process may begin life as a single-threaded process and then later dlopen() libthread, so we must be prepared to switch modes on-the-fly. There are also two possible libthread implementations (one in /usr/lib and one in /usr/lib/lwp) so we cannot link mdb against libthread_db directly; instead, we must dlopen the appropriate libthread_db on-the-fly based on which libthread.so the victim process has open. Finally, mdb is designed so that multiple targets can be active simultaneously, so we could even have *both* libthread_db’s open at the same time. This might happen if you were looking at two multi-threaded user processes inside of a crash dump, one using /usr/lib/libthread.so and the other using /usr/lib/lwp/libthread.so. To meet these requirements, we implement a libthread_db "cache" in this file. The proc target calls mdb_tdb_load() with the pathname of a libthread_db to load, and if it is not already open, we dlopen() it, look up the symbols we need to reference, and fill in an ops vector which we return to the caller. Once an object is loaded, we don’t bother unloading it unless the entire cache is explicitly flushed. This mechanism also has the nice property that we don’t bother loading libthread_db until we need it, so the debugger starts up faster.


110


Perintah-perintah mdb berikut dapat digunakan untuk mengakses LWP dari sebuah progarm dengan banyakthread:  $l Menampilkan LWP ID dari thread representatif jika targetnya adalah proses pengguna.  $L Menampilan LWP ID dari masin-masing LWP didalam target jika targetnya adalah proses pengguna.  pid::attach Melekatkan ke sebuah proses dengan menggunakan ID prosesnya, pid  ::release Melepaskan proses atau file core yang sebelumnya dilekatkan. Proses masih dapat melanjutkan eksekusinya dengan menggunakan prun(1) atau MDB atau pen-debug yang lain.  address::context Melakukan context switch terhadap proses yang ditentukan. Perintah ini menetapkan conditional breakpoints yang seringkali berguna.  [ addr ] ::bp [+/-dDestT] [-c cmd] [-n count] sym ... Menentukan breakpoint pada lokasi tertentu.  addr ::delete [id | all] Menghapus event specifiers dengan nomor ID tertentu Probe DTrace juga dikonstruksikan dengan cara yang sama seperti MDB. Pada halaman berikutnya terdapat latihan lab menggunakan DTrace kemudian MDB ketika men-debug semakin sulit dan kompleks.


111

7 M

O

D

U

L

Memulai Penggunaan DTrace Tujuan Tujuan dari latihan lab ini adalah untuk memperkenalkan DTrace dengan menggunakan skrip probe untuk sebuah system call dengan DTrace.

Sumber Bacaan Lain  Solaris Dynamic Tracing Guide. SunMicrosystems, Inc., 2007.  DTrace User Guide, SunMicrosystems, Inc., 2006


112

Mengaktifkan Probe DTrace Sederhana

Mengaktifkan Probe DTrace Sederhana Setelah menyelesaikan latihan-latihan di modul ini diharapkan peserta memiliki pemahaman dasar tentang probe-probe didalam DTrace.

Ringkasan Pembelajaran DTrace dimulai dengan membuat permintaan yang sangat sederhana yaitu menggunakan probe yang bernama BEGIN; probe ini akan terpicu (aktif) satu kali setiap ada permintaan merunut baru. Kita dapat menggunakan opsi –n dari perintah dtrace(1M) untuk mengaktifkan sebuah probe dengan menggunakan nama string-nya.


113


Mengaktifkan Sederhana

Probe DTrace

1.Buka jendela terminal 2.Mengaktifkan sebuah probe: # dtrace -n BEGIN

Setelah jeda beberapa saat, dapat disaksikan dtrace menyatakan bahwa sebuah probe diaktifkan dan sebaris informasi keluaran muncul mengindikasi probe BEGIN sudah dipicu. Setelah muncul keluaran ini, dtrace tetap menunggu probe yang lain untuk memicu. Karena kita tidak akan mengaktifkan probe yang lain dan probe BEGIN cukup hanya diaktifkan satu kali, tekan Control-C untuk keluar dari dtrace dan kembali ke prompt shell: 3.Kembali ke shell prompt dengan menekan Control-C: # dtrace -n BEGIN dtrace: description ’BEGIN’ matched 1 probe CPU ID FUNCTION:NAME 0 1 :BEGIN ^C #

Keluaran ini menjelaskan bahwa probe bernama BEGIN dipicu satu kali dan baik nama dan nomor ID, 1 ditampilkan. Perhatikan bahwa berdasarkan standar, nomor CPU dimana probe dipicu yang akan ditampilkan. Dalam contoh ini, kolom CPU mengindikasinya bahwa perintah dtrace dieksekusi pada CPU 0 ketika probenya dipicu. Permintaan DTrace dapat dikonstruksi dengan menggunakan berapapun jumlah probe dan aksi. Berikutnya, buat lagi sebuah permintaan sederhana menggunakan dua probe yaitu dengan penambahan probe END pada contoh perintah sebelumnya. Probe END memicu satu kali ketika merunut telah lengkap. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

114


4.Tambahkan probe END: # dtrace -n BEGIN -n END dtrace: description ’BEGIN’ matched 1 probe dtrace: description ’END’ matched 1 probe CPU ID FUNCTION:NAME 0 1 :BEGIN ^C 0 2 :END #

Probe END memicu satu kali ketika merunut telah lengkap. Seperti diperlihatkan, dengan menekan Control-C untuk keluar DTrace akan membangkitkan probe END. DTrace menampilkan informasi bahwa probe ini memicu sebelum keluar.


115

Menampilkan Traceable Probes

Menampilkan Probe Perunut Tujuan dari lab ini adalah untuk mengenal probe lebih jauh dan memperlihatkan bagaimana menampilkan probe yang ada dalam sebuah sistem.

Ringkasan Pada contoh-contoh sebelumnya, telah dipelajari 2 probe sederhana bernama BEGIN dan END. Tetapi darimana kedua probe ini sebenarnya berasal? Probe DTrace berasal dari himpunan modul-modul kernel yang disebut penyedia (provider), dimana masingmasing penyedia melakukan suatu bentuk instrumentasi tertentu untuk membuat probe. Sebagai contoh, penyedia syscall menyediakan probe untuk setiap panggilan system( system call) and the penyedia fbt menyediakan probe untuk setiap fungsi yang ada didalam kernel. Ketika menggunakan DTrace, setiap penyedia diberikan kesempatan untuk mempublikasikan setiap probe yang ada yang di kerangka kerja DTrace. Berikutnya setiap probe yang telah dipublikasikan dapat diaktifkan dan dilekatkan aksi perunut.


116


Menampilkan Probe Perunut 1.Buka jendela terminal. 2.Ketikan perintah berikut.: # dtrace

Opsi-opsi yang ada perintah dtrace ditampilkan. 3.Ketikan perintah dtrace dengan opsi –l : # dtrace -l | more ID PROVIDER 1 dtrace 2 dtrace 3 dtrace 4 lockstat acquire 5 lockstat block 6 lockstat 7 lockstat release --More--

MODULE

FUNCTION

genunix

mutex_enter

NAME BEGIN END ERROR adaptive-

genunix

mutex_enter

adaptive-

genunix genunix

mutex_enter mutex_exit

adaptive-spin adaptive-

Probe-probe yang tersedia di sistem ditampilkan dalam lima kolom informasi sebagai berikut:  ID – Nomor urut identifikasi internal dari probe yang ditampilkan  Provider – Nama Penyedia. Penyedia digunakan untuk mengklasifikasikan probe. Ini juga digunakan sebagai metode instrumentasinya.  Module – Nama modul Unix atau librari aplikasi dari probe yang bersangkutan  Function – Nama fungsi dimana sebuah probe berasal.  Name – Nama probe


117


4.Gunakan simbol pipa untuk meneruskan keluaran dari perintah sebelumnya kedalam perintah wc untuk menghitung jumlah total probe yang ada di sistem: # dtrace -l | wc -l 30122

Jumlah probe yang diketahui oleh sistem ditampilkan sebagai keluarannya. Jumlah ini bisa berbeda tergantung tipe sistemnya. 5.Tambahkan opsi-opsi berikut untum mem-filter tampilannya:  -P untuk penyedia  -m for modul  -f untuk fungsi  -n untuk name Perhatikan contoh-contoh berikut: # dtrace -l -P lockstat ID PROVIDER MODULE 4 lockstat genunix 5 lockstat genunix 6 lockstat genunix 7 lockstat genunix

FUNCTION NAME mutex_enter adaptive-acquire mutex_enter adaptive-block mutex_enter adaptive-spin mutex_exit adaptive-release

Hanya probe-probe yang ada didalam penyedia lockstat yang ditampilkan # dtrace -l -m ufs ID PROVIDER MODULE 15 sysinfo ufs 16 sysinfo ufs 356 fbt ufs

FUNCTION NAME ufs_idle_free ufsinopage ufs_iget_internal ufsiget allocg entry

Hanya probe-probe yang ada di modul UFS yang ditampikan.


118

Menampilkan Traceable Probes # dtrace -l -f open ID PROVIDER MODULE 4 syscall 5 syscall 116 fbt genunix 117 fbt genunix

FUNCTION NAME open entry open return open entry open return

Hanya probe-probe dengan name fungsi open yang ditampilkan. # dtrace -l -n start ID PROVIDER MODULE 506 proc unix 2766 io genunix 2768 io genunix 5909 io nfs

FUNCTION NAME lwp_rtt_initial start default_physio start aphysio start nfs4_bio start

Perintah diatas menampilkan semua probe yang memiliki nama probe start.


119

Pemograman Bahasa D

Pemograman Bahasa D Setelah memiliki sedikit pemahaman tentang penamaan, mengaktifkan dan menampilkan probe, langkah berikutnya diharapkan peserta bisa menuliskan sebuah versi program DTrace sederhana, "Hello, World."

Ringkasan Lab ini mendemonstrasikan bahwa DTrce dapat dituliskan dalam sebuah teks file dengan mengunakan bahasa pemograman D, selain mengkonstruksinya dengan perintah baris.


120

Pemograman Bahasa D

Menuliskan Program DTrace 1.Buka jendela terminal. 2.Gunakat editor teks, buat sebuah file baru bernama hello.d. 3.Ketikan sebuah program D: BEGIN { trace("hello, world"); exit(0); }

4.Simpan file the hello.d. 5.Jalankan program tersebut menggunakan opsi dtrace – s: # dtrace -s hello.d dtrace: script ’hello.d’ matched 1 probe CPU ID FUNCTION:NAME 0 1 :BEGIN hello, world #

Seperti diperlihat diatas, dtrace menampilkan keluaran yang sama seperti sebelumnya kemudian diikuti teks “hello, world”. Tidak seperti contoh sebelumnya, tidak diperlukan waktu untuk menunggu ataupun menekan Control-C. Perubahan ini merupakan efek dari aksi yang dimiliki oleh probe BEGIN didalam hello.d. Di halaman berikut, akan digali lebih dalam struktur program D untuk memahami apa yang sebenarnya terjadi.


121

Pemograman Bahasa D

Diskusi Setiap program D terdiri atas sebuah urutan klausaklausa, masing-masing klausa menggambarkan satu atau lebih probe yang akan diaktifkan, dan sekumpulan aksi opsional yang akan dilakukan ketika probe terpicu. Aksi sendiri ditampilkan sebagai kumpulan urutan pernyataan yang diapit tanda kurung { } setelah nama probe. Setiap pernyataan diakhiri oleh sebuah tanda titik-koma (;). Pernyataan pertama menggunakan fungsi trace() yang menandakan bahwa DTrace seharusnya merekam arguman yang diberikan, string “hello, world”, ketika BEGIN probe terpicu dan menampilkannya ke monitor. Pernyataan kedua menggunakan fungsi exit() untuk menandakan bahwa DTrace seharusnya menghentikan proses merunut dan keluar dari perintah dtrace. DTrace menyediakan sekumpulan fungsi – fungsi yang sangat berguna seperti trace() and exit() untuk digunakan didalam progam D. Untuk memanggil sebuah fungsi, spesifikasikan namanya diikuti oleh argumen-argumennya didalam tanda kurung. Daftar lengkap fungsi-fungsi D dijelaskan dalam Solaris Dynamic Tracing Guide. Sampai disini, mereka yang terbiasa dengan bahasa pemograman C, akan menyadari dari nama fungsi dan contoh-contoh diatas bahwa bahasa pemograman D yang digunakan oleh DTrace sangat mirip dengan C dan awk(1). Pada kenyataannya, bahasa D memang berasal dari sebagian besar sub-bagian bahasa C yang dikombinasikan dengan kumpulan fungsi-fungsi dan variabel khusus sehingga membantu memudahkan proses merunut. Mereka yang sebelumnya pernah membuat program C, akan dengan segera mentransfer sebagian besar pengetahuan tentang C untuk membuat program tracing dalam bahasa D. Untuk mereka yang tidak mengenal Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

122

Pemograman Bahasa D

bahasa C, mempelajari bahasa D tetap sangat mudah. Langkah pertama yang harus dilakukan adalah memahami dengan benar kaidah-kaidahnya dan mempelajari lebih dalam bagaimana DTrace bekerja, kemudian mempelajari bagaimana membuat program D yang lebih menarik .


123

8 M

O

D

U

L

Men-debug Aplikasi dengan DTrace Tujuan Tujuan dari modul ini adalah untuk menggunakan DTrace untum memonitor kejadian-kejadian tertentu dari sebuah aplikasi.

Sumber Bacaan Lain  Application Packaging Developer’s Guide. SunMicrosystems, Inc., 2005.


124

Mengaktifkan Probe Didalam Moda Pengguna

Mengaktifkan Probe Didalam Moda Pengguna DTrace memungkinkan juga untuk secara dinamis menambah probe-probe kedalam fungsi-fungsi di tingkat pengguna. Kode program pengguna tidak perlu untuk dikompilasi-ulang, bendera khusus, atau distart-ulang. Probe-probe DTrace dapat dinyalakan hanya dengan pemanggilan penyedianya. Sebuah deskripsi probe memili kaidah sebagai berikut: pid:mod:function:name

 pid: format

pid processid (contoh pid 5234)

 mod: nama librari atau

a.out (biner tereksekusi)

 function: nama fungsi  name: entry for function entry return for function return


125

Merunut Aplikasi Dengan DTrace

Merunut Aplikasi Dengan DTrace Didalam latihan ini akan dipelajari bagaimana memanfaatkan DTrace untuk merunut sebuah aplikasi.

Ringkasan Lab ini dibuat dengan menggunakan nomor ID proses di dalam deskripsi probe untuk merunut aplikasi tertentu. Langkah-langkahnya semakin kompleks di bagian akhir latihan ini, dengan menambahkan jumlah dan kedalaman informasi dari perilaku aplikasi yang teramati.


126


Merunut gcalctool dengan DTrace 1.Dari menu Application atau Program, jalankan program kalkulator. 2.Temukan nomor ID prosesnya. # pgrep gcalctool 8198

Angka ini adalah nomor ID proses gcalctool, selanjutnya akan disebut procid. 3.Ikuti langkah-langkah berikut untuk membuat skrip D yang akan menghitung berapa kali fungsi-fungsi tertentu di dalam gcalctool dipanggil. a.Dengan editor teks, buat sebuah file bernama proc_func.d. b.Gunakan pid$1:::entry sebagai deskripsi-probe. $1 adalah argumen pertama yang yang diterima oleh skrip, biarkan bagian predikat tetap kosong. c.Dibagian aksi, tambahkan sebuah fungsi pengkumulatif untuk menghitung jumlah total berapa kali fungsi-fungsi tertentu dipanggil dengan menggunakan aggregate statement @[probefunc]=count(). pid$1:::entry { @[probefunc]=count(); }

d.Jalankan skrip yang baru dituliskan tadi. # dtrace -qs proc_func.d procid

Ganti procid dengan nomor ID proses gcalctool


127


e.Lakukan sebuah penghitungan di program kalkulator. f.Tekan Control+C didalam jendela dimana skrip D dijalankan. Catatan – Skrip DTrace mengumpulkan data secara terus menerus hingga diberhentikan dengan menekan Control+C. Jika tidak diperlukan untuk menampilkan jumlah data total yang dikumpulkan, DTrace tetap akan menampilkannya. 4.Sekarang, modifikasi skripnya sehingga hanya menghitung fungsi-fungsi dari librari libc. a. Salin file proc_func.d ke proc_libc.d. b. Modifikasi deskripsi probe didalam file proc_libc.d menjadi seperti berikut: pid$1:libc::entry

c. Skrip barunya akan terlihat seperti ini: pid$1:libc::entry { @[probefunc]=count(); }

5.Sekarang jalankan skripnya # dtrace -qs proc_libc.d procid

Ganti procid dengan nomor ID proses gcalctool a. Lakukan sebuah perhitungan di kalkulator b. Tekan Control+C didalam jendela dimana skrip D dijalankan untuk melihat keluarannya.


128


6.Terakhir, modifikasi skripnya untuk mengetahui berapa lama waktu yang diperlukan oleh masingmasing fungsi. a. Buat sebuah file bernama func_time.d. Gunakan dua deskripsi probe didalam func_time.d. b. Tuliskan probe pertama seperti berikut: pid$1:::entry

c. Tuliskan probe kedua seperti berikut: pid$1:::return

d. Di bagian aksi dari probe pertama, simpan timestamp didalam variabel ts. Timestamp adalah sebuah variable yang secara internal tersedia (built-in) di DTrace dan berfungsi untuk menghitung berapa nanoseconds waktu yang diperlukan dari titik tertentu yang lampau. e. Dibagian aksi dari probe kedua hitung berapa nanosecond waktu total yang terlewati: @[probefunc]=sum(timestamp - ts)

f. Skrip func_time.d akan sama dengan yang berikut ini: pid$1:::entry { ts = timestamp; } pid$1:::return /ts/ { @[probefunc]=sum(timestamp - ts); }


129


7.Jalankan skrip func_time.d: # dtrace -qs func_time.d procid

Ganti procid dengan ID prosesnya gcalctool a. Lakukan perhitungan dengan kalkulator. b. Tekan Control+C di dalam terminal dimana skrip D dijalankan untuk melihat keluaran perintahnya: ^C gdk_xid__equal 2468 _XSetLastRequestRead 2998 _XDeq 3092 ...

Kolom kiri meperlihatkan nama fungsi dan kolom kanan memperlihatkan on waktu yang diperlukan untuk fungsi tersebut. Satuan waktunya adalah nano seconds.


130

9 M

O

D

U

L

Men-debug Aplikasi C++ dengan DTrace Tujuan Contoh-contoh yang terdapat dalam modul ini mendemonstrasikan pemanfaatan DTrace untuk mendiagnosa kesalahan-kesalahan pada aplikasi C++. Contoh-contoh ini juga digunakan untuk membandingkan DTrace dengan peranti pen-debug aplikasi yang lain, termasuk perangkat lunak Sun Studio 10 dan mdb.


131

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C+ + Sebuah program sampel CCtest dibuat untuk mendemostrasikan sebuah kesalahan yang lazim terjadi di aplikasi C++ yaitu ketidakcukupan memori. Dalam banyak hal, ketidakcukupan memori terjadi ketika sebuah obyek dibuat tetapi tidak pernah dimusnahkan, dan kasus seperti ini yang ada didalam sampel program di modul ini. Ketika men-debug sebuah program C++ program, perhatikan bahwa kompiler mengkonversi beberapa nama dalam C++ menjadi kumpulan karakter dan bilangan yang kompleks dan agak susah dipahami. Nama-nama yang kompleks ini merupakan sebuah rincian implementasi yang diperlukan untuk mendukung C++ pemuatan-berlebih (overloading) fungsi, untuk menyediakan nama eksternal yang berlaku untuk nama fungsi C++ yang terdiri karakter-karakter khusus, dan untuk membedakan fungsi dan variabel dengan nama yang sama dideklarasikan di ruang nama dan kelas yang berbeda. Contohnya, gunakan nm untuk mengekstraksi tabel simbol dari sebuah sampel program yang bernama CCtest menampikan keluaran sebagai berikut: # /usr/ccs/bin/nm ... [61] | 134549248| [85] | 134549301| [76] | 134549136| [62] | 134549173| [64] | 134549136| [89] | 134549173| [80] | 134616000| [91] | 134549348|

CCtest 53|FUNC 47|FUNC 37|FUNC 71|FUNC 37|FUNC 71|FUNC 16|OBJT 16|FUNC

|GLOB |GLOB |GLOB |GLOB |GLOB |GLOB |GLOB |GLOB

|0 |0 |0 |0 |0 |0 |0 |0

|9 |__1cJTestClass2T5B6M_v_ |9 |__1cJTestClass2T6M_v_ |9 |__1cJTestClass2t5B6M_v_ |9 |__1cJTestClass2t5B6Mpc_v_ |9 |__1cJTestClass2t6M_v_ |9 |__1cJTestClass2t6Mpc_v_ |18 |__1cJTestClassG__vtbl_ |9 |


132

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++ __1cJTestClassJClassName6kM_pc_ ...


133


Catatan – Kode pemograman dan makefile untuk CCtest tersedia di halaman akhir modul ini. Dari keluaran ini, dapat diasumsikan bahwa sejumlah simbol-simbol acak yang muncul ketika mendebug berhubungan dengan sebuah bernama TestClass, tetapi tidak dapat ditentukan apakah simbol-simbol ini berhubungan dengan konstruktor, destruktor, or fungsi-fungsi kelas. Kompiler Sun Studio memasukan piranti berikut, yang dapat digunakan untuk menerjemahkan simbo-simbol acak ini menjadi simbol-simbol C++ pasangannya, yaitu: nm -C, dem, dan c++ filt. Catatan – Perangkat lunak Sun Studio 10 digunakan disini, tetapi contoh-contoh dalam modul ini juga telah ditest oleh Sun Studio 9 and 10. Jika aplikasi C++ dikompilasi dengan gcc/g++, terdapat pilihan piranti lain untuk menerjemahkan symbol-simbol acak dari sebuah aplikasi yang dikenali baik oleh Sun Studio dan nama-nama simbol GNU, yaitu: gc++filt yang tersedia di /usr/sfw/bin dapat digunakan untuk menerjemahkan simbol-simbol yang terdapat didalam aplikasi g++. Contoh: Simbol-simbol Sun Studio tanpa c++filt: # nm [65] [56] [92] ...

CCtest | grep TestClass | 134549280| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t6M_v_ | 134549352| 54|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mi_v_ | 134549317| 35|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mpc_v_

Simbol-simbol Sun Studio dengan c++filt: # nm CCtest | grep TestClass | c++filt [65]|134549280| 37|FUNC |GLOB |0 |9 |TestClass::TestClass() Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

134

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++ [56]|134549352| 54|FUNC |GLOB |0 |9 |TestClass::TestClass(int) [92]|134549317| 35|FUNC |GLOB |0 |9 |TestClass::TestClass(char*) ...


135


simbol-simbol g++ tanpa gc++filt: [86] | 134550070| 41|FUNC |GLOB |0 |12 |_ZN9TestClassC1EPc [110] | 134550180| 68|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ei [114] | 134549984| 43|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ev ...

simbol-simbol g++ dengan gc++filt: # nm gCCtest | grep TestClass | gc++filt [86] |134550070|41|FUNC|GLOB |0 |12|TestClass::TestClass(char*) [110]|134550180|68|FUNC|GLOB |0 |12|TestClass::TestClass(int) [114]|134549984|43|FUNC|GLOB |0 |12|TestClass::TestClass() ...

Dan akhirnya, dengan nm –C untuk menampilkan simbolsimbol: [64]|134549344|71|FUNC|GLOB|0|9|TestClass::TestClass() [__1cJTestClass2t6M_v_] [87]|134549424|70|FUNC|GLOB|0|9|TestClass::TestClass(const char*) [__1cJTestClass2t6Mpkc_v_] [57]|134549504|95|FUNC|GLOB|0|9|TestClass::TestClass(int) [__1cJTestClass2t6Mi_v_]

Berdasarkan informasi-informasi ini bisa dibuatkan skrip DTrace untuk melakukan pengumpulan informasi (aggregation) terhadap panggilan-panggilan obyek yang terkait dengan test program kita. Kita dapat menggunakan penyedia pid DTrace untuk mengaktifkan probe-probe yang berkaitan dengan simbol-simbol C+ +. Untuk membuktikan teori konstruktor/destruktor, kita mulai dengan menghitung hal-hal berikut:  Jumlah obyek yang dibuat -- jumlah panggilan ke fungsi new()  Jumlah obyek yang dimusnahkan – jumlah pnggilan ke fungsi delete() Dengan menggunakan perintah dibawah ini, kita bisa mengekstrak simbol-simbol yang berkaitan dengan fungsi new() and delete() dari program CCtest: Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

136

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++ # dem ‘nm CCtest | awk -F\| ’{ print $NF; }’‘ | egrep "new| delete" __1c2k6Fpv_v_ == void operator delete(void*) __1c2n6FI_pv_ == void*operator new(unsigned)


137


Skrip DTrace dengan kegunaan yang sama dapat digunakan untuk mengaktifkan probe terhadap fungsi new() dan delete(), skripnya bernama CCagg.d: #!/usr/sbin/dtrace -s pid$1::__1c2n6FI_pv_: { @n[probefunc] = count(); } pid$1::__1c2k6Fpv_v_: { @d[probefunc] = count(); } END { printa(@n); printa(@d); }

Jalankan program CCtest didalam sebuah jendela, kemudian eksekusi skrip CCagg.d di jendela yang lain seperti diperlihatkan berikut ini: # dtrace -s ./CCagg.d ‘pgrep CCtest‘ | c++filt

Keluaran DTrace diteruskan dan menjadi masukan bagi c++filt untuk diterjemahkan menjadi simbol-simbol C+ +, tetapi gunakan perintah ini dengan hati-hati seperti tertulis dalam peringatan berikut ini. Perhatian – Jangan gunakan ^C untuk keluar dari perintah DTrace seperti yang biasa dilakukan karena hal ini menyebabkan c++filt ikut berhenti bersama dengan DTrace sehingga tidak ada keluaran yang ditampilkan.


138


Untuk menampilkan keluaran perintah ini, buka jendela baru dan ketikan perintah: # pkill dtrace

Gunakan urutan langkah-langkah berikut sebagai lanjutan latihan ini: Jendela 1: # ./CCtest

Jendela 2: # dtrace -s scriptname | c++filt

Jendela 3: # pkill dtrace

Keluaran di jendela 2 menampilkan jumlah total panggilan terhadap fungsi new() dan delete() seperti berikut ini: void*operator new(unsigned) 12 void operator delete(void*) 8

Dari pengamatan keluaran diatas, terlihat memang benar dugaan bahwa lebih banyak obyek-obyek yang dibuat daripada yang dihapus. Berikutnya adalah memeriksa alamat memori obyek tersebut dan dan mencoba untuk mencocokannya dengan setiap keberadaan fungsi new() and delete(). Variabel argumen DTrace digunakan untuk menampilkan setiap alamat yang berkaitan dengan obyek. Karena sebuah pointer ke obyek tertentu terdapat didalam nilai balik fungsi new(), seharusnya akan terdapat nilai pointer yang sama sebagai arg0 dalam panggilan terhadap fungsi delete().


139


Dengan sedikit modifikasi pada skrip sebelumnya, jadilah sebuah skrip baru bernama CCaddr.d: #!/usr/sbin/dtrace -s #pragma D option quiet /* __1c2k6Fpv_v_ == void operator delete(void*) __1c2n6FI_pv_ == void*operator new(unsigned) */ /* return from new() */ pid$1::__1c2n6FI_pv_:return { printf("%s: %x\n", probefunc, arg1); } /* call to delete() */ pid$1::__1c2k6Fpv_v_:entry { printf("%s: %x\n", probefunc, arg0); }

Eksekusi skrip ini: # dtrace -s ./CCaddr.d ‘pgrep CCtest‘ | c++filt

Tunggu sejenak, kemudian ketikan perintah berikut didalam jendela 3: # pkill dtrace

Keluarannya memperlihatkan sebuah pola berulang berikut, sebanyak tiga panggilan terhadap fungsi new() dan dua panggilan terhadap fungsi delete(): void*operator void*operator void*operator void operator void operator

new(unsigned): new(unsigned): new(unsigned): delete(void*): delete(void*):

809e480 8068a70 809e4a0 8068a70 809e4a0

Dari hasil pengamatan terhadap keluaran yang berulang ini, sebuah pola menarik muncul. Terlihat bahwa setiap panggilan pertama terhadap fungsi new() tidak memiliki panggilan delete() yang terkaitnya. Disini sekarang sumber penyebab ketidakcukupan memori dapat teridentifikasi!


140


Dengan melanjutkan pengamatan menggunakan DTrace, informasi lain masih dapat diperoleh. Dengan memodifikasi skrip sebelumnya, dapat diketahui tipe kelas yang berkaitan dengan obyek yang dibuat di alamat 809e480 dan panggilan terhadap ustack() untuk fungsi new(). Skrip hasil modifikasi ini bernama CCstack.d: #!/usr/sbin/dtrace -s #pragma D option quiet /* __1c2k6Fpv_v_ == void operator delete(void*) __1c2n6FI_pv_ == void*operator new(unsigned) */ pid$1::__1c2n6FI_pv_:entry { ustack(); } pid$1::__1c2n6FI_pv_:return { printf("%s: %x\n", probefunc, arg1); } pid$1::__1c2k6Fpv_v_:entry { printf("%s: %x\n", probefunc, arg0); }

Eksekusi CCstack.d di jendela 2, kemudian ketikan pkill dtrace di jendela 3 untuk menampilkan keluaran berikut: # dtrace -s ./CCstack.d ‘pgrep CCtest‘ | c++filt libCrun.so.1‘void*operator new(unsigned) CCtest‘main+0x19 CCtest‘0x8050cda void*operator new(unsigned): 80a2bd0 libCrun.so.1‘void*operator new(unsigned) CCtest‘main+0x57 CCtest‘0x8050cda void*operator new(unsigned): 8068a70 libCrun.so.1‘void*operator new(unsigned) CCtest‘main+0x9a CCtest‘0x8050cda void*operator new(unsigned): 80a2bf0 Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

141

Menggunakan DTrace Untuk Men-debug dan Membuat Profil Sebuah Program C++ void operator delete(void*): 8068a70 void operator delete(void*): 80a2bf0


142


Berdasarkan data dari fungsi ustack() diperoleh informasi bahwa fungsi new() dipanggil dari main+0x19, main+0x57, dan main+0x9a. Pengamatan berikutnya lebih ditujukan pada obyek yang berkaitan dengan panggilan pertama terhadap fungsi new() di main+0x19. Untuk menentukan tipe konstruktor yang dipanggil di main+0x19, manfaatkan mdb seperti berikut ini: # gcore ‘pgrep CCtest‘ gcore: core.1478 dumped # mdb core.1478 Loading modules: [ libc.so.1 ld.so.1 ] > main::dis main: pushl %ebp main+1: movl %esp,%ebp main+3: subl $0x38,%esp main+6: movl %esp,-0x2c(%ebp) main+9: movl %ebx,-0x30(%ebp) main+0xc: movl %esi,-0x34(%ebp) main+0xf: movl %edi,-0x38(%ebp) main+0x12: pushl $0x8 main+0x14: call -0x2e4 main+0x19: addl $0x4,%esp main+0x1c: movl %eax,-0x10(%ebp) main+0x1f: movl -0x10(%ebp),%eax main+0x22: pushl %eax main+0x23: call +0x1d5 <__1cJTestClass2t5B6M_v_> ...

Sebuah konstruktor dipanggil setelah panggilan terhadap fungsi new(), di alamat main+0x23. Panggilan ini teridentifikasi sebagai panggilan terhadap konstruktor __1cJTestClass2t5B6M_v_ dan panggilan ini tidak pernah dimusnahkan. Manfaatkan dem untuk menerjemahkan simbol ini: # dem __1cJTestClass2t5B6M_v_ __1cJTestClass2t5B6M_v_ == TestClass::TestClass #Nvariant 1()

Dapat disimpulkan bahwa panggilan terhadap TestClass() baru di main+0x19 adalah penyebab terjadinya kekurangcukupan memori. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

143


Pengamatan terhadap file kode pemograman CCtest.cc memperlihatkan: ... t = new TestClass(); cout << t->ClassName(); t = new TestClass((const char *)"Hello."); cout << t->ClassName(); tt = new TestClass((const char *)"Goodbye."); cout << tt->ClassName(); delete(t); delete(tt); ...

Jelas terlihat bahwa pemakaian pertama kali variabel t = new TestClass(); ditulis-ulangkan oleh pemakain kedua: t = new TestClass((const char *)"Hello.");. Ketidakcukupan memori telah teridentifikasi dan perbaikan bisa diimplementasikan. Penyedia pid DTrace pid memungkinkan pengaktifan probe terhadap sembarang instruksi yang berkaitan dengan sebuah proses yang akan diamati. Contoh ini ditujukan untuk membuat sebuah model pendekatan DTrace untuk secara interaktif men-debug proses. Fitur-fitur DTrace yang digunakan dalam contoh ini meliputi: pengumpulan informasi (aggregations), menampilkan argumen-arguman fungsi dan nilai balik dan mengamati tumpukan panggilan pengguna (user call stack). Penggunaan perintah c++filt dari perangkat lunak Sun Studio dan gc++filt dari gcc adalah untuk mengekstrak probe-probe fungsi dari tabel simbol sebuah program dan menampilkan keluaran DTrace dalam format yang sesuai dengan kode pemogramannya.


144


File-file kode pemograman yang dibuat untuk contoh ini adalah sebagai berikut: CONTOH 9–1

TestClass.h

class TestClass { public: TestClass(); TestClass(const char *name); TestClass(int i); virtual ~TestClass(); virtual char *ClassName() const; private: char *str; }; TestClass.cc: #include <stdio.h> #include <string.h> #include <stdlib.h> #include #include "TestClass.h" TestClass::TestClass() { str=strdup("empty."); } TestClass::TestClass(const char *name) { str=strdup(name); } TestClass::TestClass(int i) { str=(char *)malloc(128); sprintf(str, "Integer = %d", i); } TestClass::~TestClass() { if ( str ) free(str); } char *TestClass::ClassName() const { return str; }


145


CONTOH 9–2

CCtest.cc

#include #include <stdio.h> #include <stdlib.h> #include #include "TestClass.h" int main(int argc, char **argv) { TestClass *t; TestClass *tt; while (1) { t = new TestClass(); cout << t->ClassName(); t = new TestClass((const char *)"Hello."); cout << t->ClassName(); tt = new TestClass((const char *)"Goodbye."); cout << tt->ClassName(); delete(t); delete(tt); sleep(1); } }

CONTOH 9–3

Makefile

OBJS=CCtest.o TestClass.o PROGS=CCtest CC=CC all: $(PROGS) echo "Done." clean: rm $(OBJS) $(PROGS) CCtest: $(OBJS) $(CC) -o CCtest $(OBJS) .cc.o: $(CC) $(CFLAGS) -c $<


146

1 M

O

D

U

L

Manajemen Memori dengan DTrace dan MDB Tujuan Didalam module ini akan dibahas bagaimana kita dapat menyusun kembali pengetahuan yang telah diperoleh tentang pengamatan proses dengan DTrace untuk melakukan pengujian kegagalan halaman memori (page fault). Kemudian pengujian ini diteruskan dengan menggunakan MDB. MDB merupakan piranti pendebug tingkat-dasar yang memungkinkan untuk pencarian kesalahan hingga ke tingkat kode pemogramannya.

Sumber Bacaan Lain

 SolarisModular Debugger Guide SunMicrosystems, Inc., 2007.


147

Perangkat Lunak Untuk Manajemen Memori

Perangkat lunak Untuk Manajemen Memori Manajemen memori di OpenSolaris menggunakan suatu konstruksi perangkat lunak yang disebut segmen untuk menangani memori virtual sebuah proses juga kernel. Sebagian besar struktur data yang digunakan oleh perangkat lunak manajemen memori ini didefinisikan di /usr/include/vm/*.h. Di dalam modul ini, akan dipelajari kode pemograman dan struktur data yang digunakan untuk menangani kegagalan halaman memori.


148

Pengujian Memori Virtual dengan DTrace dan MDB

Pengujian Memori Virtual dengan DTrace dan MDB Tujuan dari lab ini adalah untuk menguji kegagalan halaman memori dengan menggunakan DTrace dan MDB.

Ringkasan Pertama, skrip DTrace digunakan untuk merunut aksiaksi dari sebuah kegagalan halaman memori tunggal untuk sebuah proses. Skrip ini menampilkan alamat memori virtual yang menyebabkan suatu kegagalan, dan kemudian merunut setiap fungsi yang dipanggil terhitung dari waktu kegagalan halaman memori terjadi hingga program kernel yang berfungsi menangani kegagalan virtual memori (fault handler) kembali. Dari pengamatan terhadap keluaran skrip ini dapat ditentukan bagian mana dari sumber kode pemograman yang harus diperiksa lebih lanjut. Catatan- Didalam modul ini, telah ditambahkan teks informasi keterangan dari keluaran skrip DTrace, yang sebagian besar berupa kode-kode, untuk membimbing latihan ini. Perhatikan simbol <---untuk menemukan teks keterangan yang terkait dengan keluaran tersebut.


149


Pengujian Kegagalan Halaman Memori Dari Sebuah Proses Dengan DTrace 1.Buka sebuah jendela terminal 2.Buatlah sebuah skrip DTrace bernama pagefault.d seperti berikut ini: #!/usr/sbin/dtrace -s #pragma D option flowindent pagefault:entry /execname == $$1/ { printf("fault occurred on address = %p\n", args[0]); self->in = 1; } pagefault:return /self->in == 1/ { self->in = 0; exit(0); } entry /self->in == 1/ { } return /self->in == 1/ { }

3.Jalan skrip ini dengan Mozilla sebagai argumennya. Catatan – File yang dieksekusi untuk menjalankan Mozilla adalah mozilla-bin bukan mozilla. Pernyataan dengan penekanan tertentu juga digunakan untuk menampilkan berbagai macam panggilan, sebagai contoh adalah panggilan terhadap mutex_owner(), dengan menggunakan ASSERT().Pernyataan dengan penekanan tertentu hanya digunakan untuk men-debug kernel.


150

Pengujian Memori Virtual dengan DTrace dan MDB # ./pagefault.d mozilla-bin dtrace: script ’./pagefault.d’ matched 42626 probes CPU FUNCTION 0 -> pagefault

fault occurred on address = fb985ea2

0 | pagefault:entry

<-- i86pc/vm/vm_machdep.c

atau 0 -> as_fault

sun4/vm/vm_dep.c <-- generic address

space fault common/vm/vm_as.c 0 0

-> as_segat -> avl_find

<-- segmen ada di struktur

AVL 0

-> as_segcompar

<-- pencarian terhadap

segment 0

<- as_segcompar

<-- yang mengandung

alamat yang gagal 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

-> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar -> as_segcompar <- as_segcompar <- avl_find <- as_segat

0

-> segvn_fault

<-- common/vm/vm_as.c

<-- segmen yang mengandung kegagalan ditemukan, (bukan SEGV) <-- common/vm/seg_vn.c


151

Pengujian Memori Virtual dengan DTrace dan MDB 0

-> hat_probe

<-- pencarian isian di table

halaman

0

-> htable_getpage

untuk halaman tersebut <-- i86pc/vm/hat_i86.c or sfmmu/vm/hat_sfmmu.c <-- table halaman di-hash di

x86 0 0 0 0 0 0

-> -> <-> <->

htable_getpte htable_lookup htable_lookup htable_va2entry htable_va2entry x86pte_get

<-- i86pc/vm/htable.c

<-- mengembalikan isian table

halaman 0 0 0 0 0 0 0 0 0 0 0 0

-> x86pte_access_pagetable -> hat_kpm_pfn2va <- hat_kpm_pfn2va <- x86pte_access_pagetable -> x86pte_release_pagetable <- x86pte_release_pagetable <- x86pte_get <- htable_getpte <- htable_getpage -> htable_release <- htable_release <- hat_probe


152

Pengujian Memori Virtual dengan DTrace dan MDB 0 -> fop_getpage

<-- operasi file untuk mengisi

halaman memori 0

<-- file ada di ufs fs(common/fs/ufs/ufs_vnops.

-> ufs_getpage

c) 0

<-- memeriksa sparse

-> bmap_has_holes

file 0

<- bmap_has_holes

0

-> page_lookup

<-- memeriksa apakah halaman sudah ada di memori -> page_lookup_create <-- common/vm/vm_page.c <- page_lookup_create <-- buat halaman jika

0 0

perlu 0

<- page_lookup

0

-> ufs_getpage_miss

<-- halaman tidak ada di

memori 0

<-- dapatkan nomor

-> bmap_read

blok untuk halaman tersebut dari inode 0 0 0 0 0

-> bread_common -> getblk_common <- getblk_common <- bread_common <- bmap_read

0

-> pvn_read_kluster

0

-> page_create_va

<-- membaca halaman (common/vm/vm_pvn.c) <-- buat beberapa

halaman 0 0 0 0

<-> <<-

page_create_va segvn_kluster segvn_kluster pvn_read_kluster

0

-> pageio_setup

<-- siapkan halaman

untuk operasi i/ocommon/ os/bio.c Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

153


<- pageio_setup


154


-> lufs_read_strategy <-- pembacaan ufs di-log

0

-> bdev_strategy

0

-> cmdkstrategy

<-- baca perangkat common/os/driver.c <-- common disk driver (cmdk(7D)) <-common/io/dktp/disk/cmdk.c

0

-> dadk_strategy

<-- direct attached disk (dad(7D)) <-- untuk ide disks (common/io/dktp/dcdev/dadk.c) <-- driver mempersiapkan dma dan memulai page in 0 0 0

<- dadk_strategy <- cmdkstrategy <- bdev_strategy

0

-> biowait

0

-> sema_p

0

-> swtch

<-- tunggu pagein selesai common/os/bio.c <-- bangunkan sema_v setelah interupsi selesai <-- biarkan thread lain

jalan 0

-> disp

(common/disp/disp.c) <-- jadwalkan thread

berikutnya untuk dijalankan 0 0

<- disp -> resume

<-- switching sebenarnya

terjadi disini 0 0

0

-> savectx <- savectx

-> restorectx

<-- intel/ia32/ml/swtch.s <-- simpan konteks yang lama <-- thread yang lain berjalan disini <-- kembalikan kontext


155


(thread dibangunakan) 0 0 0 0 0

<- restorectx <- resume <- swtch <- sema_p <- biowait


156

Pengujian Memori Virtual dengan DTrace dan MDB 0 0 0 0 0

-> pageio_done <- pageio_done -> pvn_plist_init <- pvn_plist_init <- ufs_getpage_miss

<-- batalkan pageio_setup

<-- halaman sekarang ada di

memori 0 0 0

<- ufs_getpage <- fop_getpage -> segvn_faultpage

<-- panggil hat untuk

memuat pte(s) bagi halaman bersangkutan 0 0

-> hat_memload -> page_pptonum

<-- dapatkan nomor frame

halaman 0 0

<- page_pptonum -> hati_mkpte

<-- buat isian di table

halaman 0 0

<- hati_mkpte -> hati_pte_map

0 0 0 0

-> <-> <-

0

-> x86pte_set

<-- tentukan lokasi isian di table halaman

x86_hm_enter x86_hm_enter hment_prepare hment_prepare

<-- isi pte ke table

halaman 0 0 0 0 0 0 0

-> x86pte_access_pagetable -> hat_kpm_pfn2va <- hat_kpm_pfn2va <- x86pte_access_pagetable -> x86pte_release_pagetable <- x86pte_release_pagetable <- x86pte_set

0 -> hment_assign 0 <- hment_assign 0 -> x86_hm_exit 0 <- x86_hm_exit 0 <- hati_pte_map 0 <- hat_memload 0 <- segvn_faultpage 0 <- segvn_fault 0 <- as_fault 0 <- pagefault Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

157

Pengujian Memori Virtual dengan DTrace dan MDB #


158


Perhatikan bahwa keluaran diatas sebenarnya sudah diperpendek untuk kemudahan pemahaman. Pada tingkat atas, ketika terjadi kegagalan halaman memori hal-hal berikut akan terjadi:  Rutin pagefault() dipanggil untuk menangani kegagalan halaman memori s.  Rutin pagefault() memanggil as_fault() untuk menangani kegagalan pada sebuah alamat memori  Rutin as_fault() menyusuri susunan AVL dari struktur seg untuk melakukan pencarian segmen dengan alamat yang salah. Jika tidak ditemukan segmen seperti ini, proses yang bersangkutan akan mengirimkan sebuah sinyal SIGSEGV (segmentation violation).  Jika segmen dengan alamat yang salah ditemukan, sebuah program kernel fault handler yang spesifik segmen dipanggil. Nama fault handler ini adalah segvn_fault() yang digunakan oleh sebagian besar segmen.  segvn_fault() mencari apakah lokasi memori yang salah telah dipakai sebelumnya oleh proses yang bersangkutan. Jika data dilokasi memori tersebut masih ada (tetapi sudah dinyatakan bebas oleh pemindai halaman memori - memori page scanner), lokasi tersebut akan “diklaim ulang” sehingga dikeluarkan daftar lokasi yang bebas. Jika lokasi di memori beserta datanya sudah tidak ditemukan lagi maka akan dipanggil ufs_getpage().  ufs_getpage() berusaha menemukan nomor blok didalam sistem file dari data yang semula ada di lokasi memori dengan memanggil bmap_read().  Selanjutnya dipanggil rutin strategi program penggerak perangkat untuk menentukan rutin Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

159


strategi apa yang akan dilakukan, lihat lebih lanjut dimanual strategy(9E).  Selama lokasi memori sedang dibaca, thread yang menyebabkan kegagalan halaman memori blocks akan di-switch out melalui panggilan swtch(). Ini memberi kesempatan thread yang lain untuk aktif.


160


 Ketika paging I/O telah lengkap, interrupt handler dari penggerak disk akan membangunkan thread mozilla-bin yang semula terblok.  Program penggerak disk kembali melalui kode sistem file kepada segvn_fault().  segvn_fault() kemudian memanggil segvn_faultpage().  segvn_faultpage() memanggil lapisan HAT (Hardware Address Translation) untuk mengisi page table entry(s) (PTE)s dari lokasi memori tadi.  Sampai disini, alamat memori virtual yang menyebabkan kegagalan halaman memori sekarang sudah dipetakan kembali dengan lokasi fisik memori yang benar. Ketika pagefault() kembali, instruksi-instruksi yang semula menyebabkan kegagalan halaman memori akan dijalankan ulang dan seharusnya akan diselesaikan dengan benar. 4.Memanfaatkan mdb untuk mengamati struktur data kernel dan menentukan lokasi memori fisik yang berhubungan dengan terjadinya kegagalan halaman memori di memori virtual: a.Bukan jendela terminal b.Hitung banyaknya segmen yang digunakan oleh mozilla menggunakan perintah pmap seperti berikut ini: # pmap -x ‘pgrep mozilla-bin‘ | wc 368 2730 23105 #

Keluarannya memperlihatkan terdapat 368 segmen. Catatan – Dari pencarian terhadap segmen yang mengandung kegagalan alamat memori ditemukan segmen-segmen yang benar setelah 8 segmen. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

161


Perhatikan panggilan ke as_segcompar dari keluaran DTrace diatas. Terbukti, penggunaan struktur AVL dapat mempersingkat pencarian!


162


c.Gunakan mdb untuk menemukan lokasi segmen dengan fault address. Catatan – Jika diinginkan untuk menyimpan setiap aktivitas didalam mdb, gunakan perintah: ::log /tmp/logfile diikuti oleh perintah !vi /tmp/logfile untuk memulai menyimpannya. Jika tidak, jalankan jalankan saja mdb didalam penyangga editor.

# mdb -k Loading modules: [ unix krtld genunix specfs dtrace ufs ip sctp usba random fctl s1394 nca lofs crypto nfs audiosup sppp cpc fcip ptm ipc ] > ::ps !grep mozilla-bin

<-- temukan proses mozilla-

bin R 933 919 887 885 100 0x42014000 ffffffff81d6a040 mozilla-bin

> ffffffff81d6a040::print proc_t p_as | ::walk seg | ::print struct seg

<-- Beberapa informasi keluaran dihilangkan … --> { s_base = 0xfb800000

s_size = 0x561000

<-- segment yang dicari, alamat yang gagal (fb985ea2) <-- lebih besar/sama

dengan terhadap base dan base+size

and <

s_szc = 0 s_flags = 0 s_as = 0xffffffff828b61d0 s_tree = { avl_child = [ 0xffffffff82fa7920, 0xffffffff82fa7c80 ] avl_pcb = 0xffffffff82fa796d } s_ops = segvn_ops Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

163

Pengujian Memori Virtual dengan DTrace dan MDB s_data = 0xffffffff82d85070 }

<-- dan banyak informasi keluaran dihilangkan lagi -->


164

Pengujian Memori Virtual dengan DTrace dan MDB > ffffffff82d85070::print segvn_data_t

<-- berasal dari s_data

{ _

_

lock = { opaque = [ 0 ] } segp_slock = { opaque = [ 0 ] } pageprot = 0x1 prot = 0xd maxprot = 0xf type = 0x2 offset = 0 vp = 0xffffffff82f9e480 anon_index = 0 amp = 0

<-- menunjuk ke sebuah vnode_t <-- kita akan

melihatnya lagi kemudian di area anonymous vpage = 0xffffffff82552000 cred = 0xffffffff81f95018 swresv = 0 advice = 0 pageadvice = 0x1 flags = 0x490 softlockcnt = 0 policy_info = { mem_policy = 0x1 mem_reserved = 0 } }


165

Pengujian Memori Virtual dengan DTrace dan MDB > ffffffff82f9e480::print vnode_t v_path v_path = 0xffffffff82f71090 "/usr/sfw/lib/mozilla/components/libgklayout.so"

> fb985ea2-fb800000=K 185ea2

<-- alamat didalam segmen <-- nilai pembulatannya

adalah 185000 (ukuran page 4k) > ffffffff82f9e480::walk page !wc

<-- menelusuri daftar

page 1236 1236 21012

pada vnode_t <-- 1236 halaman

memori, (tidak perlu semuanya benar)


166

Pengujian Memori Virtual dengan DTrace dan MDB > ffffffff82f9e480::walk page | ::print page_t

<-- menyusuri daftar pg list pada vnode

<-- banyak informasi keluaran dihilangkan --> { p_offset = 0x185000 <-- disini halaman memori yang

bersesuaiannya p_vnode = 0xffffffff82f9e480 p_selock = 0 p_selockpad = 0 p_hash = 0xfffffffffae21c00 p_vpnext = 0xfffffffffaca9760 p_vpprev = 0xfffffffffb3467f8 p_next = 0xfffffffffad8f800 p_prev = 0xfffffffffad8f800 p_lckcnt = 0 p_cowcnt = 0 p_cv = { opaque = 0 } p_io_cv = { opaque = 0 } p_iolock_state = 0 p_szc = 0 p_fsdata = 0 p_state = 0 p_nrm = 0x2 p_embed = 0x1 p_index = 0 p_toxic = 0 p_mapping = 0xffffffff82d265f0 p_pagenum = 0xbd62

<-- nomor frame

halaman dari sebuah halaman memori p_share = 0 p_sharepad = 0 p_msresv_1 = 0 p_mlentry = 0x185 p_msresv_2 = 0 } Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

167


<-- banyak informasi keluaran dihilangkan -->


168


<-- perkalian antara nomor

> bd62*1000=K

frame halaman dengan ukuran halaman (hex) <-- disini adalah alamat fisik

bd62000

dari h alaman yang bersangkutan > bd62000+ea2,10/K

<-- menampilkan nilai 16 64-bit

hex di alamat fisik 0xbd62ea2:

2ccec81ec8b55 e8575653f0e48300 32c3815b00000000 5d89d46589003ea7 840ff6850c758be0 e445c7000007df 1216e8000000 dbe850e4458d5650 7d830cc483ffeeea 791840f00e4 c085e8458904468b 500c498b088b2474 8b17eb04c483d1ff e8458de05d8bd465 c483ffeeeac8e850 458b0000074ce904

> bd62000+ea2,10/ai

<-- data terlihat seperti

kode, tampilkan sebagai kode 0xbd62ea2: 0xbd62ea2: 0xbd62ea3: 0xbd62ea5: 0xbd62eab: 0xbd62eae: 0xbd62eaf: 0xbd62eb0: 0xbd62eb1: 0xbd62eb6: 0xbd62eb7: 0xbd62ebd: 0xbd62ec0: 0xbd62ec3: 0xbd62ec6: 0xbd62ec8: 0xbd62ece:

pushq movl subl andl pushq pushq pushq call popq addl movl movl movl testl je movl

%rbp %esp,%ebp $0x2cc,%esp $0xfffffff0,%esp %rbx %rsi %rdi +0x5 <0xbd62eb6> %rbx $0x3ea732,%ebx %esp,-0x2c(%rbp) %ebx,-0x20(%rbp) 0xc(%rbp),%esi %esi,%esi +0x7e5 <0xbd636ad> $0x0,-0x1c(%rbp)


169


<-- merubah kontext dari kernel ke mozilla-bin kontext debugger ditentukan menjadi proc ffffffff81d6a040, alamat proses

> ffffffff81d6a040::context

<-- dan tampilkan isi dari alamat virtual yang gagal

> fb985ea2,10/ai

0xfb985ea2: 0xfb985ea2: 0xfb985ea3: 0xfb985ea5: 0xfb985eab: 0xfb985eae: 0xfb985eaf: 0xfb985eb0: 0xfb985eb1: 0xfb985eb6: 0xfb985eb7: 0xfb985ebd: 0xfb985ec0: 0xfb985ec3: 0xfb985ec6: 0xfb985ec8: 0xfb985ece:

pushq movl subl andl pushq pushq pushq % call popq addl movl movl movl testl je movl

%rbp <-- sepertinya sesuai %esp,%ebp $0x2cc,%esp $0xfffffff0,%esp %rbx %rsi rdi +0x5 <0xfb985eb6> %rbx $0x3ea732,%ebx %esp,-0x2c(%rbp) %ebx,-0x20(%rbp) 0xc(%rbp),%esi %esi,%esi +0x7e5 <0xfb9866ad> $0x0,-0x1c(%rbp)

> 0::context debugger context set to kernel

> ffffffff81d6a040::print proc_t p_as <-- dapatkan sebagai

for mozilla-bin p_as = 0xffffffff828b61d0 > fb985ea2::vtop -a ffffffff828b61d0

<-- periksa yang telah kita lakukan

virtual fb985ea2 mapped to physical bd62ea2 <--alamat fisk Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

170


sesuai


171


Begitu segmen yang mengalami kegagalan ditemukan, isi struktur data segvn_data langsung ditampilkan. Didalam segmen ini, sebuah vnode_t memetakan data segmennya. Dilanjutkan dengan pencarian lokasi halaman memori yang berhubungan dengan alamat didalam segmen tersebut. Begitu lokasi page_t ditemukan, sebuah nomor frame halaman diperoleh. Kemudian nomor page frame dikonversikan menjadi sebuah alamat fisik diikuti dengan pengujian beberapa data di alamat fisik tersebut. Berikutnya mengeluarkan data ini sebagai kode. Terakhir melakukan pengecekan terhadap alamat fisik dengan perintah mdb bernama vtop (virtual-to-physical). d.Keuntungan tambahan: dengan menyusuri table page dari suatu proses dapat dilihat bagaimana sebuah alamat virtual diterjemahkan ke alamat fisiknya.


172

1 M

O

D

U

L

Men-debug Program Penggerak Perangkat Dengan DTrace Tujuan Tujuan dari modul ini adalah untuk mempelajari bagaimana menggunakan DTrace untuk men-debug proyek pengembangan program penggerak perangkat tertentu dengan menggunakan sebuah studi kasus.


173

Membuat Program Penggerak smbfs dari Linux ke Solaris OS

Memindahkan Program Penggerak smbfs Dari Linux Ke Solaris OS Studi kasus ini memfokuskan pada pemakaian secara optimal kemampuan DTrace unutk membantu pengembangan program penggerak perangkat. Jauh sebelum ada DTrace, untuk men-debug program penggerak perangkat seorang pengembang menggunakan panggilan fungsi seperti cmn_err() yang akan me-log informasi diagnosa ke file /var/adm/messages. Proses yang merepotkan ini bersifat spekulatif, memerlukan kompilasi ulang dan reboot sistem untuk menemukan kesalahan kode pemograman sebuah perangkat lunak. Pengembang dengan bakat bahasa assembler-nya dapat menggunakan adb dan membuat modul mdb yang diperlukan dalam bahasa C untuk mendiagnosa kesalahan perangkat lunak. Namun, pendekatan lama untuk pengembangan dan men-debug kernel seperti ini menghabiskan waktu yang cukup lama. DTrace menyediakan sebuah cara diagnosa yang praktis. Daripada melakukan penulusuran file /var/adm/messages atau informasi keluaran perintah truss, DTrace dapat digunakan untuk menangkap informasi hanya untuk kejadian tertentu yang ingin diamati oleh pengembang. Seberapa besar manfaat yang bisa diperoleh dari penggunaan DTrace bisa dibuktikan melalui beberapa contoh yang sederhana berikut. Program penggerak yang digunakan sebagai materi studi kasus dalam modul ini adalah program penggerak smbfs yang telah dibuat berdasarkan model program penggerak nfs milik Sun. Diasumsikan program penggerak telah berhasil dikompilasi, langkah berikutnya adalah melakukan pengujian apakah program penggerak tersebut bisa dimuat dan Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

174


dibongkar-muat secara benar. Hal pertama yang harus dilakukan adalah menyalin program penggerak tersebut ke /usr/kernel/fs dan cobalah memuatnya secara manual dengan perintah modload: # modload /usr/kernel/fs/smbfs can’t load module: Out of memory or no room in system tables


175


Dan di dalam file /var/adm/messages terdapat informasi: genunix: [ID 104096 kern.warning] WARNING: system call missing from bind file

Setelah pencarian informasi lebih lanjut dari pesan kesalahan “system call missing”, disimpulkan bahwa pesan kesalahan ini muncul karena fungsi mod_getsysent() didalam file modconf.c gagal memanggil fungsi mod_getsysnum. Daripada secara manual mengikuti alur program dari fungsi mod_getsysnum() dari satu file kode pemograman ke file kode pemograman yang lain, skrip DTrace yang sederhana berikut ini digunakan untuk mengaktifkan semua informasi dan kejadian balik dari penyedia fbt (Function Boundary Tracing) setiap kali mod_getsynum() dipanggil. #!/usr/sbin/dtrace -s #pragma D option flowindent fbt::mod_getsysnum:entry /execname == "modload"/ { self->follow = 1; } fbt::mod_getsysnum:return { self->follow = 0; trace(arg1); } fbt:::entry /self->follow/ { } fbt:::return /self->follow/ { trace(arg1); }

Catatan – trace(arg1) menampilkan nilai balik dari sebuah fungsi tertentu. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

176


Dengan mengeksekusi skrip ini dan menjalankan perintah modload di jendela yang lain diperoleh keluaran sebagai berikut: # ./mod_getsysnum.d dtrace: script ’./mod_getsysnum.d’ matched 35750 probes CPU FUNCTION 0 -> mod_getsysnum 0 -> find_mbind 0 -> nm_hash 0 <- nm_hash 41 0 -> strcmp 0 <- strcmp 4294967295 0 -> strcmp 0 <- strcmp 7 0 <- find_mbind 0 0 <- mod_getsysnum 4294967295

Dengan melihat nilai balik fungsi find_mbind() yaitu '0' atau nm_hash() yaitu '41' mengarahkan kita pada sumber masalahnya. Nilai balik 0 dari fungsi find_mbind() mengindikasikan adanya status kesalahan. Dengan melihat kode pemograman fungsi find_mbind() didalam file /usr/src/uts/common/os/modsubr.c, terungkap bahwa fungsi tersebut melakukan pencarian string char dalam sebuah tabel hash. Berikutnya DTrace dimanfaatkan untuk menampilkan isi string yang dicari dan isi tabel hash-nya. Agar dapat menampilkan isi dari string yang dicari tersebut ditambahkan pernyataan strcmp() kedalam skrip mod_getsysnum.d yang terdahulu: fbt::strcmp:entry { printf("name:%s, hash:%s", stringof(arg0), stringof(arg1)); }


177


Berikut adalah hasil keluarannya setelah dicoba lagi untuk memuat program penggerak smbfs: # ./mod_getsysnum.d dtrace: script ’./mod_getsysnum.d’ matched 35751 probes CPU FUNCTION 0 -> mod_getsysnum 0 -> find_mbind 0 -> nm_hash 0 <- nm_hash 41 0 -> strcmp 0 | strcmp:entry name:smbfs, hash:timer_getoverrun 0 <- strcmp 4294967295 0 -> strcmp 0 | strcmp:entry name:smbfs, hash:lwp_sema_post 0 <- strcmp 7 0 <- find_mbind 0 0 <- mod_getsysnum 4294967295

Jelas terlihat bahwa string yang dicari dalam tabel hash adalah smbfs dan string ini tidak ada dalam tabel. Bagaimana caranya memasukan string smbfs ini kedalam tabel hash? Kembali lagi ke fungsi find_mbind() untuk melanjutkan pengamatan dalam kode pemogramannya, ditemukan sebuah variabel bername sb_hashtab milik tabel hash diteruskan ke fungsi nm_hash() yang juga mengalami kegagalan. Variabel sb_hashtab ternyata diinisialisasi dengan sebuah panggilan terhadap fungsi read_binding_file() dimana fungsi ini memiliki argumen berupa sebuah file konfigurasi, tabel hashnya sendiri dan sebuah pointer fungsi. Berikutnya terungkap bahwa isi konfigurasi file yang didefinisikan itu berasal dari file /etc/name_to_sysnum di file /usr/src/uts/common/os/modctl.c. Dari sini dapat disimpulkan bahwa kegagalan memuat program penggerak tersebut disebabkan karena kelalaian untuk menambahkan konfigurasi program penggerak baru di dalam file /etc/name_to_sysnum. Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

178


Berikutnya tambahkan isian baru di file /etc/name_to_sysnum seperti berikut ini dan kemudian lakukan reboot. ’smbfs

177’

Catatan - Fungsi read_binding_file() hanya membaca sekali saja file konfigurasi tersebut pada saat boot. Setelah proses reboot selesai program penggerak smbfs berhasil dimuatkan. # modload /usr/kernel/fs/smbfs

Periksa lagi apakah program penggerak tersebut telah dimuat dengan perintah modinfo: # modinfo | grep smbfs 160 feb21a58 351ac 177 1 smbfs (SMBFS syscall,client,comm) 160 feb21a58 351ac 24 1 smbfs (network filesystem) 160 feb21a58 351ac 25 1 smbfs (network filesystem version 2) 160 feb21a58 351ac 26 1 smbfs (network filesystem version 3)

Catatan – Diingatkan kembali bahwa program penggerak ini dibuat dengan meniru model program penggerak nfs, ini menjelaskan mengapa keluarannya menjadi seperti diatas. Lanjutkan, dengan mencoba untuk membongkat-muat modul tersebut: # modunload -i 160 can’t unload the module: Device busy

Nampaknya kesalahan ini disebabkan oleh adanya nilai balik errno EBUSY. Pengamatan menjadi lebih mudah karena program penggerak smbfs adalah sebuah modul yang telah termuat sehingga semua fungsi smbfs dapat diakses: # dtrace -l fbt:smbfs:: | wc -l 1002


179


Ini luar biasa! Tanpa menggunakan kode pemograman khusus sebanyak 1002 fungsi dan kejadian balik dalam sebuah program penggerak dapat diakses. Dengan memanfaatkan akses fungsi sebanyak 1002 ini pekerjaan men-debug program penggerak dapat dilakukan tanpa memerlukan versi 'kode terinstrumentasi' khusus! Dengan menggunakan skrip DTrace sederhana berikut ini, pengamatan terhadap semua panggilan smbfs ketika perintah modunload dijalankan dapat dilakukan: #!/usr/sbin/dtrace -s #pragma D option flowindent fbt:smbfs::entry { } fbt:smbfs::return { trace(arg1); }

Nampaknya kode-kode smbfs tidak dapat diakses oleh modunload. Berikutnya, gunakan skrip DTrace berikut ini untuk pengamatan terhadap modunload: #!/usr/sbin/dtrace -s #pragma D option flowindent fbt::modunload:entry { self->follow = 1; trace(execname); trace(arg0); } fbt::modunload:return { self->follow = 0; trace(arg1); } fbt:::entry /self->follow/ { } fbt:::return /self->follow/ Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

180

Membuat Program Penggerak smbfs dari Linux ke Solaris OS { trace(arg1); }


181


Keluaran skrip ini adalah sebagai berikut: # ./modunload.d dtrace: script ’./modunload.d’ matched 36695 probes CPU FUNCTION 0 -> modunload modunload 160 0 | modunload:entry 0 -> mod_hold_by_id 0 -> mod_circdep 0 <- mod_circdep 0 0 -> mod_hold_by_modctl 0 <- mod_hold_by_modctl 0 0 <- mod_hold_by_id 3602566648 0 -> moduninstall 0 <- moduninstall 16 0 -> mod_release_mod 0 -> mod_release 0 <- mod_release 3602566648 0 <- mod_release_mod 3602566648 0 <- modunload 16

Perhatikan bahwa nilai balik EBUSY sebesar '16' ini berasal dari moduninstall. Dengan melihat sumber kode pemograman untuk moduninstall ditemukan bahwa moduninstall memberikan nilai balik EBUSY di beberapa lokasi. Beberapa kemungkinan lokasi yang ada adalah: 1. if (mp->mod_prim || mp->mod_ref || mp->mod_nenabled != 0) return (EBUSY); 2. if ( detach_driver(mp->mod_modname) != 0 ) return (EBUSY); 3. if ( kobj_lookup(mp->mod_mp, "_fini") == NULL ) 4. A failed call to smbfs _fini() routine


182


Akses langsung ke semua kemungkinan lokasi ini tidak dapat dilakukan, tetapi pendekatan terhadap lokasi-lokasi ini dapat dilakukan dengan sebuah proses pengeliminasian. Dengan skrip berikut ini dapat ditampilkan isi dari berbagai struktur dan nilai balik didalam moduninstall: #!/usr/sbin/dtrace -s #pragma D option flowindent fbt::moduninstall:entry { self->follow = 1; printf("mod_prim:%d\n", ((struct modctl *)arg0)->mod_prim); printf("mod_ref:%d\n", ((struct modctl *)arg0)->mod_ref); printf("mod_nenabled:%d\n", ((struct modctl *)arg0)->mod_nenabled); printf("mod_loadflags:%d\n", ((struct modctl *)arg0)->mod_loadflags); } fbt::moduninstall:return { self->follow = 0; trace(arg1); } fbt::kobj_lookup:entry /self->follow/ { } fbt::kobj_lookup:return /self->follow/ { trace(arg1); } fbt::detach_driver:entry /self->follow/ { } fbt::detach_driver:return /self->follow/ { trace(arg1); }


183


Skrip ini menghasilkan keluaran seperti berikut ini: # ./moduninstall.d dtrace: script ’./moduninstall.d’ matched 6 probes CPU FUNCTION 0 -> moduninstall mod_prim:0 mod_ref:0 mod_nenabled:0 mod_loadflags:1 0 -> detach_driver 0 <- detach_driver 0 0 -> kobj_lookup 0 <- kobj_lookup 4273103456 0 <- moduninstall 16

Dengan membandingkan keluaran ini terhadap kode pemogramannya diperoleh fakta bahwa kegagalan tersebut bukan disebabkan oleh nilai struktur mp ataupun nilai balik yang berasal dari detach_driver() milik kobj_lookup(). Akibatnya, dengan proses pengeliminasian, harus ada status tertentu dikembalikan melalui pangggilan status = (*func)(); dimana panggilan ini berikutnya akan memanggil rutin smbfs _fini(). Berikut ini adalah isi dari rutin smbfs _fini(): int _fini(void) { /* don’t allow module to be unloaded */ return (EBUSY); }

Pengubahan nilai balik menjadi ‘0’ dan mengkompilasi ulang sumber kode pemogramanany akan menghasilkan sebuah program penggerak yang dapat dimuatkan dan dibongkar-muatkan secara dinamis, sehingga secara keseluruhan tujuan latihan ini telah tercapai. Dalam contoh-contoh ini secara khusus banyak digunakan penyedia Function Boundary Tracing. Dengan catatan bahwa fbt hanyalah salah Pengantar Sistem Operasi: Sebuah Pendekatan Praktis dengan Menggunakan Proyek OpenSolaris – Agustus 2007

184


satu dari sekian banyak penyedia DTrace.


185

A

AA A

P

P

E

N

D

I

X

Sumber Bacaan Tambahan OpenSolaris Untuk mendapat informasi lebih lanjut, dukungan dan training manfaatkan situs-situs berikut ini:  Dokumentasi Komunitas —http://opensolaris.org/os/ community/documentation  Dokumentasi Sun — http://www.sun.com/documentation  Dukungan Sun — http://www.sun.com/support  Pelatihan Sun — Sun menawarkan berbagai pelatihan Solaris profesional dengan cakupan yang lengkap dan pilihan sertifikasi untuk membantu anda mengaplikasi platform yang bertenaga ini demi kesuksekan yang lebih besar kegiatan anda. Untuk mendapat informasi lebih lanjut tentang pelatihan Solaris, kunjungi situs ini: http://www.sun.com/training/catalog/operating_sys tems/index.xml


186

Pengantar Sistem Operasi: Sebuah Pendekatan Praktis Dengan Menggunakan Proyek OpenSolaris Buku Pedoman Siswa

Recommend Documents