Nextcloud 11 : Anlegen von Benutzern über Script

Erstellt und getestet wurde das ganze unter Nextcloud 11, sollte aber auch mit der Owncloud funktionieren.

Problem : Wir setzten hier produktiv eine Nextcloud ein, es kommt immer wieder vor das ich einige Benutzer für Kunden oder Projekte anlegen muss. Hier ist das dann immer gleich eine Gruppe von 10 - 20 Usern. Um mir das Leben zu erleichtern habe ich ein kleines Skript geschrieben das mir eine Textdatei ausliest und Benutzer anlegt.

Lösung : Als erstes muss eine Textdatei mit den ganzen Benutzern angelegt werden. Eine Zeile = ein Benutzer. z.B. users.txt
Vorname Nachname;v.nachname;Gruppe
Vorname Nachname1;v.nachname1;Gruppe1
Vorname Nachname2;v.nachname2;Gruppe2
Auf dem System muss pwgen installiert sein. Kann unter debian mit dem Befehl installiert werden.
apt-get install pwgen
Natürlich müssen alle Variablen im Skript eurem Server angepasst werden.

Dieses Skript erstellen und ausführbar (chmod u+x skriptname) machen.
#!/bin/bash
var_datum=$(date +"%Y%m%d")
var_user_file="users.txt"
var_apache_user=www-data
var_path_nextcloud=/var/www/cloud
var_result_file="${var_datum}_user_create.txt"
while read -r line
do
var_password=$(pwgen 12 -c -n -N 1)
set -e
export OC_PASS=$var_password
var_username=$(echo "${line}" | cut -d";" -f2)
var_name=$(echo "${line}" | cut -d";" -f1)
var_group=$(echo "${line}" | cut -d";" -f3)
su -s /bin/sh ${var_apache_user} -c "php ${var_path_nextcloud}/occ user:add ${var_username} --password-from-env --group='${var_group}' --display-name='${var_name}'"
echo "Benutzer ${var_username} wurde mit Passwort ${var_password} erstellt" >> "${var_result_file}"
done < $var_user_file
Wenn alles funktioniert hat müsste ein Output kommen der ca. so aussieht.

erstellen mehrer Benutzer in Nextcloud
Im Screenshot habe ich auch nochmal den Aufbau für die Demo mit cat ausgegeben. (Zeile 2)

Danach findet ihr eine Datei DATUM_users_created.txt in der alle Benutzer mit Password aufgeführt sind.

Leider ist es noch nicht möglich (Stand 03/17) Benutzer mit E-Mail Adresse zu hinterlegen hier muss dann entweder noch ein sql query abgefeuert werden oder manuell im Backend nachpflegen.

Mehr Informationen zu occ : Using OCC Command on Nextcloud 11

Debian 8 (Jessie) - Probleme mit ssh/sftp Übertragung

Problem : Nach einem Update auf Debian 8 bekommt ein Client keine Verbindung mehr. Im Logfile wird folgendes gelogt.
 sshd[xxx]: fatal: Unable to negotiate a key exchange method [preauth]


Lösung : manuelles hinzufügen des KexAlgorithms in der Datei /etc/ssh/sshd_config
Diesen Eintrag in die Datei /etc/ssh/sshd_config kopieren.
KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr
danach die Schlüssel neu generieren.
ssh-keygen -A
Jetzt starten wir noch den Dienst neu damit er alle Einstellungen mitbekommt.
service ssh restart
Nach diesen Änderungen konnte unser Kunde wieder wie gewohnt übertragen.

Kleine Anmerkung von mir es hat einen Grund warum veraltet Ciphers rausgeworfen werden.

Debian Jessie (8) - console-kit-daemon benötigt viel RAM und CPU

Problem : Auf einem Debian System läuft der Dienst console-kit-daemon und verbraucht RAM und CPU. Das ist solange richtig wie eine GUI (Gnome/KDE/FluxB/LXDE oder ähnliches) verwendet wird, ist dies nicht der Fall kann der Dienst deaktiviert werden.

Lösung : Da ich grundsätzlich ein Backup erstelle hab ich die Datei org.freedesktop.ConsoleKit.service aus /usr/share/dbus-1/system-service/ nach /backup kopiert.
cp /usr/share/dbus-1/system-service/org.freedesktop.ConsoleKit.service /backup

dannach hab ich die im Ordner gelöscht
rm /usr/share/dbus-1/system-service/org.freedesktop.ConsoleKit.service

nach einem Neustart läuft der Dienst console-kit-daemon nicht mehr und benötigt somit keine Resourcen mehr ;-)

Warnung : In manchen Foren steht die Empfehlung wie der Datei das exectue Bit zu nehmen. Ich rate davon ab da es dann zu anderen Seiten Effekten kommen kann (z.B. ssh login dauert ewig - timeout). Also ein
chmod -x /usr/sbin/console-kit-daemon
ist nur was zum testen für produktiv Systeme empfehle ich den oben beschriebenen Weg.

Apache 2.4 - Unterverzeichnis auf anderen Server umleiten mit mod_proxy

Problem : Wenn man mehrere Anwendungen hat die nur über Port 80 kommunizieren, aber alle über eine Leitung verfügbar sein müssen, kann man dies mit dem Apache Modul mod_proxy realisieren. Dieses Modul fungiert als proxy und leitet eine Anfrage intern an einen anderen Server um.

Wenn man sich diese schematische Zeichnung anschaut sieht man besser was gemeint ist.

mod_proxy - Apache 2.4
rot = physische Netzwerkverbindung


Lösung :
Diese Anleitung wurde unter Debian Jessie erstellt. Bei anderen Linux-Distributionen sollte das vorgehen ähnlich sein.
Zum Anfang stellen wir sicher das alle Module installiert sind die wir benötigen, das können wir mit dem folgenden Befehl bewirken.
apache2ctl -M
im output sollten dann diese Einträge vorhanden sein :
.....
 proxy_module (shared)
 proxy_html_module (shared)
 proxy_http_module (shared)
.....
 remoteip_module (shared)
 xml2enc_module (shared)
vermutlich sind diese Einträge nicht vorhanden wenn es sich um ein frisch installiertes System handelt. Dann müssen wir die Library nachinstallieren.
Dazu geben wir den Befehl
apt-get install libapache2-mod-proxy-html
ein. Dann aktivieren wir die Module mit
a2enmod proxy proxy_html proxy_http xml2enc remoteip
nach einem Neustart des Apache Servers stehen diese Module zur Verfügung
service apache2 restart

Nun müssen wir uns um die Weiterleitung kümmern. Diese erledigen wir in der Konfiguration der virtual Host auf dem Apache.
Ich verwende hier die Default Konfiguration für die Anleitung.
 nano /etc/apache2/sites-available/000-default.conf
öffnet den Editor dort fügen wir nun unsere Umleitung ein.
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html 
RemoteIPHeader X-Forwarded-For

# Weiterleiten auf site1.int.test
    ProxyPass /site1/ http://site1.int.test/
    ProxyPassMatch ^/site1/(.*) http://apache.proxy.ext.test/site1/$1
    ProxyPassReverse /site1/ http://site1.int.test/
	ProxyHTMLURLMap http://site1.int.test /site1/
# Weiterleiten auf site2.int.test
    ProxyPass /site2/ http://site2.int.test/
    ProxyPassMatch ^/site2/(.*) http://apache.proxy.ext.test/site2/$1
    ProxyPassReverse /site2/ http://site2.int.test/
	ProxyHTMLURLMap http://site2.int.test /site2/
		
# LogFiles

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Nachdem wir die Datei gespeichert haben überprüfen wir die Konfiguration mit dem Befehl
apache2ctl configtest
lautet der Output
Syntax OK
haben wir alles richtig gemacht. Jetzt starten wir noch den Apache Server durch damit die Konfiguration aktiv wird.
service apache2 restart


Quellen :
apache.org - Doku - proxypass
apache.org - Doku - proxypassmatch
apache.org - Doku - proxypassreverse
apache.org - Doku - proxyhtmlurlmap
apache ProxyPass: how to preserve original IP address

Debian - automatisches Aktualisieren des Systems

Ich bin normalerweise kein Fan von automatischen Updates auf Servern jedoch macht es z.B. Sinn die Sicherheits Updats Nachts automatisch zu installieren. Ein komplettes System (dist-upgrade) oder Packetupdate (upgrade) ist jedoch mit Vorsicht zu genießen. Da kann es schon mal vorkommen das man morgens kommt und der Apache oder der MySQL Server Mist baut, wenn man dann nicht sofort an das automatische Update denkt sucht man sich einen Wolf ;-) Ich gehe im der folgenden Anleitung davon aus das man unter root arbeitet sollte dies nicht der Fall sein kann man bei jedem Befehl ein sudo davor setzen, dies muss natürlich installiert & konfiguriert sein.

Zuerst installieren wir cron-apt auf dem Server der automatisch aktualisiert werden soll.

Das können wir mit dieser Zeile erledigen :
apt-get install cron-apt
Nach der Installation von cron-apt müssen wir dies noch konfigurieren. Dazu rufen wir die Konfigurationsdatei auf
nano /etc/cron-apt/action.d/3-download
dort sollten wir diesen Inhalt finden :
autoclean -y
dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
Die Standardkonfiguration bedeutet das alle Packete die als Update verfügbar sind heruntergeladen ABER nicht installiert werden.
dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
Möchte man sich gar nicht um die Updates kümmern kann man das -d aus der Zeile löschen.
z.B.
dist-upgrade -y -o APT::Get::Show-Upgraded=true
das Vorgehen sollte man aber meiner Meinung nicht machen siehe oben.

Damit die Sicherheits Updates automatisch installiert werden müssen wir eine neue Liste für apt anlegen.
nano /etc/apt/sources.list.d/00_Sicherheits_Updates.list
Dort fügen wir diesen Inhalt ein :
# Sicherheits Updates für Debian Jessie

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

Wer eine andere Version als Jessie verwendet muss das hier natürlich ändern.

Jetzt müssen wir die Zeilen die wir hier eingetragen haben aus der Datei /etc/apt/source.list auskommentieren wir möchten ja keinen Ärger mit doppelten Packetquellen haben.
 nano /etc/apt/sources.list
Der Inhalt sollte dann so in etwa aussehen, kommt drauf an ob eigene Quellen eingefügt wurden oder nicht.
#deb cdrom:[Debian GNU/Linux 8.2.0 _Jessie_ - Official amd64 NETINST Binary-1 20150906-11:09]/ jessie main

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

# In die Datei /etc/apt/sources.list.d/00_Sicherheits_Updates.list ausgelagert für cron-apt
#
# deb http://security.debian.org/ jessie/updates main
# deb-src http://security.debian.org/ jessie/updates main

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

Jetzt erzählen wir noch cron-apt das es diese Datei auch abarbeiten soll. Das machen wir indem wir eine neue Konfiguration für cron-apt anlegen.
 nano /etc/cron-apt/action.d/5-Sicherheits-Updates
mit diesem Inhalt :
upgrade -y -o APT::Get::Show-Upgraded=true
dann noch die Konfiguration dafür anlegen das auch nur Sicherheitsupdates installiert werden.
 nano /etc/cron-apt/config.d/5-Sicherheits-Updates
Inhalt :
OPTIONS="-q -o Dir::Etc::SourceList=/etc/apt/sources.list.d/00_Sicherheits_Updates.list -o Dir::Etc::SourceParts=\"/dev/null\""

Dann müssen wir noch einstellen wann das alles passieren soll. In der Default Einstellung läuft das ganze morgens um 4:00 Uhr der Syntax ist hier der gleich wie bei cron. Das kann in der Datei /etc/cron.d/cron-apt geändert werden. Da ich meine Backups früher erstelle ist für mich die Zeit ok, deswegen lass ich das auch auf Default ;-).Zum Abschluss können wir noch testen ob das ganze Zeugs jetzt auch funktioniert das erledigen wir mit
cron-apt -s
das Logfile zu cron-apt findet man unter /var/log/cron-apt/ dieses kann mit dem Befehl
cat /var/log/cron-apt/log | more
einfach durchgeblättert werden.

Wenn das alles funktioniert hat kann man sich zurücklehnen und einen Kaffee besorgen, ab jetzt werden jeden Morgen um 4:00 Uhr die Sicherheitsupdates automatisch installiert und die Packete die zum Update anstehen heruntergeladen um diese später definiert zu installieren.

Raspberry Pi3 & OMD - Open Monitoring Distribution

Servermonitorring wird immer wichtiger je größer die zu überwachende Umgebung wird. Es gibt verschiedene Ansätze um dies zu realisieren. Die Jungs von Check_MK haben eine freie Alternative zu ihrem Produkt (CEE) geschaffen das für kleinere Umgebungen durchaus genügt.
Allerdings ist in der freien Version CRE oder OMD etwas mehr Handarbeit nötig, vor allem bei den Agents.

Da ich einen Raspberry Pi3 verwende habe ich mich für OMD entschieden da es hier schon fertige Packete für armv8 gibt.

Erstmal besorgt man sich ein aktuelles raspbian-lite und schreibt das Image auf eine Micro-SD, ich würde hier mind. 8 GB empfehlen.
Da dieser Schritt zu genüge im Internet erklärt ist gehe ich hier nicht weiter darauf ein.

Sobald das System läuft kann man sich über die IP anmelden. Ich habe dafür einfach auf meinem DHCP Server nachgeschaut.

1.) Anmelden über SSH auf dem RaspBerry Pi3
ssh pi@IP-Adresse
oder, für die Windows Benutzer, über Putty / Kitty. Default Zugangsdaten sind Benutzer : pi Passwort : raspberry

2.) Ändern der Passwörter
Bleibt nicht auf den Defaults das ist ein unnötiges Risiko.

Einmal das user Passwort ändern mit passwd und dann das root Passwort mit sudo passwd

3.) Mit root anmelden
su - root
man könnte auch alle Schritte mit sudo erledigen aber gerade für die Grundkonfiguration geht mir pers. das auf die Nerven

4.) Nachdem man mit root angemeldet ist das System auf den aktuellsten Stand bringen
apt-get update && apt-get -y upgrade


5.) ändern des Computernamen
raspi-config

Hostname Konfiguration raspbianHostname Konfiguration raspbian

6.) Einstellen der Länderspezifischen Sachen & Expand Filesystem

Für Deutschland empfehle ich diese Einstellungen
I1 = de_DE.UTF-8 UTF-8
I2 = Europe/Berlin
I4 = DE Germany

5 Internationalisation Options
Expand Filesystem

7.) System neu starten
Müsste von raspi-config sowieso verlangt werden, sollte dies nicht der Fall
reboot
oder
shutdown -r now


8.) Erneut am System via SSH anmelden (siehe 1. und 3.)

9.) Einbinden des OMD Repository & Cache erneuern

Erstmal installieren wir uns den GPG Key für das Repo
cd ~
wget -q "https://labs.consol.de/repo/stable/RPM-GPG-KEY" -O - | sudo apt-key add -

Jetzt fügen wir das Repository hinzu
echo "deb http://labs.consol.de/repo/stable/debian $(lsb_release -cs) main" > /etc/apt/sources.list.d/labs-consol-stable.list

Dann müssen wir den Packet Cache erneuern
apt-get update


10.) Jetzt können wir omd installieren
Das META Packet installiert die aktuellste Version incl. der Abhängigkeiten
apt-get install omd-labs-edition


11.) Während der Installation muss ein MySQL Passwort für den Benutzer root vergeben werden.

12.) Sicherstellen das das System für OMD vorbereitet ist.
omd setup

13.) eine Seite für die Überwachung in OMD anlegen
omd create demo
wobei demo euer Sitename ist

14.) Konfigurieren der Seite
omd config demo
ich zeige euch meine Konfiguration es gibt aber viele andere Möglichkeiten OMD zu konfigurieren !

CONFIG OMD

solltet ihr meine Konfiguration übernehmen müsst ihr noch eine Datei editieren. Es kann vorkommen das dieser Schritt nach jedem Update gemacht werden muss jedoch hatte ich noch keine Probleme damit.
nano /omd/sites/demo/etc/apache/conf.d/auth.conf
dort kommentiert ihr Auth* und require valid-user aus.
#  AuthName "OMD Monitoring Site demo"
#  AuthType Basic
#  AuthUserFile /omd/sites/demo/etc/htpasswd
#  require valid-user

wenn ihr das nicht macht bekommt ihr immer 2 Anmeldemasken , die 1. ist von Thruk die 2. von Check_MK/OMD

15.) Starten der OMD Seite
omd start demo


16.) Server selbst überwachen - OPTIONAL
Wenn ihr den Server selbst überwachen möchtet müsst ihr euch noch den passenden Agent installieren.
dpkg -i /omd/sites/demo/share/check_mk/agents/check-mk-agent_1.2.6p12-1_all.deb 
auch das überwachen auf neue Updates würde ich gleich mit auf dem lokalen Server nach dieser Anleitung einrichten


Weiterführende Links :
Raspberry - Temperatur in Prompt
SSH Login ohne Passwort
OMD/CHECK_MK Plugin - Quotas überwachen Windows 2008 R2
OMD/CHECK_MK Plugin - Aufgaben überwachen (inzw. incl.)
OMD/CHECK_MK Plugin - Debian auf Updates überwachen
Viele weitere Plugins für OMD/CHECK_MK

Quellen :
https://labs.consol.de/repo/stable/
http://omdistro.org/start
https://www.raspberrypi.org/downloads/raspbian/
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)