Tag: shell

[Quicktip] Wie man Daten von Freenas auf einen USB Datenträger kopiert

Um Daten von eurem FreeNAS Server auf einen FAT32 formatierten USB Stick/USB Festplatte zu bekommen sind folgende Schritte notwendig:

  • Per SSH auf die Console des Servers verbinden
  • Verzeichnis für den Stick erstellen:
    mkdir /mnt/USB-Stick
  • Finde mittels
    gpart list
    heraus, wie die Bezeichnung des USB Sticks ist (z.B. “da1p1”)
  • Nun mountest du den Stick in das entsprechende Verzeichnis, welches du unter Punkt zwei angelegt hast
    mount -v -t msdosfs /dev/da1p1 /mnt/USB-Stick
  • mittels der Kommandos “cp” und “mv” kannst du nun auf der Console die gewünschten Dateien kopieren
  • wenn du fertig bist, kannst du per
    umount /mnt/USB-Stick
    den Stick wieder auswerfen und dann anschließend vom Server abziehen.

Pinch Geste in iTerm2 deaktivieren

Im großartigen MacOS Terminal Programm iTerm2 gibt es ein sehr lästiges Feature, mit welchem man mittels Trackpad-Pinch-Geste (also die aufziehende Geste zum Vergrößern von Bildern z.B.) die Schriftgröße des aktuellen Terminals verändert. Leider gibts dafür auch keine direkte Einstellung, aber wenigstens ein hidden Setting. Und das aktivierst du so:

  1. Öffne die “terminal” Applikation
  2. gib folgenden Befehl ein:
    defaults write com.googlecode.iterm2 PinchToChangeFontSizeDisabled -bool true

     

Freenas Jail meldet, dass das Shared Object libdl.so.1 fehlt

Beim Herumspielen mit einem neuen Jail in meiner Freenas Instanz konnte ich zwar alle möglichen Packages installieren, jedoch meldeten die diversen Tools immer wieder folgendes (in diesem Fall bei python3):

Shared object "libdl.so.1" not found, required by "python3.5"

 

Soweit ich es herauslesen konnte, liegt das wohl an ein paar umgebauten Paketen im aktuellen Freenas Jail Template, weswegen es zu dieser Unstimmigkeit kommt. Um das Problem vorerst zu lösen, kann man sich mittels eines kleinen Downgrades behelfen:

  • die Datei “/usr/local/etc/pkg.conf” bearbeiten und in der ersten Zeile folgendes hinzufügen:
    set OSVERSION = 1101001
  • in der Datei /etc/pkg/FreeBSD.conf die Property “url” auf folgendes ändern:
    url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  • in der Datei /usr/local/etc/pkg/repos/FreeBSD.conf die Property “url” auf folgendes ändern:
    url: "pkg+http://pkg.FreeBSD.org/freebsd:11:x86:64/release_2",
  • und dann mittels folgender Befehle das Downgrade starten:
    pkg update -f
pkg upgrade -f

Alle aufkommenden Fragen mit y bestätigen, und schon sollten Python und co wieder laufen.

Quelle: forums.freenas.org

FreeBSD pkg install meldet size mismatch Fehler

Die Fehlermeldung sieht in der Regel so oder so ähnlich aus:

pkg: cached package ...: size mismatch, fetching from remote
pkg: cached package ...: size mismatch, cannot continue

Um das Problem zu lösen, löscht man sämtliche caches von pkg mit folgenden Commands:

pkg clean
rm -rf /var/cache/pkg/*
pkg update -f
rm /var/db/pkg/repo-*.sqlite
pkg bootstrap -f

Beim Ausführungen von Java jnlp Anwendungen erscheint ein Access Denied Fehler

Beim Ausführen einer Java Anwendung mit einer jnlp Datei bekam ich komischerweise immer wieder Fehlermeldungen „java.io.FilePermission“ für die Datei „/usr/bin/xprop“. Die Datei war im System vorhanden und durfte auch von jedem ausgeführt werden, selbst mit Sudo kam der Fehler.

Die Lösung des Problems ist zwar relativ leicht, aber mal wieder sehr ärgerlich: es ist ein Fehler in der OpenJDK und in meinem Fall der icedtea-netx Implementierung. Und um diesen zu umgehen muss man leider die original Oracle JAVA JRE runterladen und installieren.

Wichtig hierbei: man muss wohl zwingend die tar.gz Variante und nicht die RPM Variante nehmen, da nur diese „javasw“ enthält.

Das Vorgehen für die Installation ist:

  • openjdk und co vom System schmeissen (es geht auch anders, aber man muss die Sache ja nicht unnötig verkomplizieren)
  • unter http://www.oracle.com/technetwork/java/javase/downloads/index.html den Download Button unter „JRE“ anklicken und auf der folgenden Seite die AGB akzeptieren und dann die entsprechende tar.gz für 64bit oder 32bit herunterladen
  • tar.gz entpacken und den Ordner nach /usr/java/[ORDNER_NAME] verschieben
  • anschließend (keine Ahnung ob das der richtige Weg ist, aber er funktioniert) unter /usr/bin per Link die java und javasw Binaries verlinken:
cd /usr/bin
ln -s /usr/java/[ORDNER_NAME]/bin/java
ln -s /usr/java/[ORDNER_NAME]/bin/javasw

Nun könnt ihr die jnlp Datei einfach per
javasw [DATEI].jnlp aufrufen.

[Quicktip] Wie installiere ich ein CA Zertifikat unter Debian Linux

Wenn ihr ein CA Zertifikat bzw. das zugehörige pem File auf eurem Debian Linux installieren möchtet, dann sind folgende Schritte nötig:

  • pem File unter /usr/share/ca-certificates ablegen
  • Datei /etc/ca-certificates.conf editieren und um den gerade hinzugefügten Dateinamen ergänzen. Falls ihr die Datei direkt in /usr/share/ca-certificates hinterlegt habt, dann reicht [Dateiname].pem, wenn ihr einen Unterordner erzeugt habt, dann ist der Eintrag [Unterordner]/[Dateiname].pem
  • als root bzw. per sudo “update-ca-certificates“ ausführen. Dort sollte euch gemeldet werden, dass mindestens ein Eintrag hinzugefügt wurde
  • fertig 😉

[Quicktip] Vagrant up kann die Netzwerkinterfaces nicht starten

Wenn ihr mit

vagrant up

eine virtuelle Maschine starten wollt und während des Hochfahrens die Fehlermeldung kommt, dass das Interface eth1 (oder eth2 usw.) nicht hochgefahren werden konnte, dann probiert folgendes:

  • Virtualbox öffnen
  • die laufende Vagrant Maschine im Virtualbox beenden und anschließend dort auch wieder starten, damit ihr diese direkt steuern könnt
  • anschließend mittels User „vagrant“ und Passwort „vagrant“ einloggen
  • mittels “sudo su“ zu root wechseln
  • “/etc/network/interfaces“ mit vi aufrufen und alle Zeilen löschen, die nichts mit eth0 zu tun haben. In der Regel sollte über diesen Zeilen „# VAGRANT START“ stehen
  • Anschließend noch den Ordner “/etc/udev/rules.d/70-persistent-net.rules“ mittels “rm -rf“ löschen
  • die Maschine herunterfahren und Virtualbox beenden
  • nun mittels „vagrant up“ die Maschine wieder starten, sie sollte nun erfolgreich booten
  • sollte die Provisionierung nicht starten, dann führt anschließend noch ein „vagrant provision“ durch

Wie schreibe ich eigene / custom Funktionen in einem Makefile?

Mittels selbst definierter Funktionen kann man so ein Makefile deutlich effizienter und übersichtlicher gestalten.

Definiert wird eine Funktion wie folgt:

define name-meiner-funktion
	@ [hier steht dein shellcode] \
	[mehrzeiliger Code muss pro Zeile mit \ abgeschlossen werden] \
	[Variablen werden mit $1, $2, usw. angesprochen]
endef


Aufgerufen wird die Funktion dann mittels:

$(call name-meiner-funktion,parameter1,parameter2,...)

Wichtig ist hier, dass zwischen den Kommas KEIN Leerzeichen sein darf, sonst kommt es zu Fehlermeldungen!

[Quicktip] Aptitude meldet fehlerhafte Signaturen für Jenkins

Wenn ihr ein 

aptitude update

durchführt und die Meldung

W: GPG-Fehler: http://pkg.jenkins-ci.org binary/ Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 9B7D32F2D50582E6

erscheint, dann müsst ihr folgendes machen:

sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 9B7D32F2D50582E6

Damit wird der angezeigte öffentliche Schlüssel auf den neuesten Stand gebracht und der Fehler hat sich erledigt. (9B7D32F2D50582E6 ist die Schlüssel-ID in meinem Fall, kann natürlich auch eine andere sein)