Hello,
Sadly today we've been made aware of another security issue that's
going to have to be patched, which means once again we have to
reboot everything.
It is a pity they couldn't have held the last one back for a week in
which case we'd have been able to roll the two patches together, but
they have a schedule for disclosure that they have to stick to.
So, this set of reboots is most likely to take place in the early
hours of the morning on 5/6/7 May. In the next couple of days we
will send out direct mails to all customers to let you know exactly
when your one hour maintenance window will be.
We should be able to use suspend/restore on this one so those who
have indicated that they want that should see that happen. You can
set that from:
<https://panel.bitfolk.com/account/config/>
For the benefit of new customers joining us what all this means is
that some time during the one hour maintenance window that you'll be
informed of individually by direct email, we will:
- Suspend to disk all the VPSes that have opted for that
- Shut down the rest cleanly
- Reboot the server into the patched hypervisor
- Restore the suspended VPSes
- Boot the rest
Although the maintenance window for each server is one hour long,
the work generally takes about 15 minutes.
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,
Unfortunately a flaw has been discovered in the Xen hypervisor that
has security implications, so we're going to have to apply a fix and
reboot everything. This is likely to take place between 21 and 23
April. In the next couple of days we will send out direct mails to
all customers to let you know exactly when your one hour maintenance
window will be.
We should be able to use suspend/restore on this one so those who
have indicated that they want that should see that happen. You can
set that from:
<https://panel.bitfolk.com/account/config/>
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
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,
I've added an Ubuntu 18.04 LTS installer to our Xen Shell, so it's
now available for self-install. More info about self-install:
<https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installer>
So, the command is "install ubuntu_bionic". If you don't see it,
make sure you are running version v1.48bitfolk46 of the Xen Shell as
the Xen Shell stays running if you connected to it before.
Please note:
- Obviously this is still pre-release for 18.04. I have only tested
it so far as installing it, booting it and connecting to it with
SSH. I would be interested to know of your progress if you use it.
- If you already are running Ubuntu you could just
do-release-upgrade into this as normal.
- As ever, if you'd like to perform a self-install but need to keep
your existing VPS running for a while, we can offer a new account
free for 2 weeks for you to perform your migration:
<https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS>
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,
Having run what appears to be a successful upgrade from Ubuntu 14.04 to
16.04 (yes, yes I know living in the past) I've hit a problem.
My VPS won't reboot.
$ sudo shutdown -r now
Gives:
Failed to start reboot.target: Connection timed out
See system logs and 'systemctl status reboot.target' for details.
Couldn't find an alternative telinit implementation to spawn.
failed to run telinit 6 for upstart fallback
Failed to talk to init daemon.
and trying to shut down via the xen console I get:
xen-shell> shutdown
Shutting down instance: <vpsname>
Shutting down domain <number>
Waiting for 1 domains
and the VPS stays up.
Any suggestions before I hit it with a xen console "destroy"?
Andy
--
Andrew Ransom
<aransom(a)gmail.com>
I have finally set up a server with Debian Stretch rather than Jessie.
The main 'you have to change everything' was around the move from PHP5
to PHP7.
I still want to use the -fpm version of PHP because you don't need to
load an entire PHP interpreter to serve JPEGs.
I still want to stop bots trying to bruteforce WordPress logins.
* Before (Jessie):
Apache calls php-fpm via the fastcgi module in
/etc/apache2/sites-available/example.com.conf -
<IfModule mod_fastcgi.c>
AddType application/x-httpd-fastphp5 .php
Action application/x-httpd-fastphp5 /php5-fcgi
Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi_examplesite
FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi_examplesite -socket
/var/run/php5-fpm_exampleuser.sock -pass-header Authorization
</IfModule>
and restricts access to wp-login.php in the site's .htaccess file -
<Files "wp-login.php">
AuthName "Message that Firefox shows but Chromium no longer does!"
AuthType Basic
AuthUserFile /home/exampleuser/.htpasswd
Require valid-user
</Files>
.. and it works! Anyone going to example.com/wp-login.php gets asked for
a username and password by Apache before it will run it.
* After (Stretch):
Because of the changes between the two, Apache now calls php-fpm via the
proxy-fcgi module in /etc/apache2/sites-available/example.com.conf -
ProxyPassMatch ^/(.*\.php(/.*)?)$
unix:/run/php/php7.0-fpm_exampleuser.sock|fcgi://localhost/home/exampleuser/public_html/
and with the same .htaccess file, it *doesn't* trigger on access to
wp-login.php because it's a .php file, ProxyPass gets there first and
just runs it without checking anywhere else if it should.
The method used on Jessie isn't particularly great, but because the
enemy is dumb bots, it doesn't have to be!
For the past few years, it's worked to dramatically reduce the impact of
the endless attempts to bruteforce access to anything running WordPress
- unlike the plugins that do something about the appalling security of a
standard WordPress installation* it didn't need to run PHP or touch the
database at all.
I do also have fail2ban watching wp-login.php and blocking anyone who
hammers it, but the next time there's a WordPress bot storm, it will
affect the server because of all the PHP and database access.
Any suggestions? I don't want to have to rename or move wp-login.php and
I don't want to have compile PHP5.4 from source either...
Ian
* "Allowing infinite attempts to login without blocking the IP address
after so many failures or even notifying the site's owner? What could
/possibly/ be the problem with that?? In fact, let's make it even easier
by allowing hundreds of attempts to be made at once!!!"
Hi,
The current BitFolk rescue VM as described in
<https://tools.bitfolk.com/wiki/Rescue> is based on Debian wheezy
(7.0) and as such is starting to get too old to be useful.
I've set up a newer one based on Debian stretch (9.0), which can be
accessed by using the "rescue-dev" command (instead of just
"rescue").
Next time you have cause to use the rescue environment, if you could
give "rescue-dev" a go and let me know of any issues, that would be
helpful. It should work just the same, except for being newer.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
