X. systems.press X.systems.press ist eine praxisorientierte Reihe zur Entwicklung und Administration von Betriebssystemen, Netzwerken und Datenbanken.
Rolf Dietze · Tatjana Heuser · Jörg Schilling
OpenSolaris
für Anwender, Administratoren und Rechenzentren Von den ersten Schritten bis zum produktiven Betrieb auf Sparc, PC und PowerPC basierten Plattformen
Mit 255 Abbildungen und 96 Tabellen
123
Rolf Dietze
Tatjana Heuser
Mainzer Str. 6 10715 Berlin
[email protected]
Ettaler Str. 2 10777 Berlin
[email protected]
Jörg Schilling Seestr. 110 13353 Berlin
[email protected] [email protected] [email protected] www.opensolaris.in-berlin.de
Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.
ISSN 1611-8618 ISBN-10 3-540-29236-5 Springer Berlin Heidelberg New York ISBN-13 978-3-540-29236-4 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: druckfertige Daten durch die Autoren Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142 YL – 5 4 3 2 1 0
Inhaltsverzeichnis
Teil I Intro 1
Einf¨ uhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Zur Reihenfolge der Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Material und Arbeitsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Begleitendes Material und Errata . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Die 2.1 2.2 2.3 2.4 2.5 2.6 2.7
Geschichte von OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . . . . . OpenSolaris ist keine Betriebssystemdistribution . . . . . . . . . . Unterschiede der OpenSolaris-basierten Distributionen . . . . . Was OpenSolaris heute ist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie OpenSolaris entstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geschichtliche und rechtliche Hintergr¨ unde . . . . . . . . . . . . . . . . . Geplante weitere OpenSource Projekte von Sun . . . . . . . . . . . . . Sun’s Einstellung zu OpenSource . . . . . . . . . . . . . . . . . . . . . . . . . .
9 10 11 11 12 12 13 14
3
Lizenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Die CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Die Ziele der CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Das erste Kapitel der CDDL . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Im zweiten Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Im dritten Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Im vierten Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Im f¨ unften Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Im sechsten Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7 Im siebenten Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.8 Das achte Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17 17
3 5 6 6 7 7
17 24 24 24 25 25 25 25 26 26
VI
Inhaltsverzeichnis
3.3.9 Das neunte Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 H¨aufig gestellte Fragen im Zusammenhang mit der CDDL . . . . 3.5 Ausblicke auf bereits laufende Projekte . . . . . . . . . . . . . . . . . . . . . 3.6 Der “CDDL Header” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26 26 28 28
Teil II Konzepte und Grundlagen 4
Solaris Systemstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Open Boot PROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Grundkommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Lesen und Setzen von Variablen . . . . . . . . . . . . . . . . . . . . . 4.1.3 Lesen und Setzen von (Boot)-Aliaseintr¨agen . . . . . . . . . . 4.1.4 Auflisten der Devicealiases . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.5 Setzen von Devicealiasen . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.6 Setzen von Bootaliases, Men¨ ugesteuert . . . . . . . . . . . . . . . 4.1.7 Devicepfade im OBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.8 OBP-Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.9 Identifikationsstring, Bannerpage . . . . . . . . . . . . . . . . . . . . 4.2 x86-BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 SparcSolaris Systemboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 OBP Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Bootprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Autokonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Kernel-Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5 Starten der Systemdienste . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5.1 init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5.2 smf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 x86 Systemstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 x86 Systemstart bei ¨alteren Systemen . . . . . . . . . . . . . . . . . . . . . . 4.6 Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Wechsel zwischen Runleveln . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 inittab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Start- und Stopscripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Start der Systemdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 4.7.1.1 Milestones in der Ubersicht ................. 4.7.1.1.1 milestone/name-services . . . . . . . . . . . 4.7.1.1.2 milestone/network . . . . . . . . . . . . . . . . 4.7.1.1.3 milestone/devices . . . . . . . . . . . . . . . . . 4.7.1.1.4 milestone/single-user . . . . . . . . . . . . . . 4.7.1.1.5 milestone/sysconfig . . . . . . . . . . . . . . . 4.7.1.1.6 milestone/multi-user . . . . . . . . . . . . . . 4.7.1.1.7 milestone/multi-user-server . . . . . . . . 4.7.1.2 Systemstart unter SMF Verwaltung . . . . . . . . . .
33 33 35 36 38 38 39 40 41 46 47 49 50 51 51 51 52 52 52 52 53 54 55 56 58 59 63 64 65 65 66 66 66 67 67 68 68
Inhaltsverzeichnis
VII
4.7.1.3 Wechsel der Milestones . . . . . . . . . . . . . . . . . . . . . 72 4.8 Systemboot Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.9 System Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.9.1 init(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.9.2 halt(1M), poweroff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.9.3 reboot(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.9.4 shutdown(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 ¨ 4.10 Ubersicht zur manuellen Solarisinstallation . . . . . . . . . . . . . . . . . 76 4.11 Automatisierte Installation von Solaris . . . . . . . . . . . . . . . . . . . . . 78 4.11.1 Installserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.11.1.1 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.11.1.2 Serverkomponenten . . . . . . . . . . . . . . . . . . . . . . . . 80 4.11.1.3 Ablauf der automatischen Installation . . . . . . . . 80 4.11.1.4 Installation Phase 1: Netzboot . . . . . . . . . . . . . . . 81 4.11.1.5 Installation Phase 2: Installationsscripte . . . . . . 81 4.11.2 Konfigurationsdateien des Installservers . . . . . . . . . . . . . . 83 4.11.2.1 /etc/hosts und /etc/ethers . . . . . . . . . . . . . . . . . . 84 4.11.2.2 /etc/bootparams . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.11.2.3 Systemidentifikation: sysidcfg . . . . . . . . . . . . . . . . 85 4.11.2.4 Regel- und Klassenfiles . . . . . . . . . . . . . . . . . . . . . 87 4.11.2.4.1 rules.ok . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.11.2.4.2 key-value Felder . . . . . . . . . . . . . . . . . . 89 4.11.2.4.3 key-Feld . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.11.2.4.4 value-Feld . . . . . . . . . . . . . . . . . . . . . . . 89 4.11.2.4.5 Begin/End-Scripte . . . . . . . . . . . . . . . . 90 4.11.2.4.6 class-File . . . . . . . . . . . . . . . . . . . . . . . . 90 4.11.2.5 Test der Konfiguration . . . . . . . . . . . . . . . . . . . . . 91 4.11.3 Installserver, Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.11.3.1 Installation der Solaris Installserver-Software . . 93 4.11.3.2 Konfiguration von Clients . . . . . . . . . . . . . . . . . . . 95 4.11.3.2.1 Start des Netz-Installboots . . . . . . . . . 97 4.11.3.3 Fehlerdiagnose der beteiligten Dienste . . . . . . . . 97 4.11.3.3.1 arp/rarp . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.11.3.3.2 tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.11.3.3.3 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.11.3.3.4 bootparams . . . . . . . . . . . . . . . . . . . . . . 99 4.11.4 Worksheet: Autoinstallserver . . . . . . . . . . . . . . . . . . . . . . . . 100 5
Festplatten und Filesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.1 Strukturen auf raw devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.1.1 Implementation des Unix Filesystems, ufs . . . . . . . . . . . . 104 5.1.1.1 Der Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1.1.2 Inodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1.1.2.1 device nr . . . . . . . . . . . . . . . . . . . . . . . . 107 5.1.1.2.2 Inode nr . . . . . . . . . . . . . . . . . . . . . . . . . 107
VIII
Inhaltsverzeichnis
5.1.1.2.3 file type . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.1.1.2.4 mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.1.1.2.5 user,group . . . . . . . . . . . . . . . . . . . . . . . 108 5.1.1.2.6 timestamps . . . . . . . . . . . . . . . . . . . . . . 108 5.1.1.2.7 atime . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.1.1.2.8 mtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.1.1.2.9 ctime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.10 link count . . . . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.11 size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.12 block count . . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.13 Blocklisten . . . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.14 direct blocks . . . . . . . . . . . . . . . . . . . . . 109 5.1.1.2.15 single indirect blocks . . . . . . . . . . . . . . 110 5.1.1.2.16 double indirect blocks . . . . . . . . . . . . . 111 5.1.1.2.17 triple indirect blocks . . . . . . . . . . . . . . 111 5.1.2 Loggendes Filesystem, ufs+ . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.1.3 Memory Filesystem (tmpfs) . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.2 Abbildung logischer Strukturen auf Filesystemebene . . . . . . . . . 113 5.2.1 Abbildung des dynamischen Kernels im Filesystem . . . . 114 5.2.1.1 Solaris dynamischer Kernel . . . . . . . . . . . . . . . . 114 5.2.1.2 /etc/system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.2.1.2.1 Fileformat /etc/system . . . . . . . . . . . . 116 5.2.1.2.2 Auto-pty . . . . . . . . . . . . . . . . . . . . . . . . 117 5.2.2 Solaris Device Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.2.2.1 Device Filesystem und Dynamische Rekonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.2.2.2 Konfigurationsdateien . . . . . . . . . . . . . . . . . . . . . . 120 5.2.2.2.1 /etc/name to major . . . . . . . . . . . . . . . 120 5.2.2.2.2 /etc/path to inst . . . . . . . . . . . . . . . . . . 122 5.2.2.2.3 /etc/devlink.tab . . . . . . . . . . . . . . . . . . 126 5.2.2.2.4 Zugriffsrechte u ¨ber /etc/minor perm 127 5.2.2.3 Abbildung im Filesystem . . . . . . . . . . . . . . . . . . . 127 5.2.2.4 Device Filesystem Management . . . . . . . . . . . . . . 128 5.2.3 Prozeß Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.2.4 Contract Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 5.2.4.1 ctrun(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.2.4.2 ctstat(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.2.4.3 ctwatch(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.2.5 Kernel Object Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.2.6 Loopback Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.2.7 Translucent Filesystem (bis SunOS 4.1.4) . . . . . . . . . . . . 138 5.3 NFS, Network Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.3.1 Begriffsdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.3.2 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.3.3 NFS in Solaris Releases bis Solaris 9 . . . . . . . . . . . . . 140
Inhaltsverzeichnis
5.4
5.5
5.6
5.7
5.8
5.9
IX
5.3.4 NFS ab OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.3.5 Nutzung des NFS Client Services . . . . . . . . . . . . . . . . . . . 142 5.3.6 Volume Management Filesystem . . . . . . . . . . . . . . . . . . . . . 143 Filesysteme f¨ ur Wechselmedien und Datenaustausch . . . . . . . . . 143 5.4.1 Universal Disk Format (UDF) . . . . . . . . . . . . . . . . . . . . . . . 143 5.4.2 Das ISO-9660 Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.4.3 Das FAT-Filesystem (pcfs) . . . . . . . . . . . . . . . . . . . . . . . . . 146 Administration von Festplatten . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 5.5.1 Formatierung und Partitionierung . . . . . . . . . . . . . . . . . . . 147 5.5.2 format.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.5.3 Label per Commandline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 5.5.4 Hinzuf¨ ugen und Entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Administration von Filesystemen . . . . . . . . . . . . . . . . . . . . . . . . . . 155 5.6.1 Erzeugung eines Filesystems, newfs . . . . . . . . . . . . . . . . . . 156 5.6.2 Nachtr¨agliche Modifkation von Parametern, tunefs . . . . . 157 5.6.3 Integrit¨atscheck, fsck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.6.4 Mount und Umount von Filesystemen . . . . . . . . . . . . . . . . 159 5.6.4.1 mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.6.4.2 mnttab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.6.4.3 /etc/vfstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.6.4.4 mount(1M) im Detail . . . . . . . . . . . . . . . . . . . . . . 163 5.6.4.5 umount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.6.4.6 Zusammenfassend zu Mountoperationen . . . . . . 165 Aufbau des Filesystem Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.7.1 Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.7.2 Directories und Pfade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.7.3 Absolute und relative Pfadangaben . . . . . . . . . . . . . . . . . . 167 Verst¨andnisfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Navigation im Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.8.1 pwd(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.8.2 cd(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 5.8.2.1 Der directory stack der csh . . . . . . . . . . . . . . . . . . 174 5.8.2.2 Der directory stack der ksh . . . . . . . . . . . . . . . . . 174 5.8.3 ls(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.8.4 find(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.8.5 du(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 5.8.6 df(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Basis Unix Zugriffsrechte – Permissions . . . . . . . . . . . . . . . . . . . . 186 5.9.1 Modi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 5.9.1.1 Zugriffsrechte auf Dateien . . . . . . . . . . . . . . . . . . . 186 5.9.1.2 Zugriffsrechte auf Directories . . . . . . . . . . . . . . . . 187 5.9.1.3 Default File Permissions . . . . . . . . . . . . . . . . . . . . 187 5.9.2 umask(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.9.2.1 s-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 5.9.2.2 t-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
X
Inhaltsverzeichnis
5.10 5.11
5.12 5.13
5.14
5.15
5.9.3 chmod(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 5.9.4 Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 5.9.4.1 Manipulation von Access Control Lists . . . . . . . 192 5.9.4.2 Beispiel: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 5.9.5 chown(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.9.6 chgrp(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Zeitinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 5.10.1 touch(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Operationen am Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.11.1 mkdir(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.11.2 rmdir(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 5.11.3 rm(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 5.11.4 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 5.11.4.1 Hardlinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 5.11.4.2 Soft Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 5.11.5 ln(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 5.11.6 mv(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.11.7 cp(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 5.11.8 cpio(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 5.11.9 tar(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Antworten zu den Verst¨andnisfragen . . . . . . . . . . . . . . . . . . . . . . . 208 Extended File Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.13.1 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.13.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 5.13.3 Unterst¨ utzung durch Standardkommandos . . . . . . . . . . . . 212 5.13.4 Anwendungen f¨ ur Extended File Attribute . . . . . . . . . . . . 213 Access Control Listen unter Solaris . . . . . . . . . . . . . . . . . . . . . . . 214 5.14.1 UNIX Zugriffsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.14.2 Posix ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 5.14.3 NFSv4 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 5.14.4 Die Auswertung von NFSv4 ACLs . . . . . . . . . . . . . . . . . . 220 5.14.5 Das Auflisten von ACLs mit Hilfe von ls . . . . . . . . . . . . . 220 5.14.6 Das Verwalten von ACLs mit Hilfe von chmod . . . . . . . . 222 5.14.7 Die integrative Wirkung der NFSv4 ACLs . . . . . . . . . . . . 224 Sun Logical Volume Manager, SLVM . . . . . . . . . . . . . . . . . . . . . . . 225 5.15.1 Theorie der RAID-Technologie . . . . . . . . . . . . . . . . . . . . . . 226 5.15.1.1 RAID Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 5.15.2 RAID Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 5.15.3 SLVM Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 5.15.3.1 /etc/lvm/md.tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 5.15.4 SLVM: Statedatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 5.15.4.1 Das metadb(1M) Kommando . . . . . . . . . . . . . . . . 237 5.15.4.2 Anlegen von Statedatabases . . . . . . . . . . . . . . . . . 237 5.15.4.3 Erzeugen von Statedatabases in Disksets . . . . . . 240 5.15.4.4 L¨oschen von Statedatabases . . . . . . . . . . . . . . . . . 240
Inhaltsverzeichnis
XI
5.15.4.5 Reparatur von Statedatabases . . . . . . . . . . . . . . . 241 5.15.5 Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 5.15.5.1 Stripe/Concat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 5.15.5.2 Stripe aus Concats . . . . . . . . . . . . . . . . . . . . . . . . . 245 5.15.5.3 Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 5.15.5.3.1 Migration von Datenbest¨anden . . . . . 251 5.15.5.4 RAID-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 5.15.5.5 Ersetzung von Raid Komponenten . . . . . . . . . . . 253 5.15.5.6 Metadevices on Lofi . . . . . . . . . . . . . . . . . . . . . . . . 253 5.15.6 Hot Spare Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 5.15.6.1 Administration von Hot Spare Pools . . . . . . . . . 259 5.15.6.1.1 Erzeugung eines Hot Spare Pools . . . 260 5.15.6.1.2 Einbinden weiterer Partitionen . . . . . 261 5.15.6.1.3 Entfernen einer Partition . . . . . . . . . . 261 5.15.6.1.4 Ersetzen einer Partition . . . . . . . . . . . 261 5.15.6.1.5 L¨oschen eines Hot Spare Pools . . . . . . 262 5.15.6.1.6 Anbinden an RAID-Sets . . . . . . . . . . 262 5.15.6.1.7 Ersatz von RAID-Set Partitionen . . . 265 5.15.7 SLVM Devices u ¨ber MPxIO . . . . . . . . . . . . . . . . . . . . . . . . 268 5.15.8 SDS Bootdisk Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 5.15.9 SLVM Softpartitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 5.15.9.1 Erzeugung von Softpartitionen . . . . . . . . . . . . . . 279 5.15.9.2 Spiegelung von Softpartitionen . . . . . . . . . . . . . . 280 5.15.9.3 RAID5 aus Softpartitionen . . . . . . . . . . . . . . . . . 281 5.15.9.4 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 5.15.9.5 Vergr¨oßern von Softpartitionen . . . . . . . . . . . . . . 283 5.15.9.6 L¨oschen von Softpartitionen . . . . . . . . . . . . . . . . . 283 5.15.9.7 Auflistung der Softpartitionen . . . . . . . . . . . . . . . 283 5.15.10 SLVM Disk Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 5.15.10.1 RAID-Set Administration in Disk Sets . . . . . 286 5.15.11 Troubleshooting SLVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 5.15.11.1 Rettung eines Stripes/Concats . . . . . . . . . . . . . 287 5.15.11.1.1 Stripe . . . . . . . . . . . . . . . . . . . . . . . . 288 5.15.11.2 Rettung eines Mirrors . . . . . . . . . . . . . . . . . . . . 288 5.15.11.2.1 Offensive Methode . . . . . . . . . . . . . 289 5.15.11.2.2 Defensive Methode . . . . . . . . . . . . . 290 5.15.11.3 Rettung eines RAID-5 . . . . . . . . . . . . . . . . . . . 290 5.16 Zettabyte Filesystem, ZFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 ¨ 5.16.1 Neuigkeiten im Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . 295 5.16.2 Beschreibung des Beispielsetups . . . . . . . . . . . . . . . . . . . . 297 5.16.3 Storage Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 5.16.3.1 Administration von Storage Pools . . . . . . . . . . 303 5.16.3.1.1 Auflisten von Konfigurationen und Status . . . . . . . . . . . . . . . . . . . . 305 5.16.3.1.2 Aufsetzen eines Stripes . . . . . . . . . 306
XII
Inhaltsverzeichnis
5.16.3.1.3 5.16.3.1.4 5.16.3.1.5 5.16.3.1.6 5.16.3.1.7 5.16.3.1.8
Aufsetzen eines Zweifachspiegels . 307 Aufsetzen eines Mehrfachspiegels 307 Aufsetzen eines Stripe-Mirrors . . . 308 Aufsetzen eines RAID-Z . . . . . . . . 309 Aufsetzen eines striped RAID-Z . 309 Aufsetzen von Kombinationsvolumes . . . . . . . . . . 310 5.16.3.1.9 Hinzuf¨ ugen von virtual Devices in Storage Pools . . . . . . . . . . . . . . . 311 5.16.3.1.10 Import/Export von Storage Pools 312 5.16.3.1.11 Fehlersituationen, vDev-Errors . . 314 5.16.3.1.12 Replacementoperationen . . . . . . . . 315 5.16.3.1.13 Attach/Detach . . . . . . . . . . . . . . . . 315 5.16.3.1.14 Administrationsfehler . . . . . . . . . . 317 5.16.3.1.15 L¨oschen von Storage Pools . . . . . . 318 5.16.4 ZFS Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 5.16.4.1 ZFS Subkommandos . . . . . . . . . . . . . . . . . . . . . 319 5.16.4.2 ZFS Properties: Setzen und Lesen von Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 5.16.4.3 Administration von ZFS Datasets . . . . . . . . . 323 5.16.4.3.1 Erzeugen eines Filesystems . . . . . . 325 5.16.4.3.2 Erzeugen eines Subfilesystems . . . 326 5.16.4.3.3 Auflistung von ZFS Filesystemen 327 5.16.4.3.4 L¨oschen eines Filesystems . . . . . . . 328 5.16.4.3.5 ZFS Snapshots . . . . . . . . . . . . . . . . 328 5.16.4.3.6 Clonen eines ZFS Filesystems . . . 330 5.16.4.3.7 Anzeige der Properties . . . . . . . . . 331 5.16.4.3.8 Reservieren einer Storage Area . . 333 5.16.4.3.9 Setzen von Quotas . . . . . . . . . . . . . 334 5.16.4.3.10 Mountoptionen . . . . . . . . . . . . . . . . 335 5.16.4.3.11 NFS-Optionen . . . . . . . . . . . . . . . . 337 5.16.4.3.12 Automatische Compression . . . . . 338 5.16.4.4 ZFS als Blockdevice . . . . . . . . . . . . . . . . . . . . . 338 5.16.4.5 ZFS Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 5.17 Images von Filesystemen lofi(7D) . . . . . . . . . . . . . . . . . . . . . . . . . . 340 5.17.1 lofiadm(1M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 5.17.2 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 5.17.2.1 Installation von CD-Images . . . . . . . . . . . . . . . 341 5.17.2.2 Diskettenimages . . . . . . . . . . . . . . . . . . . . . . . . . 342 5.17.2.3 Partitionsimages . . . . . . . . . . . . . . . . . . . . . . . . . 343 5.18 Solaris I/O Multipathing, MPxIO . . . . . . . . . . . . . . . . . . . . . . . . 344 5.18.1 Arbeiten mit MPxIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 5.18.1.1 Per Port Einstellungen . . . . . . . . . . . . . . . . . . . 354
Inhaltsverzeichnis
6
XIII
Solaris Netzwerk Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 6.1 Client-Server Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 6.2 Netzwerk-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 6.2.1 Grundlagen zur Adressierung . . . . . . . . . . . . . . . . . . . . . . . 360 6.2.2 Anmerkung zu Hostnamen . . . . . . . . . . . . . . . . . . . . . . . . . 362 6.2.3 Anmerkung zu IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . 364 6.2.4 Der IPv4-Adreßraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 6.3 Das TCP/IP Schichtmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 6.3.1 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 6.3.2 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 6.3.3 Internet Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 6.3.4 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 6.3.5 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 6.3.6 Grenzen im TCP/IP Modell . . . . . . . . . . . . . . . . . . . . . . . . 369 6.4 Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 6.4.1 Initialisierung der Netzwerkumgebung bei OpenSolaris371 6.4.2 Initialisierung der Netzwerkumgebung bis Solaris 9 . . . 374 6.4.2.1 Initialisierung von Netzwerkinterfaces . . . . . . . . 374 6.4.2.2 Netzwerkumgebung . . . . . . . . . . . . . . . . . . . . . . . . 376 6.4.3 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 6.4.3.1 /etc/nodename . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 6.4.3.2 /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 6.4.3.3 /etc/ethers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 6.4.3.4 /etc/hostname.
. . . . . . . . . . . . . . . . . . . . . . . . . 383 6.4.3.5 /etc/networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 6.4.3.6 /etc/netmasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 6.4.3.7 /etc/netconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 6.4.4 Administration von Netzwerkinterfaces, Upper Layer . . . 387 6.4.4.1 Erzeugung eines Interfaces . . . . . . . . . . . . . . . . . . 387 6.4.4.2 L¨oschung eines Interfaces . . . . . . . . . . . . . . . . . . . 388 6.4.4.3 IP-Adresse auf physikalischem Interface . . . . . . . 388 6.4.4.3.1 On the fly . . . . . . . . . . . . . . . . . . . . . . . 388 6.4.4.3.2 Persistent . . . . . . . . . . . . . . . . . . . . . . . . 389 6.4.4.4 Logische Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 390 6.4.4.4.1 On the fly . . . . . . . . . . . . . . . . . . . . . . . 391 6.4.4.4.2 Persistent . . . . . . . . . . . . . . . . . . . . . . . . 392 6.4.4.4.3 Logische Interfaces in Zones . . . . . . . . 393 6.4.4.5 Start/Stop eines Interfaces . . . . . . . . . . . . . . . . . . 394 6.4.4.6 Erzeugen eines VLans . . . . . . . . . . . . . . . . . . . . . . 394 6.4.4.6.1 On the Fly . . . . . . . . . . . . . . . . . . . . . . . 395 6.4.4.6.2 Persistent . . . . . . . . . . . . . . . . . . . . . . . . 396 6.4.4.7 IPFC, IP u ¨ber FCAL . . . . . . . . . . . . . . . . . . . . . . 396 6.4.5 Wechsel des Hostnamens . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 6.4.5.1 Empfohlene Methode . . . . . . . . . . . . . . . . . . . . . . . 399 6.4.5.2 Praktikabler Weg . . . . . . . . . . . . . . . . . . . . . . . . . . 400[email protected] eingerichtet./ufsboot, also auf einem sun4u System /platform/sun4u/ufsboot. Dieses Programm l¨adt dann /platform//kernel/unix auf 32-Bit Systemen und /platform//kernel/sparcv9/unix auf 64-Bit Systemen. Danach werden /kernel/genunix bzw. /kernel/sparcv9/genunix und der Kernel Runtime Linker krtld geladen. 4.3.3 Autokonfiguration Diese drei Module k¨ onnen dann selbstst¨ andig beliebige weitere Module nachladen. Dabei werden, bis zu dem Zeitpunkt an dem das Root Filesystem gemountet wurde, Treiber des Bootproms und die w¨ahrend des Bootvorgangs geladene Filesystemimplementierung verwendet. Mittels dieser Treiber wird die /etc/system des im EEPROM gesetzten Bootdevices gelesen, und gegebenenfalls dort per forceload angegebene Kernel Module nachgeladen. Hiervon wird insbesondere Gebrauch gemacht, wenn anschließend als root filesystem nicht das bis zu diesem Zeitpunkt verwendete ufs, sondern das Mirror Device eines SoftRaid Systems gemountet werden soll. Siehe hierzu das Listing 5.17 auf Seite 278. In dieser /etc/system, die im Benutzung von (NIS) {domainname= name_server=} statisch ip_address= netmask= Server-netmask beachten! protocol_ipv6=} network_interface=<primary|[if]> erstes Netzwerkinterface, {dhcp dhcp protocol_ipv6=} root_password=somevaluecryptedfromshadowfile security_policy=NONE security_policy=kerberos domain ist eine FQDn {default_realm=domain admin_server=domain kdc=domain1,domain2,domain3} system_locale=en_US. 4.11.2.4.3 key-Feld Als Keys werden folgende Belegungen unterst¨ utzt: any immer true arch Abh¨ angigkeit von der Maschinenarchitektur domainname true, wenn Client einer bestimmten Domain angeh¨ort disksize Auswahl nach Plattengr¨ oße hostname Auswahl nach Hostname installed karch Abh¨ angigkeit von der CPU-Architektur memsize Abh¨ angigkeit von der Speichergr¨oße model Abh¨ angigkeit vom Rechnermodell (z.B.: SUNW,Sun-Fire-15000) network Abh¨ angigkeit vom Netzwerk totaldisk Abh¨ angig von den Gesamtplatten des Rechners Kombinierbar, wie in 4.11.2.4.2 beschrieben. 4.11.2.4.4 value-Feld Das Feld, das dem Key-Feld folgt, h¨ alt die Werte, auf die der bzw. die Keys gematcht werden. So ist der einfachste Fall: any - -D Dryrun-Test gegen die lokale Bootplatte, es wird jedoch keine Modifikation vorgenommen -d Test gegen ein VTOC-File (prtvtoc(1M)) -c Pfad zum Distributionsverzeichnis der Solaris-Release Vorsicht: Bei einem Test auf dem Installserver sollte bei einem Testlauf f¨ ur ein ¨ Klassenfile gegen die lokale Bootplatte die Option -D verwendet werden. Altere Versionen von pfinstall(1M) schreiben ohne diese Option auf die Bootplatte mit entsprechenden Folgen f¨ ur das System.liest. 4.11.3.2.1 Start des Netz-Installboots Der Netz-Autoinstallboot wird vom OBP-Prompt des Clients mit dem Kommando boot net - install auf dem Installserver f¨ ur das Netzwerkinterface ausgef¨ uhrt werden, u auft. ¨ber das die Installation l¨ ¨ 4.11.3.3.1 Uberpr¨ ufung des arp/rarp-Services Wenn eine Netzwerkadresse nicht aufgel¨ ost werden kann, so ist zu u ufen, ¨berpr¨ ob die Eintr¨age in /etc/hosts, /etc/ethers stimmen, Mehrfachangaben enthalten etc. Es kann unter Verwendung des Kommandos arp(1) u uft werden, ¨berpr¨ ob die entsprechende MAC-Adresse bekannt ist. Das Protokoll rarp ist nicht routingtransparent. Weiterhin bestehen Fehlerquellen in inkorrekten Adress- und Netzangaben (IP-Adresse, Netzmaske, Routing). ¨ 4.11.3.3.2 Uberpr¨ ufung des tftp-Service Zum einen ist zu u ufen, ob der tftp-Service durch den inetd(1M) u ¨berpr¨ ¨berhaupt gestartet wird. Weiterhin sind die Zugriffsm¨ oglichkeiten von außen zu testen (Vorsicht, nicht vom gleichen Host im gleichen Verzeichnis!) Eine weitere Fehlerquelle sind auch die Files unter /tftpboot. Dazu ein ¨ Uberblick u ¨ber die Struktur: [ []]],:<Partition> pbundle existieren jeweils drei Dateien, die jeweils Filedeskriptoren zur¨ uckliefern: ctl: Das Controlfile zu dem betreffenden Contract. status: Das Statusfile zu dem betreffenden Contract. events: Die Events des betreffenden Contracts. Das Administrationsinterface zum Contract Filesystem setzt sich aus drei Kommandos zusammen: ctrun(1): Ausf¨ uhrung eines Prozesses in einem Prozeß Contract. ctstat(1): Anzeige aktiver Prozeß Contracts. ¨ ctwatch(1): Uberwachung von Events in einem Contract oder einer Gruppe von Contracts. Die grundlegende Arbeitsweise erinnert an Prozessgruppen, wobei die Contract ID letztendlich eine Art Gruppenidentifikator darstellt. Im Groben kann quit, then return quit partition>, then return] /SourcePath /TargetPath {} +:[:vererbungs flags] group@::[:vererbungs flags] everyone@::[:vererbungs flags] user:<User-Name>:: . . . → [:vererbungs flags] group::: . . . → [:vererbungs flags] Mit einem Eintrag der einen expliziten Gruppennamen enth¨ alt lassen sich Rechte f¨ ur weitere namentlich bekannte Gruppen festlegen. Die Rechte bestehen aus einem einzelnen Recht oder durch eine Auflistung von mehreren durch ’/’ getrennten Einzelrechten. Dabei werden f¨ ur die Einzelrechte die Texte verwendet, die wir vorher besprochen haben. Die Typeintr¨ age k¨ onnen dabei folgende Werte annehmen: ¨ allow Wenn eine Ubereinstimmung der Nutzer oder Gruppenspezifikation des ACL Eintrages mit dem aktuellen Nutzer vorliegt und das gew¨ unschte Recht im ACL Eintrag gefunden wurde, dann wird das gew¨ unschte Recht gew¨ ahrt. ¨ deny Wenn eine Ubereinstimmung der Nutzer oder Gruppenspezifikation des ACL Eintrages mit dem aktuellen Nutzer vorliegt und das gew¨ unschte Recht im ACL Eintrag gefunden wurde, dann wird das gew¨ unschte Recht verwehrt und die weitere Suche nach Rechten abgebrochen. f¨ ur die Elemente bzw. RAID-Sets folgt. Von deutlichem praktischem Vorteil ist jedoch, eine sinnvolle Ordnung in die Bezeichnung der RAID-Sets und Elemente einzuf¨ uhren und durchzuhalten. So hat es sich als praktisch erwiesen, f¨ ur Mirrors d*0 und die zugeh¨orenden Submirrors d*1, d*2, d*3. . . zu w¨ ahlen. F¨ ur Stripes, Concats und RAID-5 Metadevices kann ein nicht auf der Ziffer 0 endender Identifikator gew¨ahlt werden. Das hat bei Auflistungen wie df -k iostat -x 1 etc. den Vorteil, daß der Administrator mit einem Blick zwischen redundanten Mirrors und nichtredundanten Stripes/Concats unterscheiden kann. Abgesehen davon ist die Ausgabe des SLVMStatus dadurch erheblich einfacher lesbar. Die Beispiele in diesem Buch folgen dieser Konvention, die in Tabelle 5.12 aufgelistet ist. mirror d*0 submirrors d*1, d*2 stripes/concats d*[1..9] Tabelle 5.12. Namenskonventionen f¨ ur RAID-Sets <size> metainit <softpart> -p -o -b <size> metattach softpart size mitzuf¨ uhren, wobei disksetname den Namen des Disk Sets, auf dem die Operation stattfinden soll, spezifiziert. Dies bedeutet, daß in Disk Sets Stripes, Concats, Mirrors, RAID-5 und Hot Spare Pools definiert werden k¨ onnen, bis hin zur Administration von Statedatabases. Dies sei hier nur kurz an einem Beispiel gezeigt, die grundlegenden Funktionen wurden zuvor beschrieben. Es soll ein Mirror aus einem Stripe aus zwei Festplatten in einem Disk Set nfs zwischen den Rechnernodes nova und endeavour erzeugt werden. Dazu ist zun¨achst die Konfigurationsdatei /etc/lvm/md.tab wie folgt zu modifizieren: # nfs-mirror: nfs/d10 -m nfs/d11 -m nfs/d12 # nfs/d11 1 2 /dev/rdsk/c2t0d0s0 /dev/rdsk/c2t1d0s0 nfs/d12 1 2 /dev/rdsk/c3t0d0s0 /dev/rdsk/c3t1d0s0 in kommaseparierter Liste die Tabellenspalten auszugeben, die von Interesse sind, in der angegebenen Reihenfolge. Eine Beispielausgabe mit Tabellenheader ist in Beispiel 5.30 zu sehen, die Feldnamen k¨onnen, klein geschrieben, auch einzeln spezifiziert werden s.o. endeavour# zpool list NAME SIZE new2 16.8G new3 16.8G]. Die ZFS eigenen Kommandos ¨ in Ubersicht create:”: directory is not empty use legacy mountpoint. . . filesystem successfully created, but not mounted Diese Fehlermeldung sollte man ernst nehmen, denn wenn der Grund daf¨ ur, ¨ also das nicht unterst¨ utzte Ubermounten, vor dem n¨achsten Reboot nicht beseitigt wird, so hat man sp¨ atestens bei diesem n¨achsten Reboot die Gelegenheit auf der Systemconsole das Problem zu beseitigen, denn das System wird bei Ausf¨ uhrung des Starts von filesystem/local bei der Methode fs-local aufh¨oren und damit nicht den multi-user-server Milestone erreichen. Und da somit keine Netzwerkzugriffsm¨ oglichkeiten gestartet wurden, ein Login per rsh/ssh/telnet dementsprechend nicht gegeben ist, ben¨otigt der Administrator dann Zugang zur Systemconsole24 um den Fehler beseitigen zu k¨onnen. ¨ Inwieweit das den Uberlegungen zu einer vereinfachten Administration mit 24 oder bei rekursiver Anwendung zfs destroy -r , was alles restlos bis zum angegebenen Parentfilesystem l¨ oscht. 5.16.4.3.5 ZFS Snapshots Ein Snapshot eines Filesystems ist gewissermaßen eine “Sicherheitskopie” des Filesystems, Kopie des Filesystems, die nur gelesen werden kann. Snapshots k¨onnen auf Filesystemebene erzeugt werden, sie liegen dann im Wurzelverzeichnis des jeweiligen Filesystems unter .zfs. Durch den copy-on-write Mechanismus ist die Erzeugung eines Snapshots keine l¨angere Operation, sondern lediglich ein Mechanismus, Altbl¨ ocke des Filesystems nicht wieder frei zu geben. Ein Snaptshot belastet damit nicht den Durchsatz des Filesystems sondern ben¨otigt lediglich Platz. Erzeugen eines Snapshots Ein Snapshot wird erzeugt durch Verwendung des Subkommandos snapshot unter Angabe des Filesystems und einer Identifikationsinformation, beispielsweise ein Datum, ein Wochentag, ein besonderes Ereignis oder eine andere sinnvolle Information. Nach Erzeugung ist der Snapshot wiederzufinden unter /.zfs/snapshots/info wobei info die zuvor gew¨ ahlte Identifikationsinformation ist. In Beispiel 5.57 ist das kurz gezeigt. endeavour# zfs snapshot export/home/ufa00@globus endeavour# ls -l /export/home/ufa00/.zfs/snapshot total 2 drwxr-xr-x 3 root sys 3 Jan 1 15:22 globus/[email protected] export/home/ufa00@sunday pm/demo@grits_tests[email protected] alter, also vorher entstanden als das Snapshot export/home/ufa00@sunday. ¨ endeavour# zfs rollback export/home/[email protected] cannot rollback to ’export/home/[email protected] ’: . . . → more recent snapshots exist use ’-r’ to force deletion of the following snapshots: export/home/ufa00@sunday endeavour# zfs rollback -r export/home/[email protected] endeavour# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT export/applications@newyearsday 0 2.19G export/home/[email protected] 0 41.1M pm/demo@grits_tests 0 5.41M /mnt[email protected] 357K - 41.1M ... endeavour# zfs clone export/home/[email protected] export/home/ufann endeavour# zfs list NAME USED AVAIL REFER MOUNTPOINT ... export/home 10.0G 4.38G 10.5K /export/home export/home/ufa00 42.1M 4.38G 41.8M /export/home/ufa00 export/home/[email protected] 357K - 41.1M export/home/ufa01 8K 14.4G 8K /export/home/ufa01 export/home/ufa02 8K 4.38G 8K /export/home/ufa02 export/home/ufann 0 4.38G 41.1M /export/home/ufann .... endeavour> zfs get all pm NAME PROPERTY pm type pm creation pm used pm available pm referenced pm compressratio pm mounted pm quota pm reservation pm recordsize pm mountpoint pm sharenfs pm checksum pm compression pm atime pm devices pm exec pm setuid pm readonly pm zoned pm snapdir pm aclmode pm aclinherit|compress", "symmetric-option"; # # symmetric-option = 0x1000000; an. W¨ahrend -L alle Devices und deren Mapping in den MPxIO Layer aufzeigt, ist unter Verwendung der -l Option unter Angebe des interessierenden Plattencontrollers eine eingeschr¨ ankte Auflistung m¨ oglich. In Listing 5.19 ist exemplarisch eine Auflistung der Pfade und des Mappings aller an Controller c2 h¨angenden Festplatten aufgelistet. Das Beispiel ist an einer UE220R durchgef¨ uhrt worden, die u ¨ber vier FCAL Hostbusadapter an ein im Splitloop betriebenes A5200 FCAL-StorEDGE Array angeschlossen ist (vergleiche Legacy Storage, Abschnitt B.4). Damit ist unter Verwendung der Ausgaben von stmsboot -l [ f¨ ur die physikalischen Controller c2, c3, c4 und c5 in der in Listing 5.19 dargestellten Art und Weise eine sortierte Liste des Mappings zwischen den jeweils zwei physikalischen und dem logischen MPxIO-Device in Tabelle 5.15 darstellbar. Es sein nochmals darauf hingewiesen, daß die Festplatten unter den Pfaden /dev/[dsk,rdsk]/[c2*,c3*,c4*,c5*] die physikalischen Festplatten sind und die.Soll hingegen nur ein einzelnes Device dekonfiguriert werden so geht das durch Aufruf von cfgadm -c unconfigure <device>. Beispielsweise wird ein an Atachmentpoint Id c2 definiertes Device 21000020371b0fa9 aus Listing 5.21 durch Aufruf von cfgadm -c unconfigure c2::21000020371b0fa9 dekonfiguriert. Sollte es notwendig sein, ein einzelnes Device unter MPxIO Verwaltung zu stellen oder dessen Verwaltung upzudaten, so ist es m¨oglich unter Angabe beider redundanter Pfade mit dem Kommando cfgadm -c configure c*::<device>c*::<device> das Device nachzubereiten. Ein Update der Konfiguration und der Eintr¨age in der /etc/vfstab ist durch Aufruf von stmsboot -u forcierbar. Sollte der Multiplexed IO Support wieder deaktiviert werden m¨ ussen, so ist dies ebenfalls mit dem Kommando stmsboot vorzunehmen, dann mit der Option -d. Ein Reboot folgt und des wird im Weiteren wieder nur mit den physikalischen Festplattenpfaden gearbeitet. 5.18.1.1 Per Port Einstellungen Es gibt die M¨oglichkeit MPxIO-Support global oder per Port zu aktivieren, wobei die per Port Einstellungen die h¨ ohere Priorit¨at geniessen. Die Konfiguration ist im fp-Treiberkonfigurationsfiel /kernel/drv/fp.conf durchzuf¨ uhren. mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 mtu 1500 index 2 inet 223.255.255.254 netmask ffffff00 broadcast 223.255.255.255 ether 8:0:20:74:ed:a8 werden gestartet, danach IPv6 Alle IPv6 Interfaces entsprechend der Konfiguration der /etc/hostname6. werden gestartet, danach DHCP werden alle auf DHCP konfigurierten Interfaces initialisiert und gestartet, spezifiziert durch die Konfigurationsfiles /etc/dhcp.. Defaultrouter Anschließend wird bei Existenz einer /etc/defautlrouter statisches Routing mit den in der /etc/defautlrouter eingetragenen Routen aktiviert. Die DHCP Autokonfiguration im vorherigen Schritt erlaubt auch das Setzen von Routen. System Identity (Nodename) Setzt die Systemidentifikation, den Nodename etc. und setzt die bereits vollst¨andig gestarteten Systemservices • svc:/network/loopback:default und • svc:/network/physical:default voraus. Die ausgef¨ uhrte Startmethode ist /lib/svc/method/identity-node definierten Netzwerkinterfaces gestartet werden. Wie? Woher? Ein Blick in einen Scriptausschnitt in Listing 6.3 zeigt das recht einfache Verfahren-Dateien gelesen und ausgewertet wird, solange der Argumentvektor gr¨ oßer null ist. Das Konstrukt einer while-Schleife, in der der Argumentvektor durch Anwendung der Operation shift modifiziert wird, ist im Abschnitt 11.7, Bourne Shell Scripte ab Seite 849 genauer erkl¨art. Hier sei nur kurz dargelegt, daß shift den Argumentvektor (siehe Seite 869) um ein Wort verschiebt und das betreffende Wort verwirft. Nach jeder Anwendung von shift ist folgerichtig der Argumentvektor ein Element kleiner. Im Argumentvektor des Interfacekonfigurationsscriptes liegen alle erkannten Interfaces, die nun jeweils bearbeitet und anschließend net netconfig nodename ethers net hosts services netmasks networks ticlts /etc/dhcp.-gw Ein Beispiel: pinta-gw • Per Interface Namensgebung: - Ein Beispiel: pinta-qfe1 Die Benennung des zweiten Interfaces mit “-gw” geht auf RFC95215 zur¨ uck, wobei zum damaligen Zeitpunkt nicht zwischen nodename und prim¨aren Hostnamen unterschieden worden ist. A host which serves as a GATEWAY should have “-GATEWAY” or “-GW” as part of its name. Hosts which do not serve as Internet gateways should not use “-GATEWAY” and “-GW” as part of their names. RFC952 Die IP-Adressen eines Rechners, die auf Ehternetinterfaces definiert sind, lassen sich mit dem Kommando ifconfig -a auflisten: pinta> ifconfig -a lo0: flags=1000849 . . . → mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.201.10 netmask ffff0000 broadcast 10.10.255.255 skge0: flags=1000843 . . . → mtu 1500 index 3 inet 10.10.100.2 netmask ffffff00 broadcast 10.10.100.255. Auf Eintr¨age in der Hosttabelle wird in diversen Situationen (Kommandos, Scripte etc.) zugegriffen. W¨ ahrend des Systemstarts, als auch in anderen Betriebsmodi eines Rechners, in denen kein Netzwerkinformationsdienst l¨auft, ist diese Datei die einzige Zuordnung von Hostname und IP-Adresse und umgekehrt. Gerade ¨ altere Scripte verwenden in diesem Fall die Referenzierung u atslink /etc/hosts. ¨ber den Kompatibilit¨ Die IP-Adresse aller Ethernet Interfaces eines Solaris-Rechners lassen sich mit dem Kommando ifconfig(1M) mit der Option -a anzeigen, gezeigt in Beispiel 6.10. Es werden das loopback-Interface (lo0), das physikalische Interface hme0, diverse logische Interfaces16 auf hme0 (hme0:1 .. hme0:3) und zwei Ethernet Interfaces eines Drittherstellers skge0 und skge50000 mit ihren IP-Adressen und anderen Informationen, die im folgenden erkl¨art werden, angezeigt. Soll nur ein bestimmtes Interface angezeigt werden, so ist, analog zu Beispiel 6.11, ifconfig(1M) mit dem Namen des Interfaces aufzurufen: 6.4.3.3 /etc/ethers Die Datei /etc/ethers ist eine Tabelle zur Zuordnung von MAC-Adressen zu Hostnamen. Zusammen mit passenden Informationen aus der /etc/hosts (oder einem netzwerkinformationsdienstbasierten hosts-Eintrag) wird die Zuordnung von MAC-Adresse zu IP-Adresse durchgef¨ uhrt. MAC-Adressen werden zentral vergeben pro Ethernet Netzwerkinterface. Das bedeutet, jedes Ethernet Netzwerkinterface hat eine eigene eindeutige MAC Adresse. Auch die /etc/ethers ist eine zweispaltige Tabelle, in deren erster Spalte die MAC-Adresse und in deren zweiter Spalte der Hostname steht. Auch in der 16 . . . → mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.201.10 netmask ffff0000 broadcast 10.10.255.255 hme0:1: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.201.11 netmask ffff0000 broadcast 10.10.255.255 hme0:2: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.201.18 netmask ffff0000 broadcast 10.10.255.255 hme0:3: flags=1000843 . . . → mtu 1500 index 2 inet 192.168.10.2 netmask ffffff00 broadcast 192.168.10.255 skge0: flags=1000843 . . . → mtu 1500 index 3 inet 10.10.100.2 netmask ffffff00 broadcast 10.10.100.255 skge50000: flags=1000843 . . . → mtu 1500 index 4 inet 192.168.128.1 netmask ffffff00 broadcast 192.168.128.255 . . . → mtu 1500 index 3 inet 10.10.100.2 netmask ffffff00 broadcast 10.10.100.255 /etc/ethers werden Kommentare durch das Zeichen # eingeleitet und gelten bis zum n¨achsten . Das Format folgt damit folgendem Beispiel: # MAC # ??.??.??.??.??.?? 8:0:20:1:2:3 8:0:20:1:3:a0 0:a3:b4:24:1:e7 F¨ ur das Setzen von statischen IP-Adressen, die nach einem Boot automatisch gesetzt sein sollen wird f¨ ur jedes zu konfigurierende Interface eine Datei /etc/hostname. erzeugt, wobei if hier f¨ ur den Treibernamen, gefolgt von seiner Instanznummer, stehen soll. Als Beispiel: Interface Nr. Type Datei hme 0 10/100 MBit /etc/hostname.hme0 eri 0 10/100 MBit /etc/hostname.eri0 hme 1 10/100 MBit /etc/hostname.hme1 ge 0 1000 MBit /etc/hostname.ge0 bge 0 10/100/1000 MBit /etc/hostname.bge0 Das Beispiel beschreibt Namen f¨ ur Dateien f¨ ur diverse Sun Ethernet Interfaces. Die so definierten Interfaces sind IPv4-Interfaces. IPv6-Interfaces werden statisch unter Verwendung des /etc/hostname6. konfiguriert. Im Defaultfall ist der Aufbau der Datei vergleichsweise einfach, im einfachsten Fall steht ein durch die /etc/hosts aufgel¨oster Hostname darin, der u ¨ber die /etc/hosts zu einer IP-Adresse erweitert wird, wie es in Beispiel 6.12 gezeigt ist. Sofern der Hostname jedoch nicht aufgel¨ost werden kann, kann das entsprechende Interface beim Startup des Systems17 nicht initialisiert werden. pinta# cat /etc/hostname.hme0 pinta Datei f¨ ur die Startupkonfiguration von IPv6 Interfaces, jedoch mit Namensaufl¨osung u ¨ber die Konfigurationsdatei /etc/inet/ipnodes. Es sei an dieser Stelle dringend empfohlen, Interfacehostnamen u ¨ber /etc/inet/hosts aufzul¨osen und nicht u ¨ber einen Netzwerkinformationsdienst, der zum Zeitpunkt des Systemstarts noch nicht verf¨ ugbar ist. Gleiches gilt f¨ ur die Referenzierung von Defaultroutereingr¨agen etc. Wenn beispielsweise weitere logische IP-Adressen18 dazukommen sollen, so kann ein /etc/hostname.-file, wie in Beispiel 6.13, bereits komplexer aufgebaut sein., wie es in 6.5 zu erkennen ist oder im Abschnitt zur /etc/hostname.-Syntax in 6.4.3.4. 20 mtu 1500 index 4 inet 192.168.128.1 netmask ffffff00 broadcast 192.168.128.255 <semantics> <protofamily> <protoname> \ # <device> ... udp6 tpi_clts v inet6 udp /dev/udp6 tcp6 tpi_cots_ord v inet6 tcp /dev/tcp6 udp tpi_clts v inet udp /dev/udp tcp tpi_cots_ord v inet tcp /dev/tcp rawip tpi_raw inet /dev/rawip ticlts tpi_clts v loopback /dev/ticlts straddr.so ticotsord tpi_cots_ord v loopback /dev/ticotsord straddr.so ticots tpi_cots v loopback /dev/ticots straddr.soplumb Beispielsweise kann ein Interface mit der Instanznummer 0 und dem Namen eri wie folgt erzeugt werden: ifconfig eri0 plumb mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 mtu 1500 index 2 inet 0.0.0.0 netmask ffff0000 broadcast 10.10.255.255 mtu 1500 index 2 inet 0.0.0.0 netmask ffff0000 broadcast 10.10.255.255unplumb Das Kommando ifconfig wird damit keine weiteren Informationen zu dem betreffenden Interface mehr ausgeben k¨ onnen. Es ist auch nicht notwendig vor einem unplumb die Interfacekonfiguration zur¨ uckzusetzen. 6.4.4.3 IP-Adresse auf physikalischem Interface Als physikalisches Interface wird in diesem Zusammenhang das Interface betrachtet, das unter der Bezeichnung gef¨ uhrt wird. Also etwa hme0, hme1, hme127, bge19, ce3 . . . . Physikalische Interfaces werden plumbed und unplumbed. 6.4.4.3.1 On the fly Um eine IP-Adresse einem Interface zuzuordnen, ist das Kommando ifconfig(1M) zu verwenden. Jede unvollst¨ andige Angabe zu Netzmaske und Broadcastadresse wird durch ihren Netzwerkdefault beziehungsweise die in /etc/netmasks gesetzten Werte erg¨ anzt. Das Aufsetzen eines IP Interfaces mit Adresse erfolgt in zwei Schritten: 1. Erzeugen des Interfaces (Laden des Streamdrivers) 2. Setzen von Parametern. Das Erzeugen eines Interfaces wurde zuvor beschrieben in Abschnitt 6.4.4.1. Das Setzen von Parametern wie IP-Adresse, Netzmaske, Broadcastadresse und Betriebszustand ist unter Angabe des Interfaces als Liste wie im Beispiel 6.16 gezeigt, durchzuf¨ uhren. Das Ergebnis l¨ aßt sich wieder mit ifconfig(1M) anzeigen. In Beispiel 6.16 wurden vier Schritte ausgef¨ uhrt, die prinzipiell auch nacheinander ausgef¨ uhrt werden k¨ onnen: 1. hme0 bekommt die IP-Adresse, die durch die /etc/hosts aufgel¨ost f¨ ur pinta-gw ersetzt wird. mtu 1500 index 2 inet 10.10.100.10 netmask ffffff00 broadcast 10.10.100.255 zu modifizieren. Der Aufbau von /etc/hostname. ist bereits in 6.4.3.4 beschrieben worden. Sei nun also das Interface qfe0 mit einer durch Eintr¨age in der /etc/hosts IP/Hostnamen Adresse f¨ ur pinta-gw aufgel¨ osten Adresse so zu konfigurieren, daß nach einem Systemstart qfe0 mit der zu pinta-gw geh¨orenden (und u osten) IP-Adresse gesetzt ist, so ist lediglich die Datei ¨ber die hosts augfgel¨ /etc/hostname.qfe0 anzulegen und der Name pinta-gw einzutragen, wobei in Beispiel 6.17 entsprechende Werte in /etc/netmasks gesetzt seien. pinta# cat > /etc/hostname.qfe0 pinta-gw ^D pinta# reboot ... pinta> ifconfig qfe0 hme0: flags=1000843 mtu 1500 index 2 inet 10.10.201.10 netmask ffff0000 broadcast 10.10.255.255 wird nur w¨ahrend des Systemstarts gele¨ sen. Eine Anderung in dieser Datei wird folgerichtig erst nach einem Reboot wirksam mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 mtu 1500 index 2 inet 10.10.100.10 netmask ffff0000 broadcast 10.10.255.255 hme0:1: flags=1000843 mtu 1500 index 2 inet 10.10.201.11 netmask ffff0000 broadcast 10.10.255.255 hme0:2: flags=1000843 mtu 1500 index 2 inet 10.10.201.18 netmask ffff0000 broadcast 10.10.255.255 des entsprechenden Interfaces wie folgt zu konfigurieren: Es ist pro logischem Interface eine Zeile der Form addif Konfigurationsdateien der betreffenden physikalischen Interfaces zu setzen, wie es in Beispiel 6.22 gezeigt ist. Der Eintrag f¨ ur die Konfiguration des physikalischen Interfaces muß in der ersten Zeile in dieser Datei stehen, andernfalls wird versucht, die Option addif als Hostname des Interfaces zu konfigurieren. pinta addif addif addif definiert logische Interfaces folgen, w¨ahrend des Systemstarts22 ausgelesen und ausgewertet. 22 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 lo0:1: flags=2001000849 mtu 8232 index 1 zone mza inet 127.0.0.1 netmask ff000000 lo0:2: flags=2001000849 mtu 8232 index 1 zone mzb inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.100.3 netmask ffffff00 broadcast 10.10.100.255 ether 8:0:20:c4:b3:34 hme0:1: flags=1000843 . . . → mtu 1500 index 2 zone mza inet 10.10.100.70 netmask ffffff00 broadcast 10.10.100.255 hme0:2: flags=1000843 . . . → mtu 1500 index 2 zone mzb inet 10.10.100.71 netmask ffffff00 broadcast 10.10.100.255 mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0:1: flags=1000843 . . . → mtu 1500 index 2 inet 10.10.100.70 netmask ffffff00 broadcast 10.10.100.255 zu erzeugen und der geeigente Hostname innerhalb dieses VLans in der Datei zu spezifizieren oder es ist direkt die VLan IP Hostadresse in der /etc/hostname. anzugeben. Mit zuvor berechnetem Beispiel eines bge1-Interfaces im VLan 10 muß eine Datei /dev/hostname.bge10001 erzeugt werden, in der ein u ¨ber die /etc/inet/hosts aufl¨ osbarer Hostname oder direkt eine IP-Adresse steht. Im Beispiel 6.26 ist das kurz dargestellt. Nach einem Systemboot wird das entsprechende VLan Interface bereit stehen. nova# cat >/dev/hostname.bge10001 nova-vlan10 ^D nova# cat >>/etc/inet/hosts 192.168.10.72 nova-vlan-10 ^D nova# reboot. Die Instanznummer ist zu entwickeln. Bei Sun Sparc Systemen geht dies recht einfach. Es wird die PCI Slotnummer, die Anzahl an fp-Ports auf der betreffenden FCAL-Karte und die I/O-Bord Slotnummer gebraucht. In Gleichung 6.125 wird daraus die Busnummer in dezimal berechnet. Es wird der Hexadezimalwert dieser Busnummer ben¨otigt. Slot# ∗ #P orts on Card + IOBord Slot# = Bus# mtu 65280 index 5 inet 174.192.10.10 netmask ffffff00 broadcast 174.192.10.255 ether 0:e0:8b:24:64:10 saturn# ping 174.192.10.17 174.192.10.17 is alive saturn# telnet 174.192.10.17 Trying 174.192.10.17 Connected to endeavour. Escape character is ’^]’. login:^D gel¨oscht, 5. /etc/defaultdomain gel¨ oscht, 6. die Zeitzone auf PST8PDT in /etc/TIMEZONE gesetzt, 7. alle Netzwerkinformationsdienste abgeschaltet, 8. /etc/inet/netmasks gel¨ oscht, 9. /etc/defaultrouter gel¨ oscht, 10. der root-Passworteintrag in /etc/shadow gel¨oscht, 11. /etc/.rootkey gel¨ oscht, 12. /etc/resolv.conf gel¨ oscht, /etc/nodename /etc/inet/hosts /etc/net/*/services 2. Bei Bedarf ist /etc/defaultdomain /etc/defaultrouter sowie der verwendete Namensdienst anzupassen. 3. Bis Solaris 9 mußten zus¨ atzlich noch die Konfigurationsdateien /etc/net/*/hosts auf den neuen Hostnamen umgestellt werden, bei OpenSolaris werden diese Konfigurationsdateien nicht weiter ben¨otigt. Sie wurden ersetzt durch ein anderes auf der /etc/netinfo asierendes Verfahren (die /ec/netinfo ist nicht weiter umzustellen, sie enth¨alt keine Hostnameninformationen). 4. Anschließend ist mit uname(1) und hostname(1) weiter zu verfahren. 5. Alle von dem Hostnamen, Nodenamen abh¨angigen Dienste sind u ¨ber den neuen Hostnamen in Kentnis zu setzen (kill -1 ... oder Restart der Applikation).. Somit ist beispielsweise f¨ ur eine DLPI Aggregation aggr1 die Sequenz: Konfiguration des IP Service ifconfig aggr1 plumb Konfiguration einer IP-Adresse ifconfig aggr1 10.10.10.10/24 up einzugeben um ein IP Interface auf eine DLPI Aggregation zu konfigurieren und damit u ¨ber eine Interfacegruppe Pakete zu versenden und zu empfangen. Dazu bedarf es seitens des Netzwerkswitches einer Konfigurationsm¨oglichkeit mtu 1500 index 9 inet 10.10.100.61 netmask ffffff00 broadcast 10.10.100.255 ether 0:d:60:9a:a4:a, wobei key die Keynummer der Aggregation ist, automatisch konfiguriert werden, es k¨onnen logishe Interfaces auf den Aggregationen konfiguriert werden und die Data Link Provider Interface Aggregationen sind in IPMP Interfacegruppen konfigurierbar. Data Link Aggregationen sind in SolarisExpress Solaris 11 Build 28 neu hinzugekommen und noch vergleichsweise unbekannt. ausgewertet. Unter Benutzung des neuen ifconfig-Subcommands addif werden mit dem qfe0 Beispielkonfigurationsfile in Listing 6.4 zwei logische Adressen zus¨atzlich aufgesetzt. nova addif 10.20.200.5 netmask 255.255.255.0 broadcast 10.20.200.0 up addif 10.20.200.6 netmask 255.255.255.0 broadcast 10.20.200.0 up 1 # Defaultroute gesetzt pinta# route delete default 1 # Defaultroute geloescht: Konfigurations¨ anderungen werden ab dem angegebenen alternativen Rootverzeichnis ausgef¨ uhrt (JumpStart etc.) -e -d -r: Die Optionen -e (enable/aktivieren), -d (disable/deaktivieren) und -r (revert/auf Default zur¨ ucksetzen) wirken auf die Variablen ipv4-forwarding: aktiviert/deaktiviert das IPv4 Forwarding, wie zu Solaris 9 Zeiten durch /usr/sbin/ndd -set /dev/ip ip forwarding <0|1> ein oder ausgeschaltet wurde. ipv4-routing: Steuert den Start eines Routing-Daemons. Ist das Konfigurationsfile /etc/defaultrouter existent, ist das Routing deaktiviert. Bei Aufruf mit der Option -e wird der /usr/sbin/in.routed gestartet. ipv6-forwarding: Ein- beziehungsweise Abschalten des v6 Forwarding. ipv6-routing: Ein- beziehungsweise Abschalten des v6 Routing, wobei bei einem Start der /usr/lib/inet/in.ripngd gestartet wird. Forwarding- oder Routingfunktionalilt¨ at ist ein routadm -u notwendig um die Neueinstellung zu u ¨bernehmen. Da routeadm(1M) bei entsprechender Kommandierung von sich aus Routing Daemons sowohl f¨ ur IPv4 als auch IPv6 startet, ist es sinnvoll, auch eine Konfigurationsm¨oglichkeit zu bieten, welche Daemon Prozesse das Routing durchf¨ uhren sollen. Das geht mit der Option -s . Die unterst¨ utzten Variablen sind: ipv4-routing-daemon=: Angaben des zu startenden Routing Daemon mit vollst¨ andiger absoluter Pfadbeschreibung. Per Default wird /usr/sbin/in.routed verwendet. ipv4-routing-daemon-args=<args>: Kommandozeilen- beziehungsweise Aufrufargumente des spezifizierten Routing Daemons ipv4-routing-stop-command=<args>: Kommando zum stoppen des Routing Daemons. Per Default wird unter Verwendung der Information aus PIDrun File der Daemon direkt terminiert mit kill -TERM “cat /var/run/in.routed.pid“ ipv6-routing-daemon=: Angaben des zu startenden Routing Daemon mit vollst¨ andiger absoluter Pfadbeschreibung. Per Default wird /usr/lib/inet/in.ripngd verwendet. ipv4-routing-daemon-args=<args>: Kommandozeilen- beziehungsweise Aufrufargumente des spezifizierten Routing Daemons ipv4-routing-stop-command=<args>: Kommando zum stoppen des Routing Daemons. Per Default wird unter Verwendung der Information aus PIDrun File der Daemon direkt terminiert mit kill -TERM “cat /var/run/in.ripngd.pid“ Damit ist das dynamische v4 Routing zu aktivieren durch Aufruf des Kommandos routeadm -e ipv4-routing&& routeadm -u L¨oschen einer Netzroute mit dem Kommando route delete net Setzen einer Hostroute mit dem Kommando route add host L¨oschen einer Hostroute mit dem Kommando route delete host So gesetzte Routingeintr¨ age sind statisch. Das Kommando route(1M) unterst¨ utzt die Optionen -f: Mit den Unteroptionen inet f¨ ur IPv4 und inet6 f¨ ur IPv6 wird die entsprechende Routingtabelle von allen Gatewayeintr¨agen bereinigt. Per Default angewendet auf IPv4 Tabellen. Wird ein -f einem Subkommandoaufruf vorangestellt, werden erst die Eintr¨age geflushed bevor das Subkommando ausgef¨ uhrt wird. -n: Die Aufl¨ osung von Host- und Netzwerksnamen wird nicht durchgef¨ uhrt, es werden numerische Informationen ausgegeben. -v: Verbose Mode, detaillierte Ausgabe -q: Jegliche Ausgabe wird unterdr¨ uckt (Scripting) Und die Subkommandos add: Hinzuf¨ ugen einer Route, eines Routingeintrages change: Modifizieren eines Routingeintrages ( Gateway etc.) delete: L¨oschen einer Route, eines Routingeintrages flush: L¨oschen aller Gatewayeintr¨ age get: Anzeige einer Route, bzw. eines Routingeintrages f¨ ur einen Zielpunkt monitor: St¨ andiges Monitoring der Routingtabelle auf Modifikationen und Fehlerausgaben. ¨ 6.6.4 Uberpr¨ ufen der Routingfunktionalit¨ at Die Routingeinstellungen k¨ onnen mit dem Kommando netstat(1M) aufgelistet werden. die Angabe der Option -r gibt die Routingtabelle aus, wie in Beispiel 6.34 wiedergegeben. sunrise# pkill -9 sendmail sunrise# pgrep sendmail inetd_generic.xml prophist volatile *:default.log restore_repository name_servcice.xml sqlite repository_door ns_files.xml svc.configd ns_nis.xml svc.startd sbin capture log svcadm method <Method Logfiles> svccfg console−login manifest bin fs−local application svcs font fs−root svcprop management fs−usr print manifest−import security monitor x11 seed device global.db milestone nonglobal.de multi−user−server.xml share multi−user.xml fs_include.sh name−services.xml krb_include.sh network.xml net_include.sh single−user.xml smf_include.sh sysconfig.xml network telnet.xml platform site <sitespecific> system cron.xml device filesystem autofs.xml security svc restarter.xml), ctstat und svcs -v zu erkennen und sei hier kurz am Beispiel eines in.telnetd-Starts in den folgenden Listings vorgestellt. Zun¨achst wird in Listing 7.14 u uft ob der telnetd seitens der Service ¨berpr¨ Management Facility aktiviert ist, es ist zu erkennen, daß der Service aktiviert ist und keine Contract ID gelistet wird. nova> svcs -v| grep telnet STATE NSTATE STIME CTID ... online 22:11:03 ...’ Die Belegungen sind: require all:’ , ist Instanzname und Status verzeichnet. Zum Schluß folgt in dem Abschnitt zwischen und die Spezifikation zugeh¨ origer Dokumentation wie beispielsweise Manpages etc., welche mit dem Kommando svcs -x <Service> unter den Punkten See:, wie in Beispiel 7.4 auf Seite 448 gezeigt, aufgelistet werden. Zusammenfassend: Eine vollst¨andige Servicebeschreibung beinhaltet: • 4 clock daemon (cron) <documentation> <manpage title=’cron’ section=’1M’ manpath=’/usr/share/man’ /> <manpage title=’crontab’ section=’1’ manpath=’/usr/share/man’/> ), sondern von Milestones. Ein Milestone beschreibt eine Menge von Diensten, die aktiviert sein muß um den betreffenden Milestone zu erreichen. Es wird unterschieden in Milestone korrespondierender Runlevel single-user S multi-user 2 multi-user-server 3 Tabelle 7.3. Haupt Milestones. Seit OpenSolaris ist dies vereinfacht durch den Aufruf von inetadm disable ftp Wobei der Aufruf von svcadm disable network/ftp die gleiche Wirkung hat. ¨ Hier sei die Eingabe von svcs -a empfohlen, um eine Ubersicht der durch die Service Management Facility verwalteten Services zu erhalten. 7.1.5 SMF Desaster Recovery Zuvor wurde in 7.1.3 dargelegt, daß die Service Management Facility im Wesentlichen nur auf das Repository unter /etc/svc/repository.db zugreift, um als zu starten definierte Dienste zu starten und darauf zu achten, diese Dienste nachzustarten, sollten sie abnorm terminieren. In 4.3.5.2 wurde dargelegt, daß die Service Management Facility bei einem Systemboot durch init(1) gestartet wird und letztendlich unter Beachtung der definierten Abh¨angigkeiten das System in den Zielrunlevel bringt. Es kann jedoch passieren, daß das Repositoryfile defekt ist, die Boot-Repositories defekt sind, oder gar /etc/svc leer ist. Das System kann damit im Prinzip nicht mehr Starten. Auch k¨onnen keine Daemonprozesse wie rshd(1M), sshd(1M) etc. mehr gestartet werden, womit der Zugriff von Außen gesperrt ist. Wann immer die /etc/svc/recovery.db korrupt oder fehlerhaft ist und das Service Management Facility dies erkannt hat, typischerweise durch Anfrage zu einem zu startenden Prozeß oder eine direkte Anfrage an Service Management Facility, etwa das Auflisten aller Dienste per svcs-Aufruf, wird auf der Systemconsole /dev/console die in Listing 7.28 zitierte Ausgabe beziehungsweise administrative Aufforderung ausgegeben. Mit der in Listing 7.28 notierten Ausgabe bzw. Administrationsaufforderung bietet OpenSolaris in diesen F¨ allen Recoveryprozeduren an, die dem Administrator M¨ oglichkeiten an die Hand geben, das Repository zu restaurieren. Dazu ist auf Informationen außerhalb der Service Management Facility zur¨ uckzugreifen, womit sich die administrative Sicht auf die Service Management Facility erweitert, um die XML-Files im Filesystem und deren Reimport repository-boot- mehrere Generationen von Backupkopien der repository.db Link auf letztes repositoryrepository-manifest import manifest import- repository-manifest import- mehrere Generationen von Manifestimporten repository.db Das Repository selbst Tabelle 7.5. Backupfiles der Service Management Facility Files zur¨ uckgegriffen. Alle nach Erstellung der aktuellsten Boot-Backup-Kopie durchgef¨ uhrten Modifikationen am SMF-Repository sind damit verloren und m¨ ussen bei Bedarf manuell nachgefahren werden. Bei Verfahren 2, wenn kein integres Boot-Repository existiert, kann aus dem letzten Manifestimport restauriert werden. In diesem Fall werden die repository-manifest import- verwendet, und wenn das nicht geht, bleibt als letzte M¨oglichkeit, das initiale Repository-File von /lib/svc/seed/global.db nach /etc/svc/repository.db zu kopieren und den Import aller verzeichneten Dienste erneut durchzuf¨ uhren. Hierbei gehen allerdings alle Anpassungen die auf dem System durchgrf¨ uhrt wurden verloren, sie sind somit mit svcadm(1M) oder svccfg(1M) nachzufahren. Sollte aus irgendeinem Grund DROP INDEX BEGIN TRANSACTION DROP TABLE ROLLACK TRANSACTION DROP TRIGGER COMMIT TRANSACTION DROP VIEW END TRANSACTION COPY EXPLAIN INSERT PRAGMA REINDEX REPLACE DETACH DATABASE Tabelle 7.7. SQLite sql Interface verzeichnet gewesen. 7.2.1 Netzwerkweites Logging auf einem zentralem Loghost Die Meldungen der Syslog Daemonen sind besonders in der forensischen Analyse von sicherheits,– und betriebsrelevanten Vorf¨allen von Bedeutung. Es empfiehlt sich daher aus verschiedenen Gr¨ unden, wichtige Meldungen an einer zentralen, besonders gesicherten Stelle mitloggen zu lassen: • Die Meldungen auch mehrerer Systeme stehen an zentraler Stelle, und sind in der Folge leichter auswertbar, da nicht die Logfiles auf jedem System einzeln abgerufen und ausgewertet werden m¨ ussen. • Die Meldungen auch mehrerer Systeme stehen in chronologischer Reihenfolge, Abh¨angigkeiten der Systeme voneinander werden deutlich. • Die Meldungen haben eine einheitliche Zeitbasis. Abweichungen und Manipulationen an einzelnen Systemen sind hierdurch u ufbar. ¨berpr¨ Abh¨angig von der H¨ ohe des Sicherheitsbedarfes kann es an dieser Stelle sogar erforderlich sein, die Meldungen zentral auf einem nicht nachtr¨aglich verf¨alschbaren Medium, beispielsweise einem Teletype Terminal als Console, einem Drucker, einem u ¨ber serielle Schnittstelle eingebundenem logging device ohne Netzwerkzugang, oder einem WORM–Medium (Write Once Read Many) mitloggen zu lassen. Zusammen mit der Option des syslogd(1M) Zeitstempel zu generieren, ist hier¨ uber eine gute Verifizierbarkeit der Logdaten gegeben. Ein Beispiel f¨ ur eine solche Konfiguration ist in der Graphik 7.12 auf Seite 482 aufgezeigt. 7.2.1.1 Netzwerk Devices Zahlreiche integrierte Devices sind ebenfalls in der Lage Meldungen an einen netzwerkweiten syslogd(1M) abzugeben. Hierzu geh¨oren beispielsweise die Router, Switches und Firewalls des Herstellers Cisco, die T3 Storage Arrays des Herstellers Sun, und die System Controller der msg–Maschinenklasse SF[3800..6800] des Herstellers Sun. <service_fmri value=’svc:/network/inetd:default’ /> <exec_method type=’method’ name=’inetd_start’ exec=’/usr/sbin/in.tftpd -s /tftpboot’ timeout_seconds=’0’> <method_context> <method_credential user=’root’ group=’root’ /> tftp ] eingeben Bei multiplen CD-Laufwerken wird f¨ ur jedes Laufwerk ein /cdrom/cdrom* angelegt. Bei zwei Laufwerken unter vold-Kontrolle somit /cdrom/cdrom0 und /cdrom/cdrom1. Wird in diesem Fall mit eject ohne Angabe des Laufwerks eine CD ausgeworfen, so wird die erste in der Liste der gemounteten Laufwerke ausgeworfen. spezifiziert werden. #NFS CLIENT VERSMAX=4 H¨ ochste durch den Client unterst¨ utzte Version des NFS Protokolles. Da zuerst versucht wird eine Verbindung mit der h¨ ochstm¨ oglichen Version auszuhandeln kann es sinnvoll sein, an dieser Stelle eine niedrigere Version einzutragen wenn die Server, von denen Filesysteme u ¨ber NFS gemountet werden sollen, ohnehin keine h¨ ohere Version unterst¨ utzen. Erlaubt die Verwendung des Version 4 Dele#NFS SERVER DELEGATION=on gationsfeatures Anweisung an den nfsmapid Daemon nicht #NFSMAPID DOMAIN=domain die DNS-Domain sondern die an dieser Stelle explizit genannte Domain zu verwenden Tabelle 7.19. Parameter zu NFS in /etc/default/nfs"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o rw -d "menkar:export" /export[email protected] > alle NFS-seitig exportierten Filesysteme einer in der lokalen /etc/hosts des mount-Clients mit einem IP-Hostname Paar verzeichneten Maschine durch ein einfaches Ansprechen des u ¨berwachten Mountpunktes automatisch gemountet werden. So wurden beispielsweise durch ein ls /net/asv1 alle exportierten Filesysteme des NFS Servers asv1 gemountet. Dies konnte durch beliebige Benutzer des Mount-Clients initiiert werden. Mit den neueren Solaris-Releases, so auch mit OpenSolaris, ist es ausreichend eine IP-Adresse unter /net zu referenzieren. Sei also wie in Abbildung 7.23 ein NFS-Server asv1 im Netz und wie in Abbildung 7.24 ein NFS-Server asv2 f¨ ur diesen erreichbar, jeweils mit exportierten Fi- auf die vom Rechner exportierten Verzeichnisse zuzugreifen. -xfn: Wird z.B. durch die Applikation SunRay genutzt. Es k¨onnen weitere explizite Maps bei Bedarf erzeugt und eingebunden werden, die Zahl und die Namen der impliziten Maps sind zur Zeit auf zwei begrenzt (-hosts, -xfn). 7.7.6 Erstellung und Modifikation der Automountermaps Es sind durch die Solaris Betriebssysteminstallation bereits zwei Automounter Maps erstellt worden. Zum einen die auto master, zum anderen eine recht simple, weil nur auf die Eintr¨ age in Namensdiensten verweisende, auto home. 7.7.6.1 Format der Automountermaps Der grunds¨atzliche Aufbau von Automountermaps folgt nachfolgender Struktur: key das CD-Laufwerk sofort wieder frei, sofern es nicht busy ist. Siehe hierzu auch den Abschnitt 7.4, Wechselmedienmanagement ab Seite 505. 7.7.11 Autofs Debugging Der Automounter bot bis Solaris 9 eine einfache und praktische Methode des Debugging. Der Automounter bietet eine spezielle Map, unter der alle von Rechnersystemen nfs-exportierten Filesysteme erreichbar sind. Per Default wird diese Map unter /net referenziert. In der Automounter Konfigurationsdatei /etc/auto master ist dies verzeichnet mit # Master map for automounter # /net -hosts ausf¨ uhrt, erh¨alt er eine Fehlermeldung, daß obiges Kommando nicht gefunden wurde. F¨ ur den Automounter selbst ist dies jedoch ein Signal, Debuginformationen auf der Console auszugeben. Dabei gelten die in Tabelle 7.28 angegebenen Debuglevel. Verboseflag: AUTOMOUNT VERBOSE=TRUE/FALSE Verboseflag, Daemon: AUTOMOUNTD VERBOSE=TRUE/FALSE und kann einem Administrator durchaus von Hilfe sein, da sowohl Informationen u oste Anfragen, nicht aufgel¨oste Map-Expansionen etc. ¨ber nicht aufgel¨ als auch Zugriffsrestriktionen des Servers oder nicht herausnehmbare Mountpunkte (busy) des Clients mit angezeigt werden.[email protected] 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. bin dev etc pub usr 226 Transfer complete. 25 bytes received in 0.0073 seconds (3.37 Kbytes/s) ftp>]]* ::= ::= <status> ::= ":" [<source> "[" + "]" <status> "=" "success" | "notfound" | "unavail" | "tryagain" ::= 0...MAX_INT eine durch den nscd(1M) gecachte Tabelle, wie etwa hosts, passwd etc ist. Einige Beispiele im Beispiel 7.25 zeigen schnell die Funktion. Wenn also das standardisierte Interface des nscd(1M) verwendet wird, ist dem anfragenden Prozess im Prinzip verborgen, aus welcher Art Namensdienst die Antwort kommt, oder anders gesagt, ein Programm muß nicht vor der Anfrage wissen, welcher Namensdienst zu verwenden ist und damit eine spezialisierte Anfragefunktion f¨ ur jeden erdenklichen Namensdienst bereithalten. Im Prinzip eine Art Virtualisierung durch Abstraktion von der Dienstspezifikation. 7.11.6 Service Management Facility Einbindung des nscd Seit Einf¨ uhrung der Service Management Facility in OpenSolaris wird auch der Name Service Cache Daemon u ¨ber diese Facility verwaltet. Dies l¨aßt sich schnell erkennen, etwa wie in Listing 7.61 zusammengestellt. Demnach wird der Name Service Cache Daemon direkt u ¨ber die Service Management Facility verwaltet, denn der Holder Prozeß ist der svc.startd. Das Ergebnis eine ptreeAufrufes best¨atigt dies, in dem beigef¨ ugten Beispiel ist die Contract ID 24. ausf¨ uhren 4. NIS-Client initialisieren: ypinit -c Es folgt eine interaktive Abfrage nach den NIS-Servern 5. Solaris 9: /usr/lib/netsvc/yp/ypstart ausf¨ uhren 6. OpenSolaris: svcadm enable nis/client Im Zusammenhang mit dem Betrieb des NIS-Clients unter OpenSolaris sind mit dem Service Management Facility Idenitfier ausf¨ uhren 4. NIS-Client initialisieren: ypinit -c-o nobanner ¨ andern. Schon bei Solaris 9 wurde dies nicht mehr unterst¨ utzt. Die Modifikation des Interfacescriptes war lange Zeit ein Workaround, wurde jedoch sp¨ aterhin auch verhindert bzw. ignoriert. Ein aktueller Workaround ist es, das lp-Binary beispielsweise in ein Directory /usr/bin/sunlp zu verschieben und unter dem Namen /usr/bin/lp ein Shellscript zu erzeugen, was die gew¨ unschten Printoptionen h¨alt, etwa wie es im Beispiellisting 7.65 gezeigt ist, es ist zu beachten, daß explizit u uft wird, ¨berpr¨ ob der Druckbefehl “lp” hieß. Dieser Workaround ist sicher kein sehr sch¨oner, jedoch praktikabler Weg. Alternativ kann auch auf ein anders Printersystem gewechselt werden, wie beispielsweise cups. #!/bin/lp /usr/bin/sunlp/lp -o nobanner $*[email protected] PSTAMP=Steve Christensen BASEDIR=/usr/local CLASSES=none an pkgadd u ¨bergeben werden kann und dann als Eingabe auf die pakets¨ pezifischen Fragen genommen wird. Bei jeder Anderung der Abfragescripte seitens des Paketerstellers ist diese Datei mit den Antworten erneut zu erstellen. In der Praxis findet dieses Verfahren wegen der eher umst¨andlichen Processing package instance <SMCrcs> from rcs (sparc) 5.7 Walter F. Tichy et al Using as the package base directory. ## Processing package information. ## Processing system information. 1 package pathname is already properly installed. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. The following files are already installed on the system and are being used by another package: /usr/local/bin /usr/local/doc /usr/local/man /usr/local/man/man1 Do you want to install these conflicting files [y,n,?,q] y ## Checking for setuid/setgid programs. Installing rcs as <SMCrcs> ## Installing part 1 of 1. /usr/local/bin/ci .... [ verifying class <none> ] Installation of <SMCrcs> was successful. Determining if sufficient save space exists... Sufficient save space exists, continuing... Installing patches located in /9_Recommended Using patch_order file for patch installation sequence Installing 114008-01... Installation of 114008-01 failed. Return code 2. Installing 112998-03... ..... The following patches have been installed on the System: 112233-07 112975-02 113573-02 114375-06 112601-07 112998-03 ... The following patches were not able to be installed: 114008-01 ... For more installation messages refer to the installation logfile: /var/sadm/install_data/Solaris_9_Recommended_log Use ’/usr/bin/showrev -p’ to verify installed patch-ids. Refer to individual patch README files for more patch detail. Rebooting the system is usually necessary after installation.EOF-Marken, gefolgt von einem fsf eom an das Ende des Bandes rewind an den Anfang des Bandes offline rewind + Bandauswurf (wenn m¨ oglich), oder Band unzugreifbar schalten. erase Band l¨oschen status Status ausgeben Ein Beispiel: Es befindet sich ein Band in dem unter dem Pfad /dev/rmt/0hn erreichbaren Bandlaufwerk, die Environmetvariable $TAPE sei entsprechend gew¨ahlt. • Betriebsrelevante Systempakete in dem eigenen Zone Rootfilesystem. Zones sind per Kommando zu erzeugen. Es werden das Zone Rootfilesystem erzeugt, optional logische Devices u ¨bergeben, die Zone initialisiert und gestartet. Zur Erzeugung und zur Administration werden zwei Kommandos bereitgestellt: zoneadm(1M) Erzeugung des XML Zonekonfigurationsfiles Installation der Betriebssystemkopie im Filesystem der Zone, Start, Stop, Reboot zonecfg(1M) Konfiguration, mit interaktivem Kommandointerpreter zur Modifikation des XML Konfigurationsfiles der einzelnen Zones. zonecfg -z . . . create zoneadm -z install zoneadm -z ready zoneadm -z boot Interaktiv Interaktiv zoneadm: cmds: [halt|boot. . . ]install, mit erzeugt wird. Schritt drei ist im Prinzip die Erstellung des XML Zonekonfigurationsfiles per Kommandointerpreter. Man kann letztendlich auch das Konfigurationsfile in /usr/share/lib/xml/dtd/zonecfg.dtd.1 zu Rate ziehen. Nach Erzeugung einer Zone kann schon eine Consolesession auf die erzeugte Zone mit dem Kommando zlogin -C [ er¨ offnet werden, so, daß man beim Start auch gleich die Bootmessages sehen kann, und sich nach Ausgabe des Console Loginprompts sogleich an der Zone einloggen kann. Nach der Erstellung des XML Zonekonfigurationsfiles bei bereits erzeugtem und installierten Rootfilesystem der Zone ist die Zone zu starten, wie es in Tabelle 9.16 in Schritt f¨ unf beziehungsweise sechs gezeigt ist. Sodann bootet die nonglobal Zone. Ist es der erste Boot einer ordnungsgem¨aß per zoneadm -z install erstellten nonglobal Zone, so werden bei diesem ersten Boot die Servicemanifeste der Zone in der Zone geladen. Ebenfalls beim ersten Boot wird die Systemidentifikation auf der Zoneconsole interaktiv abgefragt, es sei denn, es wurde ein den Bedingungen gen¨ ugendes File sysidcfg in das. Damit befindet man sich in einer interaktiven Sitzung. Ist die Zone zu diesem Zeitpunkt noch nicht konfiguriert, so ist das erste notwendige Kommando ein create, in der Abbildung nicht weiter dargestellt. Man befindet sich im Zustand configured. Wird nun beispielsweise mit dem Kommando add ein Ressourcetype hinzugef¨ ugt, verl¨aßt man die Grundebene, die in der Sun Dokumentation global scope genannt ist, und wechselt in die Ressourcetypebene, bei Sun resource scope genannt. In der resource scope k¨onnen nun Properties des jeweiligen Ressourcetypes gesetzt werden. In dem Graph in Abbildung 9.9 sind zwei Beispiele f¨ ur eine solche Ressourcendefinition gezeigt. Zuerst ein expizites Beispiel, in dem in den Ressourcetyp fs f¨ ur Filesystem gewechselt wird und die Property dir=/mnt gesetzt wird. Anschließend kann mit end wieder in die global scope zur¨ uckgewechselt werden, oder es kann durch Aufruf des Kommandos cancel der resource scope ohne Sicherung der Einstellungen wieder verlassen werden. Der zweite Teil des Beispieles ist allgemein gehalten. Dort wird ein add ResTyp=/ aufgerufen, also ein beliebiger definierter Resourcetype (fs, device, etc.), es k¨onnen sodann sinnvolle zugeh¨orige Properties gesetzt werden und es kann mit end sichernd, oder auch wieder mit cancel verwerfend die resource scope Ebene verlassen werden. Das Beispiel soll auch die Verwendung von commit, revert und exit zeigen. Das erste Teilbeispiel, die Definition einer Filesystemressource wurde committet. Wird nun nach der zweiten x-beliebigen Ressourcetypekonfiguration nach Beendigung per end Kommando das Kommando revert aufgerufen, so wird die aktuelle Konfiguration verworfen und wieder auf den letzten committeten:<status>: 1 2 3 Wobei die Belegung wie in Tabelle 9.17 dargelegt genutzt wird. Spalte Belegung 1 Der Name der Zone 2 Status der Zone 3install aufgesetzt, so werden die notwendigen Pakete u ¨ber das Solaris Packagesystem identifiziert und installiert. Das Zonerootverzeichnis, in den hier vorgestellten Beispielen sind dies /export/zones/mz? muß jeweils das Zugriffsrecht “rwx------” oder auch 700, haben, anderenfalls wird die Zonenenkonfiguration beim verify durchfallen und die Zone kann nicht gebootet werden. In Beispiel 9.59 ist dies menkar# ls drwx-----drwx-----drwx-----drwx-----drwx-----drwx-----menkar# ls total 4 drwxr-xr-x drwxr-xr-x menkar# ls bin@ dev/ etc/ die Definition f¨ ur die zu verwendenden Systemressourcen. Wer Zones auf minderausgestatteten Systemen testen m¨ ochte, muß auch nicht gleich zwei CPUs f¨ ur die Zone abstellen und kann auf eine Ressourcelimitierung vorerst verzichten. Im Produktionsbetrieb ist eine Ressourcenlimitierung jedoch sinnvoll, siehe hierzu auch die Diskussion in Abschnitt 8.3.2 ab Seite 634. In dem Beispiel folgt ein Kommentar zur Zone, abgeschlossen mit einem nachtr¨aglich definierten Verzeichnis, hier testweise /opt/csw. Die gesamte Zonedefinition ist eingeschlossen in die Zone-Klammer, womit die Definition mit wieder abgeschlossen werden muß. Die Zone ist damit im Prinzip konfiguriert. Wer etwas XML beherrscht, kann dieses File selbstverst¨andlich manuell erzeugen oder anpassen. Es liegen sogar Templates in /etc/zones daf¨ ur bereit: SUNWblank.xml, was ein leerer Rumpf ist, und SUNWdefault.xml, wo schon einige Definitionen zu Verzeichnissen etc. vorgegeben sind. Ein guter erster Einstieg mag jedoch in der Tat die Verwendung der Konfigurationsshell, gestartet durch Aufruf des Kommandos zonecfg(1M), sein. Nachfolgend wird, Schritt f¨ ur Schritt an einigen Bespielen gezeigt, welche Konfigurationskommandierung welche Eintr¨ age in einem Zonenkonfigurationsfile zur Folge haben. /masterconsole Master Seite der Zone Console Softlink auf /devices/pseudo/zconsnex@1/zcons@0:masterconsole./slaveconsole Slave Seite der Zone Console Softlink auf devices/pseudo/zconsnex@1/zcons@0:zoneconsole. Zoneseitig wird im lokalen Filesystem der nonglobal Zone ein Consoledevice unter /dev/zconsole bereitgestellt. Die Console einer Zone wird ge¨ offnet mit dem Kommando zlogin(1) unter Verwendung der Option -C und Angabe der Zielzone, wie in Beispiel 9.64 gezeigt. Es wird in dem Beispiel auch gleich gezeigt, wie das darunterliegende tty heißt: /dev/console der Zone. menkar# zlogin -C mza [Connected to zone ’mza’ console] mza console login: root Password: Last login: Mon Jan 23 01:26:32 on console Sun Microsystems Inc. SunOS 5.11 snv_23 October 2007 Jan 23 02:20:16 mza login: ROOT LOGIN /dev/console mza# tty /dev/console ls -l /dev/console lrwxrwxrwx 1 root root 8 Jan 31 03:01 /dev/console -> zconsole mza# ^D mza console login:). • Welche Pakete des Systems sollen der Zone bereitgestellt werden. • lokale Kopie der Rootverzeichnisses. • Bereitstellung von Filesystemressourcen.Dateien in /etc/der Zone. Die Konfiguration der Interfaces wird bereits durch den Zonelayer verwaltet. Netzwerkinteraces Jede Zone f¨ ur sich hat ein so genanntes Netzwerk Loopbackinterface mit der IP-Adresse 127.0.0.1, jedoch ist dieses Loopbackinterface ein logisches Interface: lo0:*. Dazu kommt, daß f¨ ur jede nonglobal Zone je ein logisches Loopbackinterface in der Global Zone bereitgehalten wird (lo0:1, lo0:2 . . . ). hostname./path/ verf¨ kann pfiles auf neueren Solaris Versionen auch die Pfadnamen zu den offenen Files auflisten. 10.1.16.3 pflags(1) Mit dem pflags Pogramm lassen sich die Trace-Flags, die anstehenden Signale und andere Prozess-Statusinformationen f¨ ur jeden Kernelthread eines Prozesses auflisten. 10.1.16.4 pldd(1) Mit dem pldd Programm lassen sich die dynamischen Bibliotheken, die ein Programm implizit gelinkt hat oder explizit u ¨ber dlopen (3C) angeh¨angt hat, auflisten. 10.1.16.5 pmap(1) Mit dem pmap Programm kann der Adreßraum von Prozessen aufgelistet werden. Dabei werden alle einzelnen Bereiche nach Herkunft (HintergrundSpeicher), Zugriffsrechten, Gr¨ oße und Ladeadresse aufgelistet werden. 10.1.16.6 prun(1) Mit dem prun Kommando k¨ onnen Prozesse, die mit Hilfe des Kommandos pstop angehalten wurden, fortgesetzt werden. Die Aufgabe wird dabei nicht mit Hilfe von Signalen sondern u uhrt. ¨ber das /proc Debug-Interface durchgef¨ 10.1.16.7 psig(1) Mit dem psig Programm werden die Aktionen und Signalhandler von laufenden Prozessen aufgelistet. 10.1.16.8 pstack(1) Mit dem pstack Programm kann ein Stacktrace von laufenden Prozessen ausgegeben werden. Die Ausgabe ist vergleichbar mit dem, was man durch Eingabe von $c und vmcore., wobei der numerische Wert variabel ist, und zwei Dateien mit gleicher Nummer jeweils ein Paar bilden. Wenn man so einen Crash-Dump analysieren will, dann f¨angt man am Besten damit an, daß man mdb n[email protected] mappt eine genullte Seite auf die Adresse 0 und macht dadurch Nullpointerdereferenzierungen nicht fatal. Wenn man auf einfache Weise verifizieren will, ob ein Programmabsturz auf eine Nullpointerdereferenzierung zur¨ uckzuf¨ uhren ist, dann kann man das Programm probeweise auf folgende Weise starten: [email protected] programm Wenn es nun fehlerfrei l¨ auft, dann ist der Beweis erbracht. 1.conf: 3 leave command mode telnet> ... =[wert]% csh(1)-Scripte werden ausgef¨ uhrt, indem eine csh(1) mit dem Scriptnamen aufgerufen wird oder das Ausf¨ uhrungsrecht f¨ ur das Script gesetzt wird. Ein csh(1)-Script ist oft an der ersten Zeile im Scriptfile zu erkennen:. Gesetzte Variablen sind sofort referenzierbar. Auch entf¨allt die Bourne Shell typische var=wert Notation, Variablen werden im CShellenvironment mit setenv gesetzt. 11.8.3.2 Der Library Suchpfad Der Library-Suchpfad ist der Pfad, den der Runtime-Linker durchsucht, um eine geforderte Library zu laden. Der Runtime-Linker l¨adt die Library ld.so. ld.so wird zur Laufzeit die notwendigen Libraries nachladen und durchsucht deshalb die Standardlibraries nach der gew¨ unschten Library und, wenn gesetzt, auch durch alle zus¨ atzlich benannten Library-Pfade. Gesetzt wird die Environmentvariable: LD_LIBRARY_PATH entsprechend der Syntax der verwendeten Shell. So wird der SuchPfad f¨ ur Libraries f¨ ur die csh(1) gesetzt wie folgt: 0 1 dhs@nx1> setenv LD_LIBRARY_PATH /usr/lib:/usr/sfw/lib:/opt/sfw/lib:\ /usr/local/lib ... =[wert] command mode visual mode i,I insert mode o,O line mode (change <word/line/. . . >) Ersetzen des Textes von der Cursorpositon an bis zum Ende der angegebenen Region durch einen beliebig langen Text. Das Ende des zu ersetzenden Bereiches wird durch einen $ angezeigt. ahrend des Schreibens wie im insert Text, der dahinter bereits steht wird w¨ mode nach rechts verschoben.} ok. Die Bannerpage informiert u ¨ber die Anzahl und die Version der eingebauten CPUs, des installierten Speichers, und der Ethernetadresse des Onboard Netzwerkinterfaces./Tools, die Manualpage wird dennoch mit dem System installiert. to Continue or ’q’ to Quit. [Default: c]: stopping: Drive in "ets0" front slot 0....Done offlining: Drive in "ets0" front slot 0....Done Hit after removing the device(s). Drive in Box Name "ets0" front slot 0 Notice: Device has not been removed from the enclosure. It has been removed from the loop and is ready to be removed from the enclosure, and the LED is blinking. Logical Nodes being removed under /dev/dsk/ and /dev/rdsk: Logical Nodes being removed under /dev/dsk/ and /dev/rdsk: c3t0d0s0 c3t0d0s1 c3t0d0s2 c3t0d0s3 c3t0d0s4 c3t0d0s5 c3t0d0s6 c3t0d0s7 to Continue or ’q’ to Quit. [Default: c]: Hit after inserting the device(s). Drive in Box Name "ets0" front slot 0 Logical Nodes under /dev/dsk and /dev/rdsk : c3t0d0s0 c3t0d0s1 c3t0d0s2 c3t0d0s3 c3t0d0s4 c3t0d0s5 c3t0d0s6 c3t0d0s7 und zu sehen. Alle Redundanzinterfaces werden durch den pnmd manipuliert. • Bei einem Adapterfailover bleibt per z.B. ifconfig nur das erste Interface sichtbar, der pnmd schaltet unsichtbar auf ein Redundanzinterface um. • Das Konfigurationsfile wird w¨ ahrend des Starts des pnmds gelesen. • Eine Modifikation des NAFO-Konfigurationsfiles per z.B. Texteditor ist zumindest nicht unterst¨ utzt.members= → [ policy=] [ interval= ] → [ type= ] mtu 1500 inet 172.168.10.87 netmask ffffff00 broacast 172.168.10.0 zur IP Konfiguration des Metanetworkadapters verwendet werden. Die Umschaltung zwischen Netzwerkadaptern verlief relativ einfach und schmerzlos. Im Beispiel einmal hin und wieder zur¨ uck: saturn# apconfig -P mhme0 -a hme1 saturn# apconfig -N -u metanetwork: mhme0 physical devices: hme1 A hme0 P saturn# apconfig -P mhme0 -a hme0 saturn# apconfig -N -u metanetwork: mhme0 physical devices: hme1 hme0 P A sollten gel¨ oscht werden um eine diesbez¨ ugliche Fehlermeldung beim n¨ achsten Reboot zu vermeiden. saturn# ifconfig mhme0 unplumb saturn# apnet -d mhme0 saturn# apconfig -N -u metanetwork: mhme0 D physical devices: hme1 hme0 P A Enter Preferred load host Internet address []:: Enter Preferred dump address []:: Select type of IP packet encapsulation (ieee802/ethernet) [<ethernet]:: Type of IP packet encapsulation: <ethernet> Load Broadcast Y/N [Y]:: warning: OBP/Console inaktiv Plattform Shell console -d Domain Shell aktiv OBP/Console BREAK-Sequenz Domain Shell (OS) aktiv Domain Shell resume /dev/console (OS) aktiv Domain Shell break OBP ¨ Tabelle D.3. Ubergang zwischen den Ebenen des Domainzuganges voraus senden). 377 dumpdates 753 dumpdates(4) 771 ethers 84, 376, 377, 381, 585, 925 exec attr 693, 704–705 format.dat 152 group 585, 685 hostname. 376, 377, 383, 399, 400 hosts 84, 376, 377, 380, 399, 400, 585, 925 inetd 504 inetd.conf 491, 494, 500 inittab 58 IPMP 408 ldap 400 logadm.conf 613 magic 724 mailaliases 585 md.tab 237 minor perm 127 mnttab 161 modname.conf 115 mpathd 408 name to major 120 netconfig 376, 377, 386 netgroup 585 netmasks 376, 377, 385, 399, 585 networks 376, 377, 384, 585 nfs 520 nfslog.conf 528, 529 nfslogd 528 nfssec.conf 529 nodename 376, 377, 378, 400 nsswitch.conf 387, 576 pam.conf 710, 711 passwd 585, 684 path to inst 120, 122 policy.conf 691, 694 prof attr 691, 693, 704 
