lokales repository (gelöst)

[guennid]

Ich arbeite schon lange mit eigenem repository und dpkg-scanpackages. Seit etch ist aber zusätzlich Verschlüsselung angesagt. Gehe ich recht in der Annahme, dass ich bei jeder Veränderung des lokalen Paketlagers außer dpkg-scanpackages+ apt-get update die im Wiki dargelegte Verschlüsselungsorgie neu inszenieren muss?
Oder würde es reichen, apt-ftparchive nach dpkg-scanpackages+ apt-get update auszuführen?

Zur Erklärung der Frage: Bisher reichten die Befehle scanpackages und update zum Installieren aus. apt meckert seit etch über nicht autorisierte Quellen und ignoriert das lokale Paketlager.
Seit ich die im wiki beschriebene Vorgehensweise einmal verwendet habe, werden neu ins repository aufgenommene Pakete nicht mehr erkannt, wenn ich vorher lediglich dpkg-scanpackages und apt-get update ausgeführt habe.

Grüße, Günther

[Meillo]

Gehe ich recht in der Annahme, dass ich bei jeder Veränderung des lokalen Paketlagers außer dpkg-scanpackages+ apt-get update die im Wiki dargelegte Verschlüsselungsorgie neu inszenieren muss?

Du signierst ja deine Release-Datei. Jedes Mal wenn die sich ändert, dann musst du auch eine neue Signatur dafür erstellen.
Also jedesmal wenn sich im Repo irgendwas ändert.
Das ist IMO auf http://michael.stapelberg.de/Artikel/Debian_Repository sehr schön zu sehen.

vgl. auch http://wiki.debianforum.de/EigenesRepository

[guennid]

Danke für die Hinweise.
Ich habe diesen wiki-Eintrag verwendet.
Meine Frage ist: Ich muss aber doch nicht jedesmal den Schlüssel neu erzeugen? Anders gefragt: brauche ich die Befehle in "meinem" wiki-Artikel

Code: Alles auswählen

gpg --gen-key --homedir /Pfad zum Lager
apt-key add /Pfad zum Lager/pubring.gpg

nur einmal auszuführen?

Im Grunde stört mich aber eigentlich ganz was anderes, wofür ich wahrscheinlich fälschlicherweise die fehlende Verschlüsselung verantwortlich gemacht habe. Obwohl sich das gleiche Paket wie in security.debian.org auf der Platte befindet, versucht apt-get install es aus dem Netz zu holen. Das lokale Repo ist 1. Eintrag in der sources.list.
Wie kann ich ihm das abgewöhnen?

Grüße, Günther

[Meillo]

Ich habe diesen wiki-Eintrag verwendet.

klasse! Der ist von mir

Meine Frage ist: Ich muss aber doch nicht jedesmal den Schlüssel neu erzeugen? Anders gefragt: brauche ich die Befehle in "meinem" wiki-Artikel

Code: Alles auswählen

gpg --gen-key --homedir /Pfad zum Lager
apt-key add /Pfad zum Lager/pubring.gpg

nur einmal auszuführen?

nein (bzw. ja) ... du brauchst (ja sollst sogar) das nur einmal tun.
Denn wenn du mal einen Schlüssel hast, dann kannst du mit dem beliebig viele Dinge ver-/entschlüsseln. Auch solltest du ihn (den PublicKey) bekannt machen (für den Fall, dass jemand anderes deine Pakete auch nutzt und prüfen möchte), da wäre es ja ziemlich doof, wenn die anderen alle paar Wochen einen neuen Public-Schlüssel von dir besorgen müssten.

apt-key ist sowas wie ein Schlüsselbund, dem du deinen PublicKey hinzufügst um die mit deinem PrivateKey signierten Pakete zu prüfen.

Im Grunde stört mich aber eigentlich ganz was anderes, wofür ich wahrscheinlich fälschlicherweise die fehlende Verschlüsselung verantwortlich gemacht habe. Obwohl sich das gleiche Paket wie in security.debian.org auf der Platte befindet, versucht apt-get install es aus dem Netz zu holen. Das lokale Repo ist 1. Eintrag in der sources.list.
Wie kann ich ihm das abgewöhnen?

Okay, das ist ein ganz anderes Problem, das vermutlich in einem extra Thread besser aufgehoben ist (entweder du startest einen neuen, oder ein Mod teilt ... oder noch besser du findest eine Lösung im Forum)

Solange du keine gleichen Pakete (in verschiedenen Versionen) in deinen Repos hast, ist alles kein Problem.
Falls nun aber gleiche Pakete in verschiedenen Repos liegen, dann entscheidet die Priorität der jeweiligen Repos von wo installiert wird. Die Reihenfolge in der sources.list ist irrelevant.
... hier hört mein Wissen aber auf - ich habe keine Erfahrungen auf diesem Gebiet.
Was ich aber sagen kann, ist dass du es mit apt-pinning lösen kannst. Du kannst deinem Repo eine höhere Priorität geben.
Ob das aber die beste/einzige Lösung ist, kann ich nicht sagen.

[guennid]

Nach mehreren Stunden geb ich jetzt erst mal auf. Habe versucht mich über apt-pinning schlau zu machen, aber ich krieg es nicht gebacken, dem lokalen Repo eine höhere Priorität einzuräumen. Ich brauche den Code. Alles, was ich gefunden habe, beschäftigt sich mit backports, oder dem Mischen von stable, unstable, etc. Nichts ging auf lokale Repos ein.
Das Repo habe ich unter /root/inst.
Ich hab's versucht mit

Code: Alles auswählen

Package: *
Pin: origin /root/inst
Pin-Priority:1001

und mit

Code: Alles auswählen

Package: *
Pin: origin ""
Pin-Priority:1001

apt bevorzugt nach wie vor security. debian.org

Hier vielleicht noch die Ausgabe von apt-cache policy:

Code: Alles auswählen

Paketdateien:
 100 /var/lib/dpkg/status
     release a=now
 500 http://security.debian.org stable/updates/contrib Packages
     release o=Debian,a=stable,l=Debian-Security,c=contrib
     origin security.debian.org
 500 http://security.debian.org stable/updates/main Packages
     release o=Debian,a=stable,l=Debian-Security,c=main
     origin security.debian.org
 500 http://ftp.de.debian.org etch/non-free Packages
     release v=4.0r1,o=Debian,a=stable,l=Debian,c=non-free
     origin ftp.de.debian.org
 500 http://ftp.de.debian.org etch/contrib Packages
     release v=4.0r1,o=Debian,a=stable,l=Debian,c=contrib
     origin ftp.de.debian.org
 500 http://ftp.de.debian.org etch/main Packages
     release v=4.0r1,o=Debian,a=stable,l=Debian,c=main
     origin ftp.de.debian.org
 500 file: ./ Packages
     release c=
Festgehaltene Pakete (»Pin«):

Grüße, Günther

[Meillo]

Hier vielleicht noch die Ausgabe von apt-cache policy:

Ich denke, da hast du dich selbst auf den richtigen Weg gebracht.
Dein Repo hat immer noch eine Priority von 500. Die sollte AFAIR aber höher sein.

schau mal in `man apt_preferences' (falls nicht schon getan)
das sieht nach kurzem Überfliegen ganz gut aus


das hilft dir vielleicht auch weiter

[guennid]

Danke für deine Bemühungen, aber ich bin wohl zu dumm für diese Doku.
Ich blick nicht durch, weder in man apt_preferences noch in dem Beitrag hinter deinem link. Hab ich wenigstens dieses Prinzip richtig interpretiert: je höher die Zahl hinter "Pin-Priority", desto eher wir ein Paket aus dem zugehörigen Repo installiert?

"]Dein Repo hat immer noch eine Priority von 500

Ich glaube eher, mein repo taucht da gar nicht auf bei apt-chache policy.
Wenn ich folgendes in die preferences schreibe:

Code: Alles auswählen

Package: *
Pin: origin
Pin-Priority: 510

Dann erst tauchen (vielleicht?) meine Zahlen in der Ausgabe von apt cache policy auf. Wenn ich 1001 eingebe, erscheint das, bei 999 eben 999. Entscheidend ist wohl die 2. Zeile. Nur in dieser Form taucht etwas der von mir eingegenben Priorität Kongruentes in apt cache policy auf.
Das sieht dann z.B so aus:

Code: Alles auswählen

...
510 file: ./ Packages
              relesae c=

aber was ist jetzt: ./ ? Ganz egal welches Verzeichnis ich als das aktuelle wähle, die Ausgabe ist immer die gleiche.
- Und bevorzugt wird nach wie vor: security.debian org

Grüße, Günther

[Meillo]

Hmm ... tut mir leid, ich weiß leider nicht mehr weiter.
(Und hab gerade auch keine Zeit bei mir eine ähnliche Umgebung aufzusetzen.)

... vielleicht weiß ja noch jemand anderes Rat.

[guennid]

Es ist vollbracht.
Wie üblich, saß die Fehlerquelle ca. 30-50cm vor dem Bildschirm.
Da ich keine Lust hatte, mir diese Befehlszeilenungetüme zu merken, habe ich sie in eine batch-Datei geschrieben:

Code: Alles auswählen

#!/bin/sh
cd /
cd /root/inst
# die folgende Zeile ist falsch, siehe meinen nächsten post!
dpkg-scanpackages ./ /dev/null | gzip > Packages.gz
apt-get update
# gpg --gen-key --homedir /root/inst
# apt-key add /root/inst/pubring.gpg
apt-ftparchive release . > Release
gpg --homedir /root/inst/ -a --yes --output Release.gpg -b Release

In dieser Form hat es nicht funktioniert. Nachdem ich apt-get update ans Ende der Befehlsliste befördert hatte, war alles paletti:

Code: Alles auswählen

#!/bin/sh
cd /
cd /root/inst
# die folgende Zeile ist falsch, siehe meinen nächsten post!
dpkg-scanpackages ./ /dev/null | gzip > Packages.gz
# gpg --gen-key --homedir /root/inst
# apt-key add /root/inst/pubring.gpg
apt-ftparchive release . > Release
gpg --homedir /root/inst/ -a --yes --output Release.gpg -b Release
apt-get update

Die auskommentierten Zeilen kann man verwenden, wenn man das Repo neu anlegt - also die Schlüssel neu erzeugen muss. Ohne Verschlüsselung hat die batch übrigens auch in der letzten Form nicht funktioniert.
Ob die Zeile:

Code: Alles auswählen

gpg --homedir /root/inst/ -a --yes --output Release.gpg -b Release

nötig ist, soll Meillo beurteilen. Ich weiß sowieso nicht ganz genau, was ich da tue.

Ach ja, eh ich's vergesse: Dieser Eintrag in der preferences ist der richtige:

Code: Alles auswählen

Package: *
Pin: origin
Pin-Priority: 990

990 macht das lokale Repo zum Standard-Repo. Es sollte auch jeder Eintrag Pin-Priority > 500 genügen.
Vorsicht mit Pin-Priority > 1000. Das könnte u.U. ein unbeabsichtigtes downgrade nach sich ziehen - Wenn ich das alles richtig verstanden habe.

Grüße Günther und nochmals vielen Dank an Meillo.

[Meillo]

Es ist vollbracht.

klasse

Ob die Zeile:

Code: Alles auswählen

gpg --homedir /root/inst/ -a --yes --output Release.gpg -b Release

nötig ist, soll Meillo beurteilen. Ich weiß sowieso nicht ganz genau, was ich da tue.

ja, die ist nötig, denn die erzeugt die Signatur der 'Release'-File. Diese muss jedes Mal neu generiert werden, wenn sich die Release-File ändert. Diese ist höchstwahrscheinlich immer dann der Fall, wenn das Script ausgeführt wird.
Die Zeile ist also notwendig!
(siehe auch `man gpg')

Ach ja, eh ich's vergesse: Dieser Eintrag in der preferences ist der richtige:

Code: Alles auswählen

Package: *
Pin: origin
Pin-Priority: 990

990 macht das lokale Repo zum Standard-Repo. Es sollte auch jeder Eintrag Pin-Priority > 500 genügen.
Vorsicht mit Pin-Priority > 1000. Das könnte u.U. ein unbeabsichtigtes downgrade nach sich ziehen - Wenn ich das alles richtig verstanden habe.

Kann das bitte jemand in's Wiki übernehmen.
Da steht dieses Problem noch ungelöst offen.
... ich habe gerade recht wenig Zeit ... also, falls sich jemand Freiwilliges findet (sonst mache ich es halt in ein paar Tagen ... wenn ich es nicht vergesse.)

nochmals vielen Dank an Meillo

bitte, gerne ... hat mich ja auch weitergebracht

[guennid]

Muss noch etwas korrigieren: dpkg-scanpackages funktioniert nicht in der Form, in der ich das hier zuletzt gepostet habe. (Habe ich nach einem Hinweis von einem der Gründungsväter des df (pdreker) in diesem thread ca. vier Jahre lang so verwendet. Tut auch jetzt noch, wenn man außer dem eigenen Repo und evtl den CDs/DVDs in der sources.list alles andere ausknipst.). Es fehlt dann die Datei Packages. Und ohne die meckert die Verschlüsselung. Es muss die von Mr_Snede in diesem Wiki-Artikel verwendete Form benutzt werden, also:

Code: Alles auswählen

dpkg-scanpackages ./ /dev/null > Packages && gzip -c Packages > Packages.gz

Das ist keine Geschmacksfrage, wie man nach der Lektüre des Wikis meinen könnte.
Ich formuliere meinen letzten Beitrag entsprechend neu.

Grüße, Günther