www.7bf.de – Blog

December 11, 2009

Nagios3 unter Ubuntu 9.10

Filed under: Linux, Nagios, Ubuntu — christian @ 20:28

Hi @ll,

während der Installations- und Einrichtungs-Phase meiner neuen Server habe ich mir auch einen Nagios-Server gegönnt :-)

Diesen konnte ich unter Ubuntu quasi Out-of-the-Box per aptitude installieren, ohne zusätzliche Repositories angeben zu müssen.

Nur ein kleines Manko hatte das ganze:
Nagios bietet die Möglichkeit, einen Service-Check nicht erst zur geplanten Zeit auszuführen, sondern zu einer anderen. Dies kann über das Webfrontend geschehen.
In der Ubuntu-Installation ist ein “Re-Schedule” jedoch nicht möglich.

Nach ein bisschen Google fand ich einen Beitrag [1], welcher genau dieses Problem unter Debian Etch beschreibt.

Also folgendes ausgeführt:

/etc/init.d/nagios3 stop
dpkg-statoverride –update –add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride –update –add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

Und alles lief wie gewollt :-)

Gruß
c

[1] http://blog.devnu11.net/2008/04/nagios3-debian-etch-pakete/

November 4, 2008

Tastatur-Probleme im “VMware-Gast” unter Ubuntu 8.10 mit VMware Workstation 6.5

Filed under: Linux, Ubuntu, VMware — christian @ 15:44

Hi @ll,

da ich auf meinem Firmennotebook mitlerweile ein Ubuntu fahre, brauche ich natürlich weiterhin die ein oder andere VM :-)

Da mein Arbeitgeber VMware-Partner ist, liegt es natürlich nahe, dass man den Marktführer wählt :-D

Nur leider hatte ich das Problem, dass ich in der VM die Tastatur nur bedingt verwenden konnte.

Ein Druck auf den “Pfeil nach unten” (Cursor/down) brachte mir ein öffnen des Start-Menüs.
Ein Druck auf “-” brachte mir ein “?”.
“Strg+Alt+Entf” brachte nur ein Release der VM, was bei einer Windows-VM sehr hinderlich ist…
Und so weiter… das war kein Englisch, kein Deutsch, sondern irgendwas verwaschenes…

Auf der VMTN Community-Seite von VMware habe ich dann einen Treffer gelandet [1].

In die /etc/vmware/config die folgenden Zeilen am Ende anfügen:

xkeymap.keycode.108 = 0×138 # Alt_R
xkeymap.keycode.106 = 0×135 # KP_Divide
xkeymap.keycode.104 = 0×11c # KP_Enter
xkeymap.keycode.111 = 0×148 # Up
xkeymap.keycode.116 = 0×150 # Down
xkeymap.keycode.113 = 0×14b # Left
xkeymap.keycode.114 = 0×14d # Right
xkeymap.keycode.105 = 0×11d # Control_R
xkeymap.keycode.118 = 0×152 # Insert
xkeymap.keycode.119 = 0×153 # Delete
xkeymap.keycode.110 = 0×147 # Home
xkeymap.keycode.115 = 0×14f # End
xkeymap.keycode.112 = 0×149 # Prior
xkeymap.keycode.117 = 0×151 # Next
xkeymap.keycode.78 = 0×46 # Scroll_Lock
xkeymap.keycode.127 = 0×100 # Pause
xkeymap.keycode.133 = 0×15b # Meta_L
xkeymap.keycode.134 = 0×15c # Meta_R
xkeymap.keycode.135 = 0×15d # Menu

Ein /etc/init.d/vmware restart hinterher geschoben und läuft! :-)

Gruß,
c

[1] http://communities.vmware.com/thread/177133?tstart=45

November 1, 2008

Auflösung am externen Monitor unter Ubuntu 8.10

Filed under: Linux, Ubuntu, X — christian @ 16:27

Hi @ll,

im vorher gehenden Beitrag hatte ich noch das Problem, dass mein externes 22″ WS-TFT nicht über 13′irgendwas’x768 kam.

Das Problem lässt sich sogar lösen ;-)

editiere die /etc/X11/xorg.conf und suche nach

Section “Screen”
Identifier      “Default Screen”
Monitor         “Configured Monitor”
Device          “Configured Video Device”
SubSection “Display”
Virtual 2389 768
EndSubSection
EndSection

Dort muss lediglich die Zeile “Virtual” angepasst werden :-)

Die erste Zahl ist die Display-Breite vom externen TFT plus die vom Notebook-TFT und die zweite ist die maximale Display-Höhe (ich meine hier jeweils die Auflösungswerte).

Bei mir also:
TFT (1680×1050)
Notebook (1024×768)
erster Wert: 1680+1024=2704
zweiter Wert: 1050>768 also =1050

Daraus ergibt sich dann der folgende Eintrag:

Section “Screen”
Identifier      “Default Screen”
Monitor         “Configured Monitor”
Device          “Configured Video Device”
SubSection “Display”
Virtual 2704 1050
EndSubSection
EndSection

Und schon lässt sich bequem über das “Bildschrimauflösung”s-Tool von Ubuntu ein Dual-Head einrichten…

Ist sogar einfacher als unter Ubuntu 8.04 :-)

I like it!

Gruß,
c

Update von Ubuntu 8.04 auf Ubuntu 8.10

Filed under: Linux, Ubuntu — christian @ 15:28

Hi @ll,

heute habe ich mein System mal auf den aktuellen Stand gebracht.

Auf der Webseite der deutschen Ubuntu-Users Community [1] gibt es eine gute Anleitung für ein Upgrade auf das nächste Release [2].

Dieser Anleitung bin ich gefolgt und bin nun stolzer Nutzer eines Ubuntu 8.10 :-)

Was ich besonders an dem neuen Ubuntu-Release mag, ist die Möglichkeit der UMTS-Einwahl über den Network-Manager. Das spart mir schonmal eine Applikation :-D

Ich habe jedoch noch ein kleines Problem… :-/

Ich habe ein IBM/Lenovo ThinkPad R60 mit einem 4:3 Display (max. 1024×768). Extern angeschlossen habe ich einen 22″ WS (max. 1680×1050).
Bei Ubuntu 8.04 war es so, dass ich mit angeschlossenem WS-TFT gebootet habe und schon hatte ich die passende Auflösung.
Das ist nicht mehr der Fall!
Ich starte und habe maximal die Möglichkeit (auch nachträglich über das Konfig-Tool für die Bildschirmauflösung) der Auflösung 1360×768.
Auch wenn ich das Notebook-TFT deaktiviere… :-/
Ich finde das extrem störend!!
Mal sehen, wann ich die Zeit finde, mich damit zu befassen.
Bei Gelegenheit sollte ich auch mal einen meiner 17″ TFTs anschliessen und schauen, ob die wenigstens auf ihre 1280×1024 kommen, oder ob die Limitierung durch das Notebook-Display entsteht…
Wäre schon recht störend, wenn dem so wäre… :-/

Wenn ich was habe, gibts nen neuen Eintrag :-)

Gruß,
c

[1]http://www.ubuntuusers.de
[2]http://wiki.ubuntuusers.de/Upgrade_auf_Intrepid

October 14, 2008

Ubuntu 8.10 (nix LTS) kommt :-)

Filed under: Linux, Ubuntu — christian @ 14:15

Hi @ll,

auch wenn ich LTS eine feine Sache finde, ist es auf einem Desktop/Notebook, dass nicht ausschliesslich auf stabilität getrimmt ist nicht zwingend erforderlich.

Daher:

Gruß,
c

September 11, 2008

Xen DomU als OpenVPN Gateway

Filed under: Linux, OpenVPN, Ubuntu, Xen — christian @ 17:01

Hi @ll,

ursprünglich schon einmal erstellt und von Madd kritisiert, hier nun die neue Variante des Howto…

Vorweg sei gesagt, dass in dieser Anleitung zwei Varianten benannt werden.
1) Anmeldung über Zertifikate
2) Anmeldung über Zertifikate und Zugangsdaten (Benutzername/Passwort)
Der Unterschied liegt lediglich in den Konfigurationsdateien von Server und Client, daher werde ich erst an der entsprechenden Stelle darauf hinweisen.

Betriebssystem
Um dieses Howto zu erstellen habe ich ein Ubuntu 8.04 Server unter Xen 3.0.3 über debootstrap installiert.

Zusätzliche Pakete
Nach dem ersten Start sollten noch die folgenden Pakete installiert werden:

  • openssh-server (nur zu administrativen Zwecken / ich habe die OpenVPN-Konfiguration darüber durchgeführt)
  • openvpn (zur Einwahl via OpenVPN… o_O )
  • openssl (zur Zertifikatserstellung benötigt)
  • iptables (für IP-Masquerading benötigt)

Erstellung der Zertifikate
Zunächst in den richtigen Ordner wechseln:

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/

Dier muss die Datei vars editiert werden. Dabei bitte (mindestens) die folgenden Zeilen anpassen:

export KEY_COUNTRY=DE
export KEY_PROVINCE=NRW
export KEY_CITY=Paderborn
export KEY_ORG=”7bf”
export KEY_EMAIL=”c@7bf.de”

Die Werte sind natürlich entsprechend eurer Umgebung anzupassen.

Durch Eingabe der folgenden drei Kommandozeilen wird das CA-Zertifikat (für die Erstellung von Server- und Client-Zertifikat erforderlich) erstellt:

. ./vars
./clean-all
./build-ca

Bei Ausführung von ./build-ca werden einige Informationen abgefragt, welche entsprechend eurer Daten angegeben werden sollten.
Bis auf den folgenden Eintrag sollten alle Werte bereits durch eure Angaben in der Datei vars passen.

Common Name (eg, your name or your server’s hostname) [7bf CA]:servername.7bf.de

Jetzt wird das Server-Zertifikat durch Aufrufen der folgenden Kommandozeile erstellt:

./build-key-server server

An dieser Stelle werden erneut einige Abfragen erfolgen, von denen wieder einige manuell Beantwortet werden müssen:

Common Name (eg, your name or your server’s hostname) [server]:servername.7bf.de
A challenge password []:   <– MUSS NICHT ANGEGEBEN WERDEN!!
An optional company name []:7bf

Nun erstellen wir die Diffie Hellmann Parameter.
Warum dies erforderlich ist, habe ich leider noch nicht feststellen können, bin aber für jeden Hinweis dankbar :-)

Ich habe nur festgestellt, dass es ohne nicht funktioniert.

./build-dh

Als letztes Zertifikat muss noch ein Client-Zertifikat erstellt werden.
Der Einfachkeit halber nenne ich das hier einmal client1, kann aber jegliche Form von Namen haben (abgesehen von Leer- und Sonderzeichen, da kann es zu Problemen kommen).

./build-key client1

Die Angaben können mit denen des Server-Zertifikates gleichgesetzt werden, bis auf den Common Name, dieser sollte den Namen des Clients (in der Kommandozeile zur Erstellung des Zertifikates angegeben) beinhalten.

Die Zertifikate sind damit erstellt und wurden unter

/usr/share/doc/openvpn/examples/easy-rsa/2.0/keys

abgelegt.

Nun müssen diese noch auf Server- und Client-Seite verfügbar gemacht werden.

Bitte wie folgt verteilen:

ca.crt Server + alle Clients
ca.key nur an der key signing machine
dh{n}.pem Server
server.crt Server
server.key Server
client1.crt Client
client1.key Client

Der Einfachste Weg zur Verteilung ist die Ablage in /etc/openvpn/keys/, da in /etc/openvpn/ auch die Server- bzw. Client-Konfiguration abgelegt wird und damit alles zusammen ist (vereinfacht z.B. ein Backup).

Konfiguration des Servers

Exemplarisch stelle ich hier zwei Server-Konfigurationen bereit, um (wie oben bereits besagt) die Einwahl mit und ohne Zugangsdaten zu verdeutlichen. Abzulegen ist die Konfigurationsdatei nach ihrer Erstellung in /etc/openvpn/. Eine Namensvorgabe gibt es nicht, doch muss die Datei auf .conf enden und wird dann beim starten des OpenVPN-Dienstes automatisch geladen.

Die Konfiguration sieht vor, dass entweder der FQDN (Domain-Name) des Servers angegeben wird, oder eine IP-Adresse. Des weiteren wird ein privates Netzwerk angegeben, welches für die eingewählten VPN-Clients gedacht ist. Dies muss kein Netz sein, dass der Server physisch beherrscht, sondern ein anderes, da der Server ohnehin als Gateway für die Clients fungieren wird. Als DNS-Server übergebe ich zwei von der Universität Paderborn, es können aber auch andere (z.B. ein eigener sein).

Einwahl nur mit Zertifikaten (keine Benutzer-Authentifizierung erforderlich):

user nobody
group nogroup
dev tun
local fqdn_oder_ip_vom_server
port 1194
proto tcp
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 192.168.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “redirect-gateway”
push “dhcp-option DNS 131.234.137.23″
push “dhcp-option DNS 131.234.137.24″
client-to-client
keepalive 10 120
comp-lzo
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log

Einwahl mit Zertifikaten und zusätzlicher Benutzer-Authentifizierung (Benutzer-Account auf dem Server):

user nobody
group nogroup
dev tun
local fqdn_oder_ip_vom_server
port 1194
proto tcp
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 192.168.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “redirect-gateway”
push “dhcp-option DNS 131.234.137.23″
push “dhcp-option DNS 131.234.137.24″
client-to-client
keepalive 10 120
comp-lzo
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
plugin /usr/lib/openvpn/openvpn-auth-pam.so common-auth
client-cert-not-required
username-as-common-name

Da es sich bei dem VPN-Netzwerk um ein virtuelles Netzwerk handelt, benötigt der Server auch eine IP-Adresse in diesem Netzwerk. Zu diesem Zweck muss das Kernel-Modul tun geladen werden.
Auf physischen Linux-Servern ist das i.d.R. kein Problem, doch in Xen DomU’s ist normalerweise kein Kernel installiert.
Daher installiert man entweder einen Kernel inkl. Module oder kopiert sich einfach die Module der Xen Dom0 (Host-System der Xen-Maschine):

scp root@xen-dom0-name:/lib/modules/$(uname -r) /lib/modules/$(uname -r)

Darauf folgende kann auch das entsprechende Modul geladen werden:

modprobe tun

Der Server soll als Gateway fungieren, daher wird noch IP-Masquerading benötigt. Dazu sind drei Kommandozeilen erforderlich:

iptables -t nat -F POSTROUTING
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

Als Netzwerkadresse und Subnetzmaske sind hier wieder jene gefordert, die in der Server-Konfiguration verwendet wurden.

Nun kann der Server-Dienst gestartet werden:

/etc/init.d/openvpn start

Konfiguration des Clients

Auch hier stelle ich zwei Konfigurationsdateien bereit, analog zu den Server-Konfigurationen. Diese sollten ebenfalls unter /etc/openvpn/ abgelegt werden (nur eben auf dem Client). Auch hier gilt als Vorgabe lediglich die Endung .conf zu verwenden.

Einwahl nur mit Zertifikaten (keine Benutzer-Authentifizierung erforderlich):

client
dev tun
proto tcp
remote fqdn_oder_ip_vom_server 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key
comp-lzo
verb 3

Einwahl mit Zertifikaten und zusätzlicher Benutzer-Authentifizierung (Benutzer-Account auf dem Server):

client
dev tun
proto tcp
remote fqdn_oder_ip_vom_server 1194
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key
comp-lzo
verb 3

Auch auf dem Client muss nun das Kernel-Modul tun geladen werden.
In den gängigen Distributionen sollte dies problemlos funktionieren:

modprobe tun

Damit kann die VPN-Einwahl durchgeführt werden:

openvpn /etc/openvpn/client1.conf

Ich verwende den Namen client1 hier nur exemplarisch… ihr habt die Datei selbst angelegt und wisst daher am besten, wie diese Zeile angepasst werden muss.

Bei der Benutzername- und Passwort-Abfrage sind die Daten eines Benutzer-Accounts vom Server gefordert.
Die Einwahl wird zwar auch mit dem root-Login funktionieren, ist jedoch nicht die feine Art. Daher rate ich dazu, einen Benutzer hierfür anzulegen.

Funktionstest

Wenn die Einwahl ohne Fehler funktioniert hat, dann könnt ihr dies noch überprüfen, indem ihr die Webseite http://www.wieistmeineip.de/ besucht. Diese sollte euch nun die öffentliche IP-Adresse eures VPN-Servers anzeigen.

Bei mir hat dies (abgesehen von dem Ubuntu 8.04) mit folgenden Software-Ständen funktioniert:
Linux-Server: openvpn 2.0.9-4etch1
Linux-Client: OpenVPN 2.0.9 i686-pc-linux
Windows-Client: OpenVPN-Portable 2.1_rc7 Win32-MinGW

Ich hoffe, dass ich jemandem mit diesem Howto helfen konnte… und vor allem hoffe ich, dass Madd nun zufrieden ist ;-)

Gruß,
c

Quellenangabe:
Bei meinen Recherchen nach “wie mache ich sowas” bin ich vor geraumer Zeit auf die folgende Seite gestossen, die mir auch bei diesem Howto das Leben erleichtert hat:
http://nodomain.cc/archives/2007/06/30/740-Howto-Rootserver-als-OpenVPN-Gateway-nutzen.html

July 18, 2008

Public-Webserver und böser VSFTPd

Filed under: Linux, Ubuntu, VSFTPd — christian @ 23:21

Hi @ll,

ich habe mir gerade die Zeit genommen, mich mal endlich mal daran zu machen, meinen Public-Webserver als Xen-VM aufzusetzen.

Nach erstellung der Flat-Files und dem debootstrap eines Ubuntu 8.04 ging alles recht einfach von der Hand.
Damals hatte ich noch arge Probleme mit der richtigen Konfiguration eines Apache… doch wenn man es einmal gemacht hat, dann ist das recht einfach… auch ohne die alte (funktionierende) Config zu nehmen, sondern alles neu einzutragen…

Aber ich hatte erstmal das Gefühl, dass der VSFTPd mich nicht mag…

Wusstet ihr, was der alles kann?

Der ist anfürsich ein recht schlanker FTPd, doch wenn man die Optionen miteinander kombiniert, dann kommt man zu den wunderlichsten Ergebnissen.
Kleines Beispiel (Ziel: authentifizierte User sollen Dateien hochladen können):
write_enable=yes
local_enable=yes
funktioniert nicht
write_enable=YES
local_enable=YES
funktioniert nicht
write_enable=yes
local_enable=yes
funktioniert nicht
write_enable=YES
local_enable=YES
funktioniert doch!

Erklärung:
Zunächst mal der Wert der Variable…
yes!=YES
Linux ist nicht Windows und damit casesensitiv
Die Kombination der Variablen bzw. deren Folge ist ebenfalls nicht unwichtig.
Ich kann kein
write_enable
setzen, wenn
enable_local
nicht aktiv ist. Bedeutet: Erst die lokalen User zulassen, dann Schreibberechtigung vergeben… nicht umgekehrt…

Doch am Ende wurd’ alles gut :-D

Soviel von heute… mal sehen, wann ich Zeit finde, den SSHd fertig zu machen… denn dort ist mein Ziel eine “rbash” (restricted Bash), um die User im Home-Dir zu halten. Bislang sind alle meine Versuche gescheitert… aber aufgegeben habe ich noch nicht :-)

Gruß,
c

P.S.
Falls jemand die Konfiguration eines VSFTPd gebrauchen kann, der es lokalen Usern nach der authentifizierung erlaubt, Dateien aus dem Home-Directory herunter- oder in selbiges hochzuladen, jedoch keine Anonymous-Logins erlaubt, dem sei diese Config ans Herz gelegt:
#/etc/vsftpd.conf - c@7bf.de 2008-07-19
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
ftpd_banner=Welcome to blah FTP service.
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
Btw: Standonly-Mode, nix mit (x)inet……

Powered by WordPress