Posts Tagged ‘grep’

Dienstag, 1. Dezember 2020

Mehrere Unix Timestamps auf der macOS Kommandozeile in Daten umwandeln

Voraussetzung: MacPorts und das Utility gdate (unter Linux: date) (Teil des Pakets coreutils) sind installiert.

$ python -mjson.tool < netatmo.json | grep utc | cut -d ":" -f 2 | awk '{print $1}' | xargs -I '{}' gdate -d "@{}"
Mon Nov 30 22:28:06 CET 2020
Mon Nov 30 22:27:57 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:27:38 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 17:07:34 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:46 CET 2020
Mon Nov 30 22:07:42 CET 2020
Mon Nov 30 22:07:00 CET 2020
Mon Nov 30 22:07:07 CET 2020

Im vorliegenden Fall nahm mich Wunder, wann meine Netatmo-Sensoren das letzte Mal einen Wert an den Server übertragen hatten.

Mindestens zwei Stationen mit einer handvoll Sensoren haben den Wert seit gestern nicht mehr aktualisiert. Ich vermute auf Grund dieses Absturzes.

Hierzu lud ich über die Netatmo API das JSON mit den Daten aller meiner Stationen herunter, gab das JSON schön formatiert aus (ein Key-Value Pair pro Zeile), selektierte die Zeilen mit dem Attribut time_utc, isolierte deren Wert — die Unix Timestamp (ein Integer), entfernte die Leerzeichen vor und nach dem Wert und übergab die Liste der Werte mittels xargs dem Tool gdate zur Umwandlung in ein menschenlesbares Datum.

Tags: , , , , , , , , , , , , , ,
Labels: Apple, IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. März 2020

Unter Linux Nicht-ASCII-Charakter in einer Datei ausgeben

Unter Linux verwendet man folgenden Befehl:

$ grep --color='auto' -P -n "[^\x00-\x7F]" dump.txt

Quelle: How do I grep for all non-ASCII characters?

macOS‘ grep unterstütz dies leider nicht.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 23. Januar 2020

grep interpretiert Dateiinhalte fälschlicherweise als Binärdaten

Ein Bash-Script, welches täglich meine SVN-Logs auf unerwartete Zugriffe durchgeht, meldete mir gestern:

...
1  Binary  file  (standard  input)  matches
...

Dabei handelt es sich um eine Meldung von grep, mit welchem ich die Apache-Logs filtere. Offenbar enthält das Access Log von dieser Woche Inhalte, die grep glauben machen, dass es sich um eine Binärdatei und nicht um eine ASCII/UTF-8-Datei handelt. In Durchgängen in früheren Monaten und Wochen trat dieses Problem nicht auf.

Wenn man sich sicher ist, dass man grep ASCII-Daten füttert, kann man dies mit einem Argument forcieren:

$ grep --text README.txt

So klappt die Auswertung nun auch wieder mit meinem Bash-Script.

Nachtrag

Gemäss diesem Unix & Linux Stack Exchange-Artikel erachtet grep eine Datei als Binär, wenn es erstmalig auf das NUL-Zeichen trifft.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Dezember 2019

Netflix mit zehntausenden DNS-Queries pro Tag von meinem Sony KD-55AF8

Seit ein paar Monaten steht in unserer Wohnung der erste richtig „smarte“ TV, ein Sony KD-55AF8, auf welchem mittlerweile Android TV 8.0 installiert ist.

Seit gestern analysiere ich die DNS-Queries, die von Netzwerkgeräten im LAN an den lokalen DNS-Forwarder gestellt werden sowohl quantitativ (welche Domains werden am meisten aufgelöst, welches Gerät setzt die meisten Queries ab und in welcher Stunde des Tages gibt es die meisten Queries) sowie qualitativ (werden von SANS als Suspicious eingestufte Domains aufgelöst, was ein Zeichen für Malware-Befall sein könnte). Ich war nicht schlecht überrascht, dass ein TV-Gerät, welches allerhöchsten zwei von 24 Stunden im Tag „läuft“, der Spitzenreiter aller Queries ist. Ich zählte innerhalb von 24 Stunden sage und schreibe 90’498 Queries. Gefolgt wurde der TV vom Server selber, auf welchem der DNS-Server läuft mit 72’411 Queries. Auf Platz drei dann ein Client mit noch 7’162 Queries.

Heute nun nahm mich Wunder, was zum Teufel der TV ständig abzufragen hat. Hier das Resultat der Analyse der named-Logs vom Vortag (10.1.2.3 ist die (fiktive) IPs meines TVs):

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
   1284 clients3.google.com
   1220 connectivitycheck.gstatic.com
   1196 www.google.com
   1195 mtalk.google.com
    994 nrdp52-appboot.netflix.com
    324 events.cid.samba.tv
    162 us.edge.bamgrid.com
    142 watch.product.api.espn.com
    118 clients4.google.com
    109 androidtvchannels-pa.googleapis.com
    105 footprints-pa.googleapis.com
     91 fling.cid.samba.tv
     83 www.youtube.com
     52 mdh-pa.googleapis.com
     41 clientservices.googleapis.com
     37 www.googleapis.com
     35 play.googleapis.com
     34 platform.cid.samba.tv
     28 android.googleapis.com
     13 www.gstatic.com
     12 youtubei.googleapis.com
     10 static.doubleclick.net
      7 www.netflix.com
      7 android.clients.google.com
      6 api-cdn.arte.tv
      5 lh3.googleusercontent.com
      5 antv-26-sony-bravia4kgbatv3-414000300.api.amazonvideo.com
      4 sdk.hockeyapp.net
      4 middleware.7tv.de
      4 devices.ted.com
      4 cdn-gl.imrworldwide.com
      4 android.googleapis.com
      3 zdf-cdn.live.cellular.de
      3 geoloc.arte.tv
      3 geocheck.sim-technik.de
      3 config.ioam.de
      3 cdn.meta.ndmdhs.com
      3 bam-sdk-configs.bamgrid.com
      2 sdk.imrworldwide.com
      2 api.meta.ndmdhs.com
      1 www.sony.net
      1 www.sony-asia.com
      1 voledevice-pa.googleapis.com
      1 update.biv.sony.tv
      1 time.android.com
      1 static-cdn.arte.tv
      1 sportscenter.api.espn.com
      1 secure.espncdn.com
      1 safebrowsing.googleapis.com
      1 r4---sn-1gieen7e.gvt1.com
      1 people-pa.googleapis.com
      1 ocsp.int-x3.letsencrypt.org
      1 metadata.erabu.sony.tv
      1 log.core.cloud.vewd.com
      1 isrg.trustid.ocsp.identrust.com
      1 images.erabu.sony.tv
      1 fls-na.amazon.com
      1 cloudfront.xp-assets.aiv-cdn.net
      1 cert-cdn.meta.ndmdhs.com
      1 cdn.espn.com
      1 browserjs-legacy.core.cloud.vewd.com
      1 broadband.espn.com
      1 bravia-cfgdst-ore-pro.bda.ndmdhs.com
      1 bdcore-apr-lb.bda.ndmdhs.com
      1 app-measurement.com
      1 api.erabu.sony.tv
      1 api.auth.adobe.com
      1 ajax.googleapis.com

Netflix führt die Statistik unangefochten an:

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn | grep -i "netflix\|nflx"
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
    994 nrdp52-appboot.netflix.com
      7 www.netflix.com

Von den täglich über 90’000 Queries entfallen über 90 Prozent auf Netflix-Domains:

$ cat queries.log.1 | grep 10.1.2.3 | grep -i "netflix\|nflx" | wc -l
84114

Dabei schauen wir — wenn überhaupt — mit der Netflix-App auf dem Apple TV 4K mit einer anderen IP Netflix, und nie mit der Android TV App.

Netflix, shame on you! Die Frage, wieso die Netflix-App das macht, konnte ich bis jetzt noch nicht beantworten, werde es hier aber nachtragen, sollte ich es erfahren.

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT

10 Kommentare | neuen Kommentar verfassen

Donnerstag, 29. Oktober 2015

Fortschritt von apt-get mittels der Log-Datei mitverfolgen

Wer nach langer, langer Zeit apt-get wieder einmal ausführt, kann je nachdem Stunden warten, bis das Upgrade abgeschlossen ist.

Um sich einen Überblick zu verschaffen, wie weit die Installation bereits vorgeschritten ist, kann sich der Log-Datei der Anwendung behelfen und diese in einem zweiten Terminal analysieren.

Als erstes findet man heraus, wie viele Debian-Pakete bereits heruntergeladen und entpackt wurden:

# cat /var/log/apt/term.log | sort | grep ^Unpacking | wc -l

Ist der Upgrade-Prozess bereits weiter fortgeschritten, kann man sich mit folgendem Befehl anschauen, wie viele Pakete bereits effektiv installiert wurden:

# cat /var/log/apt/term.log | sort | grep ^Setting | wc -l

Tags: , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Montag, 2. März 2015

SAP-Datenexporte mit Unix-Tools filtern

Kürzlich stand ich vor der Aufgabe, einen 1.8 Millionen Zeilen umfassenden SAP-Export (SE16N, sowie Hintergründe) nach genau 16-stelligen Zahlenfolgen zu filtern. Anstelle Excel (kann sowieso nicht mit 1.8 Millionen Zeilen umgehen) oder das komplizierte ACL zu verwenden, entschied ich mich stattdessen, die Plaintext-Datei mit Unix-Tools zu filtern.

Inspiration dazu war der kürzlich auf Hacker News erschienene Artikel Command-line tools can be 235x faster than your Hadoop cluster.

Unter Windows klappt das problemlos, wenn man Github für Windows installiert hat – die Installation bringt nämlich eine Linux-Shell mitsamt den grundlegendsten Unix-Tools mit, so auch cat, grep und wc.

Um den SAP-Export mit „|“ als Feldabgrenzung auf den gesuchten Pattern zu filtern, habe ich folgenden Befehl verwendet:

$ cat export.txt | grep -E "\|[4-5]{1}[0-9]{15}" > export-filtered.txt

Dieser Befehl speichert alle Zeilen aus der Datei export.txt, welche 16-stellige Zahlen enthalten, die mit 4 oder 5 beginnen und am Anfang eines Feldes stehen (deshalb \|), in die Datei export-filtered.txt.

So entfiel der Import über eine graphische Oberfläche (mit der obligatorischen Titelleiste „Keine Rückmeldung“) und die Sache war innert 5 Minuten gegessen.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 31. August 2014

Unter Linux einen Kommandozeilenbefehl regelmässig in Sekundenabständen ausführen (ohne cron)

Kürzlich spielte ich wieder einmal eine Sicherung des Inhaltes der 2 GB SD-Card, welche in meinem uralten TomTom ONE Europe steckt, zurück auf das Gerät. Da das Navigationsgerät nur über einen USB1-Anschluss verfügt, handelt es sich um eine entsprechend langwierige Angelegenheit.

Da ich die Sicherung auf der Kommandozeile unter Verwendung von rsync und ohne irgendwelche aussergewöhnlichen Kommandozeilenoptionen durchführte (-av reicht mir in solchen Fällen), musste ich mir einen anderen Weg überlegen, um den Fortschritt zu visualisieren.

Ich öffnete mir dazu ein zweites Kommandozeilenfenster. Damit ich den Computer kurzzeitig verlassen und mich bei der Rückkehr jeweils vom Fortschritt überzeugen konnte, startete ich folgenden Befehl:

$ watch -n 1 "df -k | grep INTERNAL | awk '{print \$4} {print \$5}'"

Mit Hilfe des Unix-Tools watch kann ein Befehl alle definierten n Sekunden wieder ausgeführt werden (hier: n -1, sprich jede Sekunde). Den Befehl fügte ich in Anführungszeichen bei, weil dieser Sonderzeichen und Pipes enthielt.

Konkret wird das Tool df aufgerufen, welches Grösseninformationen über gemountete Volumes ausgibt. Mittels grep filtere ich den Datenträger heraus, welcher mich interessiert. Und mittels awk isoliere ich dann die Grössenangaben über den noch verfügbaren Speicher (-k, das heisst in Kilobytes). Diese Zahl sollte im beschriebenen Anwendungsfall stetig nach unten zählen, bis der Kopiervorgang zu Ende ist.

WICHTIG: Damit awk in einem solchen Konstrukt funktioniert, müssen die Dollarzeichen escaped werden.

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 7. November 2013

Die gängigsten Unix-Kommandozeilen-Tools unter Windows

Welcher Linux-Benutzer kann unter Windows schon auf nützliche Kommandozeilen-Tools wie cat, cut, sed, awk, tr und Konsorten verzichten? Das Complete package, except sources der CoreUtils for Windows rüstet unter Windows die gängigsten Linux-Kommandos nach.

Damit Windows nach der Installation die Linux-Befehle aber auch wirklich findet, muss der Pfad zu den ausführbaren Dateien in die Windows-Umgebungsvariable PATH aufgenommen werden. Dies geschieht folgendermassen:

  1. Computer
  2. Systemeigenschaften
  3. Erweitert
  4. Umgebungsvariablen…
  5. Path
  6. Bearbeiten…

An den String fügt man den Pfad C:\Program Files (x86)\GnuWin32\bin; (Windows 7 mit 64-bit CPU) respektive C:\Program Files\GnuWin32\bin; an.

Sobald man nun die Windows-Kommandozeile öffnet, hat man die ganze Palette an Befehlen zur Hand …

… ausser grep!

Dieses muss man als eigenständiges Installationspaket von derselben Web-Site herunterladen und installieren:

Grep for Windows

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 7. November 2012

Microsoft Domain Policies mit grep unter Windows filtern

Herkules-Aufgabe am Tag, an welchem Barack Obama zum neuen alten Präsident der USA gewählt wurde: Ich musste aus über 150 Domain Policies im HTML-Format diejenigen Dokumente herausfiltern, welche Passworteinstellungen enthielten. Und dies – wohlgemerkt – unter Windows. Wie macht man das?

Im Grund genommen ist das ganze keine grosse Hexerei:

  1. msysgit herunterladen
  2. msysgit installieren
  3. Git bash starten
  4. Ins Verzeichnis mit den Policies wechseln
  5. Folgenden Befehl ausführen:
    $ grep "Enforce password" *.html

Doch oha! grep liefert keine einzige Datei zurück, welche Kennwortrichtlinien enthält? Ein cat auf eine Beispieldatei zeigt, dass zwischen jedem Buchstaben ein Leerzeichen folgt. Indem man eine Beispieldatei mit Notepad++ öffnet, findet man heraus, dass die Exporte vom Domain Controller mit UCS-2 Little Endian enkodiert sind (der Zeichensatz steht in Notepad++ unten rechts in der Statusleiste).

Was nun? Ich habe mir kurzerhand ein bash-Script geschrieben, um die Dateien on-the-fly in ein für grep verständliches Format (UTF-8) zu konvertieren:

#!/bin/sh

if [ $# -lt 2 ]
then
	echo "Usage: $0 [extension of files to search] [string to search for in files]"
	exit 1
fi

for i in *.$1
do
	RES=`iconv -f UCS-2LE -t UTF-8 "$i" | grep "$2"`
	RET=$?

	if [ $RET -eq 0 ]
	then
		echo "$RET - $i"
		echo $RES
		echo ""
	fi
done

exit 0

Das Script tut folgendes: Zuerst liest es alle Dateien im aktuellen Verzeichnis aus, welche auf .html enden. In einer Schleife wird nun jede gefundene Datei mittels iconv von UCS-2LE nach UTF-8 konvertiert und an grep weitergepipet. grep sucht im Zeichensalat nach „Enforce password“. Die bash-Variable $? speichert das Resultat dieses Befehls; sprich 0 falls die Zeichenkette gefunden wurde, 1 (oder eine andere Zahl ungleich 0), wenn grep gestolpert ist oder einfach nichts gefunden hat. Ist $RET gleich 0, wird der Dateiname ausgegeben.

Schlussendlich fanden sich in den 150 Dateien gerade mal 6 Stück, welche Passworteinstellungen enthalten. Doch statt dem fehleranfälligen manuellen Geklicke habe ich quelloffene Tools, gepaart mit ein wenig Scripting-Wissen für mich arbeiten lassen.

Gut zu Wissen

Wer die Namen der Zeichensätze nicht auswendig weiss, dem wird unter folgendem Link geholfen:

libiconv

Tags: , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen