Hallo,
ich habe ein System von Debian 8 auf 9 angehoben, das mache ich nicht zum ersten Mal. Diesmal habe ich aber Nachwehen mit grep und logcheck. Grep matcht in den Logfiles bis zum Tag des Upgrades und meldet dann noch "Übereinstimmungen in Binärdatei gefunden". Logcheck arbeitet mit einem ignore-file voller regex, die plötzlich nicht mehr matchen, ich vermute hier einen Zusammenhang.
Ich könnte grep -a nehmen. Ich könnte die logs einmal rotieren (verifiziert, funktioniert dann wieder alles).
Ich möchte aber lieber wissen, was da warum passiert ist. Ich möchte nicht mitten im Monat die Logs rotieren. Ich kann nicht alle Helfer pauschal auf grep -a umstellen.
Wie also kann ich Dateien identifizieren, bei denen grep auf die Binäridee kommen wird (offenbar werden die ja erst "mittig" binär)? Wie kann ich die Dateien konvertieren? Ich suche was in der Art 'finde dateien | prüfe und konvertiere'.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Ronny,
On Thu, Feb 14, 2019 at 10:04:09 +0100, Ronny Seffner wrote:
ich habe ein System von Debian 8 auf 9 angehoben, das mache ich nicht zum ersten Mal. Diesmal habe ich aber Nachwehen mit grep und logcheck. Grep matcht in den Logfiles bis zum Tag des Upgrades und meldet dann noch "Übereinstimmungen in Binärdatei gefunden".
Um welche Logdateien geht es genau?
Wie also kann ich Dateien identifizieren, bei denen grep auf die Binäridee kommen wird (offenbar werden die ja erst "mittig" binär)? Wie kann ich die Dateien konvertieren? Ich suche was in der Art 'finde dateien | prüfe und konvertiere'.
Du koenntest zunaechst mal "file" und "file -i" auf die betreffenden Dateien ansetzen. Leider kann "file" nicht ausgeben, ab welchem Offset eine Datei "binaer" wird, wobei der Begriff auch nicht klar definiert ist. Gueltiges UTF-8 Encoding ist auch "binaer", allerdings koennen file und grep damit umgehen, und erkennen es daher als Text.
Die Dateien zu konvertieren setzt voraus, dass man ihr Encoding erkennen kann. Mit "file -i" geht das zu einem gewissen Grad, aber spaetestens wenn eine Datei an verschiedenen Offsets unterschiedliche Encodings enthaelt, kann "file -i" keine eindeutige Information mehr liefern. Wenn eine Datei *wirklich* an einem bestimmten Offset Binaermuell enthaelt, laesst sie sich nicht sinnvoll konvertieren.
Gruss, Christian
Hallo,
Ich würd zur manuellen Binärbaumsuche greifen: teile die Datei in zwei Hälften (dd), greppe in beiden nach irgendwas vorhandenem (ein "e"), mit einer matchenden Hälfte wieder von vorn beginnen, bis die Hälfte klein genug ist, dass man es mit bloßem Auge sofort sieht.
Beste Grüße Fabian
Am 14. Februar 2019 14:53:41 MEZ schrieb Christian Perle chris@linuxinfotag.de:
Hallo Ronny,
On Thu, Feb 14, 2019 at 10:04:09 +0100, Ronny Seffner wrote:
ich habe ein System von Debian 8 auf 9 angehoben, das mache ich nicht
zum
ersten Mal. Diesmal habe ich aber Nachwehen mit grep und logcheck.
Grep
matcht in den Logfiles bis zum Tag des Upgrades und meldet dann noch "Übereinstimmungen in Binärdatei gefunden".
Um welche Logdateien geht es genau?
Wie also kann ich Dateien identifizieren, bei denen grep auf die
Binäridee
kommen wird (offenbar werden die ja erst "mittig" binär)? Wie kann
ich die
Dateien konvertieren? Ich suche was in der Art 'finde dateien | prüfe
und
konvertiere'.
Du koenntest zunaechst mal "file" und "file -i" auf die betreffenden Dateien ansetzen. Leider kann "file" nicht ausgeben, ab welchem Offset eine Datei "binaer" wird, wobei der Begriff auch nicht klar definiert ist. Gueltiges UTF-8 Encoding ist auch "binaer", allerdings koennen file und grep damit umgehen, und erkennen es daher als Text.
Die Dateien zu konvertieren setzt voraus, dass man ihr Encoding erkennen kann. Mit "file -i" geht das zu einem gewissen Grad, aber spaetestens wenn eine Datei an verschiedenen Offsets unterschiedliche Encodings enthaelt, kann "file -i" keine eindeutige Information mehr liefern. Wenn eine Datei *wirklich* an einem bestimmten Offset Binaermuell enthaelt, laesst sie sich nicht sinnvoll konvertieren.
Gruss, Christian -- Christian Perle chris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Hallo Christian,
danke, dass Du Dich meiner annimmst.
Um welche Logdateien geht es genau?
Zum Beispiel auth.log, syslog oder auch mail.log. Also alles was durch syslog-ng verwaltet wird.
Du koenntest zunaechst mal "file" und "file -i" auf die betreffenden Dateien ansetzen.
Das hatte ich schon am Start:
ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines
ns2:~# file -i /var/log/syslog /var/log/syslog: text/plain; charset=us-ascii
ns2:~# locale LANG=de_DE.UTF-8 LANGUAGE= LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Fabian,
auch Dir ein Dank für die Ideen.
Ich würd zur manuellen Binärbaumsuche greifen: teile die Datei in zwei Hälften (dd), greppe in beiden nach irgendwas vorhandenem (ein "e"), mit einer matchenden Hälfte wieder von vorn beginnen, bis die Hälfte klein genug ist, dass man es mit bloßem Auge sofort sieht.
Ich bin anders rangegangen aber mit der selben Motivation. Ich habe die Datei im vi offen und sehe zwischen der letzten grepbaren Zeile bis zum ersten Auftreten des Suchstrings im "binären Bereich" eben nichts augenscheinliches. Muss man vi noch befähigen "Sonderzeichen" sichtbar zu machen?
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo,
wenn du die Ecke eingrenzen kannst, würde ich sie mir mit "hexdump" oder was immer die Kommandozeile hergibt betrachten, am besten im einem Tool das hex und Ascii nebeneinander zeigt.
Beste Grüße Fabian
Am 14. Februar 2019 17:13:00 MEZ schrieb Ronny Seffner ronny@seffner.de:
Hallo Fabian,
auch Dir ein Dank für die Ideen.
Ich würd zur manuellen Binärbaumsuche greifen: teile die Datei in
zwei
Hälften (dd), greppe in beiden nach irgendwas vorhandenem (ein "e"),
mit
einer matchenden Hälfte wieder von vorn beginnen, bis die Hälfte
klein
genug ist, dass man es mit bloßem Auge sofort sieht.
Ich bin anders rangegangen aber mit der selben Motivation. Ich habe die Datei im vi offen und sehe zwischen der letzten grepbaren Zeile bis zum ersten Auftreten des Suchstrings im "binären Bereich" eben nichts augenscheinliches. Muss man vi noch befähigen "Sonderzeichen" sichtbar zu machen?
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hi,
Am Thu, 14 Feb 2019 17:13:00 +0100 schrieb "Ronny Seffner" ronny@seffner.de:
Muss man vi noch befähigen "Sonderzeichen" sichtbar zu machen?
"-b" vermutlich - jedenfalls für vim. Zeigt vim bei mir aber eh auch so an, wie sich vi verhält, weiß ich nicht (Gnade der späten Geburt...)
Ansonsten das bereits erwähnte hexdump, mit -C, ich vermute irgendwo ist da ein NUL byte drin, oder horizontaler Tab oder irgendsowas Verirrtes. Ich hatte neulich ein ähnliches Problem mit Logfiles, kann mich aber gerade absolut nicht daran erinnern, was genau da war, da ich seither leider durch einen Türrahmen gegangen bin und das bei mir immer zu partiellem Gedächtnisverlust führt :/ Mal sehen, obs meinem Kollegen noch einfällt.
Oder, eben gebastelt, schau mal die Häufigkeitsverteilung der Bytes an.
hexdump -v -e '/1 "%02X\t"' -e '/1 "%c\n"' FILE|sort|uniq -c
Der zweite Block nach -e printed das Zeichen noch, das kann aber natürlich die Ausgabe stören je nach Sonderzeichen, ggf. also weglassen, und die seltensten Zeichen voran:
hexdump -v -e '/1 "%02X\n"' FILE|sort|uniq -c|sort -hr
Grüße Carsten
"Bernd Müller" be-mueller@gmx.de (Do 14 Feb 2019 21:20:35 CET):
Das Problem mit den Log-Dateien entsteht, wenn der Prozess Speicher für das Logfile angefordert hat, aber aus irgendeinem Grund dann doch nicht in die Datei schreibt. In diesem Fall werden einfach Null-Bytes in das Logfile
Du meinst, syslog-ng alloziert schon mal genug Platz, um dann anschließend reinzuschreiben? Mit mmap(2), oder einfach direkt im File mit lseek(2)? Das hielte ich für sehr gewagt, weil dann Tools, die am Ende des Logfiles mitlesen möchten, ein Problem hätten.
Ist das ein xfs, was Du da verwendest?
Ich möchte aber lieber wissen, was da warum passiert ist. Ich möchte nicht mitten im Monat die Logs rotieren. Ich kann nicht alle Helfer pauschal auf grep -a umstellen.
Haben diese Files auffällige Größen (irgendwelche Vielfaches von 4k oder so)
-- Heiko
Hallo Ronny,
On Thu, Feb 14, 2019 at 17:04:31 +0100, Ronny Seffner wrote:
Um welche Logdateien geht es genau?
Zum Beispiel auth.log, syslog oder auch mail.log. Also alles was durch syslog-ng verwaltet wird.
Hmm, ich kann mich nicht erinnern, dass syslog-ng auf Debian der Default-Syslogserver waere. Eigentlich ist das doch rsyslogd?
ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines
Wenn eine Datei nur lang genug ist, erkennt file nicht, wenn sich irgendwo weiter hinten Binaermuell darin befindet. Probeweise habe ich meine /var/log/syslog (aktuell 3 MB) nach /tmp kopiert und in die Kopie ab Offset 1500000 eine Folge von 8000 Nullbytes geschrieben:
$ ls -l syslog -rw-r----- 1 chris chris 3145267 Feb 14 22:58 syslog
$ dd if=/dev/zero of=syslog conv=notrunc bs=1 seek=1500000 count=8000 8000+0 records in 8000+0 records out 8000 bytes (8,0 kB, 7,8 KiB) copied, 0,0191606 s, 418 kB/s
$ file -i syslog syslog: text/plain; charset=us-ascii
Voila, file sagt "ascii", obwohl 8000 Nullbytes drin sind.
Gruss, Christian
Christian Perle chris@linuxinfotag.de (Do 14 Feb 2019 23:11:11 CET):
ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines
Wenn eine Datei nur lang genug ist, erkennt file nicht, wenn sich irgendwo weiter hinten Binaermuell darin befindet. Probeweise habe ich meine /var/log/syslog (aktuell 3 MB) nach /tmp kopiert und in die Kopie ab Offset 1500000 eine Folge von 8000 Nullbytes geschrieben:
File schaut nur am Anfang nach magic patterns, aus dem Bauch würde ich sagen, daß schon nach ca 1k Schluß ist. Ich weiß nicht, ob es führende binäre Nullen „skippen“ würde, glaube es aber nicht.
-- Heiko
On Fri, Feb 15, 2019 at 11:11:18AM +0100, Heiko Schlittermann wrote:
Christian Perle chris@linuxinfotag.de (Do 14 Feb 2019 23:11:11 CET):
ns2:~# file /var/log/syslog /var/log/syslog: ASCII text, with very long lines
Wenn eine Datei nur lang genug ist, erkennt file nicht, wenn sich irgendwo weiter hinten Binaermuell darin befindet. Probeweise habe ich meine /var/log/syslog (aktuell 3 MB) nach /tmp kopiert und in die Kopie ab Offset 1500000 eine Folge von 8000 Nullbytes geschrieben:
File schaut nur am Anfang nach magic patterns, aus dem Bauch würde ich sagen, daß schon nach ca 1k Schluß ist. Ich weiß nicht, ob es führende binäre Nullen „skippen“ würde, glaube es aber nicht.
man 1 file man 5 magic
da passiert viel "Magie" :-)
Default für die maximale Anzahl an Bytes ist laut der manpage von file 1 MiB, ob aber überhaupt soviel gelesen wird, hängt aber vom Dateityp ab.
In der Definition für libmagic kann man für bestimmte Tests Offsets angeben, wenn die magischen Bytes erst später in einer Datei kommen, für den Fall von oben wird das aber wahrscheinlich nicht helfen. Das Überspringen von Null-Bytes hab ich nicht gefunden.
Viele Grüße Jan
lug-dd@mailman.schlittermann.de