Zu UCS 3.0 sollten wir das Verfahren zur Veröffentlichung der Security-Updates vereinfachen. Es gibt z.Zt. zwei verschiedene Advisory-Typen: Einmal die Hotfixes, die per Mail angekünfigt werden und dann die zusammengefassten Security-Updates, für die das Advisory in LaTeX geschrieben wird und auch eine eigene UCR-Variable gepflegt wird. Zu UCS 3.0 sollten wir das vereinfachen und effizienter gestalten: - Security-Fixes werden nur noch über den aktuellen Hotfix-Mechanismus veröffentlicht - Die Ankündigung erfolgt weiterhin per Mail, diese Mails sollten auf der Webseite archiviert werden (z.B. durch ein Mailman-artiges Webarchiv o.ä.), so dass keine manuelle Pflege auf der Webseite nötig ist - Die Pflege des LaTeX-Advisories entfällt - Die Pflege von univention-security-update entfällt, die UCR-Variable ist nicht mehr nötig - Die gebündelten Security-Updates werden nicht mehr veröffentlicht, stattdessen werden die jeweils angefallenen Security-Fixes in die jeweiligen Patchlevel-Releases umkopiert. - Die Generierung der TGZ-Archive müsste dann so umgestellt werden, das für jeden Hotfix ein eigenes Archiv erstellt wird, ansonsten ist die Pflege zu komplex und unübersichtlich
In den /etc/issue-Dateien wird die Security Versionsnummer nicht mehr ausgegeben. Auch univention-updater bricht jetzt nicht mehr ab, wenn es die Variable nicht gibt.
Das Verfahren soll wie folgt sein: - Security Updates und Hotfixes sollen vereinheitlicht werden. - Es werden einzelne Updates als Errata veröffentlicht, secX und hotfixes entfallen: http://apt.univention.de/3.0/maintained/errata001/ http://apt.univention.de/3.0/maintained/errata002/ - Die Ankündigung erfolgt per Mail und wird automatisch auf einer Webseite auf forge dargestellt - Wir veröffentlichen nicht nur Security Updates, sondern auch UCS Bugfixes mit diesem Verfahren. Auf der Webseite - Die Updates sollen zukünftig einheitlich per univnetion-upgrade oder per UMC Modul eingespielt werden, das wird in Bug #23453 behandelt. - Das Paket univention-security-update entfällt. Aufgaben für diesen Bug: - Infrastruktur für die Webseite erstellen und das Layout anpassen / absprechen - Erstellen des Tools zur automatischen Umwandlung der Mail in den Webseiten Text - Infrastruktur zum Veröffentlichen der Updates implementieren
Ich würde folgendes umsetzen: Alle Errata für ein UCS-Release werden in einem Scope gebaut, also eines für alle Errata für 3.0, 3.0-1 etc. Das ermöglicht eine saubere Übernahme dieser Binaries in das folgende Point-Release. Dabei werden die DEBs kopiert und nicht neu gebaut. Um auch alte Binaries zu erhalten (also wenn zwei Mal Firefox veröffentlicht wird) könnten diese in ein obsoleted-Verzeichnis verschoben werden. Mit dem aktuellen 2.4-Verfahren tritt das Verhalten aber auch schon auf. Das Announcen erfolgt dann mit announce_ucs_errata -r 3.0-0 -s samba -t advisory.txt Es wird dann die naechste verfügbare errata-ID (z.B 007) ermittelt und unter /var/univention/buildsystem/mirror/ftp/3.0/maintained/errata007 abgelegt. In der mit -t übergebenen Daten stehen die Meta-Daten für das Advisory, also z.B. der Advisory-Text, CVE-ID/UCS-Bug und ob es sich um eine Sec-Errata oder Bugfix-Errata handelt. Dazu wird die Advisory-Übersichts-Seite aktualisiert und eine Unterseite für errata007 erzeugt. Mit dem Announcen wird eine Ankündigungs-Mail direkt an den Testverteiler verschickt (Arvid und ich). Dann erfolgt wie gewohnt die QA des Updates und des Advisorys. Mit einem weiteren Befehl ala publish-errata gehen die Updates dann live: - Sync des Mirrors - Sync der lokalen Advisorys-HTML-Dateien auf den Webserver - Verschicken der Advisory-Mail an den Verteiler (Wg. der Umstellung der Kontakte-Verwaltung auf OpenERP wird für eine Übergangszeit die manuelle Übergabe der Kontakte-CSV nötig sein. Nach Migration der Kontakte auf OpenERP kann dann direkt die Postgres-Datenbank angefragt werden)
(In reply to comment #3) > Ich würde folgendes umsetzen: > > Alle Errata für ein UCS-Release werden in einem Scope gebaut, also > eines für alle Errata für 3.0, 3.0-1 etc. Das ermöglicht eine saubere > Übernahme dieser Binaries in das folgende Point-Release. Dabei werden > die DEBs kopiert und nicht neu gebaut. > > Um auch alte Binaries zu erhalten (also wenn zwei Mal Firefox > veröffentlicht wird) könnten diese in ein obsoleted-Verzeichnis > verschoben werden. Mit dem aktuellen 2.4-Verfahren tritt das Verhalten > aber auch schon auf. Wie würden pre- und postup.sh Skripte abgelegt werden? > Das Announcen erfolgt dann mit > > announce_ucs_errata -r 3.0-0 -s samba -t advisory.txt Potentiell könnten dann Paketleichen entstehen. Können wir das irgendwie verhindern? > Es wird dann die naechste verfügbare errata-ID (z.B 007) ermittelt und unter > /var/univention/buildsystem/mirror/ftp/3.0/maintained/errata007 > abgelegt. In der mit -t übergebenen Daten stehen die Meta-Daten für > das Advisory, also z.B. der Advisory-Text, CVE-ID/UCS-Bug und ob es > sich um eine Sec-Errata oder Bugfix-Errata handelt. > > Dazu wird die Advisory-Übersichts-Seite aktualisiert und eine > Unterseite für errata007 erzeugt. > > Mit dem Announcen wird eine Ankündigungs-Mail direkt an den > Testverteiler verschickt (Arvid und ich). Das müssten mehr Leute sein, da wir auch nicht Security-Updates darüber veröffentlichen. tech-intern? > Dann erfolgt wie gewohnt die QA des Updates und des Advisorys. > > Mit einem weiteren Befehl ala publish-errata gehen die Updates dann live: > - Sync des Mirrors > - Sync der lokalen Advisorys-HTML-Dateien auf den Webserver > - Verschicken der Advisory-Mail an den Verteiler > > (Wg. der Umstellung der Kontakte-Verwaltung auf OpenERP wird für eine > Übergangszeit die manuelle Übergabe der Kontakte-CSV nötig > sein. Nach Migration der Kontakte auf OpenERP kann dann direkt die > Postgres-Datenbank angefragt werden) Das müsste entsprechend dokumentiert werden. Der aktuelle Absender ist <security-announce@univention.de>. Soll das so bleiben?
> Der aktuelle Absender ist <security-announce@univention.de>. Soll das so > bleiben? Hier soll announce_noreply@univention.de verwendet werden.
Mit Bug #23453 wurde univention-security-update nach univention-errata-update umbenannt. Das Tool liegt unter /usr/share/univention-updater. Für das Einspielen sollte univention-upgrade verwedent werden, oder das UMC Modul. Der Pfad muss errata1, errata2 usw. sein, nicht 001, 002.
Created attachment 3757 [details] YAML-Beispieldatei für Security-Update
Created attachment 3758 [details] YAML-Beispieldatei für Bugfix-Update
Eine erste Version ist soweit umgesetzt. Ich teste das am Montag nach dem internen Update auf 3.0 und schliesse dann den Bug. Den Workflow für ein Erratum-Update ist in einer initialen Version im internen Wiki beschrieben: https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates
(In reply to comment #9) > Eine erste Version ist soweit umgesetzt. Ich teste das am Montag nach dem > internen Update auf 3.0 und schliesse dann den Bug. > > Den Workflow für ein Erratum-Update ist in einer initialen Version im internen > Wiki beschrieben: > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates Für die Errata-Updates werden jetzt auch Release-Dateien erzeugt und signiert. Noch nicht in Betrieb genommen, omar ist noch auf UCS 2.4.
(In reply to comment #10) > (In reply to comment #9) > > Eine erste Version ist soweit umgesetzt. Ich teste das am Montag nach dem > > internen Update auf 3.0 und schliesse dann den Bug. > > > > Den Workflow für ein Erratum-Update ist in einer initialen Version im internen > > Wiki beschrieben: > > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates > > Für die Errata-Updates werden jetzt auch Release-Dateien erzeugt und signiert. > > Noch nicht in Betrieb genommen, omar ist noch auf UCS 2.4. Es waren noch ein paar Anpassungen für UCS 3.0 nötig. Die entsprechenden Keys wurden auf dimma (das schon auf 3.0 aktualisiert wurde) kopiert und die Anleitung https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates Ich habe zwei Dummy-Errata auf den Test-Mirror announct, einmal für elinks und einmal für cron. Die YAML-Sourcen finden sich in doku/branches/ucs-3.0/release/errata Changelog nicht nötig.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Eine erste Version ist soweit umgesetzt. Ich teste das am Montag nach dem > > > internen Update auf 3.0 und schliesse dann den Bug. > > > > > > Den Workflow für ein Erratum-Update ist in einer initialen Version im internen > > > Wiki beschrieben: > > > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates > > > > Für die Errata-Updates werden jetzt auch Release-Dateien erzeugt und signiert. > > > > Noch nicht in Betrieb genommen, omar ist noch auf UCS 2.4. > > Es waren noch ein paar Anpassungen für UCS 3.0 nötig. Die entsprechenden Keys > wurden auf dimma (das schon auf 3.0 aktualisiert wurde) kopiert und die > Anleitung > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates Das ist gut. Was nochmal klar in der Anleitung stehen sollte: Die Errata-Updates werden pro Patchlevel Release gebaut. Es sollen immer alle Errata Updates in das nächste Patchlevel übernommen werden. Ich fände es besser, wenn die Scopes immer in mit der gleichen Versionsnummer angelegt werden, also errata3.0-0, errata3.0-1, errata3.1-0. Dann ist es einheitlich und wir müssen nicht immer Sonderbehandlungen einbauen. https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates#Announce_des_Erratum-Updates -> Da gibt es im Moment keine Möglichkeit auf den Testmirror zu announcen? Brauchen wir das nicht? https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates#Generierung_der_Advisory-Testmail -> das sollten wir im Moment immer an tech-intern schicken. Auf der Ablauf Seite sollte nochmal etwas deutlicher beschrieben werden, wie es funktioniert. Wichtig ist, dass man in einem normalen Scope baut, aber beim Announce nur ein Paket daraus veröffentlicht wird. > Ich habe zwei Dummy-Errata auf den Test-Mirror announct, einmal für elinks und > einmal für cron. Die YAML-Sourcen finden sich in > doku/branches/ucs-3.0/release/errata Die Seite ist vom Aussehen noch nicht ideal. Gibt es dazu noch einen weiteren Bug, oder wird das an diesem Bug bearbeitet? Funktionale Tests stehen noch aus.
> Das ist gut. Was nochmal klar in der Anleitung stehen sollte: > > Die Errata-Updates werden pro Patchlevel Release gebaut. Es sollen immer alle > Errata Updates in das nächste Patchlevel übernommen werden. Das wurde in die Anleitung aufgenommen. > Ich fände es besser, wenn die Scopes immer in mit der gleichen Versionsnummer > angelegt werden, also errata3.0-0, errata3.0-1, errata3.1-0. Dann ist es > einheitlich und wir müssen nicht immer Sonderbehandlungen einbauen. Können wir so machen. Der aktuelle errata3.0-Scope ist ohnehin mehr für die Tests bis zum Release, den können wir dann stilllegen. > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates#Announce_des_Erratum-Updates > -> Da gibt es im Moment keine Möglichkeit auf den Testmirror zu announcen? > Brauchen wir das nicht? Für die Hotfixes haben wir das nicht verwendet. Der aktuelle Workflow testet die finale Installation au der Sicht wie es auch der Kunde sieht, ich habe das unter "QA der Installation von apt.univention.de" noch einmal separat aufgeführt. > https://hutten.knut.univention.de/mediawiki/index.php/Errata-Updates#Generierung_der_Advisory-Testmail > -> das sollten wir im Moment immer an tech-intern schicken. Habe ich angepasst. > Auf der Ablauf Seite sollte nochmal etwas deutlicher beschrieben werden, wie es > funktioniert. Wichtig ist, dass man in einem normalen Scope baut, aber beim > Announce nur ein Paket daraus veröffentlicht wird. Habe ich in die Einleitung aufgenommen. > > Ich habe zwei Dummy-Errata auf den Test-Mirror announct, einmal für elinks und > > einmal für cron. Die YAML-Sourcen finden sich in > > doku/branches/ucs-3.0/release/errata > > Die Seite ist vom Aussehen noch nicht ideal. Gibt es dazu noch einen weiteren > Bug, oder wird das an diesem Bug bearbeitet? Ich passe das noch auf eine Zwei-Zeilen-Tabelle an. Außerdem habe ich Bug 24931 zur Aktualisierung der CSS-Datei angelegt.
(In reply to comment #13) > > Die Seite ist vom Aussehen noch nicht ideal. Gibt es dazu noch einen weiteren > > Bug, oder wird das an diesem Bug bearbeitet? > > Ich passe das noch auf eine Zwei-Zeilen-Tabelle an. Wurde umgesetzt, das aktuelle Layout ist hier zu sehen: http://univention-repository.knut.univention.de/download/errata/errata4.html
Das sec-mailing Script, das von send-errata-mails.py aufgerufen wird, verwendet noch security-announce@univention.de als Absender. Ich habe bei der QA die Verzeichnisse buildsystem2/errata/staging/ und buildsystem2/errata/mail/ und buildsystem2/errata/mail/sent/ für die Gruppe Tech schreibbar gemacht, damit Mitglieder der Gruppe * aktualisierte Adresslisten unter buildsystem2/errata/mail/ ablegen können * send-errata-mails.py verschickte Mails nach 'sent' verschieben kann, wenn das Script als normaler Benutzer aufgerufen wird. Das Ownership der Advisories bleibt dabei unverändert (d.h. nicht schreibbar für normale Benutzer). Verified: * Die wiki-Anleitung gibt das Verfahren korrekt wieder * announce_errata.py kopiert die deb-Pakete korrekt nach mirror/ftp/3.0/maintained bzw. 3.0/unmaintained. * announce_errata.py generiert korrekt signierte Mails und verschickt sie an die Adressen in test.csv, insbesondere an tech-intern * send-errata-mails.py verschickt die Announcements an die Adressen in list.csv und und verschiebt sie nach 'errata/mail/sent' * preup.sh/postup.sh kommen manuell nach mirror/ftp/2.4/maintained/errata5/all/ * Die overview Webseite wird korrekt generiert. * status/next-3.0.txt wird korrekt aktualisiert und status/overview-3.0.txt führt alle Durchläufe von announce_errata.py auf. * Die HTML-Advisories sind sowohl unter http://apt.univention.de/download/errata/ als auch unter http://errata.univention.de/ erreichbar.
(In reply to comment #15) > Das sec-mailing Script, das von send-errata-mails.py aufgerufen wird, verwendet > noch security-announce@univention.de als Absender. Das wurde angepasst.
Es werden jetzt auch Tarballs für ein Offline-Update generiert.
Verified: * Auch Updates per tar.gz über ein lokales Repository funktionieren. * Changelog OK.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"