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 Apr 29, 2010

VNC mal ganz einfach

VNC ist ein wirklich nuetzliches Werkzeug, wenn man mal eben ein X-Display an einem Server braucht.  Ich verwende es meist fuer den Oracle Installer oder andere GUI-Tools.  Wenn diese in einer VNC-Session laufen, stoert es nicht, wenn der Netzwerk-Anbieter mal eben die IP-Adresse wechselt oder man aus einem sonstigen Grund die Netzwerkverbindung verliert.  Auch laufen insb. Java-GUIs teilweise stabiler, wenn die Latenz zum X-Server klein ist...


Allerdings empfand ich das Aufsetzen von VNC immer wieder unnoetig aufwendig -  bis ich ueber vncadm gestolpert bin.


Dieses kleine Script traegt eine beliebe Anzahl von VNC-Displays in der Konfiguration des Xservers ein und uebergibt sie der Kontrolle von dtlogin.  Damit sind sie reboot-fest und man hat eine vollstaendige Umgebung einschl. normalem Login. Die Benutzung ist denkbar einfach - hier ein kleines Beispiel:



root@maramba,tmp>./vncadm -r 1024x786 add 1-4
root@maramba,tmp>./vncadm list
Display Title Resolution Port
===============================================================
:1 maramba_(:1) 1024x786 5901
:2 maramba_(:2) 1024x786 5902
:3 maramba_(:3) 1024x786 5903
:4 maramba_(:4) 1024x786 5904
root@maramba,tmp>./vncadm del 3-4
root@maramba,tmp>./vncadm list
Display Title Resolution Port
===============================================================
:1 maramba_(:1) 1024x786 5901
:2 maramba_(:2) 1024x786 5902


Vorraussetzung ist lediglich ein installiertes VNC.  Das ist seit einiger Zeit im Paket SUNWxvnc von Solaris 10 enthalten.  ggf. gibt es den Server aber auch auf der Seite von RealVNC zum Download. VNC selbst muss nicht weiter konfiguriert werden.  Da die Sessions von dtlogin verwaltet werden, braucht man die Datei xstartup nicht.  Ein vnc-passwort wird ggf. abgefragt und gespeichert.  Nach kurzer Zeit (dtlogin wartet ein wenig) werden die Xvnc Server automatisch gestartet.  Da vncadm ueber die Konfiguration von dtlogin arbeitet, funktioniert es natuerlich nur mit Solaris 10.  In OpenSolaris ist CDE, und damit dtlogin, ja nicht enthalten.  Eine Erweiterung fuer den GDM ist jedoch angedacht.


Das Script stammt von meinem Kollegen Ralph Bogendoerfer.  Den Download gibt es hier.



Mittwoch Mrz 31, 2010

Sun Presenter Console mit OpenSolaris

Die Sun Presenter Console fuer OpenOffice bzw. StarOffice gibt es ja schon laenger.  Man braucht dafuer jedoch ein Betriebsystem (bzw. einen Xserver), der einen zweiten Monitor unterstuetzt.  Das war bei meinem Laptop (mit Radeon Mobility X1600 Grafik) bis vor kurzem nicht der Fall.  Mit Build 117 von OpenSolaris hat sich das geaendert. Meinen Dank an dieser Stelle an meinen Kollegen Andris Perkons fuer den Hinweis :-)


Um das ganze in Betrieb zu nehmen, braucht man folgendes:
  • Sun Presenter Console
  • Xinerama Support fuer Xorg
    • mit "Xorg -configure" ein xorg.conf.new file erzeugen
    • Dies nach /etc/X11/xorg.conf kopieren
    • Dort in 'Section "Screen"', 'SubSection "Display"':
      fuer alle Farbtiefen "Virtual 3600 1200" eintragen
    • Xserver neu starten

Danach kann man mit SHIFT-F5 verschiedene Xinerama-Modi durchschalten.  Fuer den Presenter ist der ungespiegelte 2-Monitor-Betrieb der richtige.  Wichtig dabei ist, dass OpenOffice derzeit nicht mit unterschiedlichen Aufloesungen auf den beiden Monitoren zurecht kommt.  Ich habe deswegen einen eigenen Account fuer's Praesentieren.  Dadurch bleibt mein "Arbeitsdesktop" aufgeraeumt...

Da ich SHIFT-F5 nicht mag (es ist mir zu wenig berechenbar), habe ich zwei kleine Scripte fuer Beamer An/Aus:

Beamer An:

screensaver-command -exit
xrandr -s 1024x768
xrandr --output VGA-0 --mode 1024x768 --right-of LVDS
res=`xrandr|grep \\\*|tail -1|awk '{print $1}'`
zenity --info --text="Beamer now on\\nResolution $res \\nScreensaver off"

Beamer aus:

xrandr --output VGA-0 --off

Dabei nehme ich stillschweigend eine Beameraufloesung von 1024x768 an. Das duerfte meist passen.

Und nun: Frohes Praesentieren!

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


Mittwoch Mrz 10, 2010

Ein paar Gedanken zu Skalierbarkeit


Vor einigen Tagen gab es auf einem internen Verteiler ein Diskussion ueber Skalierbarkeit, und warum Solaris besonders gut darin ist.  Einige alt-gediente Performance-Meister fassten das Thema so bemerkenswert gut zusammen, dass ich diese Zusammenfassung gerne einem breiteren Publikum zugaenglich machen moechte.  Sie waren einverstanden, deswegen:


Was ist Skalierbarkeit, und warum ist Solaris so gut darin, Anwendungen nicht am skalieren zu hindern?
Gute Skalierbarkeit ist eine klassische Beobachtung bei Systemen, die ueber Jahre hinweg optimiert wurden.  Diese Systeme habe nicht nur eine gute Leistung bei hoher Last, sondern diese Leistung degeneriert bei Ueberlast auch weniger.


Der Grund dafuer wird meistens mathematisch beschrieben:  Die Steigung der Kurve der Antwortzeit (Degeneration) wird dominiert durch die Antwortzeit der einen, langsamsten Komponente.  Ein neues Produkt hat normalerweise ein paar wenige, grosse Flaschenhaelse.  Und weil sie so gross sind, steigt die Antwortzeit-Kurve fruehzeitig in Richtung Unendlichkeit, und ist dabei sehr steil und gerade.


Ein solches System auch nur ein wenig zu ueberlasten wirkt wie ein "Gegen die Wand fahren" - das System haengt scheinbar.  Wenn man die Last auf der X-Achse, und die Antwortzeit auf der Y-Achse auftraegt, sieht das ungefaehr so aus:



Das heisst in unserem Metier die "Hockey-Stick" Kurve ;-)  Die Antwortzeit ist anfangs recht flach, bis zu einem Wendepunkt, ab dem die Kurve gen Himmel steigt wie ein Engel mit Heimweh.


Ein gut optimiertes, ausgereiftes Produkt hingegen hat viele kleine Flaschenhaelse.  Einer davon ist der groesste, und dieser bestimmt die Position und Steigung des Wendepunkts.  Bei einem entsprechend kleinen Flaschenhals ist die Steigung flach.  Bei Ueberlast erlebt der Benutzer ein solches System als langsam oder zaeh, aber nicht als haengend.  Grafisch sieht das dann etwa so aus:



Nicht optimierte oder wenig ausgereifte Programme zeigen ab ca. 80% Auslastung haeufig schlechte Leistung.  Ein haeufiger Grund dafuer ist, dass die Wahrscheinlichkeit fuer wirklich gleichzeitige Anfragen hoch ist, und diese die Software kurzfristig an den Wendepunkt hin zur Degeneration fuehren.  Da das System nicht-optimal ist, ist der Grad der Degeneration hoch und entsprechend fuer den Benutzer sichtbar.  Diese Situation tritt typischerweise bei ca. 70% - 80% Last auf, manchmal auch frueher.


Wir haben in der Entwicklung von Solaris seit Jahren erfolgreich Jagd auf auch die kleinsten Flaschenhaelse gemacht.  Entsprechend ist der Anstieg unserer Degenerations-Kurve sehr sehr sanft.  PCs, auf der anderen Seite, haben eine Tendenz, schnell und haeufig gegen die Wand zu fahren.  Ein Teil ihrer ja bereits legendaeren Unzuverlaessigkeit ist allerdings nicht echt: Manche Benutzer ueberlasten die Maschine, vermuten wegen der extrem langen Antwortzeiten einen Haenger oder Absturz, und booten neu...


Ein haeufig genannter Grund fuer die hervorragenden Skalierungseigenschaften von Solaris sind seine sehr feinkoernigen Spin-Locks.  Grobkoernige Locks verlaengern die Antwortzeiten von eigentlich seriellen Locks mit der zu erwartenden Auswirkung entsprechend Amdahl's Law.  Durch seine ueber die Jahre entwickelte Plattform-Kenntnisse traegt insbesondere der Solaris Scheduler stark zur Skalierbarkeit von Solaris bei.  Auch andere Features wie diverse AIO Optionen und Preemption-Kontrolle wie sie bspw. in Oracle integriert wurden sind weitere Gruende fuer die gute Skalierbarkeit.


Desweiteren geht es bei Skalierung, insbesondere \*guter\* Skalierung, nicht nur um hohen Durchsatz und die durchschnittliche Antwortzeit als Funktion der Last.  Gute Skalierbarkeit fuehrt haeufig auch zu einer geringeren Varianz in der Antwortzeit, die der Benutzer als hoehere Zuverlaessigkeit erlebt, sowie zu der erwaehnten sanften Degeneration jenseits der Saettigung.  Diese Faktoren sollten viel oefter gemessen und besprochen werden.  Leider konzentriert sich die Benchmark-Welt viel zu sehr auf die eine Zahl des hoechsten Durchsatzes.


Als letztes:  Die Grundlage fuer all dies wurde gelegt, als Sun (in den 90er Jahren) seine Version von SVR4 definierte.  Wir haben die Implementierung von AT&T mehr oder weniger vollstaendig durch unsere eigene Vorstellung von voller Preemption, Multi-Threading und dem ganzen Rest ersetzt.  Wenn die Grundlage stimmt, ist es so viel einfacher, darauf aufbauend andere Dinge zu bauen.  Wenn man bei jedem neuen Feature die Grundlage umbauen muss, ist das sehr viel muehsamer.  


Die Folge:  Grosse Server auf einer hervorragenden Grundlage fuehrt zu Kunden, die immer noch mehr Arbeit auf die Server bringen, was neue Probleme aufzeigt die wir loesen, was zu Kunden fuehrt, die noch mehr Arbeit auf die Maschinen bringen...


Wenn man das ganze live erleben moechte, hier die Zutaten fuer eine Live-Demo:
Perfbar oder den Gnome perfmeter als Anzeige der CPU-Auslastung.  Auch ein Textfenster mit mpstat reicht dafuer aus.  Dann noch eine interaktive Anwendung als Gradmesser fuer die "gefuehlte" Performance.  Hier bietet sich z.B. die Java2D-Demo an, die mit jedem JDK-Release ausgeliefert wird.  Nun den Rechner unter Last setzten, bspw. mit mehreren endlos laufenden encrypt-Kommandos.  Sichtbare Verschlechterung der interaktiven Anwendung wird es erst sehr nahe an 100% geben ;-)


Die Steigerung hiervon ist, die interaktive Anwendung mittels Solaris Resource Manager mit bspw. 80% CPU auszustatten und die Menge der Hintergrundjobs immer weiter zu steigern.  Selbst erfahrene Techniker kommen hierbei immer wieder ins Staunen.  Problematisch an dieser zweiten Demo koennte sein, dass der eine oder andere anfaengt, an einen Trick zu glauben...  


Dieser Artikel wurde aus mehreren Email-Beitraegen zusammengestellt.  Die Autoren sind:

David Collier-Brown
James Litchfield
Bob Sneed

Vielen Dank hierfuer!
(Die englische Originalfassung gibt es im englischsprachigen Teil dieses Blogs.  Die deutsche Uebersetzung ist von mir.

Montag Mrz 08, 2010

So lange lebt Solaris

Nein, diesmal geht es nicht um die lange Verfuegbarkeit von Solaris am Markt.  Das hatte ich ja schon ;-)  Diesmal geht es darum, wie lange ein solches Solaris unterbrechungsfrei seinen Dienst verrichten kann.  Aber hier gilt: Ein Bild sagt mehr als tausend Worte:



Gesehen bei einem Kunden, der bei dieser Maschine nichts mehr fuerchtet als einen Kollegen vom Service, der auf dem neuesten Kernel-Patch besteht.  Allerdings handelt es sich hier natuerlich um Solaris 8, und das bevorstehende Konsolidierungsprojekt gefaehrdet das Erreichen der 2500 Tage mehr als ein potentieller Kernel-Patch.

Montag Feb 08, 2010

Oracle Encryption und das Solaris Cryptographic Framework

Seit Oracle 10gR2 gibt es die Moeglichkeit, einzelne Spalten einer Tabelle zu verschluesseln[1].  Als Erweiterung hiervon ist es seit Release 11gR1 moeglich, ganze Tablespaces zu verschluesseln[2].  Beide Features ermoeglichen es, sensitive Daten davor zu schuetzen, dass der Datentraeger auf irgend eine Weise ausgespaeht wird.


Der Master Key, der die Schluessel fuer die Verschluesselung von Spalten bzw. Tablespaces absichert, wird im sogenannten "Oracle Wallet" gespeichert.  Dies ist ueblicherweise eine Datei, deren Speicherort in der sqlnet.ora festgelegt werden kann.  Fuer Anwendungen mit besonders hohem Schutzbedarf ist es jedoch auch moeglich, diesen Master Key in einem externen Geraet, einem sogenannten "Hardware Security Modul" (HSM) abzulegen[3].  Der Zugriff auf diese Geraete erfolgt ueber den Standard PKCS#11.  Da nicht jeder immer gleich Zugriff auf tatsaechliche HSM-Hardware wie z.B. die Sun Crypto Accelerator Karte SCA 6000 hat, kann man statt dessen auch den Softtoken-Store des Solaris Cryptographic Framework [4,5] als HSM nutzen.  Die Oracle-seitige Konfiguration ist die gleiche, und ggf. kann man zu einem spaeteren Zeitpunkt ein "echtes" HSM dazu konfigurieren.  Die Schluessel lassen sich dann mit geschicktem export/import migrieren.


Hier nun die notwendigen Schritte:


Als erstes legt man ein normales Oracle Wallet an.  In der sqlnet.ora traegt man dazu folgendes ein:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Dann erzeugt man den Masterkey mit:



alter system set encryption key identified by "walletpasswd" ;


Damit kann man nun bereits Spalten (alter table oe.customer modify (credit_limit encrypt); ) oder Tablespaces (create tablespace test datafile '+DATA' size 10M encryption default storage(encrypt); ) verschluesseln. Bis hierher wird noch das "normale" Oracle Wallet verwendet.


Als naechstes migriert man nun die jetzt bereits vorhandenen Master-Keys fuer Spalten bzw. Tablespaces in den Softtoken.  Dazu muss dieser erst vorbereitet werden.  Da jeder Solaris-User einen eigenen Softtoken-Store hat (~/.sunw), muss dies als der Oracle-User erfolgen, unter dessen UID die Datenbank betrieben wird.  Dieser Benutzer setzt mit dem Kommando "pktool setpin" ein eigenes Passwort fuer den Tokenstore.  (Das Defaultpasswort ist "changeme", ein Ratschlag, den man natuerlich beherzigen sollte.)  Damit ist der Tokenstore bereit. 


Nun muss Oracle noch Zugriff auf die PKCS#11-Library bekommen:



mkdir ­p /opt/oracle/extapi/32/hsm/sun/1.0.0
mkdir ­p /opt/oracle/extapi/64/hsm/sun/1.0.0
cp /usr/lib/libpkcs11.so /opt/oracle/extapi/32/hsm/sun/1.0.0
cp /usr/lib/sparcv9/libpkcs11.so /opt/oracle/extapi/64/hsm/sun/1.0.0


Als letzte Vorbereitung wird nun die sqlnet.ora geaendert:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Die Migration der beiden Master-Keys dorthin erfolgt nun mit:



alter system set encryption key identified by "scfpasswd" migrate using "walletpasswd";


Das Wallet auf und zu (und die Daten damit zugaenglich oder auch nicht) macht man mit den Kommandos



alter system set wallet open identified by "scfpasswd";
alter system set wallet close ;


Damit verwendet Oracle jetzt den Softtoken-Store des Solaris Cryptographic Framework, um seine Masterkeys zu speichern. Wer moechte, kann nun das alte, obsolete Wallet von Oracle entweder loeschen oder in ein auto-open Wallet wandeln. Letzteres geht mit dem WalletManager (owm) von Oracle. (Danke an Peter Wahl fuer diesen Hinweis).


Das ganze funktioniert natuerlich nicht nur Single-Instance, sondern auch im RAC.  Meine Empfehlung dazu: Die Vorbereitung vollstaendig auf einem Knoten machen, dann den Softtoken, also ~/.sunw, auf die anderen Knoten kopieren, dann erst diese starten.  Ansonsten laeuft man Gefahr, dass einzelne Knoten unterschiedliche Masterkeys erzeugen, und dann bleibt, soweit ich weiss, nur ein "drop database"...  Synchronisation der Keys zwischen den Knoten gibt es mit Release 11.2.0.1. [6].  Dabei wird allerdings ein Wallet auf einem gemeinsamen Filesystem vorausgesetzt.  Da dies mit dem SCF normalerweise nicht moeglich ist (da ja die Oracle-User eigene Homeverzeichnisse haben), muss der Softtoken hier weiterhin manuell kopiert werden.  Besonders angenehm macht es hier die Software der SCA 6000, die es ermoeglicht, mittels LDAP zu synchronisieren...


Nachtrag (2010-02-23): Der Speicherort des Softtoken, normalerweise ~/.sunw, kann mittels der Umgebungsvariablen SOFTTOKEN_DIR beliebig gesetzt werden, und damit auch auf ein von allen Knoten aus zugaengliches gemeinsames Verzeichnis [7].


[1] Transparent Data Encryption (TDE)
[2] Tablespace Encryption
[3] Anleitungen
[4] SCF auf BigAdmin
[5] SCF auf docs.sun.com
[6] Neu mit 11gR2
[7] manpage zu pkcs11_softtoken(5)


2010-02-10:  This blog entry is now also available in english.

Mittwoch Okt 21, 2009

LDoms fuer OpenSolaris

Cloudcomputing ist ja in aller Munde.  Jede Form von Rechner, die im Internet buchbar ist, befindet sich derzeit in Wolken ;-)  Eine besondere Wolke gibt es fuer die Entwickler von OpenSolaris: Die OpenSolaris Testfarm.  Dort kann jeder Entwickler, der an einem OpenSolaris-Projekt mitarbeitet, sich einen Solaris Container oder auch einen ganzen Server zu Testzwecken reservieren.  Seit neuestem nun auch eine LDom.  Damit OpenSolaris auch in LDoms optimal laeuft (nicht, dass das heute nicht auch schon so waere).  Virtualisierung sinnvoll eingesetzt!

Freitag Sep 11, 2009

Was an Solaris so gut ist

Forbes hat seinen Artikel mit "Why Oracle Wants Solaris" ueberschrieben.  "Warum ist Solaris das beste Betriebsystem" waere genauso gut gewesen, meine ich.  Der Artikel gibt eine gute, nicht zu lange Uebersicht ueber die wichtigsten Vorzuege von Solaris.  Immer wieder gut, wenn man mal wieder auf einen ueberzeugten Linux, AIX, HPUX oder Windows-Fan trifft.  Manche sagen ja, das waeren alles nur Glaubenskriege.  So, wie diese Diskussionen oft gefuehrt werden, sind sie das leider auch.  Das Glaube, aehnlich wie Liebe, blind macht, sollte allerdings nicht darueber hinweg taeuschen, dass es tatsaechlich viele gute Gruende gibt, die fuer Solaris sprechen.

Montag Sep 07, 2009

CUPS und SunRays

Seit mein Laptop, bzw. der Luefter, so laut geworden ist, wurde er in den Keller verbannt.  Dank SunRay ist das ja kein Problem :-)  Nur der USB-Anschluss des Druckers, der war natuerlich jetzt so nicht mehr drin.  Aber die SunRay hat ja auch einen USB-Port.  Die einzige Huerde war CUPS, bzw. der richtige Devicefile-Eintrag.  Ein wenig Googlen hat geholfen, der Trick ist jetzt hier dokumentiert.  Wesentlich ist das "hal backend" und "parallel:/tmp/SUNWut/..." als Devicefile.  Jetzt druckt's wieder :-)

Dienstag Jun 30, 2009

Drucken mit SXCE Build 115

Gestern habe ich mittels LiveUpgrade meinen Laptop von SNV103 auf SNV115 (genauer: Solaris Express Community Edition) gebracht.  Hat gut funktioniert, nach einem kleinen Bugfix fuer den SunRay Server ging alles - bis ich zum ersten Mal drucken wollte.  Bisher, also von build 53 bis einschl. 103, hatte ich das gute alte Solaris lpd-System verwendet - einschliesslich Plug&Play USB-Drucker hat das super funktioniert.  Die pragmatische Loesung jetzt: Umstellen auf CUPS und Neueintragen der Drucker.  Die Umstellung geht mit einem Kommando:  print-service -s cups. Dannach ist die CUPS Verwaltung unter http://localhost:631/ erreichbar.

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 2015
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