Kontakt
Einfach Suchbegriff eingeben und Enter drücken
Abbrechen

Am häufigsten gestellte Fragen

Frequently Asked Questions

Neueste FAQ-Einträge

Zunächst gilt das im Artikel Wie verbinde ich mich mit einem IPv6-Only-proServer (proServer2G)? bezgl. der SSH-Verbindung geschriebene: wenn Sie IPv6-Konnektivität an Ihrem Arbeitsplatz haben, ist nichts weiter nötig - die Verbindung funktioniert wie gewohnt.

Wenn Sie lokal nur über einen Uplink mit IPv4 verfügen, lesen Sie bitte zunächst diesen Eintrag und stellen Sie sicher, dass Sie sich per Kommandozeile (Mac OS, BSD, Linux) oder Putty (Windows) erfolgreich mit dem proServer verbinden können.

Der fehlende letzte Schritt ist dann einfach. Sie stellen zunächst eine Kommandozeilen-Verbindung wie oben her (mit Jumphost), fügen aber noch ein Port-Forwarding hinzu. Dazu dienen die folgenden zusätzlichen Parameter:

ssh -L 2222:127.0.0.1:22 vproWXYZ

Auch Putty verfügt über einen Dialog, in dem Sie einer Verbindung ein Port-Forwarding hinzufügen können. Die hergestellte Kommandozeilen-Sitzung lassen Sie nun bitte einfach stehen.

Nun starten Sie z.B. FileZilla und geben als Server für die SFTP-Verbindung "localhost" an und als Port "2222" - die übrigen Parameter (Username, Schlüsseldatei) wie gewohnt.

Der einfache Aufruf von "pkg audit" schlägt fehl, weil versucht wird eine Liste der bekannten Sicherheitslücken herunterzuladen und dafür standardmässig ein Pfad benutzt wird, der hier nur read-only verfügbar ist. Diesen Pfad kann man aber beim Aufruf übersteuern.

Mit folgendem Aufruf

 pkg audit -F -f /tmp/audit.txt

wird die Datei mit den Sicherheitslücken abweichend als /tmp/audit.txt gespeichert, wobei Name und Pfad natürlich frei wählbar sind, sofern das Zielverzeichnis existiert und beschreibbar ist.

Der Parameter -F bewirkt, das eine ggf. schon vorhandene Datei ignoriert und die Liste neu geholt wird; sinnvollerweise wirft man die Datei dann nach Gebrauch auch weg.

Sofern IPv6-Konnektivität besteht, kann eine Verbindung zum proServer2G direkt aufgebaut werden. Andernfalls muss der Zugriff durch einen sogenannten Jumphost getunnelt werden. Dies wird in der Praxis meist durch einen passenden Eintrag in der ~/.ssh/config-Datei des Entwicklers geregelt, ist jedoch auch manuell über entsprechende Aufrufparameter möglich. Für die folgenden Beispiele verwenden wir als Beispiel den vproWXYZ als Host und Nutzernamen.

Beispiel für ssh über Jumphost mit expliziten Parametern:

ssh -J jumping@ssh-jumphost.karlsruhe.punkt.de vproWXYZ@vproWXYZ.proserver.punkt.de

Beispiel für das Hochladen von datei.tar via Jumphost mit expliziten Parametern:

scp -o ProxyJump=jumping@ssh-jumphost.karlsruhe.punkt.de datei.tar.gz vproWXYZ@vproWXYZ.proserver.punkt.de:

In der Regel günstiger ist es, einen Eintrag wie folgt in ~/.ssh/config anzulegen:

Host vproWXYZ
      HostName vproWXYZ.proserver.punkt.de
      User vproWXYZ
      ProxyJump jumping@ssh-jumphost.karlsruhe.punkt.de

Damit reicht dann für den ssh-Zugriff ein einfaches

ssh vproWXYZ

Hintergrund

Der globale Pool an freien IPv4-Adressen, aus dem Provider bei Bedarf weitere Adressen anfordern konnten, ist seit Januar 2011 erschöpft. Der für unsere Region zuständige regionale Pool ist im September 2012 auf einen kritischen Wert geschrumpft; seit dieser Zeit kann jeder registrierte Provider noch einmalig einen Block von ca. 1000 IPv4-Adressen anfordern, weitere IPv4 Adressen sind nicht mehr verfügbar. Einige Provider die noch über unbenutzte IPv4 Adressen verfügen sind bereit diese zu verkaufen; oft wurden diese Adressen aber vorher für Spam und Verbreitung von Schadsoftware benutzt und werden vielerorts ausgefiltert.

Die meisten Internet-Anbieter stehen daher vor der Herausforderung, mit dem vorhandenen Bestand an IPv4 Adressen mehr Dienste als zuvor, also z.B. zusätzliche Websites, anzubieten. Der Ansatz der punkt.de ist es hier, Dienste weitestmöglich auf den Betrieb mit IPv6 zu verlagern, wo Adressen praktisch unbegrenzt zur Verfügung stehen. Die 2. Generation unserer proServer ist ein Ergebnis dieser Bemühungen.

Überblick des Systemaufbaus

Die vpro-Container

Dies sind wie bisher eigenständige virtuelle Maschinen mit der Funktionalität eines kompletten Betriebssystems. Jedoch verfügt die virtuelle Maschine nur noch über eine externe IPv6-Adresse und keine Legacy-IP-Adresse (IPv4-Adresse) mehr.

Die gate64-Container

Dies sind eigenständige virtuelle Maschinen, welche für jeweils mehrere vpro-Container die Verbindung mit dem Legacy-IP-Netz herstellen. Diese gate64-Container verfügen jeweils über eine IPv6- und eine IPv4-Adresse. Ausgehende Verbindungen, also solche die vom vproXXXX aus initiiert werden, sind darüber zu beliebigen Zielen im IPv4 Bereich möglich. Eingehende Verbindungen, also aus dem (IPv4-)Internet auf den vproXXXX sind nur auf den Ports 80 (HTTP) und 443 (HTTPS) möglich.

Der ssh-jumphost

Dies ist ebenfalls eine eigenständige Maschine mit je einer IPv4- und einer IPv6-Adresse. Mit diesem Host als Zwischenstation ist ein ssh/scp-Zugriff auf den vproXXXX auch für diejenigen Entwickler möglich, die nur IPv4 Zugriff auf das Internet haben.

Was sich für den Admin/Entwickler ändert

DNS-Einträge

Jedem vproXXXX-Container ist ein "zuständiger" gate64-Container zugeordnet. Die IPv4-Adresse dieses gate64-Containers teilen wir Ihnen beim Einrichten eines vpro-Containers mit. Für die auf dem vpro gehosteten Websites tragen Sie im DNS jeweils einen AAAA-Record mit der IPv6-Adresse des vproXXXX und einen A-Record mit der IPv4-Adresse des zugeordneten gate64-Containers ein.

Achtung: Im Unterschied zur 1. Generation der proServer ist der AAAA-Record im DNS jetzt zwingend erforderlich, da der gate64-Container über diesen DNS-Eintrag erfährt, auf welchem vproXXXX sich eine darüber angesprochene Website befindet.

Zugriff vom vpro-Container auf Resourcen im IPv4-Internet

Falls der Zugriff auf die externe Resource über einen Hostnamen im DNS erfolgt, ist für den Entwickler nichts weiter zu beachten: Der auf dem vpro verwendete Nameserver liefert für Resourcen, die nur IPv4-Adressen haben eine "synthetische IPv6-Adresse" zurück, welche dann über ein sogenanntes NAT64-Gateway (auf dem zugeordneten gate64-Host) geführt und dort nach IPv4 übersetzt wird. Aus Sicht des proServers erfolgt die Kommunikation also per IPv6, die Übersetzung auf dem gate64 ist für den proServer nicht sichtbar.

Erfolgt der Zugriff über IPv4-Adressliterale (also direkt eine numerische IPv4-Adresse), so muss ein solches Literal auf die zugehörige IPv6-Adresse umgeschrieben werden. Dies geht durch das Voranstellen des Präfix 64:ff9b::/96. So würde beispielsweise aus der IPv4-Adresse 192.0.2.3 die "synthetische" IPv6-Adresse [64:ff9b::192.0.2.3], das Ergebnis wird dann wie ein IPv6 Adressliteral verwendet. Um das Zielsystem anzupingen, würde man also

ping6 64:ff9b::192.0.2.3

aufrufen.

Einschränkungen

Es gibt einige betriebliche Einschränkungen dadurch, dass aus dem IPv4-Internet eingehende Verbindungen nur über Port 80 und 443 (sowie 22/ssh via Jumphost) möglich sind.

  • Websites können nur auf port 80 (HTTP) und 443 (HTTPS) liegen. Diese Einschränkung gilt nicht für interne Adressen auf dem vpro oder private Verbindungsstrecken zwischen mehreren vpro-Containern, und natürlich auch nicht für Verbindungen über IPv6.
  • Mailversand vom vpro ist möglich, zu IPv4-Zielen erfolgt er über das NAT64 Gateway. Mailempfang aus dem Internet geht auf dem vpro aber nur per IPv6 oder über einen vorgelagerten Dual-Stack Mailserver.

Falls diese Einschränkungen ein Problem für Ihre Anwendung darstellen, sprechen Sie uns bitte an. Gemeinsam werden wir eine Lösung finden.

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.

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.

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.

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.

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.

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.

Suche filtern