Arch Linux

i just found a workaround:
1. pacman -Syu
2. ln -s smtpctl /usr/bin/sendmail

:)

-arne

Thanks for the workaround. I found the hard way only now that the email has not worked since the package update (29.5.). Will the workaround become a permanent fix?

There must have been some other changes in the package as after update the opensmtpd required to change ownership and permissions of some directories to start successfully:
chown root:smtpq /var/spool/smtpd/offline/
chmod 770 /var/spool/smtpd/offline/
chmod 700 /var/spool/smtpd/purge/

Next time after updating smtpd I will remember to send test email.

This workaround is how Debian packages opensmtpd (source https://anonscm.debian.org/cgit/collab-maint/opensmtpd.git/tree/debian/links), I assume this is meant to be the correct way.
You should also provide symlinks for /usr/bin/newaliases and /usr/bin/makemap on the same schema, for scripts and users used to these standard sendmail utils.

@Link:
> [...] I assume this is meant to be the correct way. [...]
>
i c.
but why the man page if there shall be no such command?
You might say that they're the next endangered files - man pages. :)

-arne (who likes Twelve Monkeys)

The command does exist, it is just provided by smtpctl, on the same model than e.g. busybox.

@Link:
But the man page says:
> SYNOPSIS
> sendmail [-tv] [-F name] [-f from] to ...
while sendmail doesn't exist by default...

so it is just a workaround...
The bug is still in opensmtpd, because it advertises non-existent commands...

maybe s/o should report it upstream?

-arne

Fix

@Danijel:
why not
ln smtpctl "$pkgdir/usr/bin/sendmail"
?

-arne

because of:

ln: failed to access 'smtpctl': No such file or directory

eeks - i meant:
ln -s smtpctl "$pkgdir/usr/bin/sendmail"

a symlink... :)

-arne

So, what's the benefit of a symlink in this case?

* I cannot see a need to expose the fact that smtpctl and sendmail are the same file
* It is possible to get rid of the sendmail functionality by deleting sendmail and vice versa,
A symlink requires more care to do that.
* And last but not least, a symlink wastes an inode.

i dont know, but b4 it used symlinks 2...
furthermore symlinks feel better than hardlinks IMO... :)

btw: mailq needs 2 b linked 2 smtpctl 2

-arne

also link mailq

@Danijel:
do u want to use "ln -s" in ur patch now?
I mean: now u use my bad command from T09:59...

makemap and newaliases need a link to smtpctl, 2...

-arne

Oh dear, I should not work on a touch screen...

Linked all __prognames except "send-mail" since no other mta installs send-mail according to "pkgfile send-mail"

I made myself clear what I think about hardlink vs. symlink. If you want a symlink you have to change the patch yourself.

/usr/bin/sendmail is meant to be symlinked to smtpctl.
Take a look at sendmail_compat() at line 1994: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/smtpd/smtpctl.c?rev=1.149&content-type=text/plain

Fedora does it: http://pkgs.fedoraproject.org/cgit/rpms/opensmtpd.git/tree/opensmtpd.spec#n132
Gentoo does it: https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-mta/opensmtpd/opensmtpd-5.9.2_p1.ebuild#n73

The code does not require symlinks. Use symlinks if you want to, it doesn't change the functionality, it just wastes inodes.

Ah, that's true. The code does not require symlinks. And it does indeed waste one inode.

I suggest taking a look at other packages and seeing how it's done there, and then try and follow what's customary in Arch. I trust Lukas Fleicher to have control of these matters.

The important part is that certain functionality is missing from opensmtpd now because of a lack of links; at least "sendmail", "makemap" and "newaliases".

So could we get this assigned to someone who could do this quick update? The issue mentioned by Pavel about the permissions was also irritating, the packaging should have taken care of that. I don't think it makes sense to argue a lot about wasting a single inode and hardlinks vs. symlinks, the result would matter of someone with commit privileges fixing this issue. Thanks!

The package indeed comes with a sendmail symlink, but one pointing to the build directory, not the actual smtpctl binary:

sendmail -> /build/opensmtpd/pkg/opensmtpd/usr/bin/smtpctl

Seconded!

Just use the binary name as the source of the symlink, you don’t need to provide the entire path since both the source and the destination are in the same directory.

Just as a note, on OpenBSD, they use the mailwrapper to deal with this: http://man.openbsd.org/OpenBSD-current/man8/mailwrapper.8

In the end, sendmail, makemap and newaliases are links to this mailwrapper, which, in turn, looks at a configuration file (/etc/mailer.conf) that deals with the actual redirection:

sendmail /usr/sbin/smtpctl
send-mail /usr/sbin/smtpctl
mailq /usr/sbin/smtpctl
makemap /usr/libexec/smtpd/makemap
newaliases /usr/libexec/smtpd/makemap

I agree the packaging of opensmtpd is lacking. I don't think arch need to implement a mailwrapper a la OpenBSD. Simple symlinks are more than enough. And really, modern filesystems shouldn't run out of inodes, unless you are creating huge amount of files, and even then, it would be hard to hit the limit. This whole discussion of symlink vs. hardlink or should we do it or not is moot. The fact is, we need a mailer on arch when we install opensmtpd. If it will be smtpctl itself (it should) or if it will be pulled in as a dependency doesn't matter.

sendmail, mailq, newaliases and makemap is not working because these are all most be linked to /usr/bin/smtpctl but they are linked to /build/opensmtpd/pkg/opensmtpd/usr/bin/smtpctl.
in PKGBUILD lines 52-55, the links most be corrected and remove $pkgdir from target address ($pkgdir/usr/bin/smtpctl).