[opensuse] Rsync and Procmail resource file issue...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Just been tracking down a problem which I have finally pinned down to some issues with the local procmail config file (~/.procmailrc) and its permissions and contents. The end result was that incoming mail was accepted but not delivered to the local account correctly. Somehow after a rsync run to perform a backup of the file structure the permissions to the file seems to have effectively changed (and also possibly the contents). As procmail is only called for mailbox delivery and is not a daemon, any changes in procmail causing this problem should have become evident before the update, so this would suggest that rsync is involved somewhere. To further confirm this there have been some slight changes in spamd start messages which do not seem be affecting its operation, but may indicate a change in this applications behaviour possibly for similar reasons. This needs further investigation before I can figure out what exactly is going on, and how serious any other damage (if it exists) really is, and whether rsync is involved. However, I was wondering if anyone has come across similar issues with rsync. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkti1KEACgkQasN0sSnLmgI8+ACffyUneqoQLxivaS4ZxwpPAsJj OlQAnigAemZVv+OYgipfVTM4InKIIjW3 =1j8W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
G T Smith wrote:
-----BEGIN PGP SIGNED MESSAGE----- Somehow after a rsync run to perform a backup of the file structure the permissions to the file seems to have effectively changed (and also possibly the contents). As procmail is only called for mailbox delivery and is not a daemon, any changes in procmail causing this problem should have become evident before the update, so this would suggest that rsync is involved somewhere.
rsync is very widely used so it seems unlikely that there is a problem of this nature. If I understood what you're suggesting, it would involve rsync reopening a file that it's reading from in order to write to it, or executing operations that mutate the state of the source filesystem, all of which seem unlikely. Certainly I've never seen any such issues. So personally I'd spend my effort looking in other directions unless and until you find a smoking gun. If you did want to pursue the rsync angle, I guess the rsync mailing list would be the best place. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2010-01-29 at 12:29 -0000, G T Smith wrote:
Just been tracking down a problem which I have finally pinned down to some issues with the local procmail config file (~/.procmailrc) and its permissions and contents. The end result was that incoming mail was accepted but not delivered to the local account correctly.
Check that the owner of the home directory and the ~/.procmailrc are the same: cer@nimrodel:~> l ~/.procmailrc - -rw------- 1 cer users 24554 2009-12-16 15:26 /home/cer/.procmailrc ·············XXX····································XXX cer@nimrodel:~> l /home | grep `whoami` drwxr-xr-x 211 cer users 28672 2010-01-29 15:28 cer/ ···············XXX·····································XXX If they are not, correct as appropiate. And don't blame rsync: you'd have copied across different UIDs (my educated guess). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkti8gkACgkQtTMYHG2NR9U/sACdFhbwtM0JZDtsr26mEAoDHCfL waEAoJaPauuxWNNyJsP0LSvHPKbHcTiG =QtO5 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos E. R. wrote:
On Friday, 2010-01-29 at 12:29 -0000, G T Smith wrote:
Just been tracking down a problem which I have finally pinned down to some issues with the local procmail config file (~/.procmailrc) and its permissions and contents. The end result was that incoming mail was accepted but not delivered to the local account correctly.
Check that the owner of the home directory and the ~/.procmailrc are the same:
cer@nimrodel:~> l ~/.procmailrc -rw------- 1 cer users 24554 2009-12-16 15:26 /home/cer/.procmailrc ·············XXX····································XXX
cer@nimrodel:~> l /home | grep `whoami` drwxr-xr-x 211 cer users 28672 2010-01-29 15:28 cer/ ···············XXX·····································XXX
If they are not, correct as appropiate.
And don't blame rsync: you'd have copied across different UIDs (my educated guess).
-- Cheers, Carlos E. R.
This would make sense (the file system has a lot of artifacts from a 500 base to 1000 UID base change... a long story dont ask :-) ). However, the user ownership was correct, but the actual rights had become too insecure for procmail to allow use of the file. More recent versions of procmail are a bit picky about this, but if procmail had been updated one would have expected problems from the time of update, *not* a later run of rsync. It also does not explain possible changes in the contents of .procmailrc that caused the procmail operation to stop functioning as expected immediately after rsync was used. The rsyncd daemon was running to facilitate rsync from a second machine, while the command line form was used to facilitate local use with a USB drive (but obviously these were not synced at the same time). A local rsync had already been run without apparent problems before (but rsyncd was only recently re-enabled). The difficulty here is that this event was only noticed because it effected a critical file, which begs the question what else (if anything) may have been compromised by earlier runs or this run. The difficulty is that primary observation (i.e. comparing files before and after) is currently not an option, all we have is secondary observation (i.e. a change in behaviour before and after an action). The latter is not conclusive. I do have copies of the original file elsewhere, but the scripts concerned with extraction are in the middle of a massive rewrite and will not be available for a little while. The file has not been directly changed for months, this when recovered should help narrow things down a bit. I am not ruling anything out as a cause at the moment as there are other possibilities, but until I can eliminate rsync as a cause I do not intend to use it. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktkGVIACgkQasN0sSnLmgLGVACaA4/mKhQbeSo6SQuKczBdaCig AgEAni9qzpAGcbr9vKKg+cZR/xih5QLu =mwTv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Carlos E. R.
-
Dave Howorth
-
G T Smith