Feature roadmap/Image customization

Feature subcategory		Is part of::Category:Security, activation and deployability
Requesters		{{#arraymap:Uruguay, Ethiopia, Colombia,Peru, Mexico, Mongolia|,|x|Requested by::x}}
Requirements		For Colombia details, see: http://lists.laptop.org/pipermail/devel/2008-July/017299.html When imaging a new laptop or upgrading a laptop we must allow the deployment to create a custom image. This special image will allow XOs to be re-imaged via USB or over a network (via olpc-update to internet, via olpc-update to XS, via Quicker Imaging feature above). The customized image must allow configuration of the following items. These should be settable when creating a new image or when upgrading unless otherwise noted. The ideal solution would allow a deployments to load a source XO with the OS, add anything they want to it (e.g. RPMs, activities, other content, language packs, scripts, changed configuration files, etc.) then the "click a button" and output a signed image which is a full copy of that XO (need to document anything which does not get copied exactly, e.g. factory data, user name, other?). This signed image can then be installed via any of the available mechanisms. Cuando haciendo un imagen nuevo para el XO o haciendo una actualizacion del Software debe permitir que el despliegue cree una imagen de encargo. Esta imagen especial permitiráue XOs sea puesto víel USB o sobre una red (víla olpc-update del Internet, víla olpc-update de un XS, o via Quicker Imaging definido arriba). La imagen modificada para requisitos particulares debe permitir la configuracióe los puntos siguientes. Étos deben ser configurable al crear una nueva imagen o al aumentar a menos que se indicare en forma diferente. Must allow re-image of an XO or update of an XO from 8.2(767) and preferably 70x as well. Must allow install or upgrade via olpc-update to internet, via olpc-update to XS, via NAND Blaster, via USB stick. When installing a custom image, must not require any user interaction with the keyboard. Can require holding down a game key on startup. Al instalar una imagen de encargo, no debe requerir cualquier interaccióel usuario con el teclado. Puede requerir el mantenimiento de una llave del juego en arranque. Must allow setting the language Debe permitir el fijar de la lengua Must allow inclusion of the activities and content bundles chosen by the deployment. Debe permitir la inclusióe las actividades y el contenido líelegido por el despliegue. Must allow installing a language pack Debe permitir el instalar de un paquete de la lengua Must allow configuring the keyboard for a language Debe permitir el configurar del teclado para una lengua Must allow installing an RPM (Ethiopia) Debe permitir el instalar de una RPM (Etiopí Must allow setting Time, Date Timezone Debe permitir deinicion del tiempo y Timezone Must allow setting of all elements of the sugar-control panel, CLI and GUI versions. Debe permitir el ajuste de todos los elementos del panel del azúcontrol, de las versiones del CLI y del GUI. Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done. Debe trabajar con XOs activado y XOs no activado. En el caso no activado debe activarlos asíue el XO es pronto para usar en la escuela cuando estáecho. Must no require more than one reboot. No debe requirer mas que on "reboot" Should turn off when its done or show "success" screen then one key stroke and shutdown. Must allow changing startup picture by copying an image to the XO. Debe permitir el cambiar del cuadro de lanzamiento copiando una imagen al XO. Must not require that deployments request a new signed build from OLPC. This can be addressed by allowing them to sign their own builds or by allowing all the customizations listed to be made on a signed build without requiring that it be re-signed. We can require that this feature is only available to specially designated users. Necesidad no requerir que los despliegues pidan una nueva estructura firmada de OLPC. Esto puede ser tratada permitiendo que firmen sus propias estructuras o permitiendo todos los arreglos para requisitos particulares enumerados para ser hecho en una estructura firmada sin requerir que re-signed. Podemos requerir que esta caracteríica estéolamente disponible para los usuarios especialmente señdos. See also: <trac>7878</trac> <trac>6689</trac> <trac>6432</trac> The following two points need redefinition and clarification: Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done. (rewrite to cover pre-activated and lease feature disabled cases). When imaging in a warehouse must activate the laptop Note, follow up on issues with open firmware.
Specification		* http://lists.laptop.org/pipermail/devel/2008-March/011553.html http://lists.laptop.org/pipermail/devel/2008-July/016417.html re: the ideal solution paragraph above: I don't feel this is a realistic aim. A lot of files are initialized on first boot which need to be customized per-XO. For a redistributable XO image, all of these changes would have to be undone at image generation time. While it is possible to produce a specification of these changes by taking an unmodified unbooted image and "diff" it against a booted-but-otherwise-untouched XO nand image, this is a bit of a hack and would be a pain to maintain in the long run (our system and its building blocks are constantly changing). Michael Stone had a good writeup on the differences he detected in a Nepal build that had been made in this way, even after they thought they had cleaned it up. Can anyone find the link? And here's my suggestion for improving customisation: We already have the technology to insert RPMs into a build, because the released builds are made up of RPMs and not much more! So let's fix up pilgrim or puritan to be more available for use by deployments, perhaps setting up a koji-style build server of some kind hosted at 1CC (to avoid the deployments having to set up a build box). As for other customisations, the current method (customization key) works fine for the limited customisations that it allows, so that simply needs to be expanded. -DanielDrake 20:15, 17 December 2008 (UTC)
Owners		{{#arraymap:|,|x|Contact person::User:x}} Please indicate developers or champions supporting this request
Priority		Priority::1
Helps deployability?		Helps deployability::yes
Target for 9.1?		Target for 9.1::yes