Blog
11 Oktober 2013 - by deeagle (G+)

Aktuell arbeite ich mit zwei Rechnern. Nachdem ich einen alten Samsung SyncMaster repariert habe nimmt dieser den Platz an meinem Code-Rechner ein. Ein Iiyama ProLite E1700S blieb dabei übrig. Dieser verfügt über eine Auflösung von 1280×1024 (17”). Als Kommunikations- und Leserechner habe ich meinen alten IBM R50e Laptop im Einsatz. Ziemlich OldSchool, aber leistet mir noch gute Dienste. Der Bildschirm ist ein 15” mit einer Auflösung von 1024×768. Der Einsatz des 17” am Laptop bietet sich hier an und ist über eine Monitor-Halterung sogar noch Platzsparender auf dem Schreibtisch.

Problem:

 Beim Systemstart werden beide Montiore angesteuert und die geringste Auflösung auf beiden angezeigt. Des Weiteren möchte ich das Display abschalten, während der Monitor angeschlossen ist (da der Laptop neben dem Schreibtisch steht). Es soll ganz normal das Laptop-Display genutzt werden, wenn der externe Monitor nicht angeschlossen ist.

Soll-Zustand (und jetziger Ist-Zustand)

Schreibtischaufbau: Laptop (IBM R50e) + ext. Monitor

Laptop (IBM R50e) + ext. Monitor

Lösungsmöglichkeit:

Die Konfiguration nehme ich in meinen Systemen via RandR vor und ist unter Debian/Ubuntu das Standardwerkzeug zum Einstellen der Monitoreinstellungen. Durch den Aufruf von xrandr in einer konsole werden die aktuellen Monitore und deren Betriebsmodi angezeigt und wählbar. Da ich mich vor dem Start des Benutzerkontos noch einloggen soll, möchte ich, dass die Monitorkonfiguration automatisch nach dem Einloggen eingestellt wird. Unter OpenBox schreibe ich mir dazu ein Helferscript (bash) und nehme es in die autostart.sh auf. Somit wird die Konfiguration bei jedem Benutzerlogin überprüft und gesetzt.

 

1. Bestimmen der Monitore mittels RandR

user@host:~$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048
LVDS1 connected (normal left inverted right x axis y axis)
    1024x768       60.0 +
    800x600        60.3     56.2
    640x480        59.9
VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024      60.0*+   75.0
   1280x960       60.0
   1152x864       75.0
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        72.8     75.0     66.7     60.0
   720x400        70.1

2. Bestimmen der Einzel-Befehle
LVDS1 bezeichnet hier das Laptop-Display und VGA1 den externen Monitor.

  1. Laptop-Monitor ausschalten
    xrandr --output LVDS1 --off
  2. Externen Monitor konfigurieren
    xrandr --output VGA1 --auto

Durch den Aufruf beider Befehle ergibt sich die gewünschte Konfiguration bei angeschlossenem Monitor.

3. Automatisiertes Bash-Script

xrandr zeigt durch den Eintrag ‘connected’ alle aktuell angeschlossenen Systeme an. Dies machen wir uns zu nützen um den Anschluß des Monitors abzuprüfen. Wenn der Monitor angeschlossen ist  sollen beide Konfigurations-Befehle ausgeführt werden. Dies überprüfe ich mit einem einfach grep connected. Das folgende Script speicher ich unter ~/.config/xrandr_monitor_setting und mache es anschließend ausführbar.

#!/bin/bash
 
DISPLAY_LAPTOP="LVDS1"
DISPLAY_MONITOR="VGA1"
USER_HOME="/home/$(whoami)"
 
MONITOR_CONNECTED="$DISPLAY_MONITOR connected"
SEARCH=$(xrandr | grep "$MONITOR_CONNECTED" | wc -l)
 
if [ $SEARCH -eq 1 ]; then
        # 1. laptop monitor off
        $(xrandr --output $DISPLAY_LAPTOP --off)
        # 2. Monitor on
        $(xrandr --output $DISPLAY_MONITOR --auto)<br />        # 3. specials commands for this config starts here
else
        $(xrandr --output $DISPLAY_LAPTOP --auto)
fi
 
exit 0

4. Script ausführbar

user@host:~$ chmod +x ~/.config/xrandr_monitor_setting

5. Autostart-Aufruf für OpenBox

 Der Aufruf wird nun unter ~/.config/openbox/autostart.sh hinzugefügt (nach belieben, aber vor exec openbox!)

 Von nun an wird die Systemeinstellung automatisch nach dem Login gestartet.


Blog
17 Mai 2013 - by deeagle (G+)
Steam on Linux Quelle: http://www.winload.de/steam/steam-linux

Steam on Linux Quelle: http://www.winload.de/steam/steam-linux

Steam ist schon länger für Linux erhältlich. Offiziell wird dabei Ubuntu Linux unterstützt. Bisher gab es mehrere Scripte um das ganze auch unter Debian zum laufen zu bekommen. Ich diese Scripte vor einiger Zeit für meine Zwecke portiert und in einem allgemeinen Script zusammengefasst.

Vlt. kann es ja auch noch für den ein oder anderen nützlich sein und somit habe ich es auf Github gelegt.

Was kann das Script?

Bei Ausführung wird geschaut ob die benötigten Libs und Steam installiert sind und ggf. nachinstalliert.

Wie funktionierts?

Man öffne ein Terminal (z.B. xterm) und führt das script aus (./run_steam.sh) und steam sollte starten.

Root-Rechte?

Das Scripte fragt ggf. nach Root-Rechten um steam.deb zu installieren.

Update-Fehler!

Da Ubuntu-Pakete installiert werden und diese teils schon fortgeschritten sind können Probleme auftreten. Updates müssen dann z.B. via # aptitude safe-upgrade –full-resolver -y eingespielt werden.

 

Zu github: https://github.com/deeagle/debian_steamrun


Schlagwörter: , , , ,
Blog
26 November 2012 - by deeagle (G+)

Am Wochenende habe ich mich mal intensiv mit dem Projekt wp-cli auseinandergesetzt. Der Name steht für WordPress-Command-Line-Interface und befähigt einen WordPress-Installationen via Shell zu administrieren. Also getestet und für sehr komfortabel befunden.

Heute morgen dann der erste Montag-Aufschauer. Mein Mailclient meldet einen rkhunter-Warning mit der Nachricht ‘Please insepct this machine, because it may be infected.’ im Posteingang. Ok, erstmal einen Kaffee holen und dann schauen wir mal.

Als erstes auf der Maschine eingeloggt und das Log-File analysiert. Also was ist überhaupt die Warnung und wodurch wird diese ausgelöst.

/var/log/rkhunter.log meldet auch eine mögliche Infektion durch RH-Sharpe’s Rootkit und gefunden während des scans von /usr/bin/wp.

Als erstes die Debian-Prüfsummen begutachten.

#  debsums | grep FAILED

Hier wurde mir aber nichts von dem Paket wp angezeigt.

wp?

Da war doch was! Denn mittels wp wird das wp-cli in der shell aufgerufen und bedient.

Also Aufruf und Paket geschaut und ja, es ist das WordPress command line interface.

Um das ganze zu Beheben gibt es jetzt zwei Möglichkeiten:

  1. Den wp-cli-Aufruf ändern (z.B. in wps)
  2. rkhunter mitteilen, dass /usr/bin/wp nicht infiziert ist und nicht mehr gescannt werden soll.

Ich habe mich dabei für Variante 2 entschieden, da ich von wp-cli

  1. noch mehrere Update beziehen und testen werde,
  2. ich das ganze zum testen auf mehreren lokalen Maschinen installiert habe.

Dafür das Conf-File von rkhunter mit einem Editor der Wahl öffnen (# vi /etc/rchunter.conf) und die Zeile RTKT_FILE_WHITELIST suchen.

...<br />RTKT_FILE_WHITELIST="/usr/bin/wp"<br />...

Danach einen neuen Durchlauf starten und im Log-File wird nun an der Stelle das auslassen angezeigt, aber ohne Fehlermeldung beendet.

/var/log/rkhunter.log

...<br />Info: Found file '/usr/bin/wp': it is whitelisted for the 'rootkit' check.
...
Rootkit checks...
    Rootkits checked : 247
    Possible Rootkits: 0

Links:

rkunhter, wp-cli, wordpress


Blog
7 Dezember 2011 - by deeagle (G+)

Sehr interessant ist es ja schon. Gestern nen Artikel von einem Google-Mitarbeiter bei Google+ gelesen, der auf die neue Graphen-Funktion in Google aufmerksam machte. An sich ist es ja eine coole Funktion, die man auch mal gebrauchen kann, jedoch gab’s das auch schon früher … z.B. bei WolframAlpha. Interessant ist, sobald es von Google kommt schaut jeder bzw. geht mom die Love-Funktion (abs(x)+sqrt(1-x^2), sqrt(abs(x))-sqrt(1-x^2)) durch’s Netz. Bei WolframAlpha bin ich in der ganzen Zeit noch nicht drauf gestoßen … Als Vergleich mal die beiden Ausgaben der Betreiber zur Funktion.

 

Love-Funktion von Google

Love-Funktion von Google

 

Love-Funktion von WolframAlpha

Love-Funktion von WolframAlpha

 

Die Macht der Marke …

Direktlinks:

  1. Google
  2. WolframAlpha

Schlagwörter: , ,
Blog
5 Dezember 2011 - by deeagle (G+)

Yeah, heute nochmal kurz die Netzwerkbridge und die damit verbundenen Geräte überprüft. Genau 100 Tage ist die WLAN-Bridge nun online und funktioniert tadellos. Die Geräte sind dabei zwei Linksys WRT54g mit nem DD-WRT-Image. Eine Kiste dient dabei zusätzlich noch als WLAN-Hotspot für die Endgeräte. Das ganze war vor 100 Tage auch ganz locker innerhalb von 2h Stunden in Betrieb genommen (inkl. Planung und Test).

Der Hotspot
Fehlerquote von > 0.020%

Die Gegenstelle
Fehlerquote ~0% (5 Error Packages)

 

Und weiter so. :)


Schlagwörter: , , ,

« Ältere Einträge