Hi,
I was hoping to only mention this much closer to the time when it
could actually happen, but a few people have been asking about this
so I thought it was only fair to give an update.
TL;DR version:
We're planning to soon double the amount of RAM offered for the
current price. You'll be contacted individually when this can
happen; hopefully it just happens, but if you're unlucky then you
might need to be migrated or keep the same amount of RAM for a lower
price instead. Do not panic. You can stop reading now. :)
Longer version:
For a while now it has been clear to us that BitFolk has fallen
behind its competitors in how much RAM we offer for a given price
point, and I wanted to reassure you that I have been taking steps to
remedy this. These have included:
- 56GiB of RAM installed across several machines at the recent
maintenance at the end of February.
- Ongoing migration of all customers off of dunkel.bitfolk.com so
that some non-urgent hardware maintenance and a RAM upgrade can be
done.
- New server with 48GiB RAM being prepared for colo now.
We are hoping to double the RAM allocation for the same price, i.e.
the smallest VPS will come with 480MiB RAM and additional RAM may be
purchased 240MiB at a time.
We could of course just offer this right now to new customers, but I
really dislike it when existing customers are not offered the same
deal as new, even if it does make some business sense to chase the
new. So, I'm holding back from doing that until I know it will be
possible to apply the upgrade to the majority of existing customers.
I can't give any firm timescale for this right now; it's going to
happen as soon as possible.
For many customers this is all going to be very simple; you'll
receive an email that says "congrats, shut down and boot again to
enjoy twice as much RAM". That's it. Unfortunately for some of you
it's not going to be possible to "just do it".
Some of you will be on hosts that cannot be economically upgraded.
8GiB DDR2 DIMMs are stupidly expensive; it's cheaper to buy new
machines with 8GiB DDR3. Here's how it's going to work:
Customers with 240 or 360MiB RAM will be upgraded first. That's
because 240 and 360MiB plans won't be available to new customers
afterwards. If we can't upgrade you because the host is out of
RAM then you will be offered migration[1] to a host that does have
enough RAM. If there's no host available with enough RAM then you
will remain with the same amount of RAM and your future renewals
will be cheaper, however we will upgrade you to at least 480MiB RAM
as soon as we can and you will have no choice in this.[2]
Next, customers with 480MiB or more RAM will be upgraded. If we
can't upgrade you then you'll stay with the RAM you have, at the
lower cost.[3]
As soon as we start upgrading people, the new plans will be
available to new customers, although we may run out of capacity
quickly due to upgrading existing customers. Once this happens,
please don't try to cancel your monthly contract and sign up again
to get the extra RAM quicker; I would hope to have upgraded everyone
that I can within a couple of days of starting. :)
As usual if anyone wants to downgrade then they will be free to do
so from their next contract renewal.
However, if:
- you currently have 480MiB or more of RAM *and*;
- you know you don't need twice as much as you have now *and*;
- you're definitely going to ask to be downgraded back towards what
you started with;
then it would be helpful if you could email support(a)bitfolk.com with
your VPS account name and the amount of RAM you'd like to end up
with. We *may* be able to both downgrade you (and give you some
service credit back) and use that RAM to give to someone else. No
promises though; you may have to wait until your next renewal as
normal.
If you have any questions about all this then please just hit reply
to direct them to the users list, or send an email to
support(a)bitfolk.com if you'd rather discuss off-list.
Cheers,
Andy
[1] Migrating your VPS between hosts will require us to shut it down
and then boot it up again, with something like 5-10 minutes of
downtime in between. If a migration is necessary then we'll
contact you individually to co-ordinate the work.
[2] While you may be satisfied that 240 or 360MiB RAM is adequate
for you, I don't want to keep lots of custom plans going and I
don't want to bill below £8.99/mo if possible.
[3] e.g. If you're on 480MiB RAM, 10GiB disk, 100GB/mo data transfer
then that currently costs £13.99/mo. If we couldn't upgrade you
to 960MiB RAM then you will remain on 480MiB but the plan will
only cost you £8.99/mo from your next renewal.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
If you've recently installed the PAM security update in ubuntu, or
have automatic updates enabled, then I recommend reading this:
http://www.ubuntu.com/usn/usn-1140-2/
"USN-1140-1 fixed vulnerabilities in PAM. A regression was found that caused
cron to stop working with a "Module is unknown" error. As a result, systems
configured with automatic updates will not receive updates until cron is
restarted, these updates are installed or the system is rebooted. This
update fixes the problem."
Regards,
Graham
Hello,
On Tue, May 31, 2011 at 11:56:17AM +0100, Michael Stevens wrote:
> On Tue, May 31, 2011 at 10:53:56AM +0000, Andy Smith wrote:
> > I'll look into what access it needs and see if I can allow it.
>
> It's not too important as I've found some monitoring that works now.
I've fixed it now. It needed "noquery" restriction lifting for
customer networks, so you can query server status.
Cheers,
Andy
Hello,
On Tue, May 31, 2011 at 11:49:05AM +0100, Michael Stevens wrote:
> On Tue, May 31, 2011 at 10:38:41AM +0000, Andy Smith wrote:
> > And from some random host appears to work:
> >
> > $ /usr/lib/nagios/plugins/check_ntp -H 212.13.195.4
> > NTP OK: Offset 0.006038069725 secs|offset=0.006038s;60.000000;120.000000;
>
> Sent more info in other email.
I see. The check_ntp_peer plugin must require more permissions, as I
found a machine with it on and I can reproduce this. NTP is a UDP
protocol and tends to just ignore you if you ask it things that it
isn't allowed to tell you, so that'll probably be why it says
timeout.
I'll look into what access it needs and see if I can allow it.
Cheers,
Andy
Hi,
> root@ceres:/etc/nagios3/conf.d# host ntp1.lon.bitfolk.com
> ntp1.lon.bitfolk.com has address 212.13.195.4
> root@ceres:/etc/nagios3/conf.d# /usr/lib/nagios/plugins/check_ntp_peer
> -v -H 212.13.195.4
> CRITICAL - Socket timeout after 10 seconds
Do you have a firewall?
What do the rules look like?
Do you have a VPS that's old enough to have an IP address in the
original 212.13.194.0/24 range? If so, is your subnet mask set correctly
now that it's a /25 or have you allowed route redirect messages in?
http://lists.bitfolk.com/lurker/message/20081202.111409.1d738f7a.en.html
Can you ping 212.13.195.4 ?
I looks like I still have the /24 netmask but I can ping 212.13.195.4
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
Hi Michael,
On Tue, May 31, 2011 at 11:28:50AM +0100, Michael Stevens wrote:
> Being a big nagios fan, I'm trying to monitor the bitfolk NTP servers
> with nagios.
We already monitor them with nagios, btw. :)
And cacti:
http://tools.bitfolk.com/cacti/graph_779.html
> I have:
>
> define host{
> use generic-host ; Name of host template to use)
> host_name ntp1.lon.bitfolk.com
> alias ntp1.lon.bitfolk.com
> address 212.13.195.4
> }
>
> define service{
> use generic-service
> host ntp1.lon.bitfolk.com
> service_description ntp
> check_command check_ntp
> }
>
> Which seems like it ought to work. Testing with pool.ntp.org servers it
> seems to work.
What does it do instead of working?
What does your check_ntp command actually look like?
Mine looks like:
define command {
command_name check_ntp
command_line /usr/lib/nagios/plugins/check_ntp -H $HOSTADDRESS$
}
And from some random host appears to work:
$ /usr/lib/nagios/plugins/check_ntp -H 212.13.195.4
NTP OK: Offset 0.006038069725 secs|offset=0.006038s;60.000000;120.000000;
However, this is quite an old version of Nagios so maybe newer
checks do something that require more access.
Cheers,
Andy
Hi,
> I've put my vote in.
>
> It wasn't anything specific, just a vague belief that more bits =
> cooler, and a desire to keep the same architecture I had elsewhere.
Whilst this maybe the case ;-) more bits will mean that some programs
have a significantly larger memory footprint.
Beware the shiny! ;-)
I can sympathise with you tho': sometimes I have to jump through extra
hoops to build myself appropriate 32bit binaries for my VPS.
PS: If you want a 64bit architecture just for the sake of coolness I
recommend MIPS R12K, IA-64 or even UltraSPARC ;-)
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
Hi,
> Being a big nagios fan, I'm trying to monitor the bitfolk NTP servers
> with nagios.
>
> I have:
>
> define host{
> use generic-host ; Name of host template to use)
> host_name ntp1.lon.bitfolk.com
> alias ntp1.lon.bitfolk.com
> address 212.13.195.4
> }
>
> define service{
> use generic-service
> host ntp1.lon.bitfolk.com
> service_description ntp
> check_command check_ntp
> }
>
> Which seems like it ought to work. Testing with pool.ntp.org servers it
> seems to work.
>
> The nagios instance is running on my bitfolk VPS so it shouldn't be
> access related.
>
> Anyone know what I'm doing daft?
What specifically is not working?
How do you know it's not working?
What do the logs say?
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
Hi Michael,
On Sun, May 29, 2011 at 01:14:54PM +0100, Michael Stevens wrote:
> Hi.
>
> I notice I seem to have a 32bit VM. Or, at least, I have a 32bit OS
> installed.
>
> Does bitfolk offer 64bit VPSes? How do I get it setup?
I'm afraid only 32bit virtual machines are supported at the moment.
This is just to make life easier for us, but with the low amounts of
RAM in the typical VM they should actually be faster as 32bit for
most purposes.
Is there a particular reason that you need a 64bit install?
There's an open feature request for 64bit support here:
https://tools.bitfolk.com/redmine/issues/27
Please do log in (usual credentials) and vote it up if you'd like to
see it implemented.
I can see it happening in due course as it seems that the
architecture is a bit simpler than i386 and actually has fewer
quirks. Also VM memory footprints are getting larger.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
