FW: OT: Integrating Directory Services for Linux

FW: OT: Integrating Directory Services for Linux

[Ron Van Dam]

IMHO, directory services for managing user accounts and permissions for
linux is pretty dismal at this point. I know there are userland projects
available for linux such as PAM and OpenLDAP, but they are relatively hard
to set up and get working and fall short on delivery. If anyone has worked
with Novell's NDS and tried emulate it with OpenLDAP and PAM you know what I
mean.

Has anyone thought much about integrating DS for Linux. I thought it would
be a real good idea to have a DS architecture built-in to linux to manage
just about everything, from user accounts, service configuration parameters,
mounts, kernel-modules, to function call security permissions. Having this
level of functionally would be a significant improvement for the
administrator who manages a large number of servers, especially for managing
Linux for Desktop users.

I know some one out there is comparing this concept to the Windows registry.
I was thinking that this would be a distributed database with journalling,
with all of the checks of a filesystem to protect the database. The database
would also need to be extensible so that userland developers can import
schema to extend the functionally of the database. For instance, the
database could be used to manage a DHCP or DNS server, or  storing your user
profile (.gnome or .kde) configurations. It should also support partitioning
if I have multiple sites connected by a WAN, I can partition the database
information so that only the essential information is replicated between
sites and the WAN isn't clogged with replication traffic.


Comments?


Thanks for reading this
Ron

Re: FW: OT: Integrating Directory Services for Linux

[Frank Schneider]

Ron Van Dam schrieb:
> 

(DS into Kernel for simplifying Management)

> I know some one out there is comparing this concept to the Windows registry.
> I was thinking that this would be a distributed database with journalling,
> with all of the checks of a filesystem to protect the database. The database
> would also need to be extensible so that userland developers can import
> schema to extend the functionally of the database. For instance, the
> database could be used to manage a DHCP or DNS server, or  storing your user
> profile (.gnome or .kde) configurations. It should also support partitioning
> if I have multiple sites connected by a WAN, I can partition the database
> information so that only the essential information is replicated between
> sites and the WAN isn't clogged with replication traffic.
> 
> Comments?

Hello...

Some comments, yes :

1.) Why add an extra-DS-System to the existing ones ?
We have OpenLDAP, NDS (going down), ADS (going up, pushed by MS) and
NIS+ out there, plus things like X.500 or how they are called. Currently
Linux can work with most of them except ADS, AFAIK (better or worse with
some, but it can)
Why re-invent the wheel a 4th or even 5th time ?
I would say that linux is best at working together with nearly every
other OS or sec-application, so i would suggest that it gets linux
further if these connections and capabilities are extended, and not by
re-inventing something like ADS...

2.) I think these DS-Systems are really a part of userland, and the
kernel itself should never mess around with high-level-security issues
like Access Controll Lists or such things...this is the job of
userlandtools.
The problem i see, if you force these things into the kernel, you will
get a significant performance impact, because if you start to do
(perhaps complicated) securitychecks *everytime* before calling a single
function, you will loose time...and performance is one of the points
where linux is ahead of other OSes, IMHO.

3.) To the idea of a "linux-registry":
I do not like this, UNIX lives now 30 years with /etc and human-readable
configfiles and without a "database", and i think its a good compromise
between usability and "keep-it-simple".
And it works.
We see at WinXY, what problems a "registry" produce, e.g. to be usefull,
*every* application would have to use it (in the right way!), and we
see, this does not work, even not under W2k, where MS should have all
possibilities to prevent applications from messing around with the
registry, but it is still possible to crash a W2k by simply deleting
some strings....

Solong..
Frank.

--
Frank Schneider, <SPATZ1@T-ONLINE.DE>.                           
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
... -.-

RE: FW: OT: Integrating Directory Services for Linux

[Ron Van Dam]

Frank Schneider:
>>1.) Why add an extra-DS-System to the existing ones ?
>>We have OpenLDAP, NDS (going down), ADS (going up, pushed by MS) and
>>NIS+ out there, plus things like X.500 or how they are called. Currently
>>Linux can work with most of them except ADS, AFAIK (better or worse with
>>some, but it can)
>>Why re-invent the wheel a 4th or even 5th time ?

 Using ADS or NDS is not a good solution, because in my opinion, it would be
dependent on a another OS. I would rather have the DS maintained on a
OpenSource OS. NIS+ is basically obsolete. OpenLDAP could be turned into a
workable solution, but there is no "consistent" bridge between OpenLDAP and
Linux. For instance if you want to manager user accounts with it you need
PAM, and unfortunately PAM isn't compatible with a lot of userland
applications and services.

In my opinion, I don't see any way for directory services to become a fully
enabled tool without full support from all of the major Linux development
groups. I believe its going require a lot of effort to to make it a reality.
I don't think DS will work unless there some standard for DS established by
the core linux development groups. Another words, what I would like have is
the framework for a standard for implemeting DS for Linux.

>> I think these DS-Systems are really a part of userland, and the
>>kernel itself should never mess around with high-level-security issues
>>like Access Controll Lists or such things...this is the job of
>>userlandtools.

Agreed, the database any other tools can be done in userland and should be.
I started this discussion to see if anyone out there considers DS important
for Linux growth.  I am not sugguesting that this should be in the kernel.
Just some sort of directory system that can manage configurations of a large
number of linux boxes.

However, I don't see how you can manage permissions to kernel function calls
with out some kernel support. Depending on what level of functionally is
included, there may be a need access database information during boot-up,
before userland processes can be started. If you managing kernel functions
calls for userland access, how can you tell if the process has permissions
unless some functionally is built-in the kernel? Think of a directory
service operating more like a file system than a database.

>>The problem i see, if you force these things into the kernel, you will
>>get a significant performance impact, because if you start to do
>>(perhaps complicated) securitychecks *everytime* before calling a single
>>function, you will loose time...and performance is one of the points
>>where linux is ahead of other OSes, IMHO.

You're probably right. Perhaps groups of function calls could be grouped and
other methods could be implemented to manage overhead, or shouldn't even be
considered. However, I believe  here is already some limited support for
this (RSBAC http://www.rsbac.org) and CAPs. Its just not supported in a
directory service.

>>3.) To the idea of a "linux-registry":
>>I do not like this, UNIX lives now 30 years with /etc and human-readable
>>configfiles and without a "database", and i think its a good compromise
>>between usability and "keep-it-simple".
>>And it works.

The Windows Registry isn't anything like what I am suggesting. The Windows
Registry isn't really even a database, is more or less an open draw, shoved
full of  bits and pieces of information everywhere. The Windows registry is
a lot like a /etc directory in non-human readable form. Every Windows box
has its own registry, just like every Unix box has a /etc directory. Think
of a directory service of more than a simple database and more like a shared
file system where you can access configuration information on any box from
any box you choose.

How would you manage 1000 or 10,000 desktop boxes each with their own /etc
directory?  Imagine your supporting several hundred or even several thousand
unix boxes, and you need to apply a standard change to all of them. Lets
also assume your not getting paid by the hour, or you need to get the change
done in just a hour or two. Would you trust a running a script on a
/etc/*.conf file to apply a change on your boxes? I suppose if you really
like to torture yourself, you could modify each of those files by hand,
ouch!

Thanks for the response.
Ron

Re: FW: OT: Integrating Directory Services for Linux

[Alicia Whisnant]

Ron Van Dam wrote:
>  Using ADS or NDS is not a good solution, because in my opinion, it would be
> dependent on a another OS. I would rather have the DS maintained on a
> OpenSource OS. 

That's just not true anymore, at least not for NDS.  Novell's latest
version (called "eDirectory" these days) runs very gracefully on Linux
(and solaris, too, FWIW).  It's possible to run an entire NDS
infrastructure with running netware these days.  This has been out for
quite awhile.
Go to this page and scroll down to "eDirectory", and you can download
and play with it yourself:
http://download.novell.com/sdMain.jsp
Note that the package also includes PAM login modules for linux.  Also
note full LDAP compatibility.

As a side note, novell has an intriguing metadirectory technology called
DirXML, which can glue any directory to any other directory with XML
templates.  You can use it to synchronize an Oracle table with an NDS
userlist, for example.

> NIS+ is basically obsolete.

Hrm, please qualify that.  Why do you think it's obsolete?  It's
considerably more advanced (and certainly more secure) than most of the
other options out there, including LDAP-over-SSL.  Just a bitch to
admin.

> OpenLDAP could be turned into a
> workable solution, but there is no "consistent" bridge between OpenLDAP and
> Linux. For instance if you want to manager user accounts with it you need
> PAM, and unfortunately PAM isn't compatible with a lot of userland
> applications and services.

PAM is the standardized and agreed-upon method for divorcing
authentication from the system.  It's been like that for quite some time
now.  What if this discussion was about some Linux GUI apps not being
compatible with X?  The boat's been sailing for quite some time, either
hop on or build your own, I say, or swim (sink?).

<snip>
> I don't think DS will work unless there some standard for DS established by
> the core linux development groups. Another words, what I would like have is
> the framework for a standard for implemeting DS for Linux.

What's wrong with the name service switch stuff?  and more importantly,
PAM?
The "PAM isn't supported by enough apps" argument is kind of weak. 
Reason being that the developer chose not to support it.  I for one
don't think the kernel should be modified just because Joe Blow
hardcoded open (/etc/passwd), or whatever.

<snip>
> I started this discussion to see if anyone out there considers DS important
> for Linux growth.  I am not sugguesting that this should be in the kernel.
> Just some sort of directory system that can manage configurations of a large
> number of linux boxes.

I personally believe that nothing will be so pivotal in a desktop war as
a good, unified directory.  Is the desktop a growth area for Linux?  You
betcha.  There are other areas (i.e. embedded) that Linux could benefit
from directories, too (think of a cellphone that anyone could use by
"logging into" it).

> However, I don't see how you can manage permissions to kernel function calls
> with out some kernel support. 

Pluggable Authentication Modules

> Depending on what level of functionally is
> included, there may be a need access database information during boot-up,
> before userland processes can be started. 

Who, besides root, would ever need to perform activities before userland
processes can start?

> If you managing kernel functions
> calls for userland access, how can you tell if the process has permissions
> unless some functionally is built-in the kernel? Think of a directory
> service operating more like a file system than a database.

Handled all by PAM and name service switch.

<snip>

> How would you manage 1000 or 10,000 desktop boxes each with their own /etc
> directory?  Imagine your supporting several hundred or even several thousand
> unix boxes, and you need to apply a standard change to all of them. Lets
> also assume your not getting paid by the hour, or you need to get the change
> done in just a hour or two. Would you trust a running a script on a
> /etc/*.conf file to apply a change on your boxes? I suppose if you really
> like to torture yourself, you could modify each of those files by hand,
> ouch!

Agreed, by hand it would be painful.  But why are scripts so scary? 
Just don't screw up :) .
I have played on a team which maintained 1000+ solaris and sunos
workstations, each with their own /etc, for a userlist > 7000 users. 
Everything (passwd, shadow, group, printcap, etc) lived in NIS. 
Individual changes to system files were made with rdist or cronjobs.  I
believe Linux+LDAP (or even NDS, because of the awesome performance)
would be much better suited to this task.

As long as you do enough testing, it's probably the ultimate way to
maintain lots of machines.  Again, note that this was done with an
obsolete (in my opinion, this time :) directory services (NIS).

> Thanks for the response.
> Ron

Thanks,
Josh

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: FW: OT: Integrating Directory Services for Linux

[Alicia Whisnant]

Ron Van Dam wrote:
>  Using ADS or NDS is not a good solution, because in my opinion, it would be
> dependent on a another OS. I would rather have the DS maintained on a
> OpenSource OS. 

That's just not true anymore, at least not for NDS.  Novell's latest
version (called "eDirectory" these days) runs very gracefully on Linux
(and solaris, too, FWIW).  It's possible to run an entire NDS
infrastructure without running any netware these days.  This has been
out for
quite awhile.
Go to this page and scroll down to "eDirectory", and you can download
and play with it yourself:
http://download.novell.com/sdMain.jsp
Note that the package also includes PAM login modules for linux.  Also
note full LDAP compatibility.

As a side note, novell has an intriguing metadirectory technology called
DirXML, which can glue any directory to any other directory with XML
templates.  You can use it to synchronize an Oracle table with an NDS
userlist, for example.

> NIS+ is basically obsolete.

Hrm, please qualify that.  Why do you think it's obsolete?  It's
considerably more advanced (and certainly more secure) than most of the
other options out there, including LDAP-over-SSL.  Just a bitch to
admin.

> OpenLDAP could be turned into a
> workable solution, but there is no "consistent" bridge between OpenLDAP and
> Linux. For instance if you want to manager user accounts with it you need
> PAM, and unfortunately PAM isn't compatible with a lot of userland
> applications and services.

PAM is the standardized and agreed-upon method for divorcing
authentication from the system.  It's been like that for quite some time
now.  What if this discussion was about some Linux GUI apps not being
compatible with X?  The boat's been sailing for quite some time, either
hop on or build your own, I say, or swim (sink?).

<snip>
> I don't think DS will work unless there some standard for DS established by
> the core linux development groups. Another words, what I would like have is
> the framework for a standard for implemeting DS for Linux.

What's wrong with the name service switch stuff?  and more importantly,
PAM?
The "PAM isn't supported by enough apps" argument is kind of weak. 
Reason being that the developer chose not to support it.  I for one
don't think the kernel should be modified just because Joe Blow
hardcoded open (/etc/passwd), or whatever.

<snip>
> I started this discussion to see if anyone out there considers DS important
> for Linux growth.  I am not sugguesting that this should be in the kernel.
> Just some sort of directory system that can manage configurations of a large
> number of linux boxes.

I personally believe that nothing will be so pivotal in a desktop war as
a good, unified directory.  Is the desktop a growth area for Linux?  You
betcha.  There are other areas (i.e. embedded) that Linux could benefit
from directories, too (think of a cellphone that anyone could use by
"logging into" it).

> However, I don't see how you can manage permissions to kernel function calls
> with out some kernel support. 

Pluggable Authentication Modules

> Depending on what level of functionally is
> included, there may be a need access database information during boot-up,
> before userland processes can be started. 

Who, besides root, would ever need to perform activities before userland
processes can start?

> If you managing kernel functions
> calls for userland access, how can you tell if the process has permissions
> unless some functionally is built-in the kernel? Think of a directory
> service operating more like a file system than a database.

Handled all by PAM and name service switch.

<snip>

> How would you manage 1000 or 10,000 desktop boxes each with their own /etc
> directory?  Imagine your supporting several hundred or even several thousand
> unix boxes, and you need to apply a standard change to all of them. Lets
> also assume your not getting paid by the hour, or you need to get the change
> done in just a hour or two. Would you trust a running a script on a
> /etc/*.conf file to apply a change on your boxes? I suppose if you really
> like to torture yourself, you could modify each of those files by hand,
> ouch!

Agreed, by hand it would be painful.  But why are scripts so scary? 
Just don't screw up :) .
I have played on a team which maintained 1000+ solaris and sunos
workstations, each with their own /etc, for a userlist > 7000 users. 
Everything (passwd, shadow, group, printcap, etc) lived in NIS. 
Individual changes to system files were made with rdist or cronjobs.  I
believe Linux+LDAP (or even NDS, because of the awesome performance)
would be much better suited to this task.

As long as you do enough testing, it's probably the ultimate way to
maintain lots of machines.  Again, note that this was done with an
obsolete (in my opinion, this time :) directory services (NIS).

> Thanks for the response.
> Ron

Thanks,
Josh

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: FW: OT: Integrating Directory Services for Linux

[Ron Van Dam]

Josh wrote:
>>That's just not true anymore, at least not for NDS.  Novell's latest
>>version (called "eDirectory" these days) runs very gracefully on Linux
>>(and solaris, too, FWIW).  It's possible to run an entire NDS
>>infrastructure without running any netware these days.  This has been
>>out for quite awhile.

I am fully aware of eDirectory. However, just like PAM, OpenLDAP, and other
add-on directory tools, it isn't fully adopted or utilized by all of the
Linux tools. Few if any OpenSource projects have embraced NDS. Maybe I'm
wrong, but I don't believe it would ever be adopted as a standard by the
Linux community.

>>Hrm, please qualify that.  Why do you think it's obsolete?  It's
>>considerably more advanced (and certainly more secure) than most of the
>>other options out there, including LDAP-over-SSL.  Just a bitch to
>>admin.

Your last sentence "Just a bitch to admin" sums it up pretty well.

> applications and services.

>>PAM is the standardized and agreed-upon method for divorcing
>>authentication from the system.  It's been like that for quite some time
>>now.  What if this discussion was about some Linux GUI apps not being
>>compatible with X?  The boat's been sailing for quite some time, either
>>hop on or build your own, I say, or swim (sink?).
<snip>
>>What's wrong with the name service switch stuff?  and more importantly,
>>PAM?

In my opinion PAM is a hack, and it breaks a compatibly with a lot of stuff
out there. I really don't care what technology is used to get the job done.
But as I said in a earlier post I don't see how DS can become reality unless
there is a standard supported by everyone.

<snip>
> I started this discussion to see if anyone out there considers DS
important
> for Linux growth.  I am not sugguesting that this should be in the kernel.
> Just some sort of directory system that can manage configurations of a
large
> number of linux boxes.

>>I personally believe that nothing will be so pivotal in a desktop war as
>>a good, unified directory.  Is the desktop a growth area for Linux?  You
>>betcha.  There are other areas (i.e. embedded) that Linux could benefit
>>from directories, too (think of a cellphone that anyone could use by
>>"logging into" it).

Exactly.

>>Who, besides root, would ever need to perform activities before userland
>>processes can start?

Perhaps the kernel? It depends on how deep DS plays a roll on Linux. With
CAP implemented you can lock down the system so that root can't even perform
some tasks.


> How would you manage 1000 or 10,000 desktop boxes each with their own /etc
> directory?  Imagine your supporting several hundred or even several
thousand
> unix boxes, and you need to apply a standard change to all of them. Lets
> also assume your not getting paid by the hour, or you need to get the
change
> done in just a hour or two. Would you trust a running a script on a
> /etc/*.conf file to apply a change on your boxes? I suppose if you really
> like to torture yourself, you could modify each of those files by hand,
> ouch!

>>Agreed, by hand it would be painful.  But why are scripts so scary?
>>Just don't screw up :) .
>>I have played on a team which maintained 1000+ solaris and sunos
>>workstations, each with their own /etc, for a userlist > 7000 users.

What if some less then enthusiastic has semi-mangled a /etc file. Can you
guarantee that the  script will correctly parse and modify it? Scripting
works fine if the machines are completely uniform, but I bet you there are a
lot of sysadmins that would be weary of perform a large scale change on
/etc/*.conf files.

I know I am going to get some dirty looks about this, but also consider the
scenerio that a larger company wants to move off of Windows to Linux for the
desktop. To start off most of your desktop support technicians will NOT be
capable of writing scripts to apply changes. With a DS system in place you
can create admin tools that dumb down the configuration. I know some people
will consider this a week argument,but its true. I believe that in order for
Linux to reach the desktop, there has to be a method to manage them easier
than the current available tools. I think DS is the best approach.

Thanks,
Ron

RE: FW: OT: Integrating Directory Services for Linux

[Nils Philippsen]

On Mon, 2001-09-10 at 13:50, Ron Van Dam wrote:
[snip]
> >>PAM is the standardized and agreed-upon method for divorcing
> >>authentication from the system.  It's been like that for quite some time
> >>now.  What if this discussion was about some Linux GUI apps not being
> >>compatible with X?  The boat's been sailing for quite some time, either
> >>hop on or build your own, I say, or swim (sink?).
> <snip>
> >>What's wrong with the name service switch stuff?  and more importantly,
> >>PAM?
> 
> In my opinion PAM is a hack, and it breaks a compatibly with a lot of stuff

Can you elaborate on that? IMO what PAM does is the only sensible thing
to do: abstraction of the authentication procedure. You cannot have
different authentication schemata (passwords (encrypted with Unix
crypt(), MD5, algorithm-of-the-month), smart-cards, biometrical
methods), multiple independently developed programs and stay sane
without such a thing as PAM in place. One can discuss _how_ PAM does
what it does, but _what_ it does only makes sense.

> out there. I really don't care what technology is used to get the job done.
> But as I said in a earlier post I don't see how DS can become reality unless
> there is a standard supported by everyone.

That won't happen. What you propose induces a single point of failure
where it isn't necessary. Personally I like that if something screws up
my nameserver configuration that I still can login -- this is one point
why I abhor anything remotely resembling to a registry, a centralized
configuration database (or directory if you wish). Think of what would
happen if some bits flipped in your directory and all of a sudden root
can't write to disk anymore (ok, I'm painting black here).

> What if some less then enthusiastic has semi-mangled a /etc file. Can you
> guarantee that the  script will correctly parse and modify it? Scripting
> works fine if the machines are completely uniform, but I bet you there are a
> lot of sysadmins that would be weary of perform a large scale change on
> /etc/*.conf files.

In that scale, any configuration files rolled out to my machines would
be generated from scratch, i.e. with templates or a similar technique.

> I know I am going to get some dirty looks about this, but also consider the
> scenerio that a larger company wants to move off of Windows to Linux for the
> desktop. To start off most of your desktop support technicians will NOT be
> capable of writing scripts to apply changes. With a DS system in place you
> can create admin tools that dumb down the configuration. I know some people
> will consider this a week argument,but its true.

You can even create "admin tools that dumb down the configuration" with
the current arcane method of plain ASCII configuration files. Not that
I'd like admins who need dumbed down configuration to administer my
machines. If you want working machines, you need skilled personnel to
operate them -- that's my opinion. If you have a network of NT machines,
you know a decent admin by his ability to script his tasks. Switching
from scripting on Windows to Unix/Linux shouldn't be hard, rather the
opposite.

> I believe that in order for Linux to reach the desktop, there has to be a
> method to manage them easier than the current available tools. I think
> DS is the best approach.

In order for Linux to reach the desktop, there is a lot to be done, but
I suspect it more in the areas of user interfaces (interoperability
between KDE and GNOME for instance, decent help systems),
interoperability with MS Office, games. The admin tools that exist now
are mostly sufficient when it comes to end users.

Nils
-- 
 Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
+49.7152.209647
nils@wombat.dialup.fht-esslingen.de / nils@redhat.de /
nils@fht-esslingen.de
        Ever noticed that common sense isn't really all that common?

Re: FW: OT: Integrating Directory Services for Linux

[Frank Schneider]

Ron Van Dam schrieb:
> 
> Frank Schneider:
> >>1.) Why add an extra-DS-System to the existing ones ?
> >>We have OpenLDAP, NDS (going down), ADS (going up, pushed by MS) and
> >>NIS+ out there, plus things like X.500 or how they are called. Currently
> >>Linux can work with most of them except ADS, AFAIK (better or worse with
> >>some, but it can)
> >>Why re-invent the wheel a 4th or even 5th time ?
> 
>  Using ADS or NDS is not a good solution, because in my opinion, it would be
> dependent on a another OS. 

Thats true, but imagine the following:
A company wants to switch from W2k to Linux (a case that will happen in
the future quite often, i hope).
What will be better, first only switching the OS (because Linux can
"talk" ADS or OpenLDAP), and in a second task switching the DS-service
(from ADS to OpenLDAP or whatever) or switching both at once ?
I think you would have enough to do in convincing the management of the
first solution...but the second one will most likely be dropped because
of the fear that the whole company cannot work anymore...:-)

The problem is at the moment, that every DS-structure wants to gain
access of the "core-tasks" like AAA (Authentication, Authoriasation,
Accounting), MS is pushing this because they think when their OS sits in
the middle, all the other servers have to move to W2k too.
Novell and OpenLDAP are likely doing the same, without the marketing
perhaps (OpenLDAP), but the target is also clear.

Why then move linux in a battle around these core-tasks by building an
owne DS-system ?
I would say that the way "we can replace it, and we are more stable,
cheaper and easier to manage" would be the better way.

> I would rather have the DS maintained on a
> OpenSource OS. 

This is a good start, but then we would have to ask us why we do not
increase support for OpenLDAP instead of rolling our own...


> NIS+ is basically obsolete. 

Dont say this...its the only way to get nearly all UNICEs into one
system...SUN can do OpenLDAP, like Linux, but HP-UX cant...if you have
HP-UX-Workstations, your only way is NIS(+)...

> OpenLDAP could be turned into a
> workable solution, but there is no "consistent" bridge between OpenLDAP and
> Linux. For instance if you want to manager user accounts with it you need
> PAM, and unfortunately PAM isn't compatible with a lot of userland
> applications and services.

But PAM is running quite long now, and i think it has a good structure
and is expandable...if the apps cannot work with PAM, we should change
the apps....and not throw away PAM...PAM is one of the things were Linux
is ahead of others...i can switch the authentication on my linuxbox from
/etc/passwd to an NT-Domaincontroller...AFAIK this can only linux (or
*BSD?)
 
> In my opinion, I don't see any way for directory services to become a fully
> enabled tool without full support from all of the major Linux development
> groups. I believe its going require a lot of effort to to make it a reality.

Ok, but building an own DS-system would be an effort too, or ?

> I don't think DS will work unless there some standard for DS established by
> the core linux development groups. Another words, what I would like have is
> the framework for a standard for implemeting DS for Linux.
> 
> >> I think these DS-Systems are really a part of userland, and the
> >>kernel itself should never mess around with high-level-security issues
> >>like Access Controll Lists or such things...this is the job of
> >>userlandtools.
> 
> Agreed, the database any other tools can be done in userland and should be.
> I started this discussion to see if anyone out there considers DS important
> for Linux growth.  I am not sugguesting that this should be in the kernel.
> Just some sort of directory system that can manage configurations of a large
> number of linux boxes.

BTW, there is already a tool to manage various *X-boxes...its called
"VENUS", but i do not know the manufacturer in the moment...my company
uses this, and it can do quite a lot...it depends on NIS.

(...ACL in Kernel..)
 
> How would you manage 1000 or 10,000 desktop boxes each with their own /etc
> directory?  Imagine your supporting several hundred or even several thousand
> unix boxes, and you need to apply a standard change to all of them. Lets
> also assume your not getting paid by the hour, or you need to get the change
> done in just a hour or two. 

Have a look at this VENUS-system, it can do this...and it can do this
across various *X-plattforms, and thats a point we also have to keep in
mind: We as linux will have always other *X beside us, and therefore we
should have a eye not only on the Win-side, but also on the *X-side...

Would you trust a running a script on a
> /etc/*.conf file to apply a change on your boxes? I suppose if you really
> like to torture yourself, you could modify each of those files by hand,
> ouch!

Ok, i did not run scripts over linux-boxes, but i ran scripts over some
hundred network-components (cisco switches) and it always worked for
me...but it is a risk, thats clear, but if you get 80-90% done with a
script, and the rest by hand, it is a success...trying to get 100% with
one script/solution is a kind of dreaming IMHO...
 
Solong..
Frank.

--
Frank Schneider, <SPATZ1@T-ONLINE.DE>.                           
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
... -.-

Re: FW: OT: Integrating Directory Services for Linux

[Horst von Brand]

SPATZ1@t-online.de (Frank Schneider) said:

[...]

> The problem is at the moment, that every DS-structure wants to gain
> access of the "core-tasks" like AAA (Authentication, Authoriasation,
> Accounting), MS is pushing this because they think when their OS sits in
> the middle, all the other servers have to move to W2k too.
> Novell and OpenLDAP are likely doing the same, without the marketing
> perhaps (OpenLDAP), but the target is also clear.

LDAP is an _open_ standard by the IETF, OpenLDAP is an _open source_
implementation of the above.

Sure, it would be nice if Linux runs every DS under the sun, but AFAICS it
should concentrate on open standards.
-- 
Dr. Horst H. von Brand                Usuario #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: FW: OT: Integrating Directory Services for Linux

[Albert D. Cahalan]

> 3.) To the idea of a "linux-registry":
> I do not like this, UNIX lives now 30 years with /etc and human-readable
> configfiles and without a "database", and i think its a good compromise

1. NeXT, nextstep, openstep, Darwin, MacOS X   (netinfo)
2. AIX
3. SuSE (YaST junk, etc.)

Note: not saying if it is good or bad, just that it is.

Reiserfs seems to be headed toward handling this sort of thing.
Head over to www.namesys.com sometime and check out the weird ideas.

RE: FW: OT: Integrating Directory Services for Linux

[Ron Van Dam]

Chris Siebenmann wrote:
>> What if some less then enthusiastic has semi-mangled a /etc file.

> Then the registry breaks in the same way. There is always something
>that someone can do to screw the machine up; moving where most of the
>data is stored doesn't change that. At most it reduces the number of
>knobs someone can break off.

Not true. First I would like to say the a directory service isn't a
registry. It's a database to store information in a organized system. There
is nothing organized about the windows registry! The window registry is
nothing more than a huge INI file with bits and pieces of information
everywhere. It has no schema to pervent anyone from adding an bits of
information anywhere they want.

With a text file I can put anything in it. I can make a 100 MB resolv.conf
file if I wanted too. With a structured schema, the configuration can pretty
much be locked down what information is summitted or changed.

> No one dealing with a large collective of Unix machines is managing
>them on a one-by-one basis. They are driving configurations out of a
>central system for managing them, in some form or way, and if they have
>any sense individualization is strongly discouraged if not exterminated.
>(There are some quite elaborate systems for doing this, going so far as
>to store everything in SQL databases. See various LISA proceedings.)

Do you see DS as a bad thing for Linux? Tell why you think having a DS
system for Linux would be a terrible waste?

Thanks,
Ron