Es war einmal ein Sambashare …

und dann kam Fedora 31 daher. Ich habe Zuhause diverse Geräte, die sich von meinem PC Videos in die Küche, ins Bad, ins hiesige Bett oder ins Hotelbett nach Paris ziehen können, falls NetFlix ausfällt 🙂

Es war einmal ein Sambashare …

Nun ist da ein älteres AOS4 Gerät dabei, welches außer Emails eigentlich nur als Unterhaltungsquelle für NetFlix oder meine eigene Videothek dient. Das liegt daran, daß es praktisch nichts wiegt und der Akku trotz des Alters lange hält. Die Rechenleistung reicht auch genau noch dafür aus, bei FHD wirds schon schwierig bis geht gar nicht mehr.

Jetzt stand der Wechsel auf Fedora 31 wegen Fedora 30 EOL sowieso an, also habe ich das 7.000 Schritte Update gestern mal gemacht. Das lief technisch gut, aber sehr lange und das trotz SSD. Nach dem Reboot gabs dann das von Windows schon bekannte Durchbooten ohne Bildschirm zucken. Wers mag, bitte. Bis auf ein VNC Problem in Python, das sich durch rustikales Nachinstallieren mit Gewaltandrohung von alten Paketen lösen lies, gab es keine nennenswerten Probleme.

Heute wollte ich dann in der Küche beim Mittag mal etwas laufen lassen, aber das bislang genutzt Programm meinte nur so, daß kein Server da wäre. Also habe ich nachgesehen, aber der Server war da. Das gleiche Programm, aber mit AOS5 als Basis, konnte den Sambaserver auch finden und nutzen, aber die AOS4 Version davon nicht. Das finde ich jetzt schon so komisch, daß ich dem Dev da mal eine Email geschrieben habe. Leider gabs noch keine Reaktion, falls die jemals kommen wird.

Also habe ich etwas geforscht und der Unterschied zu Fedora 30 war bei Samba, daß es dort noch Version 4.10.15 war und jetzt 4.11 ist. Mit 4.11 wurde per default NT1 aka Samba 1 deaktiviert. Nach sehr viel rumraten, weil Lösungen aus dem Netz dafür verliefen alle samt im Sande, hatte ich dann doch einen Weg gefunden:

[global]


client min protocol = NT1
server min protocol = NT1
security = user
ntlm auth = ntlmv1-permitted

Wenn man obiges in die /etc/samba/smb.conf einträgt und neustartet, dann geht auch wieder mit AOS4 Programmen 😉

Wenn Ihr das mal selbst testen müßt: smbclient -L //IP.ADDR/

Wenn da was angezeigt wird und in eurem Programm nicht, dann liegts an Eurem Programm 😉

 

es geht um scrcpy

Heute solls um ein kleines Projekt namens „scrcpy“ gehen. Das ist jetzt kein L33t-Speak ;), sondern stand wohl mal für „screen copy“, denn genau darum geht es: Eine Bildübertragung vom Handy zum PC – Live.

„scrcpy“

Das Projekt gibt es bei GitHUB im Genymobile Repo und man muß es selbst zusammen häkeln. Das stellt natürlich eine gewisse Hürde dar, daher hier eine kleine Hilfe, was man machen muß :

Schritt 1: Buildtools installieren

Dazu bitte als Root ausführen:

Wer noch kein RPMFusion für Fedora aktiviert hat, könnte es machen:

# enable RPM fusion free
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

Ansonsten braucht Ihr nur das hier:

dnf install SDL2-devel ffms2-devel meson gcc make java

Schritt 2 – Sourcen laden

Zunächst machen wir uns mal ein neues Arbeitsverzeichnis:

[marius@eve Programme]$ mkdir scrcpy
[marius@eve Programme]$ cd scrcpy/

Dann laden wir die Sourcen von dem Programm via git herunter:

[marius@eve scrcpy]$ git clone https://github.com/Genymobile/scrcpy
Klone nach ’scrcpy‘ …
remote: Counting objects: 2441, done.
remote: Total 2441 (delta 0), reused 0 (delta 0), pack-reused 2441
Empfange Objekte: 100% (2441/2441), 539.98 KiB | 1.27 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1417/1417), Fertig.

Nun brauchen wir noch den Server ( den kaputten Buildprozess für den Server überspringen wir hier, da es einen PreBuild-Server gibt, aber wir brauchen trotzdem einige Files aus dem Buildprozess):

[marius@eve scrcpy]$ wget https://github.com/Genymobile/scrcpy/releases/download/v1.3/scrcpy-server-v1.3.jar

Schritt 3 – Umgebung bauen:

[marius@eve scrcpy]$ cd scrcpy
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Program ./scripts/build-wrapper.sh found: YES (/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh)
DEPRECATION: build_always is deprecated. Combine build_by_default and build_always_stale instead.
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[30/31] Linking target app/scrcpy.

Wenn Ihr das hier lest:

[31/31] Generating scrcpy-server with a custom command.
FAILED: server/scrcpy-server.jar
/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh ../server/. server/scrcpy-server.jar release
Downloading https://services.gradle.org/distributions/gradle-4.4-all.zip

und dann jede Menge Gradle-Schrottdownload-Meldungen erscheinen, hats mit dem eigenen Server nicht geklappt und es kommt der nächste Schritt:

Den Scheiss wieder löschen 😉

Das Ihr hier andere Pfade habt, muß ich glaube ich, nicht extra erwähnen, oder ? 😉

[marius@eve x]$ cd ..;rm -rf x
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true -Dprebuilt_server=/home/marius/Programme/scrcpy/scrcpy-server-v1.3.jar
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[31/31] Linking target app/scrcpy.

Schritt 5 – Installieren

[marius@eve x]$ sudo ninja install
[sudo] Passwort für marius:
[0/1] Installing files.
Installing app/scrcpy to /usr/local/bin
Stripping target ‚app/scrcpy‘
Installing server/scrcpy-server.jar to /usr/local/share/scrcpy

Schritt 6 – Starten

Trommelwirbel und …

und wie man an dem Bild schon sehen, daß Ganze funktioniert nur, wenn man in den Entwicklereinstellungen des Handies das USB-Debugging erlaubt.

man sieht die Android Oberfläche mit Icons

Nun kann man, wenn man kann, mit der Maus das Handy auf dem PC fernsteuern, Eingaben machen, Programme starten, Surfen, Spielen, Videos schauen und mit SimpleScreenRecorder auch Tutorials vom Handy aufnehmen.

Wenn das böse Wenn nicht wär.

Die Sache mit dem Wenn man kann ist fies. Die Verbindung zu meinem Handy lebt nur wenige Sekunden, aber andere Handies bekommen das auch dauerhaft hin, wie Malte aus unserer LUG neulich demonstriert hat.

Es kommt also auf das Android ROM an, das auf dem Handy läuft. Wer eine Alternative sucht, kann Teamviewer für Android nutzen, das bekommt das deutlich stabiler auch auf einem Stock-ROM hin. Aber wer weiß dann schon, wer da mitliest.

Am Ende dann nicht vergessen den Gradle Kram wieder zu entfernen: rm -rf ~/.gradle

Androids K9 Mail nutzt noch TLS 1.0

Au man, man darf echt nicht nachsehen, was seine Programme so tun 🙁

K9-Mail

Das auf Android beliebte K9-Mail setzt auch gebrochene Krypto und nur als Beispiel erdachte Cipher!

2018-05-07 08:52:17 1fFa0M-0004M4-PW <= AAAAAAAAAAAAAAA H=********.dip0.t-ipconnect.de (XXXXX) [XXXXX] P=esmtpsa X=TLSv1:AES128-SHA:128 CV=no … id=1baxr95b3gdd6225t9ggj1yy.1525675936562@email.android.com

Das 146 MB große Paket enthält allen Anscheins nach nicht mal eine aktuelle SSL Implementierung. Schlimmer wäre es nur noch, wenn Sie das an Android outsourcen würden, aber wofür dann die 146 MB ? Im Programm ist nur eine „größere“ Grafik enthalten , der Rest ist pillepalle und ansonsten auch recht trivial von der Funktion her.

Für ein „Advanced Email for Android“ Programm echt enttäuschend 🙁

Mal sehen ob Sie antworten 😀

Webseite: https://k9mail.github.io/