Montag, 14. Mai 2018

Universelles Apple Zubehör seit fast 30 Jahren

Es gibt ein Werkzeug oder Hilfsmittel das ich seit fast 30 Jahren für meine Apple Geräte brauche.

Früher habe ich damit 3,5' Disketten aus meinem Mac befreit, heute säubere ich damit die Ladebuchse von meinem iPhone, damit ich es laden kann. Ich bin schon darauf gespannt, wann Apple dieses universelle Tool selbst vermarktet - wie wäre es mit iClip X oder MacClip Pro - Karl Klammer wäre sicher stolz.

Mittwoch, 2. Mai 2018

Prüfen von Java Libs auf bekannte Verwundbarkeiten

Es gibt ein gutes Tool mit dem man Java Libs auf bekannte OWASP Schwachstellen prüfen kann. Dieses Toll gib es als Plugins für diverse Build-Werkzeuge. Man kann es aber auch Out-Of-The-Box nutzen:

Installation:
brew install dependency-check

Für Grade gibt es ein Plugin, wenn man dieses nich nutzen möchte kann man alle Dependencies herunterladen, mit folgenden Grade Task:
task getDeps(type: Copy) {
   from sourceSets.main.runtimeClasspath
   into 'runtimeX/'
}


Ausführen und Erzeugen eines Report mit gefundenen Verwundbarkeiten
dependency-check --project haupt --scan runtimeX/ --suppression config/dependencyCheck/suppressions.xml --suppression config/dependencyCheck/suppressNetty.xml


In dem Report findet man gelegentlich False-Positive Warnungen, diese kann man mit Hilfe der Saupression-Dateien unterdrücken.


Link:

  1. https://www.owasp.org/index.php/OWASP_Dependency_Check

Prüfen von JavaScript Libs auf bekannte Verwundbarkeiten

OWASP ist hoffentlich für viele Entwickler eine bekannte Quelle, wenn es um Sicherheit von Software geht.
Mit Hilfe des Programms retire kann man seine JavaScript Libs auf OWASP bekannt Verwundbarkeiten prüfen:

Installation von retire via Yarn:
yarn global add retire

Prüfen auf JS Verwundbarkeiten:
retire -v --js --jspath myProject

Die Option -v sollt man möglichst mitgegeben, um zu sehen, das retire funktioniert bzw. der angegebene Pfad OK ist.


  1. Ursächliche JavaScript Library identifizieren und CVE-Vulnerabily verstehen
  2. Version der JavaScript Library anpassen
  3. Library in der Datei _.retireignore_ gegebenenfalls aufnehmen
Natürlich sollte man diesen C heck natürlich regelmässig wiederholen.

Dienstag, 10. April 2018

Postgresql Zombie Prozesse finden und beenden

Zombie gibt es überall, auch in Form von Queries in Datenbanken wie hier der Postgresql DB. Diese Zombies können auf unterschiedliche Weise entstehen, z.B. wenn eine Javaanwendung eine Query mach und in eine Excption gerät und dann die Ressourcen, d.h. hier die DB Query aufräumen. Die DB wartet dann ewig, dass die Java Applikation sich das Ergebnis der Query abholt, vergebens.

Mit der folgenden SQl Query kann man Zombies finden, hier Queries die älter als 30 Minuten sind.

select pid, age(query_start, clock_timestamp()), usename, query 
FROM pg_stat_activity 
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
AND query_start < NOW() - INTERVAL '30 minute'

Anschliessend kann man sie beenden:

select pg_terminate_backend(pid)

Einige nützliche Links

  1. https://gist.github.com/rgreenjr/3637525
  2. https://stackoverflow.com/questions/35319597/how-to-stop-kill-a-query-in-postgresql
  3. https://jobs.zalando.com/tech/blog/hack-to-terminate-tcp-conn-postgres/?gh_src=4n3gxh1

Samstag, 17. März 2018

Warum ich keine mehr Konfigurationsdatei brauche.

In der heutigen Softwareentwicklung, also ich meine Java, Docker und die Cloud, brauche ich keine Konfigurationsdateien mehr. Warum? Ganz einfach, eine Konfigurationsdatei ermöglicht es, das Setup von Programmen an die eigenen Bedürfnisse anzupassen und die Software neu zu starten. So machen es viele Programme wie der Apache Server oder Postgres. Hier machen Konfigurationsdateien Sinn.

Wenn ich mich im Cloud Umfeld bewege und individuelle Wegwerf-Software mit Docker erstelle und deploye, dann gibt es diesen Anwendungsfall nicht mehr, dass ich ein Konfiguration anpasse und dann die Software neu starte.

Im der Welt von Docker, Cloud und Continuoude Deployments kann ich die Konfiguration im Code ändern, ins GIT einchecken und warten bis meine Continuouse Deployment Pipeline mir nach wenigen Minuten eine neue Softwareversion ausgerollt hat. Fertig, jetzt brauch ich eine Properties oder YAML Dateien mehr. Das ist für Softwareentwickler einfacher als sich via VPN auf Hosts, und dann auf Docker Container anzumelden und Änderungen an der Konfiguration durchzuführen. In den letzen Jahren in denen ich mich in diesem Umfeld bewege ist mir dieser Fall nicht vorgekommen.

Aber, Secrets wie Access-Keys, Passwörter oder Benutzernamen gehören natürlich nicht so plain in den Code und auch nicht ins GIT. Solche geheimen Daten kann man dann ggf. in verschlüsselten Konfigurationsdateien speichern.

Montag, 19. Februar 2018

Generatoren für Lasttests - Jmeter, XLT oder Gatling, welches Tool ist das Richtige?

Lasttest gehen einfach, das ist eine verbreitete Meinung unter Softwareentwicklern. Ja es ist mit den meisten Tools sehr einfach simple Lasttest zu erstellen, die einem "Hello World" Programm entsprechen. Das allein ist natürlich kein Kriterium für die Auswahl eines Lasttest Tools. Wie man sinnvolle Lasttest durchführt wird in einem anderen Artikel beschrieben.

Apache Jmeter 

Jmeter ist der Klassiker, wenn es um Lasttest geht. Jmeter ist in Java geschrieben, lässt sich durch Plugins und eigenen Code erweitern. Viele Plugins sind seit Version 4 Teil von Jmeter. Sonst lassen sich im Internet auch diverse Plugins finden oder man schreibt in Java eine eigenes Plugin, hier z.B. eins zu Testen des Overheads durch HMAC Verschlüsselung (Link). Einfacher ist es selbst Code-Fragmente zu schreiben und direkt im Test auszuführen, dafür gibt es verschiedene Plugins und Sprachen (Beanshell, Groovy). Man kann Test Parametrisieren und auf Properties und Umgebungsvariablen, sehr einfach zugreifen.

Der Test selbst wird mittels einer GUI erstellt und als XML Datei gespeichert. Wenn man will kann man natürlich auch die XML Datei später verändern.

Dei Möglichkeiten Lasttest auszuwerten sind begrenzt aber ausreichend. Für Detailanalysen sollte man der Messungen als CSV protokollieren und mit speziellen Werkzeugen oder Sprachen wie R oder Rstudio durchführen.

Jmeter ist ein ausgereiftes Lastest Tool mit dem Fokus aus Lasterzeugung. Jmeter ist nicht nur für HTTP/S geeignet ist, man kann z.B. auch JDBC oder Mongo Datenbanken testen. Eine weitere Spezialität sind verteilte Lastest um auch grosse Lasten zu erzeugen. Via Script-Sprachen lassen sich die meisten Lasttest-Anforderungen umsetzen. Die Dokumentation ist gut und die Community umfangreich.

Xceptance XLT

XLT, nicht zu verwechseln mit XSLT, ist als kommerzielle Lasttest Werkzeug durch die Firma Xceptance aus Jena entwickelt worden (Link). Seit einiger Zeit ist jedoch frei verfügbar. Diese Professionalität merkt man dem Tool durchgehend an, und es ist schwierig alle Features aufzulisten. Besonders interessant, ist hier die Möglichkeit reale Browser wie den Firefox als Testagenten einzusetzen. Auf diese Weise sind auch gleichzeitig Performance-Messungen möglich.  Im Vergleich zu Jmeter sind die sehr guten Analyse Fähigkeiten hervorzuheben. Es ist für hohe Lasten gut geeignet, fokussiert aber auf HTTP/S. Wem die normalen Fähigkeiten von XLT nicht ausreichen, kann den Lasttest auch als Java Applikation umsetzen, so kann man jede Lasttest-Anforderung umsetzen.

Gatling

Gatling (Link) ist ein relativ neues Lasttest Tool geschrieben in Scale und oft als Herausforderer für die etablierten Lasttest Tools angesehen wird. Lastest werden als Scala Code codiert, wobei für einfache Lasttest kein wirkliches Scala Know-How notwendig ist. Für erfahrene SCALA Entwickler ist es sicher auch einfach anspruchsvolle Lasttest-Anforderungen als Code umzusetzen. Die Dokumentation ist für Anfänger gut aber nicht sehr umfangreich auch die Community ist nicht mit Grösse der Community von Jmeter vergleichbar. Die Auswertungsmöglichkeiten sind eingeschränkt aber sehr bunt.

Empfehlung

Für einfache Lasttest sind alle Tools geeignet, genauso wie für anspruchsvolle Lasttest geeignet sind. Gatling würde ich ausschliessen, weil SCALA Know How erforderlich ist um komplexe Lasttest umzusetzen. SCALA ist keine populäre Programmiersprache. Im TIOBE Index  ist SCALA nicht unter den Top 20 Programmiersprachen und wird die Top 20 auch nie erreichen. Damit zählt auch SCALA zu den exotischen Programmiersprachen. Eigentlich würde man in diese Kategorie auch Beanshell (Jmeter) und Groovy (Jmeter) einsortieren aber diese Sprachen akzeptieren auch Plain Java. Damit ist es deutlich schwerer erfahrene SCALA Programmierer für Gatling zu finden als erfahrenen Java Programmierer für Jmeter oder XLT. Das merkt man auch der Community und der Dokumentation an. Ich würde Gatling nicht für Produktivumgebungen empfahlen.

Jmeter und XLT sind solide und bewährt. Jmeter hat aber Schwächen bei der Auswertung, die man bei Bedarf leicht ausgleichen kann. Jmeter hat eine umfangreiche Auswahl an Samplern (HTTPS, DB, TCP, ..), und ist dadurch nicht nur für HTTPS Lasttest einsetzbar.
Beide Werkzeuge, Jmeter und XLT sind für die meisten Fälle zu empfehlen. XLT ist das Werkzeug der Wahl wenn es um Browser-basiertes Testen geht, auch sind die XLT Reports und Auswertungsmöglichkeiten hervorragend. Jmeter ist der Allrounder und den Lasttestgeneratoren.


Jmeter XLT Gatling
Geeignet für einfache Lasttest Gut Gut Gut
Geeignet für komplexe Lasttests Gut Gut Ok
Verhält sich wie ein Webbrowser Bedingt Ja Nein
JS Ausführung Nein Ja Nein
Dokumetation Sehr gut Sehr gut Ok
Community Umfangreich Gering Ok
Hochlast Ja Ja

Analyse der Ergebnisse Ok Sehr gut Ok
Erweiternbar durch Programmiersprachen Beanshell/Java/Groovy Java SCALA
Test Protokoll und Systeme HTTPS/JDBC/MongoDB/JMS/AJP/LDAP/SMTP/TCP/… HTTPS HTTPS
RampUp Test Ja Ja Ja
Konstant Test Ja Ja Ja
Funtionstest Ja Ja Ja
Performancemessung Bedingt Ja ?