BitFolk Users January 2018

users@mailman.bitfolk.com

5 participants
6 discussions

by Ian

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

6 years, 8 months

Problems upgrading to Ubuntu Xenial Xerus (16.04)

by Paul Lewis

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

6 years, 8 months

Latest CentOS 7 kernel doesn't boot under Xen PV - workaround available

by Andy Smith

Hi, I haven't had chance to personally check this out but apparently the latest CentOS 7 kernel package doesn't boot under Xen PV: https://bugs.centos.org/view.php?id=13763 This may be highly relevant to you because an update was just pushed out for the KPTI feature (to help mitigate Spectre/Meltdown etc in Linux). As mentioned in that bug report, there are patches to fix this but they haven't yet been applied to the main CentOS kernel package. In the mean time you can use the kernel package from the CentOSPlus repository which does have this fix and the KPTI one. https://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus All of this was researched by a customer having the problem today and it resolved it for them. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

6 years, 10 months

Dear Entropy service users, what software uses /dev/random?

by Andy Smith

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

6 years, 10 months

Problem to Access my Webservers

by Samuel Bächler

Dear All First of all I like to mention that I do not think that my problem has got something to do with bitfolks infrastructure since access from my mobile phone seems to work fine (mobile internet access). Connected to the internet through init7.net I cannot access https://bitfolk.com using Chrome or Firefox. I can not 'ssh me(a)me.vps.bitfolk.com'. 'wget http://hobley.ch' (a webserver of mine at bitfolk) or 'curl -I http://hobley.ch' does respond if I try several times. I can reach bitfolk.com and hobley.ch using a tor browser. Inputs on what could cause this are welcome. Regards, Sam

6 years, 11 months

Spectre / Meltdown CPU bugs - short notice reboots will be needed, little other info yet

by Andy Smith

Hello, As you're probably aware, it turns out that pretty much every CPU made in the last 10 years is broken, and while this affects almost all computers, this is going to have a particularly nasty effect on virtualisation providers such as BitFolk. The Xen project last night released the first version of their advisory which is XSA-254: https://xenbits.xen.org/xsa/advisory-254.html This is with no embargo, because the original embargo had to be abandoned by the discoverers of the bugs. As you can see, unfortunately the Xen project have no resolutions for any of this available as yet. There's three different issues here: 1. SP1/Spectre (CVE-2017-5753) 2. SP2/Spectre (CVE-2017-5715) 3. SP3/Meltdown (CVE-2017-5754) There isn't any known resolution for (1) yet. Xen are working on mitigations for (2). It's possible to avoid (3) by going to HVM mode, but that is a huge change that brings other problems with it. It can also be avoided by running in PVH mode, but very few guest kernels will be new enough to support that. Xen are hoping to come up with a way to run PV-inside-PVH but they're not ready with that yet. There will likely be other strategies to fix or mitigate these issues in the coming days. So I'm afraid there currently is no concrete plan because there is very little information available yet. All I can tell you is that there will be a need for short-notice reboots to apply relevant fixes. I will post again when there is any useful information. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

6 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users January 2018