Falls ddclient nicht mehr die IP-Adresse mit dem entsprechenden DynDNS-Anbieter abgleicht, kann das Stoppen des Dienstes und der Neustart mit der Option –force eventuell helfen:
|
1 2 |
sudo /etc/init.d/ddclient stop sudo ddclient --force |
Siehe hierzu auch: https://intux.de/2016/04/raspberry-pi-3-mit-dyndns/
Um die Gültigkeitsdauer eines GnuPG-Keys festzulegen bzw. zu editieren führt man folgenden Befehl aus. Die eMail-Adresse ist hier entsprechend anzupassen.
|
1 |
gpg --edit-key <span class="crayon-v">user</span><span class="crayon-sy">@</span><span class="crayon-v">domain</span><span class="crayon-sy">.</span><span class="crayon-v">tld</span> |
Dann geht es mit
|
1 |
> expire |
weiter. Im folgenden Beispiel habe ich zwei Jahre gewählt.
|
1 |
2y |
Nun wird der Key gesichert
|
1 |
> save |
und an einen Keyserver versendet, der diesen dann weiter verteilt.
|
1 |
gpg --send-key 388229E0039D66CC |
Es erscheint in meinem Fall folgende Ausgabe:
|
1 |
gpg: sende Schlüssel 388229E0039D66CC auf hkp://keys.gnupg.net |
Da sind sie wieder! Nach dem Upgrade auf Nextcloud 14 galt es auch hier wieder neu auftauchende Fehlermeldungen zu beseitigen.
Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen wird, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller.
- Fehlender Index „share_with_index“ in der Tabelle „oc_share“.
- Fehlender Index „parent_index“ in der Tabelle „oc_share“.
- Fehlender Index „fs_mtime“ in der Tabelle „oc_filecache“.
Der „Referrer-Policy“ HTTP-Header ist nicht gesetzt auf „no-referrer“, „no-referrer-when-downgrade“, „strict-origin“ oder „strict-origin-when-cross-origin“. Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.
Um die erste Fehlermeldung zu beseitigen, wurde im Virtual Host mit
|
1 |
# nano /etc/apache2/sites-available/nextcloudcloud.conf |
die vorhandene Zeile
|
1 |
Header append X-FRAME-OPTIONS "SAMEORIGIN" |
entfernt. Darunter fügt man an dieser Stelle
|
1 |
Header set Referrer-Policy "no-referrer-when-downgrade" |
ein und auch die dritte Fehlermeldung verschwindet nach dem Neustart des Webservers.
|
1 |
# /etc/init.d/apache2 restart |
Um das Datenbank-Problem zu lösen, wechselt man ich das Hauptverzeichnis der Nextcloud
|
1 |
# cd /var/www/html/nextcloud |
und führt
|
1 |
sudo -u www-data php occ db:add-missing-indices |
aus. Die erfolgreiche Bestätigung sollte dann so aussehen:
|
1 2 3 4 5 6 7 |
Check indices of the share table. Adding additional share_with index to the share table, this can take some time... Share table updated successfully. Adding additional parent index to the share table, this can take some time... Share table updated successfully. Adding additional mtime index to the filecache table, this can take some time... Filecache table updated successfully. |
Zum Schluss sind alle Überprüfungen bestanden und die Nextcloud darf wieder produktiv genutzt werden.
Fehlermeldungen beseitigt – Alle Überprüfungen bestandenViel Spaß!
Nach einer frischen Installation von Nextcloud hat man i.d.R. mit einigen Fehlermeldungen zu kämpfen. Die Suche nach den Problemlösungen beschäftigt mich dann immer eine ganze Weile. Aus diesem Grund habe ich einfach einmal aufgeschrieben, was ich bei der letzten Installation alles noch erledigen musste.
Hier die Sicherheits- & Einrichtungswarnungen nach der Installation:
Ihr Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, Ihren Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass Sie es aus dem Document-Root-Verzeichnis des Webservers herausverschieben.
Der Zugriff auf diese Site erfolgt über HTTP. Es wird dringend geraten, den Server so zu konfigurieren, dass er stattdessen nur HTTPS akzeptiert, wie es in den Sicherheitshinweisen beschrieben ist.
Es wurde kein PHP-Memory-Cache konfiguriert. Zur Erhöhung der Leistungsfähigkeit kann ein Memory-Cache konfiguriert werden. Weitere Informationen finden Sie in der Dokumentation.
Bitte überprüfen Sie noch einmal die Installationsanleitungen und kontrollieren Sie das Protokoll auf mögliche Fehler oder Warnungen.
Der PHP-OPcache ist nicht richtig konfiguriert. Für eine bessere Leistung empfiehlt es sich folgende Einstellungen in der php.ini vorzunehmen:opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
Dem Datenverzeichnis entzieht man wie folgt die Erreichbarkeit aus dem Internet. Dazu öffnet man die /etc/apache2/apache2.conf.
|
1 |
# nano /etc/apache2/apache2.conf |
Dort verändert man den bestehenden Eintrag
|
1 2 3 4 5 |
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> |
in
|
1 2 3 4 5 |
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> |
Die Umstellung auf HTTPS wurde nach der Anleitung „Let’s Encrypt auf dem Raspberry Pi“ durchgeführt.
Den PHP-Memory-Cache richtet man ein, indem man die benötigten Pakete via
|
1 |
# apt install php-apcu |
installiert. Im Anschluss wird via
|
1 |
# nano /var/www/html/nextcloud/config/config.php |
folgende Zeile hinzugefügt:
|
1 |
'memcache.local' => '\\OC\\Memcache\\APCu', |
Um die Fehlermeldung zu PHP-OPcache zu eliminieren, öffnet man die php.ini
|
1 |
# nano /etc/php/7.0/apache2/php.ini |
und trägt Folgendes am Ende der Datei ein:
|
1 2 3 4 5 6 7 |
opcache.enable=1 opcache.enable_cli=1 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1 |
Zum Schluss wird der Apache-Webserver neu gestartet.
|
1 |
# /etc/init.d/apache2 restart |
Nun erhielt ich die nächste Fehlermeldung.
Der „Strict-Transport-Security“-HTTP-Header ist nicht auf mindestens „15552000“ Sekunden eingestellt. Für mehr Sicherheit wird das Aktivieren von HSTS empfohlen, wie es in den Sicherheitshinweisen erläutert ist.
Bitte überprüfen Sie noch einmal die Installationsanleitungen und kontrollieren Sie das Protokoll auf mögliche Fehler oder Warnungen.
Diese beseitigt man indem man das Header-Modul für den Apache2 aktiviert.
|
1 |
# a2enmod headers |
Dach trägt man in den Virtualhost der Webseite unter DocumentRoot
|
1 |
Header always set Strict-Transport-Security "max-age=15552000; preload" |
ein und startet den Webserver mit
|
1 |
# /etc/init.d/apache2 restart |
neu.
Am Ende waren alle Warnungen beseitigt und alle Tests wurden erfolgreich bestanden.
Gestern habe ich das erste Mal das offizielle 7″ Touchscreen für den Raspberry Pi verbauen dürfen. Das Ganze war recht schnell und unkompliziert bewerkstelligt (siehe Video von Maker-Tutorials.com). Für den späteren Einsatz empfehle ich hierzu das entsprechende Bundle, bestehend aus Gehäuse und Touchscreen.
Zu beachten ist dann, dass das Display per Befehl um 180° zu drehen ist, da es sonst im Gehäuse auf dem Kopf steht. Dazu wird mit
|
1 |
sudo nano /boot/config.txt |
|
1 |
lcd_rotate=2 |
an das Ende der Datei eingetragen und mit Ctrt + o gespeichert. Nach dem Verlassen des Editors mit Ctrl + x wird der Rpi rebootet.
Quelle: YouTube
Meine Empfehlungen
Viele Jahre habe habe ich mein Backend von WordPress so abgesichert, dass auffällige IP-Adressen nach drei gescheiterten Login-Versuchen für eine gewisse Zeit keinen Zugang mehr zum Verzeichnis wp-admin bekamen. Da auf meinem Server schon lange keine IP-Adressen mehr geloggt werden, ist diese Methode nicht mehr praktikabel.
Aus diesem Grund habe ich nach einer Alternative gesucht. Ganz zufrieden bin ich damit das Login-Verzeichnis via Benutzername und Passwort zu schützen. Ein weiterer Vorteil ist, dass ich ein weiteres Plugin aus meiner überladenen WordPress-Installation entfernen kann.
Zuerst wird via
|
1 |
# nano /var/www/html/wordpress/.htpasswd |
im Hauptverzeichnis der WordPress-Installation eine versteckte Datei .htpasswd angelegt.
Mit dem htpasswd Generator ist es möglich den Inhalt der .htpasswd zu erstellen. Hierbei wählt man einen Benutzernamen und ein starkes Passwort. Die entsprechende Ausgabe trägt man nun in die .htpasswd ein und spreichert mit Ctrt + o.
Nach dem Verlassen des Editors mit Ctrt + x öffnet man wiederum mit Nano
|
1 |
#nano /var/www/html/wordpress/.htaccess |
die .htaccess und fügt folgende Zeilen hinzu.
|
1 2 3 4 5 6 |
<Files wp-login.php> AuthType Basic AuthName "Mein Bereich" AuthUserFile /var/www/html/wordpress/.htpasswd Require valid-user </Files> |
Viel Spaß!
Einige VNC-Server hatte ich bereits in der Vergangenheit getestet. Dabei konnte ich keine wirklich vernünftige Lösung für die GNOME-Shell finden. Den einzigen, aus meiner Sicht zufriedenstellende Server, bietet RealVNC. Mit dieser proprietären Lösung kann man für den privaten Gebrauch mit bis zu 5 Remotecomputern über einen zuvor zu erstellenden Account verbinden.
Was unter Ubuntu auf Anhieb läuft, bereitet auf einem Debian im ersten Moment Probleme. Hier lässt sich der Rechner auf dem zuvor VNC Connect mit
|
1 |
# dpkg -i VNC-Server-6.3.1-Linux-x64.deb |
installiert wurde nur verbinden, wenn der Benutzer der Gruppe sudo zugewiesen wurde.
Dies geht wie folgt:
|
1 |
# adduser benutzer sudo |
„benutzer“ ist hierbei durch den entsprechenden Benutzernamen zu ersetzen. Die Änderung wird nach dem erneuten Anmelden bzw. einem Reboot wirksam.
Im Anschluss wird mit
|
1 |
sudo systemctl start vncserver-x11-serviced.service |
der entsprechende Service gestartet und der Rechner via
|
1 |
vnclicensewiz |
für den privaten Gebrauch lizensiert.
Nun sollte die GNOME-Shell via VNC von außen erreichbar sein.
Eine komplette Anleitung u.a. wie der VNC-Server in den Autostart des zu remotenden Systems eingetragen wird findet man hier.
Im Artikel „Prosody – inaktive User ausfindig machen“ hatte ich beschrieben, wie man nach inaktiven XMPP-Accounts in Prosody suchen kann. Eine elegante Möglichkeit diese User wieder loszuwerden zeigt Thomas Leister auf seinem Blog.
Ich habe mich für meinen XMPP-Server entschieden, Accounts welche drei Monate inaktiv waren zu löschen. Hierzu erstelle ich lt. Anleitung ein Script.
|
1 |
# prosodyctl mod_list_inactive intux.de 3month default | sed -e 's/^/prosodyctl deluser /' > delusers.sh |
Dieses wird dann im Anschluss ausgeführt.
|
1 |
# sh ./delusers.sh |
Danach sind alle inaktiven User des zuvor erwähnten Zeitraums vom drei Monaten vom Server gelöscht.
Letztes Wochenende hatte ich den ComplianceTester von Daniel Gultsch durchlaufen lassen und gesehen, dass enige XMPP-Erweiterungen (XEP) nicht aktiviert waren. Die größten Probleme hatte ich bei der Suche nach einer Lösung zur Aktivierung von XEP-0368. Schlußendlich half mir die Anleitung von Dominion auf adminforge.de.
Hier meine Änderungen am XMPP-Server intux.de:
Zuerst wurde sslh installiert.
|
1 |
# apt install sslh |
An dieser Stelle wurde ein „eigenständiger Server“ ausgewählt.
Dann musste die Datei /etc/apache2/ports.conf (Apache2) mit
|
1 |
# nano /etc/apache2/ports.conf |
von
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default.conf Listen 80 <IfModule ssl_module> Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule> # vim: syntax=apache ts=4 sw=4 sts=4 sr noet |
in
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default.conf Listen 80 <IfModule ssl_module> Listen 127.0.0.1:443 </IfModule> <IfModule mod_gnutls.c> Listen 127.0.0.1:443 </IfModule> # vim: syntax=apache ts=4 sw=4 sts=4 sr noet |
geändert werden. Im Anschluss wurde in die /etc/prosody/prosody.cfg.lua (Prosody) mit
|
1 |
# nano /etc/prosody/prosody.cfg.lua |
die Zeile
|
1 |
legacy_ssl_ports = 5223 |
eingefügt. In der /etc/default/sslh musste via
|
1 |
# nano /etc/default/sslh |
|
1 |
RUN=yes |
gesetzt werden. Die vorhandene DEAMON_OPTS kommentierte ich aus und fügte
|
1 |
DAEMON_OPTS="-F /etc/sslh/sslh.cfg" |
|
1 |
# mkdir /etc/sslh/ |
|
1 |
# nano /etc/sslh/sslh.cfg |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
verbose: false; foreground: false; inetd: false; numeric: false; transparent: false; timeout: 2; user: "nobody"; pidfile: "/run/sslh/sslh.pid"; # Change hostname with your external address name. Note: It should not be resolving to 127.0.0.1 listen: ( { host: "intux.de"; port: "443"; } ); protocols: ( { name: "tls"; host: "localhost"; port: "5223"; alpn_protocols: [ "xmpp-client" ]; log_level: 0;}, # catch anything else TLS { name: "tls"; host: "localhost"; port: "443";}, { name: "xmpp"; host: "localhost"; port: "5222"; }, { name: "timeout"; host: "localhost"; port: "443";} ); on-timeout: "timeout"; |
erstellt. Die Dienste Prosody, Apache2 und sslh wurden im Anschluss neu gestartet.
|
1 2 3 |
# /etc/init.d/prosody restart # /etc/init.d/apache2 restart # /etc/init.d/sslh restart |
Ob die IPs und Ports richtig konfiguriert sind, zeigte die Ausgabe von:
|
1 |
# netstat -ntpl | grep -E "5223|443" |
|
1 2 3 4 5 |
tcp 0 0 5.xx.xx.xx:443 0.0.0.0:* LISTEN 12146/sslh tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 12085/apache2 tcp 0 0 0.0.0.0:5223 0.0.0.0:* LISTEN 11409/lua5.1 tcp6 0 0 2a00:xxxx:xxx::xxxx:443 :::* LISTEN 12146/sslh tcp6 0 0 :::5223 :::* LISTEN 11409/lua5.1 |
Die Records für den XMPP-Server wurden wie folgt gesetzt.
Abschließend konnte ich via openssl erfolgreich die HTTPS-Vervindung testen.
|
1 |
# openssl s_client -connect intux.de:443 -alpn xmpp-client -servername intux.de |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 |
CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = intux.de verify return:1 --- Certificate chain 0 s:/CN=intux.de i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIHXzCCBkegAwIBAgISA/3nFQfXmCGAv8A/U84FWqEJMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA0MDYwNTI4MDBaFw0x ODA3MDUwNTI4MDBaMBMxETAPBgNVBAMTCGludHV4LmRlMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEAo2kSw/AdaY0qs9NFs2LwM9F4dpr3Ne755oyT6zfz w6vAsfYfyaOztuhjWKGChcw6xDYHUXjPhJNiO3VbMcaEFrtT+tHeX42DjDWKQEjY b8fb7n0lkgWP2nOUeEiSMdbUn6VOuptv9UEA5cxxxHs4mTTkqouXhAZ0oe1WWmfi QbeKYb2TANxeyGp/KfRvvDhlF/M2I889PR+Fy+jjbbdaffY3mD+Az4dFBZWVj1/g yyup8DoMTiCzOC8DDGOp3IuP05Ner8M8HB1YpvcrQVeApQYF8adkRA/v8yxVXHBk ToQ+8gwZMHCsd7kYCepHA7wyKRabhFWqWw5rCMvFNjGNtUa3qQaKGhnPC+ICEEMy IGFztXbsCS4ethH/oWcM5nU5UoCFflYxEQ17J7KGc6ozKXtcP6lEuvrpEaXaWBaD lbt+uYs1l+9SZXokW16edywvYzPeTkUSG7rKDg1fLkqDH5upfT3wUV9T99WwfEid 8sCnNtQzcMGkz4dzC86TMZD2Py4ijrOyIotJ32hb7eFOWKAXuplPjpNs26q3t7vj 8LKe9OBTTFy9vOBFa/6UWnZjhIoo8ppzEugzK8O8pEGxeZGcjJ6Yiq0oddCkpfXk SEIiXEeuU1at7BMGRvBpMJwdAtEe030nzFpRlVN0hon6XjDte05wS6imJHxxndNc z/kCAwEAAaOCA3QwggNwMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEF BQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU6USFs8mAjkF+ Bh1szN+E3JnbmfowHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEwbwYI KwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMubGV0 c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0 c2VuY3J5cHQub3JnLzB2BgNVHREEbzBtgg5jbG91ZC5pbnR1eC5kZYITY29uZmVy ZW5jZS5pbnR1eC5kZYIIaW50dXguZGWCDW1haWwuaW50dXguZGWCDnNlYXJ4Lmlu dHV4LmRlgg91cGxvYWQuaW50dXguZGWCDHd3dy5pbnR1eC5kZTCB/gYDVR0gBIH2 MIHzMAgGBmeBDAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEWGmh0 dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1RoaXMg Q2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWluZyBQ YXJ0aWVzIGFuZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlmaWNh dGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3JlcG9z aXRvcnkvMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcA23Sv7ssp7LH+yj5xbSzl uaq7NveEcYPHXZ1PN7Yfv2QAAAFimaPvigAABAMASDBGAiEA16BKSa9tudwOJ9NX bx2a6vKoAI3bVZ4aWvBqwD0SsdECIQDkjrZyazuCnFvNt/1UE/1SnxjY2C+U73kL 5D6LfDQG2gB2ACk8UZZUyDlluqpQ/FgH1Ldvv1h6KXLcpMMM9OVFR/R4AAABYpmj 76oAAAQDAEcwRQIgLNwhpz6m5VZz3doI6jJzHTN7qnGuj65eP7XoNVSpg5ACIQDj W9GmRaMUoTxy7WHIuNpwFkJpiYRVUQtMyYkumbhb4zANBgkqhkiG9w0BAQsFAAOC AQEAjJaamX5zMXkTJvaMgFogI0R9oZdaPTOWO9Nfjuc0b1mwcjLg2XWu2La4/WZm NmG3OjL+t6B4ZQxefQrVDat92hAGMyibJRa9xSOnzlx371y/RZckSOeQ9/JDV2Lq R/kubgEmFVVR65H9ubve2C6X9tgTppHXT265ExIe3NRf4ELkw1jmr0WCFQXUeFZj jYU4neTzcbJBV4ot5Qe5CznFJA8+oh9cBLrOo6xCFX5Z4kHWQ6T3btBfW2PGb7pN JOxTtS94WPt8NNlGOPPQ8zYaCOiLdN1r72q0wqv7FuOyQqT2abVYoWa9ylcFU5ru V8amsVkC1fzRgH65uV0aVtWVDA== -----END CERTIFICATE----- subject=/CN=intux.de issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Peer signing digest: SHA512 Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 3882 bytes and written 381 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: 91CC65F416FF7EA20324BC3EEDFB4D5DBBC8C8B937617649D630C565E6E3D74053A069CFAFE24B63F914AB00DA4FF1D1 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1528364693 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes --- |
Der Status zum XMPP-Server intux.de kann man hier abfragen.
Wenn man ein Betriebssystem in der VirtualBox von Oracle testet, möchte man auch in der Lage sein Code oder Text vom Hostsystem in die Virtualisierung zu kopieren. Von Haus aus geht das ohne eine entsprechende Konfiguration nicht. Dazu ist es nötig die Gasterweiterung auf dem Hostsystem zu installieren. Ist dies erledigt, kann man nachdem man ein paar Einstellungen vorgenommen hat die Virtualisierung starten. In meinem Fall ist ein Ubuntu 18.04 LTS schon vorinstalliert.
Vor dem Start des Systems wird über Ändern => Erweitert die gemeinsame Zwischenablage und Drag’n’Drop auf bidirektional gesetzt. Somit wird das Kopieren später in beide Richtungen möglich.
Nun wird in der Virtualisierung wie auf dem Screenshot zu sehen, die Gasterweiterung ins System Geräte => Gasterweiterung einlegen geladen.
Jetzt öffnet man mit Ctrl+Alt+t das Terminal in Ubuntu 18.04 und wechselt dort in das entsprechende Verzeichnis. In meinem konkreten Beispiel wäre das das Verzeichnis /media/intux/VBox_GAs_5.2.8.
|
1 |
cd /media/intux/VBox_GAs_5.2.8 |
Hier ist jedoch entsprechend des eigenem Systems der Benutzer und die gewählte Version der Gasterweiterung anzupassen. Danach wird die Datei VBoxLinuxAdditions.run wie folgt ausgeführt und installiert.
|
1 |
sudo sh ./VBoxLinuxAdditions.run |
Ist dies geschehen, kann man nun Texte vom Hostsystem in die Virtualisierung kopieren. Dies geht natürlich auch in die andere Richtung.
Viel Spaß!
