Ungewollt aufgezwungene Repo-Einträge entfernen und verhindern

Hinweis: In dem Thema Ungewollt aufgezwungene Repo-Einträge entfernen und verhindern gibt es 10 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Das ist jetzt kein Muss, aber vielleicht geht es dem einen oder anderen auch so wie mir, das er sich darüber aufregt, das man in seinen Repo-Listen immer und immer wieder Einträge aufgezwungen bekommt, die man gar nicht haben will.


    So scheint es jetzt die neueste Politik von openSUSE zu sein, dem User vorzuschreiben, welche Repos er haben darf und welche nicht. Ich habe jetzt unter Tumbleweed, Tumbleweed-Slowroll und Leap 15.6 ein und das selbe feststellen müssen, nämlich, das in der Repo-Liste immer und immer wieder zwei Einträge hinzu gefügt werden, die ich nicht haben will. Es handelt sich hierbei um ein Debug - und ein Source-Repo. Diese sind letztendlich auch noch deaktiviert.


    Nachdem ich diese gelöscht hatte, weil ich sie nicht brauchte und auch nicht will, musste ich feststellen, das nach dem nächsten Start oder Aufruf von Zypper alles wieder da war.


    Sowas regt mich auf .... also habe ich mich auf die Suche begeben, wer für diesen Unsinn verantwortlich ist und bin auch fündig geworden.


    Was benötigen wir, um diesen Unfug zu beenden? Einen Text-Editor im Root-Modus. Das ist alles.


    Wie hängt das alles nun also zusammen?


    Unter usr/share/zypp/local/service/openSUSE/repo/opensuse-slowroll-repoindex findet man die Datei, die eine andere Datei mit Daten versorgt. Erklärung später. In dem Fall hier gehe ich von slowroll aus, andere Distributionen wie Leap oder Tumbleweed tragen nur einen anderen Namen. Unter Leap15.6 ist es dann /opensuse-leap-repoindex.

    Repoindex steht in dem Ordner zwei mal da. Uns interessiert nur der erste Eintrag, der größere. Der zweite ist nur ein Backup.


    Was machen wir in der Datei? Wir öffnen sie und entfernen den debug und source Eintrag. Nur diese! Speichern und beenden.


    Welchen Hintergrund hat diese Geschichte? Nun, es gibt noch weitere Dateien, die mit der ganzen Sache zu tun haben. Hierbei handelt es sich um die Datei etc/zypp/service.d.

    Darunter findet sich eine Datei openSUSE.service. Diese öffnen wir und entfernen ebenso die beiden source und debug Einträge. Wie wir unschwer an dem url in der Datei erkennen, können (url = dir:/usr/share/zypp/local/service/openSUSE), bezieht diese Datei ihre Daten von jener Datei, die wir im ersten Teil schon behandelt haben. Da wir dort aber die bewussten Einträge entfernt haben, sind diese nicht mehr existent. Speichern und beenden. Ich habe natürlich vorher auch noch die Nummerierung angepasst.


    Letzter Schritt: etc/zypp/repos.d öffnen, die beiden bewussten Einträge löschen.


    Somit erscheinen die unerwünschten Repo-Einträge nach Abschluss der Operation nicht mehr und werden auch nicht mehr hinzu gefügt. Das System kann updaten, ohne die störenden Einträge wieder zu produzieren.


    Nun kann man der Meinung sein, das es sich hierbei nur um eine kosmetische Operation handelt und man kann der Meinung sein, dass das auch so sei. Aber ich lasse mir von niemandem etwas aufzwingen, das ich nicht haben will. Punkt.


    Bei der Gelegenheit habe ich unter den betreffenden Ordnern auch gleich noch das ganze Nvidia-Gedöhns komplett entfernt, weil ich das nicht benötige und ich auch nicht jedesmal beim Updaten gefragt werden will, ob ich einem Schlüssel zu einer Software vertrauen will, die ich nicht installiert habe und die ich auch gar nicht haben möchte.


    Sicher kann man über vorliegenden Beitrag geteilter Meinung sein, aber dem einen oder anderen wird es evtl. helfen, die ganze Geschichte der Repos etwas besser zu verstehen.


    Und, was ich noch erwähnen möchte. Bei einem immutable System, also einem unveränderlichen System, funktionieren solche Spielereien dann nicht mehr, dann musst du, auf deutsch gesagt, fressen, was du vorgeworfen bekommst. Und aus diesem Grunde sträube ich mich, ein solches System zu benutzen.


    Wen die Sache nicht interessiert, der kann diesen Psalm lesen und vergessen. Der sehe es als Prosa eines gelangweilten Administrators ... æđ


    Wem es vielleicht auch so geht wie mir, der ist jetzt nicht unbedingt dümmer geworden und weiß, wie er sich wehren kann.


    Good Luck ...


    Nachtrag: Meine Systeme laufen jetzt schon mehrere Wochen mit dieser Konfiguration und es gibt keine weiteren zusätzlichen Einträge in die Repo-Liste. Sicher kann es sein das bei einem größeren Update wieder mal etwas eingetragen wird, aber bis jetzt konnte ich, auch nach großen Updates, noch nichts dergleichen feststellen. Falls das der Fall sein sollte, weiß man jetzt, wo man suchen muss.

  • Alero

    Hat das Thema geschlossen.
  • Das von ihm beschriebene Verhalten wird durch ein paar rpms erzeugt, einfacher ist es, diese rpms zu löschen und zu sperren.


    Hier bei mir sind die von Alero beanstandeten Verzeichnisse leer:

    Code
    ls -al /etc/zypp/services.d/
    insgesamt 8
    drwxr-xr-x  2 root root 4096 13. Jun 14:55 .
    drwxr-xr-x 10 root root 4096  2. Aug 09:41 


    Code
    ls -al /usr/share/zypp/
    insgesamt 20
    drwxr-xr-x   3 root root  4096 13. Jun 14:55 .
    drwxr-xr-x 432 root root 12288 11. Aug 11:59 ..
    drwxr-xr-x   3 root root  4096 13. Jun 14:55 schema

    Und jetzt füllen wir diese mit Leben:

    Nun mal schauen:

    Code
    ls -al /etc/zypp/services.d/
    insgesamt 12
    drwxr-xr-x  2 root root 4096 13. Aug 10:55 .
    drwxr-xr-x 10 root root 4096  2. Aug 09:41 ..
    -rw-r--r--  1 root root   95 13. Aug 10:55 openSUSE.service

    und

    Und schon ist klar, wer der Übeltäter ist.........


    Hatte ich aber Alero schon gesagt, einfach die rpms löschen und gut.

    Für den Inhalt des Beitrages 315448 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Weiter geht es:

    Dann noch löschen und sperren und gut.

    Code
    ls -al /etc/zypp/services.d/
    insgesamt 8
    drwxr-xr-x  2 root root 4096 13. Aug 11:05 .
    drwxr-xr-x 10 root root 4096  2. Aug 09:41 ..
    Code
    ls -al /usr/share/zypp/
    
    insgesamt 20
    
    drwxr-xr-x   3 root root  4096 13. Aug 11:05 .
    
    drwxr-xr-x 432 root root 12288 11. Aug 11:59 ..
    
    drwxr-xr-x   3 root root  4096 13. Jun 14:55 schema

    Bitte auch noch beachten:

    GitHub - openSUSE/openSUSE-repos: openSUSE-repos
    openSUSE-repos. Contribute to openSUSE/openSUSE-repos development by creating an account on GitHub.
    github.com


    Bei mir betraf der letzte Punkt das SLE-Update Repo, einfach das .rpmsave entfernt und wieder da.


    Sauerland

    Für den Inhalt des Beitrages 315449 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Sind nun zwei Wege in diesem Thread ... kann sich jeder aussuchen, was ihm lieber ist ...

  • Nur als Info:

    Bei deinem Weg könnte mit einem Update des rpms alles wieder rückgängig gemacht werden.......

    Ob es das gibt sei dahingestellt, aber es wäre möglich.


    Bei mir wird gelöscht und gesperrt.

    Für den Inhalt des Beitrages 315451 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Ja, gut, wir haben jetzt zwei Wege aufgezeigt, wir müssen das nicht mehr vertiefen. Die meisten werden eh nicht folgen können oder wollen ....


    Ist nur mal so ein Gag am Rande ...

  • Das Ganze lässt sich sinngemäß auch auf das NVIDIA-Repo anwenden.

    Das ganze Nvidia Zeugs habe ich komplett gelöscht und auch im Yast gesperrt ...

  • Siehe Beitrag#3 Code-Tag #1.


    Dort ist ein lock auf das nicht installierte openSUSE-repos-Leap-NVIDIA gesetzt.


    Bei Tumbleweed gibts auch noch slowroll-repos-rpms usw.

    Für den Inhalt des Beitrages 315459 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Nachtrag: Trotz vieler Updates in der Zwischenzeit funktioniert die Variante aus Post 1 immer noch ausgezeichnet. Im Leap 15.6 ebenso wie im Tumbleweed.