My failed attempt at upgading from 7.1.1 to Zentyal 8.0

[Daniel Joven]

Hi Daniel,

I appreciate your help,

Before i started the upgrade I did all of the check steps and I didn't see any error

Yes, the proper and up-to-date repository data will be used.

The first time when I wrote I used a live server clone this server contains the webmail module and this module is actively used. But today I created an empty 7.0 server, during the upgrade from 7.0 to 8.0 I didn't experience any issues but when I tried to deploy the webmail module it showed same  error


BR,
GáborS

Hi,

The script uninstalls temporarily the zentyal-webmail package and installs it later. Also, it does a database backup and restores it, just to avoid any issues during this process. Unfortunately, without the required information, we cannot know what might happen in your upgrade. You must schedule another upgrade and in case you get the same error, you must run the mentioned commands and also, analyze the following log files:

• /var/log/zentyal/upgrade.log
• /var/log/zentyal/zentyal.log
• /var/log/dpkg.log

[AlecM]

I had some issues after upgrading too, with both the Antivirus and MySQL, resolved with the help of steps provided by Daniel - thank you!

Hi,

We are debugging the antivirus issue, we believe three things should be analyzed:

1. The server was not rebooted after the upgrade, so the directory /var/run/clamav does not belong to the owner clamav.


 Ensure the directory /var/run/clamav belongs to clamav as chapderprinz suggested.
   
    sudo chown -R clamav /var/run/clamav/
   
4. Restart the module through the CLI:
   
    sudo zs antivirus restart
   

... <snip> ..

Best regards, Daniel Joven.

That fixed the same antivirus issue for us.

And the MySQL error on trying to login:

Code: [Select]

2024/04/26 11:04:02 ERROR> MyDBEngine.pm:200 EBox::MyDBEngine::_connect - Connection DB Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
 at Connection DB Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
 at /usr/share/perl5/EBox/MyDBEngine.pm line 200

The following fixed that issue (copied from another post by Daniel and edited down a bit):

check mysql running status:

   

Code: [Select]

sudo systemctl status mysql   
Status, inactive:

Code: [Select]

○ mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
   
If it is stopped (inactive), run the following commands:
   

Code: [Select]

mkdir /var/log/mysql/
    chown -R mysql:adm /var/log/mysql
    chmod -R 0770 /var/log/mysql
    systemctl restart mysql   

Status Update on 29/04/2024 - issues returned
Issues continue:  We have been getting intermittent network connectivity issues since the upgrade, with users on DHCP leased IP's.  Static IP systems (couple of users and various printers and servers) seem unaffected - I am suspecting the DHCP, but not totally sure it is the issue.  Our address elase time was very short (2 hours), so have updated this to a 24-hour lease duration.

Looking at the /var/log/syslog file we also see several entries for the following error that seems to relate to DNS:

Code: [Select]

Apr 29 09:28:43 titan sh[3185911]: ERROR(runtime): uncaught exception - (5, 'WERR_ACCESS_DENIED')
Apr 29 09:28:43 titan sh[3185911]:   File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 186, in _run
Apr 29 09:28:43 titan sh[3185911]:     return self.run(*args, **kwargs)
Apr 29 09:28:43 titan sh[3185911]:   File "/usr/lib/python3/dist-packages/samba/netcmd/dns.py", line 1235, in run
Apr 29 09:28:43 titan sh[3185911]:     raise e
Apr 29 09:28:43 titan sh[3185911]:   File "/usr/lib/python3/dist-packages/samba/netcmd/dns.py", line 1223, in run
Apr 29 09:28:43 titan sh[3185911]:     dns_conn.DnssrvUpdateRecord2(dnsserver.DNS_CLIENT_VERSION_LONGHORN,

But are unsure if this had anyhting to do with the connectivity issues, as the entry occured again more recently in the file (12:17), but no-one raised query that it had given them a problem at that time.

Additionally, the AntiVirus and MySql issues returned on our PDC (which also runs the DHCP service), with the antivirus stopping and not restarting.
Tried to reset the permission on the clamav folder, but result was the directory not found:

Code: [Select]

sudo chown -R clamav /var/run/clamav/
chown: cannot access '/var/run/clamav/': No such file or directory
So as per the upgrade guidance instructions on https://doc.zentyal.org/en/upgrade.html#antivirus-module re-ran the dpkg command for clamav:

Code: [Select]

sudo dpkg-reconfigure clamav-daemon
Service still failed to start.  Result in the error log showed:

Code: [Select]

Mon Apr 29 11:48:30 2024 -> ERROR: LOCAL: Could not create socket directory: /var/run/clamav: Permission denied
47 Mon Apr 29 11:48:30 2024 -> ERROR: LOCAL: Socket file /var/run/clamav/clamd.ctl could not be bound: No such file or directory

I re-ran the clamav config

Code: [Select]

sudo dpkg-reconfigure clamav-daemon
This time,  I selected YES to handling the configuration file automatically - the opposite to the upgrade guidance.  Went through that accepting the defaults - it recreated the missing /var/run/clamav/ folder for us, and added the missing clamd.ctl file.
This seems to have sorted it, the service has remained running for the last 15 minutes...

MySQL
The mysql error occurred again when trying to check the DHCP module from the web admin (though the dashboard was displaying OK).

Checked the mysql status in CLI:

Code: [Select]

~$ sudo systemctl status mysql
[sudo] password for copeadmin:
○ mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; disabled; vendor preset: enabled)
     Active: [b]inactive[/b] (dead)

Checked the current permissions in the mysql log directory:

Code: [Select]

~$ sudo ls -lh /var/log/mysql
total 12K
-rw-r----- 1 mysql adm     0 Apr 29 00:00 error.log
-rw-r----- 1 mysql adm    20 Apr 28 00:00 error.log.1.gz
-rw-r----- 1 mysql adm    20 Apr 27 00:00 error.log.2.gz
-rw-r----- 1 mysql mysql 942 Apr 26 19:05 error.log.3.gz
Note the difference in owner for file dated 26/04, when it ought to match the other 3 files (mysql:adm).  This had previously been corrected on 26/04 in the morning.  I had rebooted the server after office hours, but afraid I can't recall exact time - I don't think it was as late as 19:00 though.

So reapplied the permission chown commands:

Code: [Select]

sudo chown -R mysql:adm /var/log/mysql
sudo chmod -R 0770 /var/log/mysql
Result:

Code: [Select]

~$ sudo ls -lh /var/log/mysql
total 12K
-rwxrwx--- 1 mysql adm   0 Apr 29 00:00 error.log
-rwxrwx--- 1 mysql adm  20 Apr 28 00:00 error.log.1.gz
-rwxrwx--- 1 mysql adm  20 Apr 27 00:00 error.log.2.gz
-rwxrwx--- 1 mysql adm 942 Apr 26 19:05 error.log.3.gz

And then restarted mysql again.

sudo systemctl restart mysql

And check status again - OK:

Code: [Select]

~$ sudo systemctl status mysql
● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; disabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-04-29 10:24:57 BST; 4s ago
    Process: 3236229 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
   Main PID: 3236248 (mysqld)
     Status: "Server is operational"
      Tasks: 39 (limit: 7071)
     Memory: 437.9M
        CPU: 1.527s
     CGroup: /system.slice/mysql.service
             └─3236248 /usr/sbin/mysqld
So it's OK again for now - but worrying I had to re-apply the permission changes on the log directory again.  I don't want to be having to re-apply this every day!