Das ist eigentlich kein ‘richtiges’ Problem – einfach die Gnome-DE/GDM montieren und beim Login das gewünschte Environment wählen. Bei heutigen Disks ja nicht wirklich ein Platzproblem und das ganze Thema ist erledigt. Will ich aber nicht – und wenn man ohne Gnome-Shell und Co. auskommen will, schauts schon etwas anders aus.

Im Arch-Wiki gibt’s da zwar ausführliche Informationen, jedoch hat das bei mir irgendwie nie wirklich geklappt – habe da alle “Variationen” (wie im unten stehenden Beispiel) versucht, leider ohne Erfolg…mitunter auch ein Grund, warum ich das ganze generell mal in Frage gestellt hab…

eval "$(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg)"
export SSH_AUTH_SOCK

Der Keyring hat nicht viel Abhängigkeiten, mit der Installation hätte ich also keine Probleme. Auch seahorse ist recht schlank.

SSH

mit den SSH-Keys hatte ich eigentlich nie Probleme, ob jetzt der keyring montiert war oder nicht. Vielleicht verwende ich das einfach anders als andere Leute ? Ich denke, ssh holt sich die Keys aus dem .ssh-Directory und ich hab nie verstanden, warum man dazu den keyring braucht…seh da das ganze nicht wirklich. Erleuchtung erwünscht 😉

gpg-Files in vim

Das vim-gnupg-Plugin funktioniert tadellos ohne den gnome-keyring. Gefällt mir persönlich optisch sogar viel besser (fügt sich optisch einfach besser in vim ein, finde ich…)

das ganze bleibt auch “nativ”, also ohne keyring, für eine gewisse Zeitspanne aktiv und ich muss das Passwort nicht ständig eingeben.

Tip: das Pin-Entry-Tool in .gnupg/gpg-agen.conf auf den folgenden Wert setzen, damit man ein ncurses-Interface erhält:

pinentry-program /usr/bin/pinentry-curses

Lässt sich natürlich auch auf pinentry-gtk etc. setzen, mir passt das ncurses-Interface aber einfach am besten.

Own- /Nextcloud

Der Tray-Icon macht zwar keine Probleme, jedoch hab ich’s bisher nicht hingekriegt, dass das Passwort (ohne keyring) gespeichert wird.

Anstatt da lange Zeit zu investieren hab ich mir gedacht, ich mach’s doch wie bei vdirsyncer oder offlineimap – als cron. Klar, securitytechnisch wesentlich verbesserbar, aber für’s erste ganz ok für mich. Und scheisse, wenn’s einer eh bis zu meinem Userprofil geschafft hat, ist’s sowieso zu spät… Own-/Nextcloud hat aber ein schickes cli-tool, also kein Problem… (verwende immer noch den ownCloud-Client trotz NextCloud-Server (Screenshot ist zwar grad das Gegenteil…), da im Debian-Repo und es einfach bequemer ist).

owncloudcmd -u user -p password ~/ownCloud https://cloud.foo.li/remote.php/webdav

Das ganze als Cron eingerichtet, dann passt’s für mich. Mails, Kalender und Kontakte synchronisiere ich auch nur alle 5 Minuten – warum soll’s hier anders sein ? Und das ganze “Push”-Zeugs ist sowieso überbewertet und einfach Bullshit – warum will man das überhaupt ? Man kann sich ja auch einfach “künstlich” stressen…

Network-Manager

Mit dem Network-Manager (Tray-Icon) hab ich eigentlich auch keine Probleme – jedoch bin ich derzeit auf der Welle “warum _überhaupt_ eine Statusbar ?”. Das Trayicon vom Network-Manager brauch ich so gut wie nie am Desktop. Beim Laptop ist’s vielleicht etwas anders, da verbindet man sich ab und an mal mit einem neuen WLAN. Geht aber alles auch via nmcli oder nmtui. Den Icon kann ich mir doch einfach sparen im Tray…

Zudem finde ich persönlich, dass die farbigen Trayicons irgendwie einfach nicht passen (zB i3bar) und nur schon deswegen nicht dahin gehören…

Remmina

Hier krieg ich beim Start noch ne Passwort-Abfrage. Damit kann ich aber gut leben…

(mein) Fazit

Meiner Meinung nach sind Statusbars irgendwie etwas überbewertet und lenken oft nur vom Wesentlichen einfach ab. Ich musste/durfte/konnte feststellen, dass man auch ganz gut ohne “leben” kann. Ich bin mir auch sicher, dass das ganze mit Own-/Nextcloud-Client etc. bestimmt machbar ist, aber ich hab einfach keinen Bock, da lange weiterzusuchen – die erwähnten Varianten machen das, was ich vom ganzen erwarte, also bin ich auch zufrieden damit.