RE: Running appbat pkgs in LSB-si
> > lsb-apache:
> > (1) No user 'nobody' in the LSB-si. The
> > package ought not to assume a particular user,
> > it ought to use a likely-unique username and create
> > that user on pkg install (and remove it on
> > pkg removal). That was on my TODO list once,
> > before we switched to the new nALFS-based build
> > and I dropped it. Created manually.
> >
> > (2) Warning message, "Could not determine the
> > server's fully qualified domain name, using
> > 127.0.0.1 for ServerName".
> >
> > Summary: appbat package is okay, but probably
> > ought to create the user that apache runs under.
>
> hmm, perhaps we should have 'nobody'.
Since it's not in the spec, and since we were subjected
to incredible flamage for the few users that were in
the spec until we were forced to take them out, it's
best for the appbat package not to assume ANYTHING about
existing accounts. Anyway, useradd is part of the spec...
> > lsb-rsync:
> > (1) Able to contact a remote rsync server, once I
> > set one up. We should probably add instructions
> > for doing so; or alternatively, have the pkg set
> > up a way for the system under test to act as the
> > server. Remember rsync's default transport is
> > to use rsh, which is not supported by the LSB,
> > and thus not available in the LSB-si.
> >
> > Summary: rsync package is okay, but probably
> > ought to set up to run a local rsync server
> > (needs to create an rsyncd.conf for this) and
> > have the FVT include a step for starting the
> > server, since it won't be started on demand
> > from xinted/inetd like on a "normal system".
>
> rsync is required by the standard so it is already installed,
> no need to install it again (-:
Well, ignoring the fact that we're deprecating rsync,
since that's irrelevant for another 12 months, probably
(1.3 will mark it deprecated and the next release can
then drop it)...
The problem isn't whether or not an rsync is present
somewhere or not, but whether it's set up to serve
incoming requests. It's not a separate server, it's
just "rsync --daemon".
The rsync in the LSB-si isn't any better to use than
the rsync installed by the app battery, as there's no
xinetd to sit and listen for an incoming rsync request.
Thus, the instructions could describe how to set up
the appbat one to listen.
What I hadn't thought of, and just tested that it works,
is that the appbat rsync can contact the (required)
rsync in the underlying host, on the assumption that
most systems that install rsync also set it up to
listen for requests. Thanks for helping me think of that.
The catch in all of these cases is that if rsync is
asked to act as a server with --daemon, it does nothing
if it doesn't find a config file in the compiled-in path
(the client will think it failed to contact the server
at all, and thus it will look like a failure).
By default this is /etc/rsync.conf (I'll have to check
that for the appbat, since our LFS-ness requires that
to be /etc/opt/lsb-rsync/rsync.conf ... don't know if
we thought of setting that up). No system I know of
supplies an rsync.conf by default, so the setup
instructions basically involve creating an rsync.conf.
Or possibly, for the appbat, including and installing
a minimalist rsync.conf, perhaps describing some LSB
required location so that there's something to check
against that's sure to be there.
Mats
Reply to: