Allowed Origins und Origins Pattern fuer Unattended-Upgrades

[vdvogt]

Hallo,
ich versuche seit ein, zwei Wochen meine Rechner dazu zu bewegen, doch endlich ohne mein Zutun immer die Updates selbst zu machen.
Dazu habe ich unattended-upgrades installiert.
Da ich bei einem Rechner auch Iceweasel-Aurora habe, soll der natuerlich auch immer auf dem neuesten Stand sein, daher habe ich auch das noch eingefuegt.
Aber leider funktioniert unattended-upgrades nicht so wie es sein sollte, insbesondere werden keine Updates fuer Iceweasel-Aurora gemacht.
Woran koennte das liegen?
Ich vermute, dass irgendwas in 50unattended-upgrades falsch ist.
Hier deshalb ein Auszug aus 50unattended-upgrades:

Allowed-Origins:
"Debian, stable";
"Debian, stable-security";
"Debian, stable-updates";
"Debian, stable-proposed-updates";
Reicht das aus, oder fehlt hier schon ein Eintrag fuer Iceweasel-Aurora?

Origins-Pattern: (Zeilennummerierung nur um besser Bezug darauf nehmen zu koennen)
01 "origin=Debian, archive=stable";
02 "origin=Debian, archive=stable-security";
03 "origin=Debian, archive=stable-updates";
04 "origin=Debian, archive=stable-proposed-updates";
05 "origin=Debian, archive=stable, label=Debian-Security";
06 "origin=Debian, archive=stable, label=debian-security";
07 "origin=Mozilla.Debian, archive=wheezy-backports, label=iceweasel-aurora";
08 "origin=Debian Backports, archive=wheezy-backports, label=Debian Backports";

Grundsaetzliche Frage: Ist das hier case sensitive? Dann ist entweder Zeile 05 oder 06 ueberfluessig.

Sind die Eintraege richtig?
Wenn nein, bitte Hinweise wie es richtig sein muesste.

Vielen Dank!
vdvogt

[rendegast]

05, 06 wären so schon in 01 eingeschlossen.
Bei 05, 06 würde ich 05 bevorzugen, sodaß:

Code: Alles auswählen

Unattended-Upgrade::Origins-Pattern:: "origin=Debian,archive=stable,label=Debian-Security";
Unattended-Upgrade::Origins-Pattern:: "origin=Debian,archive=stable,label=Debian";

02 dürfte nicht treffen.

Bzgl. 08 "origin=Mozilla.Debian", "label=iceweasel-aurora"
http://mozilla.debian.net/dists/wheezy- ... ts/Release:

Origin: Debian Mozilla Team
Label: Debian Mozilla Team
Suite: wheezy-backports
Codename: wheezy-backports

resp. http://mozilla.debian.net/dists/wheezy- ... 64/Release:

Archive: wheezy-backports
Component: iceweasel-aurora
Origin: Debian Mozilla Team
Label: Debian Mozilla Team
Architecture: amd64

Vorlage wäre aber auch

Code: Alles auswählen

apt-cache policy | grep release

Damit das auch aufgerufen wird braucht es noch sowas (siehe /etc/cron.daily/apt):

Code: Alles auswählen

APT::Periodic::AutocleanInterval "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Enable "1";
APT::Periodic::RandomSleep "11";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Update-Package-Lists "1";

(kleiner RandomSleep, da es sonst bis 1/2 Stunde herumidlen kann)

Ich empfehle Installation von anacron,
und dann vielleicht noch Individualisierung der Zeit in /etc/cron.d/anacron
(das wäre die Zeitvorgabe für das Anstoßen der periodischen Jobs (daily/weekly/monthly) durch anacron bei regulärem Betrieb),
muß ja nicht sein daß alle mit anacron ausgerüsteten debian-Maschinen die mirrors um 07:30 anlaufen.
Analog ohne anacron für die Standard-crontab.

[vdvogt]

Hallo rendegast,
vielen vielen Dank!
Nach diesen Infos habe ich gesucht, aber wohl nicht an der richtigen Stelle!
Jetzt sollte es auch mit unattended-Upgrades funktionieren.
10periodic habe ich.

APT::Periodic::RandomSleep "11";
(kleiner RandomSleep, da es sonst bis 1/2 Stunde herumidlen kann)
Was idled da?
Wofuer das?


Wozu anacron?
Ich habe bei 10periodic ein taegliches update eingestellt und in der crontab die Zeit, wann das ausgefuehrt wird auf nachtschlafende Zeit eingestellt, so dass es bestimmt niemanden stoert.

Gruesse
vdvogt

[rendegast]

da es sonst bis 1/2 Stunde herumidlen kann)
Was idled da?
Wofuer das?

Das Skript /etc/cron.daily/apt bleibt einfach solange stehen.
Es steht (alphabetisch "a...") am Anfang der seriell abgearbeiteten Jobs.
Bei Dauerbetrieb könnte mensch das auch egal sein.
Bei nur gelegentlichem kurzen Einschalten (mit anacron) bräuchte es dann aber 5+x Minuten Laufzeit zur Abarbeitung der daily <-> wenn aber schon nach ~ 10min wieder ausgeschaltet wird.

Ich denke, es sollte eine Lastverteilung der Server erreicht werden.
(Bei windows eleganter gelöst: Die stündlich wählbare Upgradezeit (wobei da auch ein random-Faktor dazukommt),
ist nur die Zeit des Upgrade-Einspielens, geholt werden sie durch den upgrade-Dienst aber irgendwann vorher,
durch Kommunikation mit dem Server wird eine Lastverteilung gesteuert.
(Hint: dieser Vorgang läuft bei mir lokal aber zum einen IMMER im unpassenden Moment und verbraucht dann zum anderen massiv Ressourcen (viiiiel Plattenaktivität, hunderte MB Ram (<-> linux )
<-> mein walkaround: Separierung des wuaclt und Heruntersetzen zur idle-Priority:

Code: Alles auswählen

net stop wuauserv
sc config wuauserv type= own
net start wuauserv

ist permanent, dann noch

Code: Alles auswählen

wmic process where name="wuauclt.exe" CALL setpriority "idle"

als taskmanager-Job @startup, es geht wohl auch als Vorgabe in der Registry.
))

Wozu anacron?

Irgendwann ist der Rechner dochmal aus, sei es stromlos oder s2d,
wenn das gerade bei wichtigen(?) daily/weekly/monthly war, dauert es mit cron alleine day/week/month bis zur nächsten Ausführung,
mit anacron beim nächsten Systemstart/Aufwecken (maximal bis zum nächsten daily).

[vdvogt]

Hallo rendegast,
vielen Dank fuer die Erklaerung!
Habe ich im Wesentlichen verstanden.
Mein Rechner(Server) laeuft immer, es sein denn ich reboote mal kurz, das geschieht aber, wenn ueberhaupt, am Tag.
Alles andere (daily, weekly, monthly...) habe ich auf die Nachtstunden verschoben, so dass es mich zumindest nicht bei der Arbeit stoehren sollte.
Und ich habe in der letzten Zeit auch nicht bemerkt, dass irgendwas davon am Tag laeuft, weil es nachgeholt wird. Toi, toi, toi.

Noch 'ne Frage zu unattended-upgrades:
Wenn ich ueberall da wo zur Zeit Wheezy drin steht, (sources.list, 50unatt.....) stable rein schreibe, dann muesste doch beim Releasewechsel (von zur Zeit Wheezy auf das kommende Jessy) auch dieser automatisch vorgenommen werden?
Oder gibt es speziell zum Releasewechsel was zu Beachten?

Gruesse
vdvogt

[rendegast]

Wenn ich ueberall da wo zur Zeit Wheezy drin steht, (sources.list, 50unatt.....) stable rein schreibe, dann muesste doch beim Releasewechsel (von zur Zeit Wheezy auf das kommende Jessy) auch dieser automatisch vorgenommen werden?

Es muß "passen".
Aus 'apt-cache policy':

Code: Alles auswählen

     release o=Debian,a=experimental,n=experimental,l=Debian,c=main
     release o=Debian,a=stable-updates,n=wheezy-updates,l=Debian,c=main
     release o=Debian,a=testing,n=jessie,l=Debian,c=main
     release o=Debian,a=unstable,n=sid,l=Debian,c=main
     release v=,o=Debian Backports,a=wheezy-backports,n=wheezy-backports,l=Debian Backports,c=main
     release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google,c=main
     release v=7.0,o=Debian,a=stable,n=wheezy,l=Debian-Security,c=main
     release v=7.4,o=Debian,a=stable,n=wheezy,l=Debian,c=main

Bsp. die Zeile der backports: es gibt gar kein "stable",
die Zeile google: es gibt kein "wheezy".
Und bzgl. unattanded-upgrade

Code: Alles auswählen

        # first char is apt-cache policy output, send is the name
        # in the Release file
        if what in ("o", "origin"):
            res &= (value == origin.origin)
        elif what in ("l", "label"):
            res &= (value == origin.label)
        elif what in ("a", "suite", "archive"):
            res &= (value == origin.archive)
        elif what in ("c", "component"):
            res &= (value == origin.component)
        elif what in ("site",):
            res &= (value == origin.site)

Das release-Feld 'name' wird nicht verwendet und würde einen ungültigen Eintrag produzieren.
Es kann nur mit den Feldern o=, l=, a=, c=, und dem 'origin' ('apt-cache policy') == 'site' (unattended-upgrade) gearbeitet werden.
<-> Dagegen kann auf das Feld 'n=' in der preferences Bezug genommen werden.

Vergleiche auch die "beiden" Release-Dateien einer Distribution
ftp://ftp.de.debian.org/debian/dists/stable/Release
ftp://ftp.de.debian.org/debian/dists/st ... 64/Release
"wheezy" taucht als 'Codename:' nur in einer der beiden auf,
das 'Suite:' der einen Datei entspricht dem 'Archive:' der anderen.

Oder gibt es speziell zum Releasewechsel was zu Beachten?

Ich möchte nicht unbeobachtet hunderte Pakete eingespielt bekommen.
Der Filter dafür ist bei mir preferences
- "wheezy" Priority 500
- stable/testing/unstable/backports Priority 1xx
- weitere (explizit) Priority 1xx
Abschluß installierte und sonstige nicht explizit genannte:

Code: Alles auswählen

...

Package: *
Pin: release a=now
Pin-Priority: 100

Package: *
Pin: release a=*
Pin-Priority: 55

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

Showstopper versuche ich frühzeitig zu erkennen und sie mir einzeln vorzunehmen.
Bsp. dovecot(1.x, squeeze) -> dovecot2 (wheezy) bin ich lange per Verbleiben in oldstable aus dem Wege gegangen,
habe dann dovecot2 aus den squeeze-backports verwendet und mich mit dem neuen Syntax "angefreundet".
Der Releasewechsel war dann um einiges lockerer.



-----------------------------------------------------------------------------------------
(Ein denkbarer Angriff von google/nsa wäre dann immer noch,
ihr Release kurz mal "Debian, stable" zu nennen und die libc vieler linux-Maschinen zu tauschen(?)
Würde google das überleben? war ja für die nationale Sicherheit)

[vdvogt]

Hallo rendegast,
danke fuer Deine Erklaerungen!
Fazit: Vorsicht bei zu viel Bequemlichkeit!!!

Das mit dem Pinning muss ich mir bei Gelegenheit noch mal genauer anschauen.

Am Montag werde ich zuerst mal Deine Hinweise zu unattended-upgrades "einarbeiten".

Viele Gruesse
vdvogt

[johnmatrix]

Ich verwende seit einiger Zeit nicht mehr Unattended Upgrade sondern einen Cronjob aus dem Debian Handbook.
UU machte für mich einige Probleme, da es kein Dist- Upgrade durchführt und externe Quellen immer kompliziert eingetragen werden müssen.

Deshalb habe ich dieses Script verwendet und bin bis jetzt damit sehr zufrieden.

Wie ist eure Meinung dazu?

Code: Alles auswählen

 
export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade 

[vdvogt]

Hallo rendegast,
ich habe mir heute mal apt-cache policy angesehen und u.a. diese Zeilen gefunden:

http://mozilla.debian.net/ wheezy-backports/iceweasel-aurora amd64 Packages
release o=Debian Mozilla Team,a=wheezy-backports,n=wheezy-backports,l=Debian Mozilla Team,c=iceweasel-aurora
origin mozilla.debian.net

http://ftp.debian.org/debian/ wheezy-backports/main amd64 Packages
release v=,o=Debian Backports,a=wheezy-backports,n=wheezy-backports,l=Debian Backports,c=main
origin ftp.debian.org

http://ftp2.de.debian.org/debian/ wheezy/non-free amd64 Packages
release v=7.4,o=Debian,a=stable,n=wheezy,l=Debian,c=non-free
origin ftp2.de.debian.org

Ich dachte bisher, dass "o=" und "origin" das Gleiche seien.
Scheinbar stimmt das aber nicht?

Kannst Du mir bitte den Unterschied erklaeren.
Wofuer stehen "v" und "n"?
Warum steht mal "v=" ohne was hinter dem Gleich und einmal "v=7.4"

Viele Gruesse
vdvogt

[rendegast]

Ich dachte bisher, dass "o=" und "origin" das Gleiche seien.

'man apt_preferences':

A note of caution: the keyword used here is "origin" which can be used to match a hostname. The following record
will assign a high priority to all versions available from the server identified by the hostname
"ftp.de.debian.org"

Package: *
Pin: origin "ftp.de.debian.org"
Pin-Priority: 999

This should not be confused with the Origin of a distribution as specified in a Release file. What follows the
"Origin:" tag in a Release file is not an Internet address but an author or vendor name, such as "Debian" or
"Ximian".

Eine Mahnung zur Vorsicht: Das hier benutzte Schlüsselwort ist »origin«, was zum Finden des Rechnernamens
benutzt werden kann. Der folgende Eintrag wird allen Versionen eine hohe Priorität zuweisen, die auf dem Server
verfügbar sind, der durch den Rechnernamen »ftp.de.debian.org« identifiziert wird.

Package: *
Pin: origin "ftp.de.debian.org"
Pin-Priority: 999

Dies sollte nicht mit der Herkunft einer Distribution verwechselt werden, wie sie in einer Release-Datei
angegeben wurde. Was dem »Origin:«-Kennzeichen in einer Release-Datei folgt, ist keine Internet-Adresse, sondern
ein Autoren- oder Anbietername, wie »Debian« oder »Ximian«.

Also 'o=irgendein_Bezeichner' und 'origin "Server"',
hat wohl jeder dran zu knuspern der sich erstmalig intensiver mit debians Paketsystem beschäftigt.
(zusätzlich zum oben schon genannten "Archive:"<->"Suite:")

Wofuer stehen "v" und "n"?

version und name.

Warum steht mal "v=" ohne was hinter dem Gleich und einmal "v=7.4"

->
http://ftp.debian.org/debian/dists/wheezy/Release "Version: 7.4"
http://ftp.debian.org/debian/dists/whee ... ts/Release "Version:"





Noch zwei etwas heiklere Beispiele für unattended-upgrade

"origin=Google\, Inc.,archive=stable,label=Google";
"origin=Open Build Service home:garloff:storage Debian_7.0,archive=home:garloff:storage,label=Some storage tools (SCSI\, ...) (Debian_7.0)";

Bezeichner-Kommas müssen also quoted sein.
Obwohl der ":" in /usr/bin/unattended-upgrade wohl auch ein split-Zeichen ist,
scheint der zweite Ausdruck auch zu funktionieren (Sollte mal jemand den guten garloff auf die Problematik hinweisen).

[vdvogt]

Hallo rendegast,
vielen Dank fuer deine Ausfuehrungen!
Ich habe mir heute mal man apt_preferences durchgelesen und muss gestehen, dass ich nicht alles verstanden habe.
Das Paketverwaltungssystem von Debian ist doch recht "sophisticated"!

Wenn ich aber Folgendes richtig verstanden habe, dann muss ich folgende drei Zeilen in meine /etc/apt/preferences reinschreiben, wenn ich das Paket boinc-client immer auf dem neuesten Stand haben will UND es zu meiner aktuellen Release passend sein soll:

Package: boinc-client
Pin: version 7.*
Pin-Priority: 989

[ 500 <= P < 990 veranlasst, dass eine Version installiert wird, außer wenn eine Version verfügbar ist, die zum Ziel-Release gehört oder die installierte Version neuer ist]

Kann es vorkommen, dass eine neuere Version eines Paketes zB in testing oder SID enthalten ist, die aber nicht zu meinem aktuellen Release passt und bei einer Installation Probleme verursachen wuerde?

So sieht meine aktuelle /etc/apt/preferences aus:

#APT-Preferences List

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 700

Package: *
Pin: release a=unstable
Pin-Priority: 500

Die drei neuen Zeilen muessten also an den Anfang?

Noch eine Frage zur Sources.list:

Ein stable-backports gibt es nicht?
Nur Wheezy-backports?
Das muesste also bei jedem Releasewechsel manuell geaendert werden.

Viele Gruesse
vdvogt

[rendegast]

In der preferences gilt first-strike,
also die erste treffende preference gilt.

Defaultwert für nicht bewertete Repo ist Priority 500,
nicht explizit aufgeführtes 'a=now' (installierte Pakete) erhält Priority 100.
backports und experimental bekommen über die Release-Optionen
NotAutomatic: yes
ButAutomaticUpgrades: yes
automatisch die Werte 100 resp. 1.

Package: *
Pin: release a=stable
Pin-Priority: 900

Das kann weitere aktivierte Repo (nicht-debian) auch treffen, Bsp.:

Code: Alles auswählen

# apt-cache policy | grep -vi translat | grep a=stable, | sed 's@,c=.*@@' | sort | uniq
     release o=packages.dotdeb.org,a=stable,n=wheezy,l=packages.dotdeb.org
     release o=packages.dotdeb.org,a=stable,n=wheezy-php55,l=packages.dotdeb.org
     release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google

Dieses sind nun "seriöse" Repo (recht saubere Pakete, saubere Abhängigkeiten),
in denen von google finden sich zudem nur ein oder ganz wenige Pakete,
in denen von dotdeb sind es aber schonmal ~50.

Ein stable-backports gibt es nicht?
Nur Wheezy-backports?

Siehe oben den Auszug 'apt-cache policy', und/oder
http://ftp.de.debian.org/debian/dists/w ... ts/Release
http://ftp.de.debian.org/debian/dists/w ... 64/Release
auch
http://ftp.de.debian.org/debian/dists/,
als Repo-Verzeichnis schon, aber halt nicht als release-Wert.
Sowas ist aber möglich:

Code: Alles auswählen

Package: *
Pin: release o=*Backports*, l=*Backports*, a=*-backports
Pin-Priority: 102

[vdvogt]

Hallo rendegast,
danke fuer die Infos!
Ich werde das jetzt mal umsetzten.

Wenn ich noch Fragen haben sollte, melde ich mich wieder.

Gruesse
vdvogt