Editing Enterprise Provisioning - Future Prospects

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

= 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.

== 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:

# The device connects to a network and receives the DNS domain as part of the configuration from DHCP
# Preconfigurator prompts the user if the domain is a correct one
# User invokes preconfigurator application. It queries appropriate service record, for example <tt>_maemo_autoconf._tcp._srv.example.com</tt>
# DNS returns configuration server URL. Or a list of those
# 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)
# 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
# Preconfigurator downloads and installs the configurator application and puts other information in appropriate places
# 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 <tt>application/x-maemo-autoconfiguration</tt>
* 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 [https://wiki.maemo.org/Device_Management_using_Bcfg2 more information on Bcfg2].

== Summary ==

Let's proceed to [[Enterprise_Provisioning_Summary|provisioning summary]].

[[Category:Enterprise]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

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

Personal tools

Navigation

Views

Editing Enterprise Provisioning - Future Prospects

@@ Line 1: / Line 1: @@
+= 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.
@@ Line 21: / Line 23: @@
 # The device connects to a network and receives the DNS domain as part of the configuration from DHCP
 # Preconfigurator prompts the user if the domain is a correct one
-# User invokes preconfigurator application. It queries appropriate service record, for example <code>_maemo_autoconf._tcp._srv.example.com</code>
+# User invokes preconfigurator application. It queries appropriate service record, for example <tt>_maemo_autoconf._tcp._srv.example.com</tt>
 # DNS returns configuration server URL. Or a list of those
 # 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)
+** 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)
-# Configuration server validates credentials and sends back (perhaps wrapped into an XML file) a bundle of information which contains
+# Configuration server validates credentials and sends back (perhaps wrapped into an XML file) a bundel of information which contains
-#* User personal info
+** User personal info
-#* An URL from where the actual configurator application can be downloaded from
+** An URL from where the actual configurator application can be downloaded from
-#* Data needed by the configuration application, such as
+** Data needed by the configuration application, such as
-#** Certificates
+*** Certificates
-#** URL to configuration data
+*** URL to configuration data
-#** Device identifier and password
+*** Device identifier and password
-#** Application package checksum
+*** Application package checksum
 # Preconfigurator downloads and installs the configurator application and puts other information in appropriate places
-# Preconfigurator invokes the configurator application, which performs the actual device configuration
+# 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 <code>application/x-maemo-autoconfiguration</code>
+* The one-time URL (sent via SMS) is served using a special content type, for example <tt>application/x-maemo-autoconfiguration</tt>
 * The web browser of the device is capable to open the pre-configuration application for that content type
@@ Line 52: / Line 55: @@
 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 [[Device_Management_using_Bcfg2|more information on Bcfg2]].
+If you are interested, you can read [https://wiki.maemo.org/Device_Management_using_Bcfg2 more information on Bcfg2].
 == Summary ==