pass flag from server to client to script

[Carl Karsten]

Simon Hobson wrote:
> Carl Karsten wrote:
>> I am trying to figure out how a script can detect if a laptop is on 
>> 'my' network or somewhere else.
>>
>> The plan is to un/mount nfs mounts, flip proxy settings, apt-get 
>> upgrade, maybe even sync some data.
>>
>> The trick is figuring out when the laptop has transitioned from 'out there' to
>> 'in here.'
>>
>> The hope is to set something in dhcpd.conf like 
>> network-id='garblygookUUID' that can be sent to the client that can 
>> somehow be tested for in the script.  I am guessing this is outside 
>> the dhcp spec, but may be a feature of ics's client.
> 
> I believe you can configure the client to ask for arbitrary options, 
> and you can certainly configure arbitrary user defined options in the 
> ISC server - so that's one route you could use. Would vendor options 
> be the best way to deal with this ?

This is what I am hoping for, but can't figure out how.


man dhclient

        dhclient [ -p port ] [ -d ] [ -e VAR=value ] [ -q ] [ -1 ] [ -r ] [ -lf
        lease-file ] [ -pf pid-file ] [ -cf config-file ] [ -sf script-file ] [
        -e  ENVVAR=value  ]  [ -s server ] [ -g relay ] [ -n ] [ -nw ] [ -w ] [
        if0 [ ...ifN ] ]

Is [-e VAR=value] in there a 2nd time in case I missed it the first time? :)

This looks like it:


dhclient-script(8)                                          dhclient-script(8)

NAME
        dhclient-script - DHCP client network configuration script

        On after defining the  make_resolv_conf  function,  the  client  script
        checks  for  the  presence  of an executable /etc/dhcp3/dhclient-enter-
        hooks script, and if present, it invokes the script inline,  using  the
        Bourne  shell  '.'  command.    The entire environment documented under
        OPERATION is available to this script,

OPERATION
        When dhclient needs to  invoke  the  client  configuration  script,  it
        defines  a  set  of  variables  in  the  environment,  and then invokes
        /sbin/dhclient-script.  In all cases, $reason is set to the name of the

BOUND
        The DHCP client has done an initial binding to a new address.   The new
        ip  address  is  passed  in  $new_ip_address, and the interface name is
        passed in $interface.   The media type  is  passed  in  $medium.    Any
        options  acquired  from  the  server  are  passed using the option name
        described in dhcp-options, except that dashes  ('-')  are  replaced  by
        underscores ('_') in order to make valid shell variables, and the vari-
        able names start with new_.   So for example, the new subnet mask would
        be passed in $new_subnet_mask.


Sounds promising.  I'll give it a whirl.

> 
> Alternatively, could you look at other properties of your network ? 
> Eg Does the MAC address of the router match yours ? Can you resolve a 
> fqdn that only exists internal to your network ? Is the domain name 
> 'internal.<mydomain>.com' ?

everything I can think of is too fragile - as in it will fall apart when I swap 
a nic, mess with the domain, etc.  was looking to something dedicated to this 
problem.

good chance of domain not being good because I am currently mis-using it: 
foo.personnelware.com resolves to different IP's depending on what DNS I hit. 
unless it is one of my public IP's.  bunch of crap hammered into the DNS, 
augmented with more DDNS stuff.  it basically deals with port forwarding to 
private IPs

Carl K