F8 & F9 (i386/i686): Problems with sendmail & dovecot

[Daniel B. Thurman]

Bill Davidsen wrote:
>
> Daniel B. Thurman wrote:
>
> you quoted this without reading some of it...
>
> >
> > The /var/log/maillog shows:
> > =====================
> > Aug  1 16:20:06 gold sendmail[3269]: NOQUEUE: SYSERR(root):
> > /etc/mail/sendmail.cf: line 97: fileclass: cannot open
> > '/etc/mail/local-host-names': Group writable directory
>                                                 ^^^^^^^^^
>
> I would bet that /etc/mail is group writable. Or possibly /etc itself!
>
I checked.  /etc nor /etc/mail is group writable.  Both are 0755
mode.

I noticed that this problem happened in both f8 and f9.  I did
not have this problem until very recently and I was running f8
for awhile and did not have this problem whatsoever - until
when I posted this message. It was worth a try tho - but alas,
no dice.
>
> > Aug  1 16:20:06 gold sendmail[3269]: NOQUEUE: SYSERR(root):
> > /etc/mail/sendmail.cf: line 619: fileclass: cannot open
> > '/etc/mail/trusted-users': Group writable directory
> > Aug  1 16:20:06 gold sendmail[3273]: NOQUEUE: SYSERR(root):
> > /etc/mail/sendmail.cf: line 97: fileclass: cannot open
> > '/etc/mail/local-host-names': Group writable directory
> > Aug  1 16:20:06 gold sendmail[3273]: NOQUEUE: SYSERR(root):
> > /etc/mail/sendmail.cf: line 619: fileclass: cannot open
> > '/etc/mail/trusted-users': Group writable directory
> > Aug  1 16:20:06 gold sendmail[3273]: NOQUEUE: SYSERR(root):
> > /etc/mail/sendmail.cf: line 1743: Xclamav-milter: local socket name
> > /var/run/clamav-milter/clamav.sock unsafe: Group writable directory
> > Aug  1 16:20:06 gold sm-msp-queue[3280]: NOQUEUE: SYSERR(root):
> > /etc/mail/submit.cf: line 554: fileclass: cannot open
> > '/etc/mail/trusted-users': Group writable directory
> > Aug  1 09:22:58 gold dovecot: Time just moved backwards by 25199
> > seconds. This might cause a lot of problems, so I'll just kill myself
> > now. http://wiki.dovecot.org/TimeMovedBackwards
> >
> > Note the last line: I already posted a date/time setting problem in a
> > seperate thread.
> > Date/Time randomly changes either in the future or in the past upon a
> > reboot and
> > no, it's not the BIOS battery - it is brand new!
> >
> > I checked the permissions in /etc/mail and all of the file there shows
> > no group writable permissions:
> >
> > /etc/mail:
> > =======
> > -rw-r--r-- 1 root root  7178715 2008-01-14 18:35 access
> > -rw-r----- 1 root root 10334208 2008-01-14 18:35 access.db
> > -rw-r--r-- 1 root root       84 2008-01-25 12:44 authinfo
> > -rw-r----- 1 root root    12288 2008-01-25 12:44 authinfo.db
> > drwxr-xr-x 2 root root     4096 2008-01-25 13:57 backup
> > -rw-r--r-- 1 root root      233 2007-11-22 05:53 domaintable
> > -rw-r----- 1 root root    12288 2008-01-07 15:29 domaintable.db
> > -rw-r--r-- 1 root root       45 2008-01-09 16:54 generics-domains
> > -rw-r--r-- 1 root root      347 2008-06-14 10:59 genericstable
> > -rw-r----- 1 root root    12288 2008-06-14 11:40 genericstable.db
> > -r--r--r-- 1 root root     5584 2007-11-22 05:53 helpfile
> > -rw-r--r-- 1 root root       94 2008-07-04 17:43 local-host-names
> > -rw-r--r-- 1 root root      997 2007-11-22 05:53 mailertable
> > -rw-r----- 1 root root    12288 2008-01-07 15:29 mailertable.db
> > -rw-r--r-- 1 root root     1048 2007-11-22 05:53 Makefile
> > -rw-r--r-- 1 root root    60875 2008-01-26 14:04 sendmail.cf
> > -rw-r--r-- 1 root root    60985 2008-01-26 13:55 sendmail.cf.bak
> > -rw-r--r-- 1 root root     7988 2008-01-26 14:04 sendmail.mc
> > drwxr-xr-x 2 root root     4096 2008-06-28 15:53 spamassassin
> > -r--r--r-- 1 root root    41716 2007-11-22 05:53 submit.cf
> > -rw-r--r-- 1 root root      941 2007-11-22 05:53 submit.mc
> > -rw-r--r-- 1 root root      154 2008-01-09 17:53 trusted-users
> > -rw-r--r-- 1 root root     2715 2008-06-14 10:57 virtusertable
> > -rw-r----- 1 root root    12288 2008-06-14 11:40 virtusertable.db
> >
> > Hmm... what seems to be the problem here?
>
> Keep your hardware clock in UTC. Everywhere. The most common cause of
> this is the clock is in UTC in Linux and the machine is infected with a
> trojan called "Windows" which defaults to local time. It will run
> hardware clock in UTC, you just have to slap it up aside the registry.
> Sorry, I haven't fixed this for anyone in several years, you have to
> look up how to do this, but that's *very* likely to be the problem.
>
But as I said above, why now?  I did not have this problem before
so perhaps the latest update from M$ was a volley -or- a new fX
update tripped it up?  That could very well be the issue w/ M$ - but
of course, I am speculating :-O  I will of course look into the M$
registry thing.
>
> I suggest running ntpd to keep your clock accurate, but that's not any
> part of this problem.
>
Once I get the clock manually adjusted correctly, ntp works great!
Unfortunately, a reboot will force a repeat adjustment.  Sigh.

Dan