The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_134 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
Starting with build 133, almost all packages in the development package repository have been renamed with hierarchical smf(5)-style names. For general information on the the format of package names, see the pkg(5) manual page.
[...]
Users who wish to update their system to the development build can do so by setting their preferred publisher to the above URL and using the “image-update” facility provided by the pkg(1) command or by the “Update All” facility of the Package Manager GUI.

[Quelle: David Comay via opensolaris-annouce]

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_133 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
Starting with build 133, almost all packages in the development package repository have been renamed with hierarchical smf(5)-style names. For general information on the the format of package names, see the pkg(5) manual page.
[...]
Users who wish to update their system to the development build can do so by setting their preferred publisher to the above URL and using the “image-update” facility provided by the pkg(1) command or by the “Update All” facility of the Package Manager GUI.

[Quelle: David Comay via opensolaris-annouce]

• Seven Useful OpenSolaris ZFS Home Server Tips by @zalez
• Home Fileserver by @anfalas
• Building netatalk on OpenSolaris 2009.06
• …and if you like Service Discovery, read Making netatalk discoverable in OpenSolaris

Thanks folks, after about 15min of compile-time and a some copy&paste, my ZPool is now visible in Finder.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_132 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
Users who wish to update their system to the development build can do so by setting their preferred publisher to the above URL and using the “image-update” facility provided by the pkg(1) command or by the “Update All” facility of the Package Manager GUI.

[Quelle: David Comay via opensolaris-annouce]

No, the box is not glowing in the dark yet, just a little ooops with fork(). But still rock solid and pretty much usable.

shl@napfel ~ % uname -a
SunOS napfel 5.11 snv_130 i86pc i386 i86pc

This is why I love Solaris!

git clone git://git.kernel.org/pub/scm/git/git.git
cd git
make quick-install-html
pfexec mkdir -p /usr/share/doc/git-doc
cd /usr/share/doc/git-doc
pfexec mv ~/share/doc/git-doc/* .

Nun funktioniert z.B. git help --web init wie erwartet, und der Browser wird geoeffent um die Hilfe-Seite anzuzeigen.
Wenn das git-Repository sonst nicht mehr benoetigt wird kann es natuerlich anschliessend wieder geloescht werden. Ebenso ~/share, sofern keine anderen Daten dort gelagert werden.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_131 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
Users who wish to update their system to the development build can do so by setting their preferred publisher to the above URL and using the “image-update” facility provided by the pkg(1) command or by the “Update All” facility of the Package Manager GUI.

[Quelle: David Comay via opensolaris-annouce]

• die Daten eines auf MacOS X erstellten ZPools sollen auf eine OpenSolaris-Maschine uebertragen werden.

Gedankengang #1:
Es war schon spaet abends, wirklich nachgedacht wurde nicht, klein Sebastian startet ein rsync und denkt “so lang wird das schon nicht dauern”. Problematik dabei ist bzw. war allerdings, dass auf dem Pool u.A. auch diverse OpenSource-Projekte und -Sammlungen im Quelltext vorlagen, so z.B. pkgsrc, was ohne mit der Wimper zu zucken zu mehreren Millionen kleinen Files fuehrt. Ebenfalls kam der kleine Sebastian nicht auf die Idee fuer das rsync ein LAN-Kabel anzuschliessen und schickte den kompletten Datenstrom ueber WLAN durch die Luft. (Immerhin zwar n, aber im Vergleich zu Gigabit-Ethernet immernoch langsam.) Einigen wir uns auf keine so gute Idee, auch wenn sie zum Ziel gefuehrt hat.

rsync -avzP -e "ssh -p 22" /Volumes/tank/* shl@<ziel>:/tank/transfer

Gedankengang #2: (ein paar Tage spaeter)
Die Daten sind auf dem neuen Pool angekommen – so weit so gut. Und damit es noch einen Lern-Erfolg gibt, machen wir das jetzt nochmal in richtig. Damit ich den – in diesem Falle – ueberfluessigen Layer Netzwerk los werde, schliesse ich die USB-Platten vom Mac direkt an die OpenSolaris-Box an. Hierfuer muss der Pool allerdings erst umbenannt werden, da eine Maschine nicht zwei Pools des gleichen Namens mounten kann.

sudo zpool export tank
sudo zpool import oldtank tank
sudo zpool export oldtank

Die Schritte im Detail: wir exportieren den Pool, damit wir ihn per import <neu> <alt> umbenennen koennen und exportieren ihn nochmals, damit wir ihn an die andere Kiste anschliessen koennen. Hier noch ein

pfexec zpool import oldtank

und zumindest das erste Problem ist gegessen.

ZFS bietet von Haus aus eine durchdachte Moeglichkeit an um Daten von A nach B zu schieben, naemlich zfs send | zfs receive. Durch die Pipe (|) kann man hier auch prima z.B. ssh als Transport-Medium nutzen. Allerdings kann zfs send nur Snapshots uebertragen – aber bei einem Filesystem was effektiv still steht (hier oldtank) tut das ja nun wirklich nicht weh.

Das folgende Script habe ich die letzten Monate auf meinem Mac zum snapshot’en benutzt. In groben Zuegen basiert es auf Jeff’s Snapshot-Script, allerdings erstellen wir hier keinen Timestamp sondern einen hoffentlich eindeutigen String fuer die Snapshots die wir kopieren moechten, in diesem Falle “NOWITSTHETIME“.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/bin/bash
 
FS=`zfs list -t filesystem | grep oldtank | awk '/^[a-z0-9]+\//{ print $1}'`
#NOW=`date +%Y-%m-%d`
NOW=NOWITSTHETIME
 
for I in $FS; do
 echo "Snapshot'ing ${I}@$NOW ..."
 zfs snapshot ${I}@$NOW
 if [ $? = 0 ]; then
  echo "success!"
 else
  echo "failed ($?)!"
 fi
done

Im naechsten Script – ich entschuldige mich im Vorfeld fuer die massive und z.T. unnoetige Nutzung von grep, aber mir gefaellt das halt so – schicken wir die eben erstellten Snapshots nach tank/transfer2 (vorher natuerlich anlegen, sonst wird das nix…):

1
2
3
4
5
6
7

#!/bin/bash
 
for i in `zfs list -rH -t snapshot | awk '{print $1}' | grep oldtank | grep -v tank/transfer2/oldtank | grep NOWITSTHETIME`
do
echo "sending Snapshot" $i "to transfer2"
pfexec zfs send $i | pfexec zfs receive tank/transfer2/$i
done

Fragt sich nun natuerlich: was haben wir gewonnen?
zfs send serialisiert den Datenstrom, was z.B. dazu fuehrt, dass es vollkommen egal ist, ob wir mit Millionen von kleinen Dateien oder drei grossen 1TB-Files arbeiten. Ebenfalls koennen wir uns den kompletten Weg der Daten sicher ueber deren Zustand sein, denn wir vertrauen durchweg auf die Integritaetschecks von ZFS. Wenn gewuenscht (ich habe nicht wirklich einen Sinn darin gesehen) kann man durch die Pipes noch z.B. gzip einbauen, oder eben Transport-Mechanismen wir ssh oder sonstwas nutzen. Konstrukte wie

zfs send tank@BRIEFTAUBE > file
Benutze file mit Brieftaube
cat file | zfs receive tank@BRIEFTAUBE

sind genauso moeglich. Und auch die Nutzung als Backup ist durchaus eine Ueberlegung wert.
Um zur urspruenglichen Problemstellung zurueck zu kommen: im Vergleich zur Methode #1 ist die Loesung mit zfs send eindeutig schneller. Und – zumindest ich – habe damit ein besseres Gefuehl.

Beide Scripte sind per git auf github verfuegbar.
(git clone git://github.com/shl/zfssnapsend.git)

Download ist wie immer per opensolaris.org möglich, und trotz Umweg über das SUN Download-Center auch mit wget nutzbar.

Außerdem gibt es bei diesem Release zwei wichtige Punkte zu beachten:

• Nevada RE Build 130 is the final SXCE build.
• After January 2010, all existing SXCE releases will be removed from the SDLC (Sun Download Center) and no additional SXCE images of any kind will be distributed.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_130 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
IMPORTANT NOTE: Before updating a system, please review this document for all of the known issues that may affect the update.
IMPORTANT NOTE: The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through http://defect.opensolaris.org/

[Quelle: David Comay via opensolaris-annouce]

The OpenSolaris development package repository

pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_129 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).

Before updating a system, please review the “New issues” and “Existing issues” sections of this document for all of the known issues that may affect the update.

The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through defect.opensolaris.org.

Users who wish to update their system to the development build can do so by setting their preferred publisher to the above URL and using the “image-update” facility provided by the pkg(1) command or by the “Update All” facility of the Package Manager GUI.

[Quelle: David Comay via opensolaris-annouce]

Download ist wie immer per opensolaris.org möglich, trotz Umweg über das SUN Download-Center auch mit wget nutzbar, und auch diesmal lohnt sich ein Blick in die Changelogs des Systems sowie die, des X-Window Systems.

Laden und ins Archiv legen – man weiß ja doch nie, wann man mal halbwegs aktuelle SVR4-Pakete braucht.

OpenSolaris und Solaris:

OpenStorage und ZFS:

Und generell zu empfehlen:
HELDENFunk
Der Podcast von systemhelden.com
Echte Systemhelden haben immer ein offenes Ohr für echte Lösungen. Darum hört die Stimmen der Energie und Ihr werdet lernen.
  

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_127 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
IMPORTANT NOTE: Before updating a system, please review this document for all of the known issues that may affect the update.
IMPORTANT NOTE: The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through http://defect.opensolaris.org/

[Quelle: David Comay via opensolaris-annouce]

Nachdem wir die letzten beiden Jahre schon Parallel-Events zum Chaos Communication Congress im Forum41 abgehalten haben, wollen wir uns auch in diesem Jahr wieder vom 27. bis 30. Dezember 2009 im Forum41 treffen, dieses mal unter dem Motto “Dragons everywhere“, dem “distributed 26C3″-Konzept, dass die Organisatoren vom CCC dieses Jahr erstmalig als “Experiment” starten wollen (wir haben das ja schon die letzten beiden Jahre geübt).

Worum gehts?
Viele wollen, können aber aus den verschiedensten Gründen nicht zum Chaos Communication Congress nach Berlin pilgern oder sind der Meinung, dass man sich die Vorträge auch bequem von zu Hause aus per Stream anschauen kann. Genau diese Leute wollen wir damit ansprechen und erreichen.

Das Event wird gemütlich sein, Spaß am Gerät, belebende Getränke wie Club Mate oder Jolt Cola dürfen konsumiert werden (natürlich auch alle anderen nichtalkoholischen Getränke), es wird vermutlich wieder gebruncht oder zusammen Pizza gebacken (oder zu mindest gemeinsam bestellt und verspeist).

Das Ganze findet in Schwetzingen im Forum41 statt. Wer UUGRN schon länger begleitet wird das kennen, war vielleicht sogar schonmal auf einem der FIXME-Treffen dort.

Wer unsere Events kennt weiss, dass diese ohne Voranmeldung sind und auch keinen Eintritt kosten. “Spaß am Gerät” impliziert, dass man eigene Hardware mitbringen darf/soll. Wir sind eine Unix User Group, entsprechend werden Themen rund um unixoide Betriebssysteme vermutlich einen gewissen Focus haben, was jetzt Windows-User nicht so direkt ausgrenzen soll … wir sind schließlich tolerant.

Eingeladen sind Mitglieder und Freunde/Umfeld von UUGRN e.V. und NoName e.V. und solche, die uns kennen lernen wollen.

Nochmal Kompakt:
Was: Dragons everywhere / 26c3
Wo: Forum41, Schwetzingen
Wann: 27.12. bis 30.12. jeweils während der Videoübertragungen
Wer: Mitglieder, Freunde und solche die es werden wollen

Links:

• https://wiki.uugrn.org/UUGRN:Dragons_everywhere (alle Details / Orga)
• http://events.ccc.de/congress/2009/wiki/index.php/Dragons_everywhere
• https://wiki.uugrn.org/Spass_am_Geraet
• http://www.proclima.com/ (Sponsor für das Forum41)
• https://wiki.uugrn.org/Forum41
• http://events.ccc.de/congress/2009/
• http://fixme.uugrn.org/
• http://www.uugrn.org/

Wer vorher schonmal vorbei schauen will ist schon jetzt herzlich zum kommenden FIXME Treffen am 4. Dezember 2009 ab 20 Uhr im Forum41
eingeladen.

PS: es darf getwittert werden: #fixme, #26c3 und #c3fixme

Das original Announcement von Raphael ist im Archiv der Mailing-Liste der UUGRN zu finden.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_127 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
IMPORTANT NOTE: Before updating a system, please review this document for all of the known issues that may affect the update.
IMPORTANT NOTE: The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through http://defect.opensolaris.org/

[Quelle: David Comay via opensolaris-annouce]

Ebenfalls verspätet, sorry.

Download ist wie immer per opensolaris.org möglich, trotz Umweg über das SUN Download-Center auch mit wget nutzbar, und auch diesmal lohnt sich ein Blick in die Changelogs des Systems sowie die, des X-Window Systems.

Laden und ins Archiv legen – man weiß ja doch nie, wann man mal halbwegs aktuelle SVR4-Pakete braucht.

Download ist wie immer per opensolaris.org möglich, trotz Umweg über das SUN Download-Center auch mit wget nutzbar, und auch diesmal lohnt sich ein Blick in die Changelogs des Systems sowie die, des X-Window Systems.

Laden und ins Archiv legen – man weiß ja doch nie, wann man mal halbwegs aktuelle SVR4-Pakete braucht.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_126 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
IMPORTANT NOTE: Before updating a system, please review this document for all of the known issues that may affect the update.
IMPORTANT NOTE: The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through http://defect.opensolaris.org/

[Quelle: David Comay via opensolaris-annouce]

Download ist wie immer per opensolaris.org möglich, trotz Umweg über das SUN Download-Center auch mit wget nutzbar, und auch diesmal lohnt sich ein Blick in die Changelogs des Systems sowie die, des X-Window Systems.

Falls diesmal 125 wirklich das letzte Build sein wird: Laden und ins Archiv legen – man weiß ja doch nie, wann man mal halbwegs aktuelle SVR4-Pakete braucht.

You are invited to subscribe to my iCal-Calendar (using caldav) containing all the events, URL and notes of every tutorial and presentation listed on the official page.

This calendar is available via

• webcal, perfect for subscribing in iCal, Thunderbird and Outlook
• direct download
• web view (looks pretty strange)

I’m planing to update this calendar (so don’t just download it, subscribe it) in case of any changes.
Please keep in mind, that all the times are listed for the timezone Berlin/Germany and that germany will switch back from daylight saving time (DST) to normal time on 25. Oct.!

A calendar for the Linux Conference is available as well.

The OpenSolaris development package repository

http://pkg.opensolaris.org/dev/

has been updated to reflect the changes up to and including snv_125 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman “Slim Install” and the Image Packaging System (IPS).
[...]
IMPORTANT NOTE: Before updating a system, please review this document for all of the known issues that may affect the update.
IMPORTANT NOTE: The development builds have undergone limited testing and users should expect to uncover issues as the next release is developed. Bug reports and requests for enhancement are welcome through http://defect.opensolaris.org/

[Quelle: David Comay via opensolaris-annouce]

Download ist wie immer per opensolaris.org möglich, trotz Umweg über das SUN Download-Center auch mit wget nutzbar, und auch diesmal lohnt sich ein Blick in die Changelogs des Systems sowie die, des X-Window Systems.

Falls 124 wirklich das letzte Build sein wird: Laden und ins Archiv legen – man weiß ja doch nie, wann man mal halbwegs aktuelle SVR4-Pakete braucht.

See you in Dresden!

• svc:/system/filesystem/zfs/auto-snapshot:weekly
• svc:/system/filesystem/zfs/auto-snapshot:hourly
• svc:/system/filesystem/zfs/auto-snapshot:daily
• svc:/system/filesystem/zfs/auto-snapshot:monthly
• svc:/system/filesystem/zfs/auto-snapshot:frequent

Speziell in :hourly und :frequent: wenn alle 15 Minuten (:frequent) respektive jede Stunde (:hourly) ein ZFS-Snapshot der Datasets gezogen wird, fordern diese Services bei jeder Ausführung ein wake up der Hardware; und die Platte in meinem MacBook ist gefühlt ca. ⅔ meines Arbeitstags abgeschaltet.

An jeder Ecke sparen wir Strom wenn wir unterwegs sind, um maximal lang mit einer Akku-Ladung aus zu kommen, daher könnte es durchaus interessant sein zumindest :frequent abzuschalten, sobald man unterwegs ist.

pfexec svcadm disable svc:/system/filesystem/zfs/auto-snapshot:frequent

Oder bekommt jemand von Euch ein DTrace-Script gehackt, um festzustellen, ob die Platte(n) im Moment des Snapshots abgeschaltet sind, und diesen dann entsprechend zu verhindern? Hat diesen Gedanken schonmal jemand weiter gedacht oder vielleicht sogar Erfahrungen dazu?

Ich freue mich über Feedback!