Parallel zu LastPass probiere ich gerade seit einiger Zeit Enpass (auf meiner Ubuntu-Kiste und auf meinem Android-Handy) im Zusammenspiel mit meiner ownCloud aus. – Bis jetzt ganz gut …

Hier desh. ganz kurz ein paar Notizen zur Installation.

  1. Enpass per PPA installieren: https://www.enpass.io/kb/how-to-install-on-linux/
    Von Web Upd8 gibts auch nen schönen Artikel
  2. .desktop-Datei erstellen (s.u.)
  3. Starter-Icon herunterladen:
    wget https://upload.wikimedia.org/wikipedia/commons/c/c1/Enpass_icon.svg -O ~/.icons/Enpass.svg
  4. fertig …

# ~/.local/share/applications/Enpass.desktop
[Desktop Entry]
# https://standards.freedesktop.org/desktop-entry-spec/latest/
Version=5.2
Terminal=false
Type=Application
Name=Enpass
Comment=cross-platform password management solution
Exec=/opt/Enpass/bin/runenpass.sh
# wget https://upload.wikimedia.org/wikipedia/commons/c/c1/Enpass_icon.svg -O ~/.icons/Enpass.svg
Icon=Enpass
# https://standards.freedesktop.org/menu-spec/latest/apa.html
Categories=Security;Settings;System;Utility

Auch wenn ich nicht wirklich ‚viel‘ code, aber so ab und zu fällt ja doch mal was an … In den letzten Jahren v.a. aber eher Klein(st)beiträge zu bereits bestehndem Code Anderer, statt eigener Projekte.

2010 versuchte ich meine ersten Schritt(ch)e(n) mit Git und suchte dafür eine geeignete Plattform. – Nur Kommandozeile mit eigenem Git-Server war mir damals IMHO zu umständlich und wohl auch zu nerdy. ‚Damals‘ gabs zwar schon Github (und dort hatte ich auch seit 2009 einen ungenutzten Account), aber als F(L)OSS-Verfächter wollte ich mehr Community und fand letztlich Gitorious, wo ich mir einen Account zulegte. (So jedenfalls meine Erinnerung …)

Bei Gitorious gab es anfänglich keinen Issue-Tracker und die Interaktion über Weboberfläche war, im Gegensatz zu Github, sehr beschränkt. So kam es im Laufe der folgenden fünf Jahre zur vorrangigen Nutzung meines Github-Accounts.

Im letzten Jahr gab es Bedarf für die Zusammenarbeit mehrer Personen ein einem Projekt (etwas bug fixing im Code von POLYKON) – dabei sollte das erst einmal nicht in der Öffentlichkeit passieren. Somit schied Github (auf Grund der Kosten) aus und ich fand BitBucket und erstellte auch dort einen Account.

In Summe hatte ich bis dahin also drei Accounts bei unterschiedlichen Anbietern für Git-Repositories gesammelt …

Letzte Woche wollte ich mal wieder bei Gitorious schauen, was so los ist und stellte fest, dass GitLab den Laden übernommen hat und man empfiehlt, die eigenen Gitorious-Repos auf GitLab umzuziehen. Dann habe ich mich also mal bei GitLab umgeschaut und schwupps, war der vierte Account geklickt … 😉

Warum nun noch einen vierten Account?

  • GitLabs Webinterface ist schnell
  • GitLab bietet nichtöffentliche Repos an
  • GitLab bietet eig. alle (von mir benutzten) Features wie Github (und ist sogar besser ;))
  • GitLab gibts in der Community Version kostenlos
  • und jetzt der Knaller: per Klick konnte ich (mit etwas Recherche) alle Repos aus den anderen drei Accounts importieren
  • wenn die Butze iwann (vllt.) mal zu macht, dann kann ich/man das immer noch selber hosten
  • das Icon ist süüüß … 😉

Zusammengefasst: Aktuell schrumpfe/konsolidiere ich meine Git-Plattform-Accounts. Gitoriuous is schon weg und gleich kommt noch der Bitbucket-Account dran. Bei Github werde ich dann wohl nur noch wg. der Issue- und Pull-Request-Zwecke sein, die eigenen Projekte kommen dort auf jeden Fall weg.

Mal schauen, ob sich das Aufräumen langfristig als klug erweisen wird …

Old but not busted … – Dieser Inhalt wurde vor mehr als 2 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

Gestern wollte/musste ich mal wissen, was in einem LXC-Container (auf unserem Kommune-Server) gemountet ist. – Da das im ersten Anlauf nicht ganz so trivial heraus zu bekommen war, hier mal meine kleine Gedankenstütze.

long story short

root@host:~/# ls -lha /proc/$(lxc-info -n container -p | awk '{print $2}')/root/home

Erklärbär

Szenario

  • LXC-Version: 0.7.5 (ja ich weiß, is alt  … ;))
  • Host = hn
  • Container = container
  • Mount = in der fstab (host:/var/lib/lxc/container/fstab) ist das host:/home mit der Zeile "/home home none bind 0 0" eingebunden (d.h. also, dass beim Starten des LXC-Containers des /home vom Host beim Start des Containers in den Container gemountet wird; dabei ist home als relativer Pfad zum / angegeben)

Das Problem

Wenn man nun auf dem Host wissen will, wie das /home im Container aussieht (ls -lha /var/lib/lxc/container/rootfs/home) wird man feststellen, dass es ganz anders aussieht, als erwartet. – Hintergrund ist, dass der obige Mount in einem temporären Filesystem (also nicht wie ein normaler/echter Mount) eingehängt wird.

Hier mal die Ausgabe, die mit einem Standard-LXC-Template (Ubuntu) erzeugt wird:

root@host:~/# ls -lha /var/lib/lxc/container/rootfs/home
total 4.0K
drwxr-xr-x  3 root   root     19 Aug 18  2012 .
drwxr-xr-x 22 root   root   4.0K Feb  7 14:15 ..
drwxr-xr-x  2 ubuntu ubuntu   54 Aug 20  2012 ubuntu

Die Lösung

Nach etwas Recherche stieß ich auf den Blog-Post „LXC 1.0: Advanced container usage“ des LXC-Entwicklers Stéphane Graber, in dem der Trick (und einige Hintergründe) erklärt werden.

Jeder Container hat eine eigene Prozessnummer (pid). Diese bekommt man mit lxc-info -n container -p heraus.
Der im temporären Dateisystem eingehängte Mount befindet sich unter host:/proc und dort wieder unter der jeweiligen PID.
Also angenommen unser Container hat die PID 1234, dann findet man dessen root-Filesystem (inkl. aller Mounts) unter host:/proc/1234/root/.

Wir benötigen also zuerst die PID des Containers (lxc-info -n container -p) und danach können wir uns das Filesystem anzeigen lassen (ls -lha /proc/PID/root/). – Beide Befehle kann man nun kombinieren.

mit LXC 1.x

In oben genannten Blog-Post wird für das Eruieren der PID lxc-info -n container -p -H (angepasst!) angegeben. Dabei stehen die Schalter -n container für den Containernamen, -p für die Ausgabe der PID und -H (wahrscheinlich; siehe unten) für die numerische Ausgabe der PID.

Die Kombination der beiden Befehle zum Anzeigen des Root-Dateisystems für den Container sieht dann so aus: ls -lha /proc/$(lxc-info -n container -p -H)/root/ (angepasst!).

mit LXC <1.x (in meinem Fall 0.7.5)

Da ich ATM allerdings noch nicht die Version 1.x verwende, funktioniert der Tipp (aus dem Blog-Post für die Version 1.x leider nicht (so ganz).
Denn in 0.7.5 gibt es den Schalter -H bei der Ausgabe der PID mit lxc-info -n container -p nicht, so dass man nicht nur die PID, sondern den Text pid: 1234 zurück bekommt. :-/

Allerdings ist das nicht so dramatisch, denn man kann sich ja mit awk behelfen (und somit den Schalter ersetzen/emulieren). 🙂
lxc-info -n container -p | awk '{print $2}' liefert nur die zweite ‚Spalte‘ der lxc-info-Ausgabe, also die nummerische PID.

Ergo hier nun meine Lösung zum Anzeigen des Root-Dateisystems des Containers:

root@host:~/# ls -lha /proc/$(lxc-info -n container -p | awk '{print $2}')/root/home
total 4.0K
drwxr-xr-x  3 root   root    19 Aug 18  2012 .
drwxr-xr-x 22 root   root  4.0K Feb  7 14:15 ..
drwxr-xr-x  2 user1  user1       […]         user1
drwxr-xr-x  2 user2  user2       […]         user2
drwxr-xr-x  2 user3  user3       […]         user3

… wieder was gelernt … 😉 – Allerdings wohl nicht für lange, denn das Update auf die Version 1.x steht ja vor der Tür …

Old but not busted … – Dieser Inhalt wurde vor mehr als 5 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

Seit ein paar Tagen habe ich in meinem /var/log/syslog ein paar hässliche Meldungen, die das ganze syslog ‚vollmüllen‘.

Hier mal ein Beispiel:

Apr 24 08:55:10 axolotl kernel: [36283.935663] Valid eCryptfs headers not found in file header region or xattr region, inode 1717173
Apr 24 08:55:10 axolotl kernel: [36283.935674] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Auf der Suche nach Ursache & Lösung bin ich über

Das Problem der Meldungen (siehe Raphaels Erklärungen) ist wohl, dass es in meinem (mit eCryptfs verschlüsseltem) home Dateien gibt, die eine Größe von 0 Bytes haben. Wie die da hin gekommen sind kann ich nicht mehr rekapitulieren, da ich mir auch nicht mehr ganz sicher bin, seit wann die Meldungen im syslog stehen (und ich ebenfalls wenig Lust habe, die alten syslog-Dateien zu durchsuchen…).

Am Ende habe ich nun Folgendes durgeführt, um das eCryptfs wieder konsisten zu machen & somit auch die Meldungen los zu werden.

  1. sudo find /home/.ecryptfs/$username/.Private/ -xdev -size 0c ($username = mein Login-Name)
  2. Der erste Befehl sucht alle Dateien mit der 0-Byte-Größe und gibt diese aus. – Bei mir waren es zehn dieser Dateien.
  3. Danach habe ich alle ausgegebenen Dateien per Hand nochmal kontrolliert – ls -lha $datei.
  4. Abschließend (nachdem ich festgestellt hatte, dass alle Dateien wirklich mir gehören & wirklich 0 Bytes groß waren) habe ich dann alle zehn Dateien einzeln gelöscht: sudo rm "$datei".

Das Ganze habe ich immer mit root-Rechten (sudo) gemacht, da es ohne diese ständig zu Fehlermeldungen bzgl. der Rechte kam – was aber auch an der Benutzung von trash-cli liegen kann!

Zusammenfassend kann ich sagen, dass

  • seit dem die Meldungen im syslog nicht mehr vorhanden sind *claro!*;
  • ich seit dem keine Probleme feststellen konnte,
  • der Bug offensichtlich (für bestimmte Anwendungen) bereits gefixed ist (nichts desto trotz kann ein Systemcrash nat. dazu führen, dass diese Dateien wieder existieren und dann mosert eCryptfs ja zurecht…) und
  • ich der Meinung bin, dass man die Dateien relativ gefahrlos löschen kann – 0 Byte große Dateien haben keinen (privaten) Inhalt und sollte es sich um Spezialdateien von bestimmtn Anwendungen handeln, werden die beim Neustart der Anwendung wahrsch. wieder neu erstellt.

In diesem Sinne & ohne die Übernahme irgend welcher Gewehre,
der sokai

Old but not busted … – Dieser Inhalt wurde vor mehr als 5 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

…ich bin kein PHP-Programmierer, aber für meine B.A.-Arbeit mache ich es (mehr recht als schlecht) & bekomme dabei manchmal fast ne Kriese…

So zum Bsp. in den letzten beiden Tage. – Da wurde aus einer kleinen 40zeiligen Funktion (die die gewollten Grundfunktionalitäten liefert) ein kleines Monster mit 164 Zeilen… – Aber jetzt isses halt echt viel schöner & die Bedarfe Aller sind befriedigt… 😉

Außerdem noch schnell nen Link zu dem Projekt RIPS: http://rips-scanner.sourceforge.net.
Damit kann man offline PHP-Code auf Fehler & Schwachstellen prüfen lassen… – Sehr nett! (Aber bitt enicht nur darauf verlassen. ;))

*soundjetztgehtsinsbett-wink*