Hi,
TL;DR: Bitcoin payments are broken, hopefully fixed today or
tomorrow. If you need to make a payment that way please wait a
little bit. If your service will be terminated for non-payment
please contact support for an extension until it's fixed.
More detail:
It seems that our bitcoind is crashing, I think because I made the
mistake of running it as 32-bit (see repeated threads about the
death of 32-bit) and it now needs to allocate more memory than a
32-bit process can.
I could give it a 64-bit kernel but the bitcoind itself would still
be 32-bit so I'd have to recompile it as well. I'm instead going to
rebuild that host.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
>
> Date: Tue, 31 Dec 2019 21:46:57 +0000
> From: Conrad Wood <cnw(a)conradwood.net>
> It never ceases to amaze me how Andy can provide 24/7 all hours every
> day of the year 5-star support and maintenance.
> (I hope I am forgiven to suspect a 50-people strong support team, all
> called "Andy" :) )
>
Obviously you don't know that Andy is Chuck Norris's twin brother.
https://www.lifewire.com/best-chuck-norris-memes-4162016
Steve
>
Hi,
At some point between 16:00Z and 17:00Z today I'm going to upgrade
the rescue VM¹ image from Debian 9 (stretch, oldstable) to Debian 10
(buster, stable).
This will only take a few seconds, but as the rescue VM is an
NFS-mounted squashfs image, replacing the image will prevent all
currently running copies of the rescue VM from functioning.
If you are using the rescue VM at the time, you will start to see
I/O errors on its on root filesystem and will have to kill it and
start it again. At its next boot a new image based on Debian 10 will
load.
If you are or expect to be in the middle of something important with
the rescue VM between 16:00 and 17:00 then let us know and we'll
postpone the work.
Cheers,
Andy
¹ https://tools.bitfolk.com/wiki/Rescue
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
Briefly:
At around 2153Z today we started receiving alerts for basically
"everything" flapping up and down due to between 20 and 30% packet
loss. In short, this was due to a distributed denial of service
attack aimed at another customer of our colo provider. Around 2240Z
they deployed some mitigation and hopefully we don't see any more
issues.
TL;DR:
I'd only got as far as determining that it affected "everything"
before it stopped again shortly before 2200. It then started up
again around 2215 and I was able to see that it also affected our
colo provider.
I was able to make contact and they started investigating around
2215. There wasn't anything for me to do at this point except watch.
It was a large UDP DDoS, random source and destination ports.
At about 2240 they put in some mitigation. The degree to which you
were affected during this time will vary based on how your legit
traffic reached us (or didn't reach us).
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi All,
It has come to my attention - thanks Andy - that my IP6 configuration
may be wrong. My VPS is receiving IP6 traffic, but sending none, and is
(perhaps sometimes) unable to route to an IP6 address.
This is way beyond my pay grade, so I need some help here.
When I look in my cpanel, it says my IP6 address is
2001:ba8:1f1:f00d::/64
But ip a gives ....
ian@hobsoni:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:16:5e:00:04:89 brd ff:ff:ff:ff:ff:ff
inet 85.119.82.210/21 brd 85.119.87.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:ba8:1f1:f06e::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::216:5eff:fe00:489/64 scope link
valid_lft forever preferred_lft forever
ian@hobsoni:~$ ip -6 route show
2001:ba8:1f1:f06e::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via 2001:ba8:1f1:f06e::1 dev eth0 metric 1024 pref medium
ian@hobsoni:~$ ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:ba8:1f1:f06e::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::216:5eff:fe00:489/64 scope link
valid_lft forever preferred_lft forever
ian@hobsoni:~$
And here is the netplan config
ian@hobsoni:/etc/netplan$ cat 01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- "85.119.82.210/21"
- "2001:ba8:1f1:f00d::2/64"
gateway4: 85.119.80.1
gateway6: "2001:ba8:1f1:f00d::1"
nameservers:
addresses: [85.119.80.232 85.119.80.233]
ian@hobsoni:/etc/netplan$
I'm guessing that f06e is not f00d for netplan and its barfing on it.
(Sorry).
But I don't know which is correct.
Regards
Ian
--
Ian Hobson
Tel (+351) 910 418 473
Hi All,
A website on my VPS has been receiving HEAD requests,
which cause it to fail, and are cluttering up my error logs. They are
coming from IPs all over the place, but only a few (3 to 5) a day.
What would generate them?
How should the software respond?
Regards
Ian
--
Ian Hobson
Tel (+351) 910 418 473
Hi All,
I have had a user complain they got no response from a website on my
VPN. It appears that from about 9:07 until after 9:44 my front-end
(nginx) could not talk to the back-end (php). It cleared before I became
aware of the problem.
I can find nothing in the logs, other than the failed reads, so I am at
a loss to diagnose things.
Environment - The O/S is Ubuntu 18.04 LTS.
nginx is version 1.16.1 compiled to include a couple of extra
modules...standard stuff plus...
--with-pcre=../pcre-8.42 \
--with-zlib=../zlib-1.2.11 \
--add-module=../nchan-1.2.6
nginx talks to php7.2-fpm using fastcgi-pass to 127.0.0.1:9000.
Any ideas gratefully received!
Regards
Ian
--
Ian Hobson
--
This email has been checked for viruses by AVG.
https://www.avg.com
