Immer mal wieder stolpert man über tolle Pogramme wenn man sich die Updates im Repo ansieht. Sayonara ist ein GTK basierter Musik-Player. Es gehört aber nicht zu den ganz tollen Programmen, was an der GUI liegt:
Die Gui ist GTK typisch nicht grade klein oder gar optimal. Es gibt ein kleines Feld, daß sich in der Funktion austauschen läßt, statt des Levelmeters, kann man auch andere Dinge anzeigen. Aber Konfigurieren kann man die GUI nicht. Leider unbrauchbar in der Praxis, zumal ich der rechten Seite keine Funktion entzaubern konnte.
Wenn man ein Stock Linux hat, mag das als erster Musikplayer auf dem System noch funktionieren, aber für den Produktivbetrieb kommt nur QMMP in Frage:
QMMP kann man via RPMFusion bekommen. Da es themebar ist, kann es wie das alte WinAMP aussehen und im Gegensatz zu Sayonara ist es klein, schnell und effektiv 🙂
Die Unterstützung in Nemo hatte ich Euch ja schon vorgestellt.
Vielleicht findet Ihr für Sayonara einen Grund, für mich wars dann auch Sayonara, aber im wörtlichen Sinn 🙂
Verfügbar:
via Homepage: https://sayonara-player.com/current_version via Repository: dnf install -y sayonara
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:
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]$ 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.
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
Früher gabs die Funktion direkt, wenn man QMMP hatte, aber seit einigen Versionen ist die reine Hinzufügen von Files zur Playliste in das „mit einem anderen Programm öffnen“ Menü gewechselt, was bei mehr als einem File zum Problem werden dürfte. Mit der Action ist das jetzt allerdings wieder möglich.
#!/bin/bash
IN=$*
IFS=";" read -ra FILES <<< "$IN"
for i in "${FILES[@]}"; do
qmmp --enqueue "$i"
done
Falls WordPress da wieder so komische Striche daraus machen sollte, es ist 2x ein einfacher Bindestrich.
\o/ Liebe Grüße an unsere mexikanischen Linuxfreunde ! Ich weiß, daß Ihr mich als Quelle verlinked \o/ \o/ Saludos a nuestros amigos mexicanos de Linux! Sé que me vinculaste como una fuente. \o/
„ls -la“ kennt Ihr vermutlich aus jedem Konsolen-Tutorial für Linux. Aber habt Ihr auch schon mal einen lokalen Befehl nur für Euch gebaut ?
Globale oder Lokale Befehle ?
Globale Befehle kennt vermutlich jeder Linuxuser, denn alles was in /bin/ als Programm abgelegt und für alle Benutzer ausführbar ist, kann aufgerufen werden. Meistens laufen diese Programme im Context des aufrufenden Benutzers. Ausnahmen gibt es nur, wenn das SETUID-Flag gesetzt ist, dann darf jemand einen Befehl als ein bestimmter User ausführen. Üblicherweise ist das Root, aber andere user sind auch denkbar. „ls“, „find“, „uname“ usw. sind solche Befehle. So weit, so normal.
Wer den Videobeitrag Wie starten sich eigentlich Programme? gesehen hat, der ist da jetzt schon weiter, denn dort wird das genau erklärt. Kann ich Euch nur empfehlen, weil damit ist das hier möglich :
[marius@eve ~]$ firefox Ich bin aber nicht der FireFox! insgesamt 20 drwxrwxr-x. 2 marius marius 4096 14. Jul 09:45 . drwxr-xr-x. 5 marius marius 4096 5. Jul 23:48 .. -rwx——. 1 marius marius 100 14. Jul 09:45 firefox -rwx——. 1 marius marius 112 5. Jul 23:48 fixrom #!/bin/bash
echo „Ich bin aber nicht der FireFox!“
ls -la ~/.local/bin/ cat ~/.local/bin/firefox
[marius@eve ~]$
„Nicht die Mama“
Ok, Firefox ist jetzt nicht mehr Firefox .. super.. Browser kaputt gemacht 🙁 Was wäre, wenn im System ein Firefox Quantum installiert ist, der User aber Quantum ******** findet und lieber noch FF 52 ESR nutzen will? Egal welches Programm Firefox für seine Webseitendarstellung aufruft, es wird immer der systemweit installierte Firefox genommen. Der kleine Trick hier könnte das auf den Firefox ESR umleiten. Das wäre nur lokal für diesen Benutzer der Fall.
Wesentlich praktischer ist das andere kleine Programm in dem .local/bin Verzeichnis: fixrom . Wer den Beitrag über das fehlerhafte Fehlerfenster bei Runes of Magic gelesen hat, der weiß was es tut: Es verschiebt ein Fenster, daß nutzlos im Weg ist und dazu noch so defekt, daß man das nicht per Maus machen kann.
Da ich das kleine Script in das Lokale Bin-Verzeichnis verschoben habe, kann ich es von überall aus aufrufen und muß nicht mal den Pfad kennen, wo es wirklich liegt. ALT+F2 und die Eingabe von „fixrom“ startet es genauso, also wenn ich es in der Konsole eingebe. Ich kann es auch pauschal in die Desktopicons einbauen:
[marius@eve ~]$ cat Schreibtisch/Runes\ of\ Magic.desktop | grep Exec Exec=env WINEPREFIX=“/home/marius/.wine“ wine C:\\\\windows\\\\command\\\\start.exe /Unix „/home/marius/Programme/GameforgeLive/Games/DEU_deu/Runes Of Magic/Runes of Magic.exe“
Dann würde es direkt nach dem Start von Runes of Magic gestartet werden und mir das Fenster sofort vom Hals halten. Aber, dann würde es auch bei jedem Start laufen und es muß nur eine Instanz davon aktiv sein, daher starte ich das von Hand. Gut, ich könnte das Script auch mit einem PID File versehen und prüfen ob es schon läuft und dann den Start umgehen, zeige ich vielleicht sogar mal 🙂
A Truth about Red Hat
Der vollständigkeithalber muß ich erwähnen, daß das mit dem Firefoxersatz unter Fedora nur klappt, wenn man seinen Pfad korrigiert. Wer nicht weiß was ein Pfad ist, schaut sich bitte das Video an. So sieht der Pfad unter Fedora aus:
Natürlich müßt Ihr meinen Usernamen in Euren Änderungen durch Euren Namen ersetzen 😉
Wieso Fedora/Red Hat den Pfad so unbrauchbar gemacht haben, ist mir ein Rätsel, denn genau für solche Spielereien sind die lokalen Bin-Verzeichnisse da. Jetzt könnte man argumentieren, daß ein Angreifer damit den (im Beispiel) Firefox lokal ersetzen könnte und so ggf. noch mehr Schaden beim User durch Spionage anrichten kann. Das wäre zwar richtig, aber jeder, der von Remote da was hinlegen kann, kann noch ganz andere Dinge und hätte das Angriffsszenario nicht nötig 😉
Solange man aber nicht vor hat, ein Systemprogramm zu ersetzen, ist der Pfad eigentlich egal, nur .local/bin/ müßte halt drin vorkommen.
Wie Ihr ( und .tux. ) im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉
Fedora und die Repostrukturen
Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.
Immer wieder Koji
Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:
Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.
Manuelles DNF Update
Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:
[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M
Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete
Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8
Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27
Fertig.
Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :
Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.
Ob das so clever war, die automatischen Tests zu umgehen?
Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.
Wissen eigentlich alle was diese Policies so machen ?
mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:
„SELinux Base package for SELinux Reference Policy – modular. Based off of reference policy: Checked out revision 2.20091117“
Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:
u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:
(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse) … (filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0)))) (filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0)))) (filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0)))) (filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0)))) (filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0)))) (filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0)))) (filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0)))) (filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0)))) (filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0)))) (filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0)))) (filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0)))) (filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0)))) (filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0)))) (filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0)))) (filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0)))) (filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0)))) (filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0)))) (filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0)))) (filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0)))) (filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0)))) (filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0)))) (filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0)))) (filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0)))) (filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0)))) (filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0)))) (filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0)))) …
und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.
Ich hab versucht da durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.
Die Gui ist GTK typisch nicht grade klein oder gar optimal. Es gibt ein kleines Feld, daß sich in der Funktion austauschen läßt, statt des Levelmeters, kann man auch andere Dinge anzeigen. Aber Konfigurieren kann man die GUI nicht. Leider unbrauchbar in der Praxis, zumal ich der rechten Seite keine Funktion entzaubern konnte.
Wenn man ein Stock Linux hat, mag das als erster Musikplayer auf dem System noch funktionieren, aber für den Produktivbetrieb kommt nur QMMP in Frage:
