A problem I see: It's often hard to submit a dmesg.
These days, sending e-mail from an arbitrary machine is "difficult",
as it usually requires use of an e-mail relay. Gathering and sending
a dmesg via many common e-mail clients often ends up mangling the
dmesg in various ways.
Goals for a solution:
* Should not create any additional work for developers.
* Should not require any significant additions to the most basic
OpenBSD install.
* Should be able to hunt for a port with clear, outbound access.
* Should use a sane protocol (not FTP).
* Should ultimately deliver a familiar, useful, plain text e-mail to
OpenBSD developers.
* Should do some basic checking to minimize spam and mangled dmesgs
from ever hitting the OpenBSD Developers.
* Should allow users to review what is about to be sent to OpenBSD.
* Should be stupidly fast and simple for users to use.
* Should be possible to become part of the base OpenBSD install if
decided useful and desirable.
What I came up with:
The script, "senddmesg" and a system to process the submissions,
forwarding on via e-mail to dm...@openbsd.org
Protocol: The best option would probably be an HTTP(s) PUT, but the
tools to do that are not part of OpenBSD's base install (well...probably
could be done by perl, but that's above my skill set). So...looks to me
like sftp is the answer. Of course, many networks block port 22, so I
set up a redirect on the receiver to allow SFTP over ports 443, 80, and
53 in addition to port 22.
The sending script starts by checking if it is running as root. If not,
it advises the user that's ok, but less data can be sent, and gives the
user an opportunity to cancel and re-run as root. It then tries to to do
an SFTP connection to the target system over each of the ports in order
of likelihood for success. A very short timeout is used (currently one
second) so that if the SFTP client can't get through, it fails and moves
on quickly.
Once a viable port is found, dmesg, usbdevs, pcidump and sysctl hw is
run, collected into a mktemp(1) file, and the user is put into $EDITOR
or vi to look at what is being sent. When they exit vi, they are
prompted if they wish to send the file or not.
If they wish to proceed, the file is gzip'd, and sftp'd to the dmesg
collection system. A two second delay takes place, and a another SFTP
connection is made to try to retrieve a status file, which will report
if the file was accepted and forwarded on to dm...@openbsd.org or
rejected
On the receiving end, a script looks for new, uploaded files. If the
file has been received matches the filename format of a likely dmesg
upload, it's unpacked, checked for a few basic things, and if it checks
out, the dmesg file is forwarded to the OpenBSD developers. Files are
left where they could be accessed by another user less than one second,
files are uploaded with randomized names (from mktemp(1)), and the
directory the chroot user can write to is mode 370, so the uploading
user can't see other uploads that haven't been processed yet.
A Demo system is set up at dmesg.egoslike.us
You can download the senddmesg script:
$ sftp dm...@dmesg.egoslike.us:/outgoing/senddmesg
It's a fairly simple ksh script, look it over to make sure I'm not
doing something malicious or stupid, then run it to send a dmesg to *me*.
If you use it to send a dmesg, IT IS NOT GOING TO THE OPENBSD DEVELOPERS
AT THIS TIME. I'm not auto-forwarding e-mail until a developer says
"do it".
The dmesg user has a 30kB filesize ulimit and no password, and a few
tricks to make it difficult to use it to pass messages from user to
user via this system.
This is a proof of concept only. I really don't like the current
senddmesg script, there are quite a few things I want it to do better,
including having options for non-interactive ("just send the dang
thing!") and command line driven. However, before I spend a lot
of time making it suck less, I would like some indication that
developers think this is worth going further with.
IF developers wish me to go forward with this, we can talk about
hosting options (or keep using this system, a VPS hosted by Vultr).
I am willing to keep running it for the project.
Nick.
