Re: RC NG, ntp and routed
Brad Knowles wrote: At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: > NETWORKING ... does not, in itself, depend on any filesystems. >> Sure it does. In order to do anything, you have to run programs -- right? The NETWORKING script does nothing. It runs no programs, therefore it needs no filesystems. It's purely a placeholder to simplify dependency specifications: all networking initialization is gauranteed to happen before NETWORKING. Therefore, scripts that require networking (such as lpd, sshd, ftpd, etc.) can safely depend on NETWORKING without having to know the details of the network initialization. For example, someone who needs a special routing daemon can add a script that REQUIREs network2 and comes BEFORE NETWORKING, and then their routing daemon will be started at the appropriate time: before any network-capable daemons (or remote filesystems), but after the initial interface configuration. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Mike Makonnen wrote: If you are using a daemon essential to network connectivity in /usr/local and at the same time have it (/usr/local) mounted remotely, then you haven't thought things through properly. Listen, I think we're talking past each other here. I _am_ in favour of adding routing to NETWORKING (look at an earlier email in the thread). My only argument is that if an admin chooses to use a daemon from ports then he should be bright enough to include it in a local filesystem. Good. That's what I'm saying too. :-) Well, that, and that local filesystems should be mounted before networking, and remote fs afterwards (which, as I see, is the present case). -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "A University without students is like an ointment without a fly." -- Ed Nather, professor of astronomy at UT Austin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Thu, Dec 12, 2002 at 08:09:24AM -0200, Daniel C. Sobral wrote: > > I mean that routed is _one_ routing daemon, one that supports the old, > would someone please shot it in the head to give it peace, RIP. If you > happen to run a modern routing protocol... hell, if you happen to run a > middle-aged routing protocol, you'll be using something else. > > And, since you do not seem to be aware of it, Zebra, for one, is run as... > > router_enable="YES" > router="/usr/local/sbin/zebractl" > router_flags="start" If you are using a daemon essential to network connectivity in /usr/local and at the same time have it (/usr/local) mounted remotely, then you haven't thought things through properly. Listen, I think we're talking past each other here. I _am_ in favour of adding routing to NETWORKING (look at an earlier email in the thread). My only argument is that if an admin chooses to use a daemon from ports then he should be bright enough to include it in a local filesystem. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48610/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
Brad Knowles wrote: At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: > The point of the barrier scripts is to provide > simple dependencies to other scripts. In particular, > NETWORKING should represent a fully-functional > network, including any routing or multicast routing that is > normally used on this network. It does not, in itself, depend > on any filesystems. (It runs no programs itself, so why would it?) Sure it does. In order to do anything, you have to run programs -- right? And where do those programs come from -- a filesystem, right? And what if that filesystem is not local, but mounted via NFS? So, you need a way to bootstrap the early parts of networking before mounting the later filesystems. This I disagree with. Networking should bring the network up. If something is necessary to bring the network up, it should be available locally. Remote filesystems should come _after_ the network is up. If a program needed to bring networking up is on a remote fs, then there is a problem with the system project. If it so happens to work without a fully functional network, good for it, but it's designer must shoulder the burden of supporting it. The standard way of doing things should be get the network up, and _then_ mounting the remote fs. Daemons which _depend_ on network are not part of networking, of course. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] A day without orange juice is like a day without orange juice. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: The point of the barrier scripts is to provide simple dependencies to other scripts. In particular, NETWORKING should represent a fully-functional network, including any routing or multicast routing that is normally used on this network. It does not, in itself, depend on any filesystems. (It runs no programs itself, so why would it?) Sure it does. In order to do anything, you have to run programs -- right? And where do those programs come from -- a filesystem, right? And what if that filesystem is not local, but mounted via NFS? So, you need a way to bootstrap the early parts of networking before mounting the later filesystems. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Doug Barton wrote: On Wed, 11 Dec 2002, Mike Makonnen wrote: >I don't understand what you are saying. Why would we have routing run after >local filesystems are mounted but before the network is up? What if /usr/local is an nfs-mounted partition (like it is on my systems, both at home and work)? As for that, I already answered. If you have /usr/local nfs-mounted, one of the following two things are happening: 1) You do not use a dynamic router in that host. 2) You use a dynamic router that is not resident in /usr/local, either by design (you use /usr/sbin/routed), or because you moved it from /usr/local to a locally-mounted fs. Let's try to put that in another perspective. Let's consider two possibilities: 1) You use routed_enable="NO". In that case, nothing will change for you, except locally mounted fs becoming available a bit earlier. 2) You use routed_enable="YES". This we subdivide in: 2.1) You need a router to mount remote fs. For this case, it follows that your router, whatever it is, is _not_ located in the remote fs. 2.2) You do not need a router to mount remote fs. Either because all remote fs are directly connected (ie, on one of the networks you belong to), or because you have a static route to each of them. This case might or might not present you with a problem. If you use a router which is located on a remote fs, then, indeed, the proposed ordering will cause you trouble. I argue, though, that this configuration is intrinsically wrong, because it depends on a particularity if your topology (the fact that the remote filesystems do not need the dynamic router, but normal operation does). Now... to me things seem simple. You can mount local fs very early, so there shouldn't be any trouble having them before network. And if you have them before network, there shouldn't be any problem having routed about network2, where it should logically belong. Am I missing something here? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Nature makes boys and girls lovely to look upon so they can be tolerated until they acquire some sense. -- William Phelps To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Mike Makonnen wrote: On Wed, Dec 11, 2002 at 03:28:12PM -0200, Daniel C. Sobral wrote: >[root@piratinga root]# ls -l /usr/local/sbin/ospfd >-r-xr-xr-x 1 root wheel 471392 Dec 1 00:58 /usr/local/sbin/ospfd* >[root@piratinga root]# ls -l /usr/local/sbin/bgpd >-r-xr-xr-x 1 root wheel 691952 Dec 1 00:58 /usr/local/sbin/bgpd* Who said anything about moving ports into /? I meant the routing daemons in /usr/sbin. But as Gordon pointed out that's still quite a bit of disk space. I mean that routed is _one_ routing daemon, one that supports the old, would someone please shot it in the head to give it peace, RIP. If you happen to run a modern routing protocol... hell, if you happen to run a middle-aged routing protocol, you'll be using something else. And, since you do not seem to be aware of it, Zebra, for one, is run as... router_enable="YES" router="/usr/local/sbin/zebractl" router_flags="start" ie, it is run by /etc/rc.d/routed. A very good thing, in fact, since one _needs_ it to be run early. So, please, let's not assume one is using routed(8), just like we do not assume one is using sendmail(8). >And all this because... people don't want to break fs mounting in local >and remote? > >I saw break it, and have routing run after local. If your /usr is >remote, then either you'll copy routed (or whatever you use) to a local >disk, or you won't be using it. > >People, let's face it. There *ARE* things you want to be run *after* >local fs mount and *before* remote fs mount. And we are hurting >ourselves in a few places just because we haven't admitted to it. I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? Not before network is up. Before one mounts remote filesystems. Network is _not_ up until routing is in place. For most configurations, that is done in network2 (see defaultrouter). For a few, it needs routed. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY: #32: You call your answering service and they've never heard of you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Mike Makonnen wrote: I still don't see how having the routing daemon start before the network interfaces come up helps you. The correct order seems to me: local filesystem, network, routing, remote filesystem. Am I missing something here? That what it looks like from where I'm sitting too. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The great nations have always acted like gangsters and the small nations like prostitutes. -- Stanley Kubrick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 10:11:18PM -0800, Doug Barton wrote: > On Wed, 11 Dec 2002, Mike Makonnen wrote: > > > I don't understand what you are saying. Why would we have routing run after > > local filesystems are mounted but before the network is up? > > What if /usr/local is an nfs-mounted partition (like it is on my systems, > both at home and work)? I still don't see how having the routing daemon start before the network interfaces come up helps you. The correct order seems to me: local filesystem, network, routing, remote filesystem. Am I missing something here? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48584/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, 11 Dec 2002, Mike Makonnen wrote: > I don't understand what you are saying. Why would we have routing run after > local filesystems are mounted but before the network is up? What if /usr/local is an nfs-mounted partition (like it is on my systems, both at home and work)? > > btw, someone mentioned a freebsd-rc list, but I found no such list. > > Mispelling? Not freebsd.org list? Delusions? > > Yahoo! . Sorry, my fault. http://groups.yahoo.com/group/FreeBSD-rc/ -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 03:28:12PM -0200, Daniel C. Sobral wrote: > > [root@piratinga root]# ls -l /usr/local/sbin/ospfd > -r-xr-xr-x 1 root wheel 471392 Dec 1 00:58 /usr/local/sbin/ospfd* > [root@piratinga root]# ls -l /usr/local/sbin/bgpd > -r-xr-xr-x 1 root wheel 691952 Dec 1 00:58 /usr/local/sbin/bgpd* Who said anything about moving ports into /? I meant the routing daemons in /usr/sbin. But as Gordon pointed out that's still quite a bit of disk space. > > And all this because... people don't want to break fs mounting in local > and remote? > > I saw break it, and have routing run after local. If your /usr is > remote, then either you'll copy routed (or whatever you use) to a local > disk, or you won't be using it. > > People, let's face it. There *ARE* things you want to be run *after* > local fs mount and *before* remote fs mount. And we are hurting > ourselves in a few places just because we haven't admitted to it. I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? > > btw, someone mentioned a freebsd-rc list, but I found no such list. > Mispelling? Not freebsd.org list? Delusions? Yahoo! . Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48580/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
The point of the barrier scripts is to provide simple dependencies to other scripts. In particular, NETWORKING should represent a fully-functional network, including any routing or multicast routing that is normally used on this network. It does not, in itself, depend on any filesystems. (It runs no programs itself, so why would it?) There are not going to be many scripts that require partial network functionality; I see little advantage to defining new barriers for a partially-working network. Whether NETWORKING or FILESYSTEMS comes first is irrelevant, since neither one requires the other. If a particular network script requires a local filesystem, it should say so: REQUIRE: filesystem_local or, if you prefer, REQUIRE: mountcritlocal Likewise, a filesystem script that requires full or partial networking should say so. Again, FILESYSTEMS itself does not require any networking. It would be nice if there were some way for the filesystem mounting scripts to PROVIDE those filesystems that they actually mount. Then other scripts could, for example, REQUIRE: /bin, /usr/local to ensure that the tools they need are, in fact, present. Unfortunately, I don't see any way to do this with the current rcNG system. There are a couple of approaches that might provide such functionality, but all the ones that come to mind require dumping rcorder and integrating order calculations into rc.subr. (In particular, you can't always know what features a script has provided until it has run to completion.) Gordon Tetlow asks: Does anyone have a problem with dyking out the NetBSD specific portions after 5.0? I certainly don't. Mike Makonnen suggested: ... let's move the routing daemons from /usr/sbin to /sbin. To which Gordon Tetlow responded: Lest we forget, / is statically linked. that 42k binary turns into a 450k binary in /sbin. There's work in progress to convert / to dynamic linking. _If_ that work is accepted by the group, then that would address Gordon's concern. Of course, a dynamic / does not give carte blanche to move the entire world into /sbin, either. I also agree with the poster who pointed out that folks who have a remote /usr and rely on dynamic routing can easily work around this issue on a case-by-case basis. The whole point of having fine-grained rc.d scripts is to simplify customizations. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Gordon Tetlow wrote: On Wed, Dec 11, 2002 at 12:46:03AM -0800, Mike Makonnen wrote: >You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. >I think if we have routed there we might as well have the others there. Actually we >only need to move route6d to /sbin. I can't think of a reason you would need >multicast routing before the whole system was up. I think we can live with and >additional 42k on /. Lest we forget, / is statically linked. that 42k binary turns into a 450k binary in /sbin. The / solution is wrong. For instance: [root@piratinga root]# ls -l /usr/local/sbin/ospfd -r-xr-xr-x 1 root wheel 471392 Dec 1 00:58 /usr/local/sbin/ospfd* [root@piratinga root]# ls -l /usr/local/sbin/bgpd -r-xr-xr-x 1 root wheel 691952 Dec 1 00:58 /usr/local/sbin/bgpd* And these are dynamically linked. Not to mention moving them to / would break the /usr/local paradigm. And all this because... people don't want to break fs mounting in local and remote? I saw break it, and have routing run after local. If your /usr is remote, then either you'll copy routed (or whatever you use) to a local disk, or you won't be using it. People, let's face it. There *ARE* things you want to be run *after* local fs mount and *before* remote fs mount. And we are hurting ourselves in a few places just because we haven't admitted to it. btw, someone mentioned a freebsd-rc list, but I found no such list. Mispelling? Not freebsd.org list? Delusions? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Can you buy friendship? You not only can, you must. It's the only way to obtain friends. Everything worthwhile has a price. -- Robert J. Ringer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 12:46:03AM -0800, Mike Makonnen wrote: > You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. > I think if we have routed there we might as well have the others there. Actually we > only need to move route6d to /sbin. I can't think of a reason you would need > multicast routing before the whole system was up. I think we can live with and > additional 42k on /. Lest we forget, / is statically linked. that 42k binary turns into a 450k binary in /sbin. -gordon msg48529/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 09:16:27AM -0200, Daniel C. Sobral wrote: > > Mm. How about ntpd running in multicast mode? :-) Hah! I knew I should have checked that before I opened my mouth. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48525/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
Mike Makonnen wrote: You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. I think if we have routed there we might as well have the others there. Actually we only need to move route6d to /sbin. I can't think of a reason you would need multicast routing before the whole system was up. I think we can live with and additional 42k on /. Mm. How about ntpd running in multicast mode? :-) Which just so happens to be the very next thing I want to do about ntpd on my network. -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
Gordon Tetlow wrote: On Tue, Dec 10, 2002 at 02:50:14PM -0800, Mike Makonnen wrote: >On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote: > >>On another note, I thought the patch a bit excessive. Here, I just added >>BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more. > >It's not excessive. It's the correct solution. >Your solution solves your specific problem but it's >not the right way to go about solving the problem. It's kind of hard to >explain, you have to work with it for a while to get the hang of it. For >some things it might be easier _and_ right to say this must come before >that. In this case; however, ntpd requires that routing be available as a >prerequisite, but there's no real relationship that exists between >the two that necessitates routed having to know about ntpd. If we were >to follow your example to its logical conclusion the BEFORE line for >the routing daemons would have to include _every_ daemon that requires >network availability. I think in this case it would be more correct to >have the network daemons REQUIRE the routing daemons. Does that make >sense? I agree with this analysis. It's just that the patch presented touched more files than ntpd alone. Ideally, ntpd should require NETWORKING and that should solve all problems. The real problem is that routed is included with DAEMON, not NETWORKING. I think that's the real problem and judging that routed is in /sbin, we could probably move it there without a problem. Err, not so fast, please. FreeBSD's routed is in /sbin, but I daresay quite a few of those who actually need a dynamic router resort to ports (specifically, Zebra and Gated). So let's not haste needlessly here. We are in code freeze, and these changes need not enter before 5.0-R. Let's understand the problem and the issues throughly, and produce a correct solution. -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 10:33:48PM -0800, Gordon Tetlow wrote: > > That sounds like a good idea. According to current NETWORKING requirements it > > just means the network interfaces are brought up, but routing seems to be a > > reasonable requirement as well. I can't think of a good reason why it would > > not be a good idea. Maybe we could move the other routing daemons > > there as well (from /usr/sbin)? > > Well, there in lies the chicken and the egg problem (and why I've been > cursing rcng recently). /usr is mounted after networking so all the things > that implictly require /usr must be run after networking is setup (but what > about things like route6d that is in /usr/sbin?) You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. I think if we have routed there we might as well have the others there. Actually we only need to move route6d to /sbin. I can't think of a reason you would need multicast routing before the whole system was up. I think we can live with and additional 42k on /. > > IMO rc.d should have the following major catagories: > > DISKS > FILESYSTEMS > NETWORKING > DAEMON > LOGIN I don't see the need for FILESYSTEMS. As it is we only have two scripts mountcritlocal and mountcritremote. And since network mounted filesystems are quite common any script that needs FILESYSTEM is simply going to have to wait until NETWORKING is up. There's no way we can get around that. > NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also > describes a SERVERS catagory that I don't really understand the need for. Basicaly it's for daemons that you need running as early as possible, like syslogd. Other services are going to need them, but you can't really fit them in the other categories. > > I'd like to think about really sitting down and overhauling the rc.d > system after 5.0 is branched. I think that it's reasonable to say we > should not try to be compatible with NetBSD except for keeping a common > rc.subr and major initialization catagories (basically anything that is > in all caps). Does anyone have a problem with dyking out the NetBSD > specific portions after 5.0? I was quite a ways through porting our scripts when David insisted that they be compatible with NetBSD in order to make it into the tree. It took quite a bit more work to restart almost from the beginning and redo them. And I would hate to see that work go to waste. So, I'm not an impartial party here and won't say anymore about it except to say that I think being in sync with NetBSD is a worthwhile and doable goal if we (both projects) make a firm commitment to do it. This means that we wouldn't be "slavishly" accepting NetBSD code, but that the projects would work the differences out so that the only differences left would be because of architectural differences between the two OSes. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48516/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 08:17:50AM +0100, Brad Knowles wrote:
>
> I believe that DISKS should be split into DISKS_LOCAL and
> DISKS_NETWORK. This allows us to get NETWORKING going after
> DISKS_LOCAL and before DISKS_NETWORK.
Don't over-engineer it. This is the order it is done in now.
The barier scripts are supposed to be major milestones. With your
suggestion DISKS_{LOCAL,NETWORK) would each have _only_ one
dependency (mountcritlocal and mountcritremote, respectively), so
what would be the point then?
> We may also want to split
> NETWORKING into INTERFACES and ROUTING (and higher level networking),
> in case there is anything that we might need to slide in-between. We
> might even need to split NETWORKING into three parts.
I think the current barrier scripts plus Gordon's suggestion to
include routing in NETWORKING works ok. However, improvements
to /etc/rc.d/network1 to allow bringing up/down the interfaces
individually would be nice.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48512/pgp0.pgp
Description: PGP signature
Re: RC NG, ntp and routed
At 10:33 PM -0800 2002/12/10, Gordon Tetlow wrote: DISKS FILESYSTEMS NETWORKING DAEMON LOGIN DISKS would be things that are needed to get the disks in order to start getting filesystems mounted (vinum, ccd, raidframe and friends). It may be a superflous step. FILESYSTEMS and NETWORKING are a problem because they kind of intertwine. It's not a clear cut case of mount all the filesystems then start the networking interfaces. In reality, FILESYSTEMS and NETWORKING are very much muddled (and cause me no end of grief as a result). DAEMON is for things like ssh and the like that need to run (thinking about nfsd, sshd, and just about any *d) LOGIN is just that. Things that are started at the end of system initialization. I believe that DISKS should be split into DISKS_LOCAL and DISKS_NETWORK. This allows us to get NETWORKING going after DISKS_LOCAL and before DISKS_NETWORK. We may also want to split NETWORKING into INTERFACES and ROUTING (and higher level networking), in case there is anything that we might need to slide in-between. We might even need to split NETWORKING into three parts. I'd like to think about really sitting down and overhauling the rc.d system after 5.0 is branched. I think that it's reasonable to say we should not try to be compatible with NetBSD except for keeping a common rc.subr and major initialization catagories (basically anything that is in all caps). Does anyone have a problem with dyking out the NetBSD specific portions after 5.0? Nope. It's nice to be as close as we can feasibly get, but if it doesn't work then it doesn't work, and we shouldn't unnecessarily handicap ourselves just to be compatible. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Tue, 10 Dec 2002, Gordon Tetlow wrote: > I'd like to think about really sitting down and overhauling the rc.d > system after 5.0 is branched. I think that it's reasonable to say we > should not try to be compatible with NetBSD except for keeping a common > rc.subr and major initialization catagories (basically anything that is > in all caps). Does anyone have a problem with dyking out the NetBSD > specific portions after 5.0? Well, now you're hitting on the points I was trying to make before we embarked on this voyage, and no one thought they were worthwhile. :) Namely, that as good as netbsd's rc is, it's a first draft; and something I'd like to see us improve on. That said, before we make the rash decision to just chuck it altogether, I still suggest that we discuss this on the freebsd-rc list, where Luke can get involved if he chooses to. While I don't think that we should slavishly adopt netbsd stuff for its own sake, I also don't think that we should abandon the idea of working with them to produce a system that we can both use without carefully examining the situation. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 09:47:54PM -0800, Mike Makonnen wrote: > On Tue, Dec 10, 2002 at 04:23:18PM -0800, Gordon Tetlow wrote: > > > > Ideally, ntpd should require NETWORKING and that should solve all problems. > > The real problem is that routed is included with DAEMON, not NETWORKING. I > > think that's the real problem and judging that routed is in /sbin, we could > > probably move it there without a problem. > > That sounds like a good idea. According to current NETWORKING requirements it > just means the network interfaces are brought up, but routing seems to be a > reasonable requirement as well. I can't think of a good reason why it would > not be a good idea. Maybe we could move the other routing daemons > there as well (from /usr/sbin)? Well, there in lies the chicken and the egg problem (and why I've been cursing rcng recently). /usr is mounted after networking so all the things that implictly require /usr must be run after networking is setup (but what about things like route6d that is in /usr/sbin?) IMO rc.d should have the following major catagories: DISKS FILESYSTEMS NETWORKING DAEMON LOGIN DISKS would be things that are needed to get the disks in order to start getting filesystems mounted (vinum, ccd, raidframe and friends). It may be a superflous step. FILESYSTEMS and NETWORKING are a problem because they kind of intertwine. It's not a clear cut case of mount all the filesystems then start the networking interfaces. In reality, FILESYSTEMS and NETWORKING are very much muddled (and cause me no end of grief as a result). DAEMON is for things like ssh and the like that need to run (thinking about nfsd, sshd, and just about any *d) LOGIN is just that. Things that are started at the end of system initialization. NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also describes a SERVERS catagory that I don't really understand the need for. I'd like to think about really sitting down and overhauling the rc.d system after 5.0 is branched. I think that it's reasonable to say we should not try to be compatible with NetBSD except for keeping a common rc.subr and major initialization catagories (basically anything that is in all caps). Does anyone have a problem with dyking out the NetBSD specific portions after 5.0? -gordon -gordon msg48505/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 04:23:18PM -0800, Gordon Tetlow wrote: > > Ideally, ntpd should require NETWORKING and that should solve all problems. > The real problem is that routed is included with DAEMON, not NETWORKING. I > think that's the real problem and judging that routed is in /sbin, we could > probably move it there without a problem. That sounds like a good idea. According to current NETWORKING requirements it just means the network interfaces are brought up, but routing seems to be a reasonable requirement as well. I can't think of a good reason why it would not be a good idea. Maybe we could move the other routing daemons there as well (from /usr/sbin)? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48503/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 02:50:14PM -0800, Mike Makonnen wrote: > On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote: > > On another note, I thought the patch a bit excessive. Here, I just added > > BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more. > > It's not excessive. It's the correct solution. > Your solution solves your specific problem but it's > not the right way to go about solving the problem. It's kind of hard to > explain, you have to work with it for a while to get the hang of it. For > some things it might be easier _and_ right to say this must come before > that. In this case; however, ntpd requires that routing be available as a > prerequisite, but there's no real relationship that exists between > the two that necessitates routed having to know about ntpd. If we were > to follow your example to its logical conclusion the BEFORE line for > the routing daemons would have to include _every_ daemon that requires > network availability. I think in this case it would be more correct to > have the network daemons REQUIRE the routing daemons. Does that make > sense? Ideally, ntpd should require NETWORKING and that should solve all problems. The real problem is that routed is included with DAEMON, not NETWORKING. I think that's the real problem and judging that routed is in /sbin, we could probably move it there without a problem. -gordon msg48493/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 08:22:08AM -0800, Gordon Tetlow wrote: > > I think keeping our boot scripts the same is kind of a pipe dream. I think > we should keep our rc.subr the same, but for individual scripts, I think we > should just go our own way. I can see how keeping every we possibly can the same can make things easier and I'm in favor of it. What I don't like is this stradling the middle business. It's all or nothing. We can't keep some things in sync and others not because the parts make up the whole. If we change some parts that's going to affect other parts, which in turn is going to affect the whole. This is really frustrating sometimes. So, in short: "Please let's pick a path and follow it whole-heartedly!" Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48488/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote: > On another note, I thought the patch a bit excessive. Here, I just added > BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more. It's not excessive. It's the correct solution. Your solution solves your specific problem but it's not the right way to go about solving the problem. It's kind of hard to explain, you have to work with it for a while to get the hang of it. For some things it might be easier _and_ right to say this must come before that. In this case; however, ntpd requires that routing be available as a prerequisite, but there's no real relationship that exists between the two that necessitates routed having to know about ntpd. If we were to follow your example to its logical conclusion the BEFORE line for the routing daemons would have to include _every_ daemon that requires network availability. I think in this case it would be more correct to have the network daemons REQUIRE the routing daemons. Does that make sense? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48487/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
Gordon Tetlow wrote: On Mon, Dec 09, 2002 at 06:43:50PM -0800, Mike Makonnen wrote: >The following patch should solve your problem. However, >it's only a partial solution. It fixes the case for ntpd >and ntpdate but not for other network daemons like rpcbind, which still get >started _before_ the routing daemons. I haven't included patches for >those because sorting out the dependencies is going to be a bit more >involved. I'll have it done when I get a chance later this week. >(A consequence of this is going to be that we will be moving *away* from > NetBSD in the dependency ordering, but we can sort that out with them later). I think keeping our boot scripts the same is kind of a pipe dream. I think we should keep our rc.subr the same, but for individual scripts, I think we should just go our own way. I disagree. NetBSD uses the same ntpd as us, and, therefore, face the very same problem. They just haven't noticed the problem in practice. On another note, I thought the patch a bit excessive. Here, I just added BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more. Anyway, as long as routed is run before ntpd on systems where it is active, I'm happy. Nor do I think we need to get the patch in now, before 5.0-R. The kind of environment where the problem would show up is uncommon, and not likely to be found outside production settings, and 5.0-R is _not_ indicated for production settings. -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
On Mon, Dec 09, 2002 at 06:43:50PM -0800, Mike Makonnen wrote: > > The following patch should solve your problem. However, > it's only a partial solution. It fixes the case for ntpd > and ntpdate but not for other network daemons like rpcbind, which still get > started _before_ the routing daemons. I haven't included patches for > those because sorting out the dependencies is going to be a bit more > involved. I'll have it done when I get a chance later this week. > (A consequence of this is going to be that we will be moving *away* from > NetBSD in the dependency ordering, but we can sort that out with them later). I think keeping our boot scripts the same is kind of a pipe dream. I think we should keep our rc.subr the same, but for individual scripts, I think we should just go our own way. -gordon msg48461/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
[ cc'd some more people on this ] On Mon, Dec 09, 2002 at 11:23:58AM -0200, Daniel C. Sobral wrote: > I suggest that routed be specified as being BEFORE ntpd. In the absence > of a route to the specified servers, ntpd has the annoying behavior of > chosing the address of lo0 as the source address for ntp requests, > resulting in all sorts of problems. Yeah, makes sense. It also worked like that (correctly, that is) in rc.network. > > I do see one contraindication to this behavior. Most routing protocols > also react badly to time changes. Egg and chicken problem, but, > personally, and running OSPF, which is one of those protocols that react > badly to time changes, I find it preferably to run the router first. > After all, having ntpd using 127.0.0.1 as source is useless to me. The following patch should solve your problem. However, it's only a partial solution. It fixes the case for ntpd and ntpdate but not for other network daemons like rpcbind, which still get started _before_ the routing daemons. I haven't included patches for those because sorting out the dependencies is going to be a bit more involved. I'll have it done when I get a chance later this week. (A consequence of this is going to be that we will be moving *away* from NetBSD in the dependency ordering, but we can sort that out with them later). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 Index: etc/rc.d/ntpd === RCS file: /home/ncvs/src/etc/rc.d/ntpd,v retrieving revision 1.5 diff -u -r1.5 ntpd --- etc/rc.d/ntpd 2002/10/12 10:31:31 1.5 +++ etc/rc.d/ntpd 2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: ntpd -# REQUIRE: DAEMON +# REQUIRE: DAEMON routed route6d mrouted mroute6d ntpdate # BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD Index: etc/rc.d/ntpdate === RCS file: /home/ncvs/src/etc/rc.d/ntpdate,v retrieving revision 1.4 diff -u -r1.4 ntpdate --- etc/rc.d/ntpdate2002/10/12 10:31:31 1.4 +++ etc/rc.d/ntpdate2002/12/10 02:09:05 @@ -5,7 +5,8 @@ # # PROVIDE: ntpdate -# REQUIRE: NETWORKING syslogd +# REQUIRE: DAEMON routed route6d mrouted mroute6d +# BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/rpcbind === RCS file: /home/ncvs/src/etc/rc.d/rpcbind,v retrieving revision 1.6 diff -u -r1.6 rpcbind --- etc/rc.d/rpcbind2002/09/06 16:18:05 1.6 +++ etc/rc.d/rpcbind2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: rpcbind -# REQUIRE: NETWORKING ntpdate syslogd named ppp +# REQUIRE: NETWORKING syslogd named ppp # KEYWORD: FreeBSD NetBSD . /etc/rc.subr msg48443/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
At 11:23 AM -0200 2002/12/09, Daniel C. Sobral wrote: I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. IIRC, ntpd should not cause large-scale changes to the time that might wreak havoc with your router. It should only be making changes in the rate at which the clock ticks, so as to speed it up or slow it down, to the point where you are more or less in sync with your reference(s). It would be ntpdate that would be the potentially dangerous one making large-scale changes to your system time. Therefore, you definitely want the router stuff before the ntpd stuff. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RC NG, ntp and routed
I suggest that routed be specified as being BEFORE ntpd. In the absence of a route to the specified servers, ntpd has the annoying behavior of chosing the address of lo0 as the source address for ntp requests, resulting in all sorts of problems. This wouldn't happen in configurations with defaultrouter, but for those depending on dynamic routing... Of course, most dynamic routing protocols require a certain time before it goes to a stable state and install the externally received routes, but _that_ I solved with a sleep in the zebractl script (zebra being the router I use). I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. After all, having ntpd using 127.0.0.1 as source is useless to me. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
