Another Friday has passed and there’s still no update. As stated, there are no guarantees.
I understand that everyone is impatient.
I think the teams are overwhelmed and would rather ask for their encouragement
I remember VestaCP dying the same way 
We understand the concern, especially with comparisons to what happened to VestaCP.
We were not able to meet the originally mentioned release window, but we are still here and actively working on it. The delay is caused by limited capacity, not by the project being abandoned.
Hestia is not in the same situation as VestaCP was. The project is not dependent on a single person and does not hinge on one maintainer disappearing. Development may currently be slower than desired, but it is ongoing, with a clear focus on maintenance and security.
We are continuing to work towards a release that includes the outstanding security-related updates. As soon as we have something concrete, we will communicate it.
As mentioned before, if anyone wants to help with reviews, testing, or development, please reach out. Additional help would make a real difference.
Thanks for your patience and for sticking with the project.
I would love to contribute. Please share the onboarding process.
Please send me a pm and tell me a bit about you and your skills, so we can see if it fits to hestia.
I renew my old work on my old IPV6 stuff again and begun it with DEBIAN 13. So I installed HESTIA on a “fresh” DEBIAN 13, without upgrade, backports or something else. And I can agree, without this “patch” (or better to say “replace”) in v-check-user-password user authentification does not work. But I was a little wondered, as I did not found that nor in the DEBIAN 13 branch nor in fork of @sahsanu , which I merged additionaly to “official” DEBIAN 13 branch into my own IPV6 fork/branch. Therefore I have questions:
- @sahsanu Why do you not need this replace? Do you installed a special older python3 version, or what is your workaround for it?
- @Derp If we make a real PR from your proposal here (that is really required for fresh DEBIAN installations!), should we do it exactly so and it works with all DEBIANs <13, too (general solution). Or do we need a better case distinction between DEBIAN 13 and other DEBIANs before 13, so that we have a universal solution an not only a workaround for DEBIAN 13?
Yes, I need it 
but I’ve not created a PR, it’s a known issue and in my PR I’ve focused on Dovecot 2.4.
Python version 3.13.x in Debian 13 doesn’t include the crypt module anymore.
In v-check-user-password remove the python block.
From this:
if [ "$method" = "yescrypt" ]; then
if which python3 > /dev/null; then
export PASS="$password" SALT="$shadow"
hash=$(python3 -c 'import crypt, os; print(crypt.crypt(os.getenv("PASS"), os.getenv("SALT")))')
else
# Fall back to mkpasswd as fallback
hash=$(mkpasswd "$password" "$shadow")
fi
if [ $? -ne 0 ]; then
echo "Error: password missmatch"
if [ -z "$return_hash" ]; then
echo "$date $time $user $ip46 failed to login" >> $HESTIA/log/auth.log
fi
exit 9
fi
else
to this:
if [ "$method" = "yescrypt" ]; then
hash=$(mkpasswd "$password" "$shadow")
if [ $? -ne 0 ]; then
echo "Error: password missmatch"
if [ -z "$return_hash" ]; then
echo "$date $time $user $ip46 failed to login" >> $HESTIA/log/auth.log
fi
exit 9
fi
else
But the proposal from @Derp from above here in this thread, which I used, was a little different, made more checks (existence of binary) and uses an additional call parameter. Therefore an additional question @Derp : What are the advantages of your proposal compared to just delete the python section?
And the importantest question again: Does it work without Python also on DEBIAN 10, DEBIAN 11 and DEBIAN 12?
if command -v mkpasswd >/dev/null 2>&1; then
export PASS="$password" SALT="$shadow"
hash=$(mkpasswd -m yescrypt "$password" "$shadow" 2>/dev/null || mkpasswd "$password" "$shadow")
else
# Fall back to mkpasswd as fallback
hash=$(mkpasswd "$password" "$shadow")
fi
if command -v mkpasswd >/dev/null 2>&1; then
It doesn’t hurt checking the existence of mkpasswd but Hestia installs whois package and it provides mkpasswd so it should exist.
export PASS="$password" SALT="$shadow"
You don’t need that, those variables were used by python command.
hash=$(mkpasswd -m yescrypt "$password" "$shadow" 2>/dev/null || mkpasswd "$password" "$shadow")
yescrypt is supported for all the distros supported by Hestia (Ubuntu 22.04, 24.04 and Debian 11, 12 and it’s the default when invoking mkpasswd without -.m yescrypt argument., so a simple hash=$(mkpasswd "$password" "$shadow") is enough.
Also, doesn’t make sense to use if command -v mkpasswd >/dev/null 2>&1; then and if mkpasswd doesn’t exist then execute it, hash=$(mkpasswd "$password" "$shadow")
Yes.
At least Debian 11 and 12, Hestia doesn’t support Debian 10 anymore (at least on new installs) but it will also work even when Debian 10 uses by default SHA512 instead of yescrypt (v-check-user-password has the logic to manage different hash methods).
ok, thanks for detailed information!
I think, we should make a PR with your variant of v-check-user-password against the DEBIAN 13 branch on GITHUB. I would also favorise to make a PR from your own dovecot branch (from your fork) against DEBIAN 13 branch of HESTIA. In this case we will have all the required changes in this especial DEBIAN 13 branch and it will simple to merge it later into the main branch. But that is just my proposal to “channel” all the activities and to summarise they to whole “package”.
I know it’s already a known bug for the Hestia team, so I’m not entirely sure if they want to handle it in a different way. In any case, I’ll submit the PR.
I submitted the PR for Dovecot 2.4 support for Debian 13 five months ago, and it is already using Hestia’s debian-13-support branch.
Ok, but it is not the part of debian-13-support branch yet. That is still and just a PR. Therefore I merged it into my own fork separatelly. With my “provocation” here I would only signal, that we should use the debian-13-support branch to collect all required changes. And we should hold the branch actual. Otherwise each new person here (like me) is “damned” to search of all required patches overall in the forks, in forum here as code text etc. That is not the criticism especially to you, sahsanu. You do your job here very good and above all quickly! That is the criticism about the review process here in project in generally. Therefore my proposal is, to simplify the review process here for such testing branches like this debian-13-support branch. It would be good, if on the one hand more people here become direct write rights to such testing branches and we awoid this eternal waiting for review process and check in. On the other hand we become automatic more tester here, if all these branches were more or less up-to-date.
Yes, I know, but I can’t do anything to get the PR included
I guess that’s what the Hestia team intended when they created that branch 
Note: I was submitting a new PR to the debian-13-support branch to fix the Python issue, but it included the commits from the Dovecot PR, so I’ve closed it. I don’t want to mess up that branch, so I’ll submit it again once the Dovecot PR is merged.
Thanks! I integrated your python workaround already in my own IPV6 repository and it works now.
But I have the next question. Today I started test/test.bats and I become a lot of failures:
223 tests, 8 failures, 25 skipped
That is very good for my not completly ready IPV6 stuff, but the most failures (and also warnings) are “mysql command not found”.
I found this thread and you posted there a good explanation and a workaround @sahsanu. Therefore I ask you again: Do we have similar problems with depricated using of “mysql” as command under DEBIAN 13 too, or are these problems even stronger under DEBIAN 13? Should I install the recommended packages additionaly, or do you have an alternative solution for it?
Thanks!
Could you please show me the output of those tests (number, test name and the output)?
Hestia installs these mariadb packages: mariadb-client mariadb-common mariadb-server and those packages also install these:
The following NEW packages will be installed:
galera-4 gawk libcgi-fast-perl libcgi-pm-perl libclone-perl libconfig-inifiles-perl libdbd-mariadb-perl libdbi-perl
libencode-locale-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl
libhttp-date-perl libhttp-message-perl libio-html-perl liblwp-mediatypes-perl libmariadb3 libncurses6 libregexp-ipv6-perl libsigsegv2
libterm-readkey-perl libtimedate-perl liburi-perl liburing2 mariadb-client mariadb-client-compat mariadb-client-core mariadb-common
mariadb-server mariadb-server-compat mariadb-server-core mysql-common psmisc pv socat
So mariadb-server-compat and mariadb-client-compat (the packages providing the links to simulate mysql commands) are installed too. I’m wondering what’s going on in your server.
Yes, it does, unless you explicitly install it with --mysql no
I found the installation protocoll. It will not be installed automatically:
The following additional packages will be installed:
apache2-bin apache2-data bind9-utils dovecot-core dovecot-sieve exim4-base
exim4-config galera-4 libabsl20240722 libaom3 libapr1t64
libaprutil1-dbd-sqlite3 libaprutil1-ldap libaprutil1t64 libargon2-1
libaspell15 libavif16 libc-client2007e libconfig-inifiles-perl
libexttextcat-2.0-0 libexttextcat-data libgav1-1 libgd3 libidn12
libimagequant0 liblua5.4-0 libmariadb3 libnsl2 libpcre2-posix3 libpq5
librav1e0.7 libspf2-2t64 libstemmer0d libsvtav1enc2 libunwind8 libxpm4
libxslt1.1 libyuv0 mariadb-client-core mariadb-server-core mlock
mysql-common php-common python3-systemd socat ssl-cert
Suggested packages:
apache2-doc ufw www-browser bind9-doc dovecot-flatcurve dovecot-gssapi
dovecot-ldap dovecot-lmtpd dovecot-managesieved dovecot-mysql dovecot-pgsql
dovecot-solr dovecot-sqlite dovecot-submissiond ntp exim4-doc-html
| exim4-doc-info eximon4 mail-reader spf-tools-perl swaks mailx monit
sqlite3 aspell uw-mailutils libgd-tools mariadb-test php-pear
Recommended packages:
bsd-mailx | mailx python3-pyinotify python3-setuptools aspell-en
| aspell-dictionary | aspell6a-dictionary libdbd-mariadb-perl
| libdbd-mysql-perl libterm-readkey-perl mariadb-client-compat
libhtml-template-perl mariadb-server-compat pv ghostscript
The following NEW packages will be installed:
apache2 apache2-bin apache2-data apache2-suexec-custom apache2-utils bind9
bind9-utils dovecot-core dovecot-imapd dovecot-pop3d dovecot-sieve exim4
exim4-base exim4-config exim4-daemon-heavy fail2ban galera-4 libabsl20240722
libaom3 libapache2-mod-fcgid libapr1t64 libaprutil1-dbd-sqlite3
libaprutil1-ldap libaprutil1t64 libargon2-1 libaspell15 libavif16
libc-client2007e libconfig-inifiles-perl libexttextcat-2.0-0
libexttextcat-data libgav1-1 libgd3 libidn12 libimagequant0 liblua5.4-0
libmariadb3 libnsl2 libpcre2-posix3 libpq5 librav1e0.7 libspf2-2t64
libstemmer0d libsvtav1enc2 libunwind8 libxpm4 libxslt1.1 libyuv0
mariadb-client mariadb-client-core mariadb-common mariadb-server
mariadb-server-core mlock mysql-common nginx php-common php8.3 php8.3-apcu
php8.3-bcmath php8.3-bz2 php8.3-cli php8.3-common php8.3-curl php8.3-fpm
php8.3-gd php8.3-imagick php8.3-imap php8.3-intl php8.3-ldap php8.3-mbstring
php8.3-mysql php8.3-opcache php8.3-pspell php8.3-readline php8.3-soap
php8.3-xml php8.3-zip python3-systemd socat ssl-cert vsftpd
Both packages are only “recommended”, but will not be installed automatically.
I installed fresh this virtual server a few days ago and did not install mariadb or its packages manually. Moreover I have my own “install” and “uninstall” scripts for testing. These scripts uninstall nearby all, what HESTIA installed before and remove a lot of files and directories additionally. I use these scripts for testing purposes instead of new install of virtual server. Maybe, that I have here a problem, but I think not so. I think this “recommended” says already all.
Edit:
I really have a problem:
I will doublecheck the installation protocoll. Removing of hestia-php is not really a good solution.
Edit2:
I found this on the end of installation protocol:
Processing triggers for dovecot-core (1:2.4.1+dfsg1-6+deb13u2) … invoke-rc.d: policy-rc.d denied execution of restart. mysql.user table already exists! Run mariadb-upgrade, not mariadb-install-db Enabling module remoteip. To activate the new configuration, you need to run: systemctl restart apache2 Reading package lists… Building dependency tree… Reading state information… You might want to run ‘apt --fix-broken install’ to correct these. The following packages have unmet dependencies: hestia-php : Depends: libzip4 but it is not installable
I’ve tested it right now in a new and fresh Debian 13 install and using the MariaDB repo for version 11.8 and it installs the compat packages:
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/mariadb-keyring.gpg] https://dlm.mariadb.com/repo/mariadb-server/11.8/repo/debian trixie main" > /etc/apt/sources.list.d/mariadb.list
curl -s https://mariadb.org/mariadb_release_signing_key.asc | gpg --dearmor | tee /usr/share/keyrings/mariadb-keyring.gpg > /dev/null 2>&1\n
apt update
apt install mariadb-server mariadb-common mariadb-client
Installing:
mariadb-client mariadb-common mariadb-server
Installing dependencies:
galera-4 libencode-locale-perl libhttp-date-perl libpcre2-posix3 mariadb-server-compat
libcgi-fast-perl libfcgi-bin libhttp-message-perl libterm-readkey-perl mariadb-server-core
libcgi-pm-perl libfcgi-perl libio-compress-brotli-perl libtimedate-perl mysql-common
libclone-perl libfcgi0t64 libio-html-perl liburi-perl pv
libconfig-inifiles-perl libhtml-parser-perl liblwp-mediatypes-perl liburing2 socat
libdbd-mariadb-perl libhtml-tagset-perl libmariadb3 mariadb-client-compat
libdbi-perl libhtml-template-perl libncurses6 mariadb-client-core
Suggested packages:
libmldbm-perl libsql-statement-perl libipc-sharedcache-perl libmime-base32-perl libwww-perl mariadb-test doc-base
libnet-daemon-perl libdata-dump-perl libbusiness-isbn-perl libregexp-ipv6-perl mailx netcat-openbsd
Summary:
Upgrading: 0, Installing: 36, Removing: 0, Not Upgrading: 4
Download size: 30.8 MB
Space needed: 244 MB / 12.4 GB available
Continue? [Y/n]
[...]
❯ ls -l /usr/bin/mysql
lrwxrwxrwx 1 root root 7 Feb 1 11:17 /usr/bin/mysql -> mariadb