Has anyone successfully used the version of certbot in jessie-backports
to install https certificates from letsencrypt on Apache?
The reason for asking is that I haven't :)
It doesn't help that the version there is older than the one covered by
the documentation at <https://certbot.eff.org/docs/using.html> - there's
no 'certificates' command, for example.
Ian
Hi all,
I was looking to upgrade my VPS to the latest Ubuntu release this afternoon but ran across a problem. Whenever I try to run "do-release-upgrade” I receive the following error:
Checking for a new Ubuntu release
Get:1 Upgrade tool signature [836 B]
Get:2 Upgrade tool [1,265 kB]
Fetched 1,266 kB in 0s (0 B/s)
authenticate 'xenial.tar.gz' against 'xenial.tar.gz.gpg'
gpg exited 1
Debug information:
gpg: Signature made Wed 07 Dec 2016 09:10:01 GMT using RSA key ID C0B21F32
gpg: /tmp/ubuntu-release-upgrader-r7c80csz/trustdb.gpg: trustdb created
gpg: BAD signature from "Ubuntu Archive Automatic Signing Key (2012) <ftpmaster(a)ubuntu.com<mailto:ftpmaster@ubuntu.com>>"
Authentication failed
Authenticating the upgrade failed. There may be a problem with the network or with the server.
Searching online<http://askubuntu.com/questions/842706/how-to-upgrade-ubuntu-if-i-get-authen…>, this looks like it could be a problem with the xenial.tar.gz file on the local repo cache. Has anyone else had similar problems, and if so, how did you resolve them?
I suppose beyond that, has anyone successfully upgraded their Ubuntu VPS to 16.04? Were there any problems along the way?
Thanks,
Paul
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
Hello,
Unfortunately some more serious security issues have been uncovered
in Xen which affect versions and configurations which we have
deployed.
These were pre-disclosed yesterday, with full public disclosure
coming two weeks later on Thursday 12 October as normal.
So, we're going to have to patch everything and reboot before then.
This will very likely be taking place over three nights starting in
the early hours (BST) of Tuesday 10 October, but we will be sending
out an individual email to every customer confirming when they will
be affected.
For those unaware of what this entails, it means that at some point
within an hour-long maintenance window we will shut your VPS down
cleanly as the machine it's on is shut down, and then boot it again
once the machine has booted up. It typically takes 5-10 minutes.
As a reminder, you are able to opt for your VPS to be suspended to
and restored from SSD if you don't like losing program state:
https://tools.bitfolk.com/wiki/Suspend_and_restore
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,
Around 0920Z today, monitoring notified me that host "snaps" wasn't
responding.
I could get no response over the network and even the serial console
was completely unresponsive. I had no option but to hard power cycle
it.
It is now booted again and all customer VPSes on it should be
started again but I do not yet know the reason for the outage and am
still investigating.
Apologies for the disruption.
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,
As those of you on the "users" list may have seen, I've been making
some necessary changes to our Direct Debit integration with
GoCardless:
https://lists.bitfolk.com/lurker/message/20170920.113352.8bfd6684.en.html
On 31 October GoCardless are retiring the original API we integrated
with in 2012 so I've had to make the changes necessary to move to
their current "Pro" API.
Sadly there aren't any really any new features to talk about, hence
my delay in taking care of this. One thing I do need to mention is
that the capped mandates of the legacy API are no longer supported.
All Direct debit mandates set up through the legacy API were capped
to the exact amount per time period for your recurring VPS bill,
e.g. £10.79 per month, £29.64 per quarter, etc. In hindsight this
was a bad idea as it caused problems as soon as anyone upgraded or
tried to move their payment date earlier.
An awkward consequence of this is that pre-existing Direct Debit
mandates will still respect the caps set on them but there is no
longer any way for us to query those caps. Whereas before we could
tell that a charge might fail today but succeed tomorrow, and thus
would be happy enough to wait until tomorrow to submit it, we now
can't tell at all. We have to submit the charge and see if it fails.
And if it does fail, we can't tell the difference between "too soon"
and "too much". This is unfortunate because "too soon" is of course
a temporary issue, but "too much" is a permanent one.
I decided not to cancel everyone's Direct Debit mandates because
this is still a relatively rare problem: it only becomes an issue if
you upgrade your VPS or try to pay a one-off invoice, which then
causes the cap to be exceeded the next time your scheduled payment
tries to be charged.
Instead I've decided that we will just catch the "cap exceeded"
error and ask you to cancel and re-authorise on a case by case
basis. To assist with that I've made it so you can cancel your own
Direct Debit from the panel.
I whinged some more about this here:
http://strugglers.net/~andy/blog/2017/09/21/tricky-issues-when-upgrading-to…
and wrote some more about it here:
https://tools.bitfolk.com/wiki/Direct_Debit#Legacy_Integration
As before you can fiddle with the Direct Debit stuff from the
Billing section of the Panel:
https://panel.bitfolk.com/account/billing/
It's been live and taking payments for about 5 days now, but if
anyone has any issues with it of course do let me know. And I
welcome anyone with a UK bank account to switch to it as it is still
the best payment method. :)
Speaking of which: there was some hope that we could start taking
Direct Debits from customers with bank accounts in EUR and SEK, as
the Pro API does supports that. It turns out though that this also
requires BitFolk to have bank accounts in those currencies and to
also bill in those currencies. That's not something that I want to
do in the foreseeable future so instead I will work on doing
recurring payments through Stripe (credit/debit cards).
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,
On 31 October our Direct Debit payment provider will be retiring its
v1 API (now called legacy). I believe I've made the changes
necessary to switch to the new API, but I would like some volunteers
to help test it out before I put live payments through it.
If you are currently paying by Direct Debit (or are willing to start
doing so) and happy to help out with some testing, please could you
reply off-list? If you don't have an invoice coming up soon then I
will probably want to trigger some small charges that will get
credited to your account.
Unfortunately the new API doesn't come with much in the way of
improvements neither for customers or for BitFolk: although it does
support payments in EUR and SEK, it requires BitFolk to have bank
accounts denominated in those currencies and bill in those
currencies, which isn't something I want to do at the moment. Also
there is a new minimum transaction fee of £0.20.
There's no choice if I want to keep accepting Direct Debit payments
though, which I very much do.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
Unfortunately some serious security issues have been uncovered in
Xen, which affect versions and configurations which we have deployed.
These were pre-disclosed today, with full public disclosure coming
on Tuesday 12 September as normal.
So, we're going to have to patch everything and reboot before then.
This will very likely be taking place over three nights starting in
the early hours (BST) of Sunday 10 September, but we will be sending
out an individual email to every customer confirming when they will
be affected.
For those unaware of what this entails, it means that at some point
within an hour-long maintenance window assigned to your VPS we will
shut your VPS down cleanly as the machine it's on is shut down, and
then boot it again once the machine has booted up. It typically
takes 5-10 minutes.
If you wish you can opt for your VPS to be suspended to and restored
from SSD if you don't like losing program state:
https://tools.bitfolk.com/wiki/Suspend_and_restore
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,
We were recently made aware that our Cacti¹ bandwidth graphs for a
particular customer were dramatically different from reality.
On investigation I realised that it was a bug in the Linux kernel
where it wasn't using 64-bit counters for Xen backend network
devices. As a result for readings above ~228Mbit/s the counter was
wrapping twice and reporting incorrect values on an SNMP read (as
used by Cacti).
This is a fairly minor issue because we do not use SNMP counters for
billing. It does mean that if your VPS has ever done more than about
228Mbit/s average in a 5 minute period that Cacti won't be showing
it properly.
The kernel bug has since been fixed but deploying a fixed version
would involve using a self-compiled² backports kernel. I am not
going to do this because I haven't tested it enough yet.
Instead I have identified the 30 or so customers that have ever
recorded that much bandwidth use in the last 12 months and am adding
new bandwidth graphs for you, using 1-minute polling. Also new
customers will have the 1-minute resolution graphs. That should be
safe to about 1.1Gbit/s.
So, if you are looking at Cacti and see you now have two bandwidth
graphs with one cutting off where the other began, this is the
reason why.
I wrote a blog article about this at:
http://strugglers.net/~andy/blog/2017/09/03/when-is-a-64-bit-counter-not-a-…
Cheers,
Andy
¹ https://tools.bitfolk.com/cacti/ - Log in with your usual BitFolk credentials
² We already use self-compiled kernels based on Debian kernel
packages, because some security patches have not yet made it into
Debian's packages. Building the kernel isn't the problem, it's
testing it well enough.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
