Open Source

TUXEDO InfinityBook Pro 13 – Teil 3

Nachdem ich Ubuntu und Windows auf dem TUXEDO InfinityBook Pro 13 getestet habe, wollte ich wissen, wie sich das frisch veröffentlichte Debian 9 Stretch auf diesem Gerät schlägt. Hatte man bei der Installation von Debian 8 noch arge Installationsprobleme mit dem Kernel 3.16, so verlief das EFI-Setup mit Stretch problemlos. Die Funktionstastenbelegung funktioniert nach dem Setup fast komplett. Der Flugmodus über die Taste F11 lässt sich mit einem kleinen Eingriff in die Konfiguration des Grub aktivieren. Die verbaute Hardware wird vollständig erkannt. Um allerdings das WLAN-Modul zu aktivieren, ist es nötig den unfreien Intel-Treiber iwlwifi (non-free) einzuspielen. Dieses Problem trat schon beim Vorgängermodell auf. Da das Pro 13 über eine LAN-Schnittstelle verfügt, kann das Paket aber problemlos aus den Quellen contrib non-free installiert werden. Die Webcam sowie der Card-Reader funktionierten auf Anhieb und die Grafik läuft einwandfrei.

Debian 9 Stretch Übersicht (GNOME-Version 3.22)

Debian 9 verrichtet ansonsten seinen Dienst erwartungsgemäß stabil und zuverlässig. Das System startet einen Tick schneller als unter Ubuntu, in knapp 16 Sekunden. Allerdings muss man bei der Performance der Akkulaufzeit ein paar Abstriche machen. Nach 7:30h im üblichen Standby-Test geht dem Gerät die Puste aus. Allerdings kam ich beim Arbeiten mit dem InfinityBook auf eine ähnliche Laufleistung wie unter Ubuntu. Das Notebook quittierte seinen Dienst nach 5:10h. Verantwortlich hierfür ist der, wie unter der LTS, eingesetzte Kernel 4.9. Später sollte eine deutliche Verbesserung spürbar sein, wenn neuere Kernel über die Backports frei gegeben und auch eingespielt werden. Die CPU-Temperatur liegt im Normalbetrieb bei ca. 46°C. Dabei ist der Lüfter nicht zu hören.

Natürlich habe ich auch wieder etwas „Duke Nukem 3D: Megaton Edition“ via Steam gezockt, um die CPU etwas an die Grenzen zu führen. Die Temperatur stieg in den Spitzen auf maximal 100°C. Der Lüfter machte dann natürlich ordentlich Geräusche. Das InfinityBook ist eben kein Gaming Notebook, sondern richtet sich eher an Entwickler, Reisende, Normalanwender, aber auch Blogger.

Fazit

Das TUXEDO InfinityBook Pro 13 kam im Test mit Debian 9 Stretch gut zurecht. Es wurden im Test mit dem Gerät normale Aufgaben mit LibreOffice, Gimp, Inkscape, Firefox etc. erledigt. Selbst nicht so anspruchsvolle Spiele laufen auf dem InfinityBook gut. Allerdings wirkt hier der Lüfter störend.

Die Akkulaufleistung ist mit Debian 9 vergleichbar wie unter Ubuntu 16.04 LTS. Mit dem Kernel 4.9 kommt dabei die getestete Linux-Distribution auch hier nicht ansatzweise an ein Windows heran. Die Problematik ist bekannt. Jedoch besteht im Hinblick auf neuere und aktuellere Kernel etwas Hoffnung.

Alles in Allem kann man aber sehr gut auf dem InfinityBook mit Debian 9 stable arbeiten. Das TUXEDO InfinityBook Pro 13 ist also auch für eingefleischte Debianer einen Blick wert. Wobei man beim WLAN-Modul zu einem unfreien Treiber greifen muss.

Vorschau

Im nächsten Artikel werde ich berichten, wie das TUXEDO InfinityBook Pro 13 von innen aussieht und wie es um die Erweiterbarkeit bestellt ist.

MySQL- Sicherung ohne Passwort im Script

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel „MySQL-Sicherung“ in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

crontab -e

1	crontab -e

folgenden Befehl eingetragen.

0 2 * * * /home/user/MySQLscript.sh

1	0 2 * * * /home/user/MySQLscript.sh

Dann wurde eine ~/.my.cnf

nano ~/.my.cnf

1	nano ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

[client]
user=root
password=meinpasswort

[client]

user=root

password=meinpasswort

„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

chmod 600 ~/.my.cnf

1	chmod 600 ~/.my.cnf

Im Anschluss habe ich ein neues Script mit dem Inhalt

#!/bin/sh
mysqldump in********** | gzip > /samba_share/backup/in**********/in**********-$(date +%Y-%m-%d).sql.gz
mysqldump cc********** | gzip > /samba_share/backup/cc**********/cc**********-$(date +%Y-%m-%d).sql.gz
mysqldump bc********** | gzip > /samba_share/backup/bc**********/bc**********-$(date +%Y-%m-%d).sql.gz
mysqldump kt********** | gzip > /samba_share/backup/kt**********/kt**********-$(date +%Y-%m-%d).sql.gz
mysqldump wo********** | gzip > /samba_share/backup/wo**********/wo**********-$(date +%Y-%m-%d).sql.gz
mysqldump ne********** | gzip > /samba_share/backup/ne**********/ne**********-$(date +%Y-%m-%d).sql.gz
mysqldump cy********** | gzip > /samba_share/backup/cy**********/cy**********-$(date +%Y-%m-%d).sql.gz
mysqldump pe********** | gzip > /samba_share/backup/pe**********/pe**********-$(date +%Y-%m-%d).sql.gz
mysqldump ma********** | gzip > /samba_share/backup/ma**********/ma**********-$(date +%Y-%m-%d).sql.gz
mysqldump pr********** | gzip > /samba_share/backup/pr**********/pr**********-$(date +%Y-%m-%d).sql.gz
mysqldump ro********** | gzip > /samba_share/backup/ro**********/ro**********-$(date +%Y-%m-%d).sql.gz
mysqldump bcc********* | gzip > /samba_share/backup/bcc*********/bcc*********-$(date +%Y-%m-%d).sql.gz
mysqldump pi********** | gzip > /samba_share/backup/pi**********/pi**********-$(date +%Y-%m-%d).sql.gz

#!/bin/sh

mysqldump in********** | gzip > /samba_share/backup/in**********/in**********-$(date +%Y-%m-%d).sql.gz

mysqldump cc********** | gzip > /samba_share/backup/cc**********/cc**********-$(date +%Y-%m-%d).sql.gz

mysqldump bc********** | gzip > /samba_share/backup/bc**********/bc**********-$(date +%Y-%m-%d).sql.gz

mysqldump kt********** | gzip > /samba_share/backup/kt**********/kt**********-$(date +%Y-%m-%d).sql.gz

mysqldump wo********** | gzip > /samba_share/backup/wo**********/wo**********-$(date +%Y-%m-%d).sql.gz

mysqldump ne********** | gzip > /samba_share/backup/ne**********/ne**********-$(date +%Y-%m-%d).sql.gz

mysqldump cy********** | gzip > /samba_share/backup/cy**********/cy**********-$(date +%Y-%m-%d).sql.gz

mysqldump pe********** | gzip > /samba_share/backup/pe**********/pe**********-$(date +%Y-%m-%d).sql.gz

mysqldump ma********** | gzip > /samba_share/backup/ma**********/ma**********-$(date +%Y-%m-%d).sql.gz

mysqldump pr********** | gzip > /samba_share/backup/pr**********/pr**********-$(date +%Y-%m-%d).sql.gz

mysqldump ro********** | gzip > /samba_share/backup/ro**********/ro**********-$(date +%Y-%m-%d).sql.gz

mysqldump bcc********* | gzip > /samba_share/backup/bcc*********/bcc*********-$(date +%Y-%m-%d).sql.gz

mysqldump pi********** | gzip > /samba_share/backup/pi**********/pi**********-$(date +%Y-%m-%d).sql.gz

erstellt und dieses mit

chmod +x ~/MySQLscript.sh

1	chmod +x ~/MySQLscript.sh

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

cd /samba_share/backup

1	cd /samba_share/backup

mkdir in********** cc********** bc********** kt********** wo********** ne********** cy********** pe********** ma********** pr********** ro********** bcc********* pi**********

1	mkdir in******** cc****** bc****** kt****** wo****** ne****** cy****** pe****** ma****** pr****** ro****** bcc***** pi********

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App „External Storage“ in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.

MySQL-Sicherung

Inspiriert durch den Artikel „Backup oder Datensicherung eines root-Servers / vServers / VPS„von Bitblokes habe ich mir Gedanken gemacht, wie ich meine MySQL-Datenbanken vernünftig und regelmäßig sichern kann. Die Snapshots von Servercow sind schon sehr gut, um ein Backup des ganzen Servers zu erstellen. Jedoch ist man hin und wieder auf eine einzelne Datenbank angewiesen.

Da ich bei Servercow einen zusätzlichen RAID5 HDD-Netzwerkspeicher von 150 GB und diesen in meine Nextcloud eingebunden habe, kann ich dort bequem meine Datenbanksicherungen ablegen. Bei jeder Synchronisation zu Hause, landen dann die Sicherungen auf meinem Notebook.

Da ich bisher meine Datenbanken manuell mit mysqldump durchgeführt habe, wollte ich das Ganze nun automatisieren.

Dazu wurde das Script MySQLscript.sh

# nano /root/MySQLscript.sh

1	# nano /root/MySQLscript.sh

mit folgendem Inhalt erstellt.

#!/bin/sh
mysqldump -u root -pmeinpasswort in********** > /samba_share/backup/in**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort cc********** > /samba_share/backup/cc**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort bc********** > /samba_share/backup/bc**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort kt********** > /samba_share/backup/kt**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort wo********** > /samba_share/backup/wo**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ne********** > /samba_share/backup/ne**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort cy********** > /samba_share/backup/cy**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pe********** > /samba_share/backup/pe**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ma********** > /samba_share/backup/ma**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pr********** > /samba_share/backup/pr**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ro********** > /samba_share/backup/ro**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort bcc********* > /samba_share/backup/bcc*********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pi********** > /samba_share/backup/pi**********-$(date +%Y-%m-%d).sql

#!/bin/sh

mysqldump -u root -pmeinpasswort in********** > /samba_share/backup/in**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort cc********** > /samba_share/backup/cc**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort bc********** > /samba_share/backup/bc**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort kt********** > /samba_share/backup/kt**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort wo********** > /samba_share/backup/wo**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ne********** > /samba_share/backup/ne**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort cy********** > /samba_share/backup/cy**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pe********** > /samba_share/backup/pe**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ma********** > /samba_share/backup/ma**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pr********** > /samba_share/backup/pr**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ro********** > /samba_share/backup/ro**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort bcc********* > /samba_share/backup/bcc*********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pi********** > /samba_share/backup/pi**********-$(date +%Y-%m-%d).sql

Dabei ist „in**********“ der Name meiner ersten Datenbank. Der Eintrag „meinpasswort“ im Script muss natürlich durch das MySQL root Passwort ersetzt werden.

Im Anschluss wird das Script ausführbar gemacht

# chmod +x MySQLscript.sh

1	# chmod +x MySQLscript.sh

und der Befehl mit

# nano /etc/crontab

1	# nano /etc/crontab

in den crontab eingetragen.

0 2 * * *       root    /root/MySQLscript.sh

1	0 2 * * * root /root/MySQLscript.sh

So wird nach dem Neustart von Cron jeden Tag um 2:00 Uhr eine Sicherung jeder einzelnen Datenbank im Verzeichnis /samba_share/backup abgelegt.

# /etc/init.d/cron restart

1	# /etc/init.d/cron restart

Upgrade auf Roundcube 1.3.0

Gestern wurde Roundcube in Version 1.3.0 released. Ich habe das Upgrade heute gleich auf meinem vServer angestoßen. Dazu wurde der Download von Roundcube 1.3.0 in /var/www/html abgelegt.

# cd /var/www/html

1	# cd /var/www/html

# wget https://github.com/roundcube/roundcubemail/releases/download/1.3.0/roundcubemail-1.3.0-complete.tar.gz

1	# wget https://github.com/roundcube/roundcubemail/releases/download/1.3.0/roundcubemail-1.3.0-complete.tar.gz

Der Tarball wurde entpackt,

# tar xfz *.tar.gz

1	# tar xfz *.tar.gz

das neue Verzeichnis betreten

# cd roundcubemail-1.3.0

1	# cd roundcubemail-1.3.0

und das Upgrade ausgeführt. Der Pfad muss hierbei entsprechend angepasst werden. Da meine Roundcube-Installation in /var/www/mail/rc liegt, sieht die Eingabe wie folgt aus:

# ./bin/installto.sh /var/www/mail/rc

1	# ./bin/installto.sh /var/www/mail/rc

Das Upgrade verlief ohne Probleme. Zum Schluss konnten das temporäre Upgrade-Verzeichnis und der Download gelöscht werden.

# cd ..

# cd ..

# rm -r roundcubemail-1.3.0

1	# rm -r roundcubemail-1.3.0

# rm *.tar.gz

1	# rm *.tar.gz

PHP 7

Ich habe mal schnell meinen vServer auf PHP 7 geswitcht. Nun besteht keine Eile sofort auf Debian 9 Stretch zu springen.

Google Earth 7 unter Stretch

Vor einiger Zeit war es kaum noch möglich auf Debian 8 Google Earth zu installieren, geschweige denn vernünftig zu starten. Mittlerweile kann man Google Earth im Browser ausführen, was eine Installation obsolet macht. Jedoch habe ich nun unter Debian 9 Stretch festgestellt, dass sich die letzte Version 7.1 64-Bit problemlos installieren lässt.

Dazu läd man die 64-Bit-Variante für Debian/Ubuntu hier herunter: https://www.google.com/intl/de/earth/download/ge/agree.html

Dann steigt man in das entsprechende Download-Verzeichnis ab und installiert das Paket mit

# dpkg -i google-earth*

1	# dpkg -i google-earth*

und führt

# apt-get -f install

1	# apt-get -f install

aus. Da sich beim ersten Start Orte nicht anfliegen lassen. Ersetzt man im Starter den Befehl zum Ausführen

/opt/google/earth/free/google-earth %f

1	/opt/google/earth/free/google-earth %f

durch

env LC_NUMERIC=en_US.UTF8 google-earth

1	env LC_NUMERIC=en_US.UTF8 google-earth

Viel Spaß!

Nextcloud-Client für Debian 9

Endlich gibt es eine Quelle für den Nextcloud-Client für Debian. Hier kurz die Vorgehensweise für Stretch.

<span class="pl-c1"># echo</span> <span class="pl-s"><span class="pl-pds">'</span>deb http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/ /<span class="pl-pds">'</span></span> <span class="pl-k">&gt;</span> /etc/apt/sources.list.d/nextcloud-client.list

1	<span class="pl-c1"># echo</span> <span class="pl-s"><span class="pl-pds">'</span>deb http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/ /<span class="pl-pds">'</span></span> <span class="pl-k">></span> /etc/apt/sources.list.d/nextcloud-client.list

# wget http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/Release.key

1	# wget http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/Release.key

# apt-key add - &lt; Release.key

1	# apt-key add - < Release.key

# apt update

1	# apt update

# apt install nextcloud-client

1	# apt install nextcloud-client

Mehr Infos unter: https://github.com/nextcloud/client_theming

Viel Spaß!

Stretch auf dem ThinkPad E550

Nun sind es ja nur noch zwei Wochen bis Debian 9 offiziell released wird. Was soll da noch schief gehen?

Aus diesem Grund habe ich schon mal das Upgrade auf Stretch angestoßen.

Zuerst wurden meine Einträge in der /etc/apt/sources.list angepasst. Dabei wurde jeweils jessie durch stretch ersetzt.

nano /etc/apt/sources.list

1	nano /etc/apt/sources.list

# deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 NETINST Binary-1 20160402-14:42]/ jessie main

#deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 NETINST Binary-1 20160402-14:42]/ jessie main

deb http://ftp.de.debian.org/debian/ stretch main
deb-src http://ftp.de.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

# jessie-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ stretch-updates main
deb-src http://ftp.de.debian.org/debian/ stretch-updates main

# Debian 9 "Stretch"
# deb http://httpredir.debian.org/debian/ stretch main contrib non-free
# deb http://ftp.debian.org/debian jessie-backports main contrib non-free

# deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 NETINST Binary-1 20160402-14:42]/ jessie main

#deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 NETINST Binary-1 20160402-14:42]/ jessie main

deb http://ftp.de.debian.org/debian/ stretch main

deb-src http://ftp.de.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main

deb-src http://security.debian.org/ stretch/updates main

# jessie-updates, previously known as 'volatile'

deb http://ftp.de.debian.org/debian/ stretch-updates main

deb-src http://ftp.de.debian.org/debian/ stretch-updates main

# Debian 9 "Stretch"

# deb http://httpredir.debian.org/debian/ stretch main contrib non-free

# deb http://ftp.debian.org/debian jessie-backports main contrib non-free

Dann waren noch die Paketquellen neu einzulesen und das Dist-Upgrade auszuführen.

apt update

1	apt update

apt dist-upgrade

1	apt dist-upgrade

Nachdem alle Pakete eingespielt wurden, konnte das System rebootet und auch contrib non-free aktiviert und eingelesen werden.

Debian 9 Stretch ist drauf und alles läuft bestens!

http-upload in Prosody aktivieren

Um nun auch Bilder in den XMPP-Chaträumen versenden zu können, habe ich den http-upload in Prosody aktiviert. Dazu wurde zuerst ein A-Record für die Subdomain upload.intux.de angelegt. Danach musste mein Let’s Encrypt Zertifikat, welches für intux.de und www.intux.de gültig war, noch erweitert werden.

# /opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --rsa-key-size 4096 -d intux.de -d www.intux.de -d upload.intux.de

1	# /opt/letsencrypt/letsencrypt-auto certonly --renew-by-default --rsa-key-size 4096 -d intux.de -d www.intux.de -d upload.intux.de

Im Anschluss wurden die Zertifikate noch in das entsprechende Verzeichnis /etc/prosody/certs kopiert.

# cp /etc/letsencrypt/live/intux.de/fullchain.pem /etc/prosody/certs
# cp /etc/letsencrypt/live/intux.de/privkey.pem /etc/prosody/certs
# chown root:prosody /etc/prosody/certs -R

# cp /etc/letsencrypt/live/intux.de/fullchain.pem /etc/prosody/certs

# cp /etc/letsencrypt/live/intux.de/privkey.pem /etc/prosody/certs

# chown root:prosody /etc/prosody/certs -R

Ich habe die Config von Prosody geöffnet.

nano /etc/prosody/prosody.cfg.lua

1	nano /etc/prosody/prosody.cfg.lua

Diese wurde um die Einträge

modules_enabled = {

.....
"http_upload";

.....
}

modules_enabled = {

.....

"http_upload";

.....

}

und

Component "upload.intux.de" "http_upload"

1	Component "upload.intux.de" "http_upload"

erweitert. Danach wurde Prosody neu gestartet und http-upload aktiviert.

# /etc/init.d/prosody restart

1	# /etc/init.d/prosody restart

Tipp

In Gajim muss das Plugin HttpUpload nachinstalliert werden.

exFAT

Neulich hatte ich einen USB-Stick bekommen, welcher auf einem Windows-System in exFAT formatiert war. Um auf die Daten zugreifen zu können, war es nötig folgende Erweiterungen zu installieren.

# apt-get install exfat-fuse exfat-utils

1	# apt-get install exfat-fuse exfat-utils

exFAT ist ein Microsoft-Dateisystem, welches es ermöglicht Dateien größer 4GB auf einen Flash-Speicher zu schreiben.