dreckhände

On windows I used to like the Windows Explorer as a file manager, at least in the shape it had with w2k. And there has been  toy pack by Microsoft which, among other more or less useful add ons, allowed me to add an "send to clipboard" entry to the context menue of any file which would push the file's path into the clipboard and thus helped me to avoid typing it. I missed it ever since I changed to linux/KDE as my desktop environment. Yes, you can get the folder path but that's not all I wanted.

However I found hob to fix this and add such an entry to the dolphin file manaer's context menue, and it was easy, too.

The thing that needs to be added is called a ServiceMenu in KDE jargon, I let locate find me where those sort of files live on my system and it returned a number of them at /usr/share/kde4/services/ServiceMenus/. I assume there are other folders you could put them , i.e. below ~/.kde/, but I was in a hurry and just got root to create /usr/share/kde4/services/ServiceMenus/sendPathToClipboard.desktop The name is not important as long as it is unique and ends in .desktop.

Opened it in an editor and this is what I put there:

[Desktop Entry]

 Für eine Gruppe Rechnern in einem Intranet sollen für https Zertifikate erstellt werden. Alle Systeme sind unter mehr als einer Domain erreichbar, die Zertifikate sollen jeweils für alle Namen gültig sein. 'Echte', also von einer in den Browsern vorinstallierten CA signierte Zertifikate scheiden aus Kostengründen aus, Um nicht für jeden einzelnen Rechner eine Ausnahme in den Browsern speichern zu müssen setze ich eine eigen CA auf und signiere die einzelnen Zertifikate mit diesem CA-Zertifikat. Es reicht dann, dieses eine Zertifikat in den browsern zu importieren und alle damit signierten Zertifikate werden grün.

Man kann das natuerlich 'händisch' mit openssl allein machen, aber die Verwaltung wird leicht unübersichtlich. Ich habe XCA genommen, ein 'x509 Certification Authority management tool based on QT4', dass ich auf debian squeeze / KDE mit apt-get install xca installierte.

XCA hat Reiter für Schlüssel, Unterschriftsanfragen, Zertifikate, Rücknahmelisten und Vorlagen. Diese Vorlagen sind XCA-spezifisch, man kann sie neu erstellen aber auch bestehende Zertifikate oder Unterschriftsanfrage in eine Vorlage exportieren. Das ist in der Praxis eine ziemliche Hilfe und erspart Abtippen, für eine neues Request wählt man dann einfach im Reiter Herkunft unten das passende Template und traegt dessen Werte mit Übernehmen ein, anschliessend ändert man nur das, was wirklich neu muss.

Bei der Erstellung des CA-Zertifikates muss man darauf achten, im Reiter Erweiterungen in den Grundbeschränkungen als Typ Zertifikats Authorität einzustellen, Kritisch markieren, im Reiter Key Usage müssen links Certificate Sign und CRL Sign markiert sein, im Reiter Netscape markiert man SSL CA, S/MIME CA und Object Signing CA.

Bei den Zertifikaten für mehr als einen Domainnamen ist das entscheidende Feld im Reiter Erweiterungen die Zeile subject alternative name, hier auf Bearbeiten klicken und in dem Formular links oben DNS und rechts daneben den ersten Namen, mit Hinzufügen eintragen. Das wiederholt man nun der Reihe nach für jeden Namen, für den das Zertifikat gelten soll, auch für den schon auf dem vorigen reiter eingetragenen common name. Es ist wohl so, dass, wenn das Feld subject alternative name im Zertifikat gesetzt ist, nur die dort eingetragenen Werte gelten. Bei Key Usage muss man noch darauf achten, dass im rechten Feld auch TLS Web Server Authentication markiert ist, sonst bekommt man (in FireFox, der da auskunftsfreudiger ist als etwa Chrome) den Fehler SEC_ERROR_INADEQUATE_CERT_TYPE."The rule is that IF a server cert contains an extended Key Usage extension, then it MUST include the extended usage for server authentication."

bekommt man den Fehler sec_error_unknown_issuer zu sehen, muss man an die erzeugten Zertifikate das Zertifikat der signierenden CA anhängen, für server, die alles in einer datei wollen (so Courier) etwa per 

cat domain.tld.{key,crt} my-own-CA.crt >domain.tld.pem

 Bei Webmin zb geht beides, man kann eine wie oben erzeugte combo als keyfile in /etc/webmin/miniserv.conf eintragen, oder dort nur den key selbst und die Zertifikate als certfile= und extracas=

 Wie schon erwähnt kann der zu nagios gehörende nrpe kein IPv6 und der icinga-nrpe wollte bei mir einfach nicht laufen. Die zu überwachenden Rechner liegen aus Sicht von IPv4 recht disparat, manche im lokalen Lan, manche in einem entfernten Lan, dass per DSL angebunden ist, teils mit statischen IP bei einem Hoster. Alle haben aber IPv6 und so habe ich den Weg über check_by_ssh gewählt.

- ringsum apt-get install nagios-plugins-standard
- ringsum einen fuer die nagios-Abfragen dedizierten und ansonsten rechtlosen user (icingaremote:icingaremote) anlegen
- auf dem icinga-server fuer den user, unter dem der  server laeuft, ein private/public Schlüsselpaar erzeugen
   ssh-keygen -t rsa
- ringsum mkdir  /home/nagiosremote/.ssh und dort in authorized_keys den public key des erzeugten Schluesselpaars vom icinga-server ablegen
- zur Kontrolle vom icinga-server aus ssh auf die entfernten Rechner  ssh icingaremote@domain.tld

Wenn das soweit geht, auf dem icinga-server in /etc/icinga/objects eine clientx.cfg je remote client anlegen, in hostgroups.cfg Gruppen fuer Rechner mit identischen abfragen anlegen, in services_icinga.cfg service definieren,

Einzig der Test auf mysql auf dem localhost wollte partout IPv4...
 

Bei webmin war ich der festen Ansicht, dass IPv6 nicht geht und nie gehen wird. Ich hatte mal so eine Bemerkung auf der Projektseite gelesen, und da es in perl ist (perl considered harmful)... Stimmt aber gar nicht (mehr): 

aktuelle Versionen von webmin lassen sich mit einem mausklick Ipv6-enablen, alles, was sie dazu brauchen, ist, ein package:

 apt-get install  libio-socket-inet6-perl

 Oft ist es ja nur der Rechner in der anderen Ecke des Lab, dessen desktop ich mal eben vor mir sehen möchte, und lieber nicht hinübergehen. Aber es funktioniert im wesentlichen ganz genau so mit einer Kiste, die hunderte Kilometer entfernt ist: eben mal vnc aufmachen.

Ich bin da, nach einigen Versuchen, mal auf tightvnc gestossen, der sich flink installieren und einrichten lässt und prima mit dem kdrc harmoniert. Und tightvnc laesst sich klaglos durch einnen ssh-Tunnel schicken, und das beruhigt schon. 

Ich gehe hier mal davon aus, dass zu dem entfernten Rechner ohnehin eine ssh-Verbindung besteht und Passworte dank authentification keys kein Thema sind.

Auf dem entfernten Rechner ist tightvnc schnell installiert, mit debian reicht ein

apt-get install tightvncserver  (als root)

und dann startet man den server zum initialisieren als der user, mit dem man auf dem entfernten Rechner aktiv sein will. 

vncserver

Man darf/muss ein Passwort festlegen, notieren! - man wird bei jeder Verbindung danach gefragt werden. Erstmal fertig.
Um jetzt konkret eine Session zu öffnen, gebe ich, als user, auf der console des entfernten Rechners

tightvncserver -nolisten tcp -localhost -geometry 1152x864 -nevershared :2
und kontrolliere den Erfolg mit
ps aux|grep vnc

Xtightvnc :2 -desktop X -auth /home/user/.Xauthority -geometry 1152x864 -depth 24 -rfbwait 120000 -rfbauth /home/user/.vnc/passwd -rfbport 5902 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb -nevershared -nolisten tcp -localhost :2

der rfbport (5902) und die Nummer des desktops (:2) sind die beiden Daten, die ich in dieser Ausgabe kontrolliere, dann bin ich mit dem Server soweit fertig und wechsele zu einer Shell des lokalen Rechners, auch hier als passender user.

krdc vnc:/127.0.0.1:2 & ssh user@host.domain.tld -N -C -L 5902:127.0.0.1:5902

und pling öffnet sich der kdrc mit der Passwortabfrage und dann baut sich der entfernte Desktop auf. Bei langameren Verbindungen (dsl rauf und schmales dsl runter) vereinfacht es die Maussteuerung, wenn man im krdc oben "Local Cursor" aktiviert.