(start-dccifd) su: no directory

> From: "Tom Bucacci" 

> I installed DCC on a FreeBSD 5.4 server from the ports collection.  

Unless the garbage added to the ports version of the DCC source has
been fixed, that may have been a mistake.  Besides, when I last I
heard, the FreeBSD ports package for 5.* was disabled because of some
nonsense about library linking problems.  My own machines run FreeBSD.

The person building the port or package, I'm not sure which, recently
contacted me.  I tried to convince him to use the DCC
./configure script instead of the crazy sed scripts to do whatever they
feel is needed.  Among other things, that would let people who us the
FreeBSD port use /usr/local/dcc/libexec/updatedcc to install new verisons.
 From what he said, it might be difficult to convince the "committers"
to do things the easy and better way.

> created a symbolic link called rcDCC.sh in /usr/local/etc/rc.d/ linked
> to /usr/local/dcc/libexec/rcDCC.  When DCC tries to start I get an error
> when starting dccifd.  The error is 'su: no directory'.  I'm not sure
> what this means or how to fix it.  Has anybody run into this problem?

You probably did not give the "dcc" user or whatever you chose a real
shell or home directory.  The user's home directory should be /var/dcc
or whatever you make the DCC home directory.  I find it convenient to
give the dcc user a real shell so that I can do things like

    su dcc
    ci -l ids map

I like to maintain RCS archives of configuration files.  Those particular
files must be private and owned by the dcc user.

However, to help such no-shell problems, the most recent version of
the DCC source falls back on executing the daemons with -Idcc su fails.
If you had installed from source, I would suggest that you run updatedcc
to get the most recent version.  Since you used the FreeBSD port, the
updatedcc script will not have been built with your ./configure choices,
or the choices of the FreeBSD port people.


By the way, what Microsoft mail system do you use that changes the
message body of a retransmission of a message after a 4yz temporary failure
and includes a copy of the real message body as some kind of proprietary
Microsoft document format?  Your subscription confirmation took a day
or two and would have failed except that I noticed it in my logs.  I'm
working on some stuff and have been watching logs more closely.  I use
the greylisting in dccm and dccifd.  See
http://www.dcc-servers.net/dcc/greylist.html
To foil obvious but so far unreported attacks on greylisting, by default
it requires that greylist retransmissions be identical.  The varying,
not-really-retransmissions of your subscription confirmation did not
get through until I restarted dccm with GREY_CLIENT_ARGS=weak-body in
/var/dcc/dcc_conf...or probably /usr/local/dcc/dcc_conf on your system.


Vernon Schryver    vjs@rhyolite.com