RSSEinträge zu Tag: ssh
Displayport schaltet sich aus aber nichtmehr ein
Erstellt: 15.01.2016 08:58
Der Displayport ist teils ein wenig leidig. Wird der Monitor ausgeschaltet oder ausgesteckt, aktiviert sich der Port nichtmehr. Der Bildschirm bleibt schwarz weil die Grafikkarte kein Signal mehr liefert.
Dagegen gibt es zwei Lösungen, entweder man benutzt (z.B. und sofern möglich) einen Displayport-zu-HDMI-Adapter oder man weckt den Port mit xrandr wieder auf.
Ersteres unterdrückt das vom Displayport genutzte Datenformat welches das Problem verursacht und zwingt die Grafikkarte HDMI-Signale zu senden.
(Sollte diese Erklärung falsch sein, macht mich darauf aufmerksam. ;) )
Nun zur Softwarelösung. Ist der Bildschirm schon dunkel, ist es möglich per SSH mit xrandr das Signal wieder einzuschalten:
$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
DP2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 59.95*+
1920x1080 60.00
[...]
DP3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Auf dem Problemrechner über SSH die DISPLAY-Variable setzen um den Screen zu definieren und mit xrandr den Bildschirm in Standardauflösung aktivieren:
$ ssh user@dunklerrechner
$ export DISPLAY=:0
$ xrandr --output DP2 --auto
Das Ganze geht aber auch von selbst:
...automagisiert mit udev!
Zuerst wird über udevadm ausgelesen was für Events - zum Beispiel beim Ein- und Ausschalten des Monitors - generiert werden:
$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[71528.979723] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV [71529.116551] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
KERNEL[71531.400604] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV [71531.598893] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
Mit den ausgelesenen Event-Parametern (card0, drm, change) kann nun ein udev-Rules-File (/etc/udev/rules.d/70-dp-repair.rules) erstellt werden.
/usr/local/bin/dp-repair.sh ist hierbei das Script welches ausgeführt wird, wenn dieses Event eintritt. "user" sollte gegen den eigenen User ersetzt werden:
# /etc/udev/rules.d/70-dp-repair.rules
KERNEL=="card0", SUBSYSTEM=="drm", ACTION=="change", RUN+="/bin/su user -c /usr/local/bin/dp-repair.sh"
Hier noch das Beispielscript /usr/local/bin/dp-repair.sh. Es grept nach conntecteten Ports und aktiviert diese mit der Standardauflösung. Je nach Setup muss man dieses doch sehr simple Script noch den Bedürfnissen anpassen:
#!/bin/bash
# /usr/local/bin/dp-repair.sh
export DISPLAY=:0
for DPPORTS in $(xrandr | grep " connected " | awk '{ print$1 }'); do
/usr/bin/xrandr --output $DPPORTS --auto
done;
Ausführbar machen:
# chmod +x /usr/local/bin/dp-repair.sh
Ein komplexeres Script zur Monitorsteuerung gibts unter: https://github.com/geyslan/xrasengan
Nun schaltet udev den Displayport automatisch wieder ein.
-bash: /dev/null: Permission denied beim SSH-Login
Erstellt: 14.04.2011 15:48
Die Fehlermeldung "-bash: /dev/null: Permission denied" beim Login per SSH oder ähnliche Meldungen können entstehen, wenn die Dateirechte von /dev/null nichtmehr korrekt sind.
Kontrolliert man /dev/null zeigt sich folgendes Bild:
# ls -lh /dev/null
crw------- 1 root adm 1, 3 Mär 30 16:48 /dev/null
Korrekt wäre:
# ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mär 30 16:48 /dev/null
Wie kann das passieren?
Die sind die Standardrechte wie sie syslog-ng anlegt für Logfiles. syslog-ng gibt allen Logfiles die voreingestellten Rechte, so auch dem Verzeichnis /dev/null, wenn man direkt darauf verweist.
destination d_drop { file("/dev/null"); };
Dies umgeht man, indem man Nachrichten welche man verwerfen will ohne definierte Destination angibt:
destination d_drop { };
/dev/null repariert man am einfachsten wieder indem man es löscht und korrekt wieder anlegt:
# rm /dev/null
# mknod -m 0666 /dev/null c 1 3
Und schon ist wie Welt wieder in Ordnung:
# ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mär 30 16:52 /dev/null
ssh_config und sshd_config in cygwin finden
Erstellt: 22.11.2010 09:56
Die Config-Dateien von SSH (und anderen Programmen) sind unter cygwin ein wenig versteckt.Sie liegen nicht in /etc/ssh, sondern in /cygdrive/c/cygwin/etc/defaults/etc/.
Also /etc/ssh/ssh_config wird zu:
/cygdrive/c/cygwin/etc/defaults/etc/ssh_config
...und /etc/ssh/sshd_config zu:
/cygdrive/c/cygwin/etc/defaults/etc/sshd_config
...zumindest bei der Standardinstallation.
MySQLDump über SSH
Erstellt: 13.10.2010 18:14
Auch "mysqldump" lässt sich wie so vieles recht einfach über SSH übertragen:
# mysqldump -uUser -pPassword --opt --lock-tables=false -A | ssh root@192.168.0.123 "cat > /path/to/dump.sql"
root@192.168.0.123's password: Password [Enter]
...und einen Kaffee holen! :D
Festplatten-Images mit dd und ssh über das Netzwerk
Erstellt: 06.05.2010 16:12
Ein Image von einer Festplatte anfertigen, dies macht wohl jeder hin und wieder. Ein prominentes Werkzeug dazu ist ganz klar dd. Netterweise funktioniert das Ganze auch direkt über ssh, so vermeidet man ein Zwischenspeichern des Images:
# dd if=/dev/quelle | ssh user@host dd of=/pfad/ans/ziel.img