Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Fedora Directory Server 1.0 Released! 200

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.
This discussion has been archived. No new comments can be posted.

Fedora Directory Server 1.0 Released!

Comments Filter:
  • wow (Score:5, Insightful)

    by know1 ( 854868 ) on Sunday December 04, 2005 @07:36AM (#14177681)
    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!
  • 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:command line (Score:3, Insightful)

    by Anonymous Coward on Sunday December 04, 2005 @08:16AM (#14177768)
    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:+ Kerberos ? (Score:4, Insightful)

    by Dolda2000 ( 759023 ) <fredrik@dolda200 0 . c om> on Sunday December 04, 2005 @08:35AM (#14177807) Homepage
    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:ldap schmel-dap (Score:2, Insightful)

    by deep44 ( 891922 ) on Sunday December 04, 2005 @09:18AM (#14177891)
    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:+ Kerberos ? (Score:3, Insightful)

    by CRC'99 ( 96526 ) on Sunday December 04, 2005 @09:40AM (#14177947) Homepage
    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 ? (Score:5, Insightful)

    by moreati ( 119629 ) <alex@moreati.org.uk> on Sunday December 04, 2005 @10:00AM (#14178009) Homepage
    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 ? (Score:3, Insightful)

    by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Sunday December 04, 2005 @10:56AM (#14178165)
    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:ldap schmel-dap (Score:2, Insightful)

    by deep44 ( 891922 ) on Sunday December 04, 2005 @12:22PM (#14178499)
    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:+ Kerberos ? (Score:3, Insightful)

    by hkb ( 777908 ) on Sunday December 04, 2005 @02:26PM (#14179173)
    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 ? (Score:1, Insightful)

    by Anonymous Coward on Sunday December 04, 2005 @02:47PM (#14179294)
    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:command line (Score:3, Insightful)

    by dtfinch ( 661405 ) * on Sunday December 04, 2005 @04:55PM (#14179945) Journal
    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.
  • by totro2 ( 758083 ) on Monday December 05, 2005 @02:11AM (#14182907)
    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.

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Working...