Use of rcorder for local rc.d/*.sh scripts

[Brooks Davis]

On Tue, Jun 07, 2005 at 03:11:09PM -0400, J.R. Oldroyd wrote:
> On Jun 07, 10:37, Brooks Davis wrote:
> > >                          So, if this approach were adopted, several
> > > changes will be needed to all local rc scripts:
> > > 	- any with a .sh suffix will need to be renamed from
> > > 	  "foo.sh" to "foo"
> > > 	- any files like "*.sh.sample" will have to be moved
> > > 	  elsewhere, or made non-executable
> > > 	- rcorder tags will need to be added to any that care
> > > 	  about the order of their execution, and names like
> > > 	  "000.*" can be eliminated
> > 
> > There is very little chance of getting this to fly.  Remember, any
> > solution has to work for all releases currently supported by ports.  In
> > practice, this currently means the security branches so anything that
> > breaks existing localpkg based systems is not going to work.  I think
> > that keeping the .sh extension is going to be required for the
> > foreseeable future.  Requiring that rcorder runs on all the .sh files
> > generate an appropriate order is probably a reasonable goal for 6.0.
> > If we did that in 6.0, we could require the removal of non .sh files for
> > 7.0 and remove the .sh extensions through a release dependent action in
> > the RC_SUBR support in bsd.port.mk.  In theory you could do the RC_SUBR
> > changes for 6.0, but big changes to requirements for ports are very time
> > consuming, especially if you are going to modify bsd.port.mk.
> > 
> > Any change of this order is going to require discussion on ports, and
> > buy-in from portmgr.
> > 
> 
> Is this as bad as you're suggesting?

Possibly. :-| The curse of having nearly 13,000 ports is that changes in
any significant portion are quite difficult if you have to have a flag
day.  It's by no means impossible, but it's a lot of work.

> Agreed, requiring "foo.sh" be renamed to "foo" for so many ports
> is a biggie, so perhaps we keep the *.sh for now, and arrange that
> files in the local scripts dirs are run in a subshell from rc.subr,
> rather than being sourced.  This is probably important for security
> reasons, anyway.  It also keeps existing semantics, so should work
> on all systems.
> 
> It also eliminates the issue with foo.sh.sample as such files
> will continue to be ignored.

I think we definitely want to keep the existing semantics of *.sh scripts
being run for the time being, if not permanently.

> We only need to add rcorder tags on ports which currently use
> "NNN.foo.sh" scripts, and we could even delay this by introducing
> an extra rc.conf flag to have /etc/rc execute any local NNN files
> immediately after SERVERS or such suitable point.

The trick is finding all of them.  We don't currently have a plist
database.  It's something that needs to happen, but until it exists,
finding all the rc files is an interesting challenge.  It's probably not
infeasible by 6.0 though if you can get kris to help you.

> If you feel this is not the desired direction, let's revert back
> to the "localpkg hack".  My goal here was to simply introduce the
> use of rcorder for local scripts so that those scripts which do
> have tags can take advantage of them and thereby fix a problem
> in which some things currently don't start.

What I like about the localpkg hack is that it doesn't change much.  I
think you have solutions to most of my concerns though.  My gut feeling
is that full integration of /usr/local in rcorder is not feasible for
6.0, but localpkg with rcorder should be.  Remember, feature freeze is
nominally Friday.  My suggestion would be to push for the localpkg hack
and the port changes it requires for 6.0 so ports can depend on
each other's services with the plan of doing full integration in 7.0.
That would get the most critical feature working now and give us over a
year to shake out any issues with full ordering.  After a good period of
settling, I think we could even MFC the localpkg hack to 5.x, probably in
time for 5.5.  If that, happened, I think we'd be able to fully mandate
rc.d style scripts for 7.0 because all supported versions of FreeBSD
would run rcorder on their scripts.

BTW, thanks for working on this.  It's a feature I've been wanting for
some time now.  As always the devil is the details.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20050608/efb849e2/attachment.bin