Message ID | 20221129215541.26224-1-eu@euandre.org |
---|---|
State | New |
Headers | show |
Series | [bug#59701] gnu: mailutils: Inform correct path of sendmail. | expand |
EuAndreh via Guix-patches via 写道: > * gnu/packages/mail.scm (mailutils)[arguments]: Add > -DPATH_SENDMAIL > to CFLAGS pointing to /run/setuid-programs. Thanks! Did you try making mailutils simply respect $PATH instead? Do you know why it doesn't? Can't? Hard-coding a distribution-specific location is something we often bemoan other packages doing… Kind regards, T G-R
I did try it, but it was mailutils that I feel forced my hand. It uses a pre-defined list of paths to search, instead of $PATH, namely: /usr/sbin:/usr/lib:/etc So I feel the opposite ocurred: I wanted it to just rely on $PATH, but mailutils used a specific search path, but it at least gives us a way in to put a custom value.
This is the *compile-time* search path used by the build system, no the runtime one.
On Tue, Nov 29, 2022 at 10:31:33PM +0000, EuAndreh via Guix-patches via wrote: > I did try it, but it was mailutils that I feel forced my hand. It uses a > pre-defined list of paths to search, instead of $PATH, namely: > > /usr/sbin:/usr/lib:/etc > > So I feel the opposite ocurred: I wanted it to just rely on $PATH, but > mailutils used a specific search path, but it at least gives us a way in to > put a custom value. Can we change that value to $PATH? I checked and I don't have sendmail in /run/setuid-programs, and I know I'd use my msmtp setup for sendmail *for myself* but not for the system if it were available.
That's a good idea. Let me try it.
Come to think of it, I did try it. It required a significant amount of patches to the source code itself, to the point where one should prepare a patchset and send upstream, after refactoring some of the code. The problem is that the aforementioned search path used is searched at compile-time, and if no sendmail binary is found, the absolute fallback path is used instead. So instead of a run-time $PATH lookup, it has a compile-time /usr/sbin:/usr/lib:/etc lookup, with a /usr/sbin/sendmail fallback. Ideally we would like to have: 1. not looking for sendmail binaries at compile-time, and relying on $PATH instead; 2. not having a fallback absolute path to a fallback binary, and just get a ENOENT at runtime instead, plus a few more diagnostic messages to STDERR. As I progressed in achieving that, I had modification on top of modification to the build system and the source code, and at some point I found myself questioning the approach, as it was becoming too fragile and too custom. There is no bug registered in GNU Mailutils' bug database, but there is a thread [0] in its list with people talking about when the exact same problem was encountered when our friends at Nix packaged mailutils [1]. The suggestion [2] from the maintainer is actually to put a symlink to the setuid sendmail binary where mailutils expects to find it: > There's no way to do this currently, except for symlinking the actual > sendmail-compatible binary (whatever it is in your distro) to the > predefined path (preferably, to the place defined by _PATH_SENDMAIL > in your /usr/include/paths.h). In fact, that's what all distros that > I've ever seen do. The difference for Guix (and Nix) is that /usr/sbin/ doesn't even exist, so we use the PATH_SENDMAIL macro to tell mailutils where to find sendmail, as upstream seems happy with the state of affairs. [0]: https://lists.gnu.org/archive/html/bug-mailutils/2017-10/msg00004.html [1]: https://github.com/NixOS/nixpkgs/issues/21008 [2]: https://lists.gnu.org/archive/html/bug-mailutils/2017-10/msg00001.html
> Can we change that value to $PATH? I checked and I don't have sendmail > in /run/setuid-programs, and I know I'd use my msmtp setup for sendmail > *for myself* but not for the system if it were available. With mailutils, I'm afraid this can't be done. What our Nix friends do is have a module (which is equivalent to a Guix service) that accepts a "setSendmail" option [0] which, when true, adds the a setuid msmtp binary wrapper [1]. That mixes up user-level and system-level configuration, and the only way around is add a user-level alias wrapper for mailutils wrapper that specifies where to find sendmail at runtime: alias mail="mail -E'set sendmail=\"$HOME/.guix-home/profile/bin/msmtp\"'" Doing this to the mailutils package definition would require juggling some options around and knowing very well how mailutils handles options, so that the dynamic lookup of the sendmail binary doesn't break anything else. [0]: https://github.com/NixOS/nixpkgs/blob/353a64f7bac4230a46dfa47a6212902c622b98a2/nixos/modules/programs/msmtp.nix#L15 [1]: https://github.com/NixOS/nixpkgs/blob/353a64f7bac4230a46dfa47a6212902c622b98a2/nixos/modules/programs/msmtp.nix#L76
EuAndreh 写道: > I did try it, but it was mailutils that I feel forced my hand. > It > uses a pre-defined list of paths to search, instead of $PATH, > namely: Thanks, but I think you missed my point. I suggested *making* it respect $PATH. Kind regards, T G-R
From what I could read and debug from the mailutils source code, this would require a non-trivial amount of refactoring, not a couple of (substitute* ...) calls some a few files. This should be done by submitting changes upstream, so that the maintainer can properly review and apply them. I'd say this is how this software is written to work right now, and tweaking it would be thwarting its core purpose.
EuAndreh <eu@euandre.org> writes: >> Can we change that value to $PATH? I checked and I don't have sendmail >> in /run/setuid-programs, and I know I'd use my msmtp setup for sendmail >> *for myself* but not for the system if it were available. > > With mailutils, I'm afraid this can't be done. For the `mail` command, it can be customized in a `~/.mailrc` file, maybe: ``` set sendmail=sendmail:/run/setuid-programs/sendmail # or set sendmail=smtp://127.0.0.1 ```
diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm index cef5fe2916..2c42cdfaca 100644 --- a/gnu/packages/mail.scm +++ b/gnu/packages/mail.scm @@ -347,6 +347,9 @@ (define-public mailutils #~(list "--sysconfdir=/etc" "--disable-static" + ;; Specify path to sendmail setuid binary, which otherwise + ;; defaults to /usr/sbin/sendmail + "CFLAGS=-DPATH_SENDMAIL=\\\"/run/setuid-programs\\\"" ;; Add "/X.Y" to the installation directory. (string-append "--with-guile-site-dir=" (assoc-ref %outputs "out")
* gnu/packages/mail.scm (mailutils)[arguments]: Add -DPATH_SENDMAIL to CFLAGS pointing to /run/setuid-programs. --- Notes: The current compilation options of GNU Mailutils don't specify a value for the "PATH_SENDMAIL" C macro. The build system of the package looks for a definition of this variable in the "paths.h" header file from the glibc package, and falls back to what is defined as the default in its "paths" file, /usr/sbin/sendmail. As this binary doesn't exist, "mail" fails to execute: $ cat mail.txt From: root To: root Subject: This fails The body $ mail -t < mail.txt mail: Cannot open mailer: No such file or directory mail: cannot send message: No such file or directory $ echo $? 1 I've confirmed this by looking at the file called "paths" in the source code of mailutils, and at the strace output of calling mailutils. I do have a working sendmail binary under /run/setuid-programs, and it now it is correctly called by the "mail" command, from mailutils. Given that this was the default, probably most Guix users do have a /root/dead.letter, with emails from the system, mainly rottlog notifications of log rotations, as it does use GNU Mailutils directly in its /etc/rottlog/rc configuration. gnu/packages/mail.scm | 3 +++ 1 file changed, 3 insertions(+)