>
> I'm writing to you because I'm not sure of the best way to notify
> customers about this work and would like you to give me some
> feedback on how you'd prefer the communication to work.
>
I am strictly amateur with nothing mission critical. I will not have any
problems with whatever you decide to do.
Steve
>
Morning,
Can anyone help me straighten out MariaDB?
Background: I let the disk get completely full on my VPS (oops!). Bought
another 5GB but the system was pretty unresponsive due to lack of disk
space. Rebooted, thinking to dump some old kernels to free space, had to do
this in Xen and it took an absolute age to shut down. Booted and resized
disk successfully, but...
*The issue: *MariaDB will not start.Presumably did not shut down happily.
Returns:
Job for mariadb.service failed because the control process exited with
error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
Looking at systemctl status mariadb.service:
mariadb.service - MariaDB 10.1.47 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor
preset: enabled)
Active: failed (Result: exit-code) since Fri 2021-03-12 10:17:53 UTC;
10min ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 11875 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS
$_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Process: 11801 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ]
&& VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -
Process: 11799 ExecStartPre=/bin/sh -c systemctl unset-environment
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 11798 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d
/var/run/mysqld (code=exited, status=0/SUCCESS)
Main PID: 11875 (code=exited, status=1/FAILURE)
Status: "MariaDB server is down"
Webmin also returns this fault code when prompted to start the DB:
DBI connect failed : Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock'
Running Ubuntu 18.04. User skill level: probably just about enough
knowledge to be dangerous.
Cheers,
Andy
Hi,
In the last couple of hours I unfortunately had to reboot host
"talisker" including full shutdown & boot of all the VMs on it.
It seems from logs that problems started at approximately 01:00. The
first alerts came in at 01:22 when customers started trying to
reboot their VMs. Symptoms for customers were stalling of tasks,
unable to shut down properly, unable to boot again after forcibly
shutting down.
I spent some time trying to investigate but it wasn't making things
any better so by about 02:30 I decided to issue a reboot. Customer
VMs were all back up and running by about 02:45.
I continue to investigate what the root cause may be and am keeping
a close eye on things.
Apologies for the disruption this will have caused you.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hello,
After many years of abandonment we have relaunched Planet BitFolk, a
blog aggregator that syndicates articles by BitFolk-adjacent persons
and things:
https://planet.bitfolk.com/
There is more information about it here:
https://tools.bitfolk.com/wiki/Planet_Bitfolk
If you would like to add yourself please submit a pull request or
whatever:
https://github.com/bitfolk/planet-bitfolk
It would be really good if you did, because at the moment it's a bit
Planet Popey. 😀
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
A long time ago I used to have a script that made a stacked graph of
which Linux distros customers chose over time. It was fun but the
script was horrible and hard to keep up to date, so I stopped in
2013:
https://ibin.co/5rTylhYv24am.png
I made a new one now in Grafana:
https://bitfolk.com/techspec.html#toc_3_Distro_Toothpaste
It's not very interesting yet because there's only 1 day of data in
it, but now seems like a good time to remind you that you can change
what distribution you report at:
https://panel.bitfolk.com/account/
I recently added Slackware since I know there's a few of those now.
Also if you reinstalled with something else then it might be out of
date.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
I'm planning to install software on my VPS, which requires incoming UDP
on port 10000.
My iptables is set to allow incoming udp on that port, but it remains
closed to the outside world.
I've set up a simple listener on port 10000, then tested using a web
service for port checking, and I've tested using telnet from two other
locations.
"Unable to connect to remote host: Connection time out", says telnet.
Have I omitted to do something I should have done?
Ian.
Hi,
==TL;DR: version==
You can now perform a mostly-automated install of CentOS 8.x from
our Xen Shell:
https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installer
xen shell> install centos_8
==Full version==
Installing CentOS 8 at BitFolk has previously only been possible by
booting the Rescue VM and doing it in a chroot:
https://tools.bitfolk.com/wiki/Installing_CentOS_8
This is because as of CentOS 8, Red Hat decided to disable support
for PV and PVH mode Xen guests in all their kernels, even though the
upstream Linux kernel does have that supported by default.
Thanks to some work by Jon Fautley¹ in hacking together a modified
installer kernel and initrd for CentOS and RHEL we were able to
boot the installer anyway, so now a more normal install experience
is possible.
It is still necessary for CentOS users to switch to the kernel-ml
kernel package from ElRepo, so our installer does that for you.
===But isn't CentOS 8 dead?===
Red Hat recently moved the EOL date for CentOS 8 forward from 2029
to 31 December 2021. After that point, existing CentOS 8 users would
need to switch to CentOS Stream or some other distribution.
We would like to support CentOS Stream, as well as RHEL and perhaps
one of the more popular CentOS replacements (e.g. Rocky Linux)
should they ever make a release. This work was necessary for that.
===Should I install CentOS 8?===
Probably not given its short remaining lifespan, unless you want to
switch it to CentOS 8 Stream or RHEL8 later.
If you do we'd like to know how you get on with our installer. It's
only received light testing so far.
CentOS 7 is still security supported by the CentOS Linux project
until 30 June 2024.
===What is CentOS Stream?===
I'm not going to try to explain what Red Hat's product lineup is. As
far as I understand it's a rolling release, i.e. constantly updated,
with packages that are about to go into the corresponding RHEL
release. Red Hat does not recommend it for production use.
Red Hat's announcement is here:
https://www.redhat.com/en/blog/faq-centos-stream-updates
===Why are you considering offering RHEL?===
As of 1 February 2021 Red Hat is allowing its free Red Hat Developer
subscription to have up to 16 active servers:
https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-progra…
It should be possible for us to support this soon, though with the
same caveat that it will likely be necessary to use the kernel-ml
EPEL package.
===Other questions?===
Please do ask if there's anything else.
Cheers,
Andy
¹ https://guv.cloud/
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi all,
I run Debian Bullseye on my VPS. Overnight, Bind9 updated to version
9.11.1-1 and promptly crashed.
The fault is already known:
https://gitlab.isc.org/isc-projects/bind9/-/issues/2413
and appears to relate to the use of a named ACL for "allow-update" in the
config. This matches my setup.
I've just downgraded back to 9.16.8-1 for now and that fixed things for
me. Thought I'd mention it, just in case anyone else runs into problems.
If you're on Bullseye and use ACLs in your Bind config, it might be
worth putting a hold on updates to bind9 for a little while.
Cheers,
Alun.
Hi all,
If you are running your own email server and you are using SpamCop
(spamcop[.]net) somewhere in your spam filtering set-up, this is
important.
The service has had its DNS registration lapse and now points to a
domain parking service. More importantly, any lookup against the
SpamCop blocklist will return a positive response, which spam filters
take to mean the domain is listed.
While it would not be difficult for a DNSBL client to distinguish
between these responses and proper DNSBL responses (which usually are
in 127.0.0.0/8), but in practice most don't.
So if you are using SpamCop, it is strongly advised you remove it from
your DNSBL client until the domain starts working again.
Martijn
Hello,
On:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
I am listing Ubuntu EOL dates as found at:
https://wiki.ubuntu.com/Releases
However, it seems that the EOL dates from the Ubuntu wiki refer to
Extended Security Maintenance:
https://ubuntu.com/security/esm
If I understand things correctly, this:
- covers only a small subset of the archive
- requires an Ubuntu Advantage account
- entitlement to ESM updates is only available for free for
personal use on up to 3 machines
So, for example, the recent "sudo" security issue is not available
for 14.04 LTS users unless they meet the above requirements.
If I have misunderstood things can someone correct me?
If not, I don't think it is particularly clear of us to list those
EOL dates on BitFolk's page and instead we should list the "End of
Standard Support" ones.
Thoughts?
And if we do list "End of Standard Support" dates, should that be
matched with "end of stable support" dates for Debian? The situation
for Debian is not straightforward either:
https://wiki.debian.org/DebianReleases#Production_Releases
While LTS and ELTS are available free to everyone (BitFolk is one of
monetary sponsors that makes that possible), they do only cover a
subset of what was in Debian stable.
A summary of what each thing means for Debian is something like:
Stable Security:
- Supported until release end of life
- Package maintainers and security team are supposed to provide
security fixes for every package in the stable release
- buster EOL: some time in 2022
Long Term Support:
- Dedicated team of paid developers provide security fixes on a
best effort basis; sometimes package maintainers help.
- Known to only cover a subset of the archive; most important
packages do get updates.
- buster LTS EOL: likely some time in 2024
Extended LTS:
- Even smaller team of paid developers provide security fixes
- buster ELTS EOL: likely some time in 2026
Which is these things is fair to call a supported Debian release?
Really I'd just like to keep some consistency.
(Personal controversial interjection: I'm no CentOS fan but this is
exactly what people will miss about CentOS. It was a straightforward
10 year support commitment. Which was a massive commitment. It
wasn't always timely, but you knew that RHEL would get an update and
then CentOS would. For 10 years. That has value.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
