Garten Eden

#linux #programming #android #online #stuff

Pylint3 für Ubuntu/Linux Mint und Sublime Text

Pylint hilft mir ungemein als Werkzeug zur statisches Codeanalyse beim Programmieren. Leider unterstützt das Paket pylint in Ubuntu-basierten Distributionen (wie Linux Mint) nur die Analyse von Python2-Scripts; Python3-Unterstützung taucht erst in den vivid-Quellen (15.04) auf.

pylint für Python 3

Dennoch lässt sich das Paket pylint3 problemlos nachinstallieren, nachdem man ein neue Version von python3-astroid bereitstellt. Downloaden kann man beides aus den offiziellen Ubuntu-Quellen (unter Architektur: all):

Nach dem Installieren der beiden Pakete ist pylint3 neben pylint global verwendbar, sie beeinflussen sich also nicht.

Pylint3 für Sublime Text 3

Glücklicherweise gibt es auch für meinen Lieblingseditor Sublime Text 3 ein Plugin/Package, das Pylint einbindet und dessen Ergebnisse z. B. bei jedem Speichern einer Python-Datei grafisch anzeigen kann.

Screenshot Pylint3 in Sublime Text 3

Das Package heißt Pylinter und kann komfortabel über Sublimes Package Control installiert werden.
Nach der Installation muss noch der Pylint-Pfad angepasst werden, damit die 3er-Version genutzt wird. Dies geschiet über Preferences → Package Settings → Pylinter → Settings – User. (Default würde bei jedem Package-Update überschrieben werden.)
Meine Pylinter.sublime-settings:

{
	// Show different icons for errors, warnings, etc.
	"use_icons": true,

	// Automatically run Pylinter when saving a Python document
	"run_on_save": true,

	// Don't hide pylint messages when moving the cursor
	"message_stay": true,

	// my changes for python3 support
	"python_bin": "python3",
	"pylint_path": "/usr/lib/python3/dist-packages/pylint/lint.py"
}
(relevant für den Pfad sind die letzten beiden Zeilen)

flattr

0 Kommentare

nginx Pakete im Vergleich

nginx wird bekanntlich in vielen Distributionsquellen, darunter Ubuntu-basierten, in mehreren Varianten zur Installation angeboten, die alle unterschiedlich viele Module und damit Funktionen mitbringen. Die folgende Tabelle liefert einen Überblick über die Module, die in den Ubuntu 14.04 LTS Trusty-Quellen enthalten sind.

nginx -extras -full -core -light
Standard HTTP Modules:
access
auth basic
auto index
browser
charset
core
empty gif
fastcgi
geo
gzip
headers
index
limit requests
limit zone
log
map
memcached
proxy
referer
rewrite
scgi
split clients
ssi
upstream
user id
uwsgi
Optional HTTP Modules:
addition
debug
embedded perl
flv
geoip
gzip precompression
http sub
image filter
ipv6
mp4
random index
real ip
secure link
spdy
ssl
stub status
substitution
webdav
xslt
Mail Modules:
imap
mail core
pop3
smtp
ssl
Third Party Modules:
auth pam
chunkin
dav ext
echo
embedded lua
fancy index
http push
http substitution filter
httpheadersmore
nginx development kit
upload progress
upstream fair queue

Update 06.04.15: Ich habe die Liste aktualisiert und ein Python3-Script geschrieben, das diese Informationen aus einem System ausliest und in einer Tabelle darstellt.

flattr

0 Kommentare

Was spricht gegen TLS?

TLS, früher SSL, ist nun wirklich nicht neu (SSL seit 1994; die aktuelle Version TLS 1.2 wurde 2008 beschrieben und wird von allen aktuellen Browsern unterstützt). Trotzdem werden viele Internetseiten nicht verschlüsselt zum Besucher transportiert. Wieso?

Ein Plädoyer für mehr Verschlüsselung im Netz — Ja, du bist gemeint, Admin!

Die Vorteile

Vielleicht zuerst zu den Vorteilen, warum man eine verschlüsselte Verbindung aufbauen sollte. Die kurze, aber tiefgreifende Antwort ist: Edward Snowden. Man muss nicht mehr paranoid sein, um zu wissen, dass jeder mit mehr oder weniger Begabung/Aufwand an sämtliche Kommunikation herankommt. Spitzfindige werden sagen, dass die NSA auch verschlüsselte Verbindungen abhören kann. Richtig, doch kann man für die NSA den Aufwand exponentiell erhöhen, wenn deutlich mehr Kryptographie im Netz im Spiel ist und für alle nicht-NSA-ler das Mitlesen gleich verhindern. Richtig konfiguriert gilt es als sicher.

Aber: Rechenintensiv!

Was schlecht für den Server ist, ist auch schlecht für den Besucher der Seite. Jeder, der Mails oder Dateien ver-/entschlüsselt, weiß, dass Kryptographie die CPU hoch fährt und die Ladezeit erhöht. Aber gilt das auch für Webserver? Wo stehen wir bei aktuellen Optimierungsverfahren? Glaubt man Google, Facebook und Co. bewegen wir uns nach Aktivierung von TLS mit aktuellen Optimierungen im Rahmen von max. ca. +1% CPU-Aktivität und +10 KB Speicheraufwand pro Verbindung, bei einem Overhead von weniger als +2%. Zu den Stellschrauben, an denen wir drehen können, gehört auch die Möglichkeit, den TLS-Verbindungsaufbau bei wiederkehrenden Verbindungen drastisch zu verkürzen, ergo nicht jedes mal vollständig neu berechnen zu müssen.
Ach ja, wir halten fest: Falsch.

Aber: Viel langsamer!

Auch falsch. Zumindest teilweise. Was stimmt, ist, dass erst ein Handshake zwischen den Partnern stattfinden muss, in dem Cipher, Challange etc. gewählt und übertragen wird. Das kostet im Optimalfall einen Roundtrip (ein Paket zum Server, eins zurück). Was heißt Optimalfall? Server und Client müssen die erwähnten Technologien unterstützen, hauptsächlich sind das TLS sessions, TLS False Start, OCSP stapling, forward secrecy und SPDY.
. Auf Clientseite gibt es mit aktuellen Browsern keine Probleme, auch nicht mobil. Serversoftware beherrschen die Methoden meist auch schon seit Längerem, sie warten also nur darauf, aktiviert zu werden.

Aber: Aufwand!

Auch bekannt als: Ich bin faul. Gut, auch ich würde nicht direkt Hurra! rufen, wenn ich was an meinem laufenden Server ändern sollte. Aber ist es das nicht wert? Vor allem, weil es inzwischen genug Tutorials diesbezüglich gibt. Meine nginx Konfiguration umfasst z.B. gerade mal ein Dutzend Zeilen.

Aber: Zertifikat? Kosten?

Null Euro. Stichwort: StartSSL. Und bald wohl auch Mozilla & Co.
Was planen die da?! sudo apt-get install lets-encrypt && lets-encrypt example.com? Unglaublich gut. Ich bleibe am Ball.
Erwähnenswert ist, dass Erstgenanntes in allen wichtigen Browsern keine Warnung erzeugt. Und wirklich von Jahr zu Jahr kostenlos ist.

Kein Aber!

Unterm Strich bleiben die meisten Vorbehalte gegenüber sicheren Verbindungen also haltlos und können gezielt adressiert werden.
Ich finde, wir als Administratoren, Webseitenbetreiber und Blogger sind es unseren Lesern schuldig.

Okay, ich überlege es mir…

Eine super Einführung gibt Ilya Grigorik, seines Zeichens Forscher bei Google u.a. für Sicherheit und Internet-Performance, auf seiner Projektseite istlsfastyet.com. Für Serverkompatibilität und vor allem eine sehr gelungene Präsentation zu diesem und ähnlichen Themen verweise ich auf seine Seite. Das verlinkte Video ist übrigens sehr überzeugend und für alle, die etwas für Netzwerke übrig haben, spannende, leicht-verdauliche Kost.

Wie man sieht, spricht fast nichts mehr gegen grundlegende Verschlüsselung.
Also Admin, ran an die Arbeit.

Update 16.12.14: Zu einer ähnlichen Einschätzung kommt aktuell auch Golem im Artikel Mythen über HTTPS.

flattr

5 Kommentare

⇓   Ältere Artikel   ⇓

de

Moment, lade ältere Artikel...

E-Mail (nicht öffentlich)

Homepage (optional)

Kommentar... (code-Tag erlaubt)