Saturday June 09, 2007
Network Auto Magic Preview
Recently I wrote about an exciting new project coming to Solaris by way of the Network Auto-Magic project. I also talked about releasing a sneak peek at the promise of the Network Auto-Magic project in an upcoming OpenSolaris release. Today I am going to discuss where we are with getting this functionality into your hands.
But before we talk about releases and dates, I would like to step back a little and discuss the rationale behind the Network Auto-Magic project and the various enhancements it brings both to sysadmins as well as the so-called "end users".
The Network Auto Magic project consists of three main components. One of these is around simplifying service configuration and discovery on a network. The second is adding Network Profiles support. And the third and major component is developing a comprehensive UI to configure, automate and manage Solaris networking configuration. Let's consider each one of these is further detail.
The service discovery aspect will be implemented by enhancing the framework from Apple's Bonjour technology. One of the strengths of this technology is that it is built on top of one of the most robust and well understood internet protocols- DNS. Specifically, the technology allows applications to discover advertised services on a network. The project will deliver a public library which can be used by developers to make simple modifications to their application/service so that the services can participate in network service discovery. This reduces configuration- rather than an admin having to hard code a particular service with a certain device your application is now free to auto discover it. Eventually applications and clients can become smarter too- they can 'probe' the network on startup and unless they find a service on the network, there is no need for them to keep trying to reach a server. Like other network services delivered in Solaris, all of this functionality will be fully integrated with Service Management Facility (SMF). This component of will soon be released via an OpenSolaris build, so stay tuned!
Network
profiles, the primary component of the Network Auto-Magic project are one of the ways to simplify and automate network configuration and management. They work by allowing users to specify collections of various network properties and have them be managed automatically based on different network
environments. A Network Configuration Profile (NCP) will also include policy- such as which network interfaces to use, whether they should be activated
automatically, and so on. At any given time, exactly one NCP and one Environment are active. Users may modify the NCP to specify how Solaris should react in a particular network environment and have the right sets of actions automatically take place. For example, if you check email at your neighborhood Starbucks you may want your laptop to connect to the WiFi access
point with the correct security flavor automatically, start DHCP on it and enable DNS for host resolution. You want to turn off wired interfaces and
perhaps have the display appear scrambled
to anyone besides you! (We are still working on the latter. 
) Then when you go back to your office and connect to a wired connection, you might expect to shut down the WiFi interface, enable certain services (such as NFS file sharing or NIS for host resolution) and have your browser use the proxy servers defined via Gconf.
Finally, lets discuss the third component of the project- the comprehensive UI. The first thing long time users of Solaris would notice- when the entire project is delivered- is that we are not just delivering incremental ease of use by cleaning up redudant code or even replacing multiple layers of CLI with a "high-level" CLI. NWAM will do both of those but it certainly does not stop there. It also delivers a comprehensive GUI with the same look and feel as the Java Desktop System. We have published a Flash based prototype based on our UI specification. Its not functionally complete and some aspects are likely to change in the final version but it does give you an idea of what you might see. And thats not all- there will be also be a separate Status Notification GUI that will give you a quick snapshot of the current network status. For example, it will graphically display the signal strength of the selected WiFi network. Routine tasks such as enabling or disabling an interface (on multiple homed machines) no longer require invoking (or knowledge of) complex CLI such as ifconfig(1M) or dladm(1M).
Now, for the sneak peak! Starting with Solaris Express Developer Edition 5/07, you will be able to preview some of the Network Auto-Magic functionality. If you are installing Solaris on a supported laptop this sneak peek is for you. (Specifically, there is a limitation that only one link is active at a time.) The major new functionality supported with this release of Solaris Express Developer Edition is WiFi support and with Network Auto Magic it just works "out of the box". All flavors of WEP and WPA2 are supported for the first time. Obviously not all laptops are supported, but common WiFi chipset implementations such as Atheros and Intel Centrino are. Solaris Express Developer Edition Release 5/07 will be available around mid-June 2007. Let's explore how the NWAM preview works.
This release of Solaris Developer Express includes the 'NWAM daemon' which allows for automated network configuration on laptops and desktop machines. This daemon monitors an available Ethernet interface and automatically enables DHCP on it. If no interface is plugged into a wired network, the NWAM daemon conducts a wireless scan and queries the user for a WiFi access point to connect to via a popup GUI. Once you select a WiFi access point and connect to it successfully that choice will be saved in a file. The next time you are in the vicinity of that WiFi network, Solaris will connect to it without user intervention. For now, there is no profile support so you wouldn't be able to do the things I described in the Starbucks example above. Also, wired interfaces are preferred over wireless, although this is easily changed. For further details, please see the nwamd man page.
While we cannot talk about the schedule for when the rest of this functionality will be available we are currently working hard to ensure it meets with the expectations of the Solaris user community. We would love to hear your experience with the Network Auto Magic project and indeed all of new Solaris. It certainly isn't your grandfather's Solaris any more and with your input we hope to make it even easier to use.
( Jun 09 2007, 04:51:35 PM PDT ) Permalink
Wednesday March 28, 2007
A unique project in Solaris Networking Solaris Networking has always been known to be on the cutting edge of innovation- whether it is sterling performance, or next generation virtualization and resource control.. Clearly, one cannot build an imposing structure without a strong foundation and Solaris is no exception. Several engineering years of building high quality infrastructure is one reason why Sun is reclaiming its position in the workstation and server marketplace.
While having high quality plumbing is a prerequisite whether you are building a home or an operating system, many people these days like shiny fixtures to go along. And of course the solution needs to be elegant and easy to use. For many years, Sun customers have thought of Solaris Networking to be that way- very high quality and capable of heavy lifting but somewhat challenging to use.
Why is this important? For starters, an approachable Solaris will enable both developers and customers to use it more easily and help grow the community of Sun users. It will make Solaris a stronger contender for mobile platforms and for small and medium business customers. The latter often lack dedicated and advanced Unix configuration expertise. Finally, recent Linux distros and OS X have lifted the bar on configuration and management user interfaces and Solaris needs to do a better job competing in this area. At the same time, traditional data center customers need to lower TCO by reducing administration and management complexity.
After spending over a year working on design, we are in the process of implementing and delivering on the promise of significantly simplified and automated Solaris network configuration and management via an exciting new project that we call Network Auto Magic. Network Auto Magic or NWAM for short has a thriving community on OpenSolaris so join in and give us your feedback. Better yet, download the prototype and give it a spin! We are planning on releasing the prototype via OpenSolaris in the very near future so stay tuned. And there is much more to come. John Beck recently presented at the Bay Area OpenSolaris User Group meeting.
Tuesday May 31, 2005
BIND 9 DNS server meets SMF/Predictive Self Healing
Overview
If you have been reading about Solaris 10, chances are that you have already heard of a new feature, Predictive Self Healing or the Service Management Facility- SMF for short. There is lots of excellent information about this useful feature. You are assumed to be familiar with end user SMF concepts and CLI programs.
Since we integrated the Internet Systems Consortium's BIND 9 server in Solaris 10 and made it SMF aware, I have been asked several questions about how to configure it, what's changed from the " stock " BIND and what if anything is needed to run named, chroot. Some users also asked these same questions of ISC.
I should point out that Sun fully stands behind the Solaris integrated BIND code in the sense that we offer what we call " level one" support. This essentially means that if you think there'is a bug in the Solaris integrated BIND, you should let us know and we will investigate it and if applicable, fix it ourselves rather than pointing you to the " community " or an ISV. Sun works closely with ISC to address any issues that we find during or after integration. Sun is also an OEM level BIND Forum member.
The BIND version 9 server is new for Solaris 10. Previous versions of Solaris shipped with the BIND v8 server. The DNS client portion continues to be based on the well known BIND resolver, a defacto standard on Unix and Linux. The 03/2005 Release of Solaris 10 ships with the BIND 9.2.4 version. The server and tools ship in the same location as their BIND 8 counterparts- in /usr/sbin.
DNS Service Manifests and Upgrade to Solaris 10
Solaris 10 ships with two manifests for DNS service- a client manifest and a server manifest. The client manifest is located in /var/svc/manifest/network/dns/client.xml. The server manifest is located in /var/svc/manifest/network/dns/server.xml. The DNS client service is automatically enabled at initial boot if /etc/resolv.conf exists. Similarly the DNS server is enabled if the /etc/named.conf file exists. In both cases this assumes that all services upon which the DNS client and server depend, are enabled.
If you are upgrading from a previous Solaris version and used either or both of the DNS client and server- meaning if you have the configuration files mentioned above, the upgrade to Solaris 10 will automatically enable the services. No user intervention needed! If these configuration files don't exist, you should create them manually before attempting to enable these services. You might want to use webmin to configure these files.
Of course, given that the BIND v9 server is much more finicky about syntax errors, you may well see that a previously working DNS server configuration may not work without tweaking the named.conf file. In that case, take a look at the syslog output. The BIND v9 server is much better in terms of telling you which particular line and/or option it could not parse and/or what it expected.
May 31 14:39:03 manisha named[2586]: [ID 873579 daemon.error] /etc/named.conf:4: expected quoted string near '/'
That " /etc/named:4: " above refers to the configuration file and the line number where the parsing failed and the part after the colon is what the parser expected to see. This also applies to zone data syntax errors.
May 31 14:26:12 manisha named[3494]: [ID 873579 daemon.error] dns_master_load: named.local:3: unexpected end of line
May 31 14:26:12 manisha named[3494]: [ID 873579 daemon.error] zone 0.0.127.in-ad dr.arpa/IN: loading master file named.local: unexpected end of input
The upgrade to Solaris 10 also automatically runs " rndc-confgen -a " to create /etc/rndc.key which enables rndc to control a local BIND 9 server. This allows BIND 9 and rndc to be drop-in replacements for BIND 8 and ndc. More on this in the next section.
Administrative Interfaces
This is the part where some users have had the most questions- and for good reasons. With previous releases of Solaris (which included BIND 8) ndc was the only BIND server control tool available. rndc has replaced ndc for BIND 9 but it also lacks one important option- start, which means it cannot be used to start the name server like ndc. (This is true as of the 03/2005 Release of Solaris 10, i.e. BIND 9.2.4) rndc can, in its current state of evolution, stop the BIND name server, get status information, reload the entire configuration or some specified parts of it, toggle query logging, change the debugging level or flush the server's cache. But, with Solaris 10, general purpose SMF CLI tools (such as svcadm and svcs) are also available to control the BIND 9 server. So which admin tool should be used? The short answer is that using the SMF tools may help maintain a common experience with other Solaris services while rndc will always support a deeper set of BIND service options. Specifically and as a guideline, svcadm could be used to start, restart or stop DNS service and rndc could be used for some of the other tasks listed above.
Note that for most configurations (we describe the one exception later on) rndc stop and svcadm disable dns/server are equivalent and interchangeable. Let's look at a couple of example interactions:
{root:dnssrv:25} svcs dns/server
STATE STIME FMRI
online 15:57:57 svc:/network/dns/server:default
{root:dnssrv:26} rndc stop
{root:dnssrv:27} svcs dns/server
STATE STIME FMRI
disabled 15:58:07 svc:/network/dns/server:default
{root:dnssrv:29} svcs dns/server
STATE STIME FMRI
online 16:00:00 svc:/network/dns/server:default
{root:dnssrv:30} svcadm disable dns/server
{root:dnssrv:31} rndc status
rndc: connect failed: connection refused
If you who do not want to use the SMF framework at all, i.e. start the DNS server directly from the command line, rndc stop/halt works as you would expect and svcs/svcadm is expectedly unaware of the presence of the named process.
{root:dnssrv:32} /usr/sbin/named
{root:dnssrv:33} svcs dns/server
STATE STIME FMRI
disabled 16:00:17 svc:/network/dns/server:default
{root:dnssrv:35} rndc halt
Many of you may already know this but one of the changes between ndc and rndc (true for many platforms, not just Solaris) is that the former used hardcoded Unix domain sockets by default to communicate with the BIND server whereas the latter uses authenticated TCP sockets. However this also means that unless you run rndc-confgen -a on a freshly installed (as opposed to an upgraded) Solaris 10 system, rndc will not work.
Running the server in a chroot environment
Here we look at how you might leverage the DNS server manifest that ships with Solaris 10 to customize your own manifest to run the DNS server in a chroot jail. General chroot setup is out of scope here and the reader is referred to the many online resources on how to setup BIND v9 server for a chroot configuration. In this case we assume you are not only interested in running the DNS server chrooted, but also have it managed by the SMF framework. Remember we said that there was one configuration for which rndc stop and svcadm disable dns/server:instance are not interchangeable? Well, this is that configuration! In the case of a chrooted DNS server on Solaris 10 that is started using the SMF framework you cannot stop/halt it using rndc. It must be disabled using the svcadm CLI tool.
Here's an example interaction:
manisha# rndc status number of zones: 4 <...output truncated for brevity...> server is up and running manisha# rndc halt use svcadm(1M) to manage named manisha# svcadm disable dns/server manisha# rndc status rndc: connect failed: connection refusedIt is also possible to run the BIND server within a dedicated non-global Solaris 10 Container. More about that in another blog entry!
However I am running ahead of myself. I mentioned that I would show how to customize the shipping DNS server manifest to run the service chrooted. One way to do that would be to copy the supplied manifest ( server.xml ) file to a new file (say) - ( server-chroot.xml ). We do not recommend modifying the supplied manifest directly to preserve the ability to upgrade/patch. Another way could be to modify the properties via svccfg. We use the former method. You could start off by using a different instance name for your customized service- say 'chroot'. You then change two properties- start/exec and start/user both of which are of type astring. The former could be something like /usr/sbin/named -t /var/named instead of just /usr/sbin/named in the supplied manifest. The latter could be any non-privileged uid you choose to run the DNS server chrooted. We use the " noaccess" user in this example. Finally you need to adjust the privileges in the method credential to include proc_chroot. For further details on what that means, see the man page for privileges(5) on Solaris 10. The complete modified manifest can be found here.
You now import the manifest into the repository and enable the chrooted instance. (You may optionally want to disable any other instances of the DNS server already enabled.)
manisha# svccfg import server-chroot.xml manisha# svcadm enable dns/server:chroot manisha# svcs dns/server STATE STIME FMRI disabled 16:36:09 svc:/network/dns/server:default online 16:37:17 svc:/network/dns/server:chroot manisha# pgrep named 2457 manisha# pcred 2457 2457: e/r/suid=60002 e/r/sgid=0
Credits
I thank Cathy Zhou and Beverley Andalora for their help reviewing and integrating BIND 9 code and documentation for Solaris 10.
( May 31 2005, 02:18:10 PM PDT ) Permalink
