Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: judgej on June 26, 2006, 12:26:16 AM
-
I've upgraded from 6.0.1 to 7.0 RC3 (using the USB-attached disk method), and am unable to send e-mail.
IMP gives this error:
>> There was an error sending your message: unable to connect to smtp server localhost:25
In the log file this generates:
>> Jun 25 23:11:00 sme2 httpd: PHP Warning: fsockopen(): unable to connect to 127.0.0.1:25 in /usr/share/pear/Net/Socket.php on line 108
>> Jun 25 23:11:00 sme2 HORDE[3672]: [imp] unable to connect to smtp server localhost:25 [on line 939 of "/home/httpd/html/horde/imp/compose.php"]
In Outlook I get this error:
>> Task 'sme2 - Sending' reported error (0x800CCC0F) : 'The connection to the server was interrupted. If this problem continues, contact your server administrator or Internet service provider (ISP).'
Any ideas where I should look? I have disabled all the custom templates, but that is not to say there is not some other leftover from a past contribution.
The wierd thing is, it did work for a while, and I'm not sure what I did for it to stop working. I have renamed the IMAP folders to use '.' separators rather than ';' separators - not sure if that affected SMTP (I would hope not).
-- JJ
-
One other thing I did was to change some of the SMTP settings. This resulted in the SMTP templates being rebuilt. I just noticed this in the message log. Not sure if it is related to the SMTP no longer working?
Jun 25 22:05:50 sme2 esmith::event[2185]: expanding /var/service/qpsmtpd/ssl/cert.pem
Jun 25 22:05:50 sme2 esmith::event[2185]: WARNING: Invalid group: qpsmtpd, defaulting to 'root' group (0).
Jun 25 22:05:50 sme2 esmith::event[2185]: at /etc/e-smith/events/actions/generic_template_expand line 118
Could it be the upgrade did not create the group 'qpsmtpd'? Can I create it manually?
-- JJ
-
Now incoming mail is no longer coming through (possibily external servers are also no longer able to connect to the SMTP server). Again, it *was* working until I fiddled with a few of the mail settings in the admin screens. Changing them back has not fixed the problem.
-- JJ
-
The smtp services just seems to disconnect as soon as I have connected to it:
[root@sme usr]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[root@sme usr]#
-
Slowly getting closer...
There is a file /var/service/qpsmtpd/run, which (if I read it correctly) forks an smtp process for each incoming connection. It contains this:
exec /usr/local/bin/softlimit -d 25000000 -s 25000000 -l 25000000 \
/usr/bin/qpsmtpd-forkserver \
-u qpsmtpd \
-l 0.0.0.0 \
-p ${PORT:-25} \
-c ${INSTANCES:-40} \
-m ${INSTANCES_PER_IP:-5} \
2>&1
However - there is no 'qpsmtpd' user on the system. If I change that entry in the script to 'root' and restart the smtpd, then the floodgates open and e-mail comes in and goes out. Also I can confirm it is working by telnetting into port 25.
So - the question is - why is this user missing? Does a restore-from-disk completely overwrite /etc/passwd? Did that user never happen to be created in the first place? Has something I changed updated the 'run' script and changed the user (since it did work earlier, but I've certainly not changed anything that would make a user disappear).
-- JJ
-
Fixed. It only took five and a half hours to work out, but here is the solution:
# adduser qpsmtpd
-- JJ
PS If anyone knows what bug I should raise, that would be most appreciated. I suspect the bug would be on the upgrade process, but I'm not really sure.
-
Looking at this further, I think the restore-from-disk has removed a number of SME7-only users.
The message spooling area is set up owned by some user '453' in group '402' - no idea what they were before the restore.
Also noticed the spamd spool is owned by 1005/1005. Again no idea what users they were.
So to help me, can anyone take a look at their SME7 setup and tell me the user and group names for:
/var/spool/qpsmtpd
/var/spool/spamd
It would also be useful to see the /etc/passwd and /etc/group enties for these, so I can set them up manually.
Thanks!
-- JJ
-
Fixed. It only took five and a half hours to work out...
Would have been quicker if you'd just reported via the Bug Tracker, wouldn't it?
Quoting:
PLEASE READ THIS BEFORE POSTING
Please post bugs and potential bugs in the bug tracker - Thank You.
-
Fixed. It only took five and a half hours to work out...
Would have been quicker if you'd just reported via the Bug Tracker, wouldn't it?
Would it? I did not know it was a bug until I found out what the problem was. Since I could not find (and still can't find) any similar bugs, then I would fully expect a "works for everyone else - WONTFIX" to be the result. There are just too many variables involved in upgrading to be sure about what to report as a bug (or a potential bug), and what is simply self-made problem.
I personally find the questions and solutions in these forums extremely useful. They are useful because they are about everyday users talking to everyday users about the issues they are having, whether it involves 'supported' contributions, or official modules or not.
-- JJ
-
Bug raised: http://bugs.contribs.org/show_bug.cgi?id=1647