RE: Running appbat pkgs in LSB-si
Matts,
You may want to take a look at the fvt instructions for the app battery
apps. They are all pointed to from the following page:
http://www.linuxbase.org/appbat/cert.html
The particular fvt for rsync,
http://www.linuxbase.org/appbat/fvt/lsb-rsync_fvt.html, involves setting up
the system under test as an rsync server and creates a simple rsync.conf
file. Take a look and see if you think it is sufficient.
Regards,
Marvin Heffler
Linux Standard Base and Developers Toolbox
IBM Linux Technology Center
11400 Burnet Road, Zip 908-1A33
Austin, TX 78758
(512) 838-0953 T/L 678-0953
"Wichmann, Mats D" <mats.d.wichmann@intel.com> on 08/07/2002 01:49:14 PM
To: "Lsb-Impl (E-mail)" <lsb-impl@lists.linuxbase.org>,
lsb-appbat@freestandards.org
cc:
Subject: 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
--
To UNSUBSCRIBE, email to lsb-impl-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email
listmaster@lists.linuxbase.org
Reply to: