Hey.
On 14/09/2011, samt <[email protected]> wrote:
> Not all binaries that can be run as services have rc.d(8) control
> scripts.
I moved past that quickly.
>From the 4.9 release announcement:
- New rc.d(8) for starting, stopping and reconfiguring package daemons:
o Only a handful of packages have migrated for now.
http://marc.info/?l=openbsd-misc&m=130425995218202&w=2
It's to be expected migrating packages takes time and migrating base takes time.
Considering that rc and company have been in release for some time ...
... and it is documented (for the most part) that base services are
controlled by rc ...
... and they have concomitant flags in rc.conf ...
... and in my experience every base service behaves this way ...
... perhaps the absence of popa3d is an oversight and worth reporting.
That may be known and there is nothing to see here.
I fully expect it may be a case of only the usual suspects are in rc
and rc.conf but I don't know.
> I'm not sure what the process is, but if you post an rc.d(8) popa3d
> control script suggestion
> then at least it will be in the mail archives and if found 'acceptable'
> might be included in future
> releases.
I read rc.d and rc.subr and then I copied smtpd and changed the names. :]
Nevertheless, there you have it, that's what I did.
> As the popa3d(8) manpage suggests, you have two options for running popa3d:
>
> * directly, benefit of lower overhead (useful for busy servers) or
> * through inetd(8)
>
> Many people use popa3d (which I guess means that many of us do not have
> a resource issue)
> running it that way. If your use case requires running it directly then
> you now need
> to launch it at host startup (as you've documented in your OP)
I don't have a requirement either way.
The OpenBSD www site is offline at the moment but the man pages
essentially say ...
Essentially, inetd allows running one daemon to invoke several
others, reducing load on the system.
http://www.freebsd.org/cgi/man.cgi?query=inetd
Standalone server mode.
This has lower overhead than starting popa3d
from an inetd equivalent ... and is thus useful on busy servers to reduce load.
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/popa3d.8?rev=1.5;content-type=text%2Fplain
My understanding is that inetd mode reduces load in the sense of less
memory footprint (not all services run all the time but as needed) and
standalone mode reduces load in the sense of less work done by disk
and probably a few other items.
I have plenty of room to manoeuvre here. Rooms full of hardware and
very few network services.
When I have the choice of not running inetd and simplifying things
(albeit perhaps trivially) I'm happier to avoid it.
Standalone server mode.
In this mode popa3d
also does quite a few checks to significantly reduce the impact of
connection flood attacks.
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/popa3d.8?rev=1.5;content-type=text%2Fplain
As I understand the only other pertinent issue is using tcpd but I
haven't gone to the bottom of that. However if that is relevant and
indeed anything less than heartache (how do I implement hostname
control when my clients might be using connections that don't care for
reverse lookups) I'm all ears but at some point is that any more
pertinent than any other concerns (weakness in inetd, weakness in
tcpd, strength in less running services, strength in less
administration, etcetera).
As I said I've skipped over that, so ...
Do wrappers (maybe that's not the correct term) apply here?
Is that tcpd?
If so how much of the feature set in the tcpd man page do you take advantage of?
How useful are they?
Are there any gotchas?
What's the performance trade off for client access time?
Etcetera.
> As rc.d(8) evolves we'll hopefully find more (?) control scripts placed
> into /etc/rc.d,
> likewise hopefully more ports evolve to using said scripts.
>
>
> Good luck,
>
Thankyou.
>
> Sam T.
>
Best wishes.
