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
In case you haven't already heard:
----- Forwarded message from Jan Henkins -----
Hello there,
Forwarding this to official support due to it's importance (should have
done this earlier!). Please pass this on to the Bitfolk list!
Since I've sent the below message, I have found a mitigation strategy for
Debian:
1) Create /etc/apache2/conf.d/setenvif with the following content:
---star---
<IfModule mod_setenvif.c>
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog /var/log/apache2/range-CVE-2011-3192.log common
env=bad-range
</IfModule>
---end---
Be advised that the above should not work out of the box, since "headers"
module was not enabled by default (this could be the actual Debian and
Ubuntu standard).
2) Enable the headers and rewrite modules:
a2enmod headers
a2enmod rewrite
3) Restart apache
---------------------------- Original Message ----------------------------
Subject: Apache 1.* and 2.* vulnerability
From: "Jan Henkins"
Date: Thu, August 25, 2011 11:00
--------------------------------------------------------------------------
Hello Andy,
Sorry for not posting this to the Bitfolk list directly, I'm on my
web-mail (didn't put the mailing list address in my address book), so
please consider passing this on.
Yesterday a nasty Apache DoS vuln was released. So far all versions of
Apache is affected by this. Here are some advisories:
RedHat:
https://bugzilla.redhat.com/show_bug.cgi?id=732928
Debian:
https://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C201…
While I have not managed to work out a mitigation strategy for
Ubuntu/Debian servers, the following works rather nicely on RHEL5 and
RHEL6 (so could be good to go for CentOS too):
Create /etc/httpd/conf.d/setenvif.conf with the following:
<IfModule mod_setenvif.c>
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog /your/log/dir/range-CVE-2011-3192.log common
env=bad-range
</IfModule>
Restart apache
That should do it nicely! :-)
More reading here:
http://eromang.zataz.com/2011/08/24/cve-2011-3192-apache-httpd-killer-remot…
Please pass on to the Bitfolk community at your discretion.
--
Regards,
Jan Henkins
--
Regards,
Jan Henkins
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
We've had reports that the password reset feature of the panel is
broken at the moment.
Some new code was pushed live a few days ago and this obviously got
past testing. I am working on fixing this as a top priority, but in
the mean time if you do require a password reset please:
1. Check to see if we've fixed it yet
2. If not, contact support@ requesting reset
3. Use phone if urgent and you haven't received confirmation that
it's been done yet
I do expect it to be fixed today.
https://tools.bitfolk.com/redmine/issues/80
Apologies for the inconvenience.
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,
With immediate effect we are moving to a calendar monthly /
quarterly / yearly billing cycle instead of a rigid 30 / 90 / 360
day cycle.
This was requested in:
https://tools.bitfolk.com/redmine/issues/13
You do not need to take any action. You will effectively get 5 or 6
days of additional service per year compared to before.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
I know there is a lot of discussion on this topic going around at the
moment. I was just wondering if the site-blocking will be enforced on our
VPS's, is Bitfolk the kind of ISP they are going for? Do bitfolk have to now
monitor our connection packets? I'm aware that they say they are going for
compyright-infringing sites...but it seems like a slippery slope down to me
(where does it stop, YouTube has plenty of fan videos) and I'm sure a lot of
you are with me on the issue of freedom of speech, i'm fairly sure before
long we will have the "Great Firewall Of Britain"
Thank you,
Daniel
