Dolphin: Copy file path to klipper

Monday, February 20. 2012

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]

Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=application/octet-stream
Actions=sendToClipboard
 
[Desktop Action sendToClipboard]
Name=send Path to Clipboard
Exec=qdbus org.kde.klipper /klipper org.kde.klipper.klipper.setClipboardContents %u
Icon=klipper
 
Save it, open dolphin, right click on some file and in the Actions submenu appears a new entry. With a fancy klipper icon athe the start of the line - I just guessed that part of the .desktop file and it worked immediately.
Some infos to this are here (though related to KDE3 so it didnt work  as dcop isn't used in KDE4 and here (dcop has been replaced by qdbus with KDE4)

 

 

die eigene Certificate Authority mit XCA

Saturday, February 18. 2012

 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=

icinga / nagios via IPv6

Wednesday, February 15. 2012

 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,

 

define service {
        hostgroup_name                  remote-clients
        service_description             users logged in
        check_command                   remote-loggedin
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}

in commands.cfg die konkreten commands definieren:
define command{
        command_name    remote-loggedin
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$  -6 -l icingaremote -i /var/lib/icinga/.ssh/id_rsa -C '/usr/lib/nagios/plugins/check_users -w 20 -c 50'
        }
 

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

 

IPv6 - manches geht, manches nicht

Wednesday, February 8. 2012

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

Anschliessend nach Webmin/Webmin Configuration/Ports and Adresses/  und dort Accept IPv6 connections? mit Yes, fertig!
 
Der richtig dicke Vorteil von IPv6 ist ja, dass nun endlich die IPs nicht mehr knapp sind und man ganz ohne portumleitung und derlei Grauslichkeiten Clients und Server wieder end to end zusammenbekommt, auch wenn zwischen ihnen ein oder mehrere dsl mit dynamischen IP(v4) sind. Beispiel VPN oder Monitoring.
Erm, ja, ausser man hat auf openVpn gesetzt. Oder man versucht, zu nagios/icinga auf zu überwachenden Maschinen einen nrpe-server zu installieren. Der nrpe-Server horcht aber nur auf IPv4 und aus ist. Jetzt prokel ich in einem inoffiziellen Fork
E
in freundlicher Blogger verweist mich auf den icinga - nrpe, den hatte ich zuvor wohl übersehen. Einen Erfolg kann ich aber auch damit bislang nicht vermelden, mehrere Anläufe, buchstabengetreu oder mitdenkend den Angaben des Link zu folgen kompilierten fehlerfrei, blieben dann aber doch im ersten Test stecken:
/usr/local/icinga/libexec/check_nrpe -H 127.0.0.1 -n
CHECK_NRPE: Error receiving data from daemon.
hmm. Sachdienliche Hinweise richten sie bitte an die Kommentarfunktion weiter unten...
 
Mysql ist auch nicht ganz auf IPv6 eingerichtet, jedenfalls 5.1.49 aus debian/squeeze. 
netstat -tulpn|grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      19179/mysqld
und auf ::1 lauscht er eben nicht. Eine erhellende Diskussion zum Thema fand ich, und darin einen Link zu mysql 5.5 für squeeze, erprobt habe ich dies aber nicht.
 
 iftop gibt eine gute Übersicht über den Verkehr im Netzwerk, aber in debian squeeze nur für IPv4. Squeeze kommt mit iftop 0.17-16, IPv6 support gibt es erst ab 0.17-17 - leider ist auch in squeeze-backports nichts dabei.

 

tightvnc statt aufstehen

Friday, February 3. 2012

 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. 

(Page 1 of 1, totaling 5 entries)