In the interest of exploring things of little consequence..
NetBSD has a weird leftover from the last century called msgs(1), a tool
for administrators to issue system-wide broadcasts to keep users informed
of issues that might affect them. The messages are numbered and persist
for a fixed period in /var/msgs/, 21 days by default. The messages have
minimal RFC-2822 compliance, just From, Subject: and the message body;
more on this below.
Unlike wall(1) and mail(1), msgs(1) is intended for system admin use only
and while it can be used directly it seems to be intended to function in conjunction with the local MTA to provide a virtual account that members
of the wheel group can send mail to for system-wide broadcasts.
Anyway, whenever I'm editing /etc/mail/aliases the following entry always
seems to catch my eye:
# uncomment this for msgs:
#msgs: "/usr/bin/msgs -s"
So, what happens if it's enabled? Sadly not much with current versions
of NetBSD. The stock msgs(1) configurations reflect an earlier time when sendmail(8) was the MTA and Mail(1) -- equivalent to mail(1)/mailx(1) --
was still present.
Fortunately it doesn't take much to get msgs(1) working on current
versions of NetBSD, though one does need to have superuser privileges.
Getting msgs(1) to work with the postfix(8) MTA:
Despite what the msgs(1) manpage says, it's *not* enough to uncomment
# msgs: "|/usr/bin/msgs -s"
in /mail/aliases and run 'newaliases'. While sending mail to commands
or files _is_ allowed with the default postfix(8) configuration, sending
mail to msgs(1) fails due to the write permissions of /var/msgs/* which
has the following defaults:
$ ls -ld /var/msgs
drwxr-xr-x 2 daemon wheel 512 Sep 16 2019 /var/msgs
$ ls -l /var/msgs/*
-rw-rw-r-- 1 daemon staff 0 May 31 2019 /var/msgs/bounds
The postfix(8) MTA defaults to 'nobody' for such writes, not 'daemon';
for reasons outlined in PR bin/46790 it is not advised to simply change
the ownership of /var/msgs to "nobody:wheel"; better instead to change
the following postfix main.cf parameter:
$ postconf default_privs
default_privs = nobody # default value
# postconf -e default_privs=daemon
default_privs = daemon # new value
Once postfix(8) configs are reloaded (run 'postfix reload' or reboot)
root or superuser should be able to mail messages to "msgs" as can any daily.conf(5) cronjobs if enabled.
Using msgs(1) directly:
Running 'msgs -s' as root or superuser will prompt for a Subject: line
then launch a minimal ed-style edit session for entering the message body, finalized by typing CTRL+D on a newline.
Reading msgs(1) messages:
If a system user has 'msgs -f' in their ~/.profile or a comparable setup
they will see a notification if there are new msgs(1) messages upon login.
To read messages they just enter 'msgs' and follow the prompts. Even
after all messages have been "seen" and are therefore no longer "new"
they can still be viewed by entering 'msgs 1' (starts are msg #1) or
'msgs -N' to start one message before the message number contained in
~/.msgsrc which is used to determine what is the next "new" message.
Messages can be saved using the 's' command (saved to ~/Messages by
default) or viewed and/or processed in mail/mailx using the 'm' command (requires more tweaks; see below).
Enabling msgs(1) mail/mailx features:
The msgs(1) manpage describes the ability to redirect messages to a
temporary mailbox for viewing/processing with mail(1). However msgs(1) actually tries to call Mail(1) which NetBSD no longer has. Mail, mail
and mailx where/are all the same program so the fix is to simply create
a symbolic link:
# ln -s /var/bin/mailx /var/bin/Mail
Once the link is created the 'm' command can be used in msgs(1) sessions, however mail(1) expects the 'From' field to be filled in with the sender
and date(1) string; if left blank -- which msgs(1) will do when run
directly -- mail(1) will report there are "0 messages" in the temporary mailbox. The work-around is to pipe a proper minimally formatted mail(1) message to msgs(1) like so:
# cat |msgs -s
From msgs Sat 13 Nov 2021 12:30:09 PM MST
Subject: msgs(1) test
This is a msgs(1) test. Note the following:
- From *not* From:
- From string is "msgs $(date)"
- blank line between header and body
CTRL+D
Now when system users run msgs(1) they can now use the 'm' command and view/process received messages using mail(1) in the usual way. A shell
script can facilitate the process if this would be a frequent usage.
Daily msgs(1) maintenance:
If the daily(5) system maintenance script is being run regularly,
usually via cron(8), then 'msgs -c' is run via the "run_msgs" option
in /etc/defaults/daily.conf, enabled by default. Running 'msgs -c' from
root's daily crontab is another option. This will remove old messages
from /var/msgs/ and update the /var/msgs/bounds file. If it seems not to
be functioning correctly just delete /var/msgs/bounds; the file will be recreated automatically when 'msgs -c' is run. The frequency of purges
can be adjusted, i.e. 'msgs -c -7' would cull messages older than 7 days.
Edit the /etc/daily script as needed.
Refs:
-
https://man.netbsd.org/msgs.1
-
https://man.netbsd.org/daily.5
-
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46790
-
https://man.netbsd.org/mail.1
-
https://www.ietf.org/rfc/rfc2822.txt
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)