no-net and auto location definition

I'm trying to define two locations, no-net location and
automatic location.
This is a follow-up write-up based on Alan's specification
of location:
http://opensolaris.org/os/project/nwam/p1spec/Locatio
n_Spec

No-net location will be used when network is not available.
Automatic location will be used as a default location when
we want to
automatically configure network.

I listed my definition of these two locations as below:

==============================
NO-NET Location:

I think that if we failed to configure any IP address, we
should call it
'no-net':
activation: contingent
contingency: "if IP=="

Since we don't have any network, there is no way to do
automatic
discovery, and 'file' is the only database we can use:
nameservice_discover: false
nameservices: file
nameservice_config_file: ""
dns_nameservice_servers: ""
dns_nameservice_domain: ""
dns_nameservice_search: ""
nis_nameservice_servers: ""
nis_nameservice_domain: ""
nisplus_nameservice_servers: ""
nisplus_nameservice_domain: ""
ldap_nameservice_servers: ""
ldap_nameservice_domain: ""

I think 'solaris' is just the default name. User can rename
it.
BTW, 'solaris' is the default hostname of Indiana:
nodename: solaris
nfsv4domain: ""

I'd like to disable ipfilter/ipnat by default. User can
change it:
ipfilter_config_file: ""
ipnat_config_file: ""
enable_ipfilter: false
enable_ipnat: false

I think below properties need to be added/modified by user
explicitly
static_routes: ""
ike_config_file: ""
ipseckey_config_file: ""
ipsecpolicy_config_file: ""
enable_svcs: ""
disable_svcs: ""



==============================
Automatic Location:

I think this location can be our default location. So, maybe
we need a
'default' value for 'activation' property, which means that
when no
location is matching current situation, we use Automatic
Location:
activation: default
contingency: ""

We want to use automatic discovery:
nameservice_discover: true
nameservices: ""
nameservice_config_file: ""
dns_nameservice_servers: ""
dns_nameservice_domain: ""
dns_nameservice_search: ""
nis_nameservice_servers: ""
nis_nameservice_domain: ""
nisplus_nameservice_servers: ""
nisplus_nameservice_domain: ""
ldap_nameservice_servers: ""
ldap_nameservice_domain: ""

We should use info from dhcp:
nodename: ""
nfsv4domain: ""


I'd like to disable ipfilter/ipnat by default. User can
change it:
ipfilter_config_file: ""
ipnat_config_file: ""
enable_ipfilter: false
enable_ipnat: false

I think below properties need to be added/modified by user
explicitly
static_routes: ""
ike_config_file: ""
ipseckey_config_file: ""
ipsecpolicy_config_file: ""
enable_svcs: ""
disable_svcs: ""

Besides these locations, during cold start of nwamd, we want
to save
current configuration, say the current nsswitch.conf file,
into a
specific directory. When nwamd is shutting down, these
saved
configuration will be restored.

These two location configuration file can be modified by
user. We should
generate
a copy of them when they are modified for the first time.
So, we will be
able to
restore our default value for no-net and automatic location
when
requested by user.

There are two major open questions in this write-up:

1) Whether we should provide a default list for
enable_svcs/disable_svcs
in no-net location?
Renee pointed me to section 5.4.4 in NWAM design doc
(htt
p://www.opensolaris.org/os/project/nwam/design), where a
bunch of
smf instances are listed. The question here is should we put
them into
'enable_svcs' and 'disable_svcs' as default list?

To some extend, it makes sense to add them. For example, we
probably
want to enable network/smtp:sendmail in local-only mode in
no-net
location. But, to me, that default list create a huge burden
of
maintenance. The reason is that those svcs are out of NWAM's
control.
So, whenever they are changed, we have to make sure our
default list is
correct all the time. And it seems to me that if we keep the
default
list as an empty list, nothing will go wrong. So, maybe it's
better for
us to leave the default list empty. And user can add their
own svcs list
as they see fit. Any idea?

2) Whether we should include nodename as a property in our
location profile?
The reason we want to include nodename as a property in
location profile
is that we think it is part of networking configuration.
But, if we
allow the nodename to be an property of a location, we need
to be able
to change the nodename on the fly, which seems to be a
problem. The team
has done some investigation about changing nodename on the
fly, but only
found that it is very hard to do it cleanly for now...Any
idea?

Thanks,
Max
_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss

In my last broadcast of no-net and automatic location
definitions, I 
added a section about default location file as below. It
seems this 
section gets buried in other stuff and failed to get enough
attention. 
So, I'm replying my email and trying to highlight it.
> These two location configuration file can be modified
by user. We should
> generate
> a copy of them when they are modified for the first
time. So, we will be
> able to
> restore our default value for no-net and automatic
location when
> requested by user.
>   
This will request our API/UI to provide such mechanism for
user to be 
able to revert to default location file, if they ever change
them.
> There are two major open questions in this write-up:
>
> 1) Whether we should provide a default list for
enable_svcs/disable_svcs
> in no-net location?
> Renee pointed me to section 5.4.4 in NWAM design doc
> (htt
p://www.opensolaris.org/os/project/nwam/design), where a
bunch of
> smf instances are listed. The question here is should
we put them into
> 'enable_svcs' and 'disable_svcs' as default list?
>
> To some extend, it makes sense to add them. For
example, we probably
> want to enable network/smtp:sendmail in local-only mode
in no-net
> location. But, to me, that default list create a huge
burden of
> maintenance. The reason is that those svcs are out of
NWAM's control.
> So, whenever they are changed, we have to make sure our
default list is
> correct all the time. And it seems to me that if we
keep the default
> list as an empty list, nothing will go wrong. So, maybe
it's better for
> us to leave the default list empty. And user can add
their own svcs list
> as they see fit. Any idea?
>   
Per our discussion in the meeting, we will not provide
default list
for these two properties.
> 2) Whether we should include nodename as a property in
our location profile?
> The reason we want to include nodename as a property in
location profile
> is that we think it is part of networking
configuration. But, if we
> allow the nodename to be an property of a location, we
need to be able
> to change the nodename on the fly, which seems to be a
problem. The team
> has done some investigation about changing nodename on
the fly, but only
> found that it is very hard to do it cleanly for
now...Any idea?
>   
We will not include nodename in our location profile,
either.

But, we will specify a hosts file in each location profile.
And there
will be a default hosts file for both no-net and automatic
location.

Anyway, I've updated our location page to add my write-up:
http://www.opensolaris.org/os/project/nwam/p1spec
/Location_Spec

Thanks,
Max
> Thanks,
> Max
> _______________________________________________
> nwam-discuss mailing list
> nwam-discussopensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss
>   
_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss

Max Zhen wrote:
> 1) Whether we should provide a default list for
enable_svcs/disable_svcs
> in no-net location?
> Renee pointed me to section 5.4.4 in NWAM design doc
> (htt
p://www.opensolaris.org/os/project/nwam/design), where a
bunch of
> smf instances are listed. The question here is should
we put them into
> 'enable_svcs' and 'disable_svcs' as default list?
>
> To some extend, it makes sense to add them. For
example, we probably
> want to enable network/smtp:sendmail in local-only mode
in no-net
> location. But, to me, that default list create a huge
burden of
> maintenance. The reason is that those svcs are out of
NWAM's control.
> So, whenever they are changed, we have to make sure our
default list is
> correct all the time. And it seems to me that if we
keep the default
> list as an empty list, nothing will go wrong. So, maybe
it's better for
> us to leave the default list empty. And user can add
their own svcs list
> as they see fit. Any idea?
>
>   
One question we discussed a bit yesterday was how we'd
express
which services could possibly be on the enable/disable
lists - I think we'd like to restrict things somewhat (for
example
we don't want any of the crucial transient services that
run during boot being disabled, or nwamd itself). And we'd
probably like to make this extensible too of course as
new services are provided. Perhaps the services (and their
states) in the various profiles under /var/svc/profile may
provide a rough guide for an initial list? (i.e.
generic_limited_net.xml
etc)

Alan
_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss

Alan Maguire wrote:
> Max Zhen wrote:
>> 1) Whether we should provide a default list for
enable_svcs/disable_svcs
>> in no-net location?
>> Renee pointed me to section 5.4.4 in NWAM design
doc
>> (htt
p://www.opensolaris.org/os/project/nwam/design), where a
bunch of
>> smf instances are listed. The question here is
should we put them into
>> 'enable_svcs' and 'disable_svcs' as default list?
>>
>> To some extend, it makes sense to add them. For
example, we probably
>> want to enable network/smtp:sendmail in local-only
mode in no-net
>> location. But, to me, that default list create a
huge burden of
>> maintenance. The reason is that those svcs are out
of NWAM's control.
>> So, whenever they are changed, we have to make sure
our default list is
>> correct all the time. And it seems to me that if we
keep the default
>> list as an empty list, nothing will go wrong. So,
maybe it's better for
>> us to leave the default list empty. And user can
add their own svcs list
>> as they see fit. Any idea?
>>
>>   
> One question we discussed a bit yesterday was how we'd
express
> which services could possibly be on the enable/disable
> lists - I think we'd like to restrict things somewhat
(for example
> we don't want any of the crucial transient services
that
> run during boot being disabled, or nwamd itself). And
we'd
> probably like to make this extensible too of course as
> new services are provided. Perhaps the services (and
their
> states) in the various profiles under /var/svc/profile
may
> provide a rough guide for an initial list? (i.e.
generic_limited_net.xml
> etc)
Hmm...I think the restrictions is enforced by RBAC. We only
give 
"Network Management" profile to nwamd, so it is
not possible for nwamd 
to disable/enable arbitrary smf instances.

Max
>
> Alan
_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss