Welcome to Dploy Wiki

Design Ideas around a dploy.org project

Currently we have great pieces of software such as LinuxCOE and MondoRescue to manage server deployment from an automatic installation manner or from an imaging manner respectively (multi-distro and multi-arch support in both case). We'll later use the word deployment meaning both scenarios.

It would be great to associate the 2 software under a common GPL ombrella to create a multi-purpose deployment server in a box that would allow:

  • to deploy a known or unknown server with whatever method from a central place
  • to manage centraly in a database every information related to the machine deployed. The set of tables could be in a standalone database or integrated in other management platform which are open to such integration (HP SIM, OCS Inventory).
  • to take in account hardware particularities in the deployment (using manufacturer available tools such as HP's SSSTK and/or opensource tools)
  • give a standardized method on how to setup such a deployment server from scratch, including mirroring instruction and automatic mirror structure creation from a set of ISOs (using the mrepo tool
  • provide a web interface/console (what else :-) for the management of the systems deployed or to be deployed. Should work in both text and graphical environment for easiest usage (lynx compliant)
  • Modular approach of deployement (new features should be easily added). Each service could be hosted on a different server (pxe/tftp, dhcp, system-designer, waystation, mondorescue images, ...)
  • architecture neutral (with initial support of i386, x86_64 and ia64)
  • distribution neutral (with initial support of Fedora, RHEL, OpenSUSE, SLES, Debian, Ubuntu)

This web page has been written following multiple discussions around these topics with J. Vance, B. Gartner, L. Mayes, G. Renaud, L. Bouchard and many others.

Technical ideas around a dploy.org project

  • use a standard protocol such as HTTP, and apache+wget to allow communication between the machine deployed and and deployment server. This would be the prefered way of exchanging informations (hw inventory typically)
  • mindi (minimal boot environement) could be used on the machine deployed at first run, through media or PXE. Or it could also be launched on an already deployed server.
  • mindi could also integrate other required components such as lshw, ssstk tools, or other manufacturer tools based on a future set of configuration files provided in mindi 2.x
  • the inventory is stored in the server DB (standalone RDBMS, or integrated in another tool) and will be maintained as oprations are made on the machine, as well as some status.
  • following reboot of the server will trigger the installtion planned (deployment through LinuxCOE or image deployment with mondo)
  • Full support of proliant hardware (ILO - Raid - Firmware updates)
  • For security reason most of the scripts run as dploy user (not root)

Interface functions

  • list of servers (automatic addition of PXE based servers, manual addition for others)
  • assigning a task to a machine/group of machines
  • (proliant) manage already discovered servers (power on, off... ILO functions)
  • delete servers to restart discovery / installation
  • group servers to apply the same job to multiple servers
  • (proliant) firmware update
  • (proliant) link to admin page (2381)
  • link to webmin page (10000)
  • (proliant) link to ACU (started on demand before launching the interface)
  • launch any commands thru SSH (password or public key protected)
  • launch an imaging job

Proposed Requirements

  • Perl
  • Perl DBI
  • ISC DHCP server
  • MySQL, PostgreSQL or file
  • Perl CGI or TT
  • tftpd
  • pxelinux

References

Documentation

Concerning trac

For a complete list of local wiki pages, see TitleIndex.

Trac is brought to you by Edgewall Software, providing professional Linux and software development services to clients worldwide. Visit http://www.edgewall.com/ for more information.