By now you have probably been made aware of a security deficiency in
the design of SSL 3.0 which has been dubbed "POODLE". Here's some
I am writing to you because, unless this script is flawed:
then there are over 150 customer IPs at BitFolk that are still
supporting SSLv3 on port 443.
I don't intend to open tickets with individual customers and nag
until this is fixed, because it's very time-consuming to do that.
To check if your server needs reconfiguring:
To disable SSLv3 on Apache newer than 2.2:
Add "-SSLv3" to the end of the "SSLProtocol" line which can
normally be found in /etc/apache2/mods-available/ssl.conf on
Debian and Ubuntu.
On Apache 2.2 or older:
You'll need to use "SSLProtocol TLSv1"
Make sure that the "ssl_protocols" line does not contain the
string "SSLv3". e.g.:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
http://bitfolk.com/ -- No-nonsense VPS hosting
announce mailing list
Anyone else seeing system time oddness at dunkel?
By the end of October I had one of my VMs moved to dunkel. Since then
there have been five occasions where my monitoring have reported that
that VM's system time being way off.
Actually, on all occasions the reported offset was the same: -46.87s.
On all occasions the system time was afterwards restored by ntpd.
Based on my monitoring, this is when the time lapses happened.
Tue Nov 4 00:37:20 UTC
Sun Nov 9 09:52:21 UTC
Thu Nov 20 01:52:29 UTC
Sun Nov 23 21:37:31 UTC
Sat Dec 13 00:12:26 UTC
I am talking to a friend of mine about heroku vs AWS vs other hosting.
I am trying to find out how many tenants each host has on bitfolk but
I'm coming up short. I'm sure I saw this on the wiki a while ago but
simply cannot find it now.
Does anyone have a quick answer to this without bothering Andy?
Just installed a kernel update and noticed that the time was way out
upon reboot, until ntpdate ran:
Dec 5 15:41:24 osprey xinetd: Started working: 1 available service
Dec 5 15:41:24 osprey snmpd: NET-SNMP version 184.108.40.206
Dec 5 11:49:22 osprey ntpdate: step time server 220.127.116.11
offset -13923.906495 sec
Is this a problem with the host server (kahlua) or my VM?