Directadmin is not installed on AlmaLinux 9

Yoshua

Yoshua

Verified User
Joined
Apr 9, 2007
Messages
133
Location
Spain
Directadmin is not installed on AlmaLinux 9

New VM for a client, OS Almalinux 9 correctly installed and updated, installed software pre-required by DirectAdmin for AlmaLinux 8 (in the documentation they don't specify anything for 9 yet), used the following procedure for installation:

Code: 
mkdir -p /usr/local/directadmin/custombuild
wget -O /usr/local/directadmin/custombuild/options.conf "https://files.domain.tld/directadmin/custombuild/options.conf"
wget -O /usr/local/directadmin/custombuild/php_extensions.conf "https://files.domain.tld/directadmin/custombuild/php_extensions.conf"

cd /root/
wget -O setup.sh http://www.directadmin.com/setup.sh
chmod 755 setup.sh
export DA_SKIP_CSF=true
export DA_NS1=ns1.domain.tld
export DA_NS2=ns2.domain.tld
export [email protected]
export DA_HOSTNAME="hostname.domain.tld"
./setup.sh (LICENSE_KEY)

I get this error in the web interface:

1661978405748.png

And this is the output of the "install.txt" file, no visible error...
 

Attachments

  • install.txt
    17.7 KB · Views: 6
I tried a "build all d" and this is the error...
Code: 
[root@ns003 custombuild]# ./build all d
php 5.x, 7.x and 8.0 cannot compile against openssl 3.0 or higher. Try php 8.1 or higher.

Code: 
#PHP Settings
php1_release=7.4
php1_mode=php-fpm
php2_release=8.1
php2_mode=php-fpm
php3_release=no
php3_mode=php-fpm
php4_release=no
php4_mode=php-fpm
secure_php=yes
php_ini=no
php_timezone=Europe/Madrid
php_ini_type=production
x_mail_header=yes

On a modern OS it is no longer possible to install a version of PHP older than 8.1 or higher? That is not checked by Custombuild/Directadmin to warn us or show us the error? Always the same... :mad:
 
Last edited:
Ok, I check with the client if he can do without PHP version 7.4 and he agrees, I change the php versions to only use 8.1 and try the installation again, it starts fine until another error, this time with MariaDB:

Code: 
...
Downloading jailshell to /usr/bin/jailshell...
Downloading             jailshell-0.6...
######################################################################## 100.0%
/usr/bin/jailshell has been installed.
ERROR 2002 (HY000): Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)
######################################################################## 100.0%
Stopping mysqld ...
Ensuring local-infile is disabled for security reasons in MySQL configuration file...
/var/lib/mysql/mysql does not exist, running clean mysql data installation...
Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
/usr/local/mysql/bin/mariadbd: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

Installation of system tables failed!  Examine the logs in
/var/lib/mysql for more information.

The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:

    shell> /usr/local/mysql/scripts/mysql_install_db --defaults-file=~/.my.cnf

You can also try to start the mysqld daemon with:

    shell> /usr/local/mysql/bin/mariadbd --skip-grant-tables --general-log &

and use the command line tool /usr/local/mysql/bin/mariadb
to connect to the mysql database and look at the grant tables:

    shell> /usr/local/mysql/bin/mysql -u root mysql
    mysql> show tables;

Try 'mysqld --help' if you have problems with paths.  Using
--general-log gives you a log in /var/lib/mysql that may be helpful.

The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss

Please check all of the above before submitting a bug report
at https://mariadb.org/jira

Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xeu mysqld.service" for details.
/usr/local/mysql/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mariadbd is running and that the socket: '/var/lib/mysql/mysql.sock' exists!
Error setting root pass using /usr/local/mysql/bin/mysqladmin. Trying SET PASSWORD.
Setting password: ALTER USER 'root'@'localhost' IDENTIFIED BY 'xuOhTgryR7Bhi';
*********************************

We seem to have an error when trying to SET PASSWORD FOR 'root'@'localhost'

*********************************
...

In summary, that Directadmin/Custombuild is not compatible with Almalinux 9, even though its documentation says that it is:

1661980237727.png

You are a ******* joke as a company...
 
Yoshua said:
You are a ******* joke as a company...
Click to expand...
I rather not reply to people making statements like that... because ast least half of this joke is on your own account.
I know DA makes mistakes and makes a bit too much on updates lately, but still.

Yoshua said:
On a modern OS it is no longer possible to install a version of PHP older than 8.1 or higher? That is not checked by Custombuild/Directadmin to warn us or show us the error? Always the same... :mad:
Click to expand...
So explain why custombuild or DA would be guilty of something that OpenSSL has decided for some reason or PHP?
You'd better check out things before pointing fingers to something while it's a lack of knowledge on your own behalve.

OpenSSL does not support anything before PHP 8.1.x which was already known almost a whole year.

PHP :: Doc Bug #81540 :: OpenSSL 3.0.0 is not supported prior to 8.1.0

bugs.php.net bugs.php.net
also mentioned a couple of times on the forum here. It's not custombuilds task to point to every shortcoming of php or openssl.

As for MariaDB which version is it? Might be you have to enable the Alma linux appstream repo to get the libxcrypt-compat. Not sure about that.

Yoshua said:
In summary, that Directadmin/Custombuild is not compatible with Almalinux 9, even though its documentation says that it is:
Click to expand...
Alma 9 is very new and there will be room for improvement. However, there are some users running Almalinux 9, so it is compatible. Maybe not with all versions of PHP (due to openSSL's requirements) and/or Mariadb (maybe for other reasons). Last one needs checking/fixing maybe.
 
Richard G said:
I rather not reply to people making statements like that... because ast least half of this joke is on your own account.
I know DA makes mistakes and makes a bit too much on updates lately, but still.


So explain why custombuild or DA would be guilty of something that OpenSSL has decided for some reason or PHP?
You'd better check out things before pointing fingers to something while it's a lack of knowledge on your own behalve.

OpenSSL does not support anything before PHP 8.1.x which was already known almost a whole year.

PHP :: Doc Bug #81540 :: OpenSSL 3.0.0 is not supported prior to 8.1.0

bugs.php.net bugs.php.net
also mentioned a couple of times on the forum here. It's not custombuilds task to point to every shortcoming of php or openssl.

As for MariaDB which version is it? Might be you have to enable the Alma linux appstream repo to get the libxcrypt-compat. Not sure about that.


Alma 9 is very new and there will be room for improvement. However, there are some users running Almalinux 9, so it is compatible. Maybe not with all versions of PHP (due to openSSL's requirements) and/or Mariadb (maybe for other reasons). Last one needs checking/fixing maybe.
Click to expand...
When you continually find unresolved issues, untested builds, and no fix on their part, yes, you fall back on terms like calling them a joke, because that's what they are since they changed company direction, charge more money, create with less quality, the sad story of many companies.

As I always say, it's not that something doesn't work, that's understandable and solvable, the problem is publishing without knowing, why does it say on the web that it's compatible with AlmaLinux 9 if it isn't? If the requirements are different or there are limitations, why don't they say so? I have changed the version of PHP to 8.1 and that of MariaDB to 10.6, still the same error, I have to lose a day testing versions or patching a newly installed OS, solving the problems one by one, as they appear, by myself and without any documentation or guide, from a software that I pay for?

For this reason, for putting in its documentation that Directadmin is compatible with Almalinux 9 and wasting my time setting up a new server with it, that's why I say it's a joke, a joke in bad taste.

Thanks, as always, for trying to help, but obviously I can't wait days for a solution and I've reinstalled the OS with AL8 and everything is working now.

Years ago I would have waited and helped test Directadmin/Custombuild on AL9, as was done before, but with this new direction, I would probably even have to pay for a license myself to do pre-release testing.
 
Yoshua said:
If the requirements are different or there are limitations, why don't they say so?
Click to expand...
I do understand your worries, however, it's not always their task to say everything which is a result of OS or PHP or other changes. I even doubt if one of the competitors will state anywhere that one can't use older stuff on OS systems using OpenSSL 3.0 because it's really not only Alma 9 using OpenSSL 3.0.

It's indeed a fact that some things are created to please customers and maybe released too fast, bringing up several errors including some changes which not everybody is happy with. There is certainly room voor improvement, I won't deny that.
I did respond, because I know you don't really mean harm and are in fact a nice guy. ;)

Sad to hear that using MariaDB 10.6 still gives the same error, as far as I read, there was a fix for that in the MariaDB 10.5 and 10.6 but maybe I was mistaken.

I just wanted to advise installing Alma 8 for the moment, because everything works in there, but you already did.

However I still hope somebody will answer with a solution to this issue, so others can benefit from your post with the error.
Maybe some of the users here already using Alma 9 can comment on this, maybe they now how to fix so Alma 9 can be used better the next time. Because that's the reason that it's said on the web... because DA is running on it.

Question is where the MariaDB issues are coming from, hopefully somebody can comment on that soon.
Because Libcrypt has to do with openssl, it might also affect other supported OS systems using Openssl 3.0.

@smtalk any clue on to why this libcrypto error occurs on a MariaDB 10.6.x install on Alma 9?
 
Richard G said:
I do understand your worries, however, it's not always their task to say everything which is a result of OS or PHP or other changes. I even doubt if one of the competitors will state anywhere that one can't use older stuff on OS systems using OpenSSL 3.0 because it's really not only Alma 9 using OpenSSL 3.0.

It's indeed a fact that some things are created to please customers and maybe released too fast, bringing up several errors including some changes which not everybody is happy with. There is certainly room voor improvement, I won't deny that.
I did respond, because I know you don't really mean harm and are in fact a nice guy. ;)

Sad to hear that using MariaDB 10.6 still gives the same error, as far as I read, there was a fix for that in the MariaDB 10.5 and 10.6 but maybe I was mistaken.

I just wanted to advise installing Alma 8 for the moment, because everything works in there, but you already did.

However I still hope somebody will answer with a solution to this issue, so others can benefit from your post with the error.
Maybe some of the users here already using Alma 9 can comment on this, maybe they now how to fix so Alma 9 can be used better the next time. Because that's the reason that it's said on the web... because DA is running on it.

Question is where the MariaDB issues are coming from, hopefully somebody can comment on that soon.
Because Libcrypt has to do with openssl, it might also affect other supported OS systems using Openssl 3.0.

@smtalk any clue on to why this libcrypto error occurs on a MariaDB 10.6.x install on Alma 9?
Click to expand...

I'm very sorry, Richard, if I sometimes seem too rude in my complaints.

:(
 
Zhenyapan said:
but there:
Click to expand...
Yes that's where I found it too and also the same with compatibility to 10.5 branch.

Which is why I find it odd, because DA does not source compile MariaDB, it's installed from RPM.

Yoshua said:
I'm very sorry, Richard, if I sometimes seem too rude in my complaints.
Click to expand...
No problem, sometimes the frustrations have to come out, and I know here have been some. ;)
 
Yoshua said:
/usr/local/mysql/bin/mariadbd: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
Click to expand...
I'd double check the libcrypt.so (openssl) version used/picked up by mariadbd binary - looks like a custom OpenSSL 1.1.1 (libcrypto.so.1) being picked up and not Alma Linux 9 system OpenSSL 3.0 (/lib64/libcrypto.so.3) as even AlmaLinux 9's compat-openssl11 is reported as libcrypto.so.1.1

Code: 
yum -q provides */lib64/libcrypto.so*
compat-openssl11-1:1.1.1k-3.el9.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
Repo        : appstream
Matched from:
Filename    : /usr/lib64/libcrypto.so.1.1
Filename    : /usr/lib64/libcrypto.so.1.1.1k

compat-openssl11-1:1.1.1k-4.el9_0.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
Repo        : appstream
Matched from:
Filename    : /usr/lib64/libcrypto.so.1.1
Filename    : /usr/lib64/libcrypto.so.1.1.1k

openssl-devel-1:3.0.1-20.el9_0.x86_64 : Files for development of applications which will use OpenSSL
Repo        : appstream
Matched from:
Filename    : /usr/lib64/libcrypto.so

openssl-devel-1:3.0.1-23.el9_0.x86_64 : Files for development of applications which will use OpenSSL
Repo        : appstream
Matched from:
Filename    : /usr/lib64/libcrypto.so

openssl-devel-1:3.0.1-41.el9_0.x86_64 : Files for development of applications which will use OpenSSL
Repo        : @System
Matched from:
Filename    : /usr/lib64/libcrypto.so

openssl-devel-1:3.0.1-41.el9_0.x86_64 : Files for development of applications which will use OpenSSL
Repo        : appstream
Matched from:
Filename    : /usr/lib64/libcrypto.so

openssl-libs-1:3.0.1-20.el9_0.x86_64 : A general purpose cryptography library with TLS implementation
Repo        : baseos
Matched from:
Filename    : /usr/lib64/libcrypto.so.3
Filename    : /usr/lib64/libcrypto.so.3.0.1

openssl-libs-1:3.0.1-23.el9_0.x86_64 : A general purpose cryptography library with TLS implementation
Repo        : baseos
Matched from:
Filename    : /usr/lib64/libcrypto.so.3
Filename    : /usr/lib64/libcrypto.so.3.0.1

openssl-libs-1:3.0.1-41.el9_0.x86_64 : A general purpose cryptography library with TLS implementation
Repo        : @System
Matched from:
Filename    : /usr/lib64/libcrypto.so.3
Filename    : /usr/lib64/libcrypto.so.3.0.1

openssl-libs-1:3.0.1-41.el9_0.x86_64 : A general purpose cryptography library with TLS implementation
Repo        : baseos
Matched from:
Filename    : /usr/lib64/libcrypto.so.3
Filename    : /usr/lib64/libcrypto.so.3.0.1

This is on non-DirectAdmin based AlmaLinux 9 with MariaDB 10.6 via official MariaDB YUM Repo for RHEL9

Code: 
ldd $(which mariadb)
        linux-vdso.so.1 (0x00007ffce05ad000)
        libedit.so.0 => /lib64/libedit.so.0 (0x00007f6d72bfd000)
        libncurses.so.6 => /lib64/libncurses.so.6 (0x00007f6d72bd0000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f6d72ba1000)
        libssl.so.3 => /lib64/libssl.so.3 (0x00007f6d72afc000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f6d726d0000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f6d726b6000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f6d7248d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6d723b2000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6d721a8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6d7306b000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6d7218d000)
Code: 
mysqladmin ver
mysqladmin  Ver 9.1 Distrib 10.6.9-MariaDB, for Linux on x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Server version          10.6.9-MariaDB
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/lib/mysql/mysql.sock
Uptime:                 3 min 57 sec

Threads: 1  Questions: 1  Slow queries: 0  Opens: 17  Open tables: 10  Queries per second avg: 0.004

For PHP 7.4 and PHP 8.0 on EL9, just use OpenSSL 1.1.1 instead of system OpenSSL 3.0. That's what I do :)

edit: Actually original posters issue is with libxcrypt and not openssl
 
Last edited:
So then it's what I mentioned, this works if I understand correctly?
Richard G said:
Might be you have to enable the Alma linux appstream repo to get the libxcrypt-compat. Not sure about that.
Click to expand...

Still the newest MariaDB should support Openssl 3.0.
 
Richard G said:
So then it's what I mentioned, this works if I understand correctly?


Still the newest MariaDB should support Openssl 3.0.
Click to expand...
Ah I see the problem is that libxcryt-compat was installed and that's where problematic error is reported for /usr/lib64/libcrypt.so.1

Code: 
rpm -ql libxcrypt-compat
/usr/lib/.build-id
/usr/lib/.build-id/ca/16befb9c0efccea6de9f7530d8e8e9d8ae9916
/usr/lib64/fipscheck
/usr/lib64/fipscheck/libcrypt.so.1.1.0.hmac
/usr/lib64/fipscheck/libcrypt.so.1.hmac
/usr/lib64/libcrypt.so.1
/usr/lib64/libcrypt.so.1.1.0
/usr/share/doc/libxcrypt/README.posix

But I have that installed to and MariaDB 10.6 looks fine

edit: ah my MariaDB 10.6 is MariaDB official YUM. DirectAdmin looks to be source compiled as it references /usr/local/mysql/bin/mariadbd so picked up libxcrypt-compat's libcrypt.so.1 and not system OpenSSL 3 libcrypt.so.3 or libxcrypt's libcrypt.so.2.0.0

edit: actually on working system seems mariadbd is using libcrypt.so.2.0.0

Code: 
lsof | grep 'libcrypt.so' | grep mariadbd
mariadbd  4289                    mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4290 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4291 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4292 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4293 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4297 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4299 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0
mariadbd  4289 4300 mariadbd      mysql  mem       REG              253,0    201840  201480878 /usr/lib64/libcrypt.so.2.0.0

which is a libxcrypt package

Code: 
yum provides /usr/lib64/libcrypt.so.2.0.0 -q
libxcrypt-4.4.18-3.el9.x86_64 : Extended crypt library for descrypt, md5crypt, bcrypt, and others
Repo        : @System
Matched from:
Filename    : /usr/lib64/libcrypt.so.2.0.0

libxcrypt-4.4.18-3.el9.x86_64 : Extended crypt library for descrypt, md5crypt, bcrypt, and others
Repo        : baseos
Matched from:
Filename    : /usr/lib64/libcrypt.so.2.0.0

AlmaLinux 9 is very busy system for libcrypt it seems
Code: 
ls -lah /usr/lib64/libcrypt.so*
lrwxrwxrwx  1 root root   17 Feb  9  2022 /usr/lib64/libcrypt.so -> libcrypt.so.2.0.0
lrwxrwxrwx. 1 root root   17 Feb  9  2022 /usr/lib64/libcrypt.so.1 -> libcrypt.so.1.1.0
-rwxr-xr-x. 1 root root 198K Feb  9  2022 /usr/lib64/libcrypt.so.1.1.0
lrwxrwxrwx. 1 root root   17 Feb  9  2022 /usr/lib64/libcrypt.so.2 -> libcrypt.so.2.0.0
-rwxr-xr-x. 1 root root 198K Feb  9  2022 /usr/lib64/libcrypt.so.2.0.0
 
Last edited:
eva2000 said:
Ah I see the problem is that libxcryt-compat was installed
Click to expand...
I don't know, this was a suggestion I made, but I don't think it was installed. @Yoshua was libxcrypt-compat installed?

I have no clue myself. I was trying to help and was wondering as the why MariaDB was throwing this error. As far as I know MariaDB for Directadmin is not source compiled because I always see rpm's running on updates.
 
Richard G said:
As far as I know MariaDB for Directadmin is not source compiled because I always see rpm's running on updates.
Click to expand...
Unless DirectAdmin is building own RPMs with paths like /usr/local/mysql/bin/mariadbd, it probably is source compiled???

Should be easy to check. From official MariaDB 10.6 YUM repo installed client package

Code: 
rpm -ql MariaDB-client | grep '/usr/bin'
/usr/bin/mariadb
/usr/bin/mariadb-access
/usr/bin/mariadb-admin
/usr/bin/mariadb-binlog
/usr/bin/mariadb-check
/usr/bin/mariadb-conv
/usr/bin/mariadb-convert-table-format
/usr/bin/mariadb-dump
/usr/bin/mariadb-dumpslow
/usr/bin/mariadb-embedded
/usr/bin/mariadb-find-rows
/usr/bin/mariadb-hotcopy
/usr/bin/mariadb-import
/usr/bin/mariadb-plugin
/usr/bin/mariadb-secure-installation
/usr/bin/mariadb-setpermission
/usr/bin/mariadb-show
/usr/bin/mariadb-slap
/usr/bin/mariadb-tzinfo-to-sql
/usr/bin/mariadb-waitpid
/usr/bin/msql2mysql
/usr/bin/my_print_defaults
/usr/bin/mysql
/usr/bin/mysql_embedded
/usr/bin/mysql_find_rows
/usr/bin/mysql_plugin
/usr/bin/mysql_tzinfo_to_sql
/usr/bin/mysql_waitpid
/usr/bin/mysqlaccess
/usr/bin/mysqladmin
/usr/bin/mysqlbinlog
/usr/bin/mysqlcheck
/usr/bin/mysqldump
/usr/bin/mysqlimport
/usr/bin/mysqlshow
/usr/bin/mysqlslap
/usr/bin/mytop
/usr/bin/replace

and server package
Code: 
rpm -ql MariaDB-server | grep '/usr/bin'
/usr/bin/aria_chk
/usr/bin/aria_dump_log
/usr/bin/aria_ftdump
/usr/bin/aria_pack
/usr/bin/aria_read_log
/usr/bin/galera_new_cluster
/usr/bin/galera_recovery
/usr/bin/innochecksum
/usr/bin/mariadb-fix-extensions
/usr/bin/mariadb-install-db
/usr/bin/mariadb-service-convert
/usr/bin/mariadb-upgrade
/usr/bin/mariadbd-multi
/usr/bin/mariadbd-safe
/usr/bin/mariadbd-safe-helper
/usr/bin/myisam_ftdump
/usr/bin/myisamchk
/usr/bin/myisamlog
/usr/bin/myisampack
/usr/bin/mysql_fix_extensions
/usr/bin/mysql_install_db
/usr/bin/mysql_upgrade
/usr/bin/mysqld_multi
/usr/bin/mysqld_safe
/usr/bin/mysqld_safe_helper
/usr/bin/perror
/usr/bin/resolve_stack_dump
/usr/bin/resolveip
/usr/bin/wsrep_sst_backup
/usr/bin/wsrep_sst_common
/usr/bin/wsrep_sst_mariabackup
/usr/bin/wsrep_sst_mysqldump
/usr/bin/wsrep_sst_rsync
/usr/bin/wsrep_sst_rsync_wan

and relevant mariadbd
Code: 
rpm -ql MariaDB-server | grep '/usr/sbin'
/usr/sbin/mariadbd
/usr/sbin/mysqld
/usr/sbin/rcmysql

Code: 
 yum provides */mariadbd -q
MariaDB-server-10.6.9-1.el9.x86_64 : MariaDB database server binaries
Repo        : @System
Matched from:
Filename    : /usr/sbin/mariadbd

MariaDB-server-10.6.9-1.el9.x86_64 : MariaDB database server binaries
Repo        : mariadb
Matched from:
Filename    : /usr/sbin/mariadbd

mariadb-server-3:10.5.13-2.el9.x86_64 : The MariaDB server and related files
Repo        : appstream
Matched from:
Filename    : /usr/libexec/mariadbd
Filename    : /usr/sbin/mariadbd

mariadb-server-3:10.5.16-2.el9_0.x86_64 : The MariaDB server and related files
Repo        : appstream
Matched from:
Filename    : /usr/libexec/mariadbd
Filename    : /usr/sbin/mariadbd

One explanation is official MariaDB YUM repo only recently added RHEL 9 packages (was waiting for them myself), so DirectAdmin decided to source compile only for EL9?
 
Last edited:
eva2000 said:
so DirectAdmin decided to source compile only for EL9?
Click to expand...
You're totally right about the source compiling indeed. I''ve always see a lot of gcc and stuff passing by, pages and pages like with PHP and Apache.
When updating Mariadb I always see a process kind of like this.
Code: 
Mariadb-server ################### 10%
Mariadb-server ################### 30%
and so on until 100%. Same for the client. So I thought this was just rpm updating.
But I had a look in the build script and if I'm not mistaken it seems there the build is unpacking the tarball and it's indeed compiled from source.

So I was mistaken about being it installed from rpm.
 
I try to test DirectAdmin installation on AlmaLinux 9.

It fails to compile majordomo
wget https://files.directadmin.com/services/all/majordomo-1.94.5-patched.tar.gz
This file fails to tar.gz extraction

Error Message: The source path for majordomo does not exist. Make sure the correct path is set in majordomo.sh

HTML: 
[root@hosting-dev-al9 custombuild]# tar xzvf majordomo-1.94.5-patched.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
[root@hosting-dev-al9 custombuild]# md5sum majordomo-1.94.5-patched.tar.gz
316a354ba9653354bdf3fcd226939a76  majordomo-1.94.5-patched.tar.gz
 
@eva2000 I've just read this from smtalk in another thread:
DirectAdmin does not compile MariaDB by default on 64bit systems.
Click to expand...
Now I'm confused due to the differences you see in your yum installation and the DA installation.
 
You must log in or register to reply here.
Back
Top