Kontakt
Einfach Suchbegriff eingeben und Enter drücken
Abbrechen

FAQ: System

Auf jedem neu erstellten proServer finden sich zwei Benutzer, für die die bei der Bestellung angegebenen public-keys hinterlegt wurden.

Zum einen der Benutzer vproXXXX. Dieser kann sudo ohne Passwort aufrufen und dient der Anpassung des Servers selbst und dessen Konfigurationsdateien. Dieser Benutzer ist nicht dafür vorgesehen, dass über diesen deployed oder für die Anwendung notwendige Komponenten mittels npm nachinstalliert werden.

Für diesen Zweck gibt es den Benutzer proserver. Dieser darf kein sudo und ist damit auf sein Home-Verzeichnis unter /var/www beschränkt. Jedoch wird PHP als dieser Benutzer ausgeführt, womit eine einfache Administration Ihrer Anwendung gewährleistet wird.

Des weiteren findet sich noch der Benutzer www auf dem System. Nginx / Apache laufen  als dieser Benutzer auf dem proServer. www ist in keiner weiteren Gruppe und  hat auch keine erweiterten Rechte. Falls die Dateien Ihrer Anwendung nicht global lesbar sind, sondern nur für den Besitzer selbst und die Gruppe der Datei, so muss der Benutzer www noch in der Datei /etc/group in die Gruppe proserver aufgenommen werden.

Vorweg: Den Hostname eines Systems auf eine Domain zu setzen, die auf dem System verwendet wird - beispielsweise als Webseite - kann zu Problemen beim Mailversand führen. Daher empfehlen wir, den voreingestellten generischen Hostnamen zu behalten.

Als root ändert der folgende Befehl den Hostnamen:

hostname <new hostname>

Für eine permanente Änderung, editiere die Datei /etc/rc.conf und füge die folgende Zeile hinzu:

hostname="new.host.name"

Im Auslieferungszustand ist der Mailversand auf den proServern deaktiviert um ein unbewusstes spammen zu verhindern.

Um diesen zu aktivieren bedarf es folgender 4 Schritte:

1.: sendmail in der /etc/rc.conf nicht ausschalten.

$ sudo vim /etc/rc.conf

vorher:

# Disable Sendmail by default
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

nachher:

# Disable Sendmail by default
# sendmail_enable="NONE"
# sendmail_submit_enable="NO"
# sendmail_outbound_enable="NO"
# sendmail_msp_queue_enable="NO"

2.: sendmail Konfiguration vorbereiten

In der Datei /etc/mail/aliases sollte mindestens die Zeile

# root:	me@my.domain

aktiviert und mit einer erreichbaren Emailadresse versehen werden. An diese Adresse werden regelmäßig Informationen zu dem System inkl. evtl fehlgeschlagene cronjobs und ähnliches gesendet.

Ein möglicher Eintrag sieht anschließend zB so aus:

root:	proServer@example.com

3.: sendmail Konfiguration bauen

$ cd /etc/mail
$ sudo make
$ sudo make install

4.: sendmail starten

$ sudo service sendmail start

Folgende Meldung ist normal und bedeutet lediglich, dass sendmail nur versendet und nicht empfängt.

Cannot 'start' sendmail. Set sendmail_enable to YES in /etc/rc.conf or use 'onerestart' instead of 'restart'.

Fertig. Der Versand ist nun konfiguriert und aktiviert.

Anmerkung: Der Versand an den Hostnamen des proServers funktioniert nicht, da das System sich selbst für diesen zuständig sieht. Daher ist es wichtig, das ein Hostname gewählt wurde der nicht z.B. der zu betreibenden Webseite entspricht. Nach einem Wechsel des Hostnamen muss nochmals Schritt 3 durchgeführt werden.

Derzeit liefern wir alle proServer mit den Einstellungen für die Let's Encrypt Staging-Server aus, da für die Domain punkt.de das Kontingent an Zertifikaten für Subdomains aufgebraucht ist.

Um die Let's Encrypt Live-Server zu verwenden muss in /usr/local/etc/dehydrated/config die CA auf https://acme-v01.api.letsencrypt.org/directory geändert werden.

Die gewünschten Domains werden in die Datei domains.txt eingetragen. Dabei müssen alle Domains, für die ein einzelnes (Multidomain-)Zertifikat beantragt werden soll, in eine Zeile geschrieben und nur durch ein Leerzeichen getrennt werden. Wildcardzertifikate sind derzeit noch nicht möglich.

$ cat /var/www/letsencrypt/domains.txt

example.org www.example.org
example.com www.example.com wiki.example.com

Um die Beantragung eines SSL Zertifikats mit Let's Encrypt durchzuführen muss der DNS Eintrag dieser Domain bereits auf den proServer zeigen.

Anschließend muss noch ein Cronjob aktiviert werden:

$ sudo crontab -u root -e

# Dehydrated Cronjob
PATH=/bin:/usr/bin:/usr/local/bin
@weekly /usr/local/bin/dehydrated -c -g

Jetzt müssen nur noch die Zertifikate beantragt und die entsprechenden Domains in die Webserver Konfiguration eingetragen werden:

$ sudo dehydrated -c

Fertig. Die neu generierten Zertifikate befinden sich nun unter dem Pfad /usr/local/etc/ssl/certs/<domainname>/

Weitere Informationen zu dem von uns eingesetzten Tool gib es auf Github oder auf letsencrypt.org.

Während ein Passwort mit einer Brute-Force- Attacke geknackt werden kann, sind SSH-Schlüssel allein durch rohe Gewalt fast unmöglich zu entziffern. Beim Generieren eines Schlüsselpaares werden zwei lange Zeichenketten erstellt. Diese nennt man den öffentlichen und den privaten Schlüssel. Sie können den öffentlichen Schlüssel auf jedem Server platzieren und dann mit einem Client , auf dem der private Schlüssel hinterlegt ist, sich auf diesen Server verbinden. Wenn die beiden übereinstimmen, entriegelt das System ohne dass ein Passwort eingegeben werden muss.

Um die Sicherheit noch weiter zu steigern, kann der private Schlüssel mit einem Passwort versehen werden. Dieses muss vor einem Verbindungsaufbau einmalig eingegeben werden.

SSH-Schlüsselpaar erstellen

Diese Anleitung bezieht sich auf unixoide Betriebssysteme wie zB. Linux und OS X (macOS)

Im ersten Schritt wechseln wir in das Home-Verzeichnis des eigenen Users und rufen den SSH-Schlüsselgenerator so auf.

Die Optionen -t rsa und -b 4096 sorgen dafür, das ein Schlüsselpaar mit der RSA und 4096 bit erstellt wird.

$ cd ~
$ ssh-keygen -t rsa -b 4096

Bevor das eigentliche Schlüsselpaar generiert wird, fragt das Programm ein paar Dinge ab.

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/yourname/.ssh/id_rsa):

Hier kann man einen anderen Speicherort und Dateinamen für sein Schlüsselpaar angeben. Dies ist in den meisten Fällen nicht notwenig.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Nun kann man sich entscheiden, ob man sein Schlüsselpaar mit einem zusätzlichen Passwort sichern möchte. Dieses muss bei Verwendung des Schlüsselpaares eingegeben werden.

Wenn man kein Passwort haben möchte, gibt man nichts ein und drückt zweimal [Enter].

Your identification has been saved in /Users/yourname/.ssh/id_rsa.

Your public key has been saved in /Users/yourname/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:IF5HF7KJHhn5qnP23nQGngPXAlgELeFvrtGtP5UQaXo
yourname@computername.local

The key's randomart image is:
+---[RSA 4096]----+
|  oB= **o.       |
| .+=.oEB+o       |
|..+.*+Boo        |
|.. =.=oo         |
|  . = .oS        |
|   o o.o         |
|  .   + o        |
|... .o o         |
|oo ..oo          |
+----[SHA256]——+

Das Schlüsselpaaar wurde erstellt und im eigenen Home-Verzeichnis in den Ordner .ssh abgelegt.

Das Paar besteht aus einem öffentlichen (id_rsa.pub) und einem privaten Schlüssel (id_rsa).

WICHTIG: Derprivate Teil des Schlüsselpaares sollte niemals in fremde Hände gelangen. Ein Verschicken, z.B. in einer E-mail kann dazu führen, dass Ihre Schlüssel abgefangen und für illegale Aktivitäten benutzt wird.

$ls ~/.ssh
id_rsa		id_rsa.pub

SSH-Schlüsselpaar auf einen Server übertragen

Jetzt muss der öffentliche Schlüssel nur noch auf den Server:

cat ~/.ssh/id_rsa.pub | ssh vpro0000@vpro0000.proserver.punkt.de "cat >>  ~/.ssh/authorized_keys"

Dies funktioniert natürlich erst wenn man bereits Zugang zu einem Server hat. Also wenn man z.B. einen zweiten Schlüssel dort ablegen will.

logrotate

Wir empfehlen die Verwendung von logrotate. Die logrotate-Konfiguration ist unter /usr/local/etc/logrotate.conf abgelegt. Diese bindet gegebenenfalls weitere Konfigurationen unter /usr/local/etc/logrotate.d/ ein. In diesem Verzeichnis sollte je Dienst eine eigene Konfigurationsdatei erstellt werden. Konfigurationen für die üblichen Dienste wie php-fpm, nginx, usw. sind dort bereits hinterlegt und aktiv. Am Beispiel von nginx ergibt sich durch Vererbung aus /usr/local/etc/logrotate.conf

daily
rotate 7
create
compress
include /usr/local/etc/logrotate.d

und /usr/local/etc/logrotate.d/nginx.conf

/var/log/nginx/*.log {
  missingok
  notifempty
  copytruncate
}

Sofern die Bedeutung  aus den Namen der Konfigurationsparameter nicht ersichtlich ist, verweisen wir hier auf die logrotate Manpage.

Aktiviert wird logrotate durch einen cronjob in der crontab des Benutzers root:

sudo crontab -e -u root
5 0 * * * /usr/local/sbin/logrotate /usr/local/etc/logrotate.conf > /dev/null 2>&1

newsyslog

Alternativ zu logrotate kann auch newsyslog genutzt werden. Hier ist die Konfiguration am Beispiel des nginx-Logfiles erklärt.

Die Konfigurationsdateien werden im Verzeichnis /usr/local/etc/newsyslog.conf.d abgelegt. Auch hier sollte je Dienst eine eigene Konfigurationsdatei erstellt werden. Falls das Verzeichnis noch nicht besteht, muss es angelegt werden:

mkdir -p /usr/local/etc/newsyslog.conf.d

Die Konfigurationsdatei für nginx sieht beispielsweise so aus:

/var/log/nginx-access.log               644  7     *    @T00  JC    /var/run/nginx.pid
/var/log/nginx-error.log                644  7     *    @T00  JC    /var/run/nginx.pid

/usr/local/etc/newsyslog.conf.d/nginx

Beschreibung der Spalten:

/var/log/nginx-access.log

6447*@T00 JC/var/run/nginx.pid
Die zu rotierende QuelldateiBerechtigungen für ZieldateienWie viele Dateien behalten werden sollenGröße der Datei, ab der rotiert wird. (Unabhängig von der Größe rotieren) Wann soll die Rotation stattfinden (Hier: Täglich 0:00)Flags
J = komprimieren
C = Datei neu erstellen
Pfad zur Pid für Signals nach der Rotation



Eine detaillierte Beschreibung der newsyslog Konfiguration findet sich in der newsyslog Manpage.

Das initiale Passwort für den root-Benutzer der Datenbank befindet sich in der Datei /usr/local/etc/mysql-password auf dem proServer. Die Datei kann nur von root gelesen werden.

sudo cat /usr/local/etc/mysql-password

Mit diesem Login können beliebige eigene Benutzer und Datenbanken angelegt werden.

Die Konfiguration für den Webserver Nginx befindet sich in zwei Dateien.

/usr/local/etc/nginx/nginx.conf
/usr/local/etc/nginx/vhosts/default.conf

In der nginx.conf wird die default.conf inkludiert. Hier können auch noch weitere Dateien eingefügt werden.

Direkte Änderungen an dem vHost werden hingegen in der default.conf vorgenommen.

Nach jeder Änderung an der Nginx Konfiguration muss zumindest ein reload durchgeführt werden. Wenn dieser nicht ausreicht muss ein restart gemacht werden.

Nachfolgend finden sich die gängigsten Steuerbefehle für den Nginx-Service:

sudo service nginx start|stop|restart|reload|configtest|status

Bei https-Verbindungen ist das Aushandeln der SSL-Session-Parameter relativ aufwändig. Innerhalb eines einzelnen Workerthreads werden diese Parameter wiederverwendet, aber mehrere parallele Anfragen eines Browsers landen wahrscheinlich auf unterschiedlichen Workern. Durch einen SSL-Session-Cache kann man die Session-Parameter zwischen Workern teilen.

Der SSL-Session-Cache ist ab 29.05.2018 im Auslieferungszustand eines neu bestellten proServers sowohl für Nginx als auch für Apache aktiviert. Für ältere proServer kann die Konfiguration wie folgt angepasst werden.

Nginx

In der Zeile

ssl_session_cache shared:SSLvpro<VPRO_NUMMER>:5m;

den Platzhalter <VPRO_NUMMER> durch die entsprechende proServer-Nummer ersetzen und der Konfiguration /usr/local/etc/vhosts/ssl.conf hinzufügen:

server {
  listen 443 ssl default_server;
  listen [::]:443 ssl default_server;

  server_name vpro001.proserver.punkt.de;

  ssl_certificate /usr/local/etc/ssl/certs/vpro001.proserver.punkt.de/fullchain.pem;
  ssl_certificate_key /usr/local/etc/ssl/certs/vpro001.proserver.punkt.de/privkey.pem;
  ssl_session_cache shared:SSLvpro001:5m;
  ...
}

Anschließend Nginx neustarten:

sudo service nginx restart

Weitere Informationen finden Sie in der Nginx-Dokumentation.

Apache 2.4

Die Zeilen

SSLSessionCache "shmcb:/var/run/ssl_scache(5120000)"
SSLSessionCacheTimeout 300

der Konfiguration /usr/local/etc/apache24/modules.d/090_mod_socache_shmcb.conf hinzufügen:

LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so

SSLSessionCache "shmcb:/var/run/ssl_scache(5120000)"
SSLSessionCacheTimeout 300

Anschließend Apache 2.4 neustarten:

service apache24 restart

Weitere Informationen finde Sie in der Apache-Module-mod_ssl-Dokumentation.

!!! Wir empfehlen dringend anstelle von FTP SFTP zu verwenden. Für SFTP sind keine Änderungen an der Konfig notwendig, da dieses Protokoll via SSH und dem bereits hinterlegten Key funktioniert !!!

In der Datei /etc/rc.conf muss folgende Zeile ergänzt werden:

inetd_enable="YES"

Anschließend muss noch in der Konfigdatei des inetd FTP aktiviert werden. Dazu editiert man folgende Zeilen in /etc/inetd.conf :

Vorher:
#ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l
#ftp     stream  tcp6    nowait  root    /usr/libexec/ftpd       ftpd -l

Nachher:
ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -ll
ftp     stream  tcp6    nowait  root    /usr/libexec/ftpd       ftpd -ll

Nun kann man inetd starten:

sudo service inetd start

Abschließend kann man sich nun einen User anlegen der zwingend ein Passwort benötigt um per FTP auf den Server zugreifen zu können.

sudo adduser <username>

Um auch auf Daten außerhalb des Homeverzeichnisses zugreifen zu können muss der User noch in diese entsprechende Gruppe des jeweiligen Besitzers in der /etc/groups eingetragen werden.

Erstellen bzw. Editieren der Datei /etc/rc.local und die entsprechenden Kommandos hinzufügen. Ein Beispiel unter Verwendung des Editors vim.

sudo vim /etc/rc.local

Nach einem Reboot sollen der Redis-Cache geleert und der Neos-Node-Index erstellt werden:

/usr/local/bin/redis-cli flushall
sudo -u proserver FLOW_CONTEXT=Production/Live php /var/www/neos/flow nodeindex:build --workspace live

Dabei ist zu beachten, dass die Pfade zu den ausführbaren Programmen absolut angegeben werden.

Warum ist das notwendig?

Einige Anwendungen funktionieren nach einem Reboot nicht vollständig. Oft liegt die Ursache dafür in invalidem Cache-Inhalt. Welche Caches es zu leeren gilt, ist natürlich anwendungsspezifisch.

Reboots sind beispielsweise im Rahmen der punkt.de infrastructure-Patch-Days notwendig, um aktualisierte System-Pakete zur Verfügung zu stellen.

Die primäre Konfigurationsdatei ist /usr/local/etc/php.ini. Diese wird bei der Erstprovisionierung des proServers vorbelegt und zieht zur Konfiguration von php-Modulen zusätzlich die Dateien im Verzeichnis /usr/local/etc/php/ an, und zwar in der Reihenfolge der Dateinamen. Durch geeignete Wahl der Dateinamen in diesem Verzeichnis kann also eine Reihenfolge erzwungen werden. Auch hier wird bei der Erstprovisionierung eine Reihe von Standardwerten vorbelegt.

Um eigene Konfigurationen von Systemvorgaben unterscheiden zu können, empfehlen wir eigene Konfigurationswerte z.B. in /usr/local/etc/php/zzz-99-override.ini abzulegen.

Die ebenfalls vorhandenen Konfigdateien php.ini-production und php.ini-development werden vom php-Paket bei der Installation angelegt und enthalten Beispielwerte zur Ansicht; eine technische Funktion haben diese Dateien nicht.

php-fpm ist ein "PHP FastCGI Process Manager", also ein Programm, welches darauf wartet, dass ein Webserver ein php-skript über die CGI-Schnittstelle starten will. php-fpm leitet diese Anfrage an einen bereits bereitstehenden php-Prozess (der auch php-fpm heisst) weiter oder startet im Bedarfsfall einen neuen.

Die Konfigurationseinstellungen dafür befinden sich in /usr/local/etc/php-fpm.conf, welche zusätzlich alle .conf-Dateien unter /usr/local/etc/php-fpm.d einbindet. In der Hauptkonfigurationsdatei befinden sich Parameter, die üblicherweise nicht angefasst werden müssen. An zusätzlichen Konfigs ist in php-fpm.d die Datei www.conf vorinstalliert. Zu beiden Dateien gibt es auch eine Beispieldatei mit der Endung .conf.default, diese Dateien haben keine technische Funktion.

Ein Service wird aktiviert, indem die entsprechende Zeile in der Datei /etc/rc.conf hinzugefügt wird:

solr_enable=YES

Damit ist ebenfalls garanitiert, dass der Service bei einem Neustart des Systems gestartet wird.

Mit dem service-Kommando kann der Service gestarted und gestoppt werden:

sudo service solr start
sudo service solr stop
sudo service solr restart

Die verfügbaren Services lassen sich mit

service -l

ausgeben.

pkg info -E <Paketname>

gibt den Paketnamen inklusive der installierten Version aus.

Eine ausführlichere Paketbeschreibung erhält man mit

pkg info <Paketname>

Die Liste aller installierten Pakete inklusive Version erhält man mit

pkg info

Ja, ein proServer kann in den Auslieferungszustand versetzt werden - mit einer Einschränkung: Wir entwicklen die proServer-Plattform fortwährend weiter. Es ist daher möglich, dass sich an den ausgelieferten Basis-Konfigurationen Änderungen ergeben haben.