Risk of disaster if virtualmin-base installed after upgrading Ubuntu 10.04.4 to 12.04.1

12 posts / 0 new
Last post
#1 Fri, 08/31/2012 - 22:56
fade2gray

Risk of disaster if virtualmin-base installed after upgrading Ubuntu 10.04.4 to 12.04.1

Virtualmin gpl

After following this guide, https://www.virtualmin.com/documentation/system/os/ubuntu-lucid-to-precise, to upgrade Ubuntu server 10.04.4 LTS to 12.04.1 LTS, Virtualmin Package Updates is offering the following packages - firefox-locale-en, libgc1c2 and virtualmin-base. A simulated install of virtualmin-base (sudo apt-get -s install virtualmin-base) produces -

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
 pwgen libnet-daemon-perl postgresql-8.4 bind9 postgresql-9.1 proftpd-basic
 libnet-ip-perl db4.8-util libnet-dns-perl re2c clamav mysql-server bind9utils
 libnet-xwhois-perl php5 awstats libdbi-perl clamav-base subversion
 mysql-server-core-5.5 libclamav6 apache2 libsvn1 spamc libapache2-mod-fcgid mailman
 scponly libpg-perl mysql-client-core-5.5 clamav-docs postgresql-common
 libdbd-mysql-perl libneon27-gnutls libapache2-svn postgresql postgresql-client-8.4
 postgresql-client-9.1 liberror-perl webalizer libplrpc-perl webmin-virtualmin-dav
 libdbd-pg-perl clamav-freshclam postgresql-client-common libpq5 libtommath0
 libnetaddr-ip-perl libmail-spf-perl clamav-daemon libsys-hostname-long-perl
 mysql-server-5.5 libdigest-hmac-perl webmin-virtualmin-svn spamassassin
 clamav-testfiles mysql-client-5.5
Use 'apt-get autoremove' to remove them.
The following packages will be upgraded:
 virtualmin-base
1 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
Inst virtualmin-base [1.0-29] (1.0-32ubuntu Virtualmin for Ubuntu Precise Pangolin:stable [all])
Conf virtualmin-base (1.0-32ubuntu Virtualmin for Ubuntu Precise Pangolin:stable [all])

You can image what will happen if an autoremove is performed.

Mon, 09/03/2012 - 10:52
fade2gray

OK - perhaps I should actually ask a question.

After upgrading my server, from Ubuntu 10.04.4 LTS to 12.04.1, I am being offered an upgrade to vertualmin-base (from 1.0-29 to 1.032).

If I upgrade virtualmin-base, it is suggested I autoremove the packages mentioned above.

Why am I being offered the virtualmin-base if the suggested autoremoval of packages is going to break things?

Should I report this as a Virtualmin issue?

Mon, 09/03/2012 - 16:10
andreychek

Howdy,

Well, you can do the upgrade, just don't run "apt-get auto-remove" :-)

I believe the dependencies of virtualmin-base are different in the newer Ubuntu version, and that may be causing what you're seeing.

Also, there's some thoughts on disabling the auto-remove here:

http://www.linuxquestions.org/questions/debian-26/how-do-i-get-rid-of-au...

Tue, 09/04/2012 - 15:11
Joe
Joe's picture

This is a known issue, but the docs don't cover the necessary step to avoid it. We'll need to get that fixed.

The issue is that when I original built the Debian/Ubuntu version of the install, I didn't realize that apt-get had this (really scary) feature. auto-remove gives me nightmares, but it's a reality we have to live with. So, I changed the install.sh to explicitly request all of the dependencies be installed, and vrtualmin-base no longer depends on anything (except some of our Virtualmin packages). This solves the problem for future installs, but makes an additional step for those upgrading, if they have auto-remove enabled (which is, frighteningly, the default).

So, the solution is to explicitly install all of those dependencies using apt-get before upgrading the virtualmin-base package, so that the packages get a flag that says you wanted those packages explicitly, rather than installing them to resolve dependencies.

I'll ask Eric to try this out and make sure I'm remembering correctly, and to get the docs updated for this upgrade. (The Debian 5 to 6 upgrade docs also ought to have this step, but I don't recall if they do.)

--

Check out the forum guidelines!

Thu, 09/06/2012 - 13:10
andreychek

Okay, that can all be corrected by running this command... this will set all these packages as "manually installed", which will prevent them from showing up in the "autoremove" list:

apt-get install bind9 spamassassin spamc procmail libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd webmin usermin webmin-virtual-server libcrypt-ssleay-perl webmin-virtual-server-theme webmin-virtualmin-dav webmin-virtualmin-svn webmin-virtualmin-awstats webmin-virtualmin-mailman webmin-virtualmin-htpasswd clamav-base clamav-daemon clamav clamav-data clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin usermin-virtual-server-theme procmail-wrapper php-pear php5 php5-cgi webmin-security-updates libgd2-xpm

Fri, 09/07/2012 - 18:55
fade2gray

Hi Eric / Joe,

After applying Eric's command, installing virtualmin-base still suggests removing postgresql-8.4 and postgresql-client-8.4. But I did see a notification during upgrade that postgresql 8.4 was obsolete and should be removed. So should those to packages be added to the list and then purged afterwards?

Fri, 09/07/2012 - 22:04
andreychek

Hmm, what does this command show:

dpkg -l postgresql*

Sat, 09/08/2012 - 02:12
fade2gray

dpkg -l postgresql* (before Ubuntu upgrade).

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version          Description
+++-================-================-================================================
ii  postgresql       8.4.13-0ubuntu10 object-relational SQL database (supported versio
un  postgresql-7.4   <none>           (no description available)
un  postgresql-8.0   <none>           (no description available)
ii  postgresql-8.4   8.4.13-0ubuntu10 object-relational SQL database, version 8.4 serv
un  postgresql-clien <none>           (no description available)
ii  postgresql-clien 8.4.13-0ubuntu10 front-end programs for PostgreSQL 8.4
ii  postgresql-clien 106ubuntu1       manager for multiple PostgreSQL client versions
ii  postgresql-commo 106ubuntu1       PostgreSQL database-cluster manager
un  postgresql-doc-8 <none>           (no description available)
un  postgresql-pl    <none>           (no description available)

Notification seen during upgrade (extracted form /var/log/dist-upgrade/apt-term.log).

Obsolete major version 8.4
 
The PostgreSQL version 8.4 is obsolete, but the server or client packages are still installed. Please install the latest packages (postgresql-9.1 and postgresql-client-9.1) and upgrade the existing  clusters with pg_upgradecluster (see manpage).
 
Please be aware that the installation of postgresql-9.1 will automatically create a default cluster 9.1/main. If you want to upgrade the 8.4/main cluster, you need to remove the already existing 9.1 cluster (pg_dropcluster --stop 9.1 main, see manpage for details).
 
The old server and client packages are no longer supported. After the existing clusters are upgraded, the postgresql-8.4 and postgresql-client-8.4 packages should be removed. Please see /usr/share/doc/postgresql-common/README.Debian.gz for details.
 
<OK>

dpkg -l postgresql* (after Ubuntu upgrade) .

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version          Description
+++-================-================-================================================
ii  postgresql       9.1+129          object-relational SQL database (supported versio
un  postgresql-7.4   <none>           (no description available)
un  postgresql-8.0   <none>           (no description available)
ii  postgresql-8.4   8.4.13-0ubuntu10 object-relational SQL database, version 8.4 serv
ii  postgresql-9.1   9.1.5-0ubuntu12. object-relational SQL database, version 9.1 serv
un  postgresql-clien <none>           (no description available)
ii  postgresql-clien 8.4.13-0ubuntu10 front-end programs for PostgreSQL 8.4
ii  postgresql-clien 9.1.5-0ubuntu12. front-end programs for PostgreSQL 9.1
ii  postgresql-clien 129              manager for multiple PostgreSQL client versions
ii  postgresql-commo 129              PostgreSQL database-cluster manager
un  postgresql-contr <none>           (no description available)
un  postgresql-doc-8 <none>           (no description available)
un  postgresql-doc-9 <none>           (no description available)
un  postgresql-pl    <none>           (no description available)
un  postgresql-plpyt <none>           (no description available)
Sun, 09/09/2012 - 14:47
andreychek

Okay, so both postgresql-8.4 and postgresql-9.1 are installed -- it does sound like postgresql-8.4 does ultimately need to be removed.

However, I'd recommend ensuring that apt's package upgrade process has properly migrated all your data into postgresql-9.1 prior to doing that.

In theory, it should do that for you, but it'd be wise to verify that first :-)

-Eric

Tue, 09/11/2012 - 10:34 (Reply to #9)
fade2gray

postgresql-8.4 was installed when I ran Virtualmin gpl install.sh on Ubuntu server 10.04.x LTS, so shouldn't the upgrade to 12.04.1 LTS have automatically handled the transition from postgresql-8.4 to 9.1?

Besides, I don't use postgresql and the postgresql module shows that the default databases have no tables, so I assume that it's not used by the system, Virtualmin or Webmin and is safe just to purge 8.4?

Tue, 09/11/2012 - 11:12
andreychek

Yup, if you're not using Postgres, then it should be completely safe to purge the old version.

It's likely even safe to do so if you are using Postgres -- being cautious here is just a precaution in case you had data you wanted to preserve.

Since that's not the case, there shouldn't be any problem at all in removing that old version.

-Eric

Tue, 09/11/2012 - 11:24 (Reply to #11)
fade2gray

Great - thanks Eric.

Topic locked