Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Robert Watson [EMAIL PROTECTED] writes: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I'd discourage that. It's fairly intrusive and breaks existing setups. I'm NOT going to repartition and reinstall! (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. I don't think there shall be devils in the implementation details. I admit not having looked at rcorder yet, but dependencies can be passed on from one rcorder run to the next, through the usual process environment. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. /etc/local/rc.d might work, it's quite similar to the /etc/opt approach configuration stuff for /opt applications on Linux. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Seconded from the user's view. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Oliver Eikemeier wrote: The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, Nov 30, 2003 at 10:45:40AM -0500, Richard Coleman wrote: Oliver Eikemeier wrote: The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Andreas Klemm wrote: I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Richard Coleman [EMAIL PROTECTED] writes: But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Ports belong into /usr/local, not into /etc. There should be some hook that allows port start scripts to run before some base system scripts, and if Oliver's two-staged reevaluate approach supports this with / and /usr in separate partitions, then why not take his suggestion? There's nothing that prevents RCNG from stretching out its fangs to /usr/local/etc/rc*, in fact, hier(7) encourages that. If I get the picture right, what's suggested is that after mounting local file systems, the RC order is re-evaluated, and again after mounting remote file systems (diskless). This would allow the system to gradually complete its /etc/rc* picture. Another idea would be to use unionfs or something to keep /usr/local/etc/rc.d in the root partition for real, and when it's shadowed by the actual /usr/local or /usr mount, punch a hole so you can look at the rootfs with unionfs or something. I'd like Oliver's suggestion better though. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Matthias Andree wrote: Richard Coleman [EMAIL PROTECTED] writes: But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Ports belong into /usr/local, not into /etc. There should be some hook that allows port start scripts to run before some base system scripts, and if Oliver's two-staged reevaluate approach supports this with / and /usr in separate partitions, then why not take his suggestion? There's nothing that prevents RCNG from stretching out its fangs to /usr/local/etc/rc*, in fact, hier(7) encourages that. If I get the picture right, what's suggested is that after mounting local file systems, the RC order is re-evaluated, and again after mounting remote file systems (diskless). This would allow the system to gradually complete its /etc/rc* picture. Another idea would be to use unionfs or something to keep /usr/local/etc/rc.d in the root partition for real, and when it's shadowed by the actual /usr/local or /usr mount, punch a hole so you can look at the rootfs with unionfs or something. I'd like Oliver's suggestion better though. I guess I'm not really arguing for putting the startup scripts for ports in /etc/rc.d (contradicting what I said earlier). But I do think that RCNG/rcorder needs to be extended to handle ports. And it needs to be done in a more comprehensive fashion than just adding special hooks for backend databases. The multiple rcorder evaluation method you mention sounds like a good place to start. The unionfs idea is also interesting. But I doubt many people trust it enough to use it for this purpose. It's a shame really, but that's another discussion. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, 30 Nov 2003, Richard Coleman wrote: Andreas Klemm wrote: I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Perhaps we just need to place wrapper startup script, that will try to start real startup script in /usr/local/etc/rc.d if it exist? Most of ports are installed into /usr/local, so, lets don't use hierarchy above that. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: On Sun, 30 Nov 2003, Richard Coleman wrote: snip For 5.2-RELEASE, I think we should ignore the whole issue and let the couple of ports that insert things in /etc/rc.d just do it. We're not going to find any other solution in time to either close the discussion or test it properly. For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote: On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: On Sun, 30 Nov 2003, Richard Coleman wrote: ..snip.. For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
David O'Brien wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. That abandons the ability to have a read-only /usr. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Robert Watson wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research I think this message sums up the options quite nicely. I like option 2 the best, with option 3 a close second. I think either would be an acceptable compromise. Option 1 abandons the ability for read-only /usr, which many people like. That and the NFS problems that Robert mentioned should rule this out. But I like anything over doing nothing (option 4). Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Mon, 1 Dec 2003, Richard Coleman wrote: (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. ... I'm actually leaning towards (2) as being the best solution, as it's easy and functional. I think this message sums up the options quite nicely. I like option 2 the best, with option 3 a close second. I think either would be an acceptable compromise. Option 1 abandons the ability for read-only /usr, which many people like. That and the NFS problems that Robert mentioned should rule this out. But I like anything over doing nothing (option 4). Having written the e-mail, I should really have indicated that either (2) or (3) is a winner, and (3) is probably easier. Comes of spending a lot of time on the description of the solutions, and little time on the opinion :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Kris pgp0.pgp Description: PGP signature
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Sorry that I missed that thread, our ISP has f*cked up our connection. The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
