Very Computer

I've been dabbling with the idea of starting an open source project to
provide a system administration tool for Linux, FreeeBSD and other
platforms.  I've heard about similar commercial ventures by IBM, Sun,
and others, but have not found an open source project that quite fits
the image I have in my head.  I am imagining a system written in several
layers.  From the bottom up they go like this:

1) An admin library.  This supplies a standard set of function calls
   that do things like add/modify/delete a user, configure printers,
   tweak network settings in the rc scripts, etc.  This library provides
   the platform specific part.  It should include functions for querying
   about the operating systems capabilities and features (i.e. we shouldn't
   display a DNS admin option if the box doesn't run a DNS).

2) A server.  Your basic TCP daemon that talks to a client piece and
   includes support for robust user authentication and encryption of
   the data stream.

3) A standardized protocol for talking between the client and server.  It
   should be inherently extensible, allowing new features to be added to
   client and server without redefining the protocol.

4) The client piece.  I envision a Java app to start with, partially
   because of the cross-platform development benefits, but mainly
   because I want an excuse to program in Java.  :-)  There is no reason
   that various client versions could not be written, so if you want a
   admin tool that integrates with the KDE desktop or whatever, it should
   be easy to do.

Directory services (X500 style, like NDS) should be kept in mind while
designing this beast.  Any good open source directory service projects
or resources I should know about?

It should be easy to plug new feature sets into the system (like an
apache admin set for example).  Any thoughts on the best way to
facilitate that?

Are there any *cross platform* projects like this already begun?

What about the client/server protocol?  Any existing protocols I should
look at or build on top of?

My reference platforms will be Linux and FreeBSD, but the app should
port easily to other platforms.  It has been inspired by a bunch of
ugly hacks I pieced together here at DIAS to make the admin of our
servers easier for the non-technical staff.  I've been telling myself
for a while that I would throw the current mess out and do it *the
right way*.  I plan on implementing a trimmed down version of all four
layers and then release it as open source for further development.
right now I am collecting info for the basic design.  Any input will
be greatly appreciated.

--
Thad Phetteplace
President - DIAS, Inc.

posted:

Quote:>I've been dabbling with the idea of starting an open source project to
>provide a system administration tool for Linux, FreeeBSD and other
>platforms.  I've heard about similar commercial ventures by IBM, Sun,
>and others, but have not found an open source project that quite fits
>the image I have in my head.  

I take it that neither COAS nor Linuxconf are suitable to your purposes?

--
Those who do not understand Unix are condemned to reinvent it, poorly.  
-- Henry Spencer          <http://www.hex.net/~cbbrowne/lsf.html>

Quote:> Are there any *cross platform* projects like this already begun?

Had a look at GNU cfengine?
--
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator
"Xerox studies suggest that most people print out electronic mail
 that is longer than half a page; paper use rises by 40 percent in
 offices that introduce E-mail." -- CCM

|
| I've been dabbling with the idea of starting an open source project to
| provide a system administration tool for Linux, FreeeBSD and other
| platforms.  I've heard about similar commercial ventures by IBM, Sun,
| and others, but have not found an open source project that quite fits
| the image I have in my head.  I am imagining a system written in several
| layers.  From the bottom up they go like this:
|
| 1) An admin library.  This supplies a standard set of function calls
|    that do things like add/modify/delete a user, configure printers,
|    tweak network settings in the rc scripts, etc.  This library provides
|    the platform specific part.  It should include functions for querying
|    about the operating systems capabilities and features (i.e. we shouldn't
|    display a DNS admin option if the box doesn't run a DNS).
|
| 2) A server.  Your basic TCP daemon that talks to a client piece and
|    includes support for robust user authentication and encryption of
|    the data stream.
|
| 3) A standardized protocol for talking between the client and server.  It
|    should be inherently extensible, allowing new features to be added to
|    client and server without redefining the protocol.
|
| 4) The client piece.  I envision a Java app to start with, partially
|    because of the cross-platform development benefits, but mainly
|    because I want an excuse to program in Java.  :-)  There is no reason
|    that various client versions could not be written, so if you want a
|    admin tool that integrates with the KDE desktop or whatever, it should
|    be easy to do.
|
| Directory services (X500 style, like NDS) should be kept in mind while
| designing this beast.  Any good open source directory service projects
| or resources I should know about?

Yes, as a matter of fact.  We've been working for the last 3 years on just such
a beast.  It's called Ganymede, and you can read about it at

 http://www.arlut.utexas.edu/gash2

It's written in Java, is client/server, has a built in object database
and support for pluggable Java classes for object management.  The
database schema is editable using a GUI editing tool.  It is not X.500
or LDAP based, and it is only designed to handle on the order of
50,000 records, but it works well.

I'm going to be presenting the work at this year's LISA conference
next month up in Boston.  You can read a preprint of our paper for
LISA at the bottom of the aforementioned web page.

Note that we are still working on getting approval for releasing the
project under the GNU General Public License.  If you sign up for the
development mailing list, you'll get an informative message which
includes directions on downloading the system via ftp.  Right now the
developer's pre-release does not include most of the system's source,
but it does include full javadocs and source code for all of the
customization classes.

The system is in late beta.. we'll probably put out Ganymede 1.0
within the next month or so, assuming approval for GPL licensing goes
through.

| --
| Thad Phetteplace
| President - DIAS, Inc.

|

--
-------------------------------------------------------------------------------

Applied Research Laboratories                 The University of Texas at Austin
-------------------------------------------------------------------------------

Quote:

> I take it that neither COAS nor Linuxconf are suitable to your purposes?

Thanks for the pointer to COAS.  It comes closest to what I am shooting for.
It might be possible to build the client/server layer as an extension on top
of the COAS API.  I will need to investigate it more to see what extent
I can build on top of or at least interoperate with COAS.  Also, thank you
to everyone else who has posted or emailed responses.  There have a great
many useful suggestions and pointers to related projects.  I am drafting
a preliminary design doc that I will publish to a web page.  Your feedback
is appreciated.

Thanks,

Thad

Please, for the sake of all programmers, PLEASE release it under the
BSD license...

--

America: where you're free to do as you're told.

|
| >
| > Note that we are still working on getting approval for releasing the
| > project under the GNU General Public License.  If you sign up for the
|
| Please, for the sake of all programmers, PLEASE release it under the
| BSD license...

Wow, that's a pretty dramatic plea.  What would be the benefit of
doing so?

| --

| America: where you're free to do as you're told.

--
-------------------------------------------------------------------------------

Applied Research Laboratories                 The University of Texas at Austin
-------------------------------------------------------------------------------

The benefit of doing so is that we, as programmers, are not restricted
by the GPL source "requirements", etc...  And commercial developers
*also* will be less likely to be scared away by the open-source
"requirement" of the GPL.

Say I created a program based on this project.  If it's GPL, I *have*
release my code as GPL (or parts that are derived from the original
code) whether I like it or not.  So much for consistency.  So much for
standards.  

GPL is "restrictively unrestrictive".

--

Please don't email replies to Usenet postings.

This is all very true.  But consider this from a certain Linus Torvalds
(paraphrased, of course):

"He who writes the code decides the license.  Anyone else is just a
whiner."

If the author of the administration tool suite decides to release under
the GPL, more power to him.

----------------------------------------------------------------------
Phil Brutsche

"Be of stout heart, Number One.  We've handled the Borg.  We can
certainly handle Admiral Jellico." - Jean-Luc Picard

Help stop spam!  Visit http://www.cauce.org
----------------------------------------------------------------------

        That doesn't slow down the industry in console *
        one bit. While a pure GPL has it's problem, LGPL quite
        adequately addresses them. Whining that the GPL needs
        to be replaced with the BSD licence is deceptive at best.

Quote:

>Say I created a program based on this project.  If it's GPL, I *have*
>release my code as GPL (or parts that are derived from the original
>code) whether I like it or not.  So much for consistency.  So much for
>standards.  

>GPL is "restrictively unrestrictive".

        Then don't muck about with the sourcecode. It's typically
        not good programming practice anyways.

--
Unix had  startmenus and tasbars before Microsoft          |||
even had a decent memory manager for DOS.                 / | \

        In search of sane PPP docs? Try http://www.veryComputer.com/

| >
| > Wow, that's a pretty dramatic plea.  What would be the benefit of
| > doing so?
|
| The benefit of doing so is that we, as programmers, are not restricted
| by the GPL source "requirements", etc...  And commercial developers
| *also* will be less likely to be scared away by the open-source
| "requirement" of the GPL.
|
| Say I created a program based on this project.  If it's GPL, I *have*
| release my code as GPL (or parts that are derived from the original
| code) whether I like it or not.  So much for consistency.  So much for
| standards.  

Of course, that doesn't bother me a great deal, in principle.  In
practice, I can see how one might want to be able to write a
commercial utility that would talk to the Ganymede server, yet would
be forced to be GPL'ed, as there are certain classes that would have
to be bound to the client.

| GPL is "restrictively unrestrictive".

Of course, that's the point.  In any case, I don't speak for the
university or their lawyers, and they are the ones who set the
guidelines for what sort of licensing is acceptable in this situation.

| --

| Please don't email replies to Usenet postings.

--
-------------------------------------------------------------------------------

Applied Research Laboratories                 The University of Texas at Austin
-------------------------------------------------------------------------------

Because its an extremist position and hinders code use and re-use.  It
also gives the unwashes masses the impression that "free software authors"
are not writing software for the benefit of mankind, but to further a
strange and extreme political agenda (to them).

And to those who write free software to be used by all regardless of
purpose, it fosters ill-will and makes people suspicious your good intentions.
Which is not a problem if that does not bother you.  Some people think that
software hoarding is a good strategy to use against software hoarders.

Jeremy
--

Four
Lines
Suffice.

What the * are you talking about?   Sorry for the language, but the
GPL does block use in console *, and when I did console
programming, this did occasionally slow me down.

As for LGPL 'adequately addresses them': Talk to FSF about accepting
use of shared libraries as OK under the LGPL, then come back and
repeat that statement.  Oh, and look at modern compiler technology,
and how the LGPL 'adequately address that'.  The LGPL is a minefield;
proprietary developers with a clue will consider LGPLed code as if it
was GPLed, keeping it far away from their programs unless they can use
the fact that interfaces can't be copyrighted to keep it clean.

Eivind.

        It doesn't slow us down a bit. It doesn't slow Applix down
        a bit. It doesn't slow Oracle down a bit. It never slowed
        Corel down a bit. It didn't slow down ID or Origin.

        Commercial software can and does link to lgpl libraries to
        their hearts content on a regular basis.

        You're just spreading FUD & rather pathetic FUD at that given
        the wealth of counter examples.

--
Unix had  startmenus and tasbars before Microsoft          |||
even had a decent memory manager for DOS.                 / | \

        In search of sane PPP docs? Try http://www.veryComputer.com/

Listing companies that have been careless does not consist proof that
they're not careless.  And saying "it didn't slow down" requires exact
knowledge of the development processes; I doubt you have that for all
those companies.  You're spreading unfounded claims and muddling the
issues.

Quote:>    Commercial software can and does link to lgpl libraries to
>    their hearts content on a regular basis.

... just as they could link to GPLed libraries to their heart's
content; they just might get trouble afterwards.

Clue:
* The GPL is not infective over an interface boundary, as interface
  copyrights have been rejected by the courts.
* The LGPL is not infective over an interface boundary, due to the
  license text and that interface copyrights have been rejected by the
  courts.
* Use of a shared library may or may not be an interface boundary, due
  to problems with linker & compiler technology that may in some cases
  push library code into the executable, even for shared libraries.

My view is that the GPL does cover its goals nicely, is pretty
explicit about it, and should not be a problem for somebody that is
careful about licenses.  I think they are wrong goals for a lot of
cases, but that is another discussion.

LGPL, on the other hand, is a dangerous license because a lot of
people seems to think it is different from the GPL.  It is not.  Due
to the precedents in the area, the LGPL and the GPL have just about
the exact same effect, except that the LGPL is more explicit in
denying people the ability to create 'work-around-the-GPL' interfaces
(something which may or may not hold up in court).

IMO, the closest you get to a 'GPL-like' license for libraries that
also allow safe commercial use is something like the Eiffel Forum
License.  This require you to distribute sources to the library if you
make modifications to it, but allow free use otherwise.  I think this
is a fair way of doing it.

Quote:>    You're just spreading FUD & rather pathetic FUD at that given
>    the wealth of counter examples.

Where are your legal precedents (not examples of companies) for your
claims?  What you've come with so far is examples that some companies
ignore the problems (I believe this is due to not even considering the
problems with shared libraries, which again is due to the GPL crowd
pushing these issues under the carpet).  You've done nothing to
substantiate your claim that 'the GPL does not slow down the industry
in console * one bit' [SIC] which I debunked by pointing out with
an example of it slowing console * down, and you've not done
anything to substantiate your claim that the LGPL adequately addresses
the problem with executables being 'derivative works'.  (The problem
is blatantly obvious in C if you have macros or inline functions; it
can be present in other cases, too.)

Oh, and please de-fake your address.   Fake addresses have no place in
serious discussions.  (No, mine is not fake; I can't remember ever
having used a fake address.)

Eivind.