Howdy all,
The Virtualmin install script now works on Debian 6.0 (squeeze). It is extremely new, but seems to work fine. File tickets if you run into any problems installing on a freshly installed Debian 6.0 system.
Warning for those upgrading from Debian 5.0 (lenny)
First up, I strongly recommend you wait a couple days until I've had a chance to test this and write a script to do it automatically. But, I know lots of people are chomping at the bit and they're going to try it anyway...so here's what I think needs to happen to safely upgrade. But the announcement of support is only for fresh installs. I don't know anything about dist-upgrades yet, as I haven't tested, but I know there is at least one problem that needs to be dealt with. If anyone wants to test this on non-production systems and let me know what blows up, that'd be cool. But, please proceed with extreme caution (and read all the messages from apt very carefully) if you're doing this on a production box (and it goes without saying that you ought to have known-good backups).
If you are upgrading an existing Virtualmin system from Debian 5.0 (lenny) or 4.0 (etch) you must manually install the dependencies for Virtualmin before upgrading your system. Otherwise, apt will helpfully remove all the packages that were installed to resolve dependencies in virtualmin-base. Those dependencies have been removed from virtualmin-base and moved into install.sh to avoid this problem in the future, but in current installations removing virtualmin-base or upgrading it will lead to auto-removal of a couple dozen somewhat important packages (like, Apache, BIND, MySQL; silly stuff like that, which some people like to have on their Virtualmin systems), possibly in addition to Virtualmin itself.
To avoid that, the following apt-get command will probably work:
apt-get install postfix postfix-pcre webmin usermin ruby libapache2-mod-ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev 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 libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libgd2-xpm libapache2-mod-php5 php5-mysql
From there, you'd want to update your virtualmin repo to point to virtualmin-squeeze rather than virtualmin-lenny. You should already have the virtualmin-universal repo configured as well; if you don't, see the docs for upgrading from etch to lenny (http://www.virtualmin.com/documentation/system/os/debian-etch-to-lenny-d...). Then perform a normal dist-upgrade.
Or, wait a couple of days, and I'll have a script that will do this for you, and it will have been tested and confirmed to not create a steaming pile of wreckage.
I think i'll wait..:) I want to be able to upgrade to squeeze and not nuke my virt install..:)
It seems testing of an upgrade lenny-based virtualmin system to squeeze doesn't go as smoothly as etch to lenny one..(
I haven't touched my lenny configuration and ran into a problem with the suggested upgrades from Virtualmin. It's suggesting this on the home screen:
If I upgrade this I lose my MySQL.
If i goto the command line and try: apt-get -s upgrade
server:/etc/apt# apt-get -s upgrade Reading package lists... Done Building dependency tree
Reading state information... Done The following packages have been kept back: libapache2-mod-php5 mysql-client-5.1 mysql-server-5.1 mysql-server-core-5.1 php-pear php5 php5-cgi php5-cli php5-common php5-gd php5-mysql The following packages will be upgraded: libmysqlclient16 mysql-client mysql-common mysql-server 4 upgraded, 0 newly installed, 0 to remove and 11 not upgraded. Inst mysql-common [5.1.54-0.dotdeb.1] (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Inst libmysqlclient16 [5.1.54-0.dotdeb.1] (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Inst mysql-client [5.1.54-0.dotdeb.1] (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Inst mysql-server [5.1.54-0.dotdeb.1] (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Conf mysql-common (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Conf libmysqlclient16 (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Conf mysql-client (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable) Conf mysql-server (5.1.55-0.dotdeb.1 packages.dotdeb.org:stable)
Not a problem as I had a "good known backup" and restored as it made quite a mess. I'm not sure if they problem is on my end or is a problem with the virtualmin. I just wanted to post it here to help.
BTW my sources.list is this: deb http://ftp.de.debian.org/debian lenny main contrib non-free deb http://ftp.de.debian.org/debian-volatile lenny/volatile main contrib non-free deb http://ftp.de.debian.org/debian-security lenny/updates main contrib non-free
deb http://software.virtualmin.com/gpl/debian/ virtualmin-lenny main deb http://software.virtualmin.com/gpl/debian/ virtualmin-universal main
deb http://packages.dotdeb.org stable all deb-src http://packages.dotdeb.org stable all
I think i'll do what i always do with production machines. Because virtualmin makes it sooooo easy to move between servers with it's backup procedure i'm going to backup the server...wipe it and install deb6.. install virt..then restore from said backup..:)
hescominsoon: I think i'll do what i always do with production machines. Because virtualmin makes it sooooo easy to move between servers with it's backup procedure i'm going to backup the server...wipe it and install deb6.. install virt..then restore from said backup..:)
So, did you do it? All went fine?
You don't really have an "untouched" system. You use Dotdeb which means your system is not vanilla Debian Squeeze any more. That might explain your problems.
cerebrum: forgot I had added dotdeb. Don't even remember why I added it. Removing it does stop the mysql apt-get suggested updates.
Liking the idea of do a clean install and then a restore hescomingsoon.
Two weeks have passed, instead of "couple of days".. if there are any problems with finishing that migration script, probably you may tell us what's the problem, so somebody can help with dealing with that.
Ok, as soon as we don't have the upgrading script yet - have anyone already performed an upgrade from lenny to squeeze without breaking virtualmin manually?)
Anyone successfully upgraded from Lenny (with Virtualmin) to Squeeze (with Virtualmin) ?
It would be great if someone could write a step by step upgrade guide!
@Joe
Any luck or progress on the script you've been writing to do the upgrade? I can't wait to have squeeze on my production server. Just that I fear things breaking crazily unless someone writes a detailed guide to do so.
Looking forward to the outcome of your tests!
Thanks in advance!
It worked for me...
Basically I had a fresh Lenny install from a VPS Rackspace Cloud Server, had installed Webmin, then Virtualmin, updated all packages with Lenny as my package list. Setup my virtual servers, etc..
Then one night, after a few beers, I changed things to the Squeeze package trees and logged back into Virtualmin and crossed my figured and hit install all updates.
As all the text flew by, there were lots of error messages, but at least it recognized that not all packages were installed yet, and the process kept trucking along. Apt-get is da bomb...
It worked!
I rebooted server, then even manually updated to 3.84gpl since it wasn't in the repo list yet and I wanted the roundcube install script.
Only thing I had to do was a couple places I had to manually update the OS so that Virtualmin would be kosher, but it recognized that 6.0 was installed, but that Virtualmin/Webmin was set to 5.0 and it asked me to update it. Virtualmin scripts are pretty slick as well.
YMMV of course, but just wanted to say "it worked for me".
Webalizer was not working for me since the upgrade from Lenny to Squeeze, but the problem was solved by installing the package geoip-database.
This package should probably be added to debdeps in the install script and in the list of packages to install in the FP of this topic.
For those who've successfully upgraded, could you please link to what all references you used that guided you for the steps to upgrade? I'm waiting to upgrade, just can't find the steps for a tried and tested solution.
Thanks in advance!
"Or, wait a couple of days, and I'll have a script that will do this for you..." almost two months have passed.. I understand, that you're running out of time, and that's not a paid support, it's all voluntary, but.. it's ok, if you will say "I don't have time to make this script" - I can understand that, so I'll find another ways. But, when you say "wait a couple of days" and then nothing from you in 6 weeks - that's something strange..
Hey Joe,
I understand that you may be busy too. If possible, please just give me an update on whether there's going to be a well guided script or tutorial to do this migration. I'd be glad and a lot of people here too, like the one above. :-)
Cheers!
news? My Debian Lenny wants to be squeeeeeze
Joe,
Please kindly post an update to where the upgrade script/tutorial stands and when it can be expected to be released.
Thanks for your hard work!
Okay!
We've done some testing, ran into some caveats, fixed those caveats, and then put together some wonderful documentation for upgrading from Debian Lenny to Squeeze.
Before making any changes, please make sure you have full backups of everything you care about! Even your pictures and music at home -- back those up too just to be on the safe side :-)
There's a lot of changes going from Lenny to Squeeze, so be prepared for some downtime. The Squeeze release notes actually suggest making sure you have console access to your server when performing an upgrade, as there's some pretty significant changes to the boot system.
Also, note that Squeeze uses PHP 5.3, which not all web applications support.
Now, without further ado, here is the Debian Lenny to Squeeze Upgrade Guide:
https://www.virtualmin.com/documentation/system/os/debian-lenny-to-squee...
"Better late than never" ? :D Can't wait to start & test it. Thank you "Virtualmin-Team" for that great Product & Support.
But at the time there is no time for testing--- I think in two weeks or so I can do that.
andreychek, thank you very much, it worked out! There were no problems with mysql or dovecot, as you assumed, and following your manual step by step gave a perfect result) But, I'v got another one small problem with BIND. In virtualmin it always is indicating like "down", but it IS in the prosess list, and /etc/init.d/bind9 start/stop works correctly. Do you know, why this problem coild happen?
p.s. thank you again for the manual, I'm on squeeze now!
Howdy,
I'm glad to hear it worked (mostly)!
As far as that BIND issues goes -- the first thing I'd try there is to go into Webmin -> Servers -> BIND DNS Server -> Module Config -> System Configuration, and make sure that "/var/run/named/named.pid" is listed in the "Default PID file location" box.
If it is -- you may want to double-check that you do indeed have a .pid file at that location (/var/run/named/named.pid).
-Eric
Thank you again! For some reason, the path to PID was different, so I've changed it accroding to your example, and it worked smoothly, thanks!)
andreychek, will I run into any issues if my server is configured with software RAID-1? Maybe a little off-topic but I've had virtualmin on this server since day 1 and I've been waiting like crazy to upgrade it. I just don't want any post-upgrade-boot-issues. How likely is it?
Howdy,
Well, it's difficult to predict if having RAID-1 would cause any issues.
In theory, it should be just fine!
However, it is an additional moving part -- and every moving part has an opportunity to fail :-)
My recommendation is that, if you want to minimize the chance of downtime -- build a test server running RAID-1, and perform an upgrade first on your test server.
Also, you may want to take a look at the Debian 6 release notes... there's an entry in the notes about boot parameter you may need to pass in if you run into trouble. Search for the word "raid" at the following link:
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en...
Also, you may want to review this section about the Grub version:
http://www.debian.org/releases/stable/i386/release-notes/ch-information....
Thanks for that reply.
Well, it's not an extra moving part.. did I mention it is SOFTWARE based RAID-1? Which is why I'm kinda worried about any Grub related issues after an upgrade.
The second link you gave me is completely greek to me.
p.s: could you approve my previous comment? it doesn't appear in the list. it may be useful to others too.
Howdy,
Well, it's not an extra moving part.. did I mention it is SOFTWARE based RAID-1? Which is why I'm kinda worried about any Grub related issues after an upgrade.
I mean "moving part" in the software sense... just that every additional piece to the puzzle is something that can go wrong.
The Debian release notes talk about 2 or 3 things that can go wrong during an upgrade when using software RAID.
Although it should work, I unfortunately can't predict what issues you'll run into... if you're concerned about it working, I'd recommend testing the upgrade process as thoroughly as possible on a test system (particularly one with similar hardware) before changing your live box.
-Eric
Thanks Eric for all the info.
I will give it a spin in the coming week. If all is well, I will come and report here so others can be sure to :)
Cheers!