Ubunutu – Yanniks Bastel Ecke

TS3 Server automatisch aktualisieren (The default license has expired.)

Hallo,
mit diesem kleinen Blog Beitrag möchte ich euch zeigen, wie ihr einen Linux Teamspeak 3 Server automatisch aktualisieren könnt.

Die Aktualisierung ist notwendig, um eventuelle Fehler oder Sicherheitslücken zu beheben und um die Lizenz der Community Version von Teamspeak z.B. auf einem selbst betriebenem Server zu aktualisieren, da diese nach ein bzw. zwei Jahren ausläuft.

Wenn die Lizenz ausgelaufen ist bekommt man diese Fehlermeldung:

CRITICAL|Accounting | |The default license has expired. Please use the latest server version.

1	CRITICAL\|Accounting \| \|The default license has expired. Please use the latest server version.

Da mir die ständige manuelle Installation des Servers keine Freude bereitet, obwohl es sich nur um die folgenden 5 Schritte handelt:

#Herausfinden der aktuellsten Version, am besten im Browser in dieses Versionsdatei anschauen: https://www.teamspeak.com/versions/server.json
#Aktuell ist die aktuellste Version 3.13.7, daher 
VERSION="3.13.7" 
#Download der aktuellsten Version: 
wget https://files.teamspeak-services.com/releases/server/${VERSION}/teamspeak3-server_linux_amd64-${VERSION}.tar.bz2 
#Server stoppen 
./teamspeak3-server_linux_amd64/ts3server_startscript.sh stop 
#Entpacken 
tar -xjf teamspeak3-server_linux_amd64-${VERSION}.tar.bz2 
#Server starten 
./teamspeak3-server_linux_amd64/ts3server_startscript.sh start

#Herausfinden der aktuellsten Version, am besten im Browser in dieses Versionsdatei anschauen: https://www.teamspeak.com/versions/server.json

#Aktuell ist die aktuellste Version 3.13.7, daher

VERSION="3.13.7"

#Download der aktuellsten Version:

wget https://files.teamspeak-services.com/releases/server/${VERSION}/teamspeak3-server_linux_amd64-${VERSION}.tar.bz2

#Server stoppen

./teamspeak3-server_linux_amd64/ts3server_startscript.sh stop

#Entpacken

tar -xjf teamspeak3-server_linux_amd64-${VERSION}.tar.bz2

#Server starten

./teamspeak3-server_linux_amd64/ts3server_startscript.sh start

Habe ich ein Skript entwickelt und auf Github.com veröffentlicht, um dies in einen einzigen Schritt zusammenzufassen, den Vorgang deutlich zu vereinfachen und zu automatisieren:

https://github.com/yannik995/TS3-Update/

Mit folgendem Befehl lässt es sicher herunterladen und auch direkt ausführen, sodass der TS3 Server aktualisiert und neu gestartet wird (Ich empfehle immer vorher ein Backup des Servers anzulegen):

apt install jq -y && wget -Nnv https://raw.githubusercontent.com/yannik995/TS3-Update/main/ts3update.sh && chmod +x ts3update.sh; ./ts3update.sh

Zu beachten ist aber das sich der Teamspeak 3 Server im aktuellem Verzeichnis unter teamspeak3-server_linux_amd64 befinden muss, da das Skript sonst nicht funktioniert.

Damit das Update nicht immer manuell angestoßen werden muss habe ich bei mir einen Crontab eingerichtet, dazu startet man den Crontab Editor mit dem Befehl:

crontab -e

1	crontab -e

Und fügt dort folgendes ein, um es nach jedem Reboot auszuführen:

@reboot bash ts3update.sh

1	@reboot bash ts3update.sh

Oder am 2. des Monats um 04:35 Uhr, die Zeit kann natürlich frei geändert werden:

35 4 2 * * bash ts3update.sh

1	35 4 2 * * bash ts3update.sh

(Ggf. muss der Pfad zum Skript angepasst bzw. hinzugefügt werden. Bei mir liegt das Skript im Home Verzeichnis des TS3 Users und daher funktioniert es auch so ohne Probleme)

Ich hoffe ich konnte euch damit weiterhelfen und wünsche euch viel Spaß beim nutzen des Skripts.

Viele Grüße

Hetzner: No bootable Device nach Festplattentausch

Falls nach einem Festplattentausch der Bootloader nicht erneut geschrieben wurde, kommt es zu dem Problem, dass der Server nach einen Neustart nicht Rebooten wird und nur die Meldung No bootable Device anzeigt.

In diesem Artikel möchte ich erklären, wie man die Datenträger wieder bootfähig macht, da ich selber dachte der Schritt sei nicht notwendig, weil alle Daten durch das MDADM Raid 1 gespiegelt werden. Leider ist das nicht so.

Um die Datenträger wieder bootbar zu machen startet man das System in den Hetzner Rescue Modus und verbindet sich per SSH. Dies wirdauch hier erklärt:
https://docs.hetzner.com/de/robot/dedicated-server/troubleshooting/hetzner-rescue-system/

Dort bindet man die benötigten Laufwerke ein und wechselt per chroot von dem Rescue System in den Kontext des eigentlichen Systems. Die macht man mit folgenden Befehlen:

mount /dev/md2 /mnt                                 #Für Systeme mit MDADM
#bzw.
mount /dev/sda3 /mnt                                #Für Systeme ohne MDADM

chroot-prepare /mnt
#Falls der Befehl nicht funktionieren sollte
mount -t none -o bind /dev /mnt/dev
mount -t proc -o bind /proc /mnt/proc
mount -t sysfs -o bind /sys /mnt/sys

chroot /mnt
#Ab hier sind wir im Kontext des eigentlichen Systems
mount -a                                            #Mountet Boot/Swap Partition, wenn vorhanden

mount /dev/md2 /mnt #Für Systeme mit MDADM

#bzw.

mount /dev/sda3 /mnt #Für Systeme ohne MDADM

chroot-prepare /mnt

#Falls der Befehl nicht funktionieren sollte

mount -t none -o bind /dev /mnt/dev

mount -t proc -o bind /proc /mnt/proc

mount -t sysfs -o bind /sys /mnt/sys

chroot /mnt

#Ab hier sind wir im Kontext des eigentlichen Systems

mount -a #Mountet Boot/Swap Partition, wenn vorhanden

Nun befinden wir uns im Kontext unseres Systems und haben alle nötigen Partitionen gemounted, können also mit dem schrieben des Bootloaders beginnen:

grub-mkdevicemap -n
update-initramfs -u
grub-install /dev/sda
grub-install /dev/sdb
#usw. am besten auf alle Platten, von denen gebootet wird.

grub-mkdevicemap -n

update-initramfs -u

grub-install /dev/sda

grub-install /dev/sdb

#usw. am besten auf alle Platten, von denen gebootet wird.

Nun muss das System noch einmal neu gestartet werden und sollte dann wieder erfolgreich booten können:

shutdown -r now

1	shutdown -r now

Ich hoffe ich konnte auch mit diesem Beitrag helfen und wir werden ab jetzt nicht mehr vergessen den Bootloader nach dem Platten tausch neu zu schreiben.
Das geht einfach mit diesen zwei Befehlen und spart euch stressige Stunden 🙂 :

grub-mkdevicemap -n
grub-install /dev/sdb                                      #sdb durch getauschte Platte ersetzen

1 2	grub-mkdevicemap -n grub-install /dev/sdb #sdb durch getauschte Platte ersetzen

Nginx Fehler 413 Request Entity Too Large

Bei größeren Dateiuploads kann es vorkommen, das nginx die Fehlermeldung „413 Request Entity Too Large“ anzeigt und den Dateiupload abbricht. Diese Standard Einstellung gibt es, um den Webserver vor zu großen Dateien zu schützen und diese Fehlermeldung kann man ganz leicht beheben.

Dafür gibt es den Konfigurationsparameter „client_max_body_size“, wenn dieser nicht gesetzt ist, hat er den Wert 1m. Dadurch wird der Upload auf die maximale Größe von 1MB beschränkt.

http {
	server {
		client_max_body_size	1M;
		listen	80;
		server_name	localhost;
		location / {
			proxy_pass	http://127.0.0.1:8080/;
		}
	}
}

http {

server {

client_max_body_size 1M;

listen 80;

server_name localhost;

location / {

proxy_pass http://127.0.0.1:8080/;

}

Wie man hier in Zeile 3 sehen kann. Diesen Wert kann man nun auf eine entsprechende Größe anpassen oder auf 0 setzen, um das Limit ganz zu entfernen, dies ist allerdings nicht zu Empfehlen.

PHP Upload Limit anpassen

Eine ähnliche Einstellung gibt es auch in der php.ini, diese Datei findet man unter dem Pfad /etc/php/7.0/fpm/php.ini (7.0 ist durch die genutzte PHP Version zu ersetzen). In dieser Datei sucht man nach „upload_max_filesize“.

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 2M

; Maximum allowed size for uploaded files.

; http://php.net/upload-max-filesize

upload_max_filesize = 2M

Diesen Wert kann man nun ebenfalls auf die benötigte Größe einstellen.

Konfig Dateien neu laden

Nachdem man diese Änderungen vorgenommen hat, muss man die Konfigurationsdateien neu laden. Diese kann man mit diesen Befehlen erledigen:

sudo service nginx reload
sudo service php7.0-fpm reload

1 2	sudo service nginx reload sudo service php7.0-fpm reload

Und schon ist ein Upload von größeren Datei über nginx und PHP möglich.

Warum kommt dieser Fehler eigentlich?

Diese Konfiguration dient eurem Schutz, damit nich unendliche große Dateien an euren Server gesendet werden können und dieser dadurch lehmgelegt wird. Daher solltet ihr darauf achten diesen Wert auch nicht zu groß einzustellen.

Viele Spaß weiterhin bei der Nutzung von Nginx

Proxmox + pfSense: Kein Internet auf der VM

Ich habe mir einen Proxmox Server mit pfSense als Router VM und mehreren virtuellen Maschinen eingerichtet.
Nach einiger Netzwerkkonfiguration war es möglich auf der Router VM über den Port Check Verbindungen herzustellen und auch eine Windows VM konnte sich mit dem Internet Verbinden, allerdings sehr langsam.

Von allen VMs war es möglich ins Internet zu pingen, allerdings konnten von den Linux VMs keine TCP und UDP Verbindungen hergestellt werden. Verbindung wurde einseitig geöffnet, fand aber scheinbar keinen Weg zurück zur VM.

Nach einigem Googlen fand ich hier das es an dem Hardware Offloading liegen kann. Nachdem es deaktiviert wurde und die Router VM neu gestartet wurde, funktionierte ein apt update endlich 🙂

Wie deaktiviere ich Hardware Offloading in pfSense?

System -> Advanced -> Networking

Und folgende Punkte aktivieren:

Ethereum NVIDIA GPU Mining unter Ubuntu/Debian

Informationen zum Thema Mining und einer Anleitung unter Windows: Ethereum: Geld verdienen mit Gaming-PCs

Installation:

Füge die Ethereum-APT-Repository mit diesen Befehlen hinzu und installiere die benötigten Programme:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install ethminer
sudo apt-get install linux-headers-amd64 build-essential

sudo apt-get install software-properties-common

sudo add-apt-repository ppa:ethereum/ethereum

sudo apt-get update

sudo apt-get install ethminer

sudo apt-get install linux-headers-amd64 build-essential

Downloade Linux Treiber von hier: http://www.geforce.com/drivers/results/117741

Mache die Datei ausführbar und installiere den Treiber:

chmod +x NVIDIA-Linux-*.run
sudo NVIDIA-Linux-*.run

1 2	chmod +x NVIDIA-Linux-.run sudo NVIDIA-Linux-.run

Starte den Miner mit folgendem Befehl:

ethminer -G -F http://eth-eu.dwarfpool.com/0x544ff6894b221ff81c272aff0c3f1b6c81e51988/Miner --farm-recheck 200

1	ethminer -G -F http://eth-eu.dwarfpool.com/0x544ff6894b221ff81c272aff0c3f1b6c81e51988/Miner --farm-recheck 200

Wobei die Adresse durch die eigene Ethereum Adresse zu ersetzen ist und Miner durch einen beliebigen Name ausgetauscht werden kann, um die Übersicht über verschiedene Miner zu behalten.

Wenn ihr die Adresse nicht ersetzt gehen die Ethereum Gewinne an mich, worüber ich mich natürlich freuen würde 🙂

Den Status im Pool könnt ihr hier Prüfen: http://dwarfpool.com/eth/address?wallet=0xEureEthereumAdresse&allpayouts=1

Woher bekomme ich eine eigene Ethereum Adresse?

Z.b. bei Kraken.com einen online Marktplatz zum Handeln verschiedener Krypto-Währungen. Dort kann man des Ethereum auch direkt in Euro umwandeln.

oder man installiert sich die Ethereum Wallet lokal und hat sein Geld auf dem lokalen PC: https://www.ethereum.org/ Download: https://github.com/ethereum/mist/releases

Mittlerweile lohnt sich das Mining nur, wenn ihr sehr sehr kosten günstig an Strom kommt. Daher empfehle ich statt in Mining doch lieber in Aktien zu investieren, das ist meiner Meinung nach mittlerweile deutlich attraktiver 🙂
Aber ich hoffe ihr fandet die Anleitung trotzdem interessant.

RRDtool: Daten zwischen verschiedenen Architekturen bewegen

Wenn man das RRDTool (z.B. in Munin) auf Serverm mit verschiedenen Architekturen nutzt, dann hat man sicher schon mal diese Meldung erhalten:

ERROR: This RRD was created on another architecture

1	ERROR: This RRD was created on another architecture

Das Problem kann man lösen, indem man ein Dump der RRD Dateien erstellt:

rrdtool dump stats.rrd > stats.xml

1	rrdtool dump stats.rrd > stats.xml

Und sie auf dem Ziel System wieder einliest:

rrdtool restore -f stats.xml stats.rrd

1	rrdtool restore -f stats.xml stats.rrd

Der andere Server kann die Datei nun lesen, testen kann man es mit:

rrdtool info stats.rrd

1	rrdtool info stats.rrd

Wenn man so einen ganzen Ordner verarbeiten möchte geht es so:

##Server 1
cd /var/lib/munin/ext-rdp2
#Dump RRD Files
for f in *.rrd; do rrdtool dump ${f} > ${f}.xml; done
#Alte Dateien löschen(Das umbenenen schlägt sonst fehl)
rm *.rrd

##Server 2
#Dateien Syncen z.B.:
rsync -avze ssh root@192.168.1.2:/var/lib/munin/ /var/lib/munin/

#Restore durchführen
for f in *.xml; do rrdtool restore -f ${f} ${f}.rrd; done
# .rrd.xml.rrd in .rrd.xml
for FILENAME in *.rrd; do mv "$FILENAME" "${FILENAME%.rrd}"; done
# .rrd.xml in .rrd
for FILENAME in *.xml; do mv "$FILENAME" "${FILENAME%.xml}"; done

##Server 1

cd /var/lib/munin/ext-rdp2

#Dump RRD Files

for f in *.rrd; do rrdtool dump ${f} > ${f}.xml; done

#Alte Dateien löschen(Das umbenenen schlägt sonst fehl)

rm *.rrd

##Server 2

#Dateien Syncen z.B.:

rsync -avze ssh root@192.168.1.2:/var/lib/munin/ /var/lib/munin/

#Restore durchführen

for f in *.xml; do rrdtool restore -f ${f} ${f}.rrd; done

# .rrd.xml.rrd in .rrd.xml

for FILENAME in *.rrd; do mv "$FILENAME" "${FILENAME%.rrd}"; done

# .rrd.xml in .rrd

for FILENAME in *.xml; do mv "$FILENAME" "${FILENAME%.xml}"; done

Ich hoffe es hilft jemanden.

Nginx 1.10.3 auf Ubuntu installieren

Vor kurzem wurde Nginx 1.9.1 (auch die neueren Versionen) veröffentlicht über die Paketverwaltung kann man diese Version allerdings noch nicht herunterladen, darum erkläre ich weiter unter wie es möglich ist.

Nginx ist im Vergleich zu Apache ein sehr schneller Webserver, welcher auch etwas anders aus Apache funktioniert und daher viele andere Vorteile bringt.

In der Version 1.9.1 bietet Nginx folgendes neues:

SSLv3 wird standardmäßig deaktiviert
einige lange veraltet Richtlinien werden nicht mehr unterstützt
der Parameter „reuseport“ wurde hinzugefügt
Fixes, für Nginx, die ausfallen könnten, um auf einige alte Linux-Varianten zu
Das Stream Modul wurde hinzugefügt um TCP Verbindungen zu verwalten
Und einige Buxfixes

Um Nginx auf Ubuntu zu installieren benötigt man zunächst Nginxs Signing Key:

cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key

1	cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key

Diesen binden wir dann in unser System ein:

sudo apt-key add nginx_signing.key

1	sudo apt-key add nginx_signing.key

Danach müssen wir noch die Nginx’s repository hinzufügen, dazu öffnen wir ein neues Dokument:

sudo nano /etc/apt/sources.list.d/nginx.list

1	sudo nano /etc/apt/sources.list.d/nginx.list

Und fügen dort folgendes ein:

deb http://nginx.org/packages/mainline/ubuntu/ codename nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ codename nginx

1 2	deb http://nginx.org/packages/mainline/ubuntu/ codename nginx deb-src http://nginx.org/packages/mainline/ubuntu/ codename nginx

„codename“ muss mit dem Namen eures Ubunuts ersetzt werden und kann über

lsb_release -c

1	lsb_release -c

abgefragt werden.

(Ubunut 14.04 LTS ist bekannt als Trusty, eine Liste gibt es hier: https://wiki.ubuntu.com/DevelopmentCodeNames , der Name darf dabei nur Kleinbuchstaben beinhalten.)

Wenn Nginx bereits installiert ist, empfiehlt es sich Nginx und alle dazugehörigen Pakete zunächst zu deinstallieren:

sudo apt-get remove nginx nginx-*

1	sudo apt-get remove nginx nginx-*

Nun können wir Nginx 1.9.1 endlich installieren:

sudo apt-get update && sudo apt-get install nginx

1	sudo apt-get update && sudo apt-get install nginx

Das war es nun um Nginx auf Ubuntu zu installieren.
Viel Spaß dabei.