Nick Holland wrote:
I've got a little project I'm working on here.
It involves stuffing a computer in a donation box with a
money detector, so every time someone tosses money in the box,
it plays an MP3 file.
(no, you can't make a living at this. At least, *I* can't)
The first two of these I did were many years ago, and we used a
486 running a simple DOS app. Well, computers that run DOS well
are gone, and trying to bring up a new program to play sound
files on any of the modern sound chips would be (not) fun...and
annoying the next time the hardware all changes again.
So, for this generation, I'm using OpenBSD, mpg321, and a 1G
CF flash device attached to an CF-> IDE interface.
However, this is the first time I've ever done an OpenBSD system
that wasn't going to be attached to some kind of network for
(hopefully) years at a time. In fact, hopefully, it will NEVER
be attached to a network. And, while I got a 1G CF device, I
could imagine doing something stupid and having it slowly fill
the CF media and six months from now getting a call saying, "It
died. Come fix it", and since it will be in another country and
probably a ten hour drive away, I'd like to avoid that. :)
Once this thing is deployed, I won't have access to it at all,
so I'll have no ability to spot a potential problem or fix it.
SO, to try to keep things quiet, I've disabled the daily, weekly,
and monthly scripts, I've disabled sendmail in /etc/rc.conf.local.
Before I ship it out, I'll move /var/log and /var/tmp to point to
a mfs system, so hopefully, if something starts logging, a power
cycle will dump everything. Only 60M is mounted RW, so it fsck's
very quickly, and my app writes only to the MFS.
What have I forgotten? Is there anything else I can do to avoid
slapping my forehead and saying, "D'oh! Forgot to ..." before I
ship it out fully detached? The good news is I'm pretty sure
there is at least one OpenBSD developer near-by, but that's just
all the more reason to make sure I don't screw it up, I'll never
live it down. :)
Nick.
A noob-ish question/observation... since the mfs could eventually fill,
why not point potential logs at /dev/null instead?
