Gentoo Wiki ArchivesGentoo Wiki

GNU_Modular_Network_Management_System

Image:Ltsp_logo.jpg

Pages

  1. LTSP Client
  2. LTSP Server
  3. LTSP Desktop
  4. LTSP Configuration
  5. GNU Modular Network Management System
edit

Introduction

GMNMs, or GNU Modular Network Management System, which is pronounced G M&Ms is a system which knollbert and I have been working on to facilitate the management a few network service configurations using MySQL and PHP. Namely, in Linux these include:

However, if someone were willing, it shouldn't be without the realm of possibility to port all of the above to the native Windows Server™ proprietary dhcp system service as well.

Additionally, we would like it to manage these services for both Windows and Linux.

Eventually it would be nice if it become an opensource replacement (or supplement) to Novell iManager or Windows whatever-they-call-it

User Documentation

First of all, our 0.0.1 release isn't really for getting work done, it was more just to put something out so people can see that:

That said, the documentation to install it is available on the OpenHaven Wiki, which also houses The Windows Documentation Project (forgive me for the shameless plug).

Developer Documentation

Again, I wouldn't recommend that you actually develop any modules for 0.0.1... it would be hard and incompatible with 0.0.2, but there is some basic developer documentation available. There has been much code clean-up since I posted it, however.

Future Development

Version 0.0.2 is nearing a preview release which will be, more or less, functional enough to use. After 0.0.2 I don't plan on doing anything more than cleaning up the code for a 0.0.3 release. At that point it will be able to accomplish the purpose for which I embarked on this journey and I'll let the OpenSource community take it from there.

The Concept

The idea here would actually be to create a network management system, but one that's first few plugins/modules address LTSP configuration. This software would be similar perhaps to webmin, but using MySQL / PHP scripts instead of perl and a much MUCH much prettier interface.

The idea would be to eventually include many of the features of these softwares:

And yet provide an interface that is as user friendly as these softwares:

And as free as this:

This document is copyright, all rights and intellectual property reserved Coolaj86.

that said, you can do anything with these ideas you want as long as it's opensource

and I only say that because I hardly know of any simple commercial software that does this and it would be terrible to see a company copyright code that does this and not give it back to the people who began with the idea. Any likeness of this idea to any commercial product is purely an accident.

Immediate Goal

This is something I would like to see happen quickly, not necessarily correctly. Just something that works to a minimal level.

User Interface

Three frames:

 ______________________________
| [LOGO]  GMNMS                |
| add quickview fullview config|
|                              |
|__________all__star__unstarr__|
|        |     INBOX           |
| MODS:  |                     |
| config | *dhcp.conf* 20050626|
| nodes  | lts.conf    20050625|
| groups | dhcp.conf   20050514|
| ltsp   |                     |
| dhcp   |         _archive_>> |
|________|_____________________|

Views

QuickView shows only very important information such as identifiers of groups or nodes (name, MAC, ipv4, location) FullView shows a more detailed view of each property of an object on per object basis. Add would allow you to add another object of that type Config would show you all of the most recent configuration files which rely on that object.

Navigation

Navigate based on what module you want to change

INBOX

showing all objects that pertain to a module, in the example above, that would be configuration files.

groups

Define one default group and several sub-groups, all of which have the default group or a sub-group as a parent. Non-node-spcefic information would go here (such as location). Nodes inherit properties from groups if their property is left undefined.

nodes

handles all nodes on a network and all information about them - dhcp, lts, etc.

dhcp

handles only dhcp related information about nodes and groups - ranges, hostnames, etc, etc

lts

handles only lts related inforamion about nodes - XF86CONFIG_FILE, XSERVER, MODULES, etc

handling boot images would be a task for a seperate module and would require a lot of system scripting (symlinking boot images, for example).

config

Every time you had a new object the database, a trigger should be made so that any affected configuration files become stared (no change would be made if the object simply went into the default group). They remain starred/bolded until 'commited', at which point they go into the database as archived configurations. The current configurations and any yet-to-be commited configurations would show up in the inbox.

For a module where there is no configuration file (ie, the module performs an action) this should show what actions would be made (ie, print out a bash script).

For now, lets just say that the configurations are copy-pasted by the admin

Roadmap

Core System

Right now, the upcoming 0.0.1 release will not be very modular at all. The immediate goal is for dhcpd.conf and lts.conf management. This, however, would be the goal:

The php scripting should probably be kept in the database eventually so that forms can be dynamically generated depending on what modules where installed, instead of static php forms.

(static php... what!? lol)


for each module, the software should be able to export a configuration file by first examining the groups for general rules and then the node-specific options to overwrite where necessary. mysql could keep copies of past configurations as full-text documents


Core Module

Information that would most likely be necessary for ANY network application. For now I'll assume nodes are worksations, this will need to be rewritten so that nodes only hold node info and that workstations or servers or switches could all have fields in the inventory module.

db tables / fields

Groups can belong to groups and any duplicate information should be resolved by the most specific information being used.

IE: The default group has dhcp options, the LAB group belongs to the default group, and a specific workstation happens to need a specific option that none else in the group does. The default settings should be read, replaced by the LAB settings (if exsiting) and then replaced by the workstation settings.

This order of updates might be done in a temporary table and then presented in the inbox as a configuration file.

dhcp module

First draft should just add a field for 'opts', later revisions should include fields for actual dhcp options and fine tune this and error check.

db tables / fields

forms

I imagine that this module would always be installed. Perhaps different modules could be created for different dhcp daemons.

ltsp module

First draft should just add a field for 'opts', later revisions should include fields for actual dhcp options and fine tune this and error check.

db tables / fields

forms

inventory module


Please improve it in any way that you see fit, and remove this notice {{Cleanup}} from the article. For tips on cleaning and formatting see Cleanup process


At the most basic level, we have the core system, inventory of nodes

All nodes have a unique ID which should be an auto increment ID, or the MAC address of the machine (though you might change the network card in a machine and not want to delete/recreate the machine in the database, so best to use UID.

give classes to nodes (perhaps each class would have a module)

if the class is PC, then it might have a manufacturer (a group) and peripherals, which would have classes such as monitor, sound card, network card, etc

However, it would be senseless to repeat the hardware information for a PC. If no value is set, it should be assumed to inherit the properties of it's group. So PCs would inherit what hardware it is assumed to have from being in a vendor/model group, and it's peripherals would inherit their information (chipset and such) from a similar group


wol module

not ltsp specific, no new plugs


probe module

This does not need to be ltsp specific but the ltsp module should add some options

  1. generate an ssh key for the apache user and place it in /opt/ltsp/sshd/.authorized_keys
  2. use the system() function of php to call ssh to run a script (LTSP client-side)
    • the script would go in /opt/ltsp/bin
  3. use scp to copy an output file (generated by the script) as ${HOST}.probe info
    • copy to public dir, maybe a /var/www/localhost/htdocs/ltsp/tmp

You could

this could also be done


kernel module

this should not be ltsp specific but installing the ltsp module should add extra options manage kernels of all machines on the network (noting if non-gnu)

Dependencies

Here's how I think this might work, considering the 'core inventory', and 'dhcp' modules conserning sql tables

Consider this: You want an inventory interface - the inventory could give you much detail - down to the serial number on every peripheral in a node - but you don't need all that detail, you select only the information you want to provide.

If you later were to install mod-joesoftware.gmnms that required that table and the system found that a module was already installed which could provide that table/row, then you would be given the option to install the additional tables from the providing module, or not install mod-joesoftware. If you did install the new table, then the interface for that table would appear in the main user interface for the providing module. Considering the idea of gmail like interface, if a thing was found to have an empty table which should not be empty - ie if you had core installed and wanted to install dhcp, core would have to install gmnms_node.node_ip, which dhcp needs, yet is empty - should be moved to the inbox for inspection. If you, from that point on, added a new module from the inventory interface, it would appear in the inbox. When clicked, the interface would call for the appropriate empty tables for each other module (just dhcp in this case) which needed information about that node before it was able to handle the node. Likewise, if the dhcp module interface were used to add a new ip address to the configuration, the message in the inbox would inform the user that core had created gmnms_node.node_pk when gmnms_node.node_ip was inserted into the table, but lacks needed information gmnms_node.node_mac.

Also, text-file configurations should appear is a section in the inbox to be approved before they are commited - IE after adding each node the same config message would appear in the inbox, but dynamically be updated when it was opened to include the new configuration. Say that 20 nodes where added to the network and you commit changes to 14 of them for all everything that they lack, 2 for most of the information they lack, but leave 4 untouched. The four untouched would show at the top of the inbox (most empty fields) and the dhcp configuration would appear in the inbox highlighting the addition of 14 new machines, and an ambigous 'range 192.168.1.200 192.168.1.206" for the machines it knows have been referenced, but can't place by mac address because the information doesn't exist.

This database structure isn't by any means normalized or complete, it's just an example of what it might look like:

mod-core.gmnms
 PROVIDE[]="gmnms_node.node_pk";
 PROVIDE[]="gmnms_node.node_mac";
 PROVIDE[]="gmnms_node.node_ip";
 PROVIDE[]="gmnms_node.node_serial";
 PROVIDE[]="gmnms_node.node_location";
 NEED[]="gmnms_node.node_pk";
 NEED[]="gmnms_node.node_mac";
 USE[]="gmnms_node.node_ip";
 USE[]="gmnms_node.node_serial";
 USE[]="gmnms_node.node_custom_fk";

mod-dhcp.gmnms
 PROVIDE[]="gmnms_node.node_subnet";
 PROVIDE[]="gmnms_node.node_bootkern";
 PROVIDE[]="gmnms_node.node_ntp";
 NEED[]="gmnms_node.node_ip";
 NEED[]="gmnms_node.node_mac";
 USE[]="gmnms_node.location";

obviously, dhcp should figure out which group a node belongs to. I think a node should be able to belong to more than one group, but it's primary group be used for the actualy configuration.

User Interface

I may gimp up a screenshot or two of gmail to try to express how I see the different modules being accessed and the creating of the user interface. My idea is that the interface should be terribly simple and easy to understand. I think that there is so much similarity between gmail's layout and functionality and the possible layout and functionality of this system.

Retrieved from "http://www.gentoo-wiki.info/GNU_Modular_Network_Management_System"
Last modified: Fri, 04 Jul 2008 06:52:00 +1000 Hits: 11,263

Created by NickStallman.net, Luxury Homes Australia
Real estate agents should be using interactive floor plans and real estate agent tools.