Also, it seems that clientmqueue is skipped on mail queue runs (in
other words, if mail spooled in clientmqueue is not sent immediately,
it is not sent ever). Seems that I'm missing something obvious here.
Any hints or help?
--
Aleksandar Milivojević <al...@fly.srk.fer.hr>
Opinions expressed herein are my own.
Statements included here may be fiction rather than truth.
8.11 doesn't use clientmqueue.
> rwxrwx---) programs like mailx doesn't work anymore (for obvious
> reasons, mailx is set-grup-id mail, not smmsp, and I don't know how
> safe it is to change it to smmsp (and it will be revert back to mail
> anyway if I install any patch that contains mailx)).
Do you use 8.12? If so, what's the error message?
Please check the permissions as stated in sendmail/SECURITY:
-r-xr-sr-x root smmsp ... /PATH/TO/sendmail
drwxrwx--- smmsp smmsp ... /var/spool/clientmqueue
drwx------ root wheel ... /var/spool/mqueue
-r--r--r-- root wheel ... /etc/mail/sendmail.cf
-r--r--r-- root wheel ... /etc/mail/submit.cf
If that doesn't help, post the permissions for those
files/directories, and the output of
grep smmsp /etc/passwd /etc/group
> Also, it seems that clientmqueue is skipped on mail queue runs (in
> other words, if mail spooled in clientmqueue is not sent immediately,
> it is not sent ever). Seems that I'm missing something obvious here.
See sendmail/SECURITY:
... In general it is necessary to clean the queue either
via a cronjob or by running a daemon, e.g.,
/PATH/TO/sendmail -L sm-msp-queue -Ac -q30m
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
Ups, yes, it is 8.12.1 :-)
Anyhow, is there a way to disable that clientmqueue thing and to have
things working as they were in 8.11 and older? This clientmqueue
thing is totaly meaningless in my environment (I don't gain nothing
from it) and it seems to much trouble to configure and integrate with
my existing software...
> Anyhow, is there a way to disable that clientmqueue thing and to have
Well, didn't tried but if you set binary to suid root, you can
probably have old behaviour.
sendmail/SECURITY says:
[...]
The .cf file is chosen based on the operation mode. For -bm (default),
-bs, and -t it is submit.cf (if it exists) for all others it is
^^^^^^^^^^^^^^
[...]
Set-User-Id
-----------
If you really have to install sendmail set-user-ID root, you can use
sh ./Build install-set-user-id
But why!?
> things working as they were in 8.11 and older? This clientmqueue
> thing is totaly meaningless in my environment (I don't gain nothing
> from it) and it seems to much trouble to configure and integrate with
> my existing software...
What is exact problem? I have various tasks and machines with very
different configurations (cyrus-lmtpd, majordomo, ldap ..., tried
nearly all) and I don't have any configuration problem with 8.12.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
The peace of software is very simple: Solaris mailx program.
Complains it cannot write to clientmqueue (of course it can't when it
is suposed to be writtable only by smmsp group and user).
> Miroslav Zubcic (mvz+...@crol.net) wrote:
> > What is exact problem? I have various tasks and machines with very
> The peace of software is very simple: Solaris mailx program.
What Solaris mailx is doing? Is it writing something directly in
sendmail's queue? On Linux mail(1) is doing his job OK:
mail -v -s "blah" te...@crol.net < test/a.txt
Is OK,
strace -o foooo mail -v -s "blah" te...@crol.net < test/a.txt
as I see this is OK, but
strace -f -o foooo mail -v -s "blah" te...@crol.net < test/blah/a
Process 18017 attached
WARNING: RunAsGid for MSP ignored, check group ids (egid=10, want=78)
can not chdir(/var/spool/clientmqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.
Process 18017 detached
From man page for strace(1):
-f Trace child processes as they are created by currently traced
processes as a result of the fork(2) system call.
So everything seems to be OK, from test/Results it seems that
SunOS/Solaris has HASSETREGID, check your binary. (sendmail -bt -d0.14)
... or take source for Linux mailx and replace it if mailx is problem.
> Complains it cannot write to clientmqueue (of course it can't when it
> is suposed to be writtable only by smmsp group and user).
I suposse that your sendmail binary is in root:smmsp ownership and
setGID to smmsp, and clientmqueue in smmsp:smmsp ownership and mode
770.
> The peace of software is very simple: Solaris mailx program.
> Complains it cannot write to clientmqueue (of course it can't when it
> is suposed to be writtable only by smmsp group and user).
mailx does NOT write to the queue. Only the MSP writes to
clientmqueue.
If you post the full error message, we might be even able
to fix it...
Please check the permissions as stated in sendmail/SECURITY:
-r-xr-sr-x root smmsp ... /PATH/TO/sendmail
drwxrwx--- smmsp smmsp ... /var/spool/clientmqueue
drwx------ root wheel ... /var/spool/mqueue
-r--r--r-- root wheel ... /etc/mail/sendmail.cf
-r--r--r-- root wheel ... /etc/mail/submit.cf
If that doesn't help, post the permissions for those
files/directories, and the output of
grep smmsp /etc/passwd /etc/group
--
Eh, found where the problem was... Hint was in line above, I made a
mistake when creating smmsp user (it was not member of smmsp group).
I changed /etc/passwd so that smmsp belongs to smmsp group, and now
everything is working fine :-)))
Thanks for the help :-)
Nope! It is Sendmail who's complaining, because in submit mode it is run as
user:smmsp and if the permissions on the /var/spool/clientmqueue are
incorect or it cannot read /etc/mail/submit.cf, it cannot submit the
message.
Nix.