Portage Pflege für alle

Jeder Gentoo und Funtoo Benutzer wird es bestimmt kennen, egal ob ein Programm nur zum Test Installiert wurde oder die Keyword und USE Datei (kann auch ein Verzeichnis sein) bearbeitet wurde. Wenn das Programm nicht mehr Installiert ist liegen viele Leichen in diese Datei.

Verständlich das dort niemand Putzt da alles per Hand gemacht werden muss.

Dachte ich mir und habe mir hierfür kleine Helfer geschrieben, die diese Arbeit abnehmen. Anfangs gab es nur den „Portage Keyword Manager“, jetzt kam „Portage Useflag Manager“ hinzu.

Die Handhabung ist die selbe wie bei „portkeyman“ (Portage Keyword Manager) was nicht verwunderlich ist, denn dieser diente als Vorlage für „portuseman“ (Portage Use Manager).

Erstmalig habe ich meine genfoo-tools am 17.02.2013 veröffentlicht, das ich auch hier im Blog bekannt gegeben habe https://knasan.wordpress.com/2013/02/17/genfoo-tools-meine-portage-utils/

In diesem kleinen Video wird gezeigt wie einfach die Tools verwendet werden können und wie man zwischen File und Directory hin und her schalten kann, was Geschmackssache ist. Ich persönlich mag die Directory Variante.

Als erstes wird in das Verzeichnis /etc/portage gewechselt und gezeigt das die Datei package.use vorhanden ist und wie viele Einträge diese hat.

 root@turanga ~ # cd /etc/portage/
root@turanga portage # ls -l package.use
-rw——- 1 root root 3423 15. Aug 17:14 package.use
root@turanga portage # wc package.use
83 355 3423 package.use
root@turanga portage

Wie man hier sehen kann ist „package.use“ eine Datei und hat 83 Einträge.
Mit „portuseman“ kann man wesentlich zwei Operationen durchführen.

• package.use aufräumen, also nicht Installierte Packete aus der Datei löschen.
• package.use Datei nach Verzeichnis konvenieren oder anders herum.

Als erstes wird gezeigt wie man einfach nicht mehr Installierte packete aus portage putzt, hierfür muss „portuseman“ lediglich mit dem Parameter -d für delete aufgerufen werden. Aus Sicherheitsgründen werden diese Operationen nicht am System direkt gemacht sondern alles in /tmp gespeichert, übernehmen muss der Benutzer nach einer Kontrolle selbst.

root@turanga portage # portuseman -d
new packages.use is saved as File to: /tmp/package.use.new

Wie man hier schön erkennen kann wurde die neue package.use Datei nach /tmp/package.use.new gesichert. Möchte man diese Datei nach betrachten übernehmen so muss diese nach /etc/portage/ kopiert werden.

Vergleicht man nun die neue und alte Datei, wird man feststellen das alles was nicht Installiert war aus diese Datei gelöscht wurde.

root@turanga portage # mv /tmp/package.use.new ./package.use
root@turanga portage # wc package.use
69 273 2681 package.use

in meiner package.use waren also 14 Einträge die nicht mehr genutzt wurden.

Anfangs habe ich gesagt das ich die Directory Variante bevorzuge, deswegen werde ich jetzt erst einmal das eben vorhandene konvenieren, was man auch mit einem Schritt machen kann, nur zur Demonstration habe ich diesen schritt nicht gleich mit angegeben.

root@turanga portage # portuseman -o d -d
new package.use is saved as directory to: /tmp/package.use
root@turanga portage # mv package.use package.use.old

root@turanga portage # mv /tmp/package.use .          <- beachte den „punkt“
root@turanga portage # portuseman -o d -d
new package.use is saved as directory to: /tmp/package.use

root@turanga portage # mv package.use package.use.old
root@turanga portage # mv /tmp/package.use .          <- beachte den „punkt“
root@turanga portage # cd package.use/

root@turanga package.use # ls
app-accessibility app-office dev-lang gnome-base media-plugins net-fs sys-libs
app-admin app-portage dev-libs kde-base media-sound net-im virtual
app-arch app-text dev-qt mail-client media-video net-misc www-client
app-editors dev-db dev-util media-gfx net-analyzer net-proxy x11-terms
app-emulation dev-games games-sports media-libs net-dns sci-geosciences x11-wm

Nun sind im Verzeichnis „package.use“ Dateien mit Kategorien. Ich mag diese Variante da diese sehr übersichtlich ist und nicht einfach nur eine Datei zugemüllt wir.d. Sucht man ein bestimmtes Programm das man mit neuen USE-Flags emerge möchte, so schaut man einfach in die Kategorie-Datei rein. Aber wie gesagt das ist Geschmackssache und jeder muss dies für sich selbst entscheiden.

Portuseman ist ab sofort im genfoo-utils ebuild zu finden.

https://github.com/knasan/ebuilds/tree/master/app-portage/genfoo-tools

-Sandy

genfoo-tools, meine portage utils!

Ich hatte mal ein Script geschrieben das mir meine /etc/portage/package.keywords Datei in ein Verzeichnis Konvertierte. Es lag danach lange auf der Platte und schien in Vergessenheit zu geraten bis ich ein Beitrag auf gentooforum.de sah http://www.gentooforum.de/artikel/21118/packages-keywords-durchputzen-lassen-ist-das-m-glich.html?s=5bcd93f04f80b28ce377b28d287e352926658d62 .

Dort frage ein User nach, ob es denn möglich sei package.keywords zu putzen.
Ich wusste, da habe ich schon mal etwas geschrieben und schaute in meine Script Sammlung nach, „portkeyman“ (Portage Keyword Manger) gesucht und wieder gefunden.

Nun hatte ich zwei Möglichkeiten, das Script im Forum Posten und es erneut untergehen lassen oder doch lieber in Git verwalten. Ich beschloss mich, dieses Script auf mein Git zu legen, so das viele davon Profitieren können.

Nach kurzen Tests wurde mir klar, ich muss am Script noch etwas ändern. Ursprünglich war es eher als Hack gedacht um eine Lösung für mein damaliges Problem zu haben. Für eine Veröffentlichung war es noch nicht gut genug. So spendierte ich dieses Script eine kleine Hilfe und examples ein paar Fehlerkorrekturen und ab in Git.

Was mich noch störte, meine Kommentare die ich seit kurzem eingeführt habe wurden komplett Ignoriert. Also auch das noch schnell hinzugefügt.
Was auch lästig war, man musste immer angeben wo die packages.keywords liegt, deswegen habe gleich noch einen Default Path eingeführt. In der Regel liegt es ja immer unter /etc/portage/package.keywords als Datei oder Verzeichnis.

Hab das Script nun ein paar mal ausgeführt und es etwas einfacher, aber so dynamisch wie möglich umgeschrieben. Das Script erkennt nun ob man Root oder Normaler User ist und ändert den Logpath um nicht immer ein Logfile angeben zu müssen, was man aber natürlich noch kann.

Um es einfach unter Gentoo oder Funtoo Installieren zu können habe ich ein Ebuild „genfoo-tools“ geschrieben. Bevor ich jedoch noch mehr portage-utils Scripte Veröffentliche möchte ich portkeyman um ein paar weitere Funktionen erweitern. Hinzufügen und entfernen von Keywords um ein Beispiel zu nennen. Ich überlege auch, einen Parameter einzuführen der das nicht in /tmp speichert sondern die Änderungen sofort im System erledigt.

Ich merke schon dass das Script vieles Automatisieren könnte oder schon tut, was man lang händisch erledigt hat. Daher würde mir ein completion Script noch gefallen, habe bisher nur eines geschrieben und bin noch nicht ganz durchgestiegen wie das genau Funktioniert. Sobald das Script in einer Phase ist wo man sagen kann, es hat alles was man sich wünscht, werde ich mir completion noch einmal ansehen.

Wer mag, darf das Script gerne Testen und mir seine Ideen oder Kritik Schreiben, schließlich soll es unsere Arbeit erleichtern. Ich Antworte auf jeden Fall, auch wenn es mal etwas länger dauert. Also nicht ungeduldig werden 😉

Das Ebuild findet ihr hier: https://github.com/knasan/ebuilds/tree/master/app-portage/genfoo-tools
und das Script selbst hier: https://github.com/knasan/genfoo-tools

-Sandy

sysnapshot und nepomukserver (KDE Desktop-Suche)

Hab einiges über die Desktop-Suche in KDE gelesen und wollte mir die angeblichen Vorteile von KDE selbst einmal ansehen. Also KDE installieren und wichtige Tools einrichten und schnell ein Backup erstellen, was ich immer nach grössere Änderungen am System mache …

sudo sysnapshot

Während dessen machte mich noch etwas schlauer wie denn die Desktop-Suche Funktionieren sollte.
Riskierte ein Blick auf mein Terminal, ups was ist das? Meine Backup-Festplatte konnte nicht getrennt werden, aber warum?

lsofs Zeigte mir an, dass Nepomuk die Festplatte in Beschlag genommen hat. Ich frage mich warum?

Einerseits habe ich die Festplatte als „root“ gemountet und ging den User nichts an, und zum anderen habe ich schon oft gelesen das nur dass Home-Verzeichnis des Users Indexiert wird. Dies wollte ich nun genauer wissen und schaltete den indexer aus. Startete nochmal sysnapshot, keine Besserung in Sicht, Nepomuk hatte wieder die Festplatte in Beschlag.
Ich begab mich auf die Suche ob es möglich Nepomuk beizubringen dass er dieses Verzeichnis in ruhe lassen soll. Ich wurde nicht fündig!

Fuck off nepomuk!

Ich hatte keine Lust mehr eine Funktion zu suchen, ich muss mich erst noch Intensiver mit Nepomuk beschäftigen, damit ich eine Lösung finden und Dokumentieren kann.

Ist zwar nicht die beste Lösung aber es funktioniert.

Man könnte auf Nepomuk verzichten, dann wäre dieses Problem gar nicht da!

Wenn man die Backup-Festplatte einbindet bevor sysnapshot gestartet wird, dann macht sysnapshot kein umount und man bleibt von diesen Problem unberührt.

Wer sysnapshot als „root“ laufen lässt hat dieses Problem auch nicht mehr, da ich nun die Zugriffsrechte auf den Mountpoint so geändert habe, dass nur Root darauf zugreifen kann.

Dies sind leider nur Workarounds, was mir gar nicht gefällt.

Abgesehen von dieser Nepomuk Thematik war mein erster Test jedoch Positiv.
Obwohl ich wusste wo die Datei lag die ich suchte, konnte ich diese schnell mit der Suche finden und ein klick, schon konnte ich an dieser Datei Arbeiten.
Hätte ich mit einen Dateimanager Navigiert hätte es länger gedauert. Mal sehen ob sich die Suche weiterhin bewährt, theoretisch benötige ich diese nicht, da ich alles Organisiert speichere.
Was ich auch beibehalten werde. Selbst wenn ich Nepomuk in Zukunft öfters befragen werden.

Sandy

sysnapshot im neuem Gewand

Ich brauchte vor kurzem eine etwas andere Konfiguration und stellte fest, dass sich ein Fehler eingeschlichen hatte. Zuerst wollte ich diesen einfach nur Fixen. Als ich meinen Code sah dachte ich mir: „dieser Code ist nicht mehr auf mein Level und muss dringend überholt werden““.

Also habe ich mir einen neuen Plan erstellt wie sysnapshot funktionieren soll.

1. Es ist nicht zwingend sysnapshot als Root zu betreiben. Manche Benutzer möchten manchmal nur ihr Heimatverzeichnis sichern. Dafür muss man kein root sein. (Wenn die Backup Festplatte verschlüsselt ist, dann kann das nur root.)
2. Es ist nicht zwingend erforderlich eine Verschlüsselte Backup Festplatte mit einem Key zu betreiben. Jedoch geht so etwas nicht im Cronjob mode. Sysnapshot wird Sie daraufhin warnen.
3. Ist etwas in der Konfiguration von Sysnapshot Falsch? Sie bekommen jeden möglichen Fehler beim starten angezeigt. Dies hat den Vorteil das man nicht alles tausendmal testen muss, sondern gleich sieht was noch geändert werden muss.
4. Die Option mount_befor hat sich bewährt deswegen habe ich diese Funktion wieder aufgenommen und auch um einige Punkte erweitert. Es wird zum Beispiel geprüft ob der Pfad existiert. Läuft etwas beim einbinden schief, bricht sysnapshot sofort ab.

Kurz gesagt, die Überprüfung von sysnapshot ist Intelligenter gestaltet als die vorherige.
Auch die Funktion Cleaner, die manchmal sehr hilfreich sein kann wurde grundlegend neu entwickelt.

Wenn man sich den alten Code (421 Zeilen) mit den neuen Code (349 Zeilen) vergleicht, kann man die Steigerung förmlich sehen. Selbst Benutzer die nicht Entwickeln können, werden mir Zustimmen. Da bin ich mir sicher!

Ich hoffe das sysnapshot ihnen Freude bereiten wird und das Sie niemals in der Lage sein werden, ein Backup einzuspielen. Wenn doch, hoffe ich Sie haben eins.

Ich Freue mich über jede Zuschrift aller Art. Haben Sie weitere Ideen für sysnapshot, dann Schreiben Sie mir. Sie können natürlich auch selbst Hand anlegen da sysnapshot OpenSource ist und steht unter der Lizenz GPLv2.

Sandy

Virt-manager für die Konsole

virt-cm ist entstanden als ich meine Virtualbox Images aus ein Backup einspielen wollte und diese nicht mehr funktionierten. Mit kvm konnte ich meine Virtualbox Images noch nutzen.

Anfangs habe ich einfach ein Script geschrieben das mir meine Virtuelle Maschine mit qemu-kvm startete. Eine kleine Funktion für das Einbinden von USB war mit am Board.

Das erste Programm schickte ich mit ein paar Fragen an Linux-User und wurde gefragt ob ich geplant habe dieses auch auf libvirt basis zu machen.

Da ich gerade dabei bin Ruby zu Lernen, kam mir diese IDEE gelegen um ein neues Projekt daraus zu machen. Also habe ich mir libvirt angesehen und bin auf das Kommando virsh gestoßen. Als ich die Dokumentation von RedHad Virtualization Durchgelesen hatte, war ich bereit einige geh versuche zu starten. Anfangs hatte ich mit ein paar Kleinigkeiten zu Kämpfen die ich dringend brauchte. Ich stellte fest, das ich USB mit libvirt nur als root an die VM leiten konnte und habe mein Code nochmal überarbeitet.

Das Importieren einer Existierende Virtuelle Machine von Virtualbox funktionierte super. Als die manage Funktion geschrieben wurde, stellte ich fest das man nicht alle Optionen hatte die libvirt einem bietet. Es war zum Beispiel nicht möglich die VM zu sichern. So ist virt-cm täglich etwas gewachsen.

Heute habe ich die Installation via ISO-Datei und CD-ROM Implementiert und sehe das Tool in einem brauchbaren Zustand. Es war also Zeit diese der breiten Öffentlichkeit zur Verfügung zu stellen.

Da ich kein XEN habe, kann ich das Importieren via XEN-XML nicht testen und habe nur das Theoretische implementiert. Persönlich nutze ich nur kvm, daher habe ich dieses Script auch darauf aufgebaut.

Theoretisch ist es aber möglich jeden Hypervisor zu nutzen. Wenn jemand Interesse daran hat seinen verwendeten Hypervisior über virt-cm nutzen zu können, kann mich gerne kontaktieren und gemeinsam dieses Tool erweitern.

Besonders schön ist es, wenn man zwei Monitore hat. Auf dem Primären Monitor lasse ich die VM starten und der Sekundäre virt-cm um Befehle auszuführen.

virt-cm steht ab sofort auf github.com als Download zur Verfügung. Natürlich unter GPL2