From sacadmin Fri May 28 12:05:11 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 28 May 2004 15:04:45 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Mike Xu Subject: 2004/444 DHCP Event Scripting Content-Length: 4278 4 ... 4 ... 4 ... 4 I'm sponsoring the following fast-track request for Mike Xu. The timer is set to 06/04/2004. Summary and Problem Description The DHCP client program (dhcpagent daemon; PSARC 1999/040) implements a state machine. Customers may want to perform some actions when the state changes; for examples, fire up an application after lease request is honored and the specified interface is configured successfully, or perform cleanup before the interface is released from DHCP control. It can be done through event notification by invoking a customer- installed action program. The current dhcpagent implementation in Solaris does not provide such a mechanism. This RFE addresses the shortcoming. It provides basic functionality similar to that of the open source ISCDHCP implementation. Release Binding Patch/micro Event Names Events represent the state changes for the dhcpagent state machine. The following events are supported. For each event, the text below describes when the event occurs and when the event program is invoked. (1) BOUND This event occurs when dhcpagent receives the ACK reply from the DHCP server for the lease request of an address. The event program is invoked just after the interface is configured successfully. (2) EXTEND This event occurs when dhcpagent attempt to extend a lease. The event program is invoked just after dhcpagent receives the ACK reply from the DHCP server for the renew request. (3) EXPIRE This event occurs when a lease expires. The event program is invoked just before the leased address is removed from the interface and the interface is marked as "down". (4) DROP This event occurs when the interface is removed from DHCP control. The event program is invoked just before the interface is removed from DHCP control. (5) RELEASE This event occurs when the leased address is relinquished on the interface. The event program is invoked just before dhcpagent relinquish the address on the interface and sends the RELEASE packet to the DHCP server. Program Invocation Event programs can be any executable binary or script. Dhcpagent looks at the fixed location /etc/dhcp/eventhook to see whether the event program exists and is executable. The system doesn't provide a default event program. The file /etc/dhcp/eventhook should be owned by the root and its mode should be 755, but the daemon does not enforce this. Upon the event program invocation, the interface name and the event name are passed to the program as command line arguments (i.e. /etc/dhcp/eventhook interface-name event-name). The event program can use the dhcpinfo utility program to fetch more information about the interface. The event program is invoked on every event defined in this document. It can ignore those events in which it is not interested. Like dhcpagent, event programs run with root privileges. Program environments are inherited from dhcpagent. Stdin, stdout, and stderr are connected to /dev/null before invocation. Dhcpagent waits for the event program to exit on each event. To avoid being blocked forever in case the event program hangs, dhcpagent waits at most 60 seconds; the event program is forcefully terminated if it doesn't exit after 60 seconds. It first sends SIGTERM to the child and if it doesn't exit after another 3 seconds, it sends SIGKILL. Dhcpagent doesn't look at the program's exit status. It is generally agreed by the I-team that a tunable is not justified for the wait time. Interface Table Interface Stability Description ------------------- --------- ----------------------------------- /etc/dhcp/eventhook Evolving Customer-supplied script/program interface-name event Evolving Command line arguments to eventhook BOUND Evolving Event keyword passed to eventhook EXTEND Evolving Event keyword passed to eventhook EXPIRE Evolving Event keyword passed to eventhook DROP Evolving Event keyword passed to eventhook RELEASE Evolving Event keyword passed to eventhook From sacadmin Tue Jun 1 15:05:59 2004 Subject: Re: 2004/444 DHCP Event Scripting From: Darren J Moffat To: Mike Xu Cc: psarc@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Tue, 01 Jun 2004 15:05:29 -0700 Content-Transfer-Encoding: 7bit Content-Length: 1967 On Tue, 2004-06-01 at 13:01, Mike Xu wrote: > Interface Stability Description > ------------------- --------- ----------------------------------- > /etc/dhcp/eventhook Evolving Customer-supplied script/program Asking the customer to deliver an executable program into /etc/dhcp just feels "icky" to me, particularly since we generally encourage our own software not to do that but instead it would probably have been something like /usr/lib/dhcp/eventhook. When I saw this case I was expecting the name of the program to be specified in a variable in /etc/default/dhcpagent eg: # The full path to the program to run on dhcp # events. The interface name is the first argument, the second # argument is the dhcp event: BOUND|EXTEND|EXPIRE|DROP|RELEASE # EVENTHOOK_PROGRAM= With respect to privileges it is certainly true today that dhcpagent is running as uid=0 with all privileges but that need not be the case, infact I'm pretty sure it can run with considerably less privilege (probably just sys_net_config and run as uid=daemon). However, even with that it could still be that dhcpagent has an inheritable set of "all" privileges to pass on to the eventhook program. I believe the expected privileges and uid that the eventhook program can reasonably expect to depend on is an exported interface of this case. The alternative would be to say that the eventhook program is executed by dhcpagent via pfexec(1)[1] and the admin is responsible for creating an RBAC profile that gives the appropriate uid/privileges if any are needed and assigining that profile to the user that dhcpagent runs as. Can an eventhook program safely call dhcpinfo ? Can an eventhook program safely do something like this: ifconfig $1 dhcp status Are there any things related to network interfaces or DHCP that the eventhook program must not do ? [1] execl("pfexec", "/etc/dhcp/eventhook", interface, event, NULL); -- Darren J Moffat From sacadmin Wed Jun 2 10:49:57 2004 Date: Wed, 2 Jun 2004 10:49:26 -0700 (PDT) From: Mike Xu Subject: Re: 2004/444 DHCP Event Scripting To: Zhongren.Xu@eng.sun.com, Darren.Moffat@Sun.COM Cc: psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: btpN3GbMVNOSDKAKp4n0tg== Content-Length: 2260 Darren wrote, >> Interface Stability Description >> ------------------- --------- ----------------------------------- >> /etc/dhcp/eventhook Evolving Customer-supplied script/program > >Asking the customer to deliver an executable program into /etc/dhcp just >feels "icky" to me, particularly since we generally encourage our own >software not to do that but instead it would probably have been >something like /usr/lib/dhcp/eventhook. > >When I saw this case I was expecting the name of the program to be >specified in a variable in /etc/default/dhcpagent eg: > ># The full path to the program to run on dhcp ># events. The interface name is the first argument, the second ># argument is the dhcp event: BOUND|EXTEND|EXPIRE|DROP|RELEASE ># EVENTHOOK_PROGRAM= The project team generally believed that the event program does not justify to be a tunable. I tend to think that making it a tunable exposes security risks: configured to a file with the write permission by the world. >With respect to privileges it is certainly true today that dhcpagent is >running as uid=0 with all privileges but that need not be the case, >infact I'm pretty sure it can run with considerably less privilege >(probably just sys_net_config and run as uid=daemon). However, even with >that it could still be that dhcpagent has an inheritable set of "all" >privileges to pass on to the eventhook program. I believe the expected >privileges and uid that the eventhook program can reasonably expect to >depend on is an exported interface of this case. The alternative would >be to say that the eventhook program is executed by dhcpagent via >pfexec(1)[1] and the admin is responsible for creating an RBAC profile >that gives the appropriate uid/privileges if any are needed and >assigining that profile to the user that dhcpagent runs as. > >Can an eventhook program safely call dhcpinfo ? Yes, it can. When more information on the DHCP interface is needed, an eventhook program is very likely to call dhcpinfo. >Can an eventhook program safely do something like this: > ifconfig $1 dhcp status Yes, it can. >Are there any things related to network interfaces or DHCP that the >eventhook program must not do ? No. Thanks, Mike From sacadmin Wed Jun 2 11:06:13 2004 Date: Wed, 02 Jun 2004 14:02:47 -0400 From: James Falkner User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Xu CC: Darren.Moffat@sun.com, psarc@sun.com, Peter.Memishian@sun.com, Dave.Miner@sun.com Subject: Re: 2004/444 DHCP Event Scripting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 651 Mike Xu wrote: >>Are there any things related to network interfaces or DHCP that the >>eventhook program must not do ? > > > No. I would think that an eventhook script should not cause an infinite loop by running certain dhcp-related commands as part of an eventhook script.. right? Should they be documented if so? Do the eventhook calls get queued up in the event that an event occurs while an eventhook script is still executing? Or are they thrown away? For example, suppose a lease expires during the invocation of the eventhook for some other event. Does the EXPIRE eventhook get called once the first eventhook invocation exits? -jhf- From sacadmin Wed Jun 2 11:11:52 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 14:11:12 -0400 To: James Falkner Cc: Mike Xu , Darren.Moffat@Sun.COM, psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 462 > I would think that an eventhook script should not cause an infinite > loop by running certain dhcp-related commands as part of an eventhook > script.. right? Should they be documented if so? those commands will fail with something like: ifconfig: hme0: interface currently has a pending command (try later) this is the same behavior you'd see today if you did something silly like: # ifconfig hme0 dhcp extend & ifconfig hme0 dhcp extend -- meem From sacadmin Wed Jun 2 11:17:20 2004 Date: Wed, 02 Jun 2004 14:16:57 -0400 From: Dave Miner Subject: Re: 2004/444 DHCP Event Scripting To: Mike Xu , Darren.Moffat@Sun.COM Cc: psarc@Sun.COM, Peter.Memishian@Sun.COM MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) Content-Length: 1422 Mike Xu wrote: > Darren wrote, > >>>Interface Stability Description >>>------------------- --------- ----------------------------------- >>>/etc/dhcp/eventhook Evolving Customer-supplied script/program >> >>Asking the customer to deliver an executable program into /etc/dhcp just >>feels "icky" to me, particularly since we generally encourage our own >>software not to do that but instead it would probably have been >>something like /usr/lib/dhcp/eventhook. >> >>When I saw this case I was expecting the name of the program to be >>specified in a variable in /etc/default/dhcpagent eg: >> >># The full path to the program to run on dhcp >># events. The interface name is the first argument, the second >># argument is the dhcp event: BOUND|EXTEND|EXPIRE|DROP|RELEASE >># EVENTHOOK_PROGRAM= > > > The project team generally believed that the event program does not justify to > be a tunable. I tend to think that making it a tunable exposes security risks: > configured to a file with the write permission by the world. > We haven't been able to come up with a reason to make it tuneable, though if someone can offer a plausible one we could re-examine it. However, the location should be on /, so that the program is available at the times dhcpagent may encounter some of these events (which can precede the mounting of /usr). That's why it's under /etc/dhcp. Dave From sacadmin Wed Jun 2 11:30:19 2004 Subject: Re: 2004/444 DHCP Event Scripting From: Darren J Moffat To: Mike Xu Cc: psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 02 Jun 2004 11:29:38 -0700 Content-Transfer-Encoding: 7bit Content-Length: 1352 On Wed, 2004-06-02 at 10:49, Mike Xu wrote: > ariable in /etc/default/dhcpagent eg: > > > ># The full path to the program to run on dhcp > ># events. The interface name is the first argument, the second > ># argument is the dhcp event: BOUND|EXTEND|EXPIRE|DROP|RELEASE > ># EVENTHOOK_PROGRAM= > > The project team generally believed that the event program does not justify to > be a tunable. I tend to think that making it a tunable exposes security risks: > configured to a file with the write permission by the world. What? /etc/default/dhpcagent is certainly not world writable. I don't see how making the path to the executable a variable in a config file that dhcpagent already reads creates a security hole. Particularly since the original spec already said that dhcpagent doesn't care what the permissions of the file actually are. If you actually care about what the program that dhcpagent executes does, then dhcpagent MUST check the permissions of the file it is going to execute, but you said it doesn't do that. Equally importantly you haven't addressed my issue with respect to privileges. I still feel uncomfortable with us asking the customer to provide an excutable program under /etc rather than getting the customer to provide the path to that program in the config file that dhcpagent already reads. -- Darren J Moffat From sacadmin Wed Jun 2 11:39:47 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 14:39:16 -0400 From: James Carlson To: Darren J Moffat Cc: Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 1741 Darren J Moffat writes: > > The project team generally believed that the event program does not justify to > > be a tunable. I tend to think that making it a tunable exposes security risks: > > configured to a file with the write permission by the world. > > What? > > /etc/default/dhpcagent is certainly not world writable. > > I don't see how making the path to the executable a variable in a config > file that dhcpagent already reads creates a security hole. Agreed. That can't be the problem. > Particularly since the original spec already said that dhcpagent doesn't > care what the permissions of the file actually are. If you actually > care about what the program that dhcpagent executes does, then dhcpagent > MUST check the permissions of the file it is going to execute, but you > said it doesn't do that. Equally importantly you haven't addressed my > issue with respect to privileges. > > I still feel uncomfortable with us asking the customer to provide an > excutable program under /etc rather than getting the customer to provide > the path to that program in the config file that dhcpagent already > reads. What about asking the customer to put the script in a known location is making you uncomfortable? It's not as though it's an unknown practice, and it's not as though /etc/dhcp has less protection than the configuration file. And it's not as though the executable could be located anywhere but on the root filesystem (as it's used before /usr is mounted). So, what's the issue? -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 2 11:41:11 2004 Subject: Re: 2004/444 DHCP Event Scripting From: Darren J Moffat To: Dave Miner Cc: Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 02 Jun 2004 11:40:31 -0700 Content-Transfer-Encoding: 7bit Content-Length: 891 On Wed, 2004-06-02 at 11:16, Dave Miner wrote: > We haven't been able to come up with a reason to make it tuneable, > though if someone can offer a plausible one we could re-examine it. > However, the location should be on /, so that the program is available > at the times dhcpagent may encounter some of these events (which can > precede the mounting of /usr). That's why it's under /etc/dhcp. Given that requirement that it be in / I withdraw my objection to /etc/dhcp/eventhook being hardcoded. I still believe the issue of privileges and uid need that can be expected by the eventhook program needs to be addressed. Assuming that dhcpagent is running as uid=0 with all privileges isn't really acceptable since I believe it should really only need sys_net_config. The uid and privileges are part of the interface between dhcpagent and /etc/dhcp/eventhook. -- Darren J Moffat From sacadmin Wed Jun 2 11:44:05 2004 Subject: Re: 2004/444 DHCP Event Scripting From: Darren J Moffat To: James Carlson Cc: Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 02 Jun 2004 11:43:23 -0700 Content-Transfer-Encoding: 7bit Content-Length: 348 On Wed, 2004-06-02 at 11:39, James Carlson wrote: > So, what's the issue? I can't quite put my finger on it just felt "icky" since we already had an /etc/default/dhcpagent config file. I was missing that it needed to be part of / because of DHCP for diskless clients. Given that I think that part of the proposal is fine. -- Darren J Moffat From sacadmin Wed Jun 2 11:48:02 2004 To: James Carlson cc: Darren J Moffat , Mike Xu , psarc@sun.com, Peter.Memishian@sun.com, Dave.Miner@sun.com Subject: Re: 2004/444 DHCP Event Scripting Date: Wed, 02 Jun 2004 20:47:28 +0200 From: Casper Dik Content-Length: 400 An unrelated other question: since syseventd allows customers to execute commands when events are posted, why isn't that generic mechanism used? Are synchronous events required or is this because of use during but when only "/" is available? If the latter, shouldn't there be a future roadmap to allow events posted early in boot which would do away with this special case for dhcpagent? Casper From sacadmin Wed Jun 2 11:48:49 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 14:48:04 -0400 To: Darren J Moffat Cc: James Carlson , Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 303 > I can't quite put my finger on it just felt "icky" since we already had > an /etc/default/dhcpagent config file. even so, there are "default" default values used by the client in the case where the configuration file is absent or no default value has been provided by the administrator. -- meem From sacadmin Wed Jun 2 11:49:41 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 14:49:09 -0400 From: James Carlson To: Darren J Moffat Cc: Dave Miner , Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 1264 Darren J Moffat writes: > I still believe the issue of privileges and uid need that can be > expected by the eventhook program needs to be addressed. Assuming that > dhcpagent is running as uid=0 with all privileges isn't really > acceptable since I believe it should really only need sys_net_config. > The uid and privileges are part of the interface between dhcpagent and > /etc/dhcp/eventhook. How do you predict the list of privileges that will be required by a customer-supplied script? There's certainly no restriction on what it could do. A reasonable script may (for instance) tickle a batch file transfer mechanism (such as `sendmail') after getting a BOUND event. If that's needed anyway, then I think the fixed name might be helpful: RBAC could be used to specify the privileges granted to that one executable. (I still think the default ought to be "everything:" asking users to grok all of RBAC and LP just because they want to use a DHCP-invoked script that works on all other UNIX platforms seems a bit extreme to me.) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 2 11:50:53 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 14:50:12 -0400 To: Casper Dik Cc: James Carlson , Darren J Moffat , Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 524 > An unrelated other question: since syseventd allows customers to > execute commands when events are posted, why isn't that generic > mechanism used? Are synchronous events required or is this because > of use during but when only "/" is available? it's because of the need for synchronous events. we spent quite a while discussing the trade-offs and concluded that the asynchronous model provided by sysevents would lead to some messy edge conditions that would make it hard to write correct eventhooks. -- meem From sacadmin Wed Jun 2 11:56:02 2004 To: Peter Memishian cc: James Carlson , Darren J Moffat , Mike Xu , psarc@sun.com, Dave.Miner@sun.com Subject: Re: 2004/444 DHCP Event Scripting Date: Wed, 02 Jun 2004 20:55:28 +0200 From: Casper Dik Content-Length: 768 > > > An unrelated other question: since syseventd allows customers to > > execute commands when events are posted, why isn't that generic > > mechanism used? Are synchronous events required or is this because > > of use during but when only "/" is available? > >it's because of the need for synchronous events. we spent quite a while >discussing the trade-offs and concluded that the asynchronous model >provided by sysevents would lead to some messy edge conditions that would >make it hard to write correct eventhooks. Thanks; that answers my question. (Of course, the obvious followup question would be "Why can't syseventd do synchronous events" as in "two asynchronous events can make one synchronous event", but that is probably taking it too far) Casper From sacadmin Wed Jun 2 11:58:22 2004 Subject: Re: 2004/444 DHCP Event Scripting From: Darren J Moffat To: James Carlson Cc: Dave Miner , Mike Xu , psarc@Sun.COM, Peter.Memishian@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 02 Jun 2004 11:57:42 -0700 Content-Transfer-Encoding: 7bit Content-Length: 2096 On Wed, 2004-06-02 at 11:49, James Carlson wrote: > Darren J Moffat writes: > > I still believe the issue of privileges and uid need that can be > > expected by the eventhook program needs to be addressed. Assuming that > > dhcpagent is running as uid=0 with all privileges isn't really > > acceptable since I believe it should really only need sys_net_config. > > The uid and privileges are part of the interface between dhcpagent and > > /etc/dhcp/eventhook. > > How do you predict the list of privileges that will be required by a > customer-supplied script? There's certainly no restriction on what it > could do. A reasonable script may (for instance) tickle a batch file > transfer mechanism (such as `sendmail') after getting a BOUND event. Agreed this is a hard problem which is why I was asking for the uid and privileges to be explicitly listed as part of the interface. I'm okay with it being run as uid=0 with all of the privileges that dhcpagent inherited (and thus has in its inheritable set). What I was pointing out was that there (to me anyway) appeared to be an assumption that dhcpagent would be running as uid=0 with all privileges and thus so would eventhook, but that might not be the case in the future. > If that's needed anyway, then I think the fixed name might be helpful: > RBAC could be used to specify the privileges granted to that one > executable. (I still think the default ought to be "everything:" > asking users to grok all of RBAC and LP just because they want to use > a DHCP-invoked script that works on all other UNIX platforms seems a > bit extreme to me.) That would be nice to do but I don't think the project team needs to be burdened with that. All I'm asking for is that the uid and privileges (if that is uid=0 and privs=all) that the eventhook program will be run as be specified as part of the interface (and thus documented in the man page). So that when someone comes along later and changes dhcpagent to run with least privilege it is clear what the interface contract between it and the eventhook program is. -- Darren J Moffat From sacadmin Wed Jun 2 12:19:09 2004 Date: Wed, 2 Jun 2004 12:18:33 -0700 (PDT) From: Mike Xu Subject: Re: 2004/444 DHCP Event Scripting To: Zhongren.Xu@eng.sun.com, james.falkner@sun.com Cc: Darren.Moffat@sun.com, psarc@sun.com, Peter.Memishian@sun.com, Dave.Miner@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: K3Fvnlj53x9FdRq9Cq/kUA== Content-Length: 488 James wrote, >Do the eventhook calls get queued up in the event that an event occurs while >an eventhook script is still executing? Or are they thrown away? For example, >suppose a lease expires during the invocation of the eventhook for some >other event. Does the EXPIRE eventhook get called once the first eventhook >invocation exits? If an eventhook invocation is already on, events BOUND, DROP and RELEASE are ignored; and invocations for EXTEND and EXPIRE are queued up. Mike From sacadmin Wed Jun 2 12:34:43 2004 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave.Miner@sun.com, Darren Moffat , Mike Xu , Peter.Memishian@sun.com, James Carlson From: Allen Wittenauer Subject: Re: 2004/444 DHCP Event Scripting Date: Wed, 2 Jun 2004 12:34:21 -0700 To: psarc@sun.com Content-Length: 1833 On Jun 2, 2004, at 11:39 AM, James Carlson wrote: > What about asking the customer to put the script in a known location > is making you uncomfortable? It's not as though it's an unknown > practice, and it's not as though /etc/dhcp has less protection than > the configuration file. And it's not as though the executable could > be located anywhere but on the root filesystem (as it's used before > /usr is mounted). > > So, what's the issue? From what I've read and followed on the case thus far (admittedly quite loosely), it would be extremely handy to specify this location, and hopefully on a per-interface basis. Why, you ask? Well, we've been toying with the idea of using DHCP to configure already running machines. We'd do this by plumbing a secondary interface[1] and tying DHCP to it. We'd then use dhcpinfo to grab our other data (LDAP bind DN, Kerberos realm information, DNS bits, etc). Using a DHCP event to trigger the re-configuration would be pretty handy. Every time the lease expires, we could re-query and potentially re-configure the requested bits, depending upon how 'safe' it is to do on a running machine. Being able to specify someplace non-/ would mean that we'd be able to list some location like /usr/dist to hold the control script. In turn, this would allow us to update the control script without having to touch individual hosts. [Otherwise, the obvious workaround is to use a symlink, but that seems like a bit of a kludge.] I certainly understand that for diskless hosts the need for the script to be on root. But DHCP isn't used only in that situation. Please, let us look outside the 'obvious' implementations here. [1] - Sidenote: it is really too bad that we can't tie DHCP to logical hosts. Then we could use this concept for non-multi-NIC'ed machines. From sacadmin Wed Jun 2 12:41:51 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 15:41:09 -0400 To: Allen Wittenauer Cc: psarc@sun.com, Dave.Miner@sun.com, Darren Moffat , Mike Xu , Peter.Memishian@sun.com, James Carlson Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 441 > From what I've read and followed on the case thus far (admittedly > quite loosely), it would be extremely handy to specify this location, > and hopefully on a per-interface basis. Why, you ask? you can always do this yourself by having /etc/dhcp/eventhook be a simple wrapper that invokes your own per-interface eventhooks, using interface name passed into eventhook. the idea was to keep things as simple as possible. -- meem From sacadmin Wed Jun 2 12:50:48 2004 Date: Wed, 02 Jun 2004 15:47:22 -0400 From: James Falkner User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Xu CC: Darren.Moffat@sun.com, psarc@sun.com, Peter.Memishian@sun.com, Dave.Miner@sun.com Subject: Re: 2004/444 DHCP Event Scripting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 896 Mike Xu wrote: > James wrote, > >>Do the eventhook calls get queued up in the event that an event occurs while >>an eventhook script is still executing? Or are they thrown away? For example, >>suppose a lease expires during the invocation of the eventhook for some >>other event. Does the EXPIRE eventhook get called once the first eventhook >>invocation exits? > > > If an eventhook invocation is already on, events BOUND, DROP and RELEASE are > ignored; and invocations for EXTEND and EXPIRE are queued up. Ok, so what's the rationale for ignoring them? I might have a fancy cleanup script for the DROP event, but it might not get triggered if it happens during some other event. You've obviously thought this through already so I'd just like to see the behavior documented so that script authors aren't surprised when their eventhook script does't get triggered in these cases. -jhf- From sacadmin Wed Jun 2 12:54:33 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2004 15:53:52 -0400 To: James Falkner Cc: Mike Xu , Darren.Moffat@Sun.COM, psarc@Sun.COM, Peter.Memishian@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 374 > Ok, so what's the rationale for ignoring them? I might > have a fancy cleanup script for the DROP event, but it might not > get triggered if it happens during some other event. the event really isn't "ignored" -- it's just that these events cannot occur while you're processing another event, and any attempt to trigger them (e.g., via ifconfig) will fail. -- meem From sacadmin Wed Jun 2 14:09:18 2004 From: Bill Sommerfeld To: James Carlson cc: psarc@sac.sfbay.sun.com, Mike Xu Subject: Re: 2004/444 DHCP Event Scripting Date: Wed, 02 Jun 2004 17:08:49 -0400 Content-Length: 1763 [disclaimer: in a past job, I rebuilt the state machine of a DHCP client. I therefore know far too much about the DHCP protocol though relatively little about the guts of the solaris implementation....] 1) I'd like to see a spec clarification that we may add additional events beyond the five specified here at any time; eventhook scripts should be prepared to treat any unrecognized events as NOOP's. (in particular, it's generally best to enable packet filters and the like *before* opening the door, so in the future we might want to add additional events: 1) after the ACK is received but before an interface is configured with the new address, and 2) after an address is removed from the interface...) 2) I'm assuming that "EXTEND" applies to any lease refresh event, whether triggered by expiration of the renew timer, the rebind timer, or a manual kick of the client; and I'm presuming that intent of this hook is to pick up changes to any of the auxiliary dhcp options. ("REFRESH" might be a better name -- sometimes dhcp servers can respond to a lease renewal request with a lease which isn't any longer than the original..) 3) DHCPINFORM: do we ever generate it? If we were to generate it, would the hook script get invoked with an EXTEND when we get the DHCPACK back from the server? 3a) likewise for DHCPFORCERENEW (RFC3203): if we implement that in the future, i'm presuming it would trigger an EXTEND callback on a successful renew.. 4) I'm a little unclear on the need for distinct EXPIRE, DROP, and RELEASE hooks. A state diagram of what the scripts should expect to see in what order would be helpful. (heroic ascii art like what you see in rfc2131 section 4.4 not needed). - Bill From sacadmin Wed Jun 2 14:55:06 2004 Date: Wed, 2 Jun 2004 14:54:37 -0700 (PDT) From: Mike Xu Subject: Re: 2004/444 DHCP Event Scripting To: James.D.Carlson@sun.com, sommerfeld@east.sun.com Cc: psarc@sac.sfbay.sun.com, Zhongren.Xu@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: P1n+Wa6dAySqrsl4h+hkMQ== Content-Length: 2372 >From: Bill Sommerfeld >To: James Carlson >cc: psarc@sac.sfbay.sun.com, Mike Xu >Subject: Re: 2004/444 DHCP Event Scripting >Date: Wed, 02 Jun 2004 17:08:49 -0400 > >[disclaimer: in a past job, I rebuilt the state machine of a DHCP >client. I therefore know far too much about the DHCP protocol though >relatively little about the guts of the solaris implementation....] > >1) I'd like to see a spec clarification that we may add additional events > beyond the five specified here at any time; eventhook scripts > should be prepared to treat any unrecognized events as NOOP's. Ok. >(in particular, it's generally best to enable packet filters and the >like *before* opening the door, so in the future we might want to add >additional events: 1) after the ACK is received but before an >interface is configured with the new address, and 2) after an address >is removed from the interface...) > >2) I'm assuming that "EXTEND" applies to any lease refresh event, > whether triggered by expiration of the renew timer, the rebind timer, > or a manual kick of the client That's right. > and I'm presuming that intent of this > hook is to pick up changes to any of the auxiliary dhcp options. > ("REFRESH" might be a better name -- sometimes dhcp servers can > respond to a lease renewal request with a lease which isn't any > longer than the original..) I believe EXTEND is a more generic name. It is the state machine's state name in our dhcpagent implementation. But I am open to the name change if it is generally believed to be more suitable. >3) DHCPINFORM: do we ever generate it? If we were to generate it, > would the hook script get invoked with an EXTEND when we get the DHCPACK > back from the server? Yes. >3a) likewise for DHCPFORCERENEW (RFC3203): if we implement that in > the future, i'm presuming it would trigger an EXTEND callback on a > successful renew.. Yes. (it is not currently implemented). >4) I'm a little unclear on the need for distinct EXPIRE, DROP, and > RELEASE hooks. A state diagram of what the scripts should expect > to see in what order would be helpful. (heroic ascii art like > what you see in rfc2131 section 4.4 not needed). Events DROP and RELEASE are triggered by user actions while EXPIRE is not. Mike From sacadmin Thu Jun 3 11:52:34 2004 From: Bill Sommerfeld To: Peter Memishian cc: James Falkner , Mike Xu , Darren.Moffat@sun.com, psarc@sun.com, Dave.Miner@sun.com Subject: Re: 2004/444 DHCP Event Scripting Date: Thu, 03 Jun 2004 14:52:02 -0400 Content-Length: 498 > > Ok, so what's the rationale for ignoring them? I might > > have a fancy cleanup script for the DROP event, but it might not > > get triggered if it happens during some other event. > > the event really isn't "ignored" -- it's just that these events cannot > occur while you're processing another event, and any attempt to trigger > them (e.g., via ifconfig) will fail. what's the user experience for that? ifconfig command hangs until the timeout then prints error message? - Bill From sacadmin Thu Jun 3 12:28:32 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Jun 2004 15:27:49 -0400 To: sommerfeld@east.sun.com Cc: Peter Memishian , James Falkner , Mike Xu , Darren.Moffat@Sun.COM, psarc@Sun.COM, Dave.Miner@Sun.COM Subject: Re: 2004/444 DHCP Event Scripting Content-Length: 231 > what's the user experience for that? ifconfig command hangs until the > timeout then prints error message? ifconfig fails, stating that a dhcp operation is already in progress on the interface (like it always has). -- meem From sacadmin Thu Jun 3 14:54:34 2004 From: Bill Sommerfeld To: Mike Xu cc: James.D.Carlson@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2004/444 DHCP Event Scripting Date: Thu, 03 Jun 2004 17:54:02 -0400 Content-Length: 973 > >4) I'm a little unclear on the need for distinct EXPIRE, DROP, and > > RELEASE hooks. A state diagram of what the scripts should expect > > to see in what order would be helpful. (heroic ascii art like > > what you see in rfc2131 section 4.4 not needed). > > Events DROP and RELEASE are triggered by user actions while EXPIRE > >is not. since you didn't give me a state transition, i'm guessing what the event hook script should see over time: For any given interface, the hook script should see cycles consisting of: exactly one BOUND zero or more EXTENDs exactly one of either DROP, EXPIRE, or RELEASE in other words: The script will not see an EXTEND unless the previous event was either BOUND or a previous EXTEND The script will only see BOUND after another event since boot if the previous event was DROP, EXPIRE, or RELEASE The script will not see more than one of DROP, EXPIRE, or RELEASE for each BOUND. did I get that right? - Bill From sacadmin Thu Jun 3 15:31:12 2004 Date: Thu, 3 Jun 2004 15:30:42 -0700 (PDT) From: Mike Xu Subject: Re: 2004/444 DHCP Event Scripting To: Zhongren.Xu@eng.sun.com, sommerfeld@east.sun.com Cc: James.D.Carlson@Sun.COM, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dGO7DMjUCVajm0xBT92rUA== Content-Length: 732 Bill wrote, >since you didn't give me a state transition, i'm guessing what the >event hook script should see over time: > >For any given interface, the hook script should see cycles consisting of: > > exactly one BOUND > zero or more EXTENDs > exactly one of either DROP, EXPIRE, or RELEASE > >in other words: > >The script will not see an EXTEND unless the previous event was either >BOUND or a previous EXTEND > >The script will only see BOUND after another event since boot if the >previous event was DROP, EXPIRE, or RELEASE > >The script will not see more than one of DROP, EXPIRE, or RELEASE for >each BOUND. > >did I get that right? I don't have a state transition diagram for you. But your description is correct. Mike From sacadmin Wed Jun 9 13:39:44 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 9 Jun 2004 16:39:08 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Mike Xu Subject: 2004/444 DHCP Event Scripting Content-Length: 412 This case was approved during ARC business at today's meeting. An updated version of the final specification (extracted from the mail file) is included in the case directory as spec.txt. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677