Device management using Bcfg2
m |
m |
||
| Line 30: | Line 30: | ||
|} | |} | ||
| + | Instructions given in this article are tested on Fremantle. They may work on other releases as well, but probably not. | ||
| - | == Why | + | == Device management? Why bother? == |
Provisioning Devices without management is like standing on the waterfront, throwing rocks in to a lake trying to get them into a bucket at a bottom. The throwing movement can be very controlled and calculated, but once the rock is released from hand, all control and traceability is lost. As a result, we do not really know if it ever hit the bucket. And if it did not, there is no way to get it there. Not to mention ability to move it into another bucket if so desired. Over time, we also inevitably lose track of how many rocks have we have thrown. | Provisioning Devices without management is like standing on the waterfront, throwing rocks in to a lake trying to get them into a bucket at a bottom. The throwing movement can be very controlled and calculated, but once the rock is released from hand, all control and traceability is lost. As a result, we do not really know if it ever hit the bucket. And if it did not, there is no way to get it there. Not to mention ability to move it into another bucket if so desired. Over time, we also inevitably lose track of how many rocks have we have thrown. | ||
| Line 46: | Line 47: | ||
== Why Bcfg2? == | == Why Bcfg2? == | ||
| + | |||
| + | Openness is central part of the Maemo philosophy. Thus, using an Open Source configuration management system fits right in. | ||
| + | |||
| + | Bcfg2 was chosen as the first candidate to try-out because | ||
| + | |||
| + | * Architecture is server-centric. Processing is performed at the server end as much as possible. This makes the client lightweight. It makes it also simpler and less frequently changing. | ||
| + | * Device management is a special use case for a software like this. They are all geared more for server and desktop management. Thus, fair amount of customization is anticipated. Bcfg2 has very flexible plugin architecture where most of it's core functionality implemented as plugins. This makes it very customization-friendly, nearly all components are replaceable | ||
| + | * Anticipation of customization puts lot of weight to implementation language. Bcfg2 is written in Python, which suits the author best. | ||
| + | |||
| + | That said, there is no reason why other configuration management systems such as CFEngine or Puppet wouldn't work as well. (Actually, Puppet was tried out, got successfully running at the Device. Only it did not communicate with the server. This is possibly caused by the SSL problem discussed later. That's was the point where lack of author's Ruby skills kicked in :) | ||
| + | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
apt-get install python | apt-get install python | ||
| Line 60: | Line 67: | ||
python setup.py install --install-layout deb --record /root/bcfg2files | python setup.py install --install-layout deb --record /root/bcfg2files | ||
| - | + | https://bugs.maemo.org/show_bug.cgi?id=5102 | |
Note, Category is intentionally broken, this is not in any shape for showing up yet | Note, Category is intentionally broken, this is not in any shape for showing up yet | ||
[[ | [[ | ||
Category:Power users | Category:Power users | ||
]] | ]] | ||
Revision as of 17:45, 22 March 2010
Contents |
Under Construction
This article contains information about using Bcfg2, an open source configuration management system in management of Maemo based devices.
Scope and terminology
Scope of the article is using Bcfg2 to manage Maemo devices of employees at a fairly large company, where the number of devices is counted on hundreds or thousands. In a private use, or in small companies things covered here hardly make any sense.
In the remainder if this document, following terminology is used
| Term | Description |
|---|---|
| Device | Maemo based handset, such as Nokia N900 |
| Enterprise | A large company ot other organization that wants employees to ba able to acces company IT systems using Maemo based devices |
| Desktop computer | A full-size computer (traditional desktop or laptop) used to access corporate IT systems |
| Enterprise configuration | A set of applications and configuration values which the Enterprise wants to deploy into the Device as a prerequisite for accessing corporate IT systems. Usually includes hardening the device security. |
| Provisioning | The process which equips the Device with Enterprise configuration |
Instructions given in this article are tested on Fremantle. They may work on other releases as well, but probably not.
Device management? Why bother?
Provisioning Devices without management is like standing on the waterfront, throwing rocks in to a lake trying to get them into a bucket at a bottom. The throwing movement can be very controlled and calculated, but once the rock is released from hand, all control and traceability is lost. As a result, we do not really know if it ever hit the bucket. And if it did not, there is no way to get it there. Not to mention ability to move it into another bucket if so desired. Over time, we also inevitably lose track of how many rocks have we have thrown.
Hence, Provisioning-only approach leads at least following shortcomings
- No statistics about Devices Provisioned
- No information about success of the Provisioning
- No method to fix failed Provisioning
- No method for managing changes at Enterprise configuration (other than publish a new release hoping users will pick it up)
Using the rock analogy, in Device management approch we never completely release the rock. We tie a thin nylon line into each rock before throwing it. The line helps us to track whether the rock hit the bucket or not. We can use the line to lift misses to the bucket. We can also use the line to move them to another bucket if so desired. We can also have statistics about the rocks thrown easily; just count the lines.
It should be also noted that there are legislations such as Sarbanes-Oxley which mandate keeping track of computers able to access and store corporate data.
Why Bcfg2?
Openness is central part of the Maemo philosophy. Thus, using an Open Source configuration management system fits right in.
Bcfg2 was chosen as the first candidate to try-out because
- Architecture is server-centric. Processing is performed at the server end as much as possible. This makes the client lightweight. It makes it also simpler and less frequently changing.
- Device management is a special use case for a software like this. They are all geared more for server and desktop management. Thus, fair amount of customization is anticipated. Bcfg2 has very flexible plugin architecture where most of it's core functionality implemented as plugins. This makes it very customization-friendly, nearly all components are replaceable
- Anticipation of customization puts lot of weight to implementation language. Bcfg2 is written in Python, which suits the author best.
That said, there is no reason why other configuration management systems such as CFEngine or Puppet wouldn't work as well. (Actually, Puppet was tried out, got successfully running at the Device. Only it did not communicate with the server. This is possibly caused by the SSL problem discussed later. That's was the point where lack of author's Ruby skills kicked in :)
apt-get install python tar zxvf bcfg2-0.9.6.tar.gz cd bcfg2-0.9.6 python setup.py install --install-layout deb --record /root/bcfg2files
https://bugs.maemo.org/show_bug.cgi?id=5102 Note, Category is intentionally broken, this is not in any shape for showing up yet [[ Category:Power users ]]