Fedora Directory Server 1.0 Released!

LnxAddct writes "NewsForge is reporting that the first official release of the Fedora Directory Server has been announced. This is good news for members of the open source community longing for an easy to use, enterprise class directory server. Fedora Directory Server is based off of Netscape Directory Server which Red Hat purchased a year ago and released as open source. Screenshots are available on their site." NewsForge is a Slashdot sister site.

Comments

command line

[Darkon]

A fancy GUI is all very well, but does this come with some decent command line tools to scriptify adding and removing users and the like? One of the things that's kept my department on NIS for so long is that absolute hideous unfriendliness of the OpenLDAP tools vs useradd, usermod and friends.

Re:command line

[Anonymous Coward]

In short: Yes.

However, I find it interesting that you describe OpenLDAP as "absolute hideous unfriendliness" when it simply isn't that case. Granted that the ldif format isn't obvious or familiar, using the command lines tools is actually rather simple. You only need to understand how an LDAP Directory works, and how your schema of choice is laid out.

I have personall written a front end for managing userspace in OpenLDAP via bash scripts, and I can tell you that once I spen a hour reading up on ldif, it was really quite simple.

Re:command line

[digitalhermit]

The addition of a user is pretty simple... Just run ldapadd against an ldif file. To create the LDIF file is simple and you can do it with a perl script to specify username, userid and password. To create the password you can use crypt or md5. Something like:

    my @validsalt = ('a' .. 'z', 'A' .. 'Z', 0 .. 9, '.', '/');
    my $salt = $validsalt[rand(64)] . $validsalt[rand(64)];
    my $test = crypt($cleartext, $salt);

Of course, you'd also want to do some basic validation of the inputs. Then just wrap the user inputs in an LDIF template and run. It sounds a lot more difficult than it actually is.

The schema can actually validate that userid is unique, but you should check anyway and also validate the groups and gids.

Re:command line

[Anonymous Coward]

It is so totally NOT built on top of OpenLDAP. In fact, it share not code with OpenLDAP at all. Thanks for playing.

Re:command line

[pe1chl]

The main gripe is that you have to kludge all this yourself.
Every admin in the world must write his or her own script to add a user to the directory.

Why can't we have ready-made programs that perform such simple tasks?
Like useradd, for example.

Re:command line

[labratuk]

Thankyou. This is the first thing I noticed too. Obviously something that hasn't changed since its netscape days when they needed to be able to show something to PHBs who made purchasing decisions. A big dumb 'START SERVER' button. Please god let them unix-ise the software in the next few versions.

Re:command line

[digitalhermit]

LDAP itself is not *just* for authentication, though that's one of its more popular uses. That's probably why there are not so many specific auth related tools. It's a similar thing with the more decoupled Linux LVM versus, for example, AIX's tightly integrated LVM. There are GUI tools such as JXplorer and lots of Java based apps that can add/modify entries. JXplorer, for example, can define template screens so that you can view only auth relevant parts of the schema.

Re:command line

[aaronl]

You could use the IDEALX smbldap-tools for the scripts and all. That would give you UNIX and Samba authentication and user account information, and control over groups, as well as a simple command line tool for passwords.

Re:command line

[LnxAddct]

Don't worry, all the command line tools are there too, a nice GUI never hurt anyone though:)
Regards,
Steve

Re:command line

[illumin8]

A fancy GUI is all very well, but does this come with some decent command line tools to scriptify adding and removing users and the like? One of the things that's kept my department on NIS for so long is that absolute hideous unfriendliness of the OpenLDAP tools vs useradd, usermod and friends.

Have you heard of ldapadd and ldapmodify? These tools are available from OpenLDAP or from pretty much any OS that is LDAP capable. I know you're probably just trolling but it's quite obvious you've never used LDAP or you'd know that it's trivially simple to add or modify entries using these command line tools.

Re:command line

[pe1chl]

As you may know (being such a wiseguy) writing a small script and releasing it to the community does very little towards making a feature available to Linux.
There are so many distributions around and so many different approaches to the same thing at this level, that there is nothing you can do as an individual.

I have written and released free software. I have written dedicated scripts to use LDAP in the company where I work.
Comparing to the competition, I think the integration of LDAP into Linux is quite far behind. Building blocks for a lot of features are available, but it is just not practical to put it all together and have a working system without 3 months of study and coding.

This is not something an individual can solve by writing some scripts and throwing them on freshmeat.

Re:command line

[Seumas]

That's hardly a "fancy GUI". It's exactly the same GUI from Netscape/iPlanet/Sun ONE Directory Servers since, I dunno, about 2000.

And yes there's a command line tool for adding and removing users in all of the above. It's called LDAPMODIFY. Want it to work like a script? Write one that uses LDAPMODIFY . . . It's nothing complex.

Re:command line

[Fyre2012]

Don't people who do write software want people who don't know how to write it to still use it?

I'm a typical web admin, so can i really afford to take time to write all the scripts to make this work? Hell no.
that said, do i still want to use it? ABSOLUTELY!
Don't know how to code? LEARN

just brilliant. What a great way to entice the MS users of the world to switch ro an FOSS solution! Fanatical support from people who care! /sarcasm

Re:command line

[curd]

One word: Net::LDAP. If you know a little bit of perl, this can be of huge help. It's well documented, has a pretty complete implementation of the ldap v3 specs, and works well with any vendor soft. Once you have a couple of working scripts, you can whoop your own tools in a matter of minutes, and coupled with cgi, you're halfway towards your own user admin gui, or a white pages application. I use it all the time at work, and it's been a lifesaver. (especially since the Netscape/iPlanet/whatever gui isn't the most user friendly...

Re:command line

[dtfinch]

For some people, "absolute hideous unfriendliness" means you have to read documentation, as opposed to the program having a nice GUI interface that is comprehensive, intuitive, obvious, and familiar to a new user.

Re:command line

[Kent Recal]

Well, LDAP, in all it's shapes and forms is absolutely hideous and unfriendly.
Its age shows, it's software from "way back".

LDAP is one of the architectures that would really be worth reinventing.
Imho the main reason why we still don't have "easy" single-signon in unix-land is because
the only available route nowadays leads through LDAP- and kerberos-land which both do their particular
job well but are such a pain to setup, maintain and integrate with that only the bravest and most fearless
sysadmins dare to walk it.

Re:command line

[punkass]

I'm a typical web admin, so can i really afford to take time to write all the scripts to make this work? Hell no.

If you don't have time to administer your web server, what the hell are you doing all day at your web admin job?

Re:command line

[chrome]

For those wishing an easier way to manage their userbase in their LDAP directory:

http://phpldapadmin.sourceforge.net/

wow

[know1]

redhat bought something usefull and made it open source? that's one of the most amazingly good things i've heard this week. i thought open source was all about using software made for free. it's so great to see a xcompany making a living off open source to buy something usefull the community needs and give it out for free. i'm a debian man myself, but keep up the good work redhat!

Re: wow

[Dolda2000]

This isn't exactly the first time RedHat has done something like this. Last year, they also bought Sistina and released GFS for free. I think they have done other such things as well, but I can't remember any off the top of my head.

Re:wow

[TheRaven64]

As another poster pointed out, Sun have done this with other things as well. One example that I suspect a lot of /.ers are familar with is Cygwin - bought be RedHat and open sourced. They are also not the only company to do this. Sun bought a German outfit called Star Division and released their flagship product as open source, and continue to supply most of the developer time to it. You might have used that too.

Re:wow

[LnxAddct]

Heh, you severly underestimate Red Hat's contribution to the community:) Read this for a truncated list of contributions they've made. Some other products they've purchased and released include GFS, Cygwin, and eCos. They also contribute more code to the kernel than any other entity and in large part maintain and extend glib and GCC (they have a few people on the GCC board and contribute huge amounts of code, in fact many of the newest features in GCC 4.0.x you can thank Red Hat for). Here is another list, but that list is only for projects hosted from that site, so its not complete either, but suffice it to say that Red Hat does a staggering amount for the community, its kind of a shame when people bash them.
Regards,
Steve

Re:wow

[Trogre]

Being a Debian man too, I'm wondering how long it will be until we can apt-get install this program...

Re:wow

[Ben Hutchings]

Some other products they've purchased and released include GFS, Cygwin, and eCos.

Cygwin and eCos (and, I think the majority of GCC 2.0) were developed by Cygnus, which Red Hat subsequently bought.

... Red Hat does a staggering amount for the community, its kind of a shame when people bash them.

Indeed. It's just their distributions that suck.

+ Kerberos ?

[ratatask]

One of the net things is if you couple together Kerberos with LDAP - much like a windows network
with Active Directory.
Does the Fedora DS intergrate those two neatly, single sign on is neat, but OSS provides
no turnkey solutions for this (yet).

Re:+ Kerberos ?

[Dolda2000]

but OSS provides no turnkey solutions for this (yet).

Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these. Updating your LDAP, Kerberos, NSS and PAM configs manually isn't exactly hard as it is. If you want to make it easy to set up multiple workstations with this setup, just use Kickstart (or a shell script on NFS...).

Really, I'm not trying to troll here, I'm just really not seeing what this need to click a single button for every possible setup comes from. Rather than trying to provide every possible setup from the start, as Microsoft does (and which much of the complexity in Windows derives from), isn't it better to have a generic solution that can be tailored to one's specific need, instead?

Re:+ Kerberos ?

[adrian.henke]

I set up OpenLDAP as backend for the heimdal kerberos, so i guess you can do the same with FDS even though its not an official feature.

Re:+ Kerberos ?

[cerberusss]

I've never understood why people need "turnkey solutions" for things like these.

It's one possible measure for the amount of care that's put in the product. You can say this doesn't go for this particular product, but lots of times adoption of a product starts with someone who has 15 minutes of spare time.

If the product doesn't show a few nice things within those 15 minutes, it just might be possible it's not looked further into.

I'm not saying this is the correct procedure to evaluate an important piece of software like an LDAP server, but I'm certain this scenario really happens.

Re:+ Kerberos ?

[CRC'99]

Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these.

Yeah, because it's not like this is a well used 'feature' in Windows Domains in just about every large company...

Re:+ Kerberos ?

[moreati]

Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these.

Largely, I think it boils down to - 'because they don't understand the technology as we do'. Take a simple, high level requirement: identity management. You or I might see that in terms of the components: such as a directory, an authentication service, creation & removal scripts, some means of replication, monitoring scripts etc.

A $notnerd sees the requirement as a black box, they don't care about the internals. They've probably been told by some techie/salesman that it will address some problem they have. For this person turnkey seems perfect, $company sells $product which is billed as an 'identity managment solution'. A magic black box solution to a black box problem, their work is done - now it is IT's problem.

Updating your LDAP, Kerberos, NSS and PAM configs manually isn't exactly hard as it is. If you want to make it easy to set up multiple workstations with this setup, just use Kickstart (or a shell script on NFS...).

To you it isn't, but what happens when you leave? It's much easier to recruit someone to maintain a push button solution, than a partly bespoke ecology of components and scripts. Often the solution and the ecology are similar in complexity, but the solution hides that behind a GUI and glossy marketting material.

Purchasers often chose to spend their money on specialised software (solutions), hopefully saving time. We often choose to spend our time customising general purpose software, hopefully saving money.

Alex

Re:+ Kerberos ?

[ratatask]

Ok, so "turnkey" was a bit overstatement. "be able to do it for the common admin" atleast.
To do this today, you need to be a wizard. With Red Hat/Fedora it's been a little easier -
They have the system-config-auth tool. Which works. Hand editing the pam config to make this workable on a debian box wasn't ... fun.
here is how you set up LDAP+Kerberos.
It is sorcery.

Re:+ Kerberos ?

[Tony Hoyle]

Even for the 'common admin' it has to look like an AD server for the Windows workstations, otherwise it'll get passed over. That means having ldap+kerberos built in from the first install.

Common signon for Linux machines is all very well, but you've been able to do that with NIS for years.

Re:+ Kerberos ?

[drsmithy]

Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these.

Because it makes deploying them easier, quicker, cheaper and less dependant on a particular individual's (or individuals') knowledge.

Re:+ Kerberos ?

[Dolda2000]

A $notnerd sees the requirement as a black box, they don't care about the internals. They've probably been told by some techie/salesman that it will address some problem they have. For this person turnkey seems perfect, $company sells $product which is billed as an 'identity managment solution'. A magic black box solution to a black box problem, their work is done - now it is IT's problem.

I agree completely with that, but my main point is that I think that this "turnkey solution" should be a separate product -- an analogy to metapackages (like GNOME), if you will. This metapackage, which would be the already existing components plus shrink-wrapped config files, could then be sold to corporate purchasers as an "identity management solution". Optimally, it should be tailored to each company. My point is that it should not be part of the directory server, and probably not even part of the Fedora Core distribution.

Maybe it should be part of RHEL, but I'd still see these kinds of turnkey solutions as something that should really be a consultant task. Each company or organization has disparate requirements and therefore, I think each case should be examined individually. I think that in general, open source software should remain the kind of general solution that it is today, and not implement 10+ buttons for each individual scenario. It might be a good idea that Red Hat could produce a number of specialized RHEL distros for the most common scenarios, but RHEL and FC themselves should remain generic.

To you it isn't, but what happens when you leave? It's much easier to recruit someone to maintain a push button solution

Most commonly, the experienced administrator would develop more or less a "push button solution", in the form of a collection of scripts to handle the most common tasks. Thus, when I quit, the next admin could just push the buttons I've prepared for myself. If he doesn't want to dive deeper, he probably shouldn't have to. Of course, it cannot be enough emphasized that the admin who develops a system should document it properly. The thing is, the "push button solution" developed locally will handle any particularities of the organization it was developed by and for, while general turnkey solutions (is that an oxymoron?) will always leave deficiencies since they cannot be tailored to the needs of the organization it will be used by.

Re:+ Kerberos ?

[rhinoX]

Actually, it's not always $notnerd vs. $nerd. I am a nerd in every sense of the word. I understand the technology as well, if not better than any other nerd. I also understand that in my company, my technical talents are better used to _produce new products_ for us to sell to our clients and thus make more money. Screwing around with configuration files, etc. is a _waste of my time_. I just want a directory service that allows single sign-on so I can easily add resources and people to the organization without having to freaking script my own mgmt console around some lame-ass command line tools because someone out there thinks that you have to use a CLI to "understand technology".

Re:+ Kerberos ?

[tenchiken]

I agree. Hopefully the next Fedora, RedHat ES will support this directory server out of the box for authentication and serving. LDAP is finally begining to mature to the point that it is realistic to use it to control heirarchal information for large and medium (and even small) enterprises. About 8 years ago I did a project to tied sendmail to a LDAP server for email authentication. Tha was painful in the extreme. Now Zimbra has a LDAP and Hula (which I think the two most promising future email platforms) both have some form of LDAP in them to manage their settings.

Re:+ Kerberos ?

[moreati]

Ah, looks like we're both arguing the same side of the coin.

As you say, the turnkey solution should be a customisation of general parts, possibly tweaked to integrate with one another. The trick is getting a $notnerd to see this, marketting this solution so they choose it over Active Directory or ZENWorks. Consultants choosing and recommending it one good method.

I believe this identity solution should be delivered like any other opensource project. A source package which distributions can repackage and integrate. If the dependances are complex enough (like GNOME), someone will release a build helper (like Garnome). Fedora Directory Server may be exactly it

As an administrator, I know what you mean about scripts making inhouse work "more or less" turnkey. However, my experience is that I only have time to make the script perform the first 90% of the job - there are too many other demands on my time. A dedicated package could better address the second 90%, which includes documentation and the corner cases that need special treatment.

There is a spectrum, from monolithic 'solution', to bespoke. This implys a tradeoff, between base complexity (due to being a generalised behemoth) and installation complexity (due to bespoke in-house development).

I agree that the current crop of closed source turnkey solutions can only be customised so far. I believe a turnkey solution based on open source components could be customised further. A completely bespoke solution could be taken the furthest, but would be hardest to support.

Re:+ Kerberos ?

[hkb]

Largely, I think it boils down to - 'because they don't understand the technology as we do'.

Oh that's just egotistical rubbish! People like turnkey solutions mainly for two reasons:

1.) They're novices and they just want something that works
2.) They're not novices, but they're overloaded with work and they don't want to learn the complete ins and outs of yet another massive, complex software package (note I said package, not the protocols it uses, etc).

Re:+ Kerberos ?

[moreati]

Also agreed.

Sorry for my poor choice of phrase. What I meant was "person who at the time is uninterested in the technology, beyond how it can further their ends". I chose $notnerd because, in my experience, it's often the case when a monolithic solution-in-a-box is chosen.

I'm not arguing against turnkey, I'm arguing for technically sound solutions. In my eye that means both a strong GUI (for everyone doing one off tasks) and a strong scriptable interface (for automating repetitive tasks). Having a scriptable interface often means a CLI one, but not always).

Commercial, monolithic SSO solutions tend to have a strong GUI, and a weaker sctipting interface. Open source and in house SSO solutions tend to have a strong scripting interface and a much weaker GUI.

Hopefully this release will have both, if so, then the next job will be marketting it.

Re:+ Kerberos ?

[Anonymous Coward]

Believe it or not, there are people out there who understand technology deeply but who do not love it. There are people who most certainly could run an entire directory service using only OpenLDAP and Perl, but they do not wish to. They would rather do it the easy way so they can use their time to do other things.

Saying that people who don't like doing things the hard way just don't get it is foolish and more than a little insulting.

Re:+ Kerberos ?

[moreati]

Sorry, I've chosen my words poorly. Again.

I should have said 'because they don't understand or care about the technology as we do, only the results'.

Turnkey is sometimes a good choice, such as in the cases you give. Customised packages & bespoke are sometimes a good choice sometimes.

My argument (and I believe Dolda2000's argument), is that turnkey solutions should not be monolithic. They should be built on independant components, rather than being a take it or leave it lump.

Any solution (eg Active Directory, OpenLDAP+PAM+Kerberos+mgmt interface) will be internally complex - the value added by making it turnkey is to hide the complexity.

If indeppendant components are chosen, it's much easier to adapt the solution to new requirements. If necessary, it becomes possible to step behind the scenes and change things in a way the vendor didn't intend and so didn't provide an API/interface for.

Re:+ Kerberos ?

[nathanh]

Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these. Updating your LDAP, Kerberos, NSS and PAM configs manually isn't exactly hard as it is.

Yes, yes it is. Now you can obviously do it. So can I - that's one of the many jobs I do, installing LDAP and Kerberos services for corporate and government clients - but it's not easy. If it was easy then these companies and agencies wouldn't need to hire me. They could do it themselves.

Let's face it. The terminology is confusing. The number of files you need to tweak is many. The interrelationships are complex. There are many pitfalls. It's a steep learning curve. The daemons and utilities often have terse (entirely confusing) error messages. Once you've learnt everything it "isn't exactly hard" but the majority of clients never learn gain the required knowledge. They rely on outside help, like me.

I would very much like to see LDAP and Kerberos become as easy to deploy on Linux as it is on Windows. I've seen brain-damaged monkeys manage to successfully deploy Active Directory. It requires some level of skill to do the same on Linux, and I'm never entirely satisfied that the result is quite as slick and well-integrated as Microsoft Active Directory. Your comment about a "single button" leading to complexity is well taken but the majority of clients would prefer that single button instead of the expensive consultant.

Re:+ Kerberos ?

[killjoe]

Why is a $notnerd maintaining something as important as your directory and authentication? Any CIO who hires a button pusher to maintain something as crucial as identity servers should be fired on the spot.

Re:+ Kerberos ?

[killjoe]

What do you mean "lame-ass command line tools". In what way are they lame? Do they not work? I find the command line tools to be very powerful and easy to work with.

Re:+ Kerberos ?

[toadlife]

Well then there are probably around two million CIO's in the U.S. alone that need to fired right now. That would be pretty harsh on the economy.

Re:+ Kerberos ?

[moreati]

The $notnerd isn't maintaining the system. Precise meaning has really come back, to bite me on the arse in this thread.

A non-techie most often gets the final decision about which solution to choose. They base their decision on advice from their in house techies, sales pitches and bids received etc.

One pitfall they wish to avoid, is a system that is more expensive to maintain and customise in the long term. A solution-in-a-box is commonly held to have lower staffing overhead, because less experienced (aka cheaper) techies, or even laypersons can operate it and perform day to day admin. With an in house solution (bespoke or scripted generic services), the staffing cost is deemed higher; because deeper site knowledge and greater experience is needed.

Note that this excludes the cost of customising and long term maintaing the system. Any manager doesn't want to rely exclusively on a small, hard to recruit pool of talent.

Re:+ Kerberos ?

[hendersj]

The "Common Admin" these days tends to not understand how systems work. Sad, but true.

I would think that the important thing would be to raise the level of knowledge of the common admin, rather than to dumb down the technology to the point that it looks like Windows. Why is it that we expect our sysadmins to be unable to cope with decent technology?

That doesn't mean intentionally making the technology difficult to use. It means expecting that the masses sysadmins out there actually understand how to implement technology solutions and for them to understand the limits of those solutions.

Over the years, I've seen far, far too many sysadmins who - for example - in wanting to find a list of expired system accounts in a system with > 5,000 users, printed the list of users (and all attribute data) out in order to go through the list by hand to find the expired accounts. The printout was over 3,000 pages long (we stored a lot of data in the directory) and tied up a major printer on a floor of our building for an entire afternoon.

I laughed at the time, but this type of thinking seems to be considered almost normal by businesses. They say they're interested in ROI and TCO, but then hire idiots who don't know how to build a proper query for data - which certainly lowers their ROI and increases their TCO.

Bottom line - I don't think a product like this should aim at the common admin - because the "common" admin is an idiot. In order to administer systems properly, you should at least have a rudimentary knowledge of how to build a query, how to automate a process through scripting, and how to effectively implement security policies.

Re:+ Kerberos ?

[trolleywobbles]

Maybe this is just me, but I've never understood why people need "turkey giblets" for things like these.

Largely, I think it boils down to - 'because they don't understand the culinary arts as we do'. Take a simple, kitchen requirement: boiling. You or I might see that in terms of the components: such as a stove, a pot, deboning, some means of boiling, monitoring the temperature, etc.

A $chef sees the requirement as a big pot, they don't care about the internals. They've probably been told by some dishwasher/waiter that it will address some problem they have. For this person the turkey seems perfect, $restaurant sells $dish which is billed as a 'Turkey Giblet in White Sauce'. A magic black pot solution to a black box pot, their work is done - now it is the manager's problem.

Updating your pots, pans, stove and oven stocks manually isn't exactly hard as it is. If you want to make it easy to set up multiple workstations with this setup, just use cheap labour (or a shell script on NFS...).

To you it isn't, but what happens when you leave? It's much easier to recruit someone to maintain a push button solution, than a partly bespoke ecology of stoves and pots. Often the solution and the ecology are similar in complexity, but the solution hides that behind good food and glossy marketting material.

Diners often chose to spend their money on specialised meals (solutions), hopefully saving time. We often choose to spend our time customising general purpose food, hopefully saving money.

Alex

Re:+ Kerberos ?

[lcarstensen]

See:

http://directory.fedora.redhat.com/wiki/Howto:Kerb eros

Not to sound cantankerous, but there's plenty of reasonable documentation hidden away on the project's Documentation page:

http://directory.fedora.redhat.com/wiki/Documentat ion

Re:+ Kerberos ?

[the_olo]

This is sort of backwards.

The HOWTO discusses allowing authentication to Fedora Directory Server using Kerberos credentials from a Kerberos database. So this works like this: you want to use the LDAP service (Fedora Directory Server) to e.g. search for some users. You connect to it, and supply your Kerberos ticket, that's obtained from a Kerberos KDC (Key Distribution Server), based on authentication based on your Kerberos Server's database (probably some ordinary files). You get authenticated based on Kerberos's authentication databse (which is outside of FDS's LDAP!), then you get access to the LDAP database. It looks completely bottoms-up! You throw away the whole scalable n-way replicated LDAP authentication database that is available in the FDS, and use some simple academic Kerberos implementation to store all your users' keys and password data! You need to keep those 2 databases in sync, and your Kerberos server probably won't scale to such large numbers of users as the Fedora Directory Server, since open source Kerberos implementations (MIT, Heimdal) use their own file-based databases.
Forget 4-way multi master replication, forget scalability to hundreds of thousands of users.

Why use Fedora Directory Server at all then, if you delegate its most useful functionality to some separate agent, separating the authentication database from user database and turning the whole "centralized identity management by LDAP" concept upside down?

What's needed is getting a Kerberos server (KDC etc.) use Fedora Directory Server as its database backend, for efficient and stable storage of users, tickets, keys etc.
The Heimdal Kerberos implementation can do supposedly this, but only through UNIX domain sockets AFAIK (no LDAP over IP network :( ).
See:
http://www.padl.com/Research/Heimdal.html and http://www.pdc.kth.se/heimdal/ .

Since Fedora Directory Server doesn't seem to support LDAP over UNIX domain sockets, putting Heimdal Kerberos authentication layer on top of FDS looks impossible currently :(

Re:+ Kerberos ?

[the_olo]

Andrew Bartlett from the Samba team is a proponent of such integration, taking place in Samba 4. See his paper on this.

Get Carter.

[Chaffar]

The example they used in the screenshots is the same one used here! There must be a deeper meaning to this blatant plagiarism. I mean, even the phone number is the same... Yep, definitely a terrorist plot in the making somewhere here...

Gentoo package?

[nighty5]

Anyone know if there is a gentoo package for this? - Even if it's not the most up to date.

I've searched used such strings as "ldap", "nss", "directory" etc - but nothing comes up too interesting.

Re:Gentoo package?

[Pecisk]

My pick is is not yet ported - so you can try to contribute a ebuild! It is your chance to shine! :)

More seriously, I will check out depencies. As I have rather big interest in this product, I will check out If I can't contribute an ebuild.

Re:Gentoo package?

[sveinungkv]

Not yet, but since the release of 1.0 hit slashdot, I guess it will come soon... ;)

Re:Gentoo package?

[destuxor]

http://www.gentoo.org/doc/en/ldap-howto.xml

Re:Gentoo package?

[ScytheBlade1]

Nice troll. Very very obvious, but nice.

That said, it is an enterprise software package, which makes a good portion of those who use gentoo just pop up and go "Oooooooohhhhhhhhhhhhhhhhhhhh........."

I'd say give it a week and it'll be there.

Re:Gentoo package?

[wampus]

If only there was a "-1: I just set up a directory server on Gentoo, for money" moderation.

Re:Gentoo package?

[GreyWolf3000]

Well, he could have been going another direction with the sentense, by using a different meaning for "since." I think the natural way the sentence flows suggests he's using "since" as a synonym for "because." This is a likely case; however, I also find it likely that he actually means "since" as in "after," e.g.:

"Not yet, but after the release hit slashdot, ...

Of course, the second clause doesn't exactly parse correctly in that case, but...well..just a thought :P

Interesting, but is it Good Enough(tm)?

[jd]

In and of itself, LDAP started off as a partial implementation of the X.500 directory services - partial being the bits that people generally found useful. The LDAP specification has changed over time, reflecting a better understanding of what people actually needed - together with the fact that as systems became more powerful, people generally needed rather more out of services.

The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.

The second problem is that there needs to be an Open Source system compatible with (and preferably better than) Microsoft's Active Directory. The LDAP side of that is absolutely critical. For this directory server to be of much interest to network administrators, this package absolutely must support two-way communication with Microsoft Active Directory's LDAP. It can support more - and it would be great if, for once, Open Source "embraced and extended" something from The Other Side...

To be of interest to system admins, it needs to work with PAM and preferably one of the standard "unified" admin interfaces, like Webmin or (yes, it is still used) linuxconf, in addition to specialized tools. It needs both. Specialized but simple command-line tools are great for doing batch tasks or quick tasks, which will be the bulk of routine tasks. More complex tasks, changing configuration files, etc, are often easier in a unified interface. For extremely precise operations, user interfaces hide too much detail, so for those you often do have to use some hefty command-line and probably a text editor for control and config files.

In other words, you've three distinct classes of operation and distinct types of interface for each. The "best" tools are ones which provide all three interface types and make it easy to develop others.

The last problem I'm seeing is that computing has moved on since Netscape ruled the world. Unified Parallel C is beginning to look like a serious rival to classical C, and even classical C compilers are gaining parallel support in the form of OpenMP (now included in a development branch of GCC). Fedora can't even keep their parallel patches in sync with the kernel. For that matter, their development repository is rarely synchronized, even though that's just a dependency chain they can follow from the SRPMs.

(Don't get me wrong - I like Fedora's distro, it is simply that if they are neglectful of something they can do in a script and a makefile, and of mere patches they had already made public, then how confident can I be of their ability to maintain a very complex piece of software?)

Re:Interesting, but is it Good Enough(tm)?

[Anonymous Coward]

I'm sorry, what the hell are you talking about? That was the most mindless post I have ever seen.

The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.

Red Hat / Fedora Team spent about a year cleaning it up and porting it to linux, or didn't you bother to read the summary?

For this directory server to be of much interest to network administrators, this package absolutely must support two-way communication with Microsoft Active Directory's LDAP. It can support more - and it would be great if, for once, Open Source "embraced and extended" something from The Other Side...

Uh? What does it need? 3-way communication with AD? 4-way? Active Directory is just a bastardized for of LDAP, and even OpenLdap includes the bits needed to work with it. What you are saying here doesn't make any sense.

To be of interest to system admins, it needs to work with PAM and preferably one of the standard "unified" admin interfaces, like Webmin or (yes, it is still used) linuxconf, in addition to specialized tools.

What you are saying here demostrates a complete ignorance of PAM, LDAP, and directory services in general. PAM has long supported LDAP, as has the NSS libraries. Webmin and Linuxconf are two interfaces the people have added as a layer on top of existing services. Nothing NEEDS to work with them, they support whatever they want. FDS has a great GUI and that is the point. Otherwise, an LDAP service is a usefull as the schema you load and how you implement it.

I like Fedora's distro, it is simply that if they are neglectful of something they can do in a script and a makefile, and of mere patches they had already made public, then how confident can I be of their ability to maintain a very complex piece of software?

Ok, seriously, get a clue. If you are looking for assurance, pony up some cash and buy the fully supported Red Hat Directory Server. Frankly, I think the entire Fedora effort is great, but I wouldn't run any substatinal business on it. For that I pay for Red Hat.

Re:Interesting, but is it Good Enough(tm)?

[TarrySingh]

Hmm.. so pay = better? contribute, test, fedora = mindless? Then why the fawk do we have all those folks(meaning us all, dev, sysadmins,dba's etc) working on Fedora?

Re:Interesting, but is it Good Enough(tm)?

[Tony Hoyle]

AD is not just a bastardised LDAP. AD is LDAP+Kerberos+Extensions which needs to be *specifically* catered for. I'm assuming this DS supports AD otherwise it's just going to get nowhere in the corporate space.

Re:Interesting, but is it Good Enough(tm)?

[Temkin]

Red Hat / Fedora Team spent about a year cleaning it up and porting it to linux, or didn't you bother to read the summary?

"Porting to Linux" is and of itself a mindless statement, since this is Netscape DS, aka iPlanet DS, which is an antique fork of Sun's current SJES DS, all of which have been running on Linux for better part of a decade.

It will be interesting to compare Fedora DS to Sun's current offering. Sun even provides an open source tool for this called SLAMD.

Re:Interesting, but is it Good Enough(tm)?

[illumin8]

The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.

To really understand this move by Redhat, it has to be taken into context with last weeks news about Sun open sourcing their enterprise applications, one of which is iPlanet Directory Server. iPlanet Directory Server and Redhat's both forked from the same Netscape code base. The difference is that Sun has invested 3-4 years of heavy development time, improving features involving 4-way multi-master replication across WAN links and many other things. It seems like Redhat just dusted off the 5 year old-code, rewrote some of the encumbered bits, and released something that's probably equivelant to Netscape Directory Server 4.0. Sun is up to iPlanet Directory Server 5.2 and has been innovating.

I think this is a move by Redhat to counter the move Sun made last week in opening up their directory server product.

Re:Interesting, but is it Good Enough(tm)?

[talksinmaths]

"Porting to Linux" wasn't the best verbage the AC could have used, but it doesn't quite descend to the level of 'mindless statement'. The fedora developers have worked to make DS for Linux a better product. For example the 1.0 release uses apache + mod_nss instead of the ns-httpd server, and the performance improvement is impressive. Of course the non-Linux platforms for which they produce DS presumably also reap these benefits, but it seems to me that the primary motivation is to make a great Linux product.

Re:Interesting, but is it Good Enough(tm)?

[swillden]

AD is not just a bastardised LDAP. AD is LDAP+Kerberos+Extensions

Right. It's Bastardized LDAP + Bastardized KERBEROS + thoroughly proprietary extensions.

I'm assuming this DS supports AD otherwise it's just going to get nowhere in the corporate space.

Sad as it is, you may just be right.

Re:Interesting, but is it Good Enough(tm)?

[jd]

That was exactly my point, although you did a much better job of expressing it.

Re:Interesting, but is it Good Enough(tm)?

[jd]

I'm impressed. Most troll postings have no information content. This is the first time I think I've seen a posting with less than that.

Re:Interesting, but is it Good Enough(tm)?

[jd]

If that is the case, it's rather worse than I expected. I've been assuming that they've kept reasonable pace with comparable products, though given all the cruft in Netscape Navigator on its release, I was partly concerned Red Hat might have been forced to lag behind, just to get the code into acceptable shape.

My main fears were largely concerning how well they tracked highly non-standard variants that are built into key products that the corporate market simply won't do without. Because things like AD are totally non-standard (a quick scan of articles on linking OpenLDAP to AD shows that the best anyone has managed is one-way from AD to OpenLDAP) it is obviously going to take significantly more effort to provide any level of integration beyond the most trivial.

Given that another major package that uses LDAP is Exchange (also from our favorite Arch Enemy), that Exchange is also very widely used and that Microsoft is likely to be keen on preventing any drop-in replacement that will interoperate 100% with Exchange, I see no reason to believe that Exchange follows the recognized standards, either.

Red Hat is not a major international corporation on the scale of IBM or Microsoft (or even Sun), it has enormous problems keeping pace with both RHEL and Fedora, it is not known as a major center for reverse-engineering protocols, it has a hard time with keeping even its own internally-written software current and its experience in the mainstream enterprise domain is limited. (The biggest area is through IBM's S/390 series, but there it is IBM that is dealing with the customer.)

Re:Interesting, but is it Good Enough(tm)?

[jd]

I've been using Linux from the days it came on two floppies and couldn't even support X. I used 386BSD before then. I was building my own LANs in the early 1980s, probably before many Slashdot posters had even used a computer. No, I think I know what I'm talking about.

RPC? DCE? You are -way- behind the times, there, and no sane person alive is going to use protocols with such horrible latency. Have you seen how many layers RPC needs to go through? It was great when it was about the only thing out there, but that was over fifteen years ago. The only way to take your comment seriously is if your name is Rip Van Winkle or you fell into a liquid nitrogen bath.

Comparing pthreads to UPC or C with OpenMP is astonishing ignorance. Threads are a subset of any parallel programming environment, but they are not a complete subset. That is why parallel extensions to C exist.

Oh, and sure, you can run parallel programs on Linux right now. On a single box, the built-in threading works just fine. For clusters, I recommend OpenMOSIX with the Distributed Shared Memory patch for most things, but MOSIX, Beowulf/bproc, Compaq's One-Stop SSI patch, etc, exist for those who have different needs.

To help with clustering, you've a choice of any combination of Active Messages (not a Microsoft product), PVM, MPI-1, MPI-2, BSP and some of the Plan 9 stuff that has been ported over.

(You get the feeling I might know something about this side of Linux?)

As for RPC being secure.... Hmmm. This must be why most admins turn off every RPC function they possibly can. No, RPC is not secure. Even with the security extensions, it is notoriously unsafe. Because it has so many layers, it is probably impossible to make safe. As for DCE - I certainly wouldn't trust anything that has been made Open Source solely because nobody else would use it any more. I would need to see some serious work on it, to regard it as the least-bit usable.

Re:Interesting, but is it Good Enough(tm)?

[kmeister62]

And on top of it very poorly documented so you can figure out what the #^%$ is going on when it doesn't work right. Trying to get W2K3 working in a properly replicated evnironment without SP1 was almost impossible. Have one machine go haywire and the bi-directional replication is screwed for good. Had this issue in a production environment. No backup for an AD used with mission critical clusters ain't fun. Luckily SP1 was able to correct the issues. Let me tell you, having to go through the build, integration and implementation of OpenLDAP/Samba on Linux FC3 taught me tons about what MS AD was supposed to be doing. Its a pain but I will tell you that the support was fantastic.

Re:Interesting, but is it Good Enough(tm)?

[chrome]

jd++ !!

Re:Interesting, but is it Good Enough(tm)?

[KmArT]

The first problem is that Netscape probably didn'tadd much to their Directory Service towards the end, and it is unclear how much Fedora has had to put resources into code cleanups and bug fixes, as opposed to adding the capabilities it is going to need.

Well, check the CVS log, or join the mailing list and find out. For starters, beside bug fixes, the entire admin server backend has been replaced with an Apache httpd.worker model - its loads light-years faster than the original ns-httpd admin interface.

The second problem is that there needs to be an Open Source system compatible with (and preferably better than) Microsoft's Active Directory. The LDAP side of that is absolutely critical. For this directory server to be of much interest to network administrators, this package absolutely must support two-way communication with Microsoft Active Directory's LDAP. It can support more - and it would be great if, for once, Open Source "embraced and extended" something from The Other Side...

LDAP is LDAP. Active Directory is not LDAP - it provides a LDAP-like interface to data and it does it Microsoft's way. If you need to integrate your FDS with AD, then have a look at http://directory.fedora.redhat.com/wiki/Download under the Windows Synchronization section.

To be of interest to system admins, it needs to work with PAM and preferably one of the standard "unified" admin interfaces, like Webmin or (yes, it is still used) linuxconf, in addition to specialized tools. It needs both. Specialized but simple command-line tools are great for doing batch tasks or quick tasks, which will be the bulk of routine tasks. More complex tasks, changing configuration files, etc, are often easier in a unified interface. For extremely precise operations, user interfaces hide too much detail, so for those you often do have to use some hefty command-line and probably a text editor for control and config files.

For you to comment, you might want to learn a little bit about the layers of an application stack. And note that LDAP defines a protocol (over the wire) and a service. You can wrap whatever you want around it for administration (just like you can any LDAP server)..

About the console

[Sk0yern]

Have anyone else noticed how slow the console is on a RedHat Enterprise 3 server?
Its like you press a button, then you have to wait for 10 seconds before anything is happening. On Enterprise 4, everything is about 50 times faster, maybe even more.
The main difference here should be 2.4 kernel versus 2.6 kernel, but what makes the console that much faster on 2.6?

Re:About the console

[croddy]

No, I haven't noticed this at all on RHEL 3.

Re:About the console

[Anonymous Coward]

User error, hit any person at keyboard to continue.

It is probably trying to do some kind of lookup, ipv6 or your nameservice, you did configure your /etc/nsswitch.conf to look at the nameserver, not the local ldap server (recursive lookups are bad ! )

Re:About the console

[flosofl]

Have anyone else noticed how slow the console is on a RedHat Enterprise 3 server?

Hmm... my airmchair diagnosis is that you may be suffering from a PEBKAC issue.

I keed! I keed!

ldap schmel-dap

[Anonymous Coward]

My employer recently tried to "enchance" our application to authenticate to an LDAP directory rather than our traditional backend security server. Wow, is LDAP ever NOT the tool for that job.

There are so few standards around LDAP authentication that it is impossible to support "LDAP" - you have to support MS Active Directory, Oracle Info Server, Novell eDir, etc..

For example, there is no standard way to handle password expiration. Every directory does it differently. There is no standard location or hashing algorithm for user passwords, nor is there any sort of standard password policy (password complexity rules, maximum retries until lockout, etc)

So we basically had to rewrite support for all these things that we already had in a modular fashion so now administrators are stuck configuring "the AD plugin", or "the OIS plugin".. ... but anyway, LDAP thinks it's all that and a bag of potato chips, but I'm here to tell you it is NOT.

Re:ldap schmel-dap

[deep44]

For example, there is no standard way to handle password expiration. Every directory does it differently. There is no standard location or hashing algorithm for user passwords, nor is there any sort of standard password policy (password complexity rules, maximum retries until lockout, etc)

RFC 2307 - using LDAP to provide a Network Information Service.

Almost everything you touched on is covered in that RFC. So the standards exist, but Microsoft/Oracle/etc chose not to adhere to them by creating their own one-off schema.

I'm not saying they were wrong to do that, but don't blame the LDAP protocol because you had problems using it to interface with AD.

Re:ldap schmel-dap

[Zphbeeblbrox]

Instead of trying to interface with all those why not create your own schema that the purchasers can import into the variouse directory types. Surely you could set it up so that you didn't have to use the proprietary protocols. Then your clients could just import that schema into their particular directory service. You could even link it into the current accounts with a little creative scripting I think. (not sure on that one though haven't messed with LDAP much yet Though I'm starting to)

Re:ldap schmel-dap

[deep44]

Yes, anybody can submit an RFC, but the IETF decides which ones to accept as official RFCs. Joe Random's weblog would probably not qualify.

Additionally, who cares if it's not an official standard? The original poster said that LDAP is flawed because Microsoft AD, Oracle, and Novell all use different schemas within their directory products. That has nothing to do with LDAP (the protocol), and everything to do with the design choices those companies made.

Re:ldap schmel-dap

[batkiwi]

Authentication in LDAP should be handled by a double-bind.

First you bind as a read-only user to grab the user's DN from whatever they pass in (if they type an email address, you query that field to return their DN). Failure of this query means they entered an incorrect username/alias.

Second, you take that DN and the password the user provided and attempt a second bind against LDAP. Failure to bind means they entered the wrong password.

Was there a particular reason you couldn't use this method?

Re:ldap schmel-dap

[batkiwi]

Ahh, got it. Shouldn't your ldap system handle password expiration/etc, and not your app, though?

Maybe you had quite specific requirements, and I WILL agree that password stuff is NOT handled uniformly in LDAP, which is why I use the bind method.

Re:Great

[Anonymous Coward]

"So I can kick the Windows ADS out of the door?" - by TarrySingh (916400) on Sunday December 04, @07:39AM

You can most likely, I do not see why not!

After all, this is just another example of you Linux people have duplicated/imitated/copied yet another concept from the Windows world so you can do something already doable in Windows!

(This goes on from both sides though - e.g. -> Windows via Terminal Services (ala watered-down licensed technology from Citrix) does what X has been doing for year on UNIX, which is remotely runnable applications & desktops. Directory Services aren't original to Windows either - Novell had them before Windows & Citrix did via NDS (Novell Directory Services))

BUT, other things (like thread-use & especially/specifically @ the kernelmode level) is another one that Linux bit off of Win32 OS, & @ the kernel level so that SMP (more than 1 cpu) was possible for the OS to use in Linux (it already had usermode "threads" that ran off a single kernelmode thread round-robin) & so Linux could 'scale to enterprise class use' as an OS.

Again - this ALL seems to be a game of copy-cat/knockoff from ALL OS families, stealing one another's features!

APK

P.S.=> Personally, I dno't really care if one OS family takes another's features (although you hear it here constantly that MS innovates & creates nothing, which partially is true, they DO license technology from others OR buy entire companies out for their technologies), as long as we, as the consumers, get those nice features in whatever OS it is we all use... apk

Scripting languages and LDAP

[dmouritsendk]

Most scripting languages will have some kind of LDAP module available, like python has http://python-ldap.sourceforge.net/ and perl has http://ldap.perl.org/.

So even if Fedora's directory server doesn't offer any console tools (i dont know if it does), it won't be any problem making scripts manipulating its data. Take a look at this example on howto remove a record, its from the python-ldap site, and it isn't exactly overly-complex to use from the looks of it :-)

import ldap
try:
        l = ldap.open("127.0.0.1")
        l.protocol_version = ldap.VERSION3
        username = "cn=Manager, o=anydomain.com"
        password = "secret"
        l.simple_bind(username, password)
except ldap.LDAPError, e:
        print e

deleteDN = "uid=anyuserid, ou=Customers,ou=Sales,o=anydomain.com"
try:
        l.delete_s(deleteDN)
except ldap.LDAPError, e:
        print e

Not the first time.

[ebuck]

As another poster has already stated, it's not the first time that RedHat has bought something and then changed the license to an open-source license.

However, this story is just a bit more complicated.

RedHat open-sourced all of the code they could, which was quite a bit, but originally just the main directory daemon, ns-slapd, a few shared libraries and command-line tools were open source. The real news here is that the last of the "other" bits have finally been re-written under a new (open-source) license.

That's part of the motivation for resetting the release nubmer; note that this is verison "1.0" instead of (grumbles about memory) 8 or 9?

So now, it is a 100% open source solution, no more binary-only rpms.

FANCY gui?

[/ASCII]

You thought that those screenshots look fancy? My first thought on looking at those screenshots was 'How could they make such a butt ugly theme the default for Swing applications?'. It combines the worst apects of Motif and Windows95.

Re:FANCY gui?

[AlphaSys]

I thought the same thing. The answer is they really didn't do anything revolutionary to the UI they bought from Netscape. Netscape's server products were actually pretty OK under the hood, but they never sold because they were even uglier in the UI than the current Redmond offerings of the time. Tsk, tsk.

Re:FANCY gui?

[kopykat]

figures!a GUI perfect application that requires a minimal of 39 patches on a one year comparison between linux and windows and the real rhetoric is in why it would take an average of 139 patches in test conditions to keep a server secure and the joke is "butt ugly!" how about the real number of patches that would be required to keep any server running and secure...! i guess in 2007 the new joke is its a kopykaT!

Re:FANCY gui?

[AlphaSys]

Well, as far as Exchange 5.5 goes, you do indeed have a point beyond any contest I can muster. But Netscape's server products really had little in the way of requiring the communicator suite on the client. Any browser, mail client, directory browser, etc. would do fine. They just happened to have a free (beer) one you could use, but you know you get what you pay for. But no, I still maintain Netscape server products didn't sell better because their administration apps were klunkier than alternatives by competitors.

Re:FANCY gui?

[dtfinch]

The answer is probably that they don't care what it looks like so long as it works and it's easy to use. It's an administration tool, not a video game.

Re:FANCY gui?

[robbkidd]

It looks old because it is old. It's been a while since I used it, but I don't recall the iPlanet configuration tool looking much different in 2000/2001ish.

Re:Linux Users:

[WheelDweller]

Yeah....tell CP/M, MP/M and DOS I said "Hi", and that I miss them a little. ;)

Re:Java Enterprise System from Sun is better produ

[allenw]

... and will be opened as well. I can't help but think that RH rushed this out the door to counter Sun.

But does anyone really want an older version that's likely been untouched for years?

Re:Great

[jooon]

I think Samba 4 (even though it is not released yet) is closer to kicking Windows ADS out of the door than this, even though this is good to have for other reasons. The problem is that Windows ADS is more than a LDAP-server and even if we have all the parts, LDAP, Kerberos, CIFS, DNS, etc. getting them to work together to be completely compatible with Active Directory Server seems to be very hard.

Re:FANCY gui? Looks like the old Netscape DS GUI

[kalmite]

Actaully this is the same exact GUI that was used for Netscape Directory server back in WinNT 4 days... so the question is why didn't RH change change the GUI to something using Gnome/KDE. Looks like they just took the old product and released it.

Sam Carter

[Andrewkov]

I'm Sam Carter, please stop using my name in screen shots!

Re:Sam Carter

[fons]

I feel your pain.

Kind regards
John Doe

Re:Java Enterprise System from Sun is better produ

[canuck57]

I think that the Fedora directory Server is late, and it is based on old versions of Netscape Directory Server.

Yes, it is late. Plus I find it disturbing some parts of it have special licensing concerns. And being version 1.0.... hopefully they will write this code out in time.

But it's strengths are that being based on the Netscape server gives it a boost in functionality over Open LDAP. I often wondered why Open LDAP seemed to almost stall in it's development.

So I will still be using Sun One Directory Server but do plan to watch this development carefully.

Nice to see

[jbellows_20]

Looking at the screenshots, this looks like the best way of managing users for the Linux community. What I'm still waiting to see is an implementation of User and Computer policies allowing for mass management of systems. I know there are ways to kinda do this using rsync or scp and cron, but we don't need a hack we need a real solution.

Re:Nice to see

[gnud]

Just curious:
by a "real solution", do you mean a GUI?

Re:Nice to see

[jbellows_20]

A real solution would be a policy engine, an actual application that read policies from an enterprise server then took those policies and applied them to the workstation. Take that and give it an interface (whether gui or tui) to allow the management of the different policies. I've looked around and there isn't much. Zenworks from Novell is supposed to be able to do this but haven't had time to setup a test system to see what it can do. As much as one might hate Microsoft, he/she has to admit that their Enterprise management tools are one of the best out of very few options.

I a n00b with a question

[jim_v2000]

Is a directory server something like MS ActiveDirectory?

Re:I a n00b with a question

[szo]

No, the other way around.

Re:I a n00b with a question

[duncanmacvicar]

No. MS ActiveDirectory is something like a directory server.

Re:I a n00b with a question

[tweek]

Actually Active Directory is a combination of LDAP and Kerberos. That's a simply definition but it will suffice.

In general directory servers are based around the OSI X.500 model and DAP.

A good bit of info is here:
http://www.kingsmountain.com/ldapRoadmap.shtml

FYI you can thank the amazing team at University of Michigan for LDAP. Go Blue!

Re:Java Enterprise System from Sun is better produ

[Anonymous Coward]

Better - how exactly, care to explain? Last I saw both started from same code base a few years ago and today both have more or less the same feature set (Heck even the screen shots are a proof that the admin console is 95% the same). And you have the Fedora Directory sources with you today - so if you find (like me) that the Sun Directory works only with RHEL 3 and 4 (it comes with a installer binary which is built to install RPM packages and doesn't work with anything other than RHEL) then you are much better off with downloading the Fedora DS sources and making a change or two to get it to run on your fav distro.

And it's definitely not a "older version untouched for years" - it's been in active development since all the years and that's how the feature set is almost same as Sun's version and it's ported to compile with fully open source software - they spent a year on that. And these are mature commercial products with more features than anyone might require at a time and so the development rate is slow and limited to bug fixes most times. Years have passed by since Sun has added a significant feature to it's DS - remember the last release supported only Redhat 7.2 until recently!

As far as support goes, you can buy it from Redhat or Sun as the case may be but then we aren't comparing products there - I don't know how Redhat support for the DS would be but I have used Sun support for their DS and it wasn't exactly extraordinary - we had to live with the problems.

So, what was your point again?

Open Bottom?

[Doc Ruby]

I'm running Open-Xchange, an OSS groupware suite that, among other features, can transparently replace (mostly) Microsoft Exchange. OX uses OpenLDAP, though it can (in theory) use any LDAP directory server, including the FDS. OX uses Postgres as its default RDBMS for its data tier, but OpenLDAP stores its data internally. OX has some limits on its integration of directory data, because the rest of the app can't connect to the OpenLDAP storage - that means some sync issues, and some data is defacto read-only by both server apps and clients.

There are posted techniques for pointing OpenLDAP at MySQL instead of itself, which seem to offer a way to point at Postgres. Does FDS let me easily point at Postgres for all persistent storage? Or even at Oracle (as OX could do)? Where's the HOWTO?

Re:Open Bottom?

[KmArT]

http://directory.fedora.redhat.com/wiki/Plugins

Just about everything about it is extensible by plugins, including data storage.

Re: Who needs turnkey

[BenFranske]

I think it's because the domain of technical knowledge is so great that it's really quite difficult to grasp it all. If you're a small or medium sized company you may not have someone who really understands Kerberos and LDAP. Your sysadmins may know everything in the world about mailservers, webservers, DNS servers, DHCP servers and database servers but very little about AAA servers, Kerberos and LDAP. Look at the security community which is still farily young. People are already starting to specialize into wireless secuirty, WAN security, LAN security, etc. What you need the turnkey solutions for are the areas you are still learning but don't grasp.

If you have a 250 person company you may have three sysadmins, six developers and two managers in IT. I've worked at companies like that and they're pretty common. The three sysadmins need to keep the phones, network, servers, printers and any other hardware running. Chances are they aren't experts at running every kind of server and might have some difficulty with getting a non-turnkey solution for the areas they're less famailiar with up and running. It also needed to be up and running last week. One of the realities of buisness is that you often need to make do with the staff and their existing knowledge which means a lot of turnkey solutions which usually means Microsoft.

Sun paid $88,000,000 for Star Office.

[Futurepower(R)]

I remember reading that Sun paid $88,000,000 for Star Office, that became Open Office. Sun still charges for support for Star Office, and my guess is that Sun has made a profit on its investment in Star Office, even though an open source version is free.

Re:Java Enterprise System from Sun is better produ

[talksinmaths]

I find it disturbing some parts of it have special licensing concerns.

From the 1.0 release announcement page:

All source code is open source, not just the core DS engine

This wasn't the case with the prior version, but AFAIK Redhat has now made good on their promise to open source the entire product.

Older Java Enterprise System Directory Server

[orpheus2000]

This is pretty funny, since this Fedora DS looks like pre-5.2 Netscape/iPlanet/SunONE/Java Enterprise System (thank you Sun for all the naming) Directory Server... which was just announced to be released for free and open-sourced by Sun this week.

Remember that Java Enterprise System is concurrently developed for Solaris SPARC, Solaris x86, and generic Linux ( and sometimes gets RPMS for the latest stable RH Enterprise). DS 5.1 and before had horrible problems with replication and the Java console was dog slow... JES DS 5.2 adds point-and-drool replication of pretty complex topologies (cascading multi-master to consumer via hubs... think Cingular LDAP) and a much quicker Java GUI. And of course numerous bug-fixes and such. And all the command-line goodies that you can shake a stick at.

I'd recommend JES if you're serious about the LDAP service.. however, this Fedora DS looks to be good for a departmental LDAP authentication service.

Just my $.02 as someone who's seen and worked with both DS's and OpenLDAP (which in my opinion doesn't even play in the same field as ns-slapd)

Re:Older Java Enterprise System Directory Server

[mikefe]

Another post in reply to yours said much of what I was going to, but let me add another little tidd-bit.

A few months ago, I went to a UUASC-OC meeting about directory services (which happens to be at the Sun office in Irvine, CA) and the main feature that DS 5.2 adds over 5.1 is "push" based updating when there is a change, instead of updating on a fixed schedule.

Open Source LDAP

[Delifisek]

I use NDS, I use AD and can't use Open LDAP successfully. Every year I try to setup for somting and I fail. Probably thats my fault.

Last time I just create OpenLDAP server for shared Outlook address book. And I fail to find a good manager for it.

I hope that Fedora DS server may fix that situation.

There is already an LDAP useradd, etc.

[Medievalist]

Thorsten Kukuk maintains a pwdutils package that includes LDAP-capable useradd, usermod, chage, etc. for SUSE.

People are begging Red Hat to integrate Thorsten's code into RH Enterprise Linux here. Join the throng and maybe Red Hat will get the thumb out.

You could also consider cpu which includes usermod/useradd functionality.

A lot of sites just use cgi-perl and Graham Barr's perl-LDAP to create a custom web app for this sort of thing. Once you've got an LDAP backend that seamlessly manages password transparency between apache, Active Directory, *nix, and Novell it becomes incredibly easy to set up secure web apps and push low-level system management functions down to people without advanced computer knowledge (like the HR department for example).

Re:There is already an LDAP useradd, etc.

[cloudmaster]

5 years ago, I wrote command-line compatible replacements for useradd/userdel/passwd. Then I abandoned LDAP and didn't finish the parts of the programs which were unimplemented (things like enabling usermod to work, and writing chage/chsh). :) I seem to recall there being a web-based password changer written around the same time. I'd be surprised if someone didn't have better stuff by now.

Note, that's perl written by someone without a lot of perl experience at the time, so it could well be the stereotypical unreadable stuff. :) I should really look at it again one day and probably clean it up... Add one more thing to my "when spare time comes" list.

BSD ?

[nurb432]

Any chance this thing will run on Fbsd?

Re:Great

[spauldo]

After all, this is just another example of you Linux people have duplicated/imitated/copied yet another concept from the Windows world so you can do something already doable in Windows!

Not quite. We haven't actually duplicated, as far as I can tell, Active Directory service yet. Samba 4 is trying to do that, I think. I may be wrong about AD not being duplicated yet though.

Either way, Microsoft took LDAP (an established standard which Sun was already gearing up to use for authentication due to the failure of NIS+ and Novell had already been using for quite some time) and mixed it with Kerberos (an ages-old project available on UNIX for years) and tweaked both a little for incompatability's sake to make Active Directory. AD isn't a new concept - more or less, they were copying Novell and using existing tools to do it.

So getting Active Directory to work on Linux (or any mainstream UNIX, for that matter) is just a matter of working around the crap Microsoft added to the existing standards. IIRC, there's not a whole lot, and people have already done it as far as client machines are concerned.

Either way, your basic insinuation about copying is misplaced in this case. Active Directory has no value except in a Windows network. If you just want a network of Linux boxes to share authentication, you don't want Active Directory - there's much better ways of doing it. LDAP (which that's all FDS is - an LDAP server and tools) has a much broader scope than just Active Directory.

MacOS Port?

[tji]

Anyone kow of any efforts to get this working on MacOS?

I am currently using OpenLDAP, which is fine if you're willing to make the effort to learn the details and differences of OpenLDAP. Fedora DS would be much easier to manage, extend the schema, etc.

Hey, its iPlanet 5.1 rebranded!

[FLoWCTRL]

Thank you Sun Microsystems!

Re:Hey, its iPlanet 5.1 rebranded!

[cant_get_a_good_nick]

Technically, it's not the sun stuff, it's Netscape, via AOL. Sun still distributes iPlanet 5.2, and it's pretty old and clunky. Sun's source cut hasn't been updated much sun took it over, and it currently only runs on RH 7.3 (with the evil 2.96 compiler).

RedHat bought the source from AOL, and actually made some changes. It runs on AS3.0, and multiple master is up to 4 nodes. We're switching from iPlanet to FS 1.0, we have it in Dev now.

Re:Linux Users:

[WheelDweller]

Believe me...I tell everyone I meet!

I'd like to see this in SuSE

[kimvette]

I'd like to see this in SuSE (Retail as well as Open). SuSE does have some LDAP management tools but it's not really an alternative to Microsoft's Active Directory yet (blasphemy, I know, but it's hard to argue against point-and-click management of a hierarchical directory service). This is something Linux sorely needs - a strong directory and centralized authentication service that is easy to deploy AND manage, and if a Windows client will work with it, it will be very, very hard to justify paying for Windows server and the gazillion CALs for each server when the same could be had for free on *nix. As long as they keep the CLI for maintenance tasks and mass import/migration of users, they'll have a winner. I hope every major distribution backs one of the tools and works to make it really, really solid.

I don't think this would kill off RHEL or SLES or Novell Linux, because larger organizations will want bundled support and value-added items like subscibed centralized deployment tools, consulting time, and so forth.

Moving along ...

[defunc]

This is the same iPlanet / Netscape LDAP directory that is so 90s now. It still has this clunky Java UI. Why is this news for nerds?

Why would anyone want to suffer like this?

[trolleywobbles]

Fedora? I mean, come on. It's like installing Gentoo, Hell, it's like USING Gentoo. Fedora is just for the boss who heard awesome things about 'TEH LN1UX' and wants to jump on the corporate Linux bandwagon. He only trusts it because it comes from a big company. AHEM. Fedora: deafeating the purpose of Linux, one release at a time.

Re:Why would anyone want to suffer like this?

[trolleywobbles]

Now, I find that quite ofensive! I've been a Gentoo user for three years now, and I've had nothing but good experiences. Have you even TRIED Gentoo? I find it bad enough that you complain about other peoples' distros, but when you;ve never tried them?

Re:Why would anyone want to suffer like this?

[trolleywobbles]

Who said I'd never tried Gentoo? The very reason I'm complaining about it is that I used to be a Gentoo user myself. I mean, apart from the hours upon hours it took to install it, and the laziness that went into it's design (I mean, no package manager? You want me to compile WHAT!?), it's just not a very solid distro. Not to be too cliche, but Ubuntu is the way to go these days. Not since the early days of Debian have I seen such functionality and elegance. You should give it a try.

Re:Why would anyone want to suffer like this?

[trolleywobbles]

You know, I resent that. I've had a lot of experience with both Fedora and Gentoo, and I don't think you have any idea what you're talking about. Both (especially Gentoo) are very maleable distros, and it's just sad you have to rely on your precious package manager to apt-get anything done. The reason you have to compile everything for Gentoo is that it enables much more cross-platform software and programming. But I wouldn't expect you to understand any of this. Just let your Ubuntu lull you into a false sense of security...

Re:Why would anyone want to suffer like this?

[trolleywobbles]

OK, then. I hear ya. It just looked like you were an ignorant troll :P

Re:Why would anyone want to suffer like this?

[trolleywobbles]

No offense taken, though I think you should at least try an Ubuntu Breezy LiveCD. It wouldn't hurt, and you'd see what I'm talking about. I mean, it may just be my opinion, but Gnetoo doesn't agree with me. Ubuntu, as it is their mission, is accessible to anyone and everyone. Hell, my 5-year-old son knows how to use it! So, if nothing else, you'd see another point of Jew. Just my opinion.

good! 1 step closer to an Active Directory killer

[totro2]

This project is nothing less than a breakthrough. Why? There is no "one good LDAP schema". Yet that's what virtually everybody wants.

This project is to LDAP what the Dublin Core is to Zope. It's a common standard that a larger system can be built on (for example, providing complex functionality like Active Directory). Yes, OpenLDAP conforms to the LDAP standard, but a common, standardized LDAP schema that provides a basis for an Active Directory Killer is an even more important standard that everybody doesn't quite seem to realize they are really in lack of.

We shouldn't have 1000 different sites who all want an OSS Active Directory alternative using 1000 different LDAP schemas, all slightly different. That's just stupid.

For those who moan and groan to "just learn LDAP, making a schema is easy", it is your attitude that stifles a real Active Directory killer for emerging.

Nobody wants to learn how to create an LDAP schema. The LDAP notation is ugly. Making a good schema that is will stand the test of time and work with various LDAP-aware programs that are already out there is not trivial. Think LDAP-aware address books in email clients, that expect certain fields in the schema.

This project promises to insulate the end user from needing to learn the internals of writing LDAP schemas. And it provides one LDAP schema to code to in all OSS that has any form of authentication, providing the possibility of the holy grail of "single sign on" (AKA "SSO") in the OSS world. Think data bases, web tools, CMS, email, workstation login, VPN login, etc.

So this is a big deal, IMHO.

Netcraft Confirms It: LINUX IS DEAD.

[trolleywobbles]

Goatse. Gaotse. Ggoatse. Gaaaotsey.

Re:Java Enterprise System from Sun is better produ

[hyc]

OpenLDAP didn't stall, RedHat just continued to ship the same antiquated release years after it was decommissioned by everyone else. OpenLDAP has gotten a ton of undeserved bad press over the past 5 years largely thanks to RedHat never updating the version they bundled.

Fedora Knows Best

[trolleywobbles]

In related news, Ubuntu users have surged past the Gentoo community to become the #1 source of annoying, off-topic distro cheerleading. Whether it's the parent responding to statistics for webserver hosting with DistroWatch numbers or this guy [slashdot.org] responding to a question about JES vs. OES with "[Ubuntu] is the first linux distro that I've recommended to my mom!", they can be counted on for their two cents regardless of the topic. Once again, you see what it looks like when a new distro really starts to get some traction. That's why I don't believe that there are serious numbers of Lindows, TurboLinux or Xandros users out there -- if there were, we'd hear from them.

Re:FANCY gui? Looks like the old Netscape DS GUI

[sbohmann]

They could have changed oh, so much about it by using either the metal look and feel (which, as far as I know, has the exact same sizes for everything as that "butt ugly" default l&f you seem so much to dislike :-), or they could've simply globally turned on antialiasing, change the color scheme a little bit and incrtease font size by one. Increasing font sizes would been the most critical step, but even if they had omitted it and done everything from the main() method and via command line params, it could look SO much better without no effort...

Hey, thanks for the code!

[Medievalist]

I thoroughly read your code before I wrote my own stuff, which is unfortunately so specific to my employers' requirements as to make it useless for anyone else. Your perl was extremely useful to me in the perl-LDAP learning process (I didn't actually cut 'n' paste any of it into my own, but it definitely flavored the way I was looking at our problems).

I was never able to find a PADL-distributed perl chage, though - although I downloaded all their tarballs a year or two ago looking for it - so you might want to change http://www.cloudmaster.com/cloudmaster/projects/fo m-files/cache/72.html
to include a link if PADL's still got it online.

Thanks again!

Re:Hey, thanks for the code!

[cloudmaster]

Cool. Knowing that it helped one person makes the effort totally worthwhile. Thank *you*!

Maybe I'll go ahead and write that chage, then. I'm pretty sure it was in there when I wrote what I wrote, but like I said, I haven't really messed with LDAP for a while (and nss_ldap + pam_ldap took care of most of the orignal reason anyway). Either way, "fix LDAP stuff" is now on my to-do list. :)