Serielle Konsole für QNAP mit Arduino

Mit dem Arduino Uno lässt sich leicht auf die serielle Konsole der QNAP zugreifen.

Gestern musste ich ein wild blinkendes QNAP NAS TS-212 reparieren, bei dem man weder per HTTP Web-UI noch per SSH dran kam. Außerdem führte das System einen regelmäßigen Neustart durch und es war nicht ersichtlich warum … Auch googlen brachte mich nicht weiter, außer auf wilde Spekulationen in alle möglichen Richtungen. Hmm … in so einem Fall wünscht man sich die gute alte serielle Konsole, die einem mehr Einblick in das System verschafft.

Der vorsorgliche Hinweis: Jeder bastelt auf eigene Gefahr! Man sollte außerdem ein paar Vorkenntnisse mitbringen, um die hier beschriebenen Schritte erfolgreich durchführen zu können! Also, jammert bloß nicht rum, wenn ihr einen Kurzschluss oder so verursacht und euch dadurch die QNAP geschrottet habt! 🙂

Nach dem Aufschrauben des Gehäuses die positive Überraschung: Auf dem Mainboard ist tatsächlich ein 4-Port Stecker zu finden, der lt. Infos im Netz tatsächlich auf eine RS-232 Schnittstelle hindeutet. Bei meinem Modell TS-212 ist der Konnektor mit CN9 beschriftet. Es handelt sich hier um einen 3.3V TTL Anschluss und bei den vier Pins handelt es sich um TX, VCC, RX, GND.

Jetzt ist nur die Frage, wie kann ich die serielle Schnittstelle abgreifen und per Serial-USB-Adapter an meinem Laptop benutzen? Die Lösung: Ein Arduino Uno Board bringt alles mit was ich benötige! Auf der einen Seite befindet sich eine digitale Input Leiste mit Anschlüssen für RX, TX und GND und auf der anderen Seite haben wir den USB Anschluss, um es direkt mit dem Laptop zu verbinden. Mit einem kleinen Adapterkabel klappt die Verbindung ganz leicht (siehe Bild).

Pinbelegung der seriellen Schnittstelle einer QNAP TS-212
Man verbindet die jeweiligen Pins RX, TX, GND mit den entsprechenden digitalen Inputs beim Arduino
… zum Schluss noch den USB Anschluss mit dem Laptop verbinden.

Dann starte ich auf meinem Linux Laptop das Programm Minicom mit dem Arduino Port /dev/ttyACM0 und mit den Terminal Einstellungen VT102, 115200 Baud, 8N1. Und siehe da, sofort habe ich den gesamten Output des QNAP Bootvorgangs in meinem Terminal.

Das bietet mir jetzt viel bessere Möglichkeiten der Fehleranalyse. Außerdem kann ich auch in die Bootschleife eingreifen, indem ich kurz nach dem Neustart, bei der Anzeige von „Marvell UBoot“ eine beliebige Taste drücke. Hier stehen dann einige Systembefehle zur Verfügung, die evtl. helfen können.

Migration Owncloud 9.1 nach Nextcloud 11.0 mit CentOS 7

Über die Vorteile von Nextcloud gegenüber Owncloud wurde ja im Netz schon viel geschrieben. Das hat mich letztendlich auch dazu bewogen mit meiner privaten Home-Cloud umzusteigen.

Mir geht es in diesem Artikel hauptsächlich um die Beschreibung der Migrationsschritte. Wer mehr über Owncloud bzw. Nextcloud wissen möchte, sollte einfach googlen.

Ich wollte bewusst kein sogenanntes „In-Place-Upgrade“ machen, also die neue Installation über die alte „drüberbügeln“, sondern parallel eine komplett neue Serverinstanz mit Nextcloud 11.0 stable hochziehen. So kann ich bequem erst den Server vorbereiten und kann auch gleich veraltete Software wie z.B. php5.4 gegen neue Stände ablösen, ohne den aktiven Owncloud-Server zu beeinflussen.

Owncloud läuft bei mir als VM unter KVM auf einem Fedora25 Server. Das Datenverzeichnis (/data) wird per NFS vom Hostsystem an die VM durchgereicht. Das hat den Vorteil, dass ich bei der Migration den NFS-Export einfach nur als Mountpoint in der neuen VM einhängen kann und keine Daten umkopieren muss. Außerdem bleibt damit die Nextcloud VM relativ schlank und ich kann zusätzlich die Daten bequem vom Hostsystem aus sichern.

Für die Nextcloud VM unter KVM hab ich folgendes Setup gewählt:

  • KVM Virtual Disk (qcow2) dynamisch wachsend mit 25 GB (LVM: / ~10GB, /var ~10GB)
  • CentOS 7.3.1611 Core (Minimal Installation)
  • PHP 7.1.4, Apache httpd 2.4, MariaDB (mysql) 5.5
  • Nextcloud 11.0.2 manual Installation (tar.bz)

CentOS habe ich wegen der sehr konservativen Update Politik gewählt, um eine stabile Basis für meinen Server zu haben. Leider bringt CentOS nur ein veraltetes PHP 5.6 mit. Da die Empfehlung für Nextcloud aber PHP 7.x ist, habe ich ein zusätzliches externes Repository angebunden. Der Apache Server und MariaDB werden dann aber aus dem CentOS Standard Repo installiert. Zwar stellt CentOS über das Epel-Repo auch eigene Nextcloud Pakete zur Verfügung, aber diese sind ziemlich veraltet, deswegen habe ich mich für die manuelle Installation von der Nextcloud.com Webseite entschieden.

Los geht’s!

Nach der Minimal Installation von CentOS 7.3 ziehen wir uns noch die Voraussetzungen für Nextcloud.

Zuerst die zusätzlich benötigten Repositories:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum install yum-utils
yum update

Anschließend installieren wir MariaDB und den Apache Webserver:

yum -y install mariadb-server mariadb
systemctl start mariadb.service
systemctl enable mariadb.service
mysql_secure_installation

yum -y install httpd
systemctl start httpd.service
systemctl enable httpd.service
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

Mit „mysql_secure_installation“ wird die Datenbank-Installation abgesichert. Hier kann man alle Defaultwerte übernehmen. Wichtig: Zugriff nur von Localhost zulassen!

Anschließend wird PHP 7.1 aus dem remi-repo installiert was wir mit yum-config-manager entsprechend als Standard aktivieren.

yum-config-manager --enable remi-php71
yum install php
yum install php-gd
yum install php-json
yum install php-mysql
yum install php-curl
yum install php-mbstring
yum install php-intl
yum install php-mcrypt
yum install php-imagick

yum install php-xml php-pecl-zip php-bcmath php-dba php-process php-soap

Auf der Nextcloud Webseite werden leider nur die als Voraussetzung benötigten Pakete für Ubuntu beschrieben. Ich hoffe also, dass ich bei meiner Aufstellung nichts vergessen habe.

Anschließend machen wir uns daran, eine neue, leere Datenbank für Nextcloud unter MariaDB anzulegen:

[root@nextcloud ~]# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 5.5.52-MariaDB MariaDB Server

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE nextcloud;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| nextcloud          |
| performance_schema |
MariaDB [(none)]> grant all privileges on nextcloud.* to ncuser@'%' identified by 'ncuser';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> grant all privileges on nextcloud.* to ncuser@'localhost' identified by 'ncuser';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> quit

Datenbankname: nextcloud
DB-User: ncuser
DB-Passwort: ncuser

Nextcloud Installation

Jetzt laden wir uns das Softwarepaket von der Nextcloud Webseite herunter und prüfen die Authentizität der gepackten Datei. Dann entpacken wir es und kopieren das entpackte Verzeichnis anschließend in den Web-Root Ordner (/var/www).
Siehe dazu auch die offizielle Installationsanleitung auf der Nextcloud Webseite: https://docs.nextcloud.com/server/11/admin_manual/installation/source_installation.html

yum install wget
wget https://download.nextcloud.com/server/releases/nextcloud-11.0.2.tar.bz2
wget https://download.nextcloud.com/server/releases/nextcloud-11.0.2.tar.bz2.md5
md5sum -c nextcloud-11.0.2.tar.bz2.md5 < nextcloud-11.0.2.tar.bz2
wget https://download.nextcloud.com/server/releases/nextcloud-11.0.2.tar.bz2.asc
wget https://nextcloud.com/nextcloud.asc
gpg --import nextcloud.asc
gpg --verify nextcloud-11.0.2.tar.bz2.asc nextcloud-11.0.2.tar.bz2
yum install bzip2
tar -xjf nextcloud-11.0.2.tar.bz2
cp -r nextcloud /var/www/
chown -R apache:apache /var/www/nextcloud

Apache für Nextcloud vorbereiten und HTTPS aktivieren

Mit openssl erstellen wir uns ein „Self-Signed-Certificate“, was für den Hausgebrauch durchaus ausreichend ist.

cd /etc/pki/tls/certs
openssl req -x509 -nodes -days 10000 -newkey rsa:2048 -keyout nextcloud.fritz.box.key -out nextcloud.fritz.box.crt

Anschließend konfigurieren wir das Zertifikat und den private Key in der Datei /etc/httpd/conf.d/ssl.conf von Apache. In diesem Zusammenhang können wir auch gleich die Strict-Transport-Security für den Header aktivieren, so wie es von Nextcloud empfohlen wird.

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>

  ServerName nextcloud.fritz.box
    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
    </IfModule>

/// AUSZUG ///

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/nextcloud.fritz.box.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/certs/nextcloud.fritz.box.key

Dann legen wir noch eine Apache-Definitionsdatei für unsere Nextcloud-Instanz unter  /etc/httpd/conf.d/nextcloud.conf an

Alias /nextcloud "/var/www/nextcloud/"

<Directory /var/www/nextcloud/>
  Options +FollowSymlinks
  AllowOverride All

 <IfModule mod_dav.c>
  Dav off
 </IfModule>

 SetEnv HOME /var/www/nextcloud
 SetEnv HTTP_HOME /var/www/nextcloud

</Directory>

Mit systemctl restart httpd wird der Webserver neugestartet. Danach sollten wir unter der URL https://nextcloud.fritz.box/nextcloud den Setup-Wizard von Nextcloud sehen. In meinem Fall hat der Setup-Wizard gleich mal gemeckert, dass ihm der Schreibzugriff auf das config Verzeichnis fehlt, obwohl das Webverzeichnis dem User „apache“ als Owner zugewiesen war. Das liegt dann aber an SELinux, was bei CentOS7 auf „enforced“ eingestellt ist und Zugriffe blockiert, die nicht explizit über entsprechende Policies erlaubt wurden. In der offiziellen Nextcloud Installationsanleitung wird zwar erklärt, wie man die SELinux-Policies entsprechend konfiguriert. Ich hab mich aber dazu entschieden SELinux global auf „permissive“ umzustellen, unter anderem auch deshalb, weil ich ja per NFS das Data-Verzeichnis außerhalb von Webroot einbinde. Somit werden keine Zugriffe mehr blockiert, sondern nur noch protokolliert (ändern unter /etc/selinux/config – anschließend Reboot).

Owncloud/Nextcloud Datenverzeichnis per NFS einbinden

Wie schon erwähnt, stelle ich das Datenverzeichnis (/data) per NFS-Export am Hostsystem zur Verfügung. Dazu installieren wir die NFS-Utils nach: yum install nfs-utils
Den Export binde ich über die /etc/fstab folgendermaßen ein:

### Owncloud Data Verzeichnis vom Hostsystem ###
192.168.xxx.yyy:/nfs/owncloud_data/data	/var/nextcloud/data 	nfs	auto 	0 0

Am Hostsystem (NFS-Server) sieht der Export (/etc/exports) so aus:

/nfs/owncloud_data 192.168.xxx.zzz(rw,sync,no_root_squash,no_subtree_check)

Migration der Owncloud Datenbank und config.php

Jetzt ist es soweit, dass wir den alten Server Offline nehmen können, um die Datenbank auf den neuen Server zu übertragen.
Dazu versetzen wir die Owncloud Instanz in den Maintenance Mode und machen anschließend ein Datenbank Backup.

sudo -u apache php occ maintenance:mode --on

/usr/bin/mysqldump --lock-tables --log-error=dbbackup-error.log -u <owncloud_dbuser> -p<oc_dbpassword> <oc_dbname> > owncloud-sqlbkp.bak

Das occ Programm befindet sich übrigens im Owncloud Webroot-Verzeichnis (z.B. /var/www/html/owncloud). Außerdem übertragen wir die config.php vom alten Server z.B. /var/www/html/owncloud/config/config.php in das ensprechende Verzeichnis auf dem neuen Server (z.B. /var/www/nextcloud/config/config.php). Die Zugriffsrechte müssen wieder entsprechend angepasst werden: 750 apache:apache.
Auf dem neuen Server wird die config.php an die neue Umgebung entsprechend angepasst:

<?php
$CONFIG = array (
  'instanceid' => '<automatisch_generiert>',
  'passwordsalt' => '<automatisch_generiert>',
  'datadirectory' => '/var/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '9.1.4.2',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'ncuser',
  'dbpassword' => 'ncuser',
  'installed' => true,
  'forcessl' => true,
  'theme' => '',
  'maintenance' => false,
  'trusted_domains' => 
  array (
    0 => 'nextcloud.fritz.box',
    1 => '192.168.xxx.zzz',
  ),
  'secret' => '<automatisch_generiert>',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'mail_from_address' => 'nextcloud',
  'mail_smtpmode' => 'smtp',
  'mail_domain' => 'your.domain',
  'loglevel' => 2,
  'trashbin_retention_obligation' => 'auto, 90',
  'updatechecker' => false,
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'your.mailhost',
  'mail_smtpport' => '587',
  'mail_smtpsecure' => 'tls',
  'mail_smtpname' => 'yoursmtpname',
  'mail_smtppassword' => 'yoursmtppassword',

/**
 * Use this configuration parameter to specify the base URL for any URLs which
 * are generated within Nextcloud using any kind of command line tools (cron or
 * occ). The value should contain the full base URL:
 * ``https://www.example.com/nextcloud``
 */
'overwrite.cli.url' => 'https://nextcloud.fritz.box/nextcloud',

);

Die config.php Datei kann bei eurer Installation natürlich auch etwas anders aussehen.

Achtung: Die automatisch generierten Keys/Salts/IDs nicht ändern und auch die ursprüngliche Versionsnummer von Owncloud hier auch nicht anpassen (9.1.4.2). Die Version dient dem Upgrade-Wizard später dazu, ein Upgrade der Datenbank auf die neue Version durchzuführen. Das dbtableprefix belassen wir ebenfalls bei oc_, weil wir die Tabellen der importierten Datenbank nicht extra anpassen wollen.
Wir ändern aber die Angaben für die Datenbank (Name/User/Passwort) und der Pfad für das „datadirectory“ wird auf den entsprechenden NFS-Mountpoint gesetzt.

Da ich den PHP APCu Memcache unter Owncloud aktiviert hatte, installiere ich noch folgendes Paket nach, damit dieser auch auf dem Nextcloud-Server wieder funktioniert:

sudo yum install php-pecl-apcu
systemctl restart httpd

Das Datenbank Backup wird ebenfalls zum neuen Server übertragen und dort in die MariaDB importiert.

mysql -u ncuser -p nextcloud < /pfad/zum/owncloud-sqlbkp.bak

Zu guter Letzt, wird der Upgrade Wizard auf dem neuen Nextcloud Server als User ‚apache‚ ausgeführt:

sudo -u apache php occ maintenance:mode --on
sudo -u apache php occ upgrade
sudo -u apache php occ maintenance:mode --off

Wenn das alles ohne Fehler durchgelaufen ist, sollte man sich über die WebUI der Nextcloud-Instanz erfolgreich mit den bisherigen Benutzern anmelden können.

Dort nehmen wir zunächst im Admin Bereich die empfohlenen Einstellungen vor und prüfen, ob alles korrekt konfiguriert ist. Vor allem die „Security & setup warnings“ sollte man ernst nehmen und beheben (siehe dazu die offizielle Nextcloud Dokumentation).

Ich hoffe ihr seid mit dieser Anleitung genauso erfolgreich wie ich. Über Anregungen und Verbesserungsvorschläge bin ich jederzeit dankbar.

How to remove an old-school EXT3 Storage Repository and create a local LVM based SR with RAID 1

With newer XenServer Version (> 5.x) you cannot longer use the old EXT3 based local storage repositories to store your virtual disks. Citrix has introduced LVM based storage repositories instead.

Caution: Make a backup before executing the following steps, otherwise you’ll lose all your data on the disk!

I assume, we already have a configured RAID1 mirror with a XSLocalEXT storage repository due to a XenServer upgrade. If you want to create a new software mirror with two new installed local disks, you have to create a new md-device with mdadm (this is not part of this documentation).

First, identify the status and devices of the mirror

If the RAID is in “rebuild” status, wait until it’s in “active” status.

[root@xenserver ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active raid1 sda[1] sdb[0]
488383488 blocks super external:/md127/0 [2/2] [UU]

md127 : inactive sdb[1](S) sda[0](S)
5928 blocks super external:imsm
unused devices: <none>

Get more details about the Software Mirror

mdadm --detail /dev/md126
mdadm --examine --brief --scan  --config=partitions

 

Identify and remove old logical volume from RAID1

[root@xenserver ~]# lvscan
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/MGT' [4.00 MiB] inherit
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-9ac571bf-5809-4f1e-a767-9fcb0c1d0b88' [19.57 GiB] inherit
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-a5b9ff3b-3bf2-4ea8-a53b-7fc086f4b4ab' [80.16 GiB] inherit
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-186f9092-9d98-410c-8839-024172512a36' [78.31 GiB] inherit
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-6fb6374a-1b83-48c6-bd26-277f19dcf4a8' [34.78 GiB] inherit
  inactive          '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-940e675e-aa13-4aa1-b694-41b6516b7e28' [48.93 GiB] inherit
  inactive          '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-60d3bd98-f81d-412b-86f6-d1d65ae6c7d2' [34.78 GiB] inherit
  ACTIVE            '/dev/VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e/VHD-ac10a162-e39e-4e61-a40c-3221413da002' [65.13 GiB] inherit
  inactive          '/dev/XSLocalEXT-6123fd9a-b126-2b74-a476-5a120175a1d9/6123fd9a-b126-2b74-a476-5a120175a1d9' [465.75 GiB] inherit

We want to remove the device /dev/XSLocalEXT …

First deactivate the LV if not already done

[root@xenserver ~]# lvchange -a n /dev/XSLocalEXT-6123fd9a-b126-2b74-a476-5a120175a1d9/6123fd9a-b126-2b74-a476-5a120175a1d9

Now you can remove the LV. You must add the metadata_read_only option, because Xenserver sets a read-only flag.

lvremove /dev/XSLocalEXT-6123fd9a-b126-2b74-a476-5a120175a1d9/6123fd9a-b126-2b74-a476-5a120175a1d9 --config global{metadata_read_only=0}

Remove also the empty volume group

[root@xenserver ~]# vgs

VG #PV #LV #SN Attr VSize VFree
VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e 1 8 0 wz--n- 890.00g 528.33g
XSLocalEXT-6123fd9a-b126-2b74-a476-5a120175a1d9 1 0 0 wz--n- 465.75g 465.75g

vgremove XSLocalEXT-6123fd9a-b126-2b74-a476-5a120175a1d9 --config global{metadata_read_only=0}

Check also, that the physical volume has no more corresponding logical volume

[root@xenserver ~]# pvscan
  PV /dev/sdd3      VG XSLocalEXT-fa330a8c-3f42-42f5-9935-3e4b40c03be3      lvm2 [457.75 GiB / 0    free]
  PV /dev/sdc3      VG VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e   lvm2 [890.00 GiB / 528.33 GiB free]
  PV /dev/md126p1                                                           lvm2 [465.76 GiB]
  Total: 3 [1.77 TiB] / in use: 2 [1.32 TiB] / in no VG: 1 [465.76 GiB]

[root@xenserver ~]# pvs
  PV           VG                                                 Fmt  Attr PSize   PFree
  /dev/md126p1                                                    lvm2 ---  465.76g 465.76g
  /dev/sdc3    VG_XenStorage-04cd13e0-8237-7754-2d66-4a6a10c5137e lvm2 a--  890.00g 528.33g
  /dev/sdd3    XSLocalEXT-fa330a8c-3f42-42f5-9935-3e4b40c03be3    lvm2 a--  457.75g      0

 

Reusing the local RAID1 by creating a new local storage repository with type=lvm

First, identify the MD-Partition with it’s uuid

ll /dev/disk/by-id/

lrwxrwxrwx 1 root root 13 Dec 29 09:26 md-uuid-27052c74:af76a037:e50f003e:65d1ffb8-part1 -> ../../md126p1

Then create the new LVM based storage repository

xe sr-create type=lvm content-type=user device-config:device=/dev/disk/by-id/md-uuid-27052c74:af76a037:e50f003e:65d1ffb8-part1 name-label="Local Disk RAID1"

Check, that the SR was successfully created

[root@xenserver ~]# lsblk
NAME                                                                                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                                                                                      8:0    0 465.8G  0 disk
└─md126                                                                                                  9:126  0 465.8G  0 raid1
  └─md126p1                                                                                            259:0    0 465.8G  0 md
    └─VG_XenStorage--d5e61586--e747--dac1--f971--29281873a18c-MGT                                      253:2    0     4M  0 lvm
sdb                                                                                                      8:16   0 465.8G  0 disk
└─md126                                                                                                  9:126  0 465.8G  0 raid1
  └─md126p1                                                                                            259:0    0 465.8G  0 md
    └─VG_XenStorage--d5e61586--e747--dac1--f971--29281873a18c-MGT                                      253:2    0     4M  0 lvm

You can now use the new created SR in Xencenter to store your VMs.

Raspberry Pi Zero [W] SSH per USB-LAN ohne Tastatur/Monitor

Der Raspi Zero hat eine coole neue Funktion, die ein virtuelles Netzwerk Gerät per USB emuliert und es per Avahi/Bonjour bereitstellt. Damit ist es möglich den Pi Zero per USB an einen PC anzuschließen und dieser erkennt ihn als virtullen USB Ethernet Adapter.img_6656.jpg

Somit kann man per SSH auf den Raspi ohne Tastatur/Maus und Montior von einem Host-PC aus zugreifen.

Zuerst installiert man ein aktuelles Raspbian Image (Jessie) auf eine MicroSD-Card: https://www.raspberrypi.org/downloads/raspbian/

Mit dd wird das Image auf die Karte geschrieben:

sudo dd if=2016-05-27-raspbian-jessie-lite.img of=/dev/sdX bs=4M
sudo sync

(/dev/sdX durch das korrekte Device ersetzen)

Bevor man nach dem Aufspielen des Image die SD-Card in den Raspi Zero einlegt und bootet, müssen noch zwei Files angepasst werden, um das USB Netzwerk Modul beim Booten zu aktivieren. Dazu mountet man die erste Partition der SD-Card (Raspbian Boot-Partition) an einem Linux-PC. Bei mir werden beide Partitionen beim Einlegen der SD-Card automatisch gemountet und die boot Partition /dev/sdc1 wird unter /run/media/juergen/boot eingebunden.

Dann fügt man „dtoverlay=dwc2“ in der config.txt als neue Zeile am Ende an:

sudo echo "dtoverlay=dwc2" >> /run/media/juergen/boot/config.txt

Anschließend wird noch die Datei cmdline.txt angepasst, indem man hinter rootwait folgendes einfügt: modules-load=dwc2,g_ether
Damit sieht die Zeile komplett so aus:

sudo vi /run/media/juergen/boot/cmdline.txt 

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh

Jetzt erst steckt man die SD-Card in den Raspi, verbindet ein Micro-USB Kabel mit dem USB-Anschluss des Pi Zero und das andere Ende steckt man in die USB-Buchse des PC (Hinweis: Bei mir haben nicht alle USB/Micro-USB Kabel funktioniert! Z.B gab es mit bestimmten USB-Ladekabeln Probleme).
Der erste Bootvorgang vergrößert automatisch die Partition und dauert deshalb etwas länger. Nach spätestens 90 Sekunden sollte aber am PC ein USB-Ethernet Gerät erscheinen:

USBEthernet1

In den Einstellungen der Netzwerkverbindung ändert man unter IPv4 die Adresse auf „Nur Link-Lokal“ USBEthernet2

Anschließend sollte das USB-Ethernet Gerät eine 169.x.y.z IP Adresse bekommen.

USBEthernet3

Sollte das nicht funktionieren, überprüft man, ob der Avahi Daemon installiert und der Dienst gestartet ist.

sudo systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
   Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Mi 2016-08-31 10:54:42 CEST; 1 day 12h ago
 Main PID: 912 (avahi-daemon)
   Status: "avahi-daemon 0.6.32 starting up."
   CGroup: /system.slice/avahi-daemon.service
           ├─912 avahi-daemon: running [BlueCloud.local]
           └─938 avahi-daemon: chroot helper

Nun kann man sich vom PC aus per ssh auf die IP-Adresse, oder dem Hostnamen raspberrypi.local verbinden:

ssh pi@raspberrypi.local

 

Inspiriert durch: http://blog.gbaman.info/?p=791

Raspbian Jessie mit Systemd und NetworkManager für besseres Netzwerkmanagement

Mittlerweile ist Debian 8 alias Jessie der Standard bei Raspbian, also Zeit endlich mit meinem Pi ebenfalls umzusteigen.

(Ich habe den Artikel wegen des neuen Raspbian Images angepasst, da der Umweg über Wheezy mit Update auf Jessie nicht mehr notwendig ist. Wer trotzdem ein Update von Wheezy auf Jessie machen muss, kann das am Ende des Artikels nachlesen.)

Mit Jessie führen die Debian-Entwickler endlich Systemd ein, was immer mehr Distributionen als Standard beim Init Prozess verwenden. Das ist ein Grund für mich meinen RaspPi mit Jessie zu installieren und Systemd zu verwenden, um in den Genuss einiger Vorteile bei der Administration zu kommen. Weiterhin werde ich die Netzwerkverwaltung auf NetzworkManager umstellen.

Installation des aktuellen Rasbian Images (Lite oder Full)
Download hier: https://www.raspberrypi.org/downloads/raspbian/

Ich gehe hier nicht näher auf die Installation des Images ein, da es im Netz dazu genügend Anleitungen gibt.

Netzwerkverbindungen auf NetworkManager umstellen

Als nächstes sollen die Netzwerkverbindungen vom alten /etc/network/interfaces Script auf den modernen NetworkManager umgestellt werden. Der bietet auch auf der Kommandozeile mit dem Tool nmcli viel größere Flexibilität beim Umgang mit den Netzwerkverbindungen.

Zuerst werden die Programmpakete für den NetworkManager installiert. Dies geschieht mit sudo apt-get install network-manager.

Anschließend kommentiert man in der bisherigen Netzwerkkonfigurationsdatei /etc/network/interfaces bis auf das loopback Interface (lo) alle Einträge aus (danke an Jörg Neumann für den Hinweis). Würde man das nicht tun, würde Debian beim Start weiterhin die Informationen dieser Konfig-Datei verwenden.

So sollte die Datei /etc/network/interfaces dann aussehen:

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto wlan0
#allow-hotplug wlan0
#iface wlan0 inet dhcp
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

#iface default inet dhcp

 

Mit nmcli eine neue LAN-Verbindung erstellen

Das Tool nmcli bedient sich am besten per sog. „tab completion“. D.h man beginnt einen Befehl und durch Tab wird er vervollständigt, oder er zeigt weitere Optionen an. So kann man sich den kompletten Befehl einfach „zusammenbauen“. Dafür installiert man das Paket bash-completion nach.

Als nächstes prüft man, ob der NetworkManager Daemon beim Booten automatisch gestartet wird (auf die Groß-/Kleinschreibung bei NetworkManager achten):

$ sudo systemctl status NetworkManager

● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled)
Active: active (running) since Mo 2015-05-04 18:47:14 CEST; 1 day 1h ago
Main PID: 368 (NetworkManager)
CGroup: /system.slice/NetworkManager.service
├─ 368 /usr/sbin/NetworkManager --no-daemon
└─14286 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-wlan0.pid -lf /var/lib/Netw...

Mit systemctl enable/start/stop/restart NetworkManager lässt sich der Daemon steuern.

Das Kommandozeilen Tool nmcli hat schließlich folgende Hauptbereiche:

  • general – Zeigt Informationen zum generellen Status des NetworkManagers und Berechtigungen
  • networking – Zeigt oder setzt globale Netzwerkoptionen, oder aktiviert/deaktiviert das Netzwerk.
  • radio – Zeigt oder setzt globale Wireless Optionen bzw. de-/aktiviert WLAN
  • connection – Hier werden die Netzwerkverbindungen hinzugefügt, konfiguriert und gemanaged
  • device – Dient zum anzeigen und managen der physischen Netzwerk Interfaces

Der Status wird immer durch Ergänzen des Parameters „status“ oder „show“ abgefragt.

Zum Abfragen des aktuellen Netzwerk Status gibt man z.B. folgenden Befehl ein:

nmcli general status (oder die Kurzform: nmcli g s)

So lange der Befehl eindeutig ist, können die Parameter auch abgekürzt werden, oder mit Tab komplettiert werden.

Die Eingabe von nmcli c s schließlich dürfte noch keinerlei Einträge zu Tage fördern.

Beim nächsten Reboot wird jedoch automatisch die kabelgebundene Netzwerkverbindung (eth0) vom NetworkManager definiert und aktiviert.

Will man zusätzlich noch manuell eine weitere Kabelverbindung hinzufügen, hangelt man sich mit der Tab Completion durch den folgenden Befehl:

nmcli connection add autoconnect yes con-name <frei wählbar> ifname <per Tab auswählbar> type ethernet save yes

Damit wird eine DHCP Connection eingerichtet. Soll dagegen eine statische IP-Adresse verwendet werden ergänzt man den Befehl noch um ip4 <xx.xx.xx.xx/24> gw4 <xx.xx.xx.xx> z.B.:

nmcli connection add autoconnect yes con-name test123 ifname eth0 type ethernet save yes ip4 192.168.2.10/24 gw4 192.168.2.1

Fertig ist die Netzwerkverbindung.

Nmcli c s <den mit con-name definierten Namen der Verbindung> zeigt im Detail alle manuell gesetzten und alle Standard Parameter, z.B.:

nmcli c s test123

Mit nmcli con modify test123 können noch viele weitere Optionen verändert werden. Z.B. kann hier noch explizit für eine Netzwerkverbindung der DNS-Server (ipv4.dns) und die DNS-Search Domain (ipv4.dsn-search) festgelegt werden, oder spezielle Routing-Einträge vorgenommen werden (ipv4.routes).

Den globalen DNS-Server trägt der NetworkManager übrigens automatisch in die Datei /etc/resolv.conf ein (erkennbar an dem Zusatz: #Generated by NetworkManager)

Hinzufügen einer Wi-Fi Verbindung

Zum Anzeigen der verfügbaren Wi-Fi access points, gibt man folgenden Befehl ein:

nmcli dev wifi list

SSID MODE CHAN RATE SIGNAL BARS SECURITY
MyWLAN Infra 11 54 MB/s 39 ▂▄__ WPA2

Das Erstellen eines WLAN Profils mit statischer IP Konfiguration, aber automatischer Ergänzung der DNS Adresse, erledigt folgender Befehl:

nmcli con add con-name MyWLAN ifname wlan0 type wifi ssid MyWLAN \ip4 192.168.100.101/24 gw4 192.168.100.1

Will man stattdessen wieder eine DHCP Adresse für das WLAN Profil, lässt man einfach die Parameter ip4 und gw4 weg.

Zum setzen eines WPA2 Passwortes, zum Beispiel „test123“, führt man folgende Befehle aus:

nmcli con modify MyWLAN 802-11-wireless-security.key-mgmt wpa-psk
nmcli con modify MyWLAN 802-11-wireless-security.psk test123

Im „Red Hat Enterprise Linux 7 Security Guide“ kann man übrigens mehr zur Passwort Sicherheit nachlesen.

Zum Schluss muss man die WLAN Verbindung noch aktivieren mit:

sudo nmcli -p con up 'MyWLAN' ifname wlan0

Folgender Befehl schaltet das WLAN komplett aus und wieder ein:

nmcli radio wifi [on | off ]

Um einen bestimmten Parameter z.B. mtu zu prüfen, verwendet man folgenden Befehl:

nmcli connection show id 'MyWLAN' | grep mtu
802-11-wireless.mtu: auto

Und zum Ändern des Parameters führt man dann folgenden Befehl aus:

nmcli connection modify id 'MyWLAN' 802-11-wireless.mtu 1350

Anschließend kann man die Konfigurationsänderung wie folgt überprüfen:

nmcli connection show id 'MyWLAN' | grep mtu
802-11-wireless.mtu: 1350

Für die evtl. Fehlersuche filtert man einfach im Journal nach NetworkManager:

sudo journalctl --unit NetworkManager

 

Somit hat man die Basis geschaffen für ein modernes Debian System mit dem RaspberryPi.

Viel Spaß damit.

 

Anhang

Für diejenigen, die ein bestehendes Raspbian Wheezy auf Jessie updaten müssen, ist hier der Ablauf beschrieben:

Der Weg führt über Wheezy

Man installiert also Raspbian Wheezy (bei mir ein Raspberry Pi 2) und konfiguriert alle nötigen Optionen mit raspi-config. Wichtig ist hier, dass man die SD-Card vergrößert, weil das Upgrade auf Jessie mindestens 1,5 GB Speicherplatz benötigt. Außerdem muss für Locales UTF-8 als Standard gesetzt sein, da es sonst beim Upgrade auf Jessie Probleme geben kann.

Anschließend aktualisiert man noch mit sudo apt-get update && sudo apt-get upgrade -y das neu installierte System.

Aktualisierung von Debian 7 (Wheezy) auf Debian 8 (Jessie)

Jetzt geht’s ans Upgrade! Vor der eigentlichen Aktualisierung prüft man jedoch noch den Status der installierten Pakete mit: sudo dpkg –audit. Nicht korrekt installierte Pakete müssen nochmals aktualisiert oder notfalls entfernt werden, bis der Befehl keine Meldungen mehr ausspuckt.

Sicherheitshalber erstellt man dann noch ein Backup des Etc-Verzeichnisses mit den Konfigurationsdateien und den Datenbanken der Softwareverwaltung dpkg und apt.

Nun wird die Repository-Datei auf den Jessie Pfad geändert: /etc/apt/sources.list
Dort ersetzt man einfach „wheezy“ durch die Zeichenkette „jessie“. Die weiteren Repositories unter /etc/apt/sources.list.d (collabora.list und raspi.list) bleiben wie sie sind, denn dafür gibt es keinen separaten Jessie-Zweig.

Dann wird mit sudo apt-get update && sudo apt-get upgrade -y die Aktualisierung der Pakete gestartet. Dies kann je nach Umfang sehr lange dauern und zwischendurch wird man immer wieder mal gefragt, wie mit den vorhandenen Konfigurationsdateien umgegangen werden soll. Hier einfach den Standard (N) bestätigen.

Wenn dieser Vorgang ohne Fehler beendet ist, erfolgt die vollständige Systemaktualisierung mit sudo apt-get dist-upgrade. Erst danach wird das System das erste mal neu gestartet.

Aufräumarbeiten

Nach dem Neustart kann man mit sudo apt-get autoremove alle veralteten Pakete entfernen, und mit sudo apt-get purge $(dpkg -l | awk ‚/^rc/ { print $2 }‘) können anschließend noch die nicht mehr benötigten Konfigurationsdateien entfernt werden, die anderenfalls sonst Probleme verursachen können. Damit wird dann auch Sysvinit vollständig entfernt.