Chrome hat von Zeit zu Zeit die Angewohnheit, das Layout (auch “UI”) beim Start einfach mal so mit abgerundeten Ecken darzustellen. Wem das auch garnicht gefällt, der kann diese Einstellung einfach aufheben.
In Chrome in die URL Zeile folgende Adresse eingeben:
chrome://flags/#top-chrome-md
Dort den ersten Eintrag “UI Layout for the browser’s top chrome” auf “Normal” stellen und unten rechts auf “Relaunch now” klicken. Fertig.
Wenn beim Ausführen des Befehles
docker-compose up
dir folgende Fehlermeldung angezeigt wird, …
ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
… dann können Sie von einem Fehler (Bug) in der Software von docker-composer betroffen sein. Durch den Fehler wird das Format (Version 3.1) nicht als richtig anerkannt.
Prüfen Sie, welche Version auf Ihrem System installiert ist:
docker-compose --version
docker-compose version 1.8.0, build unknown
Installieren Sie eine aktuelle Version von docker-compose. Finden und löschen Sie dafür die aktuelle Version:
which docker-compose
/usr/bin/docker-compose
rm /usr/bin/docker-compose
Laden Sie die für Ihr System passende Version neu herunter …
curl -L https://github.com/docker/compose/releases/download/1.20.0/docker-compose-`uname -s`-`uname -m` -o /usr/bin/docker-compose
… und erlauben Sie die Ausführung:
chmod +x /usr/bin/docker-compose
Überprüfen Sie die Version:
docker-compose --version
docker-compose version 1.20.0, build ca8d3c6
Jetzt sollte docker-compose die Datei verarbeiten können.
In der Dokumentation von “ORS” (“openrouteservice”) finden Sie folgende “Anleitung” zur Installation:
cd docker && docker-compose up
Wenn Sie während der Ausführung den folgenden Fehler erhalten, kann Ihnen dieser Artikel vielleicht helfen:
Step 6/11 : COPY .git /ors-core/.git ERROR: Service 'ors-build' failed to build: COPY failed: stat /var/lib/docker/tmp/docker-builder.../.git: no such file or directory
Ursache ist (wie die Fehlermeldung besagt) das fehlende “.git” Verzeichnis. Dieses kann dadurch natürlich auch nicht kopiert werden.
Bitte prüfen Sie, ob Sie auf Basis einer heruntergeladenen Archives (meist als ZIP Datei) arbeiten, oder ob Sie den Quellcode per GIT ausgecheckt/geclont haben:
Archiv-Version = Sie haben auf der Webseite (https://github.com/GIScience/openrouteservice) im Bereich “Code” diesen durch die grüne Schaltfläche “cline or download” heruntergeladen.
GIT Version: Sie haben den Source per GIT vom Server heruntergeladen.
Dieser Fehler tritt zumeist bei den Archiv-Versionen auf und kann durch das Auschecken per GIT auf der Kommandozeile beheben. Wenn Sie “git” bereits installiert haben, überspringen Sie die ersten Befehl bitte:
apt-get install git
Den Sourcecode auschecken/clonen:
git clone https://github.com/GIScience/openrouteservice
Anschließend in das Docker Verzeichnis wechseln:
cd openrouteservice cd docker
Dort dann den o.a. Befehl aus der Dokumentation nochmals versuchen zu starten:
docker-compose up
Um durch einen Befehl auf Kommandozeilenebene automatisch mehrere Archive (rar, zip, tar, …) entpacken zu lassen, können Sie folgenden Befehl nutzen:
for i in archive.*.part1.rar; do unrar e "$i"; done
Für die entsprechenden Archivformate passen Sie den Befehl bitte entsprechend an.
Mozilla Thunderbird setzt vor die Signatur am Ende einer eigenen E-Mail meist zwei Bindestriche (“–“):
-- Hier steht die Signatur
Um die Trennstriche zu entfernen, folgen Sie diesen Schritten:
Netbeans ist bei der Dateiverarbeitung und dem Committen von Source (insbesondere bei SVN) auffällig langsam ?
Dann hilft meist eine Deaktivierung des “DeepStatusRefresh” über Kommandozeilen-Parameter:
"C:\Program Files\NetBeans 8.2\bin\netbeans64.exe" -J-Dnetbeans.subversion.commit.deepStatusRefresh=false
Dadurch wird der Datenaustausch mit dem SVN Repository reduziert und es kann schneller committed werden.
Danach Netbeans neu starten.
Wenn Ihre WebAnwendung basierend auf dem “slim framework” nach einem Umzug oder einer Installation folgenden Fehler ausgibt:
Slim Application Error stderr: Slim Application Error: stderr: Type: Error stderr: Message: Class 'Twig_Environment' not found stderr: File: /home/folder/vendor/slim/twig-view/src/Twig.php stderr: Line: 58
… dann lösen häufig folgende Schritte das Problem:
Als Ergänzung zu unserer Anleitung für das Mailprogramm Mozilla Thunderbird hier eine Anleitung für die Einrichtung von S/Mime in Microsoft Outlook.
Wenn Sie Outlook beruflich nutzen, nur E-Mails und ggf. den Kalender brauchen und Ihre Dateien auf dem Computer vertraulich bleiben sollen (wohl meist der Fall ?), dann überdenken Sie bitte auch die folgende Lösung:
Die Deinstallation von Outlook und ein Wechsel z.Bsp. zur kostenlosen Alternative Thunderbird.
Den aktuellen Grund (aus einer Liste von ähnlichen Gründen) können Sie beim BSI (Bundesamt für Sicherheit in der Informationstechnik) nachlesen:
Technische Warnung vom 13.06.2018 (TW-T18-0088) Microsoft Outlook: Mehrere Schwachstellen
Zitat:
Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Microsoft Office Produkten ausnutzen um um einen Cross-Site Scripting Angriff durchzuführen, um Code mit Benutzerprivilegien zur Ausführung zu bringen, um Sicherheitsmechanismen zu umgehen oder um vertrauliche Daten einzusehen.”
Der Hinweis für Microsoft Produkte
Microsoft ist ein Hersteller (und nicht der einzige), dessen Produktbedienung gerne von Version zu Version “anders” ist. Wir versuchen stets, die Anleitungen aktuell zu halten, aber bei Produkten wie Outlook bitten wir um Ihr Verständnis.
Im Artikel zu Thunderbird finden Sie auch eine Anleitung für den Erhalt eines Zertifikates:
Führen Sie bitte die Schritte 1 bis 3 aus, bis Sie die .p12 Datei erhalten.
Jetzt können wir mit der Einrichtung Ihres Zertifikates beginnen:
Mit “OK” können die o.a. Fenster wieder geschlossen werden.
Wenn Sie eine neue E-Mail verfassen, können Sie dort auf “Optionen” klicken.
Im dann angezeigten Bereich finden Sie (recht mittig) die Schaltfläche “Signieren”. Ist diese gelblich hervorgehoben, dann wird die aktuelle E-Mail beim Absenden mit Ihrem Zertifikat signiert.
Der versteckte Vorteil einer signierten E-Mail ist, dass der/die Empfänger der signierten E-Mail dann Ihren öffentlichen Schlüssel erhalten haben und Ihnen dadurch verschlüsselte E-Mails zusenden können.
Verschlüsselte E-Mails
Dafür ist es zwingend erforderlich, dass Sie den öffentlichen Schlüssel des/der Empfänger kennen. Am einfachsten geht das, indem diese Ihnen einfach eine signierte E-Mail zusenden.
Zum Verschlüsseln klicken Sie ebenfalls auf “Optionen” und können dann (oberhalb von “Signieren”) auf “Verschlüsseln” klicken.
Die folgende Fehlermeldung an einem Samsung TV brachte uns doch zum Lachen.
Wenn’s dann um jeden Preis gekürzt wird, kann’s auch leicht mal unverständlich (oder halt lustig) werden:
Wenn Sie versuchen per “lftp” mit SSL Verschlüsselung (TLS) auf einen “proFTPd” Server zuzugreifen, dann kann folgende Fehlermeldung auftreten:
Lese Verzeichnisinhalt aus (0) [Warte auf Antwort...]
Im Wechsel mit
Lese Verzeichnisinhalt aus (0) [Pausiere vor erneuter Verbindung]
Dabei kann “lftp” auf dem FTP Server Dateien und Verzeichnisse schreiben, denn das Basisverzeichnis wird noch angelegt … dann ist die Verbindung jedoch scheinbar unbrauchbar.
Erst ein Blick in doe proFTPd Logs (meist unter “/var/log/proftpd/”) bringen mehr Aufklärung:
Im allgemeinen Protokoll (“/var/log/proftpd/proftpd.log”) wird der Verbindungsaufbau noch bestätigt:
2018-05-17 19:18:46,272 server.example.com proftpd[12345] test.example.net (client.example.com[1.2.3.4]): FTP session opened. 2018-05-17 19:18:46,516 server.example.com proftpd[12345] test.example.net (client.example.com[1.2.3.4]): USER john-doe: Login successful.
Also scheint es ein Problem während der Verbindung zu geben. Das TLS-Protokoll (“/var/log/proftpd/tls.log”) bringt mehr Licht ins Dunkel:
2018-05-17 19:19:19,055 mod_tls/2.6[12345]: starting TLS negotiation on data connection 2018-05-17 19:19:19,325 mod_tls/2.6[12345]: client did not reuse SSL session, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter) 2018-05-17 19:19:19,325 mod_tls/2.6[12345]: unable to open data connection: TLS negotiation failed
Aha. Die bereits bestehende SSL Verbindung wird also wird nochmals benutzt. Das schmeckt dem proFTPd Server nicht.
Wenn man dem “lftp” (testweise) die SSL Verbindung untersagt, dann funktioniert der Dateiaustausch plötzlich einwandfrei. SSL wird mit dem folgenden Befehl verboten:
set ssl-allow false
Eine schnelle Lösung ist es, dem proFTPd Server diesen Zwang zu nehmen. Das wird schon in der Fehlermeldung im Protokoll bemerkt (“see the NoSessionReuseRequired TLSOptions parameter”).
Also wird in der Config des proFTPd Servers die folgende Zeile angehängt:
TLSOptions NoSessionReuseRequired
Dann der Server neu gestartet:
/etc/init.d/proftpd restart
Und jetzt läuft auch der “lftp” wieder …