Mittwoch Jun 12, 2013

Den root pool erweitern

Zwischendurch mal ein wenig Laptop-Erfahrung...  Ich habe endlich entschieden, dieses zweite OS von der Platte zu verbannen (Ich hatte es so selten benutzt, dass ich regelmaessig das Passwort zuruecksetzen musste...).  Der Ertrag waren 50g wertvoller Laptop-Plattenplatz - gluecklicher Weise an der richtigen Stelle auf der Platte.  In der Theorie muesste ich also nur die Solaris-Partition erweitern, ZFS Bescheid sagen und den Platz geniessen.  Aber natuerlich gibt es da so verschiedene kleine Fallen.

Um Verwirrung vorzubeugen - es geht hier um x86.  Bei einem normalen SPARC Server hat man die Probleme, fuer die ich hier Loesungen beschreibe gar nicht.

Erste Lektion: Man sollte nicht versuchen, mit fdisk die Partition zu veraendern solange Solaris darauf noch laeuft.  Das funktioniert zwar, aber es gibt freundlichere Varianten des Shutdowns.  (Was hier passiert ist, dass fdisk nicht nur die Partition neu anlegt, sondern auch ein dazu passendes Label schreibt.  Das bedeutet allerdings, dass ZFS den Slice fuer den rpool nicht mehr findet.  Und das wiederum fuehrt zu einem sehr introvertierten Solaris...)  Richtig macht man das, indem man von irgendetwas anderem bootet (PXE, USB, DVD, etc) und dann die Partition veraendert.  Danach nicht vergessen, den Slice fuer den ZFS pool wieder anzulegen.  Wichtig dabei ist, dass dieser Slice wieder mit genau dem gleichen Zylinder anfaengt.  Die Laenge ist natuerlich eine andere.  (Ich zumindest musste das so machen, da  mein rpool in s0 lag.)

Danach ging es weiter wie im Handbuch:  Solaris booten und entweder  "zpool set autoexpand=on rpool" oder zpool online -e rpool c0t0d0s0" und schon waren da 50g mehr Platz.

Habe ich vergessen zu erwaehnen, dass ich doch tatsaechlich vor all dem ein volles Backup gemacht habe?  Ich werde doch langsam alt...

Mittwoch Nov 07, 2012

20 Jahre Solaris - 25 Jahre SPARC!

Normalerweise wiederhole ich ja nicht einfach das, was woanders schon steht.  Hier mache ich eine Ausnahme...

20 Jahre Solaris - Und wer hat die ganzen Innovationspreise bekommen?
25 Jahre SPARC - und kein bisschen muede :-)

Wie die Geschichte weiter geht, steht ganz unten auf diesen Seite - also schnell nachsehen...

Und wer's lieber als Video mag: 20 Jahre Solaris - 25 Jahre SPARC

(Kaum zu glauben, ich habe nur die ersten 4 Jahre von Solaris "verpasst".  Die Zeit vergeht wohl doch...)

Dienstag Apr 17, 2012

Solaris Zones: Virtualisierung beschleunigt Benchmarks!

Wenn ich mich mit Kunden ueber Virtualisierung unterhalte ist eine der ersten Fragen oft die nach dem Overhead.  Nun wissen wir ja alle, dass Virtualisierung mit Hypervisoren nicht ohne Overhead zu machen ist.  Was wir ebenfalls alle wissen sollten ist, dass es stark vom Lastprofil und dem verwendeten Hypervisor abhaengt, wie gross dieser Overhead jeweils ausfaellt.  Zwar gab es schon einige Versuche, dies in standardisierten Benchmarks zu quantifizieren.  Dennoch bleibt die Antwort auf diese Frage noch immer in den Nebeln von Marketing und Benchmark-Unschaerfe verborgen.  Erstaunen erlebe ich jedoch regelmaessig, wenn ich zu Solaris Zonen (bei Solaris 10 hiessen sie noch Container) als Alternative zur Virtualisierung mit Hypervisoren komme. Solaris Zonen sind, grob vereinfacht, nichts weiter sind als eine Menge von Unix Prozessen, abgegrenzt durch einen Regelsatz der vom Solaris Kernel durchgesetzt wird.  Daher ist es einleuchtend, dass hier nicht besonders viel Overhead anfallen kann.  Dennoch wird die Behauptung von "Zero Overhead" oft angezweifelt, gerade auch weil vielen heute Virtualisierung per Hypervisor sehr nahe ist.  Und so sehr ich die Erklaerung mit technischen Details ueberzeugend finde, so sehr verstehe ich auch, dass sehen viel besser ist als glauben.   Daher:

Die Benchmark-Teams bei Oracle sind so ueberzeugt von den Vorteilen der Solaris Zonen, dass sie diese fuer die veroeffentlichten Benchmarks verwenden.  Das Solaris Resource Management funktioniert natuerlich auch ohne Zonen, aber Zonen machen es so viel einfacher, insb. in Verbindung mit den teilweise recht komplexen Benchmark-Konfigurationen.  Es gibt zahlreiche Benchmark-Veroeffentlichungen bis zurueck in die Tage der T5440, in denen Solaris Container zur Anwendung kommen.  Einige aktuelle Beispiele, alles Weltrekorde, sind:

Die genaue verwendung der Zonen ist in der jeweiligen Benchmark-Beschreibung dokumentiert.

Darueber hinaus hat das Benchmark-Team in einem Blogeintrag beschrieben, wie sie das Solaris Resource Management und Zonen verwenden, um die Anwendungsleistung zu erhoehen.  Das verleitet fast dazu, von "negativem Overhead" zu sprechen, waere der Begriff nicht so irrefuehrend.

Mittwoch Apr 04, 2012

Folien von den Solaris Tech Days

Mehr ein "oeffentlicher Bookmark" als ein eigener Beitrag:  Die Folien von den deutschen "Solaris Tech Days" sind hier zu finden.  Die Agenda und eine Sammlung von Links zum Thema Solaris 11 als Antwort auf diverse Nachfragen gibt es im Solarium.

Dienstag Mrz 13, 2012

Ein lokaler AI Server - mit Solaris 11 mal eben aufgesetzt

Solaris 11 macht vieles neu, unter anderem auch den Installserver.  Wer, wie ich, seit (gefuehlten) 200 Jahren Jumpstart kennt, muss hier umlernen.  Dabei ist das ganze gar nicht so kompliziert.  Nur eben neu.

Mein Ziel war es, einen AI-Server zu bauen, den ich fuer Demo-Zwecke auch mal im Zug benutzen kann.  Damit sind auch die Hardware-Voraussetzungen klar: Tragbar sollte es schon sein.  Aber schoen der Reihe nach.

Als Erstes braucht man natuerlich ein OS-Image.  Das heisst in der neuen Solaris 11 Welt jetzt Repository.  Das Original dafuer kann man sich von der Solaris 11 Seite bei Oracle herunterladen.  Man braucht dazu das zweiteilige "Oracle Solaris 11 11/11 Repository Image", das man sich dann natuerlich mit cat zusammensetzt.  Die MD5 Pruefsummen gibt es uebrigens ebenfalls auf dieser Seite, nur etwas weiter oben.

Damit ist nun das Repository ganz schnell gemacht:

# zfs create -o mountpoint=/export/repo rpool/ai/repo
# zfs create rpool/ai/repo/sol11
# mount -o ro -F hsfs /tmp/sol-11-1111-repo-full.iso /mnt
# rsync -aP /mnt/repo /export/repo/sol11
# umount /mnt
# pkgrepo rebuild -s /export/repo/sol11/repo
# zfs snapshot rpool/ai/repo/sol11@fcs
# pkgrepo info -s  /export/repo/sol11/repo
PUBLISHER PACKAGES STATUS           UPDATED
solaris   4292     online           2012-03-12T20:47:15.378639Z
Und schon ist das Repository fertig. Zur Sicherheit gleich einen Snapshot anlegen, man weiss nie, wozu der noch gut ist. Um das Repository zu verwenden, koennte man es nun als Publisher auf Dateibasis eintragen:
# pkg set-publisher -g file:///export/repo/sol11/repo solaris
Falls ich das Repository spaeter auch per (virtuellem) Netzwerk verwenden moechte, jetzt noch schnell den Repository-Server aktiviert:
# svccfg -s application/pkg/server \
setprop pkg/inst_root=/export/repo/sol11/repo
# svccfg -s application/pkg/server setprop pkg/readonly=true
# svcadm refresh application/pkg/server
# svcadm enable application/pkg/server

Und schon kann man mit dem Browser auf http://localhost/ einen huebschen Repository-Server bewundern. Schritt 1 ist geschafft.  Das alles ist uebrigens in einem README, das im Repository-Image enthalten ist, gut beschrieben. 

Inzwischen gibt es natuerlich Updates, zu finden in MOS im Oracle Solaris 11 Support Repository Updates (SRU) Index.  Je nach Bedarf kann man diese Updates einfach in das bestehende Repository einpflegen oder sie als eigenstaendige Repositories betreiben.  Diese Updates sind jeweils selbststaendig, d.h. SRU4 enthaelt auch die Updates aus SRU2 und SRU3.  Mit einem kleinen ZFS-Trick kann man auch beides bekommen: Ein Gesamt-Repository und gleichzeitig fuer jedes Update ein eigenes:

# mount -o ro -F hsfs /tmp/sol-11-1111-sru4-05-incr-repo.iso /mnt
# pkgrecv -s /mnt/repo -d /export/repo/sol11/repo '*'
# umount /mnt
# pkgrepo rebuild -s /export/repo/sol11/repo
# zfs snapshot rpool/ai/repo/sol11@sru4
# zfs set snapdir=visible rpool/ai/repo/sol11
# svcadm restart svc:/application/pkg/server:default
Damit ist das normale Repository jetzt auf dem Stand von SRU4. Gleichzeitig gibt es dank der ZFS Snapshots in /export/repo/sol11/.zfs/snapshot/fcs ein gueltiges Repository ohne den Update. Wer moechte, kann dazu natuerlich auch einen zweiten Repository-Service auf einem zusaetzlichen Port betreiben.

Jetzt aber zum Installserver.  Mit nur wenig Lektuere der entsprechenden Dokumentation wird klar, dass man hierzu einen DHCP-Server betreiben muss.  Da ich vermeiden wollte, dass dieser meinem bereits bestehenden DHCP-Server (Teil meiner SunRay Installation) in die Quere kommt, und weil das fuer einen solchen Service sowieso eine gute Idee ist, soll er in einer eigenen Zone installiert werden.  Also erst mal schnell eine Zone erzeugen:

# zfs create -o mountpoint=/export/install rpool/ai/install
# zfs create -o mountpoint=/zones rpool/zones
# zonecfg -z ai-server
zonecfg:ai-server> create
create: Using system default template 'SYSdefault'
zonecfg:ai-server> set zonepath=/zones/ai-server
zonecfg:ai-server> add dataset
zonecfg:ai-server:dataset> set name=rpool/ai/install
zonecfg:ai-server:dataset> set alias=install
zonecfg:ai-server:dataset> end
zonecfg:ai-server> commit
zonecfg:ai-server> exit
# zoneadm -z ai-server install
# zoneadm -z ai-server boot ; zlogin -C ai-server
Beim ersten Boot dann einen Hostnamen und IP-Adresse vergeben, fertig ist die Zone.  Als Publisher fuer Solaris Pakete wie z.B. die AI Pakete verwendet sie dabei zwingend den Publisher der Global Zone. Das Filesystem /export/install ist natuerlich fuer den Installserver gedacht. Diesen gilt es jetzt aufzusetzen:
#zlogin ai-server
root@ai-server:~# pkg install install/installadm
root@ai-server:~# installadm create-service -n x86-fcs -a i386 \
-s pkg://solaris/install-image/solaris-auto-install@5.11,5.11-0.175.0.0.0.2.1482 \
-d /export/install/fcs -i 192.168.2.20 -c 3

Damit ist der Installserver selbst eigentlich schon fertig. Was ist hier passiert? Nun, natuerlich muss man erst einmal die notwendige Software installieren. Mit IPS ist das einfach, ggf. wird auch gleich der benoetigte DHCP-Server mit installiert. Achtung, es gibt zwei verschiedene DHCP-Server in Solaris 11, den aus Solaris 10 und frueher bekannten, und den von ISC. Letzterer wird fuer AI gebraucht. Die SMF-Namen der beiden unterscheiden sich nur wenig, der "alte" DHCP-Server heisst in SMF "svc:/network/dhcp-server:default". Der ISC-Server bringt verschiedene SMF-Services mit. Davon brauchen wir mindestens den Service "svc:/network/dhcp/server:ipv4". Mit dem Kommando "installadm create-service" wird nun ein Installations-Service aufgebaut. Er hat den Namen "x86-fcs", bedient die Architektur "i386" und bezieht sein Boot-Image aus dem Repository des System-Publishers in der Version 5.11,5.11-0.175.0.0.0.2.1482, das entspricht Solaris 11 11/11.  (Die Option "-a i386" in diesem Beispiel ist optional, da der Installserver auf einer x86-Maschine laeuft.) Die Boot-Umgebung fuer die Clients wird in /export/install/fcs angelegt, und der DHCP-Server wird fuer 3 IP-Adressen ab 192.168.2.20 konfiguriert.  Diese Konfiguration findet man in leicht verstaendlicher Form in /etc/inet/dhcpd4.conf.  Auf die gleiche Weise koennte man nun noch einen Service fuer SPARC Systeme aufsetzen.

Jetzt koennte man bereits den ersten Client registrieren und installieren.  Er bekaeme den Standard "solaris-large-server" mit dem Publisher "http://pkg.oracle.com/solaris/release" installiert und wuerde nach dem ersten Booten seine Konfiguration interaktiv abfragen.  Damit wird klar:  Der AI-Server ist eigentlich nur ein Boot-Server, die eigentliche Quelle fuer Pakete kann eine andere sein.  Da ich das so jedoch nicht haben moechte, konfiguriere ich mir meinen Client erst noch ein wenig zurecht.

Die Konfiguration von Install-Clients wird ueber sogenannte Manifeste und Profile gesteuert.  Dabei enthaelt das Manifest Informationen ueber zu installierende Pakete und Dateisystem-Konfiguration (und entspricht damit ein wenig der "rules.ok" Datei von Jumpstart).  Die Profile enthalten darueber hinausgehende Konfigurations-Angaben wie bspw. Root-PW, Primaerer User, IP-Adresse, Tastatur-Layout etc. und entsprechend damit in etwa der alten sysid.cfg. 

Am einfachsten kommt man an ein Template fuer ein Manifest, indem man sich das Default-Manifest vom Installserver geben laesst, dieses modifiziert und das Ergebnis dem Installserver bekannt gibt:

root@ai-server:~# mkdir -p /export/install/configs/manifests
root@ai-server:~# cd /export/install/configs/manifests
root@ai-server:~# installadm export -n x86-fcs -m orig_default \
-o orig_default.xml
root@ai-server:~# cp orig_default.xml s11-fcs.small.local.xml
root@ai-server:~# vi s11-fcs.small.local.xml
root@ai-server:~# more s11-fcs.small.local.xml
<!DOCTYPE auto_install SYSTEM "file:///usr/share/install/ai.dtd.1">
<auto_install>
  <ai_instance name="S11 Small fcs local">
    <target>
      <logical>
        <zpool name="rpool" is_root="true">
          <filesystem name="export" mountpoint="/export"/>
          <filesystem name="export/home"/>
          <be name="solaris"/>
        </zpool>
      </logical>
    </target>
    <software type="IPS">
      <destination>
        <image>
          <!-- Specify locales to install -->
          <facet set="false">facet.locale.*</facet>
          <facet set="true">facet.locale.de</facet>
          <facet set="true">facet.locale.de_DE</facet>
          <facet set="true">facet.locale.en</facet>
          <facet set="true">facet.locale.en_US</facet>
        </image>
      </destination>
      <source>
        <publisher name="solaris">
          <origin name="http://192.168.2.12/"/>
        </publisher>
      </source>
      <!--
        By default the latest build available, in the specified IPS
        repository, is installed.  If another build is required, the
        build number has to be appended to the 'entire' package in the
        following form:

            <name>pkg:/entire@0.5.11-0.build#</name>
      -->
      <software_data action="install">
        <name>pkg:/entire@0.5.11,5.11-0.175.0.0.0.2.0</name>
        <name>pkg:/group/system/solaris-small-server</name>
      </software_data>
    </software>
  </ai_instance>
</auto_install>

root@ai-server:~# installadm create-manifest -n x86-fcs -d \
-f ./s11-fcs.small.local.xml 
root@ai-server:~# installadm list -m -n x86-fcs
Manifest             Status    Criteria 
--------             ------    -------- 
S11 Small fcs local  Default   None
orig_default         Inactive  None

Die wesentlichen Punkte in diesem Manifest sind:

  • Es wird "solaris-small-server" installiert
  • Es gibt ein paar Locales weniger (die ich nicht haben wollte)
  • Als Publisher wird mein in der GZ laufender Package Service auf Adresse 192.168.2.12 verwendet
  • Von dort wird die FCS-Version von Solaris 11 installiert:  pkg:/entire@0.5.11,5.11-0.175.0.0.0.2.0

Auf ganz aehnliche Weise wird jetzt aus einem interaktiv erzeugten Default-Profil eine kleine Menge von Profil-Schnipseln erzeugt, was die Konfiguration von mehreren Clients spaeter leichter macht:

root@ai-server:~# mkdir -p /export/install/configs/profiles
root@ai-server:~# cd /export/install/configs/profiles
root@ai-server:~# sysconfig create-profile -o default.xml
root@ai-server:~# cp default.xml general.xml; cp default.xml mars.xml
root@ai-server:~# cp default.xml user.xml
root@ai-server:~# vi general.xml mars.xml user.xml
root@ai-server:~# more general.xml mars.xml user.xml
::::::::::::::
general.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="system/timezone">
    <instance enabled="true" name="default">
      <property_group type="application" name="timezone">
        <propval type="astring" name="localtime" value="Europe/Berlin"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/environment">
    <instance enabled="true" name="init">
      <property_group type="application" name="environment">
        <propval type="astring" name="LANG" value="C"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/keymap">
    <instance enabled="true" name="default">
      <property_group type="system" name="keymap">
        <propval type="astring" name="layout" value="US-English"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/console-login">
    <instance enabled="true" name="default">
      <property_group type="application" name="ttymon">
        <propval type="astring" name="terminal_type" value="vt100"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="network/physical">
    <instance enabled="true" name="default">
      <property_group type="application" name="netcfg">
        <propval type="astring" name="active_ncp" value="DefaultFixed"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/name-service/switch">
    <property_group type="application" name="config">
      <propval type="astring" name="default" value="files"/>
      <propval type="astring" name="host" value="files dns"/>
      <propval type="astring" name="printer" value="user files"/>
    </property_group>
    <instance enabled="true" name="default"/>
  </service>
  <service version="1" type="service" name="system/name-service/cache">
    <instance enabled="true" name="default"/>
  </service>
  <service version="1" type="service" name="network/dns/client">
    <property_group type="application" name="config">
      <property type="net_address" name="nameserver">
        <net_address_list>
          <value_node value="192.168.2.1"/>
        </net_address_list>
      </property>
    </property_group>
    <instance enabled="true" name="default"/>
  </service>
</service_bundle>
::::::::::::::
mars.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="network/install">
    <instance enabled="true" name="default">
      <property_group type="application" name="install_ipv4_interface">
        <propval type="astring" name="address_type" value="static"/>
        <propval type="net_address_v4" name="static_address" 
                 value="192.168.2.100/24"/>
        <propval type="astring" name="name" value="net0/v4"/>
        <propval type="net_address_v4" name="default_route" 
                 value="192.168.2.1"/>
      </property_group>
      <property_group type="application" name="install_ipv6_interface">
        <propval type="astring" name="stateful" value="yes"/>
        <propval type="astring" name="stateless" value="yes"/>
        <propval type="astring" name="address_type" value="addrconf"/>
        <propval type="astring" name="name" value="net0/v6"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/identity">
    <instance enabled="true" name="node">
      <property_group type="application" name="config">
        <propval type="astring" name="nodename" value="mars"/>
      </property_group>
    </instance>
  </service>
</service_bundle>
::::::::::::::
user.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="system/config-user">
    <instance enabled="true" name="default">
      <property_group type="application" name="root_account">
        <propval type="astring" name="login" value="root"/>
        <propval type="astring" name="password" 
                 value="noIWillNotTellYouMyPasswordNotEvenEncrypted"/>
        <propval type="astring" name="type" value="role"/>
      </property_group>
      <property_group type="application" name="user_account">
        <propval type="astring" name="login" value="stefan"/>
        <propval type="astring" name="password" 
                 value="noIWillNotTellYouMyPasswordNotEvenEncrypted"/>
        <propval type="astring" name="type" value="normal"/>
        <propval type="astring" name="description" value="Stefan Hinker"/>
        <propval type="count" name="uid" value="12345"/>
        <propval type="count" name="gid" value="10"/>
        <propval type="astring" name="shell" value="/usr/bin/bash"/>
        <propval type="astring" name="roles" value="root"/>
        <propval type="astring" name="profiles" value="System Administrator"/>
        <propval type="astring" name="sudoers" value="ALL=(ALL) ALL"/>
      </property_group>
    </instance>
  </service>
</service_bundle>
root@ai-server:~# installadm create-profile -n x86-fcs -f general.xml
root@ai-server:~# installadm create-profile -n x86-fcs -f user.xml
root@ai-server:~# installadm create-profile -n x86-fcs -f mars.xml \
-c ipv4=192.168.2.100
root@ai-server:~# installadm list -p

Service Name  Profile     
------------  -------     
x86-fcs       general.xml
              mars.xml
              user.xml

root@ai-server:~# installadm list -n x86-fcs -p

Profile      Criteria 
-------      -------- 
general.xml  None
mars.xml     ipv4 = 192.168.2.100
user.xml     None
In "general.xml" sind fuer viele Clients gueltige Einstellungen wie bspw. DNS-Server festgelegt. In "user.xml" die User, die einzutragen sind. Beide Profile gelten jedoch erst einmal ohne weitere Kriterien, also fuer alle Clients. Anders mars.xml, in dem die IP-Adresse fuer den Client mars festgelegt wird. Dieses Profil gilt nur fuer Install-Clients, die vom DHCP-Server die passende IP-Adresse bekommen haben. Damit das klappt, nun der letzte Schritt:
root@ai-server:~# installadm create-client -e 08:00:27:AA:3D:B1 -n x86-fcs
root@ai-server:~# vi /etc/inet/dhcpd4.conf
root@ai-server:~# tail -5 /etc/inet/dhcpd4.conf
host 080027AA3DB1 {
  hardware ethernet 08:00:27:AA:3D:B1;
  fixed-address 192.168.2.100;
  filename "01080027AA3DB1";
}

Damit ist der Client nun auch fertig vorbereitet. Damit der DHCP-Server keine Dummheiten macht, habe ich den Host-Eintrag in /etc/inet/dhcpd4.conf noch um die IP-Adresse fuer diesen Client ergaenzt. Damit bekommt dann nur dieser Install-Client diese Adresse, und nicht etwa ein unschuldiger anderer Rechner in diesem Netz...

Bemerkung: Das obige Beispiel zeigt die Konfiguration fuer ein x86-System.  Bei einem SPARC-System sieht die DHCP-Konfiguration etwas anders aus.  Hier wieder ein Beispiel mit kleinen manuellen Aenderungen, damit der DHCP-Server mir keine Sorgen macht ;-)

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.200 192.168.2.201
  option broadcast-address 192.168.2.255;
  option routers 192.168.2.1;
  next-server 192.168.2.13;
}

class "SPARC" {
  match if not (substring(option vendor-class-identifier, 0, 9) = "PXEClient");
  filename "http://192.168.2.13:5555/cgi-bin/wanboot-cgi";
}

host sparcy {
   hardware ethernet 00:14:4f:fb:52:3c ;
   fixed-address 192.168.2.202 ;
}

 

Da die Installation aber natuerlich wirklich "Hands Off" ablaufen soll, muss nun noch das Boot-Menue fuer den Client leicht modifiziert werden.  Es steht in /etc/netboot.  Dort wird fuer jeden Client ein eigenes, ueber die MAC-Adresse identifiertes menu.lst angelegt.  Das Template dafuer steht in einem Verzeichnis, das den Namen des Install-Service traegt, in meinem Fall als in /etc/netboot/x86-fcs.  Wer das Boot-Menue also nicht fuer jeden Client einzeln aendern moechte, kann auch das Template selbst anfassen.
root@ai-server:~# cd /etc/netboot
root@ai-server:~# cp menu.lst.01080027AA3DB1 menu.lst.01080027AA3DB1.org
root@ai-server:~# vi menu.lst.01080027AA3DB1
root@ai-server:~# diff menu.lst.01080027AA3DB1 menu.lst.01080027AA3DB1.org
1,2c1,2
< default=1
< timeout=10
---
> default=0
> timeout=30
root@ai-server:~# more menu.lst.01080027AA3DB1
default=1
timeout=10
min_mem64=0

title Oracle Solaris 11 11/11 Text Installer and command line
	kernel$ /x86-fcs/platform/i86pc/kernel/$ISADIR/unix -B install_media=htt
p://$serverIP:5555//export/install/fcs,install_service=x86-fcs,install_svc_addre
ss=$serverIP:5555
	module$ /x86-fcs/platform/i86pc/$ISADIR/boot_archive

title Oracle Solaris 11 11/11 Automated Install
	kernel$ /x86-fcs/platform/i86pc/kernel/$ISADIR/unix -B install=true,inst
all_media=http://$serverIP:5555//export/install/fcs,install_service=x86-fcs,inst
all_svc_address=$serverIP:5555,livemode=text
	module$ /x86-fcs/platform/i86pc/$ISADIR/boot_archive

Einer Installation (mittels PXE-Boot) steht damit nichts mehr im Wege. Fuer meine Demo-Zwecke ist das natuerlich ein Client aus der Virtualbox. Bei einem SPARC-System wuerde man statt dessen das bekannte "boot net:dhcp - install" am OK Prompt eingeben und dann genuesslich der Installation zusehen.

Und auch, wenn dieser Blogeintrag ein wenig laenger ist - so schwer ist das nun auch wieder nicht ;-)

Donnerstag Mrz 01, 2012

Die Solaris Fingerprint Database - Neuauflage in Solaris 11

Einige erinnern sich sicher an die Solaris Fingerprint Database. Sie war eine hervoragende Moeglichkeit, um die Integritaet eines Solaris Binaries zu pruefen.  Leider wurde sie zusammen mit dem Rest von Sunsolve abgeschaltet und im Nachfolger "My Oracle Support" nicht wieder in Betrieb genommen.  Die gute Nachricht nun ist:   In Solaris 11 gibt es sie wieder, und besser als jemals zuvor!

Um die alte Datenbank zu benutzen, musste man den MD5 Fingerprint eines Binaries auf der Webseite der Datenbank eingeben und pruefen.  Es gab zwar ein Tool fuer die Massenpruefung, aber umstaendlich war das allemal.

In Solaris 11 ist alles das in den Paket-Manifesten von IPS integriert.  Diese Manifeste enthalten u.A. die SHA1 and ggf. ELF Hashes aller Binaries und Scripte, die in dem jeweiligen Paket enthalten sind.  Damit ist eine manuelle Pruefung bereits moeglich.  IPS geht aber weiter und stellt auch eine Methode zur Verfuegung, mit der die Integritaet der gesamten Installation geprueft werden kann.  Hier einige Beispiele, was damit moeglich ist:

  • Was ist der SHA1 Fingerprint eines Binaries?
    digest -a sha1 /usr/bin/vim
  • Aus welchem Paket stammt es?
    pkg search -f $(digest -a sha1 /usr/bin/vim)
    (Die Option "-f" braucht man, damit das Paket auch dann gefunden wird, wenn das Binary aus einer aelteren Version stammt.)
  • Gibt es noch mehr Details?
    pkg info -r $(pkg search -f -H -o pkg.fmri $(digest -a sha1 /usr/bin/vim))

Falls das alles funktioniert hat, ist das die Bestaetigung, dass das Binary, in diesem Fall "vim" gueltig ist und aus dem Paket "vim-core" stammt.

Die Daten fuer diese Pruefungen liefert der im System konfigurierte Publisher.  Welcher das ist, kann mit dem Kommando "pkg publisher" nachgesehen werden.  Eine typische Ausgabe waere dabei:

PUBLISHER TYPE STATUS URI
solaris origin online https://pkg.oracle.com/solaris/support/

Natuerlich kann man einen einzelnen SHA1 Digest auch direkt auf der Webseite des Publishers nachschlagen.  Das geht direkt im Browser auf der URL des Publishers.  Ganz aehnlich hatte das auch mit der alten Fingerprint Database funktioniert.  IPS kann allerdings noch sehr viel mehr als das:

Mit dem Kommando "pkg verify" kann man jedes einzelne installierte Paket gegen das entsprechende Repository pruefen lassen.  Je nachdem, um was fuer Dateien es sich handelt (Binary, Script, Konfigurationsdatei), werden dabei unterschiedliche Verfahren angewandt:

  • Binaries werden mittels eines ELF Hashes geprueft.
  • Scripts dagegen mit ihrem SHA1 Hash.
  • Konfigurationsdateien koennen, ihrem Wesen entsprechend, nicht geprueft werden.  Sie sind ja gerade dazu gedacht, von einem Administrator veraendert zu werden.
  • Darueber hinaus werden auch Besitzer, Gruppe und Rechte aller Dateien geprueft.

Die Ausgabe von "pkg verify" wird jede Abweichung von den Vorgaben aus dem Paket-Manifest melden.  Damit werden z.B. veraenderte Scripte oder Binaries oder geaenderte Ausfuehrungsrechte aufgedeckt.  Diese Pruefung kann man gegen die gesamte Installation, aber auch fuer ein einzelnes Paket durchfuehren lassen.  Je nach Ergebnis kann man dann entscheiden, wie weiter verfahren werden soll:

  • Nichts tun
  • Abweichungen von Hand reparieren, bspw. weil man weiss, wie sie zustande gekommen sind.
  • Die Abweichungen automatisch durch das Paketsystem reparieren lassen.

Diese letzte Moeglichkeit ist in diesem Zusammenhang das eigentliche "Power Feature" von IPS.  Da das Paketsystem genau weiss, wie die Dinge sein sollten kann man es auffordern, diesen definierten Zustand wieder herzustellen.  Im Vergleich zu den Moeglichkeiten von BART und der Fingerprint Database ein enormer Fortschritt.

Insgesamt kann IPS damit eine bestehende Installation mit den Originaldaten des verwendeten Repositories vergleichen.  Die Integritaet des Repositories selbst muss jedoch zusaetzlich gesichert werden.  Beim "Master Repository" wird dies durch Oracle sichergestellt.  Die Pakete selbst, genauso wie die Binaries, sind kryptographisch signiert.  Bei einem eigenen, lokalen Repository sollte man das ISO-Image mittels der bereitgestellten SHA1/MD5 Fingerprints pruefen, bevor man das Repository aufbaut.  Fuer den Schutz desselben ist man dann selbst zustaendig - BART hilft hier ggf. weiter.

Zum Schluss noch ein kleines Beispiel fuer all die erwaehnten Dinge:

 root@benjaminchen:/usr/bin# ls -l vim

-r-xr-xr-x   1 root     bin      2225532 Feb 23 14:31 vim
root@benjaminchen:/usr/bin# digest -a sha1 vim
f2495fa19fcc4b8a403e0bd4fef809d031296c68
root@benjaminchen:/usr/bin# pkg search -f f2495fa19fcc4b8a403e0bd4fef809d031296c68
INDEX                                    ACTION VALUE       PACKAGE
f2495fa19fcc4b8a403e0bd4fef809d031296c68 file   usr/bin/vim pkg:/editor/vim/vim-core@7.3.254-0.175.0.0.0.2.537
root@benjaminchen:/usr/bin# pkg verify -v vim-core
PACKAGE                                                                                                    STATUS
pkg://solaris/editor/vim/vim-core                                           OK
root@benjaminchen:/usr/bin# cp vim vim.org
root@benjaminchen:/usr/bin# cp ls vim
root@benjaminchen:/usr/bin# pkg verify -v vim-core
PACKAGE                                                                 STATUS 
pkg://solaris/editor/vim/vim-core                                        ERROR
    file: usr/bin/vim
        Elfhash: 20acbb006d5331660dc026483533c29137318673 should be f301bd9d798c4bdd8edebb001fbf4317380383a9
root@benjaminchen:/usr/bin# pkg fix --accept vim-core
Verifying: pkg://solaris/editor/vim/vim-core                    ERROR          
    file: usr/bin/vim
        Elfhash: 20acbb006d5331660dc026483533c29137318673 should be f301bd9d798c4bdd8edebb001fbf4317380383a9
Created ZFS snapshot: 2012-02-29-09:27:49
Repairing:
 pkg://solaris/editor/vim/vim-core                 
                                                                             
DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  1/1         1/1      0.8/0.8
PHASE                                        ACTIONS
Update Phase                                     1/1 
PHASE                                          ITEMS
Image State Update Phase                         2/2 
 root@benjaminchen:/usr/bin# ls -l vim vim.org
-r-xr-xr-x   1 root     bin      2225532 Feb 29 10:28 vim
-r-xr-xr-x   1 root     root     2225532 Feb 29 10:27 vim.org
root@benjaminchen:/usr/bin# digest -a sha1 vim
f2495fa19fcc4b8a403e0bd4fef809d031296c68

Montag Feb 20, 2012

Solaris 11 fuer EAL4+ Zertifizierung eingereicht

Solaris 11 wurde offiziell zur Zertifizierung nach dem Canadian Common Criteria Scheme im Level EAL4+ eingereicht. Geprueft wird auf das Protection Profile "Operating System Protection Profile (OS PP)" sowie die Erweiterungen

  • Advanced Management (AM)
  • Extended Identification and Authentication (EIA)
  • Labeled Security (LS)
  • Virtualization (VIRT)

EAL4+ ist die hoechste typischerweise fuer kommerzielle Software erreichbare Ebene und gleichzeitig die hoechste Ebene, die von insg. 26 Laendern, darunter Deutschland, gegenseitig anerkannt wird. Wann die Zertifizierung abgeschlossen sein wird, liegt in den Haenden der Zertifizierungsstelle.

Den aktuellen Stand dieser Zertifizierung (und auch weiterer zertifizierter Oracle Software) findet man auf der Seite Oracle Security Evaluations.

Freitag Nov 11, 2011

Einstieg in Solaris 11

Fuer alle die, die jetzt mit Solaris 11 anfangen wollen, gibt es eine gute Zusammenfassung der Neuerungen und Aenderungen gegenueber Solaris 10.  Zu finden als Support Dokument 1313405.1.

Auch in OTN gibt es ein ganzes Portal zu Solaris 11.  Besonders hervorheben moechte ich hier die umfangreiche "How-To" Sammlung. Und nicht zuletzt gibt es natuerlich die "ganz normalen" Admin Guides.

Freitag Okt 07, 2011

Solaris 11 Launch

Schon lange wird geraetselt und gefragt, wann Solaris 11 angekuendigt wird.  Jetzt ist es soweit: Am

9. November 2011
um 19:00 Uhr Deutscher Zeit

wird es einen Webcast zur Ankuendigung von Solaris 11 geben. 

Herzliche Einladung zur Teilnahme!

(Neuigkeiten von der OpenWorld, insb. alles um T4, werde ich hoffentlich auch bald hier zusammenfassen...)

Montag Aug 01, 2011

Oracle Solaris Studio 12.3 Beta Program

Das Beta-Programm fuer Oracle Solaris Studio 12.3 ist jetzt verfuegbar.  Offen fuer jeden, kann man hier den neuesten Compiler testen.  Man darf in vielen Faellen einen Performance-Vorsprung gegenueber aelteren Versionen und auch gegenueber GCC erwarten.

Viel Spass beim Testen!

Donnerstag Mrz 31, 2011

Neugierig auf Solaris 11?

Neugierig auf Solaris 11?  Was sind die Highlights?  Was genau bringt das neue Package Format, wie funktioniert der neue Installer?  Wie sehen Analysten die Entwicklung?


All diese Fragen werden im Solaris Online Forum am 14. April ab 18:00 Uhr deutscher Zeit behandelt.  Die Veranstaltung ist live - es koennen Fragen gestellt werden. (Eine Aufzeichnung wird spaeter verfuegbar sein.)  Die Sprecher sind hochkaraetige Mitglieder aus Entwicklung und Produktmanagement.


Alle weiteren Details direkt auf der Ankuendigungsseite.

Freitag Dez 17, 2010

Solaris versteht die Hardware - pgstat erklaert sie

Motiviert durch die recht hohen Latenz-Unterschiede beim Zugriff auf Memory innerhalb der E25K wurde Solaris 9 9/02 um die sogenannten Locality Groups (lgrp) erweitert.  Damit wird die Memory-Hierarchie des Systems beschrieben, die je nach Hardware sehr stark verschieden sein kann.   Beim Erzeugen von Prozessen sowie beim Scheduling wird dann versucht, die CPU und den jeweils verwendeten Speicherbereich moeglichst nahe zueinander zu bringen.  Dieses Feature, als Memory Placement Optimization (MPO) bekannt, kann, je nach Anwendungsfall und Hardware, erhebliche Performance-Verbesserungen realisieren.

Der Solaris Kernel bietet, neben vielem Anderem, auch tausende von Zaehlern, die mit kstat, cpustat oder mit bekannteren Kommandos wie mpstat oder iostat abgefragt werden koennen.  Insbesondere die Werte, die cpustat liefert, sind dabei stark von der Hardware abhaengig, da nicht jede CPU jeden Typ Zaehler bietet. Die Auswirkungen auf die Performance, bzw die Auslastung der diversen Hierarchie-Teile konnte bisher jedoch kaum sinnvoll ausgewertet werden.  Hier gab es mit corestat bisher lediglich fuer die T-Serie ein Perl-Skript, das verschiedene Zaehler mit Hilfe von cpustat auswerten konnte.  Das ist mit Solaris 11 Express nun endlich Geschichte.

Es gibt drei neue Kommandos: lgrpinfo, pginfo und pgstat.

lgrpinfo zeigt die Hierarchie der L-Groups an, also die NUMA-Struktur der Hardware.  Immer dann, wenn man bspw. mit Solaris Containern und Resource-Gruppen einzelne CPUs zu Prozessor-Sets verbinden moechte, ist diese Information recht hilfreich.

pginfo zeigt, etwas anders orientiert als lgrpinfo, eine Baum-Sicht des gesamten Systems an.  Die Blaetter dieses Baumes sind die einzelnen Interger- und Floatingpoint Pipelines der einzelnen Kerne.  Hier ein kleines Beispiel aus einer T2 LDom, bestehend aus 16 Strands, die auf verschiedenen Cores ausgefuehrt werden:

# pginfo -v
0 (System [system]) CPUs: 0-15
|-- 3 (Data_Pipe_to_memory [chip]) CPUs: 0-7
| |-- 2 (Floating_Point_Unit [core]) CPUs: 0-3
| | `-- 1 (Integer_Pipeline [core]) CPUs: 0-3
| `-- 5 (Floating_Point_Unit [core]) CPUs: 4-7
| `-- 4 (Integer_Pipeline [core]) CPUs: 4-7
`-- 8 (Data_Pipe_to_memory [core,chip]) CPUs: 8-15
`-- 7 (Floating_Point_Unit [core,chip]) CPUs: 8-15
|-- 6 (Integer_Pipeline) CPUs: 8-11
`-- 9 (Integer_Pipeline) CPUs: 12-15

Hier wird die Zuordnung der verschiedenen Strands zu Pipelines und Cores sehr schoen deutlich.

pgstat letztlich ist ein wuerdiger Nachfolger fuer corestat und zeigt die Auslastung dieser einzelnen Komponenten sehr uebersichtlich an.  Hier wieder ein Beispiel, das gleichzeitig eine fast 100%ige Kern-Auslastung zeigt - etwas, was es recht selten zu beobachten gibt...


# pgstat -Apv 1 2
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.6% 0.4% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.1% 0.9% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 179K 1.3B 100.0% 99.1% 0.9% 0.0% 0-3
1 Integer_Pipeline [core] 80.0% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 50K 1.3B 100.0% 99.1% 0.9% 0.0% 4-7
4 Integer_Pipeline [core] 80.2% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 100.0% 0.0% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.3B 100.0% 100.0% 0.0% 0.0% 8-15
6 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 12-15
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.7% 0.3% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.5% 0.5% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 76K 1.2B 100.0% 99.5% 0.5% 0.0% 0-3
1 Integer_Pipeline [core] 79.7% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 42K 1.2B 100.0% 99.5% 0.5% 0.0% 4-7
4 Integer_Pipeline [core] 79.8% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 99.9% 0.1% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.2B 100.0% 99.9% 0.1% 0.0% 8-15
6 Integer_Pipeline 76.3% 1.2B 1.5B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.2B 1.5B 100.0% 99.8% 0.2% 0.0% 12-15

SUMMARY: UTILIZATION OVER 2 SECONDS

------HARDWARE------ ------SOFTWARE------
PG RELATIONSHIP UTIL CAP MIN AVG MAX MIN AVG MAX CPUS
0 System [system] - - - - - 100.0% 100.0% 100.0% 0-15
3 Data_Pipe_to_memory [chip] - - - - - 100.0% 100.0% 100.0% 0-7
2 Floating_Point_Unit [core] 76K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 0-3
1 Integer_Pipeline [core] 1.2B 1.5B 79.7% 79.7% 80.0% 100.0% 100.0% 100.0% 0-3
5 Floating_Point_Unit [core] 42K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 4-7
4 Integer_Pipeline [core] 1.2B 1.5B 79.8% 79.8% 80.2% 100.0% 100.0% 100.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - - - 100.0% 100.0% 100.0% 8-15
7 Floating_Point_Unit [core,chip] 80K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 8-15
6 Integer_Pipeline 1.2B 1.5B 76.3% 76.3% 76.4% 100.0% 100.0% 100.0% 8-11
9 Integer_Pipeline 1.2B 1.5B 76.4% 76.4% 76.4% 100.0% 100.0% 100.0% 12-15

Die Interpretation der diversen Werte ist, nach einem kurzen Blick in die Manpage, eine einfache und klare Angelegenheit.  Damit macht Performance-Analyse, insbesondere auf T2 und T3 Systemen, jetzt noch mehr Spass :-)

Dienstag Sep 14, 2010

So funktioniert Solaris 10 09/10 auto_reg wirklich

Im neuesten Update von Solaris 10 (09/10) gibt es als eines der neuen Features die Autoregistrierung.  Diese laesst sich mittels der Datei sysidcfg auch automatisieren.  Oder auch nicht, wie ein Bekannter von mir erfahren musste.  Wie sich herausstellte gibt es einen (inzwischen bekannten) Bug im GUI-Installer der dazu fuehrt, dass die neue Option "auto_reg" im GUI-Installer ignoriert wird, so dass hier die Registrierungsdaten immer abgefragt werden.  Der GUI-Installer springt immer an, wenn ein Bildschirm angeschlossen ist. Bei Servern ohne Bildschirm laeuft der Text-Installer, der die Option korrekt interpretiert. 


Als Workaround kann man statt des ueblichen "boot net - install" ein "boot net - install nowin" angeben, und schon funktioniert auch auto_reg.


Vielen Dank an Peter Tribble, der dies fuer mich gefunden hat.

Montag Jun 07, 2010

prstat und microstate accounting

Man lernt nie aus.  Als Reaktion auf meinen letzten Blogeintrag bekam ich den Hinweis, bei prstat doch die Option "-m" zu verwenden, um mich von den traegen und unzuverlaessigen Durchschnittswerten zu befreien.  Was dahinter steckt, wollte ich natuerlich genauer wissen, und wurde bei Eric Schrock fuendig.  Hier eine kurze Zusammenfassung:


Die herkoemmliche Ausgabe von prstat (und einigen anderen Kommandos) gibt Durchschnittswerte aus, die auf regelmaessigen Stichproben beruhen.  Je hoeher der CPU-Takt, desto hoeher ist auch die Wahrscheinlichkeit, dass einige Ereignisse selbst bei langen Messintervallen von keiner Stichprobe erfasst werden - die Ergebnisse werden immer unpraezieser, je hoeher der CPU-Takt und je kuerze die Ereignisse.  Bei Microstate-Accounting werden die Ereignisse direkt "am Objekt" erfasst.  Durch einige Aenderungen in der Implementierung wurde dies in Solaris 10 ausreichend effizient, um staendig aktiv sein zu koennen.  Verwendet man nun bspw. bei prstat diese praezieseren Werte, erscheint ein CPU-Fresser tatsaechlich sofort mit 100%.  Damit eruebrigt sich die Umrechnung der CPU-Anzahl in Auslastungs-Anteile.  Ein von der Singlethread-Leistung begrenzter Prozess wird so viel schneller und einfacher sichtbar.


Auch die Praesentation habe ich natuerlich entsprechend angepasst.


Vielen Dank fuer den Hinweis!  An solchen Dingen merke ich, dass ich Kommandos wie prstat schon viel zu lange (und durchaus erfolgreich) verwende.  Dieses neue Feature ging, aehnlich wie in dem Eintrag von Eric erwaehnt, auch bei mir wegen ZFS, Containern, SMF etc. unter.

Donnerstag Mrz 11, 2010

Demo fuer Solaris Resource Manager

Hier noch ein Beispiel, wie man eine solche Live-Demo zusammen stellen koennte:



  1. Zwei Projekte Anlegen:
    Auszug aus /etc/project:

    srm-demo:100::demo::project.cpu-shares=(privileged,3,none)
    srm-loader:101::demo::project.cpu-shares=(privileged,1,none)


  2. Interaktive Last Starten:

    newtask -p srm-demo java -jar /usr/java/demo/jfc/Java2D/Java2Demo.jar &


  3. Jetzt je nach Bedarf mehr und mehr Last-Scripts starten:

    newtask -p srm-loader someload.sh &
    someload.sh ist z.B.:


    #!/bin/sh
    while true
    do
    echo adflkjasdflkjasdflkjasdflkj > /dev/null
    done



  4. Jetzt kann man die Projekte ganz nach belieben kontrolliert (FSS) oder unkontrolliert (TS) betreiben:

    priocntl -s -c FSS -i projid 101
    priocntl -s -c FSS -i projid 100
    oder

    priocntl -s -c TS -i projid 100
    priocntl -s -c TS -i projid 101


About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute