After lenny to squeeze upgrade, apt-get offers to break virtualmin

Submitted by austinfwd on Thu, 06/28/2012 - 14:45

After upgrading from debiain 5 to 6 (32-bit), I was installing bonnie++ to do some i/o benchmarking. In the process I got prompted with this:

webhost3:/tmp# apt-get install bonnie++
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  apache2-suexec-custom libwnck-common xkb-data vbetool powermgmt-base hal kbd console-data pm-utils thunar-data xli console-common exo-utils radeontool
  hal-info miscfiles libjpeg-progs xfdesktop4-data eject libnss3-1d
Use 'apt-get autoremove' to remove them.
The following NEW packages will be installed:
  bonnie++
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 70.6 kB of archives.
After this operation, 221 kB of additional disk space will be used.
Get:1 http://ftp.debian.org/debian/ squeeze/main bonnie++ i386 1.96 [70.6 kB]
Fetched 70.6 kB in 1s (52.6 kB/s)
Selecting previously deselected package bonnie++.
(Reading database ... 117937 files and directories currently installed.)
Unpacking bonnie++ (from .../bonnie++_1.96_i386.deb) ...
Processing triggers for man-db ...
Setting up bonnie++ (1.96) ...
webhost3:/tmp# apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  apache2-suexec-custom console-common console-data eject exo-utils hal hal-info kbd libjpeg-progs libnss3-1d libwnck-common miscfiles pm-utils
  powermgmt-base radeontool thunar-data vbetool xfdesktop4-data xkb-data xli
0 upgraded, 0 newly installed, 20 to remove and 0 not upgraded.
After this operation, 45.6 MB disk space will be freed.
Do you want to continue [Y/n]?

Unfortunately, I didn't read closely or research what the unneeded packages were. I just let it uninstall them. I spent the next 2-3 hours troubleshooting fcgi/suexec issues. Eventually found out that I needed your specific apache2-suexec-custom because you hard code it to run within /home. One forum suggested I can fix most virtualmin components by running: apt-get install

Indeed this did put your packages back in. But is also reset some of my configs. My dovecot IMAP folder index file location setting got changed from ~/Maildir (default) to /var/lib/dovecot-virtualmin/..... Then users are calling me because their IMAP folders are no longer appearing in their email client. I fixed that by changing the settings back to ~/Maildir.

It also introduced some other issues that I had to troubleshoot that night with config files. Not fun. Overall probably took 2-3 hours & kept me up until 1-2am. :-)

So if you know (or can figure out) why apt-get would think your packages are no longer necessary & would offer/suggest to let it remove them (in lieu of the debian repo's versions), hopefully you can fix it so that you can save other users some heartache.

Thanks,

Doug

Status: 
Active

Comments

Submitted by JamieCameron on Fri, 06/29/2012 - 00:38

Virtualmin just installs apache2-suexec-custom as part of the install process - but it isn't a dependency of any other package, nor do I think it really needs to be. That said, I am not sure exactly how apt-get decides which packages are safe to remove..

In a case like this, you would be able to fix the problem by running apt-get install apache2-suexec-custom

Submitted by austinfwd on Tue, 07/03/2012 - 13:56

Thanks for the reply Jamie. I do think that I figured out that all I needed was to replace the stock apache2-suexec, with yours. Unfortunately I figured that out too late. I hope you don't have other users run into this problem. :-)

I would still consider this a bug. Obviously it was caused by apt-get and not virtualmin itself. But it broke virtualmin. In my opinion running apt-get on virtualmin servers is a normal process that has to be done for security updates, bug fixes, etc. Normally virtualmin handles this gracefully. But in this case it broke the machine. I would suggest that you look into whether you can prevent apt-get from being able to do this in the future.

With that said, I only have 1 other debian 5 box running virtualmin that I need to upgrade to 6. I'm sure I can take care of this issue myself if it becomes necessary in the future. So I don't think I'll be affected by it in the future. However, I think it it should be fixed if you are concerned about making this a smooth experience for us sysadmins. But hopefully most everyone is already upgraded by now since Lenny is EOL.

I'm not closing this ticket, but I don't mind if you do if you want.

Thanks again,

Doug