Wenn man bei OpenVPN, bzw. genauer gesagt dem OpenVPN-GUI nach dem Verbinden ein script ausführt, das manchmal etwas länger dauert, bekomme man die Fehlermeldung:
openvpn connect script failed. ( exit code =1) |
oder auch:
Connect script failed. Timeout after 15 secs |
Dieses Timeout kann man in der Registry hoch setzen. Dazu einfach im Schlüssel: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\OpenVPN-GUI den Wert: connectscript_timeout vom Standard 15 entsprechend setzen, z.B.: auf 60.
Um sich bei einem Linux Server über das Actice Directory authentifizieren (anmelden) zu können gibt es mehrere Möglichkeiten.
Die populärsten sind kerbereos und winbind.
Hier wird erklärt, wie man sich mit winbind über ein AD-Login bei einem Linux Server anmelden kann:
[stextbox id=“warning“ caption=“Achtung“]Damit das Active Directry login funktioniert, MUSS die Ausgabe von
hostname --fqdn |
zwingend genau dem Domänen Namen der Windows Domäne entsprechen!
Das heisst, wenn das Clients im Active Directoy die Domäne: client.example.net haben, das Server Netz aber die Domäne: my-server.linux.example.net, wird das nicht funktionieren. Die Server, müssen dann auch den Hostnamen (fqdn) my-server.example.net haben!
Sollte der Server nicht bereits im DNS so eingetragen sein, muss der Eintrag in /etc/hosts erfolgen:
192.168.1.30 my-server.example.net my-server |
[/stextbox]
Erstmal installieren wir die benötigten Komponenten:
yum install krb5-workstation pam_krb5 samba-winbind samba-winbind-clients |
Nun müssen in der Datei /etc/resolv.conf die DNS-Server der Domaincontroller- und die Domain eingetragen werden:
nameserver 192.168.1.10 nameserver 192.168.1.20 search ad.example.net |
Als nächstes kommt die Kerberos Konfiguration:
/etc/krb5.conf
[libdefaults]
default_realm = AD.EXAMPLE.NET
dns_lookup_realm = false
dns_lookup_kdc = true |
Danach noch die samba Konfiguration in /etc/samba/smb.conf anpassen, bzw. mit den folgenden Werten ergänzen:
[global] workgroup = AD realm = AD.EXAMPLE.NET security = ADS winbind enum users = yes winbind enum groups = yes winbind use default domain = no winbind refresh tickets = yes template shell = /bin/bash idmap config * : range = 10000 - 19999 idmap config AD : backend = rid idmap config AD : range = 1000000 - 1999999 |
[stextbox id=“note“ caption=“Hinweis“]Obwohl wir die smb.conf geändert haben, muss sama (smb/nmb) NICHT gestartet werden.
Die smb.conf wird in diesem Falle nur vom winbind daemon gebraucht.[/stextbox]
Nun muss noch die Datei /etc/nsswitch.conf angepasst werden damit auf dem Server die AD Benutzer und Gruppen benutzt werden können.
Bei den zwei Einträgen „passwd“ und „group“ muss einfach noch „winbind“ angefügt werden:
passwd: files winbind group: files winbind |
Jetzt noch winbind als Autostart Konfigurieren:
systemctl enable winbind |
Nun können wir der Domäne beitreten:
net ads join -Uadministrator |
Und testen:
[root@my-server ~]# net ads testjoin Join is OK |
Danach winbind neu starten:
systemctl restart winbind |
Und testen:
wbinfo -u wbinfo -g getent passwd 'AD\administrator' |
Nun geben wir den Leuten in der Gruppe Linux-Admin noch eine sudo-Berechtigung:
echo "%linux-admins ALL=(ALL) ALL" >> /etc/sudoers.d/ad |
[stextbox id=“tip“ caption=“Gruppen mit Leerzeichen“]Haben hier AD Gruppen Leerzeichen (z.B. "Domain Admins"), so lässt sich dies konfigurieren, indem man die Leerzeichen escaped:
visudo -f /etc/sudoers.d/ad |
User_Alias MYADMINS=%AD\\Domain\ Admins MYADMINS ALL=(ALL) NOPASSWD: ALL |
[/stextbox]
Um SSH login zu ermöglichen muss die Datei: /etc/pam.d/password-auth-ac mit den folgenden Einträgen ergänz werden:
Das ganze sieht dann so aus:
#%PAM-1.0 auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_winbind.so account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so umask=0077 -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so |
Mehrere Gruppen lassen sich mit den folgenden Änderungen zuweisen:
File erstellen, indem alle erlaubten Gruppen sind
/etc/login.group.allowed
root AD\linux-admins |
[stextbox id=“note“ caption=“Einschränkungen“]Es gibt allerdings die Einschränkung dass AD Gruppen keine Leerzeichen (spaces) haben dürfen.
Hat man nur Gruppen mit Leerzeichen (z.B. "Domain Admins"), dann muss man lokale Gruppen machen und die entsprechenden Leute manuell in diese Aufnehmen.[/stextbox]
Nun wird ein home Verzeichnis fürs ActiveDirectoy erstellt, um die Übersicht über lokale- und AD Logins zu behalten:
mkdir -v /home/AD |
Nun kann das gnaze getestet werden:
tail -f /var/log/secure |
$ ssh AD\\hmuster@my-server AD\hmuster@my-server's password: Creating directory '/home/AD/hmuster'. [AD\hmuster@my-server ~]$ |
Möchte man in der bash eine unlimitierte Shell-History anlegen, reicht es, z.B. in /etc/profile die Variable HISTFILESIZE auf leer zu setzen.
Damit werden eingegebene Befehle in der Shell nie überschrieben und mit der Variable HISTSIZE kann man dann noch die Anzahl Befehle definieren, die jeweils in den Puffer geschrieben werden:
export HISTFILESIZE="" export HISTSIZE=10000 |
Wenn beim apache Webserver Text oder HTML Dateien mit falschen Umlauten angezeigt werden, liegt dies meist an den Zeichensatz Einstellungen.
Mittels der [http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset|AddDefaultCharset]-Direktive kann ein Zeichensatz angegeben werden, der für alle Dateien gilt; dieser verändert jedoch die Standard-Einstellung des Browsers und führt so manchmal zu verkorksten Umlauten. Deshalb sollte diese Einstellung Standardmässig auf "Off" sein.
Bei RHEL/CentOS ist diese in der Standardeinstellung jedoch auf UTF-8, wahrscheinlich um Kompatibilität mit alten Scripts wo der Zeichensatz nicht definiert ist zu wahren.
Ist dies so, sollte die Einstellung in der httpd.conf erstmal auf "Off" gestellt werden.
Werden die Umlaute immer noch nicht korrekt dargestellt, kann man auf Verzeichnisebene (über .htaccess files) mit der Direktive "AddDefaultCharset" experimentieren.
Ebenfalls kann man mit der [http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset|AddCharset]-Direktive dies für einzelne Dateitypen (z.B. .txt) Einstellen.
[stextbox id=“tip“ caption=“Tip: httpd.conf Einstellungen überschreiben“]In der Zentralen httpd.conf des apache Webservers sollte so wenig wie möglich verändert werden um spätere upgrades nicht kompliziert zu machen.
Deshalb legt man am besten eine weitere Datei mit dem Namen: httpd-override.conf an und bindet diese mit der Include-Direktive am Schluss der httpd.conf ein:
Include conf/httpd-override.conf |
Darin kann man dann die Standard-Einstellungen jeweils „überschreiben“.[/stextbox]
Quellen:
Heutzutage sind viele Systeme auf den universellen Zeichensatz UTF-8 eingestellt, so auch Linux.
Wenn man sich nun aber über putty mit SSH verbindet, wird man feststellen, dass die Umlaute, z.B. nei vi/vim oder ls nicht richtig dargestellt werden.
Schuld ist hier eine Einstellung in putty, die noch auf ISO-8859-1 eingestellt ist.
Ändern kann man dies in den putty Einstellungen über change settings -> Translation, wo der Zeichensatz auf UTF-8 umgestellt werden sollte.
Am besten macht man dies gleich auch für den "Default Settings" Eintrag, so dass neue hinzugefügte hosts automatisch diese Einstellung benutzen.
Die Partition der /boot Festplatte wird häufig relativ klein gemacht, häufig auch etwas "zu"-klein, denn neuere Linux Distributionen brauchen für die Kernel-History gerne mal über 200MB.
Doch was tun, wenn die /boot Partition zu klein wird? – Neue erstellen und das boot Laufwerk verschieben!
Hier wird beschrieben wies geht.
Wir gehen her davon aus, dass:
/dev/sda1 die alte und
/dev/sdb1 die neue Platte/Partition ist.
Die neue boot Partition sollte ausserdem bereits mit fdisk/cfdisk formatiert und mit dem "bootable" flag markiert sein.
Zur Sicherheit ändern wir erst nur das label der alten boot Platte (/boot wird in fstab meist nach label gemountet) und passen den fstab Eintrag ggf. an.
Erst wenn die neue Partition in Betrieb ist, kann die alte gelöscht werden:
tune2fs -L/oldboot /dev/sda1 # ggf. Eintrag in /etc/fstab anpassen |
Nun erstellen wir das filesystem der neuen Partition:
mke2fs -j -L /boot /dev/sdb1 |
Als nächstes werden die beiden Partition gemountet und synchronisiert:
umount /boot
mkdir -pv /mnt/{sda1,sdb1}
mount /dev/sda1 /mnt/sda1
mount /dev/sdb1 /mnt/sdb1
rsync -ahv --numeric-ids --delete /mnt/sda1/ /mnt/sdb1/ |
Zum Schluss muss man noch mittels grub den boot Sektor auf die neue Disk schreiben:
grub grub> device (hd1) /dev/sdb device (hd1) /dev/sdb grub> root (hd1,0) root (hd1,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd1) setup (hd1) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd1)"... 15 sectors are embedded. succeeded Running "install /grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/grub/stage2 /grub/grub.conf"... succeeded Done. grub> quit |
Nach einem Reboot sollte die neue boot Partition aktiv sein!
Es ist zwar durchaus möglich mit der "alt bewährten Methode" $1-$9 in shell scripts Kommandozeilen zu machen, allerdings ist das eher umständlich.
Mit der Funktion "getopts" hat jedoch zumindest die bash-shell ein sehr handliches Werzeug dafür eingebaut!
Dabei sieht die synatx so aus:
getopts Optionen Variable [Argumente] |
Dabei werden alle Optionen die man Abfragen will mit einem ":" davor und dahinter hingeschrieben, z.B.:
getopts :a: |
Möchte man schalter/flags verwenden, die keinen Wert haben, lässt man eingach den ":" hinter der Option weg:
getopts :a |
Und ein praktisches Beispiel:
#!/bin/bash
# Demonstriert getopt
while getopts abc:D: opt
do
case $opt in
a) echo "Option a";;
b) echo "Option b";;
c) echo "Option c : ($OPTARG)";;
D) echo "Option D : ($OPTARG)";;
esac
done |
Und so wird das dann aufgerufen:
user@host > ./test.sh -a Option a user@host > ./test.sh -b Option b user@host > ./test.sh -c ./agetopter: option requires an argument -- c user@host > ./test.sh -c Hallo Option c : (Hallo) |
Bei putty würde man gerne diverse settings ändern und standardmässig für alle neuen Instanzen benutzen.
Dazu ändert man einfach den Host "Default Settings" und speichert diesen!
In gewissen Situation muss man ein system mit einem hängenden Prozess neu starten, weiss aber, dass es mit dem normalen "reboot" Kommando beim herunterfahren hängen bleiben wird. Dies passiert z.B. besonders häufig bei Filesystem-Prozessen, die vom Kernel ausgeführt werden und sich somit nicht "killen" lassen, wie copy, rsync, nfs, usw.
Somit hilft dann nur noch der "Hard Reset", bei dem man jedoch physischen Zugang zum Server haben muss.
Hat man diesen gerade nicht gibt es noch eine andere Möglichkeit, das System sofort neu zu starten, ohne durch den Prozess des "herunterfahrens" zu gehen: Über das in den Linux-Kernel integrierte sysrq-Interface.
Dies schaltet man zuerst mittels:
echo s > /proc/sysrq-trigger |
an und löst dann den "brutalen" reset über:
echo b > /proc/sysrq-trigger |
aus.
c’t: [http://www.heise.de/ct/hotline/Gewaltsamer-Reset-unter-Linux-321064.html|Gewaltsamer Reset unter Linux]
In einem VMware ESX System kann man auch ein ESX innerhalb einer VM ertsellen, was zum testen sehr gut sein kann. 😉
Man wird aber merken, dass die VMs in der "nested VM", keine Netzwerk-Verbindung haben.
Dieses kommt daher, weil beim ESX Standardmässig der sog. "Promiscuous Mode" beim vSwitch nicht aktiviert ist.
Am besten legt man deshalb ein neues Netzwerk (Portgruppe oder vSwitch) an aktiviert dort den Promiscuous Mode und Verbindet das Netzwerk mit der "ESX VM".
Weitere Informationen dazu in der vcritical.com: [http://www.vcritical.com/2011/07/vmware-vsphere-can-virtualize-itself/|VMware vSphere can virtualize itself + 64-bit nested guests]
