Koozali.org: home of the SME Server
Obsolete Releases => SME Server 8.x => Topic started by: Fumetto on December 22, 2013, 08:10:45 AM
-
I have 2 server with strange (for me) problem after last update (to do: Don't update server the day before you have to go on vacation).
Update package is:
Dec 20 16:46:06 Updated: php-common-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:07 Updated: php-cli-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:08 Updated: php-pdo-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:09 Updated: smeserver-locale-ro-2.2.0-45.el5.sme.noarch
...
Dec 20 16:46:33 Updated: smeserver-locale-nl-2.2.0-45.el5.sme.noarch
Dec 20 16:46:33 Updated: php-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:36 Updated: nss-3.15.3-4.el5_10.x86_64
Dec 20 16:46:37 Updated: libdar-2.4.11-1.el5.sme.x86_64
Dec 20 16:46:38 Updated: dar-2.4.11-1.el5.sme.x86_64
Dec 20 16:46:39 Updated: php-mysql-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:40 Updated: php-mbstring-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:40 Updated: php-ldap-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:40 Updated: php-gd-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:41 Updated: php-xml-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:42 Updated: php-imap-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:44 Updated: qpsmtpd-0.84-7.el5.sme.noarch
Dec 20 16:46:49 Updated: tzdata-2013i-1.el5.x86_64
Dec 20 16:46:51 Updated: e-smith-backup-2.2.0-76.el5.sme.noarch
Dec 20 16:46:53 Updated: php-devel-5.3.3-14.el5.sme.x86_64
Dec 20 16:46:55 Updated: smeserver-support-2.2.0-25.el5.sme.noarch
One of these servers is configured to do full backup on Saturday night, the other for the Sunday night.
Now...
On Server1 (full backup Saturday) I have a mail for full backup "successfully terminated".
After this, Sunday I have a mail with some "error"...
Backup of server.domain.it started at Sun Dec 22 00:10:04 2013
Backup of mysql databases has been done
Mounting backup shared directory <192.168.16.50:volume1/BackupServerSme>
Using set number 2 of 2
Attempt incremental backup number 1 of 6
Backup temp directory /mnt/smb/tmp_dir/server.domain.it is mounted and is writable
Backup base file name is inc-001-201312220010
Starting the backup with a timeout of : 28770 seconds
SECURITY WARNING! SUSPICIOUS FILE /etc/samba/smbpasswd: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /home/e-smith/ssl.key/server.domain.it.key: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /home/e-smith/files/users/USERNAME/Maildir/.Posta eliminata/cur/1387052948.P7247Q0M301555.server:2,DS: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /home/e-smith/ssl.crt/server.domain.it.crt: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /home/e-smith/ssl.pem/server.domain.it.pem: ctime changed since archive of reference was done, while no other inode information changed
...
On Server2 (full backup Sunday) I have a mail of saturday from Cron daemon:
From: Cron Daemon
Subject: Cron <root@server> /sbin/e-smith/do_backupwk
Some files do not follow chronological order when archive index increases withing the database, this can lead dar_manager to restored a wrong version of these files
Dates of file's data are not increasing when database's archive number grows. Concerned file is: etc/e-smith/web
Dates are not increasing for all files when database's archive number grows, working with this database may lead to improper file's restored version. Please reorder the archive within the database in the way that the older is the first archive and so on up to the most recent archive being the last of the database
Error met while processing operation: Some files do not follow chronological order when archive index increases withing the database, this can lead dar_manager to restored a wrong version of these files
Failed to add set /mnt/smb/server.domain.it/set0/inc-006-201312210040 to catalog.
Backup terminated: backup failed - status: 7424and a mail from admin-backup with many error and "Daily Backup Failed":
Backup of server.domain.it started at Sat Dec 21 00:40:02 2013
Backup of mysql databases has been done
Mounting backup shared directory <192.168.16.50:volume1/BackupServerSme>
Using set number 1 of 2
Attempt incremental backup number 6 of 6
Backup temp directory /mnt/smb/tmp_dir/server.domain.it is mounted and is writable
Backup base file name is inc-006-201312210040
Starting the backup with a timeout of : 28770 seconds
SECURITY WARNING! SUSPICIOUS FILE /root/.mc/ini: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.mc/history: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.mc/Tree: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.rnd: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.bash_profile: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/install.log: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.my.cnf: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.tcshrc: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.bashrc: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/install.log.syslog: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.cshrc: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/.bash_logout: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /root/anaconda-ks.cfg: ctime changed since archive of reference was done, while no other inode information changed
SECURITY WARNING! SUSPICIOUS FILE /home/e-smith/Maildir/cur/1385509278.11385.server:2,S: ctime changed since archive of reference was done, while no other inode information changed
...
--------------------------------------------
901 inode(s) saved
including 260 hard link(s) treated
0 inode(s) changed at the moment of the backup and could not be saved properly
0 byte(s) have been wasted in the archive to resave changing files
38733 inode(s) not saved (no inode/file change)
0 inode(s) failed to be saved (filesystem error)
254 inode(s) ignored (excluded by filters)
325 inode(s) recorded as deleted from reference backup
--------------------------------------------
Total number of inode(s) considered: 40213
--------------------------------------------
EA saved for 0 inode(s)
--------------------------------------------
Moving backup files to target directory /mnt/smb/server.domain.it/set0
Updating catalog
*** No backup allowed or error during backup ***
Failed to add set /mnt/smb/server.domain.it/set0/inc-006-201312210040 to catalog.If print email I have 1500 :shock: pages of error like this...
After this, Sunday I have a mail with "Backup successfully terminated at : Sun Dec 22 01:49:41 2013"
I try search and found this page (http://dar.linux.free.fr/doc/FAQ.html#security) with explanation (not very clear because of my limited knowledge) and many other page with references to version 2.4 of DAR.
Should I be worried? Need a bug report?
-
Same issue here.
http://bugs.contribs.org/show_bug.cgi?id=8079
Note: With dar version older than 2.4.0 (by default, unless -aa option is use) once a file has been read for backup, dar set back the atime to the value it had before dar read it. This trick was used to accomodate some programs like leafnode (NNTP caching program) that base their cache purging scheme on the atime of files. When you do a backup using dar 2.3.11 for example, file that had their mtime modified are saved as expected and their atime is set back to their original values (value they had just before dar read them), which has the slide effect to modify the ctime. If then you upgrade to dar 2.4.0 or more recent and do a differential backup, if that same file has not been modified since, dar will see that the ctime has changed while no other metadata did (user, ownership, group, mtime), thus this alarm message will show for all saved files in the last 2.3.11 archive made. The next differential backup made using dar 2.4.0 (or more recent), the problem will not show anymore.
Last sentence suggest that when another backup is done, problem will go away.
I kicked off another backup but the same messages still appeared..
-
Fumetto
Were your SME Servers clean built from a V8 CD or were they upgraded with a disk from V7.x ?
Cheers
Peter
-
Clean build V8 64 bit
-
Hi guys,
all my servers give give this error too. Both fresh v8 servers as well as upgraded servers from v7
Regards,
Taco
-
Are you also doing differential backups ? I intend to throw away the old backup and see what happens then. Do you have any other suggestions ?
-
Have you been following Bug 8076 (http://bugs.contribs.org/show_bug.cgi?id=8076)
-
Didn't, sorry
Following that bug now
-
I note that bug report is now closed and marked as fixed.
Still getting this SECURITY WARNING! SUSPICIOUS FILE /etc/samba/smbpasswd: ctime changed since archive of reference was done, while no other inode information changed
in an incremental backup against a full backup that has been created with the "fix".
Should I be worried ??
P
-
I am also getting the same error (as below) with my incremental backups - the full backups are fine, as the bug is closed should I create a new one or am I missing something?
I note that bug report is now closed and marked as fixed.
Still getting this
Quote
SECURITY WARNING! SUSPICIOUS FILE /etc/samba/smbpasswd: ctime changed since archive of reference was done, while no other inode information changed
in an incremental backup against a full backup that has been created with the "fix".
Should I be worried ??
P
-
rans0000
refer to comments in Bug 8076 http://bugs.contribs.org/show_bug.cgi?id=8076
P
-
Thanks, p
-
I have a question.
From the "error" it seems that it is only to change the ctime of a few files. Usually this is due to a change of ownership of the file.
The changes affect users' files on Ibay, file of mail folders (include .procmailrc .mailsortingrc ...), files of db (/home/e-smith/db/...) and other.
If for the file on Ibay I believe that the ownership can change, I don't think so for the email files.
It's possible that this error depends on the fact that, during the backup, the system do a cron jobs and this changes the owner of certain files?
-
rans0000
Would someone please raise a new bug as suggested in
http://bugs.contribs.org/show_bug.cgi?id=8076#c22
-
Janet
i tried to here http://bugs.contribs.org/show_bug.cgi?id=8133 (http://bugs.contribs.org/show_bug.cgi?id=8133)
Not shure, if this is NFR or bug-fix, but the gurus will find that out. These error-messages are nervewrecking, time-consuming and made several incremental backups fail here (for timeout-reasons). If i have to rely on this backup-functions, it should work flawlessly like it did before; at least it is a key feature of SME and AFFA (which is use parallel for increased security) seems to get obsolete.
-
These error-messages are sucessfully suppressed now. Ian built a fix for SME 8, that suppresses these ctime errors - many thanks for that. You can download and install the patch by editing:
yum --enablerepo=smetest install e-smith-backup-2.2.0-82.el5.sme
-
i tried to here http://bugs.contribs.org/show_bug.cgi?id=8133 (http://bugs.contribs.org/show_bug.cgi?id=8133)
Thank You.
A good, well-written, bug report makes it easier to identify the root cause of the problem and fix it.
I'm glad that you raised the bug and clearly identified the problem. Also glad that the fix works.