I was getting this error in my log files:
dovecot: IMAP(user): Time just moved backwards by 1 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards: 1 Time(s)
Looking at the website that was linked in the error message (very helpful), the solution was to edit /etc/ntp.conf and add the following:
# Added following to get rid of dovecot "Time moved backwards" error tinker step 0
Restart ntpd and after two days the error stopped showing up in my logs. Yay!
After a drive failure on one of our servers, I had to remake the quota info. Here’s what I did:
[root@serv1 home]# touch /local/home/aquota.user [root@serv1 home]# chmod 600 /local/home/aquota.user [root@cppc home]# quotacheck -vgum /local/home quotacheck: WARNING - Quotafile /local/home/aquota.user was probably truncated. Can't save quota settings... quotacheck: Scanning /dev/sda1 [/local/home] |
Now I could just reset all the user quotas for things to work.
[root@serv1 home]# setquota -u user1 1000000 1500000 200000 300000 -a
I had already mounted the disk with the correct options, but make sure /etc/fstab looks like:
/dev/sda1 /local/home ext3 defaults,usrquota 1 2
I also then also restarted nfslock, which may or may not have needed to be done. This could have been a totally unrelated problem we were having at the same time.
After installing a new copy of alpine, use the previously saved remote_pinerc file to set everything up. To do this, open a command window and start alpine from the command line and add the remote config file to the command line. If our username is arthur and the remote_pinerc file is on server.example.com, it will look something like this:
"c:\Program Files\Alpine\alpine.exe" -p {server.example.com/ssl/novalidate-cert/user=arthur}remote_pinerc
Sendmail has a feature that puts in a delay after the initial client connect, before issuing the greeting. Some spammers don’t wait for the greeting, but just send their commands. Sendmail can then look for commands that come in before the greeting and know that these commands are bad. It works pretty well.
Edit /etc/mail/sendmail.mc
dnl # Pause to try to catch spammers. Drops mail from spammers who don't dnl # wait for the 5 second delay FEATURE(`greet_pause',5000)
Edit /etc/mail/access to not use the delay for mail from the localhost
GreetPause:localhost 0
Then, put the changes into effect.
make -C /etc/mail makemap hash /etc/mail/access.db < /etc/mail/access /etc/rc.d/init.d/sendmail restart
Check what's being dropped with:
grep pre-greeting /var/log/maillog
After around 40 minutes, I had already dropped over 50 connections.
Exmh was complaining about libpng not being the same version as what was used to compile the program. Since exmh is pretty old, this is not unusual. The package that we needed was libpng10, here is the description:
The libpng10 package contains an old version of libpng, a library of functions for creating and manipulating PNG (Portable Network Graphics) image format files. This package is needed if you want to run binaries that were linked dynamically with libpng 1.0.x.
Unfortunately, this package is not included with RHEL5. (It’s only in RHEL4 and RHEL3.) I did find a copy on the web and installed it so that exmh no longer complains about the images.
The rpm is saved in /system/kickstart/install/additions.
Had a problem where one user would have hundreds of procmail processes running. Would look something like this:
root 19395 1 0 Nov10 ? 00:00:00 sendmail: ./mAA8qmVx019388 from queue user1 19396 19395 0 Nov10 ? 00:00:00 procmail -f vcejixtxapby@borg.wyle.ingr.com -t -Y -a -d user1 root 19428 1 0 Nov08 ? 00:00:00 sendmail: ./mA91ThBb019426 from queue user1 19429 19428 0 Nov08 ? 00:00:00 procmail -f Kabj@lumenetwerk.nl -t -Y -a -d user1
In the users mail folder, there was a directory Junk which is where all this junk mail was supposed to go, but it wasn’t getting written there. However, there was a file called Junk.lock there. The problem was that procmail seemed to be creating the lock, which was then getting stuck. The solution was to edit the user’s .procmailrc file.
This is how it looked:
:0: * ^Subject:.*HEP_SPAM Junk
I changed it to:
:0 * ^Subject:.*HEP_SPAM Junk
Losing the : after the 0 tells it to not use locking. This solved the problem.
Open the virusscan console. Double-click on Access Protection. Highlight the rule “Prevent mass mailing worms from sending mail” and click “Edit”. Add alpine.exe to the “Processes to exclude:” box. Ok and Apply and alpine should be able to send mail on either 25 or 587.
Copy the following to get exmh to work:
/usr/bin:
exmh*
exmh-bg*
exmh-async*
inc*
viamail*
sortm*
show*
sendfiles*
send*
scan*
rmm*
rmf*
repl*
refile*
prompter*
prev*
pick*
packf*
next*
msh*
msgchk*
mimencode*
mhstore*
mhshow*
mhpath*
mhparam*
mhn*
mhlist*
mhbuild*
mark*
forw*
folders*
folder*
flists*
flist*
dist*
comp*
burst*
anno*
ali*
whom*
whatnow*
/usr/lib/nmh:
ap*
conflict*
dp*
fmtdump*
install-mh*
mhl*
mhtest*
post*
rcvdist*
rcvpack*
rcvstore*
rcvtty*
slocal*
spost*
Tkpostage needs the tkpostage file and /usr/local/lib/TkPostage.xbm
Also put /usr/local/lib/exmh-2.7.2 there.
Had a problem where a user who forwarded mail wasn’t receiving any. Turns out that port 25 on the machine the mail was going to was blocked.
Edited /etc/mail/sendmail.mc
Was: DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA’)dnl
Changed to: DAEMON_OPTIONS(`Port=smtp, Name=MTA’)dnl
Restart sendmail
If anyone tries to forward their mail to another machine in our cluster, need to make sure that this port is open.
Peter Behr pointed out that webmail wasn’t working. The problem was after logging in, (for me, in Safari) I’d get a can’t open page redirect.php error. (In Firefox, the page would just be blank.) I looked at some files on the shop computer, where webmail (squirrelmail) was still working ok and found some differences in the /etc/httpd/conf.d/php.conf file. The solution was to add the following to the php.conf on the hep computer.
AddType application/x-httpd-php .php
Restart the web browser and things started working.
I think this must be due to the different versions of php used by the different versions of redhat. The broken computer is running RHEL4 ES release 4 (server), while the working one is running RHEL4 WS release 4 (client).