Hi everyone,
I have decided to venture down what I hope is a well trodden path by now;
upgrading my VPS from Debian Lenny to Squeeze.
I have scoured the list archives and tried to make the most of
http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.h…
however I'm not ashamed to admit that I'm no expert in this regard and
very much still learning so would appreciate a critique of my plan of
action:
- Ask Support kindly to perform a temporary disk snapshot
- Login via Xen console
- Verify no pending actions required for currently installed packages:
aptitude (Then hit 'g' once in 'visual mode')
- Verify that all packages are in an upgradable state:
dpkg --audit
- Show currently installed kernel(s):
dpkg -l | grep linux-image
Mine currently shows:
ii linux-image-2.6-xen-686 2.6.26+17+lenny1 Linux 2.6 image on
i686, oldstyle Xen suppor
ii linux-image-2.6.26-1-xen-686 2.6.26-13lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
ii linux-image-2.6.26-2-xen-686 2.6.26-26lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
- Confirm non-usage of grub2:
dpkg -l | grep grub
Mine currently shows:
ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy version)
ii grub-common 1.96+20080724-16 GRand Unified Bootloader, version
2 (common
- Updates apt sources lists from lenny to squeeze:
sed -i s/lenny/squeeze/g /etc/apt/sources.list
- Manually edit /etc/apt/source.list to confirm success of the above step
and comment out any other repositories (non-Debian, backports etc) ?
- Upgrade the kernel: (*** Am I aiming for the right one here? ***)
aptitude install linux-image-2.6-686-bigmem
- Update grub configuration:
update-grub
- Remove clocksource=jiffies from kopt directive in /boot/grub/menu.lst
and confirm correct kernel will be loaded (i.e. default # matches new
kernel position)
- Upgrade udev (to minimise the risk of running the old udev with the new
kernel):
apt-get install udev
- Reboot
- Record a transcript of the upgrade session:
script -t 2>~/upgrade-squeeze.time -a ~/upgrade-squeeze.script
(This can be reviewed at a later date with scriptreplay
~/upgrade-squeeze.time ~/upgrade-squeeze.script)
- Update the package list:
apt-get update
- Perform a minimal upgrade (i.e. upgrade those packages that don't
require installation/removal of any other package(s)):
apt-get upgrade
- Complete the rest of the upgrade:
apt-get dist-upgrade
- Remove old/obsolete packages no longer required:
apt-get autoremove
- (Hopefully:) After the dust settles, advise Support that the snapshot of
the old system can be removed
Hope does that all look? Please don't hold back...
Regards,
Mathew
Hey guys,
Does anyone have a Minecraft server running on there VPS? I am thinking
about running one on a Bitfolk VPS but I am not sure how successful it will
be, also let me know how much memory you have if you can :)
Thank you,
Daniel
On 13 October 2011 15:12, Dom Latter <bitfolk-users(a)latter.org> wrote:
> I trust I can ask this sort of question here without sparking a
> religious war - but what advantages are there in using Ubuntu on
> a server? I've been an Ubuntu desktop user for some years [1],
> but for servers I generally stick with Debian.
Based on about 8 years of running 1-3 low-usage personal servers on
Debian and 6 months running ~150 Ubuntu server hosts professionally:
Ubuntu Pros:
- Hardware certification. I can buy hardware with a reasonable
expectation that it'll work with a specific release without spending
hours attempting to find out how well individual hardware components
work. It's not a perfect scheme, but it's a start.
- Vendor support. Dell, VMware and others package various useful bits
of software and put them in their own repos. They don't all do a
brilliant job at it (e.g. VMware's kernel modules are often several
ABI versions behind the latest kernel security release) but they do
it. [1]
Ubuntu Cons:
- Security releases. The Debian security team seem to ship patches
first and the Ubuntu ones lag a bit.
I don't think there's a hugely compelling reason to migrate between them.
G
[1] Whether or not you trust an organisation enough to add their repos
to your apt sources is another matter. I tend to download the debs and
stick them in a local apt repo, but this is significantly less work
than packaging the software myself.
Hello,
If you're going to the Ubuntu release party in London tonight:
http://loco.ubuntu.com/events/ubuntu-uk/1283/detail/
Then do track me down and say hello. :)
And no you can't yet use an official installer to put Oneiric Ocelot
(11.10) on a BitFolk VPS, but I hope to have that available this
weekend. With the usual warnings about not rushing into upgrades.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"I'd be happy to buy all variations of sex to ensure I got what I wanted."
-- Gary Coates (talking about cabling)
Hi,
entropy.lon.bitfolk.com [212.13.194.102] has been renumbered to
85.119.80.215. If you're making use of our free entropy service[1] then
you may be referring to this host by IP address in your
configuration[2].
Use of the entropy service is not configured by default, so if you
don't know what I'm talking about then you most likely don't have
anything to change.
The old IP address will continue to respond until Sunday 30th
October 2011, at which point we will be taking it out of service.
If you're currently referring to it by IP address then you should
change to the host name now.
A summary of all renumberings currently in progress can be found
here:
https://tools.bitfolk.com/wiki/Renumbering_out_of_212.13.194.0/23
If you have any questions, please reply to the list or to
support(a)bitfolk.com.
Cheers,
Andy
[1] https://tools.bitfolk.com/wiki/Entropy
[2] Usually /etc/default/ekeyd-egd-linux on Debian/Ubuntu
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"I am the permanent milk monitor of all hobbies!" -- Simon Quinlank
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hello,
We're now very close to the point when we need to begin getting you
all to renumber your IP addresses. We are not there yet, but here is
some more info:
https://tools.bitfolk.com/wiki/Renumbering_out_of_212.13.194.0/23
Before finalising the procedure and sending out instructions I could
use some feedback from you on a couple of points. These involve
situations where BitFolk is contacting you by IP address.
- BitFolk Backups
Our backup servers are doing rsync-over-SSH by IP address.
If we change the IP addresses our side then your backups stop
working until you make your change.
If we don't change the IP addresses our side then your backups
will break when you make your change, and then you would need to
contact support to get the change done.
Which would be preferred?
- Nagios checks
Many of you have Nagios checks. These are done by IP address.
If we immediately make the change on our side then alerts will
start to fire for you, and will not right themselves until you
complete the IP address change on your side.
If we don't make the change on our side then as soon as you make
your change, alerts will start to fire and then you'd have to
contact support to ask for the monitoring to be fixed.
I have a strong preference for us making the change as soon as you
have the info to make the change your side, so that the monitoring
fixes itself as you do the work.
Any other ideas how to do it?
- Old rsync-style zone transfers
Some of you still have DNS secondary services driven by zone files
that we are rsyncing from you. This is happening by IP address.
This service was deprecated years ago, since everyone got enough
RAM to run a proper DNS server for this purpose.
I would like to finally retire this service. How much time would
people like to stop relying on it and switch to running a real DNS
server?
- DNS slaves
Those of you who have secondary DNS services will be running your
own DNS server on your VPS and we'll be doing AXFR to that IP
address.
The DNS secondary service comes with Nagios monitoring, so as soon
as we switch the IP configured on our side then monitoring as
mentioned above will begin to alert.
There can be multiple masters, so what we could do is set both old
and new IP addresses so that zone transfers can continue to take
place, but our monitoring can only have one IP address.
With that in mind I think I would prefer to set both old and new
IPs as masters, let monitoring alert for your TCP/53 and that will
fix itself as your sort out your new IP address.
Any other ideas how to do it?
As far as possible in all cases above I would like to avoid the
situation where we have to chase individual customers one-on-one
about things that suddenly stopped working.
I can imagine this might not be avoidable—particularly in the case
of the backups—so if we have to do it, we have to do it.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
spamd.lon.bitfolk.com [212.13.194.5] has been renumbered to
85.119.80.248. If you're making use of our free spamd service then
you may be referring to this host by IP address in your mail server
(or similar) config.
The old IP address will continue to respond until Tuesday 18th
October 2011, at which point we will be taking it out of service.
You should start using the new IP address now.
If you have any questions, please reply to the list or to
support(a)bitfolk.com.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
> The optimum programming team size is 1.
Has Jurassic Park taught us nothing?
-- pfilandr
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi all,
T-mobile are being quite insistent that the problems I have sending
emails with 4 different providers to port 587 whilst on 3G are not at
their end.
I believe I already know the answer to this, but can someone from
bitfolk please confirm that you don't block traffic from t-mobile 3G ip
addresses on port 587...?
(Has anyone come across this issue before? Seems like they have some
weird filtering that drops the smtp connection after the STARTTLS - even
happens on other port numbers)
Thanks
Joseph
Hello,
If BitFolk does not provide authoritative DNS services for one or
more of your domains then you can ignore this email.
One of our authoritative nameservers, a.authns.bitfolk.com, has been
renumbered from 212.13.194.70 to 85.119.80.222.
Normally you would only refer to this nameserver by name, so most of
you will not need to make any modifications to DNS zones or
registrar settings. If you have for some reason created records in
your zones that point at 212.13.194.70 then it's now time to change
these.
Many of you are probably restricting zone transfer by IP address.
Zone transfers will continue to come from 212.13.194.70 until Monday
17th October 2011, at which point we will switch to sourcing them
from 85.119.80.222. Please add 85.119.80.222 to your ACLs now,
without removing 212.13.194.70.
If you have any questions about this, please do reply to the list or
to support(a)bitfolk.com.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce