On Fri, 06 Jul 2007 02:49:29 +0100
Mike Ramchand <Mike.Ramchand at Sun.COM> wrote:
> Peter Memishian wrote:
> > > > * It seems that inetmenu is still being maintained, and still
> > uses
> > > > wificonfig internally. I've CC'd Mike Ramchand (who I believe
> > > > is the primary author) in the hopes that he can clue us in on
> > > > the future of inetmenu now that NWAM phase 0 has integrated.
> > >
> > > Inetmenu being very lightly maintained. (i.e. bugfixes only).
> > > Unfortunately nwam Phase 0 does not yet cover some of the scenarios that
> > > the inetmenu users often require.
> >
> > I see. Out of curiosity, what are some of those?
>
> OTOH
>
> 1: The option to configure multiple interfaces.
This seems like the big one. Once we support this in phase 1 then many
of the other things come along as necessary.
> 2: The option to configure the IP address manually.
You do this in Phase 0. See the PROFILES section in nwamd(1M). This
mechanism isn't the end all for this type of thing so while it might
meet some of your needs its also not as feature rich as we want.
> 3: The option to NOT use NIS even if it is available. (Doesn't everyone
> hate a root directory full of stubs created by NIS +auto_master map?,
> not to mention the fact that based on the default nsswitch.nis file,
> anyone can ssh into your laptop)
Not sure if I understand this one. Is there a situation in which you
it in your nsswitch.conf and you've enabled nis/client but then don't
want to use it?
> 4: The ability to configure multiple "profiles" to select from.
> 5: The ability to define start/stop user supplied scripts to the
> profiles. e.g. I could have a "build-subnet" profile which configures a
> static IP address, and then starts my dhcp server.
See nwamd(1M) as above.
> 6: The ability to automatically select one or more profiles on startup.
Not sure if what you want is covered above?
> 7: The ability to use inetmenu either as a GUI, or CLI with identical
> functionality.
We really have 3 things planned for Phase 1.
1) cli, this is for profile creation not for active control
2) panel applet which gives you blinky lights, status, etc.
3) GUI configuration application which is analogous to 1 but more
interactive (shows you current state, etc.)
Documentation for all of this stuff is on the NWAM project page and
talked about on the discussion list. It would be great to get your
input to make sure we cover needs you have.
> 8: Updating the /etc/hosts file when configuring IP on interfaces.
nwamd(1M)...
> 9: providing full configuration information when connected: name, IP,
> default router, DNS domain, NIS domain etc. not just an IP address.
> 10: When configuring NIS, to add the ypserver to the /etc/hosts file.
> (required when NIS server is not on same subnet and you can't broadcast)
You could do these with nwamd(1M) but this is one place where more
automation is needed and will be done in Phase 1.
>
> If I've missed some NWAM functionality, let me know.
>
> At the moment, in the simplest case, because I've got dhcp running at
> home, and dhcp on SWAN (obviously), NWAM works fine with me taking my
> laptop between work and home.
>
> The instant, however, I'm on a customer site, which may or may not have
> dhcp, or a build network, where I need to configure static, and
> potentially be connected to more than one network, (wireless for e-mail,
> gig-ether to jumpstart some boxes), NWAM kind of falls down for me, and
> a fair number of field based engineers who spend large amounts of time
> using their laptop as a build server at customer sites.
Yes I can see some of this esp. the multiple network pains.
>
> (Other minor niggle, which might be my fault because I've got a dodgy
> cheap switch, is that when my link bounces up and down, so does nwam,
> and I end up being offered wireless connections, and then when my link
> comes back up, if I'm unlucky, I get a new IP address, and all my
> sessions (e.g. ssh) die.)
So this is a difference between user driven mechanisms like inetmenu
and NWAM that I don't think we've spent enough time modeling. You
should be able to tell us that is the case at the least and we should
be able to guess the case and adjust if we are really doing our job.
>
> The downside of inetmenu of course, is that it's just a big korn shell
> script of badly written inefficient code and it uses zenity as the GUI,
> which although really cool, is slightly limited in the types of user
> interaction it supports..., and at the time it was written, the
> underlying support within Solaris to detect events such as link up/down
> was not available, hence, it's not automagic. (Personally, that doesn't
> really bother me, because I like having to make a conscious decision to
> connect to a network, but I fully understand the requirements of a large
> number of users to simply plug and play.)
[...]
mph
