Enterprise Provisioning - Future Prospects - Revision history

imported_>amigadave: wikify slightly

2011-01-25T08:56:45Z

wikify slightly

← Older revision		Revision as of 08:56, 25 January 2011
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.		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 23:		Line 21:
	# The device connects to a network and receives the DNS domain as part of the configuration from DHCP		# 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		# 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>		# User invokes preconfigurator application. It queries appropriate service record, for example <code>_maemo_autoconf._tcp._srv.example.com</code>
	# DNS returns configuration server URL. Or a list of those		# DNS returns configuration server URL. Or a list of those
	# Preconfigurator prompts the user his/her login credentials and connects to the configuration server		# 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 ~~bundel~~ of information which contains		# Configuration server validates credentials and sends back (perhaps wrapped into an XML file) a bundle 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 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 ===		=== 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:		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 one-time URL (sent via SMS) is served using a special content type, for example <code>application/x-maemo-autoconfiguration</code>
	* The web browser of the device is capable to open the pre-configuration application for that content type		* The web browser of the device is capable to open the pre-configuration application for that content type

Line 55:		Line 52:
	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.		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].		If you are interested, you can read [[Device_Management_using_Bcfg2\|more information on Bcfg2]].

	== Summary ==		== Summary ==

imported_>juaalto: /* Future prospects */

2010-06-04T10:35:11Z

Future prospects

← Older revision		Revision as of 10:35, 4 June 2010
Line 1:		Line 1:
	= Future prospects =		= 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.~~		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.

	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 ==		== Enterprise preconfiguration utility ==

imported_>amigadave: add to Enterprise category

2010-06-01T13:14:01Z

add to Enterprise category

← Older revision		Revision as of 13:14, 1 June 2010
Line 62:		Line 62:

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

			[[Category:Enterprise]]

imported_>jpalko: /* Summary */

2010-05-28T04:01:57Z

Summary

← Older revision		Revision as of 04:01, 28 May 2010
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]]~~

imported_>jpalko at 12:31, 27 May 2010

2010-05-27T12:31:57Z

← Older revision		Revision as of 12:31, 27 May 2010
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]]

imported_>jpalko: EDG - Future prospects

2010-05-27T12:01:09Z

EDG - Future prospects

New page

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

# 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]].