Advice please people.
I have two VPSs. One runs Lenny, the other etch. There are sufficient differences between the two for me to want to standardise on lenny. (I also run lenny internally on a couple of NSLU2s).
Upgrading should not be a problem. I have experience of doing exactly that on local machines - but I have never done it from the end of an ssh connection when the machine in question is housed in a remote datacentre (and, moreover, is a virtualised image).
The debian site (at http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.html) recommends against upgrading remotely using telnet, rlogin or rsh, but suggests that ssh will be OK.
So, before I jump in with both feet, any experience anyone could share would be good. Particulary I would like to be aware of any potential gotchas. I really don't want to be stuck with a partial upgrade that I can't get back in to.
Cheers
Mick ---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
2009/11/24 mick mbm@rlogin.net:
The debian site (at http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.html) recommends against upgrading remotely using telnet, rlogin or rsh, but suggests that ssh will be OK.
So, before I jump in with both feet, any experience anyone could share would be good. Particulary I would like to be aware of any potential gotchas. I really don't want to be stuck with a partial upgrade that I can't get back in to.
I have upgraded both debian and ubuntu over ssh in the past. It's a while since I've done it with debian but I seem to remember it was a similar experience to ubuntu (server).
I think the upgrade spawned a special ssh server on a different port so that in the case you screw up the regular one during the upgrade you can ssh to the other port. I ran the upgrade under screen so I could reconnect to it if I lost the connection. I don't know what would have happened to the install if I had disconnected half way through and wasn't running screen.
HTH,
JD
On Tue, 2009-11-24 at 20:56 +0000, mick wrote:
Advice please people.
I have two VPSs. One runs Lenny, the other etch. There are sufficient differences between the two for me to want to standardise on lenny. (I also run lenny internally on a couple of NSLU2s).
Upgrading should not be a problem. I have experience of doing exactly that on local machines - but I have never done it from the end of an ssh connection when the machine in question is housed in a remote datacentre (and, moreover, is a virtualised image).
The debian site (at http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.html) recommends against upgrading remotely using telnet, rlogin or rsh, but suggests that ssh will be OK.
Maybe the reason for suggesting ssh is that normally the ssh master/listener process can be killed and re-starting without disconnecting existing sessions.
As you mention it is a virtualised machine this should actually make things easier in two ways if you have some support:
1. A snapshot of the machine can be taken before the start of the process to restore to if it all goes wrong.
2. The equivalent of pressing the "Reset" button can be done from a software control panel rather than making a journey to the physical location of the server.
Of course if you want to rely on either of those things you'd want to know who to call to arrange it.
Regards, Steve.
mick mbm@rlogin.net wrote:
So, before I jump in with both feet, any experience anyone could share would be good. Particulary I would like to be aware of any potential gotchas. I really don't want to be stuck with a partial upgrade that I can't get back in to.
I've done a few etch-to-lenny upgrades now and I only had a problem with postgresql not migrating its databases correctly on one system for reasons I never did track down. So, the usual precautions of backing up before you start, using screen (or dtach or similar) and making sure you can reboot your server into an old kernel if needed should be sufficient.
As others have written, VPSes should be easier to ensure that.
Good luck!
On Wed, 25 Nov 2009 09:38:01 +0000 (GMT) MJ Ray mjr@phonecoop.coop allegedly wrote:
mick mbm@rlogin.net wrote:
So, before I jump in with both feet, any experience anyone could share would be good. Particulary I would like to be aware of any potential gotchas. I really don't want to be stuck with a partial upgrade that I can't get back in to.
I've done a few etch-to-lenny upgrades now and I only had a problem with postgresql not migrating its databases correctly on one system for reasons I never did track down. So, the usual precautions of backing up before you start, using screen (or dtach or similar) and making sure you can reboot your server into an old kernel if needed should be sufficient.
As others have written, VPSes should be easier to ensure that.
Turns out I can't actually upgrade the VPS!. Rapidswitch's (the provider in question) virtualisation doesn't allow for kernel upgrades so I'm stuffed.
Hey ho.
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
mick wrote:
Turns out I can't actually upgrade the VPS!. Rapidswitch's (the provider in question) virtualisation doesn't allow for kernel upgrades so I'm stuffed.
One of my colleagues is very very rude about Rapidswitch and I've never asked why because I've not contemplated using it. Maybe that sort of thing is usual for them.
What do people think about upgrading everything but the kernel?
Regards,
On Mon, 30 Nov 2009 19:33:59 +0000 (GMT) MJ Ray mjr@phonecoop.coop allegedly wrote:
One of my colleagues is very very rude about Rapidswitch and I've never asked why because I've not contemplated using it. Maybe that sort of thing is usual for them.
I'm not surprised. They have given horrible service recently (serious service outages of many hours following router failures) and I regularly get downtime messages.
BUT - their low end VPS offering gives 150 Gig of traffic per month for GBP 9.99. I can't get that sort of allowance from Bytemark (my other provider who host my web/MTA) at anywhere near that price point. Since I host a tor exit node on the Rapidswitch VPS, I really need a high traffic allowance.
I am actively looking to move off rapidswitch. I tried Tagadab (who offered 500GB of traffic pcm, but their sharp business practice put me off. They offer a cheap trial (GBP 1.00 for the first week) followed by GBP 9.99 pcm. But they set up a repeating charge to my credit card without my agreement so I cancelled. Rapidswitch at least allow me to pay a rolling 1 month contract.
I am now looking at daily.co.uk who offer 750 GB of traffic pcm on their entry levl VPS. They have just responded to a query from me about their AUP to say that they are happy with my running a tor node but that I should keep an eye on my traffic. I'll let you know how I fare as I move to them.
Cheers
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
-
Jon Dye -
mick -
MJ Ray -
Steve Fosdick