Article note: Thanks a lot! Tomorrow I will give it a try …
KDE Connect is a tool which allows your Android device to integrate with your Linux desktop. With KDE Connect Indicator, you can use KDE Connect on desktop that support AppIndicators, like Unity, Xfce (Xubuntu), and so on.

KDE Connect Indicator

The original KDE Connect Indicator hasn't been updated in about 2 year however, Steeven Lopes forked it, getting it to work with recent Ubuntu versions, while also adding various improvements:
  • support sending multiple files from the indicator;
  • new feature to find your phone;
  • new icons;
  • open KDE Connect settings from the indicator device status menu item;
  • added extensions for Nautilus, Caja and Nemo, which allow sending files from the file manager context menu;
  • bug fixes.
If you're not familiar with KDE Connect, here are some of its features:
  • display Android 4.3+ notifications on your desktop (I recommend Recent Notifications so you don't miss important notifications);
  • send and receive files (by default, the files are saved in ~/Downloads on the desktop and in the kdeconnect folder on the Android device);
  • share clipboard between your Android device and desktop;
  • allows using the Android device as a remote for Linux media players;
  • use your phone screen as your computer's touchpad;
  • uses TLS sockets encryption.

Here are a few screenshots of the KDE Connect Android app:




KDE Connect 1.0.x includes some new features, like triggering custom commands (you set this up on the desktop using the KDE Connect configuration, then launch them from the mobile device), displaying desktop notifications on the Android device (this plugin is disabled by default and you'll have to enable it on both the desktop and Android device to use it), and replying to SMS messages from the desktop. The SMS reply feature is not yet supported by KDE Connect Indicator.

The KDE Connect Indicator fork PPA only has packages for Ubuntu 16.04 (including KDEConnect 1.0, required by indicator). However, I've installed the packages in Ubuntu 16.10 and they installed successfully and everything worked, except browsing the device - but this didn't work in my Ubuntu 16.04 test either.

Sending and receiving files, displaying notifications on the desktop, shared clipboard, using the Android device to control media players or as the computer's touchpad, and so on, all worked in my test.

I should also mention that the indicator may disappear when the phone is in sleep mode, but it shows up again when you receive a notification or use your Android device.


Install KDE Connect Indicator fork in Ubuntu


Important: Before installing KDE Connect Indicator, it's important to mention that it depends on kdeconnect, a KDE package which will install quite a few KDE dependencies. If later on you want to remove KDE Connect and KDE Connect Indicator, you may want to save the list of packages which are installed by running the "apt install" command below, and manually remove those packages after you remove KDE Connect ("apt-get autoremove" won't work).

To be able to use KDE Connect Indicator, you'll need to install the KDE Connect application on your Android device.


Ubuntu 16.04: Steeven's KDE Connect Indicator fork is available in a PPA for Ubuntu 16.04. To add the PPA and install the indicator, use the following commands:
sudo add-apt-repository ppa:varlesh-l/indicator-kdeconnect
sudo apt update
sudo apt install indicator-kdeconnect kdeconnect

Ubuntu 16.10: There are currently no Ubuntu 16.10 packages in the PPA, but you can add the PPA in Ubuntu 16.10 and change it to use the Ubuntu 16.04 packages. To do this and install KDE Connect Indicator in Ubuntu 16.10, use the commands below:
sudo add-apt-repository ppa:varlesh-l/indicator-kdeconnect
sudo sed -i 's/yakkety/xenial/g' /etc/apt/sources.list.d/varlesh-l-ubuntu-indicator-kdeconnect-yakkety.list
sudo apt update
sudo apt install indicator-kdeconnect kdeconnect

Arch Linux users can install KDE Connect Indicator (git) via AUR (it uses the new fork).

Once installed, launch KDE Connect Indicator from the menu / dash. For pairing it with your Android device, see below.

Note: if you had an older version of KDEConnect installed before installing the version from the PPA, you may need to restart your system before KDE Connect Indicator works properly.

For source code, bug reports, see the KDE Connect Indicator fork GitHub page.

Pairing your Android device with KDE Connect Indicator



There are two ways you can pair KDE Connect Indicator with your Android device:
a) click "Request pairing" from the KDE Connect Indicator on your desktop, then accept the request from your phone;
b) select the desktop device from the KDE Connect application on your Android device, click "Request pairing, then on the desktop click "Request pairing" from the KDE Connect Indicator menu.

Thanks to Alex for the tip!

Article note: *niceidea!*

1. Sicherheitsrisiko Werbung Die Auslieferung von schadhafter Online-Werbung bzw. Malvertising wird zu einem immer größeren Problem und damit zum Risiko für den Nutzer. In meinem Kommentar »Adblocker sind digitale Selbstverteidigung« bin ich darauf bereits ausführlich eingegangen. Es ist daher wenig überraschend, dass Nutzer verstärkt auf AdBlocker wie bspw. uBlock Origin zurückgreifen. Doch diese Browser-Addons filtern […]

Heute war nen ‚schöner‘ verbummelter Tag …

Geschichte

Gestern Abend kommt von einem Familienmitglied die Chatnachricht „mein Rechner geht nicht mehr“, auf die ich antworte „mal Strom für mindestens eine Minute trennen“. Am Ende hilft das (nat.) nix und wir verabredeten uns für heute zu einem Telefonat.

Zu 10 Uhr dann das erste Telefonat und ich stelle recht schnell fest, dass Remote-Support ohne X und somit nur per Telefon echt ma nich geht. (Das Buchstabieren von iwelchen Kommandos ist ganz schön mühsam …)
Heraus gekommen ist immerhin, dass es sich um einen Login-Loop unter Ubuntu 16.04 (ich war anfangs noch der Meinung, dass es noch ein von mir installiertes 14.04 ist) handelt, welches seit ca. letzten Freitag besteht.

Nach ner Stunde habe ich die Faxen dicke und leider nicht mal ansatzweise ne Idee außer, dass es iwas mit der recht alten NVIDIA GeForce 6800 GS in der Aldi-Multimediakiste zu tun hat. In /var/log/Xorg.* und ~/.xsession-errors war so richtig nix zu finden.

Dann kümmerte ich mich erst einmal darum, wie ich remote auf den Desktop per SSH zugreifen kann. Dazu war es dann nötig, auf der Fritz!Box (über die der andere Rechner an INet angebunden ist) ne Portweiterleitung einzurichten und openssh-server auf dem zu reparierenden Rechner zu installieren. (Also wieder andere Baustellen …) – Das hat aber glücklicherweise dann ganz gut geklappt.

Dann hatte ich etwas Zeit (auch wenn ich nebenbei etwas HomeOffice machen ‚musste‘) zum umsehen, Loop-Ursache lokalisieren und das System noch etwas aufräumen.

Idee 1

Zuerst versuchte ich mein Glück mit dem Update des proprietären Nvidia-Treibers aus dem Paket nvidia-$NR.
Ergebnis: Ohne Erfolg, da die (alte) GeForce nur bis zum Paket nvidia-304 unterstütz wird. Also alles wieder zurückgedreht …

aptitude purge ~nnvidia- && aptitude install nvidia-304

Idee 2

Dann dachte ich mir, ich verzichte ganz auf den proprietären Kram und setze auf den (offenen) Nvidia-Treiber nouveau.
Ergebnis 2: Blöd nur dass der iwie nicht mit dem Monitor zusammenarbeiten wollte und ich nicht in der Lage war, eine annehmbare (größer 640×480) Auflösung einzustellen, obwohl ich (seit Ewigkeiten mal wieder) ne komplette /etc/X11/xorg.conf händisch gebastelt hab …
(Früher musste man alles händisch machen und Dinge haben nur geklappt, wenn man die korrekten Parameter hatte. Heute wird extrem viel automatisch gemacht und man kann oft gar nix mehr groß händisch ändern, wenn der Automatismus versagt. *grml*)

Zielgerade

Ich stieß dann (iwie in meinem 30sten Tab) auf den Foreneintrag „Anmeldung auf graphischer Oberfläche nicht möglich“ im ubuntuusers.de-Forum. Eigentlich nur, weil der recht aktuell ist. (Viele andere Recherchetreffer waren schon ewig alt …)
Der dort verlinkte Launchpad-Bug #1634802 brachte mich jedoch immer noch nicht auf die Zielgerade, jedoch auf eine Fährte. – Nämlich den (auf Ask Ubuntu verlinkten) Launchpad-Bug #1639180, der in der Beschreibung auch meine Fehlermeldung (die ich am Ende in /var/log/syslog fand) enthält:
X Error of failed request: BadValue (integer parameter out of range for operation).

Lösung

Letzten Donnerstag (3.11.16) – und da kommen wir ärgerlicherweise wieder zu Ausgangssituation .oO(Hätte ich das mal ernst genommen und in meine Recherche zu Beginn eingebunden!) – wurde die Version „304.132-0ubuntu0.16.04.2“ verteilt. Diese scheint (wie bspw. obige Bugs ja auch zeigen) einige Unzulänglichkeiten zu haben und verursachte auch auf meinem Problemsystem den Login-Loop.

Die vorhergehende Version „304.131-0ubuntu3“ lief (und läuft) ohne diese Probleme. – Ergo habe ich ein Downgrade durchgeführt.

Dazu also wieder alle installierten Nvidia-Pakete deinstallieren:

aptitude purge ~nnvidia- && aptitude install nvidia-304

Dann die „304.131-0ubuntu3“ installieren:

apt-get install nvidia-304=304.131-0ubuntu3

Am Ende noch (da das System ja nicht täglich unter meiner Kontrolle ist) die „304.131-0ubuntu3“ in der (neuen) Datei /etc/apt/preferences.d/nvidia-304 (mit folgenden Inhalt) gepinnt (s. Apt-Pinning)

Package: nvidia-304
Pin: version 304.131-0ubuntu3
Pin-Priority: 1001

Und nach nem Reboot war der Login-Loop weg … 🙂 *fertsch*

Danke an die Community, ohne die in der ja doch recht kurzer Zeit (von letztem Donnerstag bis heute) eine Lösung nicht in meinen eigenen Kräften gewesen wäre!

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 …