PSARC/2007/677 Allow ypinit -c to use IP addresses

[Paul Wernau]

> ypinit -B would be really, really useful to me, and probably others 
> besides.
> 
> Especially with NWAM, where I want to go back and forth into my NIS 
> environment, or into different NIS environments on SWAN, and then leave 
> these NIS environments when I go mobile.
> 

OK, but adding -B as an environment swapping interface seems like a 
crutch for shortcomings in NWAM and other applications that might want 
to control this.

... punchin, inetmenu, etc...

One of the exact reasons I wanted IP addresses instead of names is for 
applications like this.  It seems like what you're really describing is 
something I'd call ypswitch.

(Don't take this as well-thought out code, just an example of the scope 
I would expect to make the follow-on case worthwhile in the context 
you'd described).

pseudo-command:

ypswitch -D <domainname> <-b|-C [ip1[ip2,...]]|-d> [-t]

b is broadcast mode, -C lists one or more direct bindings, -d is disable 
back to DNS.  -t is for temporary.

The pseudo-code, possible after the original proposed case is...

--
  getopts()

  disable_flag?
	svcadm disable (-t) nis/client
	no temp flag?
		rm /etc/defaultdomain
	nsswitch stuff
	exit
	
  domainname $domain
  dom_dir=/var/yp/binding/`domainname`
  [ ! -d $dom_dir ] && mkdir -p $dom_dir

  broadcast_flag?
	[ -f $dom_dir/ypservers ] && rm -f $dom_dir/ypservers

  C_flag?
	validations...
	cat /dev/null > $dom_dir/ypservers
	for IP in ip list; do
		echo $IP >> $dom_dir/ypservers
	done

  nsswitch.conf wranglings here based on options...

  svcadm disable -s (-t) nis/client; svcadm enable -t nis/client

---

In fact, this really should be a part of a larger name service switcher 
interface for mobile users.  There's a lot of things to think about here 
related to customizations and profiles, etc.  So, broadcast or other 
non-interactive modes seem to fit into a better general purpose 
interface.  Very worthwhile, but out of scope, potentially.  I'd prefer 
to see this feature set and discussion be thought out in the context of 
NWAM, because that is where it is most useful and where name service 
configurations are a transient entity.

In fact, the purpose of this case is to allow back-end things like this 
to be able to do manipulation based on having enough information to do 
the job.  For example, you get some information from DHCP, which may 
include a NIS domain and/or a NIS server IP address.  Based on that, 
your eventhook file (or NWAM) can set up NIS as it wants to *in a very 
simple manner*.  Same for potentially mDNS custom records.

Anyway, I don't think your suggestion is a bad idea, but it should be 
one that is separated out (keeping in mind backporting and the like).  I 
might be able to be convinced otherwise or to open another case for the 
follow-up :)

Thanks,
Paul