Und wie sind die Flags gesetzt? Ist das x-Bit gesetzt? Sonst erst mal
Und zeig uns mal ein ls -l /home/frank/bin/scripte/lei.sh
Und wie sind die Flags gesetzt? Ist das x-Bit gesetzt? Sonst erst mal
Und zeig uns mal ein ls -l /home/frank/bin/scripte/lei.sh
Kein Wunder, die steht auch nicht unter /etc/sysconfig. Nein, für /etc/tmpfiles.d hilft dir YaST leider nicht weiter.
und noch einige Ergänzungen von meiner Seite:
Unter openSUSE wird /tmp standardmäßig auf ein persistentes Filesystem gemountet. Andere Distributionen benutzen auch ein tmpfs Filesystem im RAM. Die Pros und Cons werden z.B. hier diskutiert: openSUSE:Tmp_on_tmpfs#.2Ftmp.2F_on_harddisk_versus_.2Ftmp.2F_on_tmpfs
Generell ist die Erwartung von openSUSE (und auch anderen Distributionen), dass eine Applikation, die Dateien unter /tmp anlegt, diese auch wieder selbst entfernt. Im Normalfall sollte eine Applikation dort also keinen Müll hinterlassen und darauf warten, dass jemand anders aufräumt. Ich würde dir deshalb empfehlen mal zu schauen, wer da Dateien ablegt. Oft kann man aus Namen und Inhalt auf den Urheber schließen. Auch der Owner ist aufschlussreich: ist es root oder ist es ein Prozess des lokalen Users?
Die von Sauerland verlinkte Diskussion zeigt auf die richtige Stelle, wenn es darum geht, den Müll eben doch aufzuräumen. Der systemd tmpfiles Service ist hierfür zuständig. Hier auch noch ein Link in die zugehörige openSUSE Doku: cha-systemd.html#sec-boot-systemd-advanced-tmp
Wenn du also den Verursacher nicht selbst zur Verantwortung ziehen kannst, dann kannst du eine entsprechende Datei nach /etc/tmpfiles.d legen und dort deine Aufräum-Policies eintragen. Syntax und Beispiele findest du in den Links.
von Cherry gibt es auf cherry - downloads Linux-Treiber für diesen Reader, schon mal damit versucht? Achtung, der Download enthält 32- und 64-bit-Versionen und dann noch Debug-Varianten davon. Nimm die 64-Bit-Version. Schau dir dann die ReadmeFirst.txt an, bevor du weitermachst.
Ist aber nur ein Hinweis, ich hab da nix ausprobiert und hab keine Ahnung, ob der Treiber für openSUSE passt und die gewünschten Ergebnisse bringt!
Hallo,
ich denke dein Hauptmissverständnis liegt beim su-Befehl. Wenn du den innerhalb eines Skriptes aufrufst, dann startet dieser eine getrennte Shell, die von deinem Skript gar nichts mehr weiß. Die Lösung liegt im -c Parameter von su, wo du ein Kommando oder eine Kommandofolge mitgeben kannst, die dann als root ausgeführt werden soll. Also sowas wie
Das führt den Mount-Befehl als root aus und macht dann im Skript ganz normal wieder als User weiter.
Sorry, ich sehe jetzt nicht, welcher Link nichg geht. Es macht immer Sinn, wenn du bei so einer Frage genau sagst, was exakt nicht geht. Aber ich hab mit dem megamaced Repository etwas Verwirrung gestiftet, ich will das wieder aufräumen und dir zeigen, wie du auf das aktuelle Versuchspaket umsteigst:
Für alle Schritte außer dem ersten siehe Spotify
PS: Alle Links sind geprüft ![]()
Habe meine Anleitung entsprechend angepasst: Spotify
Das habe ich gemacht, es geht trotzdem nicht. Ich habe jedenfalls kein Spotify gefunden. Und bei dem ersten Befehl ist nichts passiert.
Ist schon was passiert: er beschwert sich über eine falsche Option. Ok, mein Fehler. Inzwischen kennt spotify-easyrpm die -noroot-Option nicht mehr. Und der Autor verweist auch explizit auf das Versuchspaket: GitHub - megamaced/spotify-easyrpm: Download, convert and install the Spotify for Linux package (die Download Links ganz unten gehen auf die 1-Klick-Installer des Versuchspaketes).
Da werde ich meine Anleitung korrigieren: lasse -noroot weg.
Ich find es auch nicht unbedingt prickelnd, unbedarften Usern Versuchspakete und Einklicker zu empfehlen.
Auch wenn es vielleicht von der ursprünglichen Frage ablenkt, möchte ich dazu noch etwas ausholen und die Themen Versuchspakete, Community Repos und 1-Klicker etwas näher beleuchten.
Versuchspakete
Die openSUSE Distributionen Leap oder Tumbleweed bestehen aus tausenden von Paketen, die voneinander abhängen. Zusammen entsteht ein riesiger Baum aus Abhängigkeiten. Einige Basispakete bilden eine Grundlage und stellen Bibliotheken mit oft genutzten Funktionen zur Verfügung. Ein Beispiel könnte openssl sein. Andere kann man eher einer Mittelschicht zuordnen. Sie bauen auf den Basispaketen auf, stellen aber ihrerseits wieder eine Grundlage für andere Pakete zur Verfügung. Hier fällt mir z.B. das KDE Framework oder ähnliches ein. Eine dritte Gruppe findet sich eher am Ende des Baumes, bei den Blättern. Diese Pakete hängen zwar von vielen anderen Paketen ab, stellen aber selbst keine Dienste oder Funktionen zur Verfügung. An dieser Stelle stehen viele Applikationen.
Wenn ich ein Versuchspaket einbinden möchte, dann sollte ich mir sehr genau die Frage stellen, wo dieses in der Hierarchie steht und welche Abhängigkeiten es hat. Tauscht man nämlich vorhandene Pakete aus der Basis- oder Mittelschicht aus, so ist die Wahrscheinlichkeit groß, dass man Abhängigkeiten in der Applikationsschicht bricht. Ein Beispiel ist das KDE Framework, das vor kurzem hier ebenfalls diskutiert wurde.
Installiere ich dagegen eine Applikation, die es in den Basis-Repos noch gar nicht gibt, dann ist die Wahrscheinlichkeit gering, dadurch Abhängigkeiten anderer Pakete zu verletzen. Trotzdem schaue ich mir auch hier die Abhängigkeiten ganz genau an, bevor ich auf das letzte OK klicke. snapd gehört in diese Kategorie, deshalb kann ich mir vorstellen, dass das funktioniert. Schaue ich mir dann noch in den Meta-Infos im OBS die Build-Umgebung an, dann sehe ich , dass der Buld ausschließlich auf den Standard Repositories aufsetzt (Meta Configuration of system:snappy -
openSUSE Build Service).
Community Pakete
openSUSE lebt vom Mitmachen. Deshalb finde ich es toll, dass hier jeder im OBS seine Pakete bauen und der Allgemeinheit zur Verfügung stellen kann. Klar ist aber auch: dafür gibt es keine openSUSE Qualitätskontrolle. Bevor ich also so ein Paket verwende, schaue ich es mir schon sehr genau und es schadet nicht, wenn man sich da etwas tiefer auskennt.
Zu spotify-easyrpm habe ich mir die verschiedenen Community Repos genau angeschaut. Ich habe mir auch angeschaut, wer da wirklich aktiv ist und wer nur für den persönlichen Gebrauch eine kleine Änderung eingebracht hat. So fiel meine Wahl auf megamaced. Dieser User hat wesentlich an dem Paket weiterentwickelt und scheint es aktiv zu warten. Inzwischen gibt es sogar ein Versuchspaket davon - der erste Schritt in Richtung Aufnahme in die Distribution, und vielleicht würde ich inzwischen auch das empfehlen, aber das will ich mir erst genauer ansehen.
Ich sag mal so: ein Community Paket ist wie Gebrauchtwagenkauf von privat. Wenn du keine Ahnung hast, kannst du nicht feststellen ob du eine Rostlaube erwischst oder eine solide Karre. Dann lass besser die Finger davon. Aber wenn du dich selbst auskennst oder aus glaubwürdiger Quelle Informationen dazu bekommst, dann kannst du auch da zugreifen.
1-Klick-Installer
Und jetzt noch zum letzten Thema. Hier im Forum werden die 1-KJlick-Installer oft pauschal negativ beurteilt. Doch was ist ein 1-Klick-Installer eigentlich? Die ymp-Datei enthält lediglich eine Art vorausgefülltes Formular für das Hinzufügen eines (oder mehrerer) Repositories und die Installation eines (oder mehrerer) Pakete. Wenn ich weiß, was ich tue, dann nimmt mir der 1-Klick-Installer einiges an Arbeit ab. Er verhindert Tippfehler, weiß die richtige URL zum Repository usw.
Wenn ich nicht weiß was ich tue, dann kann ich mit YaST oder zypper genau das gleiche Unheil anrichten wie mit dem 1-Klick-Installer. Und noch was: In der Vergangenheit gab es im Forum immer wieder Hilferufe von Usern, die sich mit einem 1-Klick-Installer ihr Leap-System vertumbleweeded hatten. Das ist inzwischen nicht mehr so leicht möglich! Seit einigen Monaten enthalten alle 1-Klick-Installer von software.o.o einen distversion Eintrag, der verhindert, dass man ihn auf einen unpassenden System installieren kann (siehe Seit heute: distversion in software.o.o 1-Klick-Installern). Und seitdem habe ich auch keinen derartigen Hilfereuf mehr in diesem Forum gehört.
Mit diesem Hintergrund bleibe ich dabei: