qmail/relaylock doesn't work corectly when connected via localhost

[247trader]

No prob.





About your comments: Sure, spamdyke needs valid rDNS information to do its work, no doubt about that. But why does relaylock need an DNS server to set the variable TCPREMOTEIP? The remote IP is visible from the incoming IP session, right? No need for DNS.

.

Actually it has to do with tcp-env which as part of the libraies it calls looks to resolver for the lookup and then sets the parameters. So it is related in an indirect fashion.

 

[datenimperator]

There you go:

root@srv1:~# ps aex | grep qmail-smtpd
30314 pts/0    S+     0:00 grep qmail-smtpd TERM=xterm-color SHELL=/bin/bash SSH_CLIENT=80.187.100.81 39942 22 SSH_TTY=/dev/pts/0 USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35: MAIL=/var/mail/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games PWD=/root LANG=POSIX SHLVL=1 HOME=/root LOGNAME=root LC_CTYPE= SSH_CONNECTION=80.187.100.81 39942 92.51.129.12 22 LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/bin/grep

I can run /var/qmail/bin/tcp-env but it doesn't write anything. Should it?

 

[247trader]

There you go:

I can run /var/qmail/bin/tcp-env but it doesn't write anything. Should it?

No it should not give you anything if there is nothing wrong. Also run that command again with a dash in front of the aex ( ps -aex | grep qmail-smtpd )

 

[datenimperator]

No it should not give you anything if there is nothing wrong. Also run that command again with a dash in front of the aex ( ps -aex | grep qmail-smtpd )

Running the ps with a dash in front gives me a warning:

Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html

Besides from that, the output remains unchanged.

 

[datenimperator]

I compared the bind9 config files with those from another ubuntu installation. The chrooted installation that Plesk is using is missing the db.* files in /var/named/run-root/etc/bind. Copying over those files from /etc/bind and adding the configuration fixes the problem with localhost not being resolvable.

However, the original issue remains, even after restarting the server once more. :-(

 

[Peter2]

Hey.
The software is from parallels!!!
I would NEVER install any software from parallels, when I have not
minimum the 3rd hotfix.

Maybe a dirty and fix hack is to copy old /var/qmail/bin/tcp-env to new
system.
))

- Peter

 

[247trader]

I compared the bind9 config files with those from another ubuntu installation. The chrooted installation that Plesk is using is missing the db.* files in /var/named/run-root/etc/bind. Copying over those files from /etc/bind and adding the configuration fixes the problem with localhost not being resolvable.

However, the original issue remains, even after restarting the server once more. :-(

At this point I know where the problem lies (tcp-env) I just don't know enough about the components to tell you how to fix it without looking at the server.

 

[247trader]

At this point I know where the problem lies (tcp-env) I just don't know enough about the components to tell you how to fix it without looking at the server.

I wanted to update this ticket for you in case you were still having problems. SPamdyke has a problem in plesk 9.0.0 which does not set the variables correctly. Sam has fixed the problem in the new version. Try that and see if it fixes your problem.

 

[Peter2]

I would prefer to fix the main problem and not programm workarounds cause parallels is unable to fix their own software.
That is parallels tactic.

TCPREMOTEIP should have the IP.
Not more not less.
How tcp-env had it the last 5 years.

 

[eMediaSales]

Here is the fix

Thanks to folks in this thread for pointing me in the right direction for a similar issue. Essentially tcp-env is broken in Plesk9, replace it from one of your Plesk 8.6 servers (FYI, this is on CentOS5.2).

See this thread for details: http://forum.swsoft.com/showthread.php?t=57067