UbuntuWiki:UpdateServer

{{#ifexist: :UbuntuWiki:UpdateServer/zh | | {{#ifexist: UbuntuWiki:UpdateServer/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UpdateServer|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UpdateServer|1|-1|}} | zh | | }}

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-update-server
• Packages affected:

Summary

The Ubuntu Update Server (UUS) is a web based management tool that allows system admnistrators to deploy security updates and install packages to every machine in his control. The tool provides the admin with a method of checking security updates, being able to approve or decline updates, and select when those updates are deployed to his/her machines. This closely related to NetworkWideUpdates (they could probably be combined), the big difference is that this would be tied into an organization's EasyLDAPServer infrastructure, alllowing them to deploy updates by Organization Units, etc. Competing services would include Microsoft Windows Update Server (WSUS) and the Red Hat Network (RHN).

Rationale

Administrators need to be able to test bugfixes, approve them, and roll them out on their own terms. This tool would allow them to hold certain packages before deployment while they are being tested, and more importantly, provides a centralized location for managing package management for their entire network. If the security person asks if the organization is vulnerable, the admin should have one place where he/she can look up the CVE # (or whatever), and know the status of the managed clients.

Use cases

Jorge is a Linux admin for 100 Ubuntu machines, he wants to be able to find out which machines are vulnerable to the new hole in foo, but has no way of finding out short of sshing to each of them.

Andrew wants to ensure that all his Ubuntu machines are being patched with the security patches, but he wants to be able to test the -updates packages on his own personal workstation before he approves them to roll out over his entire network. He would like to have a "testing queue" someplace where he can assign a few test machines that will get the updates, but he wants to be the final authority for pushing them out.

Jim has a custom .deb of an internal application that he's been working on, and now he has to deploy that over a few hundred servers.

Milosz owns his own multinational company and wants to use his network assets as effeciently as possible. He wants to have one canonical update server, where his crack team of admins test and approve patches, but he wants slave servers in each country to handle the load, they should talk to the central server and do the right thing.

Gordon works for a credit card firm and is in the middle of a security audit by Visa. His custom "apt-get update && apt-get-y upgrade" perl script makes the auditors laugh. Luckily his jr. admin deployed UUS, and provides detailed logs of every security patch deployed to every server over the last 18 months, sorted by severity. Shiny graphs and color impress the auditors, and they go bug the Windows guys instead.

Design

One potential design would be to put all the package information into an LDAP database. This would include what packages are available, where they are installed and history of installations. This would mean that apt (or a helper app) would need to sync with the LDAP server and install/remove/update any needed packages. There would also need to be a schema created for the LDAP server, to understand apt package managment.

---