Ubuntu is FOG's enemy
TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.
So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.
I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.
The quickest fix is to simply rerun the fog installer which should correct the problem.
As a note, it seems this problem is specific only when the mysql account is the
'root'user AND the password is blank.
The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then
sudo -i(in most cases).
From there, open mysql with
mysql -u root
NOTE: MySQL MUST be run with ROOT.
ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY '';AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';
It’s okay if one of them fails. This is going to fix Most people’s issues.
I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.
To prevent this problem from happening in the future you could run:
apt-get -y remove unattended-upgrades(AS Root again).
If, for some reason, you fail to follow the instructions.
mysql -u rootand
apt-get -y remove unattended-upgradescommands can be run prepended with
sudoto elevate privileges.
sudo mysql -u root
sudo apt-get -y remove unattended-upgrades
I concur with Tom’s post. I did write a huge thing I was going to post, but then realized it was like three pages long… so I deleted it. I’ll summarize that you’ll have less problems if you use RHEL, CentOS, or Debian for server OSs. Ubuntu is my favorite workstation OS, but I won’t use it for a server if I can at-all avoid it. And I do speak from some experience. Tom of course speaks from way, way more experience.
@Canonical I wish you’d stop changing stuff so much so often, and stop assuming that you know better than the administrator. If we set a setting via SQL manually, post OS installation, and post-mysql installation, you have no right to change it with an update that you push out at whim. I’m sick and tired of the
unity-webapps-commonpackage, I think it’s source code should be deleted forever. And I think that automatic updates via
unattended-upgradesis complete bogus. Often I’ve found that even though I select “Do not update automatically” during the OS installation, the
unattended-upgradespackage still applies updates. This is evidenced by the message “You need to restart your server” when I log in via SSH. Then you went off and fell in love with Microsoft, I don’t approve of this. I think you’re too young to be in a relationship with such an older company. Surely, the older company will take advantage of you and you’ll end up pregnant with a WinBuntu baby, or worse get some kind of virus that you’ll need to see Dr. Symantec for.
My first post here, but I thought it timely to add this. This unattended-upgrades, up until 4/29, been setup to check for security updates only. In short, on that day (or rather, at 1am my time), it updated itself along with its configuration. You can see this in the log sample below. This of course wreaked some havoc on my production systems when it updated all sorts of packages and nuked everything. Needless to say, this feature is now permanently DISABLED.
2017-04-23 04:49:04,987 INFO Allowed origins are: [‘o=Ubuntu,a=xenial-security’]
2017-04-27 15:46:07,068 INFO Allowed origins are: [‘o=Ubuntu,a=xenial-security’]
2017-04-28 12:35:25,599 INFO Allowed origins are: [‘o=Ubuntu,a=xenial-security’]
2017-04-28 12:35:29,950 INFO Packages that will be upgraded: unattended-upgrades
2017-04-30 03:19:04,933 INFO Allowed origins are: [‘o=Ubuntu,a=xenial’, ‘o=Ubuntu,a=xenial-security’]
2017-04-30 15:35:41,094 INFO Allowed origins are: [‘o=Ubuntu,a=xenial’, ‘o=Ubuntu,a=xenial-security’]
In short … it updated itself along with its configuration.
Another example of Canonical thinking they know better than the administrator. It has never been ok to overwrite configuration set by the administrator, nor will it ever be. Updating the schema of a configuration file while preserving the configuration is one thing, but overwriting custom configuration is unacceptable.
@wanderson Have you tried replacing 127.0.0.1 with localhost?
BD this mariaDB
Which linux distro is most preferred by the developers?
@wanderson The alter user syntax is only a specific version of mysql and mariadb. IN the case of mariadb I believe it started with version 10.2, and for mysql it started with 5.7.
So, in your particular case, chances are the version of mariadb is not one that supports the alter user statement. That said, i only recommended the post as it seemed similar to what we’ve recently seen with CentOS 7. It does not mean this was the issue, but trying it wouldn’t hurt anything either.
The issue that brought you to this posting is most likely related to Max connections being used. I don’t know what settings will fix that for you.
@Avaryan I try not to specify a specific OS. This posting is mainly just informing users of potential issues we were/are seeing. I’m personally a fan of Fedora/Redhat/CentOS, but I try pretty hard to make our installer distro agnostic. For the most part we support the two main types found (Debian based, and Redhat based). We also support Arch.
If I had to say which one to use, I’d actually say CentOS as it’s stable, usually minimally offset from Redhat releases. Fedora would probably be the next one on the list, but in a “production” world I wouldn’t recommend it.
@Tom-Elliott It seems that so far this command has resolved:
SET PASSWORD FOR ‘root’@‘localhost’ = PASSWORD(‘’);
SET PASSWORD FOR ‘root’@‘127.0.0.1’ = PASSWORD(‘’);
chown -R apache:root /var/www/
Praying that the mistake will not happen again!
update mysql.user set plugin=‘mysql_native_password’;
How difficult is it to migrate from an existing FOG server / FOG storage node running Ubuntu to Centos from a FOG perspective?
@Joe-Gill Easy, here’s the guide: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
Great I found this as solution for the same problem that suddenly appear here, i remove the “unattended-upgrades” from Ubuntu and I hope that don’t happen again. , solved!
Thanks @Tom-Elliott !
Hey there Canonical, you’re not doing yourself any favors when you change settings the admin has manually set. I hoped someone on your team would have read this thread and made changes accordingly to prevent the continuance of mayhem, but alas it seems nobody has… Don’t you have Google alerts setup when the words “Canonical” are used on-line?
@wayne-workman nice try wayne