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

[Garrett D'Amore]

Paul Wernau wrote:
>
>
> Darren Reed wrote:
>> Peter Memishian wrote:
>>> ...
>>>   Using IP addresses directly is useful in a highly automated 
>>> environment,
>>>   such as punchin, inetmenu, etc, where the entries are transient and
>>>   subject to change and modifying the hosts file directly is 
>>> error-prone
>>>   and as a shared file is subject to user modifications.
>>>   
>>
>> Given the target use of the change proposed by this case,
>> has thought been given to allowing ypinit to be invoked in
>> a manner that doesn't require any prompting?
>>
>> For example:
>>
>> ypinit -C 192.12.18.1
>>
>> ...to initialise a client with 192.12.18.1 as its NIS server and
>> having ypinit behave in a manner more suited to being invoked
>> by something else rather than from the command line.
>
> Do others find this useful?  One could simply write to the file 
> directly.  It's listed in the ypinit man page under FILES, so I assume 
> this is fair game.  ypinit would offer some sort of sanity check, but 
> then we get into the CLI parsing game when trying to add more than one 
> address, etc.  If the ypservers file is considered an out in the open 
> interface, I say this is out of scope.  If not (which is not 
> realistic, IMO), then I'd consider it.
>
> I've heard others want to add -B for broadcast mode, etc.  There are a 
> lot of potential RFEs here and the ypinit shell script really needs a 
> good re-write, but I don't necessarily want this small enhancement to 
> spiral on as the testing and risk increase dramatically for a feature 
> that is hopefully starting its slow, painful death.

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.

But anyway, I think NIS is not likely to die anytime soon.  It is 
heavily entrenched in a lot of customer sites.  And until we can ship a 
reasonable LDAP server implementation, NIS will always have a niche.

(The problems with LDAP that prevent it from use on my networks are: 1) 
too hard to setup/configure server, 2) requirement that LDAP master be a 
dedicated machine... i.e. LDAP master cannot also be its own LDAP 
client).  The other problem I've heard with our LDAP implementation is 
that it doesn't support full auditing on the server side.  While NIS 
does this neither, I understand that its a significant shortcoming.)

    -- Garrett