Enterprise Provisioning - Future Prospects

(EDG - Future prospects)
Line 62: Line 62:
Let's proceed to [[Enterprise_Provisioning_Summary|provisioning summary]].
Let's proceed to [[Enterprise_Provisioning_Summary|provisioning summary]].
 +
 +
[[Category:Power users]]

Revision as of 12:31, 27 May 2010

Contents

Future prospects

The purpose of this section is to give some insight on what can be expected in an enterprise deployment space in future releases. The intention is to provide some guidance for planning future activities. For example, avoiding allocating vast amount of internal resources to develop a solution to a problem which will go away in a near future release of Maemo/MeeGo.

What is said here should not be taken as any kind of a promise or roadmap. If anything, this is a list about things the team building the Enterprise Package is discussing about with the team developing the device.

Enterprise preconfiguration utility

One of the major obstacles to overcome with the enterprise deployment is the lack of a suitable pre-installed configuration application. There is no such application downloadable on default repositories. This leads to a complicated provisioning process where the user needs to go through many steps and enter unnecessarily large amounts of information on the device.

A dedicated configurator application pre-installed at the factory would solve this problem. However, enterprises do have diverse requirements and system management processes. Trying to build one monolithic configurator application which suits everyone is next to impossible. This approach would probably also lead to bloated application, too big to be included in the device factory set-up.

Better strategy would be building a split-configuration. In this approach, the device has a tiny pre-configuration utility pre-installed when it leaves the factory. The sole purpose of this utility is to download and install the actual configuration application and pass the control to it. The preconfiguration utility would have capabilities to perform some basic networking and repository setup (such as switching between networks and disable/enable repositories) and perform the autodiscovery described in the next chapter but basically nothing else.

In the split-configuration approach enterprises can utilize a wide selection of actual configuration applications. These applications can vary from small dedicated set-up applications into full-blown device management applications.

Auto-discovery

Another problem in the enterprise deployment is that the source of configuration is unknown, thus it has to be provided by the user. This can be a tedious and error prone step. This could be avoided by using a pre-configurator application with suitable service auto-discovery features. Below are some options to implement auto-discovery.

Auto-discovery utilizing DNS service records

This option relies on DNS entries controlled by the corporate. The process goes roughly as follows:

  1. The device connects to a network and receives the DNS domain as part of the configuration from DHCP
  2. Preconfigurator prompts the user if the domain is a correct one
  3. User invokes preconfigurator application. It queries appropriate service record, for example _maemo_autoconf._tcp._srv.example.com
  4. DNS returns configuration server URL. Or a list of those
  5. Preconfigurator prompts the user his/her login credentials and connects to the configuration server
    • For additional security, the preconfigurator might require that the client part of SSL certificate is already at the device (requires a commercial certificate or pre-approved self-signed certificate)
  1. Configuration server validates credentials and sends back (perhaps wrapped into an XML file) a bundel of information which contains
    • User personal info
    • An URL from where the actual configurator application can be downloaded from
    • Data needed by the configuration application, such as
      • Certificates
      • URL to configuration data
      • Device identifier and password
      • Application package checksum
  1. Preconfigurator downloads and installs the configurator application and puts other information in appropriate places
  2. Preconfigurator invokes the configurator application, which performs the actual device configuration


Auto-discovery SMS and web browser integration

Another option is to use a variation of the "SMS based" provisioning strategy described earlier. The main differences are:

  • The one-time URL (sent via SMS) is served using a special content type, for example application/x-maemo-autoconfiguration
  • The web browser of the device is capable to open the pre-configuration application for that content type

Rest of the process goes like in DNS autodiscovery option above.

Device management

An obvious shortcoming in the current provisioning process is the lack of any device management capability. After the device is provisioned, all traces are lost. There is no statistics about provisioned devices, no information about what packages were installed, how succesful was the configuration. The devices do not periodically report they are still in use, and what is perhaps most important, is the configuration still up-to-date.

In a sense, it is like standing at a waterfront, throwing rocks into a lake. They are never seen again.

These shortcomings, and a number of others, could be addressed using some device management application as a configurator application. One option would be use an open source configuration management software commonplace in management of more "traditional" computers (desktops and servers), such as Bcfg2, CFEngine and Puppet.

If you are interested, you can read more information on Bcfg2.

Summary

Let's proceed to provisioning summary.

Retrieved from "http://wiki.maemo.org/Enterprise_Provisioning_-_Future_Prospects"