Linux.com

bhli

bhli

  • Linux.com Member
  • Posts: 1
  • Member Since: 30 Jan 11
  • Last Logged In: 25 Dec 11

Latest Posts

Posted by
Topic
Post Preview
Posted
  • bhli
    Floating Information Technology Environment
    I'm not sure where this query belongs but this seems to be the closest. Does anyone know is there is a floating information technology environment (FITE) type of distribution available? By that I mean that the overall operating environment floats above the hardware and is potentially not dependent on any single piece of it. This would work by using a directory service (probably OpenLDAP in multi-master mode) to define the overall system. In terms of the initial installation the disk would be placed in the first server and started. The installation would ask for the network and subnet details for the system and the IP address for the server. The default services it would install, and they should be changeable, would be the directory service, the DCHP server, the PXE boot server, the repository server, the terminal server, the Intranet server, the mail server, the print server, and the storage server. It would also ask for the details of the first workstation to be connected to it. It would offer a selection of templates so that the architecture can be selected. It would also pre-select the directory management tool which we'll call “Network Affinity” for now as I don't know of any that exists that would do the job. The installer would also ask for the IP address and hostname for the first workstation and make a reservation in the DHCP server for it. It would also ask for a name and password for the initial administrative user who would also be given management rights to the directory. Once the server is up and running the workstation with a blank hard drive would be connected to the network and started with the boot order to be the hard drive followed by the network. After failing on the hard drive boot, as there is no OS on it, it would boot to the network and the PXE server would check with the directory service based on the IP address given to it by the DHCP server as to what it should do with the system and based on how the computer object has been defined in the directory build the workstation to those specifications. At that point you would have your initial working system. From here new systems can be added to the system using Network Affinity. You would right-click the container that you wanted the system to be in and select new computer. You would then select the template for the system, be it workstation or server and the type of architecture that it used along with the MAC address and the hostname that you wanted for it. If it is a workstation you could add any other non-standard applications that were not part of your default template. The printers that it would print to would also be added to the directory object describing the system. If is is a server any server application services that you would want it to run could also be added to the directory object definition. Then when the computer is started it would automatically be set in the way that you have defined it in the directory. A feature that would help implement the floating characteristic of the system would be the ability to move server application services such as the mail server from one server to another. You would right-click the server that it is to be moved from and select properties which would bring up the properties dialog box. There would be a tab labelled SAS for server application services and it would list the services that it was running. Within the mail service would be buttons for configuration, logs, and data which would point to the location of these items on the server. There would also be a move button which if selected would bring up the option to move the service from that server to another. After selecting which server it is to move to and either initiating the move then or scheduling it for late at night when there are few or no users on the system it would install the mail server from the repository and copy over the configuration and data files. It would then shut down the service on the original server, perform one more sync to make sure everything is across, and then bring up the new mail server and register it in the directory. The workstations would be configured in the installation template such that the mail application either has a switch that queries the directory service on start up for the IP address of he mail server or is started via a script that does the same. That way all the workstations would connect to the new mail server automatically without any intervention. When a server has reached its end of life, all the server application services could be moved off it preparing it for decommissioning. Then, on the security tab for the servers directory object, you could select to wipe the local drives and what level of wiping you wish to use. It would then do this and place a log file, probably in where the systems back up configuration files are stored, noting whether the wipe was successful or not and then shut itself down ready for removal. This could also be done for workstations although probably in larger numbers at a time. Network Affinity would probably be an GUI interface to scripts so that making same changes would be done through its interface with it calling a script while making large changes such a added a large number to workstations to the system would be done by running a script against a CSV file which would call the relevant scripts to ad the workstations directly. This would enable full cradle to grave management of computers in the whole of enterprise environment. In addition with the back up of configuration files for workstations and their definitions in the directory, if a workstation was to become unusable the helpdesk could ask the end user to shut down the system and the start it up again but to press the F12 key, or whichever key starts the network boot, and the system would rebuild itself from scratch based on it directory definition including all the applications and printers assigned to it and at the last step lay down the configuration files so that it is set up to the preferred configuration. And because it is built from the repository it would be built with all the latest up dates automatically and there would be no need for maintenance for workstation images. Alternatively, if the workstation can still respond to commands remotely the helpdesk could possibly send a rebuild command from the security tab of the workstations directory dialog box in Network Affinity which would wipe the master boot record and then restart the system which would have the same effect if the BIOS is set to boot to the hard drive first and the network second. This would also work with virtual machines allowing for development and testing of software and system builds with relative ease. And with the system also allowing terminals it would provide a high level of flexibility in mixing different types of computers on the system. And if the PXE boot system can handle it even different architectures such as ARM could also be used on the system along with the more common i386 and AMD64 systems. Software and templates would be added using a LDAP package system (.lpkg) that would be a zip file containing an LDIF file describing the package to the directory service and the template or software. The the whole of enterprise system is large enough it would be added to the root repository and then distributed to the child repositories based on a schedule, say night time, of when network traffic is low. The software can then be assigned to computers via Network Affinity either to a schedule or immediately. In each computers dialog box would be a command queue tab which lists all the actions scheduled for the computer and when they are scheduled to take place and they would be able to be modified or cancelled. Such and action could be a wake on LAN in the middle of the night for updates to be deployed. New distributions of the OS would be supplied as ISO files for new installations and lpkg files for existing installations. Then the version number in the workstation or server object is incremented and a rebuild initiated, after server application services have been moved to a different server for servers, and the new version would get installed. An lpkg file could also contain other Linux or even BSD distributions as long as a repository can be set up for it and the PXE boot service and be modified to accommodate it. It should be possible to also create installation templates for tablets and phones if the packages are available as long as they have networking built into them and for tablets and phones without an Ethernet socket some kind for boot image that starts up the wireless network interface and some kind of pseudo-PXE boot service to connect to the PXE boot server. Although I've only provided an brief overview does anyone know if a distribution like this exists or is possible? It would be nice if it is.
    Link to this post 30 Jan 11

    I'm not sure where this query belongs but this seems to be the closest.

    Does anyone know is there is a floating information technology environment (FITE) type of distribution available? By that I mean that the overall operating environment floats above the hardware and is potentially not dependent on any single piece of it. This would work by using a directory service (probably OpenLDAP in multi-master mode) to define the overall system.

    In terms of the initial installation the disk would be placed in the first server and started. The installation would ask for the network and subnet details for the system and the IP address for the server. The default services it would install, and they should be changeable, would be the directory service, the DCHP server, the PXE boot server, the repository server, the terminal server, the Intranet server, the mail server, the print server, and the storage server. It would also ask for the details of the first workstation to be connected to it. It would offer a selection of templates so that the architecture can be selected. It would also pre-select the directory management tool which we'll call “Network Affinity” for now as I don't know of any that exists that would do the job. The installer would also ask for the IP address and hostname for the first workstation and make a reservation in the DHCP server for it. It would also ask for a name and password for the initial administrative user who would also be given management rights to the directory.

    Once the server is up and running the workstation with a blank hard drive would be connected to the network and started with the boot order to be the hard drive followed by the network. After failing on the hard drive boot, as there is no OS on it, it would boot to the network and the PXE server would check with the directory service based on the IP address given to it by the DHCP server as to what it should do with the system and based on how the computer object has been defined in the directory build the workstation to those specifications. At that point you would have your initial working system.

    From here new systems can be added to the system using Network Affinity. You would right-click the container that you wanted the system to be in and select new computer. You would then select the template for the system, be it workstation or server and the type of architecture that it used along with the MAC address and the hostname that you wanted for it. If it is a workstation you could add any other non-standard applications that were not part of your default template. The printers that it would print to would also be added to the directory object describing the system. If is is a server any server application services that you would want it to run could also be added to the directory object definition. Then when the computer is started it would automatically be set in the way that you have defined it in the directory.

    A feature that would help implement the floating characteristic of the system would be the ability to move server application services such as the mail server from one server to another. You would right-click the server that it is to be moved from and select properties which would bring up the properties dialog box. There would be a tab labelled SAS for server application services and it would list the services that it was running. Within the mail service would be buttons for configuration, logs, and data which would point to the location of these items on the server. There would also be a move button which if selected would bring up the option to move the service from that server to another. After selecting which server it is to move to and either initiating the move then or scheduling it for late at night when there are few or no users on the system it would install the mail server from the repository and copy over the configuration and data files. It would then shut down the service on the original server, perform one more sync to make sure everything is across, and then bring up the new mail server and register it in the directory. The workstations would be configured in the installation template such that the mail application either has a switch that queries the directory service on start up for the IP address of he mail server or is started via a script that does the same. That way all the workstations would connect to the new mail server automatically without any intervention.

    When a server has reached its end of life, all the server application services could be moved off it preparing it for decommissioning. Then, on the security tab for the servers directory object, you could select to wipe the local drives and what level of wiping you wish to use. It would then do this and place a log file, probably in where the systems back up configuration files are stored, noting whether the wipe was successful or not and then shut itself down ready for removal. This could also be done for workstations although probably in larger numbers at a time. Network Affinity would probably be an GUI interface to scripts so that making same changes would be done through its interface with it calling a script while making large changes such a added a large number to workstations to the system would be done by running a script against a CSV file which would call the relevant scripts to ad the workstations directly. This would enable full cradle to grave management of computers in the whole of enterprise environment.

    In addition with the back up of configuration files for workstations and their definitions in the directory, if a workstation was to become unusable the helpdesk could ask the end user to shut down the system and the start it up again but to press the F12 key, or whichever key starts the network boot, and the system would rebuild itself from scratch based on it directory definition including all the applications and printers assigned to it and at the last step lay down the configuration files so that it is set up to the preferred configuration. And because it is built from the repository it would be built with all the latest up dates automatically and there would be no need for maintenance for workstation images. Alternatively, if the workstation can still respond to commands remotely the helpdesk could possibly send a rebuild command from the security tab of the workstations directory dialog box in Network Affinity which would wipe the master boot record and then restart the system which would have the same effect if the BIOS is set to boot to the hard drive first and the network second. This would also work with virtual machines allowing for development and testing of software and system builds with relative ease. And with the system also allowing terminals it would provide a high level of flexibility in mixing different types of computers on the system. And if the PXE boot system can handle it even different architectures such as ARM could also be used on the system along with the more common i386 and AMD64 systems.

    Software and templates would be added using a LDAP package system (.lpkg) that would be a zip file containing an LDIF file describing the package to the directory service and the template or software. The the whole of enterprise system is large enough it would be added to the root repository and then distributed to the child repositories based on a schedule, say night time, of when network traffic is low. The software can then be assigned to computers via Network Affinity either to a schedule or immediately. In each computers dialog box would be a command queue tab which lists all the actions scheduled for the computer and when they are scheduled to take place and they would be able to be modified or cancelled. Such and action could be a wake on LAN in the middle of the night for updates to be deployed. New distributions of the OS would be supplied as ISO files for new installations and lpkg files for existing installations. Then the version number in the workstation or server object is incremented and a rebuild initiated, after server application services have been moved to a different server for servers, and the new version would get installed. An lpkg file could also contain other Linux or even BSD distributions as long as a repository can be set up for it and the PXE boot service and be modified to accommodate it. It should be possible to also create installation templates for tablets and phones if the packages are available as long as they have networking built into them and for tablets and phones without an Ethernet socket some kind for boot image that starts up the wireless network interface and some kind of pseudo-PXE boot service to connect to the PXE boot server.

    Although I've only provided an brief overview does anyone know if a distribution like this exists or is possible? It would be nice if it is.

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board