c0t0d0s0.org

Ich werde wieder einen Vortrag im Rahmen eines Businessbreakfasts halten. Diesmal geht es um Hilfsmittel, Änderungen auf vielen Systemen auszurollen. Je größer eine Solaris-Installation wird - sei es nun durch viele Server aber auch der freigiebige Einsatz von Solaris (Kernel) Zones - desto mehr stellt sich die Frage nach Automatisierung der Administration, um die natürlichen Varianzen sich wiederholender menschlicher Arbeit zu vermeiden, sprich sicherzustellen, das bei 50 Zonen nicht 51 leicht unterschiedliche Konfigurationen zu finden sind.

Solaris 11.2 bietet eine Reihe von Mechanismen, um Administration zu automatisieren. In diesem Vortrag möchten wir erläutern, wie man sich Puppet auch auf einem einzigen Server mit vielen Zonen nutzbar machen kann (oder bei vielen Servern mit vielen Zonen), was es mit RAD - dem remote administration daemon - auf sich hat und wie man diesen selbst verwenden kann. Weitere Themen, die anhand praktischer Beispiele vorgeführt werden sollen, sind ein kurzer Einblick in den Automated Installer und die automatisierte Generierung von Konfigurationsdateien mit SMF Stencils.

Das Breakfast findet am 19.6. in Hamburg statt. Die Anmeldeprozedur ist ein wenig anders für dieses Event: Ihr könnt Euch mit einer Mail via diesem Link anmelden. In Berlin wird es den gleichen Vortrag am 10.7 geben. Hier könnt Ihr euch wie gehabt unter diesem Link anmelden.

I thought i know a lot about Solaris, however today i found out about a feature that is in Solaris i never heard of. It was on an internal discussion alias. Or to be exact ... i think i've read that part of the man page but never connected the dots: Let’s assume you have a set of files in a directory that you shouldn’t delete. It would be nice to have some protection, that a short but fatally placed rm typed under caffeine deprivation doesn't wipe out this important file. It would be nice, that the OS protects you from deleting it except you really, really want it (and thus execute additional steps).

Let’s assume those files are in /importantfiles. You can mark this directory with the nounlink attribute.

root@aramaki:/apps/ADMIN# chmod S+vnounlink .
root@aramaki:/apps/ADMIN# touch test2
root@aramaki:/apps/ADMIN# echo „test“ >> test2
root@aramaki:/apps/ADMIN# cat test2
test
root@aramaki:/apps/ADMIN# rm test2
rm: test not removed: Not owner
root@aramaki:/apps/ADMIN# chmod S-vnounlink .
root@aramaki:/apps/ADMIN# rm test2

If you just want to do it for a single file, this is possible, too

root@aramaki:/apps/ADMIN# chmod S+vnounlink test4
root@aramaki:/apps/ADMIN# rm test4

You can still change the files in the directory. Of course you are still able to write zeros or trash into it and thus removing the content by accident. You can write into the files But even as root, i can’t delete those files without removing this attribute. So you can’t delete this files by accident. Very useful for a broad set of files, for example redo log and datafiles from your database. The obvious requirement: You application shouldn’t delete the files as a regular pattern of operation. Solaris would block you application from doing so.

By the way: Darren Moffat showed how to make a file immutable back in 2008 with the same command, just a different attribute in his blog entry "Making files on ZFS Immutable (even by root!)"