ubuntuusers.de

14. Oktober 2017

Ich habe vor kurzem meine Mutt Konfiguration mit euch geteilt. Inzwischen hat sich hier ein paar Kleinigkeiten geändert, und auch ein kleiner Fehler hatte sich in die Konfiguration eingeschlichen.

Fehler

Ich hatte in der muttrc folgenden Eintrag stehen

set record=+Sent                     # Gesendet Ordner

Diese Eintrag muss jedoch bei einer Multi-Account nicht in die muttrc sondern direkt in die Accountkonfiguration:

set from=mail@example2.org
set hostname="example2.org"
set folder="imaps://imap.example2.org"
set postponed="=Drafts"
set spoolfile="imaps://imap.example2.org/INBOX"
set smtp_url="smtp://$imap_user:$imap_pass@smtp.example2.org"
set imap_user="USERNAME"
set imap_pass="PASSWORD"
set record=+Sent

Sonst kommt es dazu, dass er versucht von jedem anderen Account die E-Mails im primären Account im Ordner gesendet unterzubringen, was natürlich nicht Sinn und Zeck ist, bzw. zu Fehlern führen kann, weil es natürlich andere Logindaten sind.

Änderungen

Die Änderungen sind nur minimal und betreffen eigentlich nur die mailcap Datei, wo ich inzwischen andere Programme nutze, deren Fingerabdruck im System noch geringer ist:

message/rfc822; less %s; edit=${EDITOR-vi} %s; compose=${EDITOR-vi} %s; needsterminal;
text/html; w3m -I %{charset} -T text/html; copiousoutput;
image/*; sxiv %s &>/dev/null
video/*; mpv %s
audio/*; mpv %s
text/*; vim %s
application/pdf; apvlv %s 
application/odt; libreoffice %s
application/ods; libreoffice %s
application/msword; libreoffice %s
application/vnd.oasis.opendocument.text; libreoffice %s
application/vnd.openxmlformats-officedocument.wordprocessingml.document; libreoffice %s &>/dev/nul

So ersetzt inzwischen apvlv den vorherigen genutzten PDF Viewer atril. vim ist inzwischen für das anzeigen für Texte verantwortlich. So bald ich weitere Änderungen habe, werden diese im Orginalbeitrag, sowie jetzt mit einem zusätzlichen Beitrag vermerken.

Wie ich gerade durch die Mailing-Liste der lokalen LUG erfahren habe, findet am 19.10.17 ab 12 Uhr ein Hackathon in der iisys Hochschule in Hof (Oberfranken) statt.

Programmpunkte sind unter anderem Webanwendungen mit LivingApps erstellen und Bewässerung von Topfpflanzen. Wer Interesse hat, findet unter https://www.livinglogic.de/hackathon noch ein paar (aber wirklich nur ein paar) weitere Informationen und die Möglichkeit sich anzumelden.

Kann sein, dass ich dort auch mal vorbeischaue wenn ich mich aufraffen kann nach Hof zu fahren. Liegt ja nicht gerade direkt um’s Eck.

Ich habe vor kurzem meine Mutt Konfiguration mit euch geteilt. Inzwischen hat sich hier ein paar Kleinigkeiten geändert, und auch ein kleiner Fehler hatte sich in die Konfiguration eingeschlichen.

Fehler

Ich hatte in der muttrc folgenden Eintrag stehen

set record=+Sent					 # Gesendet Ordner

Diese Eintrag muss jedoch bei einer Multi-Account nicht in die muttrc sondern direkt in die Accountkonfiguration:

set from=mail@example2.org
set hostname="example2.org"
set folder="imaps://imap.example2.org"
set postponed="=Drafts"
set spoolfile="imaps://imap.example2.org/INBOX"
set smtp_url="smtp://$imap_user:$imap_pass@smtp.example2.org"
set imap_user="USERNAME"
set imap_pass="PASSWORD"
set record=+Sent

Sonst kommt es dazu, dass er versucht von jedem anderen Account die E-Mails im primären Account im Ordner gesendet unterzubringen, was natürlich nicht Sinn und Zeck ist, bzw. zu Fehlern führen kann, weil es natürlich andere Logindaten sind.

Änderungen

Die Änderungen sind nur minimal und betreffen eigentlich nur die mailcap Datei, wo ich inzwischen andere Programme nutze, deren Fingerabdruck im System noch geringer ist:

message/rfc822; less %s; edit=${EDITOR-vi} %s; compose=${EDITOR-vi} %s; needsterminal;
text/html; w3m -I %{charset} -T text/html; copiousoutput;
image/*; sxiv %s &>/dev/null
video/*; mpv %s
audio/*; mpv %s
text/*; vim %s
application/pdf; apvlv %s 
application/odt; libreoffice %s
application/ods; libreoffice %s
application/msword; libreoffice %s
application/vnd.oasis.opendocument.text; libreoffice %s
application/vnd.openxmlformats-officedocument.wordprocessingml.document; libreoffice %s &>/dev/nul

So ersetzt inzwischen apvlv den vorherigen genutzten PDF Viewer atril. vim ist inzwischen für das anzeigen für Texte verantwortlich. So bald ich weitere Änderungen habe, werden diese im Orginalbeitrag, sowie jetzt mit einem zusätzlichen Beitrag vermerken.

12. Oktober 2017

Vor wenigen Tagen wurde PostgreSQL 10 veröffentlicht. Das Hauptaugenmerk der neuen Version liegt auf logischer Replikation, parallelen Queries und Stabilität bzw. Sicherheit.

postgres_logo

Die Neuerungen

Letzteres macht sich durch die Verabschiedung der veralteten MD5 Authentifizierung bemerkbar. Ab sofort kommt SCRAM-SHA-256 zum Einsatz.

Die Einführung der logischen Replikation verspricht schnelleres Übertragen inkrementeller Änderungen auf andere Nodes. Hier findet sich ein Beispiel zur Anwendung dieses neuen Feature.

Für die synchrone Replikation wurden Quorom Commits eingeführt. Diese, im Rahmen des "Zero Downtime" Plans, eingeführte Funktion erlaubt es dem Admin festzulegen wie viele Replikas erfolgreiche Änderungen melden müssen, damit übertragene Daten als sicher gelten.

Die mit PostgreSQL 9.6 vorgestellen parallelen Queries wurden weiter verbessert. So unterstützen nun Daten Scans wie Index Scans oder Merge Joins diese Funktion.

Die Datenbank Partitionierung wurde ebenfalls erweitert.

Weitere Details lassen sich der PostgreSQL 10 Release Ankündigung entnehmen. Änderungen im Detail sind im Wiki zu finden


Installation PostgreSQL 10 unter Ubuntu 16.04 LTS

Zwar hatte ich die Installation der Beta schon in einen Artikel gepackt
möchte aber dennoch schnell das Vorgehen darlegen.

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main" >> /etc/apt/sources.list.d/pgdg.list' 

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
 sudo apt-key add -
      
sudo apt update

sudo apt install postgresql-10


 



Das könnte dich auch interessieren

PostgreSQL 9.6, pgAdmin 4 und Barman 2.0 - Die Neuerungen und Installation unter Ubuntu 14.04 und 16.04

pgAdmin4 - Installation und ein erster Blick auf die neue PostgreSQL Schaltzentrale

PGCenter - PostgreSQL Datenbank Statistiken und Leistungsdaten auf einen Blick

22 praktische PostgreSQL Befehle

Praktische PostgreSQL Tools und Links in der Übersicht

pgBadger 4.0 - PostgreSQL Logs analysieren und auswerten

PgTune - Performance Einstellungen für PostgreSQL Datenbanken automatisch erstellen

11. Oktober 2017

Mozilla hat Firefox 56 veröffentlicht – es handelt sich dabei um die letzte Version vor Firefox Quantum im November, dem größten Release in der Geschichte von Firefox. In der Zwischenzeit bringt Firefox 56 ein paar weitere nennenswerte Verbesserungen.

Download Mozilla Firefox 56.0 für Microsoft Windows, Apple macOS und Linux

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 56 hat Mozilla wieder zahlreiche Sicherheitslücken geschlossen, worunter auch einige sind, welche von Mozilla als besonders kritisch eingestuft werden. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 56 daher für alle Nutzer dringend empfohlen.

WebExtensions laufen in einem eigenen Prozess

Mit Firefox 56 führt Mozilla eine weitere Verbesserung der Multiprozess-Architektur ein, zumindest für Nutzer von Windows. Dort laufen WebExtensions ab sofort in einem eigenen Prozess und nicht mehr im gleichen Prozess wie Webseiten oder die Browseroberfläche selbst. Neben mehr Sicherheit bringt dies auch nicht mehr den gesamten Browser zum Absturz, wenn eine Erweiterung abstürzt. Linux und macOS werden in einem der nächsten Firefox-Updates nachziehen.

Ebenfalls werden ab Firefox 56 Links in einem neuen Prozess geöffnet, welche ein rel=“noopener“-Attribut besitzen.

Kleinere und sichere Updates

Mozilla hat die Download-Größe der Firefox-Updates durch LZMA-Kompression um ca. 20 Prozent reduziert. Dazu wurde die Sicherheit bei der Verifizierung der Update-Pakete verbessert.

Verbesserte AES-GCM-Performance

Mozilla hat den AES-GCM-Algorithmus für verschlüsselte Verbindungen dadurch beschleunigt, dass dieser nun die Harware nutzen kann. Dadurch wird weniger CPU-Last erzeugt, die Ver- und Entschlüsselung erfolgt wesentlich performanter und auch die Download-Rate kann sich dadurch verbessert zeigen.

Neue Struktur plus Suchfunktion für Einstellungen

Mozilla hat die Einstellungsoberfläche von Firefox 56 überarbeitet. Diese ist, basierend auf dem Feedback von Nutzern, neu strukturiert worden und bietet außerdem ab sofort eine Suchfunktion. Auch die Update-Funktion wurde zusätzlich zur bisherigen Position im Info-Dialog in die Einstellungen integriert.

Firefox 56

Firefox Screenshots: Bildschirmfotos aufnehmen

Firefox Screenshots, ursprünglich unter dem Namen Page Shot ein Experiment im Rahmen von Test Pilot, war zunächst in Firefox 55 für einen kleinen Teil der Nutzer integriert worden. Ab Firefox 56 ist Firefox Screenshot fester Bestandteil für jeden Nutzer. Es handelt sich dabei um ein Werkzeug zur Aufnahme von Bildschirmfotos. Firefox Screenshots geht darüber hinaus, entweder nur den sichtbaren Bereich einer Webseite oder die komplette Webseite abzubilden. Stattdessen kann auch ein beliebiger Bereich der Webseite ganz einfach festgelegt werden, indem der gewünschte Bereich per Ziehen mit der Maus markiert wird.

Die Screenshots können entweder auf dem Computer gespeichert oder auf einen Mozilla-Server hochgeladen werden, der unter screenshots.firefox.com erreichbar ist, wo die Bilder standardmäßig nach 14 Tagen automatisch gelöscht werden. Daneben können auch zehn Minuten, eine Stunde, ein Tag, eine Woche, ein Monat sowie unendlich lange als Lebenszeit eingestellt werden. Natürlich ist auch ein manuelles Löschen der Bilder möglich. Auch ein direktes Teilen über Facebook, Twitter, Pinterest oder per E-Mail ist per Klick möglich. Der Nutzer hat jederzeit Zugriff auf alle seine hochgeladenen Bilder und kann diese löschen.

Firefox Screenshots in Firefox 55

Keine automatische Medien-Wiedergabe in Hintergrund-Tabs

Diese Neuerung ist bereits seit ein paar Versionen versteckt hinter einer Option in about:config implementiert und nun standardmäßig aktiviert: wer beispielsweise auf YouTube mehrere Videos gleichzeitig öffnen möchte, hat bisher das Problem, dass die Videos in allen Tabs gleichzeitig starten und man so verschiedene Audioquellen durcheinander hört. Ab sofort startet Firefox die Wiedergabe erst, nachdem der jeweilige Tab zum ersten Mal aufgerufen worden ist.

Ausfüll-Hilfe für Formulare (nur US-Version)

Derzeit nur für Nutzer der englischsprachigen US-Version von Firefox ist eine Neuerung aktiviert, welche beim Ausfüllen von Formularen hilft. Firefox kann sich Formular-Daten wie Namen oder Adressen merken und mit diesen Daten dann Formulare befüllen, ohne dass die Daten erneut von Hand eingegeben werden müssen. Über die Einstellungen von Firefox können bestehende Formular-Daten bearbeitet oder gelöscht werden. Auch kann das Feature über die Einstellungen komplett deaktiviert werden.

v

Löschen lokaler Datenbanken möglich

Lokalen Datenbanken wurden beim Löschen der Firefox-Chronik bisher nicht mit gelöscht. Aus Datenschutz-Sicht konnte dies als Problem erachtet werden. Mit Firefox 56 hat Mozilla das Problem behoben, lokale Datenbanken werden ab sofort gelöscht, wenn der Nutzer die Offline-Daten der Webseite löschen lässt.

Verbesserungen der Webplattform

Mozilla hat Unterstützung für rel=“preload“ zum Vorausladen von Content in Firefox 56 hinzugefügt. Das <applet>-Element wird nicht länger unterstützt. Firefox verwendet intern nun Punycode, um URLs zu repräsentieren, was Kodierungsprobleme der URL vermeiden soll. Weitere Verbesserungen der Webplattform lassen sich in den MDN web docs nachlesen. Natürlich gab es auch für Entwickler von WebExtensions wieder einige neue APIs und Verbesserungen bestehender API.

Neuerungen für Webentwickler

Headless-Modus

Nachdem Mozilla in Firefox 55 einen Headless-Modus für Linux implementiert hat, bietet Firefox ab Version 56 einen solchen auch für Windows und macOS. Dieser Modus, in welchem Firefox keine Oberfläche besitzt, ist praktisch für automatisierte Tests.

Verbesserter Grid-Inspector

CSS Grids sind der neuste Trend in der Webentwicklung und mit dem Grid-Inspector bietet Firefox ein praktisches Tool zum Debugging von Grids an. In Firefox 56 hat Mozilla den Grid-Inspector unter anderem durch ein zusätzliches Layout-Panel verbessert.

Firefox 56

Debugger: HTML statt XUL

Mozilla hat den JavaScript-Debugger in den Entwickler-Werkzeugen ersetzt. Die Besonderheit: dieser verwendet kein XUL mehr, sondern ist vollständig mit Webtechnologie (HTML plus React und Redux) umgesetzt.

Im Reiter Netzwerkanalyse der Entwickler-Werkzeuge lassen sich nun einzelne Antwort-Header als Spalten anzeigen.

Verstecktes Feature: Button zur Sitzungswiederherstellung

Ist Firefox so konfiguriert, dass beim Start nicht automatisch die letzte Sitzung wiederhergestellt wird, und über about:config wird der Schalter browser.tabs.restorebutton auf den Wert „1“ gesetzt, dann zeigt Firefox beim Start einen zusätzlichen Button in der Tableiste an, um die zuletzt geöffneten Tabs wiederherzustellen.

Firefox 56

Sonstige Neuerungen von Firefox 56

Mozilla hat die Funktion zum Senden von Tabs an andere mit Firefox Sync verbundene Geräte verbessert, so dass die gesendeten Seiten nun sofort auf dem Ziel-Gerät erscheinen. Die Zeichen-Encoding-Konverter wurden neu in Mozillas Programmiersprache Rust implementiert. Die Safe Browsing-API von Google für den Schutz vor Malware wurde von Version 2 auf Version 4 aktualisiert. Bei Neuinstallationen wird ab sofort die Datenschutzerklärung in einem zweiten Tab automatisch geöffnet.

Firefox 56.0.1: Migration von 32-Bit- auf 64-Bit-Version

Mit Firefox 56.0.1 hat Mozilla kurz nach Veröffentlichung von Firefox 56.0 ein planmäßiges Update nachgelegt, welches primär den Zweck erfüllt, Nutzer der 32-Bit-Version von Firefox auf Windows automatisch auf die 64-Bit-Version zu migrieren, sofern ein 64-Bit-Windows genutzt wird. Die Migration wird schrittweise durchgeführt. Außerdem wurde mit Firefox 56.0.1 für Nutzer einer älteren Version von Windows 7 und Intel-Grafikkartentreiber D3D11 blockiert, um mögliche Abstürze zu verhindern.

Der Beitrag Firefox 56 – die letzte Version vor Firefox Quantum erschien zuerst auf soeren-hentzschel.at.

Ich bin seit Jahren ein treuer Firefox nutzer. Natürlich hat man in der Zeit auch mal andere Browser ausprobiert, daber die Freiheit die der Firefox Browser dem Nutzer gibt, ist sehr schön. Leider glänzt der Firefox in den letzten Wochen und Monaten eher mit Dingen, die man bei Microsoft bzw. Google erwarten würde:

Mozilla: Untergeschobenes Addon Search Shield Study

https://www.kuketz-blog.de/mozilla-untergeschobenes-addon-search-shield-study/

Heute morgen konnte ich erst festellen, dass der Firefox ungefragt das Addon Search Shield Study installiert und ungefragt eine Analyse durchführt. Nach einen Hinweis von mir, hat Mike Kuketz das Verhalten bestätigen können.

Firefox: Erfassung und Übermittlung der Surf-Aktivität

https://www.kuketz-blog.de/firefox-erfassung-und-uebermittlung-der-surf-aktivitaet/

In der neuen Firefox Version, die über die Webseite geladen werden kann, sind bei ca. 1- 2% der Nutzer ein Addon aktiv, das folgendes tut:

Das Experiment beinhaltet zudem das Datenerfassungstool, das Cliqz verwendet, um eine Grundlage für seine Empfehlungen zu schaffen. Die Surf-Aktivitäten derjenigen Nutzer, die eine Firefox-Version mit Cliqz erhalten, werden an die Cliqz-Server gesendet; darunter auch die URLs der Seiten, die sie besuchen. Cliqz verwendet verschiedene Verfahren, die dafür sorgen sollen, dass sensible Informationen aus den Surf-Daten entfernt werden, bevor diese aus Firefox versendet werden. Cliqz erstellt zudem keine Surf-Profile individueller Nutzer und löscht ihre IPs, sobald die Daten erhoben wurden. Der Code von Cliqz ist öffentlich zugänglich und eine Beschreibung der verwendeten Verfahren kann hier eingesehen werden.

Firefox: Screenshot Funktion

https://www.kuketz-blog.de/firefox-56-screenshot-funktion-deaktivieren/

Im aktuellen Firefox (Verison 56) ist eine neue Funktion mit der man Screenshots erstellen kann hinzugekommen. Der Nachteil, diese Screens werden in der Cloud abgelegt, wo nicht nur das hochladen getrackt wird, sondern auch jeder Aufruf.

Firefox IndexedDB Bug

https://www.kuketz-blog.de/firefox-das-alte-problem-mit-der-indexeddb/

Der Fehler ist bereits seit 8 Jahren bekannt, und trotzdem hat es Mozilla immer noch nicht geschafft oder will es nicht diesen Fehler zu beheben. Der DOM Storage wird nicht geleert, selbst, wenn man beim Löschen der Browserdaten alles auswählt. Diese Datenbank kann ausgelesen werden und ergibt so einen eindeutigen Fingerabdruck des Nutzers.

Ich vermute in den nächsten Wochen und Tagen wird noch mehr solcher Dinge auftauchen, die Frage ist jetzt ob der Firefox wirklich der richtige Browser für mich ist. Nur hier einen gute alternative zu finden, ist auch nicht leicht.

Achtung: In diesem Artikel sind fehlerhafte Informationen. Diese Artikel wird am 20.10 von mir gelöscht. Die Entsprechende Korrektur ist hier zu finden!!!

Ich bin seit Jahren ein treuer Firefox nutzer. Natürlich hat man in der Zeit auch mal andere Browser ausprobiert, daber die Freiheit die der Firefox Browser dem Nutzer gibt, ist sehr schön. Leider glänzt der Firefox in den letzten Wochen und Monaten eher mit Dingen, die man bei Microsoft bzw. Google erwarten würde:

Mozilla: Untergeschobenes Addon Search Shield Study

https://www.kuketz-blog.de/mozilla-untergeschobenes-addon-search-shield-study/

Heute morgen konnte ich erst festellen, dass der Firefox ungefragt das Addon Search Shield Study installiert und ungefragt eine Analyse durchführt. Nach einen Hinweis von mir, hat Mike Kuketz das Verhalten bestätigen können.

Firefox: Erfassung und Übermittlung der Surf-Aktivität

https://www.kuketz-blog.de/firefox-erfassung-und-uebermittlung-der-surf-aktivitaet/

In der neuen Firefox Version, die über die Webseite geladen werden kann, sind bei ca. 1- 2% der Nutzer ein Addon aktiv, das folgendes tut:

Das Experiment beinhaltet zudem das Datenerfassungstool, das Cliqz verwendet, um eine Grundlage für seine Empfehlungen zu schaffen. Die Surf-Aktivitäten derjenigen Nutzer, die eine Firefox-Version mit Cliqz erhalten, werden an die Cliqz-Server gesendet; darunter auch die URLs der Seiten, die sie besuchen. Cliqz verwendet verschiedene Verfahren, die dafür sorgen sollen, dass sensible Informationen aus den Surf-Daten entfernt werden, bevor diese aus Firefox versendet werden. Cliqz erstellt zudem keine Surf-Profile individueller Nutzer und löscht ihre IPs, sobald die Daten erhoben wurden. Der Code von Cliqz ist öffentlich zugänglich und eine Beschreibung der verwendeten Verfahren kann hier eingesehen werden.

Firefox: Screenshot Funktion

https://www.kuketz-blog.de/firefox-56-screenshot-funktion-deaktivieren/

Im aktuellen Firefox (Verison 56) ist eine neue Funktion mit der man Screenshots erstellen kann hinzugekommen. Der Nachteil, diese Screens werden in der Cloud abgelegt, wo nicht nur das hochladen getrackt wird, sondern auch jeder Aufruf.

Firefox IndexedDB Bug

https://www.kuketz-blog.de/firefox-das-alte-problem-mit-der-indexeddb/

Der Fehler ist bereits seit 8 Jahren bekannt, und trotzdem hat es Mozilla immer noch nicht geschafft oder will es nicht diesen Fehler zu beheben. Der DOM Storage wird nicht geleert, selbst, wenn man beim Löschen der Browserdaten alles auswählt. Diese Datenbank kann ausgelesen werden und ergibt so einen eindeutigen Fingerabdruck des Nutzers.

Ich vermute in den nächsten Wochen und Tagen wird noch mehr solcher Dinge auftauchen, die Frage ist jetzt ob der Firefox wirklich der richtige Browser für mich ist. Nur hier einen gute alternative zu finden, ist auch nicht leicht.

10. Oktober 2017

Bild: © fotodo / Fotolia.com

Dem Internetbrowser kommt im Bereich der Sicherheit im Internet eine zentrale Rolle zu. Speziell konfigurierte Browser wie das Tor Browser Bundle können die Privatsphäre stärken, unsicherer und/oder "gesprächige" Browser können gleichzeitig alle anderen Bemühungen konterkarieren. Leider sieht man am Beispiel Mozilla bzw. Firefox mal wieder, dass freie Softwareprojekte Datenschutz genau so mit Füßen treten können, wie kommerziellen Zwängen unterworfene IT-Konzerne.

Firefox war mal die große Hoffnung des freien Internets. Unabhängig entwickelt und vor allem durch Mundpropaganda verbreitet, beendete er die Monopolstellung des technisch rückständigen Internet Explorers, der aus den Browserkrieg der 1990er hervorgegangen war. In den letzten Jahren hat man jedoch massiv Marktanteile an Googles Chrome verloren. Das liegt natürlich einerseits an den hervorragenden Marketingmöglichkeiten, die sich Google durch seine Markmacht im Suchmaschinengeschäft bedienen kann, aber auch an der zeitweiligen technischen Überlegenheit. Chrome war einfach schneller, schlanker und stabiler als der aufgebläht wirkende, und behäbig entwickelte Firefox.

Chrome hat aber auch massive Nachteile. Kaum ein Browser überträgt so viele Nutzerdaten. Das liegt natürlich auch an der Geschäftsstruktur von Google, das mittelbar mit den Nutzerdaten Geld verdient, denn diese Daten sind die Grundlage zielgerichteter Werbung. Google hat deshalb nur ein geringes Interesse an spurenarmer Aktivität im Internet, wie sich kürzlich erst in der Reaktion auf Apples neue Sicherheitsvorkehrungen in Safari gezeigt hat.

Dies verweist bereits auf einen anderen Aspekt. Sofern man nicht in die großen Werbenetzwerke involviert ist, kann es durchaus lukrativ für ein Unternehmen sein, sich möglichst datenschutzfreundlich zu inszenieren. Apple macht das seit längerem verhältnismäßig erfolgreich vor, siehe z.B. das Verhalten in der FBI Affäre oder im Umgang mit der Auswertung von Nutzerdaten.

Es ist geradezu erbärmlich, dass ein kommerziell agierender IT-Gigant mit Sitz in den USA der Open Source Gemeinschaft vormacht, wie man von Datenschutz profitieren kann. Mozilla agiert nämlich im Angesicht sinkender Marktanteile und einer marginalen Bedeutung im mobilen Segment zunehmend erratisch. Mal versucht man sich datenschutzfreundlich zu geben, dann integriert man das proprietäre Pocket, sowie nun testweise Cliqz und ein weiteres Addons. Nachdem man Google schon bei der Versionierung kopiert und das Design nachgeahmt hat, möchte man wohl auch noch den Wettbewerb um die größte Datenhalde "gewinnen".

Zugegebenermaßen steht Mozilla nur sinnbildlich für weite Teile der Open Source-Landschaft. Anstatt die verhältnismäßig große Unabhängigkeit von Big Data-Sammelstellen zu nutzen und sich dezidiert als sichere Alternative zu präsentieren, haben viele Entwickler eine erstaunliche laissez-faire Einstellung zu dem Thema. Die exzessive Nutzung von Google+und ähnlichem zu Supportzwecken spricht da Bände. Man schreibt sich zwar Datenschutz und Sicherheit gerne auf die Fahne, aber außer allen Code offen zu legen, folgt dem nicht viel.

9. Oktober 2017

Letztes Quartal 2017, somit Zeit für ein Update von der Security Distro Front.

Parrot Security 3.8

parrot

Parrot 3.8 setzt inzwischen auf Debian 10 Buster und hat seinen Kernel auf 4.12 aktualisiert. Zusätzlich ist MATE 1.18, GCC 6.4 und 7.2, Java 9 und vieles mehr dazu gekommen.
Das Dateisystem ZFS wird nun unterstützt. Für Bitcoin Miner wurde Electrum, ein kleiner Bitcoin Client installiert. 


Ein DNS Problem vorheriger Versionen wurde behoben. Es wurde eine Round-Robin Methode implementiert, die zwischen den Parrot OpenNIC und den Standard DNS Servern wechselt.

Download


Kali Linux 2017.2

Kali_Linux

Die Nummer 1 der Security Distros bringt mit 2017.2 ein weiteres Rolling Release heraus. 

Sicherheitsexperten und Penetration-Tester dürfen sich über 1399 aktualisierte und 171 neue Pakete freuen. Als Highlight haben die Entwickler folgende Tools hervorgehoben:

  • hurl – Ein praktischer hexadezimal und URL Encoder bzw. Decoder
  • phishery – SSL fähige basic auth phishing URLs in ein .docx Word Datei injizieren
  • ssh-audit – SSH Server Audit
  • apt2 – Automatisiertes Penetrations Testing Toolkit, dass selbst scannt oder von anderen Scannern importieren kann.
  • bloodhound – Beziehungen im Active Directory darstellen
  • crackmapexec – Große Active Directory Netzwerke prüfen
  • dbeaver – Grafisches Tool für MySQL, PostgreSQL, Oracle, SQLite und weitere DBs
  • brutespray – Automatisch Standard Passwörter auf gefundenen Diensten testen


Ich persönlich finde Tinfoleak v2 interessant, dabei handelt es sich um ein Tool für Informationsgewinnung via Twitter. 

Auch das hier bereits erwähnte WPScan wurde auf 2.9.3 aktualisiert.


Alle Änderungen gibt der Changelog preis.

Download Kali


BlackArch 2017.08.30

blackarch

Drüben bei BlackArch wurde ebenfalls eine neue Version veröffentlicht.

Dabei sind 50 neue Tools, ein neuer Installer und ein aktueller Linux Kernel (4.12.8)
Die vorhandenen Programme wurden aktualisiert, auch die bestehenden Menüs (awesome, fluxbox, openbox) haben ein Update erhalten.

Download BlackArch

 

 


Bleibt noch die aktualisierte Übersicht, der hier bereits erwähnten Systeme.

Übersicht forensische Distributionen 10/17

 

Name Version Tools Besonderes Basis GUI
Autopsy 4.0 ??? The Sleuth Kit Windows  
BackBox 5 70+ eigenes Repo Ubuntu Xfce
BlackArch Linux 2017-08-30 1750+ ArchLinux ArchLinux Gnome
CaINE 5 100+ WinUFO Ubuntu Mate
DracOS 3.0 100+ CLI LFS DWM
DEFT Zero 250+ Dart2 Lubuntu 14.04 Lxde
Kali Linux 2017.2 300+ ARM fähig Debian Testing Multi
LionSec 5.0 ???   Ubuntu  
Matriux v3 RC1 300+ out of date Debian Gnome
NST 24 ??? Server integriert Fedora  
NetSecLOS 6.0 50+   OpenSuse Lxde
Paladin 6.0 30+   Ubuntu  
Parrot Security 3.8 700+ Cloud fähig Debian Buster MATE
Pentoo 2015.0 RC5 ??? 64bit Gentoo Xfce
Ronin   150+ out of date Lubuntu Lxde
Sans SIFT 3.0 20+   Ubuntu  

Für sogenannte Offside-Backups nutze ich (in der Regel in Verbindung mit rsync.net) das Tool Borg. Borg legt die zu sichernden Dateien in Repositorys an und nutzt zudem auch noch Deduplikation bei der die Daten in kleine Teile zerlegt werden. Somit werden nur die geänderten Teile bei einer Datensicherung berücksichtigt.

Vor ein paar Tagen wurde nun Borg in Version 1.1 veröffentlicht. Für mich stechen besonders folgende Sachen hervor:

  • Borg diff: Vergleichen von zwei Sicherungen
  • Borg export tar: Sicherung als Tar-Archiv exportieren
  • JSON API für die wichtigsten Sachen wie borg create, borg list usw.
  • BORG_PASSCOMMAND: Nutzung von Schlüsselringen und Hardwareschlüsseln wird damit vereinfacht

Da sich bei Borg in Version 1.1 einiges getan hat, gibt es unter https://www.borgbackup.org/releases/borg-1.1.html eine Zusammenfassung der wichtigsten Punkte.

Wer sich für Borg für ein Offside-Backup interessiert, sollte sich ggf. einmal den Dienst rsync.net ansehen. Dieser bietet für Nutzer von Attic bzw. Borg einen Sondertarifan, bei dem das GB 3 Cent im Monat kostet und man mindestens 25 GB mieten muss. Da ich dort nur meine wirklich, wirklich, wirlich wichtigen Sachen sichere komme ich somit für weniger als 8 Euro im Jahr gut zurecht und habe Dank der Deduplikation noch jede Menge Platz frei. Die Repositorys von Borg lassen sich übrigens verschlüsselt (inkl. Schlüsseldatei) anlegen so dass nur die verschlüsselten Daten hochgeladen werden.

8. Oktober 2017

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

plesk-git-1

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht. Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

plesk-git-1

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

plesk-git-1

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That’s it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

Websiten mit Hugo erstellen, bei Github/Gitlab pushen und mit Plesk ausliefern

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

7. Oktober 2017

Ab nächster Woche startet Mozilla ein “Experiment”. Ca. jedes 100. Downloadpaket von Firefox wird dann das Add-On Cliqz enthalten.

Mit diesem Add-On werden Vorschläge für Webseiten angezeigt wenn man etwas in die Adressleiste des Browsers eingibt. Hierfür werden die Surf-Aktivitäten der Nutzer der Nutzer an Cliqz-Server geschickt und ausgewertet. Mozilla verspricht zwar, dass sensible Daten vorher entfernt werden und keine individuelle Profile anglegt und die IP-Adressen gelöscht werden, aber dieses “Experiment” hinterlässt bei mir trotzem einen unschönen Beigeschmack.

Vor allem weil es sich hierbei nicht um Opt-in sondern um Opt-out handelt. Ich bin mir zwar nicht sicher, aber ich fürchte die betroffenenen Nutzer werden vermutlich beim Installieren der “verwanzten” Installationspakete nicht wirklich informiert.

Die neue Web-Engine bringt den Firefox endlich wieder technisch auf Augenhöhe mit dem Chrome-Browser von Google. In den letzten Jahren ist der Martkanteil von Mozillas Browser immer weiter geschrumpft. Runderneuert könnte der Browser alte Fans zurückgewinnen.

Lange Zeit war der Mozilla Firefox die einzige ernsthafte Alternative zum Microsoft Internet Explorer. Für Webentwickler und Leute, die mit Linux arbeiten, war es die einzige vernünftige Option. Dann kam Google Chrome und hat den Markt aufgerollt – mit geballter Marktmacht des Suchmaschinen-Konzerns, aber auch mit überlegener Technik. Chrome ist einfach wahnsinnig schnell.

Für mich als Firefox-Fan wurde es immer schwieriger, einen Bogen um Chrome zu machen. Ich finde es aber nicht gut, wenn irgendwann jegliche digitalen Angebote nur noch von zwei bis drei Konzernen kommen. Firefox war immer noch eine sinnvolle, unabhängige und freie Alternative. Doch der technische Vorsprung von Chrome wurde in letzter Zeit immer offensichtlicher.

Im letzten Jahr kündigte Mozilla dann eine neue Web-Engine an. Die Web-Engine ist das Herz des Browsers und verantwortlich für die Geschwindigkeit, mit der Webseiten angezeigt werden. Doppelt so schnell und mit einem Drittel weniger Speicherverbrauch, will der Firefox ab dem 14. November 2017 auftrumpfen. In der Beta-Version kann man das bereits heute testen und mein erster Eindruck ist: Ja, der Firefox fühlt sich wesentlich flotter an.

YouTube Video

Auch die Oberfläche wurde überarbeitet und sie sieht moderner aus. Auf der Startseite gibt es jetzt einige Link-Tipps von Pocket – dem Social Bookmarking Dienst, den Mozilla im Februar übernommen hat. Da wurden mir schon ein paar interessante Artikel angeboten.

Bisher habe ich Firefox-Sync noch nicht genutzt. Wenn man sich aber dort anmeldet, kann man nicht nur Bookmarks und Zugangsdaten zentral abspeichern und auf allen Geräten nutzen – man kann auch Tabs von einem an das andere Gerät schicken. Das ist praktisch.

Schon länger gefällt mir der Lesemodus sehr. Aus Seiten, die halbwegs ordentliches HTML haben, kann der Firefox eine Ansicht erzeugen, die gut zu lesen ist. Alle überflüssigen Elemente werden entfernt und die Schrift ist groß. Man hat dann reinen Text auf weißem Grund. So sind selbst Seiten, die noch nicht responsiv sind, kann man damit auf dem Smartphone gut lesen. Zusätzlich gibt es im Lesemodus eine Vorlesefunktion, die inzwischen auch gut zu verstehen ist.

Ich hoffe, dass der Firefox mit mehr Power auch wieder beliebter wird. Es muss ja am Ende nicht alles Microsoft und Google gehören.

Firefox wird endlich richtig flott

Nach einer Neuinstallation des Computers stellt man vielleicht fest, dass man sich an den einen oder anderen, häufig genutzten Befehl nicht mehr erinnert, da man ihn immer nur aus der Shell History aufgerufen hat. Oder man vermisst eine Einstellung, erinnert sich aber nicht mehr wo und wie diese vorgenommen wird. So erging es mir jedenfalls schon das eine oder andere Mal.

Aus diesem Grund erstelle ich in Zukunft hin und wieder einen Artikel wie diesen, mit unsortierten, aber nützlichen Shell-Befehlen und Einstellungen.

Vielleicht findet auch der oder die Eine oder Andere auch noch etwas nützliches dabei.

 


1 – Piepsen bei Tab-Completion deaktivieren

Das Piepsen der Bash, wenn die Auto-Vervollständigen Funktion mehrere Einträge findet kann auf Dauer ziemlich nervig sein. Zum Glück lässt sich der “beep” einfach deaktivieren.

Dazu wird die Datei  ~/.inputrc erstellt, oder geöffnet und folgender Inhalt eingefügt:

set bell-style none

2 – Sternchen bei Sudo Passworteingabe anzeigen

Normalerweise wird aus Sicherheitsgründen bei der Eingabe des Sudo Passworts keine Rückmeldung angezeigt, denn auch die Kenntnis über die Passwortlänge kann verräterisch sein.
Auf Wunsch kann aber auch dieses Verhalten geändert werden, so dass bei der Eingabe des Passworts Sternchen angezeigt werden.

Dazu wird in die Datei /etc/sudoers folgende Zeile eingefügt:

Defaults pwfeedback


3 – Aussehen der Bash Eingabeaufforderung anpassen

Das Aussehen und die Informationen die einem der Bash Promt anzeigt lassen sich umfangreich konfigurieren. Eine super Hilfe ist hierbei die Webseite bashrcgenerator.com. Per Drag and Drop lässt sich hier das Aussehen des Promts konfigurieren. Anschließend erhält man einen String, welcher in die Datei ~/.bashrc eingetragen werden muss.

Damit die Eingabeaufforderung aussieht wie in Screenshot unten muss beispielsweise folgender Strong eingefügt werden

export PS1="\[$(tput bold)\]\[\033[38;5;10m\]\u\[$(tput sgr0)\]\[$(tput sgr0)\]\[\033[38;5;15m\]@\[$(tput bold)\]\[$(tput sgr0)\]\[\033[38;5;1m\]\h\[$(tput sgr0)\]\[$(tput sgr0)\]\[\033[38;5;15m\]:\[$(tput bold)\]\[$(tput sgr0)\]\[\033[38;5;12m\]\w\[$(tput sgr0)\]\[$(tput sgr0)\]\[\033[38;5;15m\]\\$ \[$(tput sgr0)\]"


4 – Manpage in Postscript und PDF konvertieren

Manchmal ist es einfacher lange manpages im PDF Reader auf dem zweiten Bildschirm oder dem Tablet lesen zu können. Hierzu kann eine installierte manpage einfach in eine postscript und PDF-Datei umgewandelt werden, hier am Beispiel der manpage von pacman:

Umwandlung in postscript

man -t pacman > pacman.ps

Umwandlung in PDF

ps2pdf pacman.ps

5 – Liste mit installierten Paketen sichern

Wenn man einen Rechner neu aufsetzt ist es oft hilfreich eine Liste mit Paketen zu haben, welche vorher installiert waren.

Unter Debian/Ubuntu lässt sich eine solche Liste  mit folgendem Befehl sichern:

dpkg --get-selections > packagelist.txt

mit Pacman funktioniert dies mit folgenden Befehlen, wobei der Schalter -e im zweiten Befehl die Auswahl auf explizit installierte Pakete einschränkt und Pakete welche nur als Abhängigkeit installiert wurden ausblendet

pacman -Q > packagelist.txt

oder

pacman -Qe > packagelist.txt

6 – belegten Speicherplatz anzeigen

 

du -hs Nextcloud

Zeigt den durch den Ordner Nextcloud belegten Speicherplatz an

du -d1 -h Nextcloud

zeigt zusätzlich den durch die jeweiligen Unterordner von Nextcloud belegten Speicherplatz an


7 – zwischen zwei Verzeichnissen wechseln

Manchmal möchte man häufiger zwischen zwei Verzeichnissen hin- und herspringen, z.B. weil ein Programm Konfigurationen in zwei unterschiedlichen Verzeichnissen anlegt.

Mit dem Befehl

cd -

kann man einfach zwischen den beiden zuletzt genutzten Verzeichnissen wechseln.


8 – Die Bash History

Eine lange Liste mit zuletzt genutzten Befehlen wird in der Datei ~/.bash_history gespeichert.

history

zeigt die komplette Liste an mit voranstehender Nummerierung an.

 fc -l

zeigt einem die zuletzt genutzten Befehle, ebenfalls durchnummeriert.

!NUMMER

führt den Befehl mit NUMMER erneut aus.


9 – Version eines installierten Pakets anzeigen

unter Ubuntu/Debian (hier für das Paket openssl)

apt-cache policy openssl

bei Arch basierten Distros

pacman -Qi openssl


10 – Bildschirm ausschalten

Manuell ausschalten lässt sich der Bildschirm mit unstenstehendem Befehl. Entweder über das Terminal, oder über das Ausführen Fenster mit Alt-F2

xset dpms force off

 


Dieser Text ist lizensiert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
Titelbild “hacken-hacker-computer-internet-1685092” von Pixabay steht unter Creative Commons CC0

Unsortierte Shell Kommandos und Einstellungen #1 ist ein Beitrag von techgrube.de.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS. Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht. Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen. Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.


Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.