Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:pravin:project_plan:start [2009/05/22 16:28] less1 |
soc:2009:pravin:project_plan:start [2009/06/03 14:48] (current) less1 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Pravin Shinde: boot.kernel.org - Universal remote network booting for the masses ====== | ====== Pravin Shinde: boot.kernel.org - Universal remote network booting for the masses ====== | ||
| + | Project aims for creation of website, which can be used by any user for creating and downloading | ||
| + | customized boot images, system tools, utilities and network installation images based on needs. | ||
| + | It will also support HTTP based booting with PXELinux and allow users to customize the system using | ||
| + | the flexibility of interface provided be Syslinux and boot from it without installation. We plan to enable normal | ||
| + | users to experiment with different tools, utilities and system images without any hassles. | ||
| + | |||
| + | ===== Project Plan ===== | ||
| + | |||
| This project is about making the network boot process available to users on a large scale. | This project is about making the network boot process available to users on a large scale. | ||
| Line 25: | Line 33: | ||
| This customized PXEClient is nothing but regular PXELinux with an embedded script that sets the "next-server" | This customized PXEClient is nothing but regular PXELinux with an embedded script that sets the "next-server" | ||
| to boot.kernel.org regardless of what the local DHCP server provides. This way, any user can use boot.linux.org without | to boot.kernel.org regardless of what the local DHCP server provides. This way, any user can use boot.linux.org without | ||
| - | having to (re)configure a dhcp server. | + | having to (re)configure a dhcp server. [Done] |
| Machines with static IP addresses can be handled by providing a separate embedded script which can be generated at | Machines with static IP addresses can be handled by providing a separate embedded script which can be generated at | ||
| Line 31: | Line 39: | ||
| values will be hard-coded into the embedded script which will be bundled with PXEClient handed to the user. | values will be hard-coded into the embedded script which will be bundled with PXEClient handed to the user. | ||
| User will be provided with web-interface at boot.linux.org where he will feed in his network setting, and customized | User will be provided with web-interface at boot.linux.org where he will feed in his network setting, and customized | ||
| - | PXEClient embedded script for user's network will be automatically generated. | + | PXEClient embedded script for user's network will be automatically generated. [Currently working on] |
| These customized PXElinux clients will start the machine and contact boot.kernel.org. boot.kernel.org will return a | These customized PXElinux clients will start the machine and contact boot.kernel.org. boot.kernel.org will return a | ||
| Line 71: | Line 79: | ||
| also support booting and installation over HTTP. | also support booting and installation over HTTP. | ||
| - | ===== Project Plan ===== | + | ==== Summary ==== |
| - | This project is about making the network boot process available to users on a large scale. | + | ==== Outline ==== |
| - | The project aims to enable the creation of a site (say, boot.kernel.org) which can be used by | + | ==== Milestones and Timeline ==== |
| - | any person in multiple ways to get a customized system image, hardware diagnostics, utilities, | + | Deliverables with Timeline (Duration = 12 weeks) |
| - | security and rescue tools and network installation images. This can be done either through any | + | |
| - | web browser by creating and downloading custom images, or with tools like PXElinux which can | + | |
| - | contact boot.kernel.org at boot time over HTTP for fetching a bootable image. | + | |
| - | The reasoning behind this project is to provide one stop location for user where he can | + | [Week-0,1] |
| - | find and use most of the diagnostic, rescue tools and various system images without any | + | 1. PXE Knife on HTTP. |
| - | need for creation of dedicated media or installation. It will allow users to try out various systems | + | 2. PXE clients with embedded scripts. |
| - | in painless way. | + | |
| - | This project is based on "PXE Knife" which let the user select and boot from various | + | [Week-2,3] |
| - | system utilities using PXE. Currently PXE Knife works over TFTP. The first step of this | + | 3. Web interface for customized PXE-client based on network configuration of the user. |
| - | project will be to extend PXE Knife to work over HTTP. This project goes beyond "PXE Knife" | + | 4. Web interface for PXE Knife images of HTTP. |
| - | by supporting the hosting of actual applications on centralized server and giving out only | + | |
| - | small stub to user which will boot the system and bring it to network. Then the stub will | + | |
| - | contact central server for any application/utilities. This way, initial download time is | + | |
| - | significantly reduced and all applications can be always kept uptodate at central location | + | |
| - | of server. This way, user will always get most updated and *working* application whenever he needs. | + | |
| - | Next immediate step will be about customizing PXELinux to use boot.linux.org. | + | [Week-4] |
| - | This customized PXEClient is nothing but regular PXELinux with an embedded script that sets the "next-server" | + | 5. Detailed Syslinux menu from where user can choose which applications he wants add. |
| - | to boot.kernel.org regardless of what the local DHCP server provides. This way, any user can use boot.linux.org without | + | |
| - | having to (re)configure a dhcp server. | + | |
| - | Machines with static IP addresses can be handled by providing a separate embedded script which can be generated at | + | [Week-5,6] |
| - | boot.kernel.org by providing an IP-address, router and DNS server address corresponding to the user's machine. These | + | 6. Base system with generic kernel and base initrdfs which should boot on most of the systems. |
| - | values will be hard-coded into the embedded script which will be bundled with PXEClient handed to the user. | + | |
| - | User will be provided with web-interface at boot.linux.org where he will feed in his network setting, and customized | + | |
| - | PXEClient embedded script for user's network will be automatically generated. | + | |
| - | These customized PXElinux clients will start the machine and contact boot.kernel.org. boot.kernel.org will return a | + | [Week-7,8] |
| - | Syslinux image with a menu providing the user with a list of various systems and tools/utilities he/she wishes to select | + | 7. Precompiled applications and their respective configurations. |
| - | for his/her system. Once the user makes his/her choices, boot.linux.org will create a new system image by bundling | + | |
| - | together a precompiled kernel, a prepared initramfs and appending the selected tool/packages/stubs to it. This customized | + | |
| - | system image returned by boot.linux.org will be used by the machine to boot. | + | |
| - | Syslinux will be used to provide the user with an interface where he/she can select which | + | [Week-9,10] |
| - | kernel and which tools he wants to bundle into the image. Depending on the selection made | + | 8. scripts for dynamically appending above precompiled applications into initramfs, |
| - | by the user, an image will be dynamically generated and made available to him/her. The default interface will be using | + | and reconfiguring the system so that appended application will work. |
| - | vesamenu.c32 giving simple navigation, and expert mode interface can be provided using menu.c32 giving more flexibility. | + | |
| - | The image generated by boot.kernel.org will consist of two major components: | + | [Week-11] |
| - | the kernel itself and initramfs. The kernel portion will be common for all system images | + | 9. Providing various Network installable distributions online. |
| - | generated for a particular architecture. Most of the device drivers will be compiled as modules | + | 10. Documentation |
| - | to reduce the hardware dependence and size of the kernel. These kernel modules will be part of | + | [End] |
| - | the initramfs component. The base system kernel will be designed on the lines of "Ultimate boot CD" or | + | |
| - | "Knoppix" which are able to boot on most commodity hardware. But root filesystem will be entirely based | + | |
| - | on initramfs and hence self sufficient for execution. | + | |
| - | + | ||
| - | To keep the size of the system image resonably small, base system will only provide minimal functionality. | + | |
| - | However, the user will be provided with options to add any applications or utilities he/she wants | + | |
| - | to bundle in the image. The application selected by users will be appended to initramfs base system | + | |
| - | by exploiting the ability to append into CPIO as one more layer. This will provide semi-transparency to users | + | |
| - | as when user selects any appliction/tool, all the dependencies will be precomputed. | + | |
| - | + | ||
| - | After accepting the selection from a user's side, boot.kernel.org will dynamically append the | + | |
| - | applications selected to the base initramfs system. It will also add any other appliction/library needed | + | |
| - | for selected application to work. As all the tools which will be will be pre-configured and kept ready for deployment, | + | |
| - | only appending the binaries to the initramfs will be needed (in addition to changes in configuration of base system, if required). | + | |
| - | As no compilation is involved, this step can be done with an acceptable response time. | + | |
| - | + | ||
| - | This system can be also extended beyond providing basic rescue facilities by providing the ability | + | |
| - | to perform a network installation. Initially, the base system provided to the user will boot the machine, | + | |
| - | after which the network installation is kickstarted using the repository available on boot.kernel.org. | + | |
| - | By providing central repository and custom boot images Network installtion can be made possible. | + | |
| - | Most distributions come with network boot support over TFTP. But with small modifications these destributions can | + | |
| - | also support booting and installation over HTTP. | + | |
| - | + | ||
| - | ==== Summary ==== | + | |
| - | + | ||
| - | ==== Outline ==== | + | |
| - | + | ||
| - | ==== Milestones and Timeline ==== | + | |
