> If I get it to work I will try to create a new rpm that will check to
> see if there is xinetd or inetd on the system and configure it for the
> right one.
Here's what I wrote for another project which adds stuff to inetd.conf,
copied & modified for fam (but not tested). It adds --without-inetd and
--with-xinetd flags to the configure script, and if it's configured
--with-xinetd, it installs the config file in /etc/xinetd.d and runs
killall -USR1 xinetd.
Normally, to build rpm packages which work on as many systems as possible,
I think you'd want to configure --with-inetd (the default) and
--with-xinetd, so it would wind up attempting to add the service to both
inetd and xinetd (which is not so good). I'm not real happy with it;
do you/anyone have a better approach? (Or a test for xinetdconfdir?)
It would probably be better to test for inetd/xinetd at install time,
rather than configure time, but I don't think rpm can handle conditionally
installed files. (You could install it manually in %post, but then "rpm
-qf /etc/xinetd.d/fam" wouldn't know anything about the file, which I
don't like.)
Anyway, here's what I came up with. In configure.in:
AC_ARG_WITH(inetd,
[ --without-inetd don't add it to inetd.conf], [inetd=$withval])
AC_ARG_WITH(xinetd,
[ --with-xinetd add it to xinetd.d], [xinetd=$withval])
AM_CONDITIONAL(SUPPORT_INETD, test "$inetd" != no)
AM_CONDITIONAL(SUPPORT_XINETD, test "$xinetd" = yes)
dnl Dude, nice test.
xinetdconfdir=/etc/xinetd.d
AC_SUBST(xinetdconfdir)
In fam/xinetd/Makefile.am (fam/xinetd/fam would be listed in configure.in's
AC_OUTPUT so that it would be generated by config.status from
fam/xinetd/fam.in, so that the path to the fam executable etc. would be
determined by the configure script):
if SUPPORT_XINETD
xinetdconf_DATA = fam
endif
EXTRA_DIST = fam.in
fam/xinetd/fam.in would look like the xinetd.d entry I sent you before,
with @bindir@ instead of the hard-coded path, etc. (Maybe that's the
only change.)
build/rpm/rpm.spec.in is where it gets ugly:
%files
...
@SUPPORT_XINETD_TRUE@ %config @xinetdconfdir@/fam
...
%post
@SUPPORT_INETD_TRUE@ echo "Adding fam to inetd.conf"
@SUPPORT_INETD_TRUE@ %{editconf} inetd.conf add '\b(fam|FAM)\b' \
@SUPPORT_INETD_TRUE@ "# fam, the File Alteration Monitor,
http://oss.sgi.com/projects/fam/"; \
@SUPPORT_INETD_TRUE@ "sgi_fam/1-2 stream rpc/tcp wait root @bindir@/fam
fam"
@SUPPORT_INETD_TRUE@ echo "Restarting inetd..."
@SUPPORT_INETD_TRUE@ killall -HUP inetd || true
@SUPPORT_XINETD_TRUE@ echo "Restarting xinetd"
@SUPPORT_XINETD_TRUE@ killall -USR1 xinetd || true
...
%preun
if test "$1" = 0; then
...
@SUPPORT_INETD_TRUE@ echo "Removing fam from inetd.conf..."
@SUPPORT_INETD_TRUE@ %{editconf} inetd.conf remove '\b(fam|FAM)\b'
@SUPPORT_INETD_TRUE@ echo "Restarting inetd..."
@SUPPORT_INETD_TRUE@ killall -HUP inetd || true
@SUPPORT_XINETD_TRUE@ echo "Restarting xinetd"
@SUPPORT_XINETD_TRUE@ killall -USR1 xinetd || true
> The other problem I have is whether or not there is a version of the
> imon patches that will apply cleanly to a 2.4.x kernel (non-test). The
> kernel's I'm working with are from the xfs project (currently a 2.4.2
> based tree).
You'd think you could use SGI's imon patch with the kernel version used by
SGI's xfs project... Actually, the most recent versions of the imon patch
were contributed by E. Brian Gast. There will be a version for 2.4.2 when
someone sends one to the list. :)
--Rusty
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|