[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management)

On 4/5/06, Davide Bolcioni <db-fedora 3di it> wrote:
> As a sysadmin I might be a part of the vocal minority, and I actually agree
> that many of the problems you want to address are there and need to be
> addressed - it's just that, and I believe many of the others are
> actually trying to say just this, the proposed vision carries along a
> price we're not willing to pay.

A useful cmdline tool to interact with dbus would go a long long way. 
Something for dbus which is at least as functional a tool as gconftool
is for gconf.

A cmdline tool that exposed introspection as to what methods were
available over the
bus so admins can ask questions with regard to what clients and
methods are currently active on the bus and introspection per method
so we can ask what arguments a particular method takes without having
to dig up an API document PER DBUS CLIENT to figure out what methods
take what arguments PER CLIENT. To make use of dbus and anything which
is expected to communicate over dbus I need a tool designed to
navigate the dbus space on the cmdline.  Something I can use to
explore the space, discover which services are available and how to
communicate which each service, so I can then script actions or fire
off individual actions over remote concole connections if required.

dbus-send right now allows me to script actions across dbus, but
without the introspection tool to explore the space dbus will continue
to be under utilized for sysadmin actions... and thats going to be a
big big problem moving forward. Because as more services expect to be
controlled over dbus, admins will be using other approaches they are
more comfortable with because the minimal set of cmdline tools to
interact with dbus are not available.

dbus definitely has potential as a very powerful sysadmin oriented
technology. It's certaintly not a bad technology but it needs a
cmdline oriented interface with introspection to be approachable
enough for sysadmins to start working with it to solve their specific
local policy/action needs.  I encourage everyone to take a look at the
oddjob package in Extras to see one direction in which dbus can be
taken to morph it into something useful for a sysadmin.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]