A one-click security vulnerability CVE-2023-41106 in all versions of Zimbra Collaboration Suite has been discovered that could allow an unauthenticated attacker to gain access to a Zimbra account.
To fix this vulnerability install the latest Zimbra patch (by using apt or yum), the vulnerability is fixed in: Daffodil 10.0.3, 9.0.0 Kepler Patch 35, 8.8.15 Joule Patch 42
Discuss here:
viewtopic.php?t=72204
Discuss your pilot or production implementation with other Zimbra admins or our engineers.
My SQL server is no longer starting... Anyone got an idea?
081128 11:32:42 mysqld started
081128 11:32:43 [Warning] Setting lower_case_table_names=2 because file system for /opt/zimbra/db/data/ is case insensitive
InnoDB: Log scan progressed past the checkpoint lsn 0 360347210
081128 11:32:44 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 360348882
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 4 row operations to undo
InnoDB: Trx id counter is 0 1089536
081128 11:32:45 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
081128 11:32:45 InnoDB: Rolling back trx with id 0 1089029, 4 rows to undo
InnoDB: Error: trying to access page number 251678080 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
081128 11:32:45InnoDB: Assertion failure in thread 2955448320 in file fil0fil.c line 3959
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to MySQL Bugs.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: MySQL :: MySQL 5.0 Reference Manual :: 13.2.7.1 Forcing InnoDB Recovery
InnoDB: about forcing recovery.
081128 11:32:45 - mysqld got signal 10;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=0
read_buffer_size=1044480
max_used_connections=0
max_connections=110
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 224839 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
081128 11:32:45 mysqld ended
What doesn 'zmcontrol status' show? Is there anything significatnt in any of the log files? Have you tried these troubleshooting pages?
[url=Mysql Crash Recovery - Zimbra :: Wiki
Well after the panic I figured out it was the mysql database that was corrupted... I just copied the db folder from an earlier backup and lost one day of mails (whine whine whine)...
Your solution looks more reliable, but still would have lost the corrupted bit of mails...
Marked as Solved
