Hello,
A local root exploit has been found in udev, which I imagine almost
all of you are running:
http://lists.debian.org/debian-security-announce/2009/msg00083.html
It's important that you ensure you have applied your distribution's
fix.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hello,
Since around 11:00Z UnitedLayer has been off the air. UL is
Bitfolk's colo provider in San Francisco, by way of Cernio.
Bitfolk does not currently host any customer VMs in San Francisco,
but the Request Tracker, backup mail host and one DNS server are
there.
Details are sparse: http://search.twitter.com/search?q=unitedlayer
If it continues much longer then I will begin migrating these
services elsewhere.
For now, support(a)bitfolk.com goes direct to me instead of into the
ticketing system.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hello all.
I have recently joined, following many years as a member of a hosting
co-op. I'm currently in the middle of getting my VPS set up as I like
it and have run into a problem that, for once :), is not really my
fault.
Yesterday, I downloaded Bastille from the Debian 5 / Lenny
repositories, but it will not install on Debian 5.
This is a known bug (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510884) - and is even
marked as 'fixed' - but it has left my packages in a twist.
If I try to uninstall it, I get this
semi-divine:~# dpkg -r bastille
(Reading database ... 37260 files and directories currently installed.)
Removing bastille ...
Stopping Bastille firewall..ERROR: no reject method specified
(corrupt config file?) Exiting!
FAILED.
invoke-rc.d: initscript bastille-firewall, action "stop" failed.
dpkg: error processing bastille (--remove):
subprocess pre-removal script returned error exit status 1
Starting Bastille firewall..ERROR: no reject method specified
(corrupt config file?) Exiting!
FAILED.
invoke-rc.d: initscript bastille-firewall, action "start" failed.
dpkg: error while cleaning up:
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
bastille
.. even if I try forcing it.
OK, after wondering how on earth this one got past testing, let's try
downloading the updated version and see about installing that over the
top:
semi-divine:~# dpkg -i bastille_3.0.9-9_all.deb
Selecting previously deselected package bastille.
(Reading database ... 37221 files and directories currently installed.)
Preparing to replace bastille 1:2.1.1-19 (using
bastille_3.0.9-9_all.deb) ...
Unpacking replacement bastille ...
Setting up bastille (1:3.0.9-9) ...
Installing new version of config file /etc/init.d/bastille-firewall ...
Starting Bastille firewall..ERROR: no reject method specified
(corrupt config file?) Exiting!
FAILED.
invoke-rc.d: initscript bastille-firewall, action "start" failed.
dpkg: error processing bastille (--install):
subprocess post-installation script returned error exit status 1
Processing triggers for man-db ...
Errors were encountered while processing:
bastille
So I currently can't uninstall it or reinstall it. Grrr.
What should I do next, any Debian experts reading?
Thanks,
Ian
Hello,
Graham from cernio.com is in UK this week and we're going to go to
the Greater London LUG meeting at Westminster Uni on Saturday:
http://gllug.org.uk/index.php?/archives/45-28th-March-Greater-London-LUG-Me…
If any of you are in the area I'd love to meet you, and I'm sure
Graham would be interested to talk about co-operatives and hosting
services located all over the world.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi,
Some of you may recall the additional 120M RAM that was promised for
the end of January. If you don't know what I am talking about then
it's likely that you're one of the newer customers who already got
set up with the larger plans and none of this applies to you. If
you're not sure, see the price list on the web site which is current
and compare it with what you're paying.
The first attempt at this - just putting 48G of RAM into the
machines and rebooting them - hit problems when it turned out that
32bit Xen could not see more than 16G of RAM. That didn't provide
enough RAM for everyone to have the upgrade, and represented a waste
besides.
I then decided to use what was at the time a cold spare server to
experiment with a 64bit hypervisor on 32bit userland. If successful
then it would be something I could replicate on the other servers
with just some package installs and a reboot, as opposed to a
complete reinstall.
Well, it hasn't been as successful as I would like. Centos guests
seem to be incredibly unstable, and I think it's too risky to go
100% with that configuration.
In the meantime I have had to advertise the new plans on the web
site because the whole point of this was to keep Bitfolk
competitive. This became even more important recently when Bytemark
announced their plan upgrades.
My new plan is to install more hardware and build it 64bit to begin
with, and evaluate running 32bit guests on there. Why not 64bit
guests you may ask. The reason for this is that being able to move
VPSes around between hosts is essential for redundancy purposes and
therefore having only one host that can run 64bit guests rules that
out for now. This will be revisited in a few months.
If that proves to be stable then I will need to slowly empty the
current servers onto the new ones and then rebuild the old ones.
That's going to take months.
People are quite understandably keen to have the upgrade ASAP and I
do sympathise with this. It isn't right that new customers should
get more for the same price and that was never the intention. There
has been talk of cancelling services and then buying them new again,
which is more work for everyone involved but would force the issue
in your favour.
To try to avoid this sort of thing as much as possible I have had a
look and it seems like by not taking on new customers for a while
and shuffling a few guests around I can provide the promised upgrade
to all customers *on certain hosts*. With a bit more shuffling I
can *probably* allow same for most of the remaining hosts. I will
still need to eventually move everyone off of all the old servers
and rebuild them, because there's a total of 24G of RAM not
currently accessible.
So anyway, first up are customers on curacao. If you shut down
(*NOT* reboot!) and boot again, you should get an additional 120M of
RAM. If you aren't sure whether you're going to get extra or not
and want to check, look how much RAM you have now and then log on to
https://panel.bitfolk.com/ which will tell you what your plan is.
If your plan is bigger, shut down + boot and that's what you'll get.
In the next few days I will do the same on obstler.
Not everyone quite fits on kahlua or kwak if you all got upgraded.
I will probably give the upgrade to those paying yearly or quarterly
first and then attempt to move some things around to see if I can
give more. It's not far off working, so should be possible.
corona on the other hand is a bit of a lost cause. It was already
maxed out of RAM at 8G, so didn't get any extra, and there's nothing
that can be done. All I can do here for those who are desperate for
the extra RAM is try to move you to other machines.
I have stopped accepting new customers until the new servers are
tested because otherwise things are just going to get dragged out
more. There will be natural churn of customers so from time to time
there will be space for those on the waiting list.
In the meantime if anyone feels they are happy with their existing
amount of RAM and want to downgrade to the new plan that gives them
the same amount of RAM for lower cost, drop an email to
support(a)bitfolk.com and that will happen. People on quarterly or
yearly payments can too, and will get service credit back.
Any questions, feel free to ask on or off list..
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi folks,
I'm afraid that the host obstler went a bit strange whilst one of
you was shutting down your vps. dom0 reported the following:
Mar 20 11:04:38 obstler kernel: unregister_netdevice: waiting for v-jamesw to become free. Usage count = 1
over and over, and starting new VMs became impossible.
I had no choice but to shut down all VMs and then reboot the server,
start them again. You would have seen a clean shutdown and outage
until around 1117Z when VMs started to be brought up again. All
were up by 1126Z.
I am very sorry for the outage and will step up my investigations on
this -- it happened once before, 60 days ago.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi,
I thought I better point out - the reason that Bitfolk does not
offer Ubuntu Intrepid is that the Intrepid Xen kernel will not work
on anything except Ubuntu Intrepid host server, and Bitfolk does not
run Ubuntu.
I reported this as a bug ages ago and the outcome was that they
don't consider it a bug, have no intention of changing this (will
not be fixed in Jaunty or any later release either).
So if you are planning to upgrade to Intrepid please bear in mind
that you will need to use a non-Intrepid kernel, such as the one
from Hardy, or an upstream one or something like that. Basically I
do not recommend it.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
No problem here. We are getting what was advertised. It is not very
sensible to complain that others also get what they have contracted
for.
But you can never please all of the people all of the time.
Steve
Hi Andy,
I use the spamd server that you provide, so first of all thanks.
I have been seeing exim complain about a lot more timeouts recently and
I was wondering if the load had significantly increased on that server
or if perhaps you've added some tests that are taking longer.
Regards,
n
