I got a warning email saying that c.authns.bitfolk.com was suffering s
critical error, then very soon afterwards an email saying it was recovered.
I did a quick check with intodns.com and all was well except this
Same GlueLooks like the A records (the GLUE) got from the parent zone
check are different than the ones got from your nameservers. You have to
make sure your parent server has the same NS records for your zone as you
do.I detected some problems as follows:
For *c.authns.bitfolk.com* the parent reported: *['209.237.247.198']* and
your nameservers reported: *['173.255.227.192']*
Everytime I refresh it reports slightly differently with server c always
reported as wrong sometimes all three
Same Glue
Looks like the A records (the GLUE) got from the parent zone check are
different than the ones got from your nameservers. You have to make sure
your parent server has the same NS records for your zone as you do.I
detected some problems as follows:
For *c.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and
your nameservers reported: *['173.255.227.192']*
For *a.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and
your nameservers reported: *['85.119.80.222']*
For *b.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and
your nameservers reported: *['209.237.247.198']*
I assume there is some work going on with the servers as my domain is
resolving
Keith
--
Keith Williams
Of those who say nothing, few are silent.
- Thomas Neill
I'm sick of following my dreams. I'm just going to ask them where they're
going and hook up with them later.
- Mitch Hedberg
ทำดีได้ดี ทำชั่วไดชั่ว
I can picture in my mind a world without war, a world without hate. And I
can picture us attacking that world, because they'd never expect it.
- Jack Handey
Hello,
If you don't make use of BitFolk's secondary DNS service then you
can ignore this email as it has no impact on you.
c.authns.bitfolk.com has been renumbered:
209.20.91.73 → 173.255.227.192
2001:4978:f:392::2 → 2600:3c03::31:2053
This actually has nothing to do with BitFolk's renumbering.
c.authns used to be hosted at Slicehost which recently got bought
by Rackspace, and they are also renumbering.
Most people don't need to do anything. The glue record for
c.authns.bitfolk.com has been updated so over the next couple of
days the new IP will start being used.
If you have made your own DNS records that pointed at 209.20.91.73
or 2001:4978:f:392::2 (for example if you made nameserver host
names inside your own domain(s)) then you will need to update them.
It is recommended not to use such names because of the need to
change them in so many places.
You may also have ACLs that allow zone transfer from 209.20.91.73.
These normally don't get used since the BitFolk nameservers try to do
zone transfer from each other first. If you do have such an ACL then
you will need to update it.
209.20.91.73 and 2001:4978:f:392::2 will go away on 19th March.
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 all,
thanks for everyone's response to my wiki proposal. I hadn't intended a flame war, and may respond selectively at a future date, when for instance, I am not faced with a puzzle, as follows.
dig returns the correct value 85.y on my VPS.
dig returns the old address 212.x elsewhere (at work).
Should I be concerned? I must access the ethernet address to my VPS--not the name--from 'elsewhere'. I changed bind at least 24h ago. Is the 'expire' time* of 7 days (current setting) responsible for this, or is my problem more insidious?
*the third entry after the 'serial number' in a bind config
Thanks for any/all replies.
Cheers,
Max
Dear customer,
[ Apologies if you've received duplicate copies of this email;
we felt it was of sufficient importance to send direct to the
contacts for each account. ]
If you've been following our mailing lists you'll know that the time
has come where we need you to change the IP address(es) associated
with your VPS.
Basically:
- For each IP address on your VPS you need to enable a new address,
which has already been routed to you.
- You then need to reconfigure your services to use only the new IP
addresses.
- Finally you need to disable the old IP addresses.
Full information on what you need to do can be found here:
https://tools.bitfolk.com/wiki/Renumbering_for_customers
The next time you need to reboot your VPS you should take care to
instead shut it down and boot it again from your Xen Shell,
otherwise you will lose the routes to the new IP addresses that have
been added.
The old IP addresses will be disabled approximately *three months*
from now, so if you don't make these changes before then YOU WILL
EXPERIENCE A LOSS OF SERVICE.
Therefore if you have any questions please do not hesitate to ask,
preferably on our users list:
https://lists.bitfolk.com/mailman/listinfo/users
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,
Due to a punishing workload, I left my renumbering to the last minute
and it's not worked right.
Here is my new /etc/network/interfaces:
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet static
> address 85.119.82.73
> netmask 255.255.248.0
> gateway 85.119.80.1
>
> auto eth0:1
> iface eth0:1 inet static
> address 85.119.82.67
> netmask 255.255.255.255
>
> auto eth0:2
> iface eth0:2 inet static
> address 212.13.194.73
> netmask 255.255.255.255
>
> auto eth0:3
> iface eth0:3 inet static
> address 212.13.194.67
> netmask 255.255.255.255
ip -4 addr show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> inet 85.119.82.73/21 brd 85.119.87.255 scope global eth0
> inet 85.119.82.67/32 brd 85.255.255.255 scope global eth0:1
> inet 212.13.194.73/32 brd 212.13.194.255 scope global eth0:2
> inet 212.13.194.67/32 brd 212.13.194.255 scope global eth0:3
ip -4 route show
> 10.26.0.2 dev tun0 proto kernel scope link src 10.26.0.1
> 10.26.0.0/24 via 10.26.0.2 dev tun0
> 85.119.80.0/21 dev eth0 proto kernel scope link src 85.119.82.73
> default via 85.119.80.1 dev eth0
/etc/resolv.conf
> nameserver 85.119.80.232
> nameserver 85.119.80.233
I can still ping and ssh the old 212 addresses. When I'm logged in, I
can't ping 85.119.80.1 and dig says that there are no DNS servers
available. I can ping both 212 addresses from outside but neither of the
85 addresses.
I'd be really grateful if someone would point out my stupid and obvious
mistake.
Thanks,
Paul.
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
Hi,
Some of this was easy (changing where the slave DNSes got their info
from was a simple sed search and replace) and some tedious (changing all
the master DNS where because of needing to change the serial number for
all of them, this was done by hand via a control panel - if there was an
easier way, I am not sure I want to know now :) )
The one thing not mentioned on the wiki is that doing
> grep -r 212.13.19 *
in /etc now comes up with one hit, in ntp.conf:
> # and admin.curacao.bitfolk.com (nagios)
> restrict 212.13.194.71
so I changed that to 85.119.80.238 and 85.119.80.244 per the customer
information page on the website and restarted ntp.
Now I think it's just a case of waiting for the rest of the net to
notice the DNS changes...
Ian
