Hi,
If you do not use BitFolk's Entropy service and have no interest in
doing so then this email will be of little interest to you can be
safely ignored.
If you haven't heard about the Entropy service before, please see:
https://tools.bitfolk.com/wiki/Entropy
If you *do* use the Entropy service though, I'm interested to know
what software you have that actually uses /dev/random (and not
/dev/urandom).
Some background to this question:
To provide the Entropy service we use hardware entropy generators,
currently exclusively a pair of EntropyKeys manufactured by a UK
company called Simtec Electronics Ltd.
Despite the fact that these were extremely popular little devices
(compared to other fairly niche little gadgets), Simtec always had a
supply problem and then Simtec imploded as a company, so as far as I
know these are now impossible to obtain, the IP is lost forever etc.
Although I have one spare EntropyKey ready to put in service should
one of the two in service ever die (I've not experienced that yet),
that left me slightly worried as to what I'd do if I needed to get
more.
Then I saw the OneRNG kickstarter, and decided to pledge. So now I
have 5 of (the internal USB version of) these:
http://onerng.info/
I've not yet gone any further than verifying that they keep the
entropy pool full on the machine they're plugged into, but that's
good enough for now. Could be a decade before one of my existing
EntropyKeys dies.
I have since heard that this device proved far more popular than its
manufacturer expected (sense a theme?) and they're now extremely
difficult to get hold of because they need to get a new batch made
in China. I've had multiple people contacting me on the basis of a
tweet I did about getting these, asking me to sell them mine (which
I would, but they didn't want internal USB).
The point I'm trying to make here is that the world of hardware
random number generators is not one with reliable supply lines,
unless you want to spend a fortune on some black box.
So when I came across:
http://www.2uo.de/myths-about-urandom/
I was sad that the nerdery that is the Entropy service may be
misguided, but also happy with the possibility that I might never
have to source a hardware RNG again.
Let's just take the argument posited by the article, that all
(Linux) software should just learn to love /dev/urandom¹, as true.
If you don't agree with this claim, you are disagreeing with some
pretty big names in crypto. The Hacker News commentary on the
article may also prove of interest:
https://news.ycombinator.com/item?id=10149019
At the very least, I feel the Entropy article on the BitFolk Wiki
needs an update in light of this. To justify the service's
existence, if nothing else.
Going further, the question becomes, well, what software is there in
existence that forces use of /dev/random with no configuration that
would allow otherwise? Because even if we agree that all software
*should* be using urandom, if some popular software *refuses* to
without recompile, then we're still going to have to provide an
Entropy service, because doing so is easier than running
non-packaged software.
So Entropy service users, what have you got that uses /dev/random?
Cheers,
Andy
¹ A more correct summary of it is probably, "urandom is fine all the
time except for on initial boot when a small amount of entropy
from outside the CSPRNG is desirable."
On shutdown all fairly modern Linuxes save the current entropy
pool to the filesystem and load it up from there on boot, so it's
only essential on first boot.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Just some quick feedback on the do-release-update to Ubuntu 16.04.1.
I thought my install of 14.04 was pretty standard, and it turns out I was
wrong. Nothing went so bad that I had to nuke it from orbit, but it's been
a couple of hours of repair work spread over a couple of days.
Firstly, immediately after the update (and restart) systemd hosed pid 1 so
the server wouldn't easily restart - I began to suspect something was up
when systemctl wasn't controlling services, but service <blah> restart (et
al) was still working so things didn't twig immediately. This only really
came to light when I tried to restart the server after restoring everything
else (see below) and that wasn't having it. Google came to the rescue,
there's a way to forcibly reboot using systemctl even when pid 1 is hosed,
and what was basically restart #2 got things happy again.
Not everything PHP 5 was automatically upgraded to PHP 7.0 (didn't have
that much extra over -common, but enough that my website was down for 15
minutes or so). I had been tracking Nginx HEAD via their PPA, so it was a
(very) minor downgrade to track the Ubuntu version (to avoid future
problems, hopefully). The fly in the ointment turned out to be mysql; I had
been using percona 5.6 (via PPA), but knew I wanted to track "stock" 5.7
(which the do--update did for me), but it zapped the config back to
defaults, causing me two days to wondering why Codeguard couldn't back up
my database - turns out that the default config only listens on 127.0.0.1
now... You learn as you go in my world.
Otherwise, a nice enough experience, and I'm loving the speed of PHP 7.0.
Kind regards
Murray Crane
Hi,
Being able to store multiple contacts has been a long-requested
feature:
https://tools.bitfolk.com/redmine/issues/22
The first phase of this work has now been deployed to the panel web
site. That's just the ability to store and edit multiple contact
records.
If you visit:
https://panel.bitfolk.com/account/contacts/#toc-address-book
you'll be able to add/change/remove contact records.
These aren't very useful though until the other parts of BitFolk's
infrastructure can make use of them, and most of that work is still
to come.
The most common use of a different contact is for
monitoring/alerting, so that has been implemented first. You can
control who gets alerts by creating contact records and assigning
them to the "Alerting" role.
For those of you who have monitoring set up:
- If you have no contacts assigned to the "Alerting" role then
alerts will go to your main customer record.
- If you have at least one contact in the "Alerting" role then
alerts will go there instead. Each contact will get a copy.
- Everyone who already had a different email address set in our
monitoring has had a contact created and assigned to the
"Alerting" role for this purpose, so no action needs to be taken
to keep things behaving the same as they did before.
Other common requests for alternate contact details were for billing
and data transfer reports. These roles will be added as soon as the
relevant BitFolk systems are made to support them.
In the mean time I would suggest one useful thing to do is for
people who care about being contacted in an emergency to add at
least one contact to the "emergency" role, with a mobile phone
number and/or email address that is not hosted on your VPS. We would
only use those details to contact you if we really needed to, when
your main email address does not seem to be working.
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,
TL;DR version:
A few customers will see new bandwidth graphs appearing in their
Cacti, which can be found at https://tools.bitfolk.com/cacti/
The already-existing graphs will continue to run for a while and
then will cease to be updated. The new graph will become your
primary bandwidth graph.
This is because some high-bandwidth users need to have graphs based
on 64-bit counters, not 32-bit, in order to accurately measure
bandwidth use.
It may result in slightly higher values being reported in Cacti, but
this is merely correcting previous under-reporting. Monthly totals
as presented in our emailed data transfer reports were/are correct.
Longer version:
While investigating some recent discrepancies between the different
systems we have for accounting for customer data transfer, I
discovered that all of our bandwidth graphs were using 32-bit SNMP
counters.
A 32-bit unsigned counter has a maximum value of 4,294,967,295. With
5 minute sampling, that means that an interface seeing around
114Megabit/sec of traffic will reach 4,294,967,295 and wrap around
to zero again before the counter can be read.
As a result, a few customers who routinely use large amounts of
bandwidth have Cacti graphs that are under-reporting their usage.
Here is an example of a graph based on 32-bit counters:
http://tools.bitfolk.com/cacti/graph_5062.html
Here is the same interface graphed from 64-bit counters:
http://tools.bitfolk.com/cacti/graph_5617.html
You can see that the first daily graph has several drop-outs around
high bandwidth periods, and that the total data transferred in the
last 24 hours is under-reported in the first daily graphs.
I will not go through and replace every bandwidth graph with new
ones, only those of customers who are seen to be transferring more
than ~4.2GB in 5 minutes. So if you see a new graph appearing, this
is why.
Measuring 32-bit counters on a 2x 1 gigabit interface was of course
a very silly oversight, and it is now apparent that even the virtual
network device in an individual VPS has no problem exceeding
~114Mbit/s.
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,
By now you should have all received notification of the scheduled
maintenance that will be taking place in the early hours of the
morning (UK time) on 2016-09-02, 03 and 05.
This is the result of an embargoed security update that we have been
made aware of today.
If you have not seen the notification which was sent directly to the
email address we have for you at:
https://panel.bitfolk.com/account/contacts/
please first check your spam folders, etc., and failing that please
do let us know.
Also if you have any questions I am happy to answer these either on
the users mailing list or directly in a private ticket at
support(a)bitfolk.com.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
