On 5 February 2012 21:15, Paul Stimpson <paul(a)stimpsonfamily.co.uk> wrote:
> Hi,
>
>
> On 05/02/12 21:09, Graham Bleach wrote:
>>
>>
>> Everything you pasted looked fine to me. Do you by any chance have any
>> firewall rules that reference the old IPs or ranges explicitly?
>>
>> This should show them
>>
>> # iptables -L -n | fgrep 212.13.19
[Paul replied offlist to explain that it wasn't that]
Probably my final guess, but did you reboot your VPS? If so, try
shutting it down and then booting it
https://tools.bitfolk.com/wiki/Renumbering_for_customers#Your_next_reboot
Regards,
Graham
I'd forgotten this myself. I guess this puts an end to my procrastination.
http://lists.debian.org/debian-security-announce/2011/msg00238.htmlhttps://tools.bitfolk.com/wiki/Upgrading_your_Debian_VPS_from_lenny_to_sque…
I note that my root filesystem is on /dev/sda1. Aside from changing my
fstab to use UUIDs, are there any other special considerations for the
upgrade since I'm using /dev/sda* as opposed to /dev/xvda?
Note - Andy is probably on his way back from FOSDEM right now, so I
would set your expectations accordingly if you fire off a support
ticket to get a snapshot of your VPS root fs :)
Cheers,
Graham
After making sure that my VPS is receiving packets on the right address,
I'm now getting warnings that it's sending on the old address. To my
knowledge I don't have any software installed for which I needed to specify
the VPS' IP, so my guess is that this will end when I remove the old
address from network/interfaces. Is that right? Is there a way to test
before deleting the old IP?
Thanks,
Mike
On Sat, Jan 28, 2012 at 7:14 AM, <andy(a)bitfolk.com> wrote:
> Dear customer,
>
> You're receiving this email because our monitoring has detected that, in
> the last 24 hours, your VPS "science" is still sending packets from the
> address 212.13.195.254, which is part of our deprecated range of IP
> addresses, 212.13.194.0/23.
>
> Back at the start of November 2011 we announced that a renumbering would
> be necessary, and we set a deadline of Monday 6th February 2012 for this
> to be completed:
>
> * Announcement:
>
> http://lists.bitfolk.com/lurker/message/20111104.221826.7f38e097.en.html
>
> * Full instructions:
>
> https://tools.bitfolk.com/wiki/Renumbering_for_customers
>
> There's now just over a week before the IP addresses that you are still
> making use of are taken out of service. If you don't act to stop using
> these addresses then YOU WILL EXPERIENCE A LOSS OF SERVICE once
> 212.13.194.0/23 is decommissioned.
>
> Therefore if you have any questions about the renumbering process or
> need help to complete it, it is important that you get in touch with us
> as soon as possible.
>
> Questions regarding how to renumber would be best asked on the users
> mailing list:
>
> http://lists.bitfolk.com/lurker/list/users.en.html
>
> BitFolk will only be able to carry out the work on your behalf as a
> chargeable consultancy service. Please contact support if you would like
> us to do this.
>
> It is possible that you have received this email purely because you
> still have one or more of the deprecated IP addresses active on your
> VPS. Internet hosts receive a constant "background noise" of random
> traffic. It is recommended to remove the deprecated IP addresses once
> you think you don't need them any longer, both to avoid this and to
> reassure yourself that they are really not in use by other systems.
>
> Best regards,
> Andy Smith
> BitFolk Ltd
>
Hi,
If you don't currently take advantage of BitFolk's free backups
service then the following doesn't apply to you.
Two extra checks were added last night on the backups that BitFolk
manages for you.
All this info is going to go on a page I will create at
https://tools.bitfolk.com/wiki/Backups but you need to know it now.
- Backup age
This checks that your most recent successful¹ backup is not too
old. The warning threshold is 2.5x the appropriate interval. So if your
backups happen every 4 hours, you'll receive an alert if they are
ever older than 10 hours. If your backups happen daily then
you'll receive an alert if they are ever more than 60 hours old.
And so on.
This alerting replaces the manual process of me being sent
excerpts of log files that say a customer's backups are failing,
then opening a support ticket with the customer to make them
aware.
If you receive this alert then your backups are definitely not
happening.
The alert looks like this:
From: nagios(a)bitfolk.com
Subject: ** PROBLEM alert - backup0.bitfolk.com/Backup age youraccount is CRITICAL **
***** Nagios *****
Notification Type: PROBLEM
Service: Backup age youraccount
Host: backup0.bitfolk.com
Address: 85.119.80.240
State: CRITICAL
Date/Time: Tue Jan 31 12:37:38 UTC 2012
Additional Info:
FILE_AGE CRITICAL: /data/backup/rsnapshot.6-7-4-6/hourly.0/85.119.82.121 is 16842912 seconds old and 4096 bytes
(Those who haven't had a successful backup run in the last couple
of days will have a huge number of seconds listed there because
the backup system was only modified to record last successful
contact recently)
- Backup space usage
This checks that your total backup space usage is not approaching
your current quota. The thresholds are 95% for a warning and 99%
for a critical.
This alerting replaces the manual process of me being warned about
customers who are exceeding their quota and then opening support
tickets with them to discuss what they want to do about it².
If you receive this alert then your backups are still happening,
but you're in danger of (or already are) using more than the
agreed space. If you exceed your quota then we may disable your
backups, so that would eventually cause the above backup age alert
to fire.
Please note that we can't update the measurement of how much space
you're using very often. Backup directories contain hundreds of
millions of files, many of which are copies of each other, but
it's not possible to tell without looking. Adding it all up takes
quite a long time and stresses disk IO quite badly. So we only
update quotas every day at best at the moment.
Also please note that since this is a backup system, deleting
files on your VPS does not immediately result in using less disk
space for backups. It would be a rather pointless backup system if
it threw away deleted files immediately. :) Anything that gets
backed up is going to be kept for as long as your chosen backup
schedule dictates, e.g. 6 months by default. If you have blown
your quota by accidentally allowing large amounts of data to be
backed up, you are still going to have to contact support to get
it deleted.
The alert looks like this:
From: nagios(a)bitfolk.com
Subject: ** PROBLEM alert - backup2.bitfolk.com/Backup space usage youraccount is WARNING **
***** Nagios *****
Notification Type: PROBLEM
Service: Backup space usage youraccount
Host: backup2.bitfolk.com
Address: 85.119.80.230
State: WARNING
Date/Time: Tue Jan 31 15:52:28 UTC 2012
Additional Info:
WARNING 98.50% (394/400MiB) used
It is possible for the usage to go above 100% because we do allow
you to go over your quota for short periods of time.
Cheers,
Andy
¹ "Successful" as in, rsync connected to your host, did some stuff
and then exited with a non-error exit code. It does not
necessarily mean that what you think should be backed up is being
backed up. As with any backup solution you need to assure yourself
on a regular basis that it's doing what you expect.
² Generally one or more of:
- Buy some more disk space for backups
- Backup fewer files
- Backup less often
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
