Author Topic: My failed attempt at upgading from 7.1.1 to Zentyal 8.0  (Read 2489 times)

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #15 on: April 29, 2024, 10:35:52 am »
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

  • Zen Apprentice
  • *
  • Posts: 15
  • Karma: +1/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #16 on: April 29, 2024, 01:24:07 pm »
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):
Quote
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!

« Last Edit: April 29, 2024, 01:48:24 pm by AlecM »

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #17 on: April 30, 2024, 09:38:21 am »
Hi AlecM,

About the mysql issue, a few things I saw in your output:

1. The service is not enabled, so when the server is rebooted, it does not start.
   
Code: [Select]
    # To confirm that it is disabled
    sudo systemctl is-enabled mysql
   
    # To enable
    sudo systemctl enable mysql
   
   
2. The permission behavior is probably caused by logrotate, you can check this out by analyzing the configuration file /etc/logrotate.d/mysql-server

NOTE: You should check the permissions of the folder as well (sudo ls -ld /var/log/mysql/)

If it is possible, just fix step 1 and only check step 2 but do not make any changes, let’s see tomorrow when the system rotates the logs if the issue is fixed or if a change must be done in the mentioned configuration file.

AlecM

  • Zen Apprentice
  • *
  • Posts: 15
  • Karma: +1/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #18 on: April 30, 2024, 02:29:12 pm »
Thanks Daniel!
You were quite correct, our mysql was not set to start with the system.
Code: [Select]
~$ sudo systemctl is-enabled mysql
disabled
So enabled as you indicated:
Code: [Select]
~$ sudo systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql
Created symlink /etc/systemd/system/multi-user.target.wants/mysql.service → /lib/systemd/system/mysql.service.

Checked the permissions on the log folder - I think it's correct? (mysql:adm)
Code: [Select]
~$ sudo ls -ld /var/log/mysql/
drwxrwx--- 2 mysql adm 4096 Apr 30 00:00 /var/log/mysql/


gabor.strama

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +5/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #19 on: April 30, 2024, 04:12:39 pm »
Hi Daniel,

Here is the requested logs...
https://nextcloud.bemutatjuk.eu/index.php/s/s83n9s4oc8rGLH2

Please let me know if you need more information in this case.



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

  • Zen Apprentice
  • *
  • Posts: 15
  • Karma: +1/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #20 on: May 01, 2024, 03:30:59 pm »
Thanks Daniel!
You were quite correct, our mysql was not set to start with the system.
Code: [Select]
~$ sudo systemctl is-enabled mysql
disabled
So enabled as you indicated:
Code: [Select]
~$ sudo systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql
Created symlink /etc/systemd/system/multi-user.target.wants/mysql.service → /lib/systemd/system/mysql.service.

Checked the permissions on the log folder - I think it's correct? (mysql:adm)
Code: [Select]
~$ sudo ls -ld /var/log/mysql/
drwxrwx--- 2 mysql adm 4096 Apr 30 00:00 /var/log/mysql/

Thanks again Daniel.  I have just checked the service status after 24 hours, to allow for log rotation, and happy to report that it is still "enabled" at this point:

Code: [Select]
~$ sudo systemctl is-enabled mysql
enabled

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #21 on: May 02, 2024, 12:22:16 pm »
Thanks Daniel!
You were quite correct, our mysql was not set to start with the system.
Code: [Select]
~$ sudo systemctl is-enabled mysql
disabled
So enabled as you indicated:
Code: [Select]
~$ sudo systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql
Created symlink /etc/systemd/system/multi-user.target.wants/mysql.service → /lib/systemd/system/mysql.service.

Checked the permissions on the log folder - I think it's correct? (mysql:adm)
Code: [Select]
~$ sudo ls -ld /var/log/mysql/
drwxrwx--- 2 mysql adm 4096 Apr 30 00:00 /var/log/mysql/

Thanks again Daniel.  I have just checked the service status after 24 hours, to allow for log rotation, and happy to report that it is still "enabled" at this point:

Code: [Select]
~$ sudo systemctl is-enabled mysql
enabled

Hi,

Please, can you confirm that the Mysql log rotations are not breaking the service and everything is working as expected once you have enabled the service?

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #22 on: May 02, 2024, 12:35:13 pm »
Hi Daniel,

Here is the requested logs...
https://nextcloud.bemutatjuk.eu/index.php/s/s83n9s4oc8rGLH2

Please let me know if you need more information in this case.

Hi,

I cannot determine why the module is being removed. According to the log files, the package 'zentyal-sogo 8.0.0' is installed but for some reason, it is uninstalled later. What about the results of the commands I mentioned to you?


gabor.strama

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +5/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #23 on: May 02, 2024, 02:30:38 pm »
Hi David,

You mean this command:
sudo apt policy zentyal-sogo
sudo apt policy sogo
sudo apt policy gnustep-base-common

It is not solve the issue, but produce same error message:

The following packages have unmet dependencies:
libgnustep-base1.26 : Depends: gnustep-base-common (= 1.26.0-7) but 1.28.0-4build1 is to be installed
Depends: libicu66 (>= 66.1-1~) but it is not installable


BR,
GáborS

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #24 on: May 02, 2024, 02:56:35 pm »
Hi David,

You mean this command:
sudo apt policy zentyal-sogo
sudo apt policy sogo
sudo apt policy gnustep-base-common

It is not solve the issue, but produce same error message:

The following packages have unmet dependencies:
libgnustep-base1.26 : Depends: gnustep-base-common (= 1.26.0-7) but 1.28.0-4build1 is to be installed
Depends: libicu66 (>= 66.1-1~) but it is not installable


BR,
GáborS

The goal of those commands is to get more information about your Zentyal, concretely, for your repositories.

gabor.strama

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +5/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #25 on: May 02, 2024, 08:48:36 pm »
Hi David,

Here is the output:

root@mail:/home/strama_admin# sudo apt policy zentyal-sogo
zentyal-sogo:
  Telepítve: (nincs)
  Jelölt:    8.0.0
  Verziótáblázat:
     8.0.0 500
        500 https://packages.zentyal.org/zentyal 8.0/main amd64 Packages
        500 https://packages.zentyal.org/zentyal 8.0/main i386 Packages
     7.0.0 500
        500 file:/var/tmp/zentyal-packages ./ Packages

root@mail:/home/strama_admin# sudo apt policy sogo
sogo:
  Telepítve: (nincs)
  Jelölt:    5.5.1-1
  Verziótáblázat:
     5.5.1-1 500
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
     5.0.1.20201214-1 500
        500 file:/var/tmp/zentyal-packages ./ Packages
root@mail:/home/strama_admin#

root@mail:/home/strama_admin# sudo apt policy gnustep-base-common
gnustep-base-common:
  Telepítve: (nincs)
  Jelölt:    1.28.0-4build1
  Verziótáblázat:
     1.28.0-4build1 500
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe i386 Packages
     1.26.0-7 500
        500 file:/var/tmp/zentyal-packages ./ Packages
root@mail:/home/strama_admin#

Please let me know if you needm ore information.

BR,
GáborS

Daniel Joven

  • Zentyal Staff
  • Zen Monk
  • *****
  • Posts: 69
  • Karma: +21/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #26 on: May 03, 2024, 09:49:45 am »
Hi David,

Here is the output:

root@mail:/home/strama_admin# sudo apt policy zentyal-sogo
zentyal-sogo:
  Telepítve: (nincs)
  Jelölt:    8.0.0
  Verziótáblázat:
     8.0.0 500
        500 https://packages.zentyal.org/zentyal 8.0/main amd64 Packages
        500 https://packages.zentyal.org/zentyal 8.0/main i386 Packages
     7.0.0 500
        500 file:/var/tmp/zentyal-packages ./ Packages

root@mail:/home/strama_admin# sudo apt policy sogo
sogo:
  Telepítve: (nincs)
  Jelölt:    5.5.1-1
  Verziótáblázat:
     5.5.1-1 500
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
     5.0.1.20201214-1 500
        500 file:/var/tmp/zentyal-packages ./ Packages
root@mail:/home/strama_admin#

root@mail:/home/strama_admin# sudo apt policy gnustep-base-common
gnustep-base-common:
  Telepítve: (nincs)
  Jelölt:    1.28.0-4build1
  Verziótáblázat:
     1.28.0-4build1 500
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        500 http://hu.archive.ubuntu.com/ubuntu jammy/universe i386 Packages
     1.26.0-7 500
        500 file:/var/tmp/zentyal-packages ./ Packages
root@mail:/home/strama_admin#

Please let me know if you needm ore information.

BR,
GáborS

Hi GáborS,

The initial local repository of Zentyal that is set when Zentyal is installed through the ISO file is still active and because of that, the behavior you get. You must search for the following repository and remove it:

Code: [Select]
deb [trusted=yes] file://file:/var/tmp/zentyal-packages ./

It might be located at /etc/apt/sources.list.d/zentyal-temporal.list , /etc/apt/sources.list or in a similar location.

Once you find it, remove it and then, run the following command:

Code: [Select]
sudo apt update

After that, you should be able to install zentyal-sogo package.

gabor.strama

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +5/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #27 on: May 11, 2024, 03:11:57 pm »
Hi David,

Thank you for your huge help,
yesterday I took a big breath and I started the upgrade on my live server, but as usual, I faced another issue:
 frr : Függ ettől: libjson-c4 (>= 0.13.1) de az nem telepíthető
       Függ ettől: libyang0.16 (>= 0.16.74) de az nem telepíthető

Please can you help?

BR,
GáborS

gabor.strama

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +5/-0
    • View Profile
Re: My failed attempt at upgading from 7.1.1 to Zentyal 8.0
« Reply #28 on: May 11, 2024, 04:33:28 pm »
Hi David,

I found a solution, the ESM repository is not updated from focal to jammy therefore lots of packages will stuck on focal.
May I suggest something into the upgrade article "disable all of extended or external repository source list, example: ESM, third party repo, etc)" or something similar... :-)

BR,
GáborS