Wow. It seems like Debian has made this whole handling of root in mariadb 10.3 astonishingly cryptic. I was just reading this, which mentions the program mysql_secure_installation, which I knew nothing about:

https://www.digitalocean.com/community/ … -debian-10

Several things concern/confuse me about this:

They seem to push you towards having the root account use the unix_socket plugin authentication with no password. My initital installation ended up with the root user set for mysql_native_password and no password.

They also aren't clear at all as to what to do in cases where you actually want a password on the root account as apposed to relying on the unix_socket login. What I did...adding the root password to debian.cnf...is the only way I could find. While the debian.cnf file says "# Automatically generated for Debian scripts. DO NOT TOUCH!", I'm actually not sure that really applies with mariadb 10.3 since they've abandoned the use of the debian-sys-maint user and all that.

They also seem to imply that the changes I made to either the root user or the debian.cnf (adding the root password) file might get lost in a future update(?).

I'm not sure it could get more confusing.

EDIT: As a test I tried a fresh install of mariadb server, and then used that mysql_secure_installation to set the root password. That however set the root user's plugin to unix_socket and still allowed it to login without a password locally. It also left that debian.cnf as-is with the root user and no password. So for cases where you actually want the root user to require a password, the only option is to change (or set to '') that plugin for the root user, and that requires putting the root password in debian.cnf or the service cannot stop or start.

Tom

I installed default-mysql-server which installed these:

default-mysql-server galera-3 gawk libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mysql-perl
libdbi-perl libfcgi-perl libhtml-template-perl libmpfr6 libsigsegv2 libsnappy1v5 libterm-readkey-perl
mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3 socat

When you refer to installing "db-servers" are you referring to, in this case for example, mariadb-server-10.3? I definitely didn't get any prompts or errors of any kind.

When you get the root password prompt, did you end up with a debian-sys-maint user and password in /etc/mysql/debian.cnf? Mine ended up like this:

cat /etc/mysql/debian.cnf 
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Adding the root password there gets everything working, though I'm unclear as to what was supposed to have happened. I'm also unclear as to whether that's any less secure than the setup with the debian-sys-maint user. As far as a purge and a re-install, there's certainly no reason to think it's going to behave any differently then it did yesterday.

Tom

A few things (somewhat OT) that I meant to ask: As mentioned above I did an install of ascii 2.1 and then changed my sources to beowulf and updated. That by the way went flawlessly. Great work on everyone's part there!

Am I correct in assuming that once beowulf goes stable and I update after that, what I'll end up with should be basically identical as if I had installed using the actual beowulf ISO that will then be available? That is, that there's no compelling reason to reinstall etc?

The other thing I was curious about is the fact that I currently see this:

cat /etc/devuan_version
beowulf/ceres

Am I correct in assuming that after an update to a stable beowulf, that will show just "beowulf" as apposed to "beowulf/ceres"?

Thanks in advance, and thanks again for all your hard work fighting the good fight!

Tom

Thanks! Yea, I just tried adding the unstable branch to my sources.list and I can see that. It's a bit scary though and wants 13 upgrades and 25 new installs all from unstable, including some pretty significant stuff.

Does anyone know whether mysql will eventually be available in Beowulf?

Thanks again.
Tom

I understand exactly what Mariadb is, but my company already has installs in the field using MySQL and, for a list of reasons, we want to stick with that. We're using MySQL with Devuan Jessie servers for example.

Again as I pointed out, MySQL is in fact an option in Jessie and Ascii, but it doesn't appear to be an option in Beowulf, at least as it stands now. I was hoping to find out if that's the case, or if I'm missing something. I do have the non-free option enabled for my sources, so it's apparently not related to that.

Tom

Compiling Palemoon 28.7.2 with gcc 8.3.0 (using nice) took me almost exactly 12 hours:

time nice emerge -auv palemoon
Calculating dependencies... done!
[ebuild     U ~] www-client/palemoon-28.7.2::palemoon [28.5.0::palemoon] USE="devtools gtk2 jemalloc official-branding optimize -dbus -debug -gnome (-gtk3) -necko-wifi -pulseaudio -threads -valgrind" CPU_FLAGS_X86="sse sse2" 0 KiB
....
real	722m4.230s
user	550m32.601s
sys	33m4.531s

Also note that I only have 2 GB of RAM which is a big factor as well. No possible way could I compile FF I'd imagine, even if it didn't require rust (the rust source alone is like 275 MB....ouch).

Tom

It certainly appears that way, and that's a really massive compile (requiring rust for some time now) if you've never attempted it.

My company uses Devuan for headless servers, and our needs are very lean so none of this applies. On my own machines I'm currently using Gentoo, and switched from FF to palemoon quite some time ago for more reasons than I can count, including the compile requirements. I can even compile palemoon on very old hardware where I literally wouldn't live long enough to compile FF. Also note that palemoon already has a configuration option to omit dbus.

Tom

Thanks! In the case of the Debian link that works, and redirects to a mirror with everything beginning with that letter. The Devuan link just goes directly to that link as-is and for some reason only has directories for five packages. Not sure what's going there.

Another question: I'm assuming those would be for the current stable release(?)...for example ascii on the case of Devuan. What would the links be for other releases?

Thanks.
Tom

Thanks for all the replies!

Yea, that's the same package as is available for Debian Stretch. That can (sort of) be installed as long as you also manually install ca-certificates-java as well:

https://pkginfo.devuan.org/cgi-bin/d1pk … ease=ascii

Even then however it complains about breaking tzdata-java and will only install by adding --auto-deconfigure. Pretty ugly to say the least.

It appears to work, but I'm not sure as to what issues that ugliness with tzdata-java might cause.

Tom

This actually gave me an idea and I tried totally redoing the upgrade with the following steps:

1. Upgrade wth "apt update" and "apt dist-upgrade".

2. Added the new repo.

3. Removed all php5 packages.

4. Install required php7.2 pacakges: Note that this time this installed BOTH php7.2 and 7.3 which it did NOT do the last time with the exact same command. Odd one. Even stranger is that even this did NOT pull in that openssl1.1.

5. Chose php 7.2 using "update-alternatives --config php"

6. Comments out the new repo.

7. Ran "apt update"

After the above of course the regular updates won't install that new openssl. However I'm still confused as to why it's even there if it wasn't pulled in by any of this. While I haven't tried this yet...and someone can correct me if this is wrong...I believe I could update just php in the future by doing the following:

1. Uncomment the new repo.

2. apt update

3. apt-get install --only-upgrade "php7*"

4. Comment out the new repo.

3. apt update

I going to test that php install and see if I run into any issues as a result of not having that openssl1.1. Still don't get why that's there.

Tom

I didn't see this until today. I'm totally confused as to what you're saying is EOL..."jessie/stretch/ascii php versions"? I must be missing something. Are you just referring to versions on sury? Surely ascii php 7.2 isn't EOL for example.

Also to be clear, in the cases where I might want to do this, upgrading to ascii or compiling from source won't be an option. This would be on virtual appliances in the field in production. Worst case we might port them to a new VM running ascii I suppose.

Thanks
Tom