AutomaticUpdates

Differences between revisions 3 and 6 (spanning 3 versions)
Revision 3 as of 2005-10-26 16:51:15
Size: 867
Editor: 169
Comment:
Revision 6 as of 2005-11-02 16:40:13
Size: 2985
Editor: 209
Comment: cleanups
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * Created: [[Date(2005-10-06T19:18:35Z)]] by JaneWeideman
 * Priority: NeedsPriority
 * People: NeedsLead, NeedsSecond
 * Contributors: JaneWeideman
 * Interested: JorgeBernal
 * Status: UbzSpecification, BrainDump (then DraftSpecification then EditedSpecification then ApprovedSpecification), DistroSpecification
 * Branch: UbuntuTrack
 * Malone bug:
 * Packages affected:
 * Depends:
 * Dependents:
 [[FullSearch()]]
 * BoF sessions: none yet
 * '''Launchpad entry:''' https://launchpad.net/distros/ubuntu/+spec/unattended-package-upgrades
 * '''Created:''' [[Date(2005-11-02T19:41:30Z)]] by MichaelVogt
 * '''Contributors:''' DanielBurrows, GustavoNiemeyer, ReinardTartler
 * '''Packages affected:''' `apt`, `python-apt`
Line 18: Line 9:
Automatic Updates - automatic/silent installation of (security) updates, possible even when current user has no sudo privileges Automatic Updates - automatic installation of (security) updates, possible even
when current user has no sudo privileges
Line 21: Line 13:

When ubuntu is used by a user without sudo privileges, he cannot upgrade it
with security updates. This can mean a machine will be vulnerable to security
risks for a prolonged period of time. Also some people just don't care about
updates and other technical stuff. They just don't want to be bothered and
have ubuntu to keep itself updated and secure.
Line 28: Line 26:
The problem with unattended upgrades are packages that ask questions in
postinst. Fortunately there are few of them nowdays, but we still have
kernel, libc, etc. Another problem is that there may be conffile questions during the upgrade. [[BR]]

We may run dpkg with --force-conf-old. A problem with this is that:

 * a security upgrade may be using a new version for a (default) conffile
 * a upgrade may need a new conffile format

The packages must be prepared for it (don't ask questions, don't prompt, no new conffile).
We will limit ourself to security upgrades for the installed distro
(origin: ubuntu-security), if anything is installed/upgraded that does not comes from ubuntu-security we will ignore it.

Line 30: Line 42:
Write it in python-apt, check what's upgradable and comes from security;
verify if it does not a) break/remove anything b) installs
stuff outside security; upgrade it. It will be tied into the apt cron-job
we have already.

Line 31: Line 49:

{{{#!python
import apt
cache = apt.Cache()
pkgs = []
for pkg in cache:
 if pkg.isUpgradable() and pkg.candidateOrigin == "breezy-security":
  pkg.markUpgradable()
  if we_shouldnt_continue():
   #cache = apt.Cache()
   for pkg in cache:
    pkg.markKeep()
   for pkg2 in pkgs:
    pkg2.markUpgradable()
  else:
   pkgs.append(pkg)
Line 36: Line 70:
 * update-notifier would need a way to figure if the pkg-database is locked or
 not. Write an informational file next to the dpkg lock when acquiring it?
 Stale locks may be a problem here. Frontends should catch SIGINT and cancel their locks, the boot process should remove any stale locks.

 * flock has advisory locks, which can be used on directory you cannot write in.
 (DoS? -- one option would be to use an advisory lock to inform user processes, but not to make that the locking protocol between APT frontends; i.e., it should be entirely advisory for frontends; only the main fcntl lock should be mandatory)

Summary

Automatic Updates - automatic installation of (security) updates, possible even when current user has no sudo privileges

Rationale

When ubuntu is used by a user without sudo privileges, he cannot upgrade it with security updates. This can mean a machine will be vulnerable to security risks for a prolonged period of time. Also some people just don't care about updates and other technical stuff. They just don't want to be bothered and have ubuntu to keep itself updated and secure.

Use cases

Scope

Design

The problem with unattended upgrades are packages that ask questions in postinst. Fortunately there are few of them nowdays, but we still have kernel, libc, etc. Another problem is that there may be conffile questions during the upgrade. BR

We may run dpkg with --force-conf-old. A problem with this is that:

  • a security upgrade may be using a new version for a (default) conffile
  • a upgrade may need a new conffile format

The packages must be prepared for it (don't ask questions, don't prompt, no new conffile). We will limit ourself to security upgrades for the installed distro (origin: ubuntu-security), if anything is installed/upgraded that does not comes from ubuntu-security we will ignore it.

Implementation

Write it in python-apt, check what's upgradable and comes from security; verify if it does not a) break/remove anything b) installs stuff outside security; upgrade it. It will be tied into the apt cron-job we have already.

Code

AutomaticUpdates (last edited 2008-08-06 16:27:19 by localhost)