The Strengths and Weakness of Fedora/RHEL OS management

Shane Stixrud shane at geeklords.org
Thu Mar 30 19:58:22 UTC 2006


On Thu, 30 Mar 2006, sean wrote:

> For ad-hoc interactive usage that looks worse than what we have today;
> call up a config file and page through it to see the information you want.

It is but one possible example.  My point is how the keys and values are 
formated is flexible, the hierarchical key/value pair storage medium contains 
all of information required to recreate the dhcpd.conf file in its 
entirety.  The key descriptions and user comments can be stored as "files" 
associated with these same directories/keys and then compiled+arranged on 
demand for user consumption.

Perhaps this example is more to your liking?:

cfg_mgr --interactive

display -embed -nodesc -comments /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*

10.202.46.0-24 {
    # User comments go here
    use-host-decl-names = on
    }

    options {
       # User comments go here
       log-servers = 10.202.46.2, 10.202.46.3
       }

    hosts {
       ws001 {
          # User comments go here
          fixed-address = 192.168.0.1
          # User comments go here
          default-lease-time = 10000
 	 # User comments go here
          filename = /lts/vmlinuz-2.4.26-ltsp-1
 	 # User comments go here
 	 hw = ethernet:00:11:22:33:44:55
        }
    }
}

> But the difficult issue isn't really what tools might be possible after
> a unified config system is in place.   Rather, it's how to get enough
> apps to use the config system in the first place.   My own view is that
> concentrating on the needs of _developers_ not users and sysadmins
> is the way to success.   The user and admin tools are the easy part.

I agree the tools shouldn't be the focus, my point though is the with the 
right storage design / medium existing tools would be usable.

Cheers,
Shane




More information about the fedora-devel-list mailing list