Archiv ‘Linux’

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

Samstag, 7. März 2020

Festplatte mit NTFS-Partition unter Linux mounten

Kürzlich fiel eine in einem ELK-System verwendete Magnetfestplatte aus. Ich ersetzte diese mit einer SSD, die hier seit einiger Zeit unbenutzt herumlag. Ergattert hatte ich diese bei einer Geschäftsauflösung in Kalifornien, wo sie ungefähr fünf Jahre in einem Schrank am Verstauben war.

Bevor ich die Festplatte formatierte, nahm mich der alte Inhalt darauf wunder. Die Platte wurde in einem Windows-System betrieben und war mit dem Microsoft NTFS Dateisystem formatiert.

Eine solche Festplatte mountet man folgendermassen unter Linux:

# apt-get install ntfs-3g
# mkdir /mnt/ntfs
# mount -t ntfs-3g /dev/sda1 /mnt/ntfs

Fazit: Nicht viel spannendes, vor allem dutzende ISO-Dateien von völlig veralteten Windows-Installationsmedien und Linux-Distributionen.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 7. März 2020

rkhunter betrachtet libkeyutils.so.1.9 als Malware

Kürzlich alarmierten mich Installationen von rkhunter auf einigen meiner Debian GNU/Linux-Server täglich über einen möglichen Malware-Befall:

Warning: The following processes are using suspicious files:
         Command: dig
           UID: 114    PID: 388
           Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
           Possible Rootkit: Spam tool component
         Command: dig
           UID: 417    PID: 388
           Pathname: 2799
           Possible Rootkit: Spam tool component
         Command: dig
           UID: 418    PID: 388
           Pathname: 2799
           Possible Rootkit: Spam tool component
         Command: dig
           UID: 419    PID: 388
           Pathname: 2799
           Possible Rootkit: Spam tool component

Nach etwas Recherche dann die Erkenntnis:

Christian Hesse (eworm): But rkhunter has a match on the plain file name „libkeyutils.so.1.9“, see /usr/bin/rkhunter from line 9765. I guess any malicious software used that file name in the past. […]

A. Bosch (progandy): It seems there was an SSHD rootkit in 2013 that used the name. That should be the reason for the entry in rkhunter.

Quelle: FS#63369 – [keyutils] RKhunter reports a possible rootkit

Die Lösung des Problems ist in dem Forumsbeitrag ebenfalls beschrieben. Nachdem ich in rkhunter.conf folgende Zeile eingefügt hatte, verschwand die Warnmeldung:

...
EXCLUDE_USER_FILEPROP_FILES_DIRS=/lib/x86_64-linux-gnu/libkeyutils.so.1.9
...
RTKT_FILE_WHITELIST=/lib/x86_64-linux-gnu/libkeyutils.so.1.9
...

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 9. November 2019

sed unter macOS an Hand von duplicity

Momentan gleise ich gerade die Migration von tarsnap mit Amazon S3 zu duplicity mit Backblaze B2 auf. Hauptgrund: Die verhältnismässig hohen Kosten.

Da MacPorts nur die veraltete duplicity-Version 0.7.17 liefert, welche mit folgender Fehlermeldung den Upload der Backup-Chunks verweigert …

Attempt 1 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 2 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 3 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 4 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Giving up after 5 attempts. AttributeError: B2ProgressListener instance has no attribute '__exit__'

… habe ich mir ein Script geschrieben, welches Version 0.7.19 herunterlädt, kompiliert und in meinem Heimverzeichnis installiert.

Diese Version wiederum hat aber leider das Problem, dass die shebang-Zeile in ~/Library/Python/2.7/bin/duplicity folgendermassen lautet:

#!/usr/bin/env python2
...

Meine MacPorts-Installation kennt kein Executable mit dem Namen python2 und duplicity stirbt deshalb mit folgender Fehlermeldung:

env: python2: No such file or directory

Mein Installationsscript passt das duplicity-Script nun mit sed, dem Stream Editor, an. Da mit macOS das BSD sed mitkommt und nicht das GNU sed, muss man für ein Inline-Replacement folgendermassen vorgehen, damit es klappt:

sed -i "" 's/env python2$/env python2.7/g' /Users/user/Library/Python/2.7/bin/duplicity

Die leeren Quotes nach -i müssen zwingend angegeben werden, ansonsten erscheint die nachfolgende Fehlermeldung (vgl. Sed: ’sed: 1: invalid command code R‘ on Mac OS X).

sed: 1: invalid command code m

Wer mehr über die Unterschiede in den verschiedenen seds erfahren will, liest sich folgenden Artikel durch BSD/macOS Sed vs. GNU Sed vs. the POSIX Sed specification.

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 11. September 2019

Die Absenderadresse inklusive Display Name eines mit Linux mail (bsd-mailx) gesendeten E-Mails festlegen

Im Grunde ganz simpel, wenn man den richtigen Befehl kennt:

echo "Test" | mail -a "From: Displayname <sender@server.tld>" -s "Subject" recipient@server.tld

Beim Verfassen dieses Blog-Posts fragte ich mich zudem spontan, mit welchem Debian-Paket das Executable /usr/bin/mail installiert wird. Bei dem Executable handelt es sich auf meinen Servern um einen Symlink auf /etc/alternatives/mail. Dieser Symlink ist wiederum ein Symlink auf /usr/bin/bsd-mailx. Somit stammt das Executable vom Debian-Paket bsd-mailx:

$ dpkg --list | grep mailx
ii  bsd-mailx                      8.1.2-0.20180807cvs-1        amd64        simple mail user agent

Sackgasse

Nur über Umwege zum Erfolg führte folgende Suchfunktion: Nachdem ich apt-files gemäss der Anleitung How To Find The Package That Provides A File (Installed Or Not) On Ubuntu, Debian Or Linux Mint installiert und die Datenbank einmalig gefüllt hatte, waren das die Resultate des Tools:

$ apt-file search /usr/bin/mail | grep mail$
python-twisted-core: /usr/bin/mailmail

Nicht was ich gesucht habe.

$ apt-file search /etc/alternatives/mail

Komisch. Ich habe diesen Symlink auf jeden Fall nicht eingerichtet; das muss doch von einem Debian-Paket gekommen sein?

$ apt-file search /usr/bin/bsd-mailx
bsd-mailx: /usr/bin/bsd-mailx

Jetzt aber!

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 14. April 2019

Coops geschwatziger Apache Sling

Entweder haben die Security-Kollegen bei Coop keine Härtungsrichtlinie für Apache erstellt, oder forcieren diese nicht für alle Server. Ich kann mir nicht vorstellen, dass es für ein irgendein derart exponiertes Unternehmen sinnvoll ist, derart viele Information über den verwendeten Web-Server und dessen Module preiszugeben:

image-8351

Ob How to Hide Apache Version Number and Other Sensitive Info auch auf Apache Sling anwendbar ist, weiss ich nicht — aber dieses Reporting sollte sich auch bei dem Server mit einer Konfigurationszeile abschalten lassen.

(Screenshot erstellt im Juni 2018; Antwort auf die Übermittlung eines Teilnahmeformulars für einen Mondovino-Wettbewerb)

Tags: , , , , , , ,
Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pkgcairo: Fehlende Debian-Pakete

Damit pip das Paket pkgcairo installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:

# apt-get install libcairo2 libcairo2-dev libjpeg-dev libgif-dev python-cairo

Leider halfen diese Pakete auf meinem System auch nicht viel, denn:

...
running build_ext
pycairo: new API
error: pycairo >= 1.11.1 required, 1.8.8 found.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pycurl: Could not run curl-config: [Errno 2] No such file or directory

Damit pip das Paket pycurl installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:

# apt-get install libcurl4-openssl-dev libssl-dev

Quelle: “Could not run curl-config: [Errno 2] No such file or directory” when installing pycurl

Sonst liest man folgende Fehlermeldungen:

...
Collecting pycurl
Downloading https://files.pythonhosted.org/packages/e8/e4/0dbb8735407189f00b33d84122b9be52c790c7c3b25286826f4e1bdb7bde/pycurl-7.43.0.2.tar.gz (214kB)
100% |████████████████████████████████| 215kB 15.2MB/s 
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 913, in <module>
    ext = get_extension(sys.argv, split_extension_source=split_extension_source)
  File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 582, in get_extension
    ext_config = ExtensionConfiguration(argv)
  File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 99, in __init__
    self.configure()
  File "/tmp/pip-install-dv_5N3/pycurl/setup.py", line 227, in configure_unix
    raise ConfigurationError(msg)
__main__.ConfigurationError: Could not run curl-config: [Errno 2] No such file or directory

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

pip: pygobject: Failed building wheel for pygobject

Damit pip das Paket pygobject installieren kann, müssen auf dem Debian-System folgende Pakete installiert sein:

# apt-get install libglib2.0-dev libgirepository1.0-dev

Sonst liest man folgende Fehlermeldungen:

...
running build_ext
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
Command '('pkg-config', '--print-errors', '--exists', 'glib-2.0 >= 2.38.0')' returned non-zero exit status 1

Try installing it with: 'sudo apt install libglib2.0-dev'

----------------------------------------
Failed building wheel for pygobject
Running setup.py clean for pygobject

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2019

Alle mit pip installierten Pakete aktualisieren

Leider gibt es beim Python-Paketmanager pip („Pip installs Packages“) keine Routine à la apt-get update && apt-get upgrade, um alle installierten Pakete zu aktualisieren.

Mit folgendem Befehl kommt man aber verdammt nah an diese Funktionalität dran:

# pip install -U $(pip freeze | awk '{split($0, a, "=="); print a[1]}')

Quelle: update all installed python packages with pip

Das habe ich gestern auf einem System gemacht, musste aber leider feststellen, dass pip selbst auf einem relative „einfachen“ System bei bestimmten Paketen ins Straucheln gerät. Es ist also viel Zeit und Handarbeit nötig, um sicher zu sein, dass alle Pakete aktualisiert wurden.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen