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.

Basic setup of a Multi Node Apache Kafka/Zookeeper Cluster

Prerequesites

Install three nodes with CentOS 7 with at least 20GB Disk, 2 GB RAM and two CPU Cores.

Install JDK

yum install -y java-1.8.0-openjdkl java-1.8.0-openjdk-devel net-tools

Set JAVA_HOME in ~/.bashrc

# Set Java-Home
export JAVA_HOME="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-5.b12.el7_4.x86_64/jre"
export PATH=$JAVA_HOME/bin:$PATH

Disable SELinux, Firewall and IPv6

systemctl disable firewalld
systemctl stop firewalld

echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf

[root@kafka3 ~]# cat /etc/selinux/config | grep "^SELINUX="
SELINUX=permissive

Reboot Server

Installing Kafka

Download Kafka and unpack it under /opt

https://www.apache.org/dyn/closer.cgi?path=/kafka/0.11.0.2/kafka_2.11-0.11.0.2.tgz

tar zxvf kafka_2.11-0.11.0.2.tgz

Starting Zookeeper

On each node create a zookeeper directory and a file ‚myid‘ with a unique number:

mkdir /zookeeper
echo '1' > /zookeeper/myid

On all three Server go to Kafka home folder /opt/kafka_2.11-0.11.0.1 and setup zookeeper like this

vi config/zookeeper.properties

# the directory where the snapshot is stored.
dataDir=/zookeeper
# the port at which the clients will connect
clientPort=2181
clientPortAddress=192.168.2.56
# disable the per-ip limit on the number of connections since this is a non-production config
maxClientCnxns=0

# The number of milliseconds of each tick
tickTime=2000
  
# The number of ticks that the initial synchronization phase can take
initLimit=10
  
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
 
# zoo servers
server.1=kafka1.fritz.box:2888:3888
server.2=kafka2.fritz.box:2888:3888
server.3=kafka3.fritz.box:2888:3888
#add here more servers if you want

Start Zookeeper on all three servers

./bin/zookeeper-server-start.sh -daemon config/zookeeper.properties

Change the Kafka server.properties on all three servers (set a unique broker id on each server)

vi config/server.properties

# The id of the broker. This must be set to a unique integer for each broker.
broker.id=2

#     listeners = PLAINTEXT://your.host.name:9092
listeners=PLAINTEXT://:9093

# A comma seperated list of directories under which to store log files
log.dirs=/tmp/kafka-logs-2

# Zookeeper connection string (see zookeeper docs for details).
# This is a comma separated host:port pairs, each corresponding to a zk
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
# You can also append an optional chroot string to the urls to specify the
# root directory for all kafka znodes.
zookeeper.connect=kafka1.fritz.box:2181,kafka2.fritz.box:2181,kafka3.fritz.box

Start Kafka on all three nodes:

./bin/kafka-server-start.sh -daemon config/server.properties

Verify kafka and zookeper are running:

jps
4150 Jps
2365 QuorumPeerMain
1743 Kafka

Verify also all brokers are registered to zookeeper:

# ./bin/zookeeper-shell.sh kafka1:2181 ls /brokers/ids
Connecting to kafka1:2181

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
[1, 2, 3]

Create a example Topic with three partitions and replicationfactor 3

# ./bin/kafka-topics.sh --create --zookeeper kafka1:2181 --topic example-topic --partitions 3 --replication-factor 3
Created topic "example-topic".

# ./bin/kafka-topics.sh --list --zookeeper kafka1:2181 --topic example-topic
example-topic

# ./bin/kafka-topics.sh --describe --zookeeper kafka1:2181 --topic example-topic
Topic:example-topic	PartitionCount:3	ReplicationFactor:3	Configs:
	Topic: example-topic	Partition: 0	Leader: 2	Replicas: 2,3,1	Isr: 2,3,1
	Topic: example-topic	Partition: 1	Leader: 3	Replicas: 3,1,2	Isr: 3,2,1
	Topic: example-topic	Partition: 2	Leader: 1	Replicas: 1,2,3	Isr: 1,2,3

Test the Topic

Start a Producer on one node:

# ./bin/kafka-console-producer.sh --broker-list kafka1:9093,kafka2:9093,kafka3:9093 --topic example-topic

Start also a Consumer on a different node:

# ./bin/kafka-console-consumer.sh --zookeeper kafka1:2181 --topic example-topic --from-beginning

Write some text in the producer console. You should then see the Text on the Consumer Console.

Stop a node and write again some messages in the producer console to verify the high availability is working.

 

 

 

Docker Swarm Cluster on Raspberry Pi with Raspbian Stretch

Docker is is on everyone’s lips and now you can also use Docker on the Raspi. But one is not enough, we’ll install a Docker Swarm Cluster. If you’d like to know more about Docker and Swarm see the homepage of Docker Community.

First install a fresh Rasbian Stretch image like explained here:

Raspberry Pi Headless Installation with SSH enabled and WLAN

Update your packages to the newest versions and install some dependencies.

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common

Docker now supports also Debian Stretch (Docker CE Installation Guide)
So you can install Docker easiely with a Helper Script. Download the Script and execute it:

curl -fsSL get.docker.com -o get-docker.sh
sudo sh get-docker.sh

After successful setup, you can add the user ‚pi‘ to the ‚docker‘ group, to directly execute docker commands

sudo usermod -aG docker pi

After a reboot, you can execute the docker commands with your ‚pi‘ login:

docker run hello-world

Initializing a Swarm Cluster

Docker Swarm Documentation

To initialize the Docker Swarm Cluster execute the following command on the first Docker instance:

docker swarm init
Swarm initialized: current node (7nkdamk2m1tdhjzf45gfk5o91) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-4ynwgkfmjkj937j7kxlyll7ncucvo8jawijv8lybxourfm2d6n-dcol6t8ulsdl7axyjg2q0moqp \
    192.168.2.58:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

If you get this error…

docker swarm init
Error response from daemon: could not choose an IP address to advertise since this system has multiple addresses on interface wlan0 (fdde:530f:b4e8::f8a and fdde:530f:b4e8:0:ba66:db42:43a1:46eb) - specify one with --advertise-addr

.. you can join one of the IPv6 adresses with –advertise-addr or you can instead disable IPv6 completely:

/etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

After successfully initializing the cluster, you can get a list of cluster nodes with this command:

docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
7nkdamk2m1tdhjzf45gfk5o91 *   dockerpi1           Ready               Active              Leader

To add a second instance as worker node, execute the docker swarm join command, like you can see in the output of the docker swarm init command:

docker swarm join \
>     --token SWMTKN-1-4ynwgkfmjkj937j7kxlyll7ncucvo8jawijv8lybxourfm2d6n-dcol6t8ulsdl7axyjg2q0moqp \
>     192.168.2.58:2377
This node joined a swarm as a worker.
 

Docker Compose Installation

Docker Compose Documentation. To Install Docker Compose use this commands:

sudo apt-get install python-pip
sudo pip install docker-compose
docker-compose version
docker-compose version 1.16.1, build 6d1ac219
docker-py version: 2.5.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.1.0f  25 May 2017

 

Raspberry Pi Headless Installation with SSH enabled and WLAN

You need only a few simple steps, to get a fully headless setup of Raspbian Stretch for your Raspberry Pi

First, write the downloaded raspbian image to the SD-Card

Be careful, to write the image to the right device!

unzip 2017-09-07-raspbian-stretch-lite.zip
sudo dd if=2017-09-07-raspbian-stretch-lite.img of=/dev/mmcblk0xyz bs=4M

 

Create a WLAN Configuration File

You need a WLAN template with your WiFi Settings.

vi wpa_supplicant.conf

country=DE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={

ssid="My_WLAN"
psk="password"
key_mgmt=WPA-PSK
}

Reinsert the SD-Card and create and add some configuration files

Create an empty file called ’ssh‘ on the boot partition to enable ssh daemon:

touch /run/media/juergen/boot/ssh

Copy the earlier created WLAN config file:

sudo cp wpa_supplicant.conf /run/media/juergen/9a7608bd-5bff-4dfc-ac1d-63a956744162/etc/wpa_supplicant/

Change the hostname:

sudo vi /run/media/juergen/9a7608bd-5bff-4dfc-ac1d-63a956744162/etc/hosts
sudo vi /run/media/juergen/9a7608bd-5bff-4dfc-ac1d-63a956744162/etc/hostname

Unmount the SD-Card partitions:

sudo umount /dev/mmcblk0p2
sudo umount /dev/mmcblk0p1

Now insert SD-Card in Raspberry Pi and boot. Then you can ping the Pi and login with SSH:

ping dockerpi1
ssh pi@dockerpi1

After login change the default password of the pi user:

passwd

Also change the Locale and Keyboard layout if needed:

Set 'DE' for German:
vi /etc/default/keyboard

Change your Locale:
sudo dpkg-reconfigure locales

and your timezone:
sudo dpkg-reconfigure tzdata

Optionally

Optionally install also the DNS utils to get the nslookup command.

sudo apt-get install dnsutils

If you need autologin for the pi user add this file to your Installation

sudo vi /etc/systemd/system/getty@tty1.service.d/autologin.conf

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi --noclear %I 38400 linux

 

 

 

 

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