MJ Ray wrote:

I don't know of any web interfaces and it may be fairly easy, but not as simple as you might think. Some packages ask questions. I think dpkg-www may handle those, but I'm not sure. Alternatively, I guess you can tell debconf to never ask anything and hope for the best.

I think that installing recommended updates blindly may be better than not installing them. The "middle ground" of expecting an uninformed user to make decisions is not really an option (or not a better one, anyway!).

At the moment, I have a specific job which requires data to be logged to a database from an NT4 machine, against which reports will be run. I plan to install a Linux server with MySQL (data will be logged to it via ODBC) and use Apache/PHP to create the reports and make them available. The server will be hosted by the end user mostly for internal use, but with the web interface open to external users too.

One option would be to use an XP server instead (for many obvious reasons I want to avoid this!). However at least the client would be able to install updates (to the O/S, although not to the web server, database server or PHP). They may of-course download an update which breaks the server (unlikely but possible).

So, given that I want to use Linux, I want a way to manage updates. I could use cron-apt or update-apt, but I'd prefer to at least make the updates optional so they can be installed manually at quiet times in case something goes wrong. So all I was thinking of was something which listed the updates and offered the option to go ahead with them.

There are various systems capable of remote control, including puppet and cfengine, if you want to initiate updates yourself.

Unless I am missing something from a quick scan of their websites, these are both aimed and a sysadmin managing their own updates rather than as a way of managing vendor distributed updates?

I guess seeing as you wrote "servers" that the desktop frontends from the likes of ubuntu aren't an option. I'm not sure of the current state of webmin, but it might work:

I thought about webmin - I'm sure it would work, but it would be overkill and give too many options for "playing" :-( Yes I am talking servers without a GUI.

Of-course if I can sell support then I'll manage this via SSH but I can think of several other similar servers where this functionality would be beneficial. That's why I'm surprised it's not already commonplace, but a Google search including phrases like "apt-get" and "web interface" threw up too many false hits to be useful.

OK, I've started playing with the idea of writing a web front-end to apt-get and got stuck at the first hurdle...

Ideally I want to mimic the action of update-manager, ie get a list of updates, display the list (ideally with some details of each update), provide checkboxes to select required updates, and provide a mechanism to install the selected updates.

How do I generate a machine friendly list of available updates? Reading the apt-get docs, it suggests that apt-get -u update .. should do this, but it doesn't. (-u, aka --show-upgraded, should list upgraded packages). Various other stabs in the dark have also been fruitless.

Obviously I'm not tied to using apt-get; if aptitude or some other package manager gets me closer that's fine.

Jonathan McDowell wrote:

apt-get --print-uris -y -qq upgrade

Great! Thanks.

I can get the change notes via: aptitude changelog <pkgname> .. for each package, and then presumably just need to "apt-get install" the selected packages. So that's the theory covered...

NB: Since this is primarily for use on internal servers (ie not Internet facing) I plan on using the sudoers file to grant the web user (www-data) passwordless access to apt-get/aptitude. Can anyone give me reasons why that is a bad idea and/or suggest how else to do this?

Wayne Stallwood wrote:

If you are giving access to "ordinary" people to manage the updates why not just instead automate it so that the updates are applied on a fixed schedule without user intervention ?

Giving them some control is still advantageous. It means that they can run updates during other periods of downtime, or they can ring me and ask "is it safe to install xyz?".

The default option is to leave it that no updates get done at all, and in many ways "if it ain't broke..." is a good motto for these systems. But security updates are better installed than not.

Either way you have to deal with updates to say the kernel that won't become effective until after the next boot and either way you don't really have control of when the updates will be applied. In theory anything that may require reconfiguration will be held back unless you specify a dist-update rather than a regular one.

In theory I can enhance the web installer to handle a lot of this, although at this stage I don't really plan to. What I do plant to do is enable it on a server of my own and play with it over time to see if it proves to be a good idea.

You could even script it up to email an update report so in the event that the updating does break something you at least know it was that and not some other problem.

In general, it shouldn't be assumed that I will have access to the server once it leaves me. It may well be that this is only used (if at all) so that I have a way of talking someone through installing necessary updates over the phone. Therefore, emailed reports might be good (so I can initiate that conversation) but the end user will still need a way of installing updates, bearing in mind that the only access they'll have to the server is via a web server.

All that said, if properly locked down I might prefer to have this for some other servers I administer too. "apt-get upgrade" is fine if you trust all the updates it offers, but it is a little lacking in information and not a job I'd be prepared to delegate.

On top of all that, it just feels like a nice project to play with :-)

MJ Ray wrote:

At least this bit is already done: install apt-listchanges

Thanks, I'll take a look.

The --apt option seems helpful but I can't work out how to use it; I believe it takes the output from apt-get and uses that to generates the list of changes, but I can't work out what parameters to pass to apt-get to make this work and I can't find any examples.

Watching with interest,

Don't hold your breath! But I'll keep you informed.

MJ Ray wrote:

Oh, I thought I installed apt-listchanges, configured it (dpkg-reconfigure apt-listchanges # if you already configured it or have your debconf preferences set to auto-configure things) and now it runs and emails whenever apt installs things, automatically.

I think you're getting apt-listchanges mixe dup with something else (which I've come across but not used, and can't remember what it's called).

According to man apt-listchanges: apt-listchanges — Show new changelog entries from Debian package archives

There was no configuration on installation. However it does sound a useful component part of my "project", if I can work out how to use it :-)

we tend to install once and upgrade forever... one of the beauties of debian.

Yes, lots of small steps is better than the big major (and troublesome) upgrade steps of a certain alternative.

Mind you, I'm not sure how much I'm looking forward to upgrading my Ubuntu 6.06LTS installs to Ubuntu 8.04LTS. That's a pretty big step (although not as big as the XP->Vista 6 year jump). Maybe I'll wait until around June for that one...

MJ Ray wrote:

Also on man apt-listchanges:

--email-address=address In addition to displaying it, mail a copy of the changelog data to the specified address. To only mail changelog entries, use this option with the special frontend 'mail'.

OK, you got me: I didn't keep reading :-)

There is another updates to email package I looked at previously, so I jumped to conclusions...

...

There was no configuration on installation. [...]

I speculated that was due to running with a too-high debconf priority option (which would be fine if it's going to be automated most of the time) and dpkg-reconfigure apt-listchanges may reveal the mail option.

I (wrongly, it turns out) assumed that the debconf priority would be set lower than it was.

dpkg-reconfigure apt-listchanges does indeed give me some options.

Hope that helps,

It does, sorry for being thick/lazy first time around.

Wayne Stallwood wrote:

I wouldn't grow too much grey hair over it..rumour has it that Ubuntu are working very hard to make sure the upgrade between LTS releases is as uneventful as possible.

Makes me wonder whether they'll hit 8.04 or whether it'll slip to 8.06 or similar. There must be *much* more work involved in testing the migration from 6.06, not least because most live systems running 6.06 are doing so for stability and are unlikely to join beta programmes.

It may be that they're not trying too hard to make many changes against 7.10, but that just means 8.04 would be out of date before it started and even harder to migrate to the next LTS release (10.04?).

On Fri, 2008-01-18 at 11:44 +0000, James Freer wrote:

...

The question i would raise is "how much" testing do they do - i'd say not enough. They seem to put themselves under a lot of pressure to provide a new version every 6 months - why not just each year and thoroughly test. From what i have understood the upgrade is for security only. But then as i've noticed with 6.04 Firefox wasn't upgraded.

To be honest most migration problems will be relating to either out of package meddling (strange configs, hand installed software conflicting with registered packages, packages from third party resources etc) or specific to some particular hardware (in itself hard to test against due to the diversity of the x86 platform) Firefox in 6.06 was upgraded from 5.10 I am sure.

1 yearly upgrades would mean that people would spend a lot of time running out of date packages due to ubuntu's policy of not incrementing software versions generally for ongoing updates to an existing installation. This is I feel important as it provides a degree of predictability in that if you say you are on Ubuntu 6.06 I can reasonably safely make the assumption of kernel version x and gnome version y etc. The LTS versions are an alternative of 6 monthly updates at the cost of running older software..you takes your choice.

Also...and this IMO is key.

If you update yearly then really the software versions you are going to want to include aren't going to be even released until the last half of the existing Ubuntu versions lifetime..so what do you do for the first 6 months given that some of the software versions you plan to include don't even exist ? You can't test properly unless you are running the shipping versions of the included packages.

in answer you your individual points

a] not something I have ever seen..sorry. Sounds like the Bios on both machines was reporting 2 floppies as I cannot understand otherwise how this would happen, did they have zip drives or something else that may have been miss identified ?

b] 6.06 surely ? In what way did the update get confused ? tbh a general problem here would be all over the net considering the number of people with machines still on LTS (me included)

c] There always are problems on the forums with a new version I can't remember if 7.04 was any worse or better than previous or latter versions, I ran it for 6 months+ so it couldn't have been all bad, in fact I remember updating to 7.04 a little bit earlier before official release than I usually do..again hardware diversity and people only posting when there is a problem and not when it works just fine distort results. A place used by and large as a support forum isn't a great place to gauge software quality because how do you know how many people aren't having problems ?

d] Never heard of this or experienced any synaptic problems with any of the 5 or 6 7.10 systems I have used..again it would be interesting to see linkage or specifics.

e] This I want to see..a ps2 keyboard that provides a USB interface ? Sounds hardly standard to me in fact I am not even sure how this would work. Have you submitted a bug or asked for help in the forums as if this keyboard is reasonably common I would expect a lot of interest.

It sounds like I am defending Ubuntu rather aggressively here..it is not my intention to suggest that Ubuntu is the best option always. If another distro works out better for you or you prefer a 1 year release schedule then the beauty of linux is that you are free to try it. Maybe Debian's release strategy would be a better fit for you as you can make a choice as to how "bleeding edge" you want your system and then have rolling upgrades rather than a fixed "new distro" cycle.

Kind Regards Wayne