From beyonddc.storage at gmail.com Wed Jul 5 20:38:51 2006 From: beyonddc.storage at gmail.com (Chun Tat David Chu) Date: Wed, 5 Jul 2006 16:38:51 -0400 Subject: [Fedora-directory-devel] [Fedora-directory-users] Any recommendation for a decent up to date LDAP book? Message-ID: <20e4c38c0607051338p1b74bbffj3b435b94f50353be@mail.gmail.com> I would like to learn more about the LDAP, but a lot of the book I found on amazon.com are more than 2-3 years old. I am afraid they're out of date. Is there any good books that you guys would like to suggest? I am interested in in-depth LDAP explaination/usages/design/schema design. I don't really want to be product specific because the last 2 years, we already switched 3 directory server. From Sun DS to OpenLDAP to Fedora DS. Thanks in advance! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj at sci.fi Wed Jul 5 20:37:09 2006 From: mj at sci.fi (Mike Jackson) Date: Wed, 05 Jul 2006 23:37:09 +0300 Subject: [Fedora-directory-devel] Re: [Fedora-directory-users] Any recommendation for a decent up to date LDAP book? In-Reply-To: <20e4c38c0607051338p1b74bbffj3b435b94f50353be@mail.gmail.com> References: <20e4c38c0607051338p1b74bbffj3b435b94f50353be@mail.gmail.com> Message-ID: <44AC22F5.2030005@sci.fi> Chun Tat David Chu wrote: > I would like to learn more about the LDAP, but a lot of the book I found > on amazon.com are more than 2-3 years old. I am > afraid they're out of date. > > Is there any good books that you guys would like to suggest? I am > interested in in-depth LDAP explaination/usages/design/schema design. > I don't really want to be product specific because the last 2 years, we > already switched 3 directory server. From Sun DS to OpenLDAP to Fedora DS. What makes you assume that because a book is 3 years old that it's outdated? The LDAP standard hasn't changed since 1997; it's still at version 3. "Understanding and Deploying LDAP Directory Services" is still the best book you could hope to read. -- mike From gfidente at babel.it Mon Jul 10 12:06:32 2006 From: gfidente at babel.it (Giulio Fidente) Date: Mon, 10 Jul 2006 14:06:32 +0200 Subject: [Fedora-directory-devel] build on solaris using gcc Message-ID: <44B242C8.5000708@babel.it> i've read carefully the build documentation written for solaris, but it assumes i'm using the sun workshop and the procedure does not work unmodified for gcc someone has experiences about the build process using gcc and/or has documentation about that? thanks in advance :-D -- Giulio Fidente Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) From rcritten at redhat.com Mon Jul 10 12:32:03 2006 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Jul 2006 08:32:03 -0400 Subject: [Fedora-directory-devel] build on solaris using gcc In-Reply-To: <44B242C8.5000708@babel.it> References: <44B242C8.5000708@babel.it> Message-ID: <44B248C3.5010207@redhat.com> Giulio Fidente wrote: > i've read carefully the build documentation written for solaris, but it > assumes i'm using the sun workshop and the procedure does not work > unmodified for gcc > > someone has experiences about the build process using gcc and/or has > documentation about that? > > thanks in advance :-D I haven't built on Solaris using gcc in a while but it does work. Some things, especially the things from mozilla.org, need to be told to use gcc. Generally what I did is: export CC=gcc export CXX=g++ This will force the right compiler for sasl, db4, etc. For NSS/NSPR/LDAPSDK/SVRCORE pass in the flag NS_USE_GCC=1 on the gmake command-line. You'll also need this when building the FDS code, something like: % gmake USE_PERL_FROM_PATH=1 NS_USE_GCC=1 BUILD_DEBUG=optimize rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From martinez_brain at hotmail.com Tue Jul 11 19:18:08 2006 From: martinez_brain at hotmail.com (Brian Martinez) Date: Tue, 11 Jul 2006 14:18:08 -0500 Subject: [Fedora-directory-devel] Solaris 10 Client Install In-Reply-To: <44B248C3.5010207@redhat.com> Message-ID: All, Does anyone have information specific to the configuration of Solaris 10 acting as a LDAP client to a Fedora-DS Server for the purpose of User Authentication? I have several Sun Blade 2500's running Solaris 10 that require the ability to utilize a central authentication system and I prefer to use FDS on a RH Linux platform. I hold out hope that this has been attempted/accomplished by the real experts and I can leverage that work in completing this task. Thank you in advance, Brian From snickell at stanfordalumni.org Mon Jul 17 19:24:05 2006 From: snickell at stanfordalumni.org (Seth Nickell) Date: Mon, 17 Jul 2006 12:24:05 -0700 Subject: [Fedora-directory-devel] enumerating security problems Message-ID: <853cc1c00607171224g5c84626x70d89628424db1e2@mail.gmail.com> http://directory.fedora.redhat.com/wiki/Security_Problems I'm building up a list of general, problematic security vulnerabilities that are common across computer networks today. Hopefully we'll be able to explain how to target many of these on the realsecurity website (so I have a bias for problems that can be tackled using the DS/CS/smartcard combo, but we should open it up beyond that too). Would love for other people to jump in and add some (or discuss them in this thread). Here's what I've jotted down thus far: Problem: People choose passwords that are easily guessable/crackable Attack vector: passwords are cracked and the systems compromised Problem: People post important passwords around their workplaces Attack vector: anyone gaining physical access to a building can harvest large numbers of passwords AND account names (usernames are usually derived from the person's name which is also present around their workplace), and use them covertly remotely at a later time Problem: People forget their passwords and have to get them reset frequently Attack vector: as the frequency of password resets increases, it is natural for, e.g. help desk personel to become lax in when and why they will re-issue a password. This increases vulnerability to social engineering. If resetting passwords is a big deal and an unusual event, this is much less likely to occur. But that is only feasible if people don't forget their passwords. Problem: Computer screens are rarely locked when unattended Attack vector: By gaining physical access to a computer not only can a variety of keylogging and other intrusive programs be installed, not only can data be taken, but immediate access to other resources is often granted (from open ssh logins to file shares). This is particularly problematic on modern operating systems featuring a "keychain" which caches passwords for a login. Once the computer is unlocked access to a variety of remote resources is typically also granted. Problem: Stored data and sent messages, even highly sensitive ones, are rarely encrypted Why? Its a PITA to encrypt things, maintain a set of keys/certs between systems, etc Problem: Its relatively easy to learn secret information such as passwords through social engineering, and this is typically all that is required to gain access to a computer system Problem: Computers are not updated and contain many security vulnerabilities This is often ameliorated by the presence of a firewall, but it does render the inside of the network extremely soft once penetrated -Seth From mj at sci.fi Mon Jul 17 19:47:18 2006 From: mj at sci.fi (Mike Jackson) Date: Mon, 17 Jul 2006 22:47:18 +0300 Subject: [Fedora-directory-devel] enumerating security problems In-Reply-To: <853cc1c00607171224g5c84626x70d89628424db1e2@mail.gmail.com> References: <853cc1c00607171224g5c84626x70d89628424db1e2@mail.gmail.com> Message-ID: <44BBE946.6060507@sci.fi> Seth Nickell wrote: > http://directory.fedora.redhat.com/wiki/Security_Problems > > I'm building up a list of general, problematic security > vulnerabilities that are common across computer networks today. > Hopefully we'll be able to explain how to target many of these on the > realsecurity website (so I have a bias for problems that can be > tackled using the DS/CS/smartcard combo, but we should open it up > beyond that too). Would love for other people to jump in and add some > (or discuss them in this thread). > Hi, How is this relevant to a directory server wiki, which is about a directory server product and how to use it? Out of the seven things you listed, all are common problems, and only one can be mitigated by FDS features - the first one (password policy). BTW, what is the realsecurity website, the one that says "coming soon" in big green letters? Why didn't you just post these things there to begin with? BR, -- mike From snickell at stanfordalumni.org Mon Jul 17 21:05:40 2006 From: snickell at stanfordalumni.org (Seth Nickell) Date: Mon, 17 Jul 2006 14:05:40 -0700 Subject: [Fedora-directory-devel] enumerating security problems In-Reply-To: <44BBE946.6060507@sci.fi> References: <853cc1c00607171224g5c84626x70d89628424db1e2@mail.gmail.com> <44BBE946.6060507@sci.fi> Message-ID: <853cc1c00607171405t5195f67ev30f49630f9deeaa4@mail.gmail.com> Hey Mike, The fedora directory server is one piece of the larger identity/security problem the hurricane team inside RH is tackling. Other major pieces include CA bits (http://www.redhat.com/software/rha/certificate/), a number of components for dealing with smart cards, and work on client-side software such as thunderbird and nss. Most of these are open source (and the ones that aren't are at least moving in that direction), but we haven't built any sort of public visibility for the other bits.... yet. I think one of the problems that becomes painfully obvious when n3wbz start playing with a directory server is that its really a pretty low-level nitty gritty component, and you have to know what you want to do with it today (which, coincidentally, mostly involves authentication, identity, credentials, etc, not so much the "storing data" part). We want to take many of the things people are finding the directory server useful for, and make those goals really direct and easy to achieve. That's what we're working toward now with realsecurity.org, which we'll hopefully be throwing up in a week or two. This isn't going to be some big polished thing yet, but hey, at least we're getting the info out there, right? :-) -Seth (interaction designer, red hat) On 7/17/06, Mike Jackson wrote: > Seth Nickell wrote: > > http://directory.fedora.redhat.com/wiki/Security_Problems > > > > I'm building up a list of general, problematic security > > vulnerabilities that are common across computer networks today. > > Hopefully we'll be able to explain how to target many of these on the > > realsecurity website (so I have a bias for problems that can be > > tackled using the DS/CS/smartcard combo, but we should open it up > > beyond that too). Would love for other people to jump in and add some > > (or discuss them in this thread). > > > > > Hi, > > How is this relevant to a directory server wiki, which is about a > directory server product and how to use it? > > Out of the seven things you listed, all are common problems, and only > one can be mitigated by FDS features - the first one (password policy). > > BTW, what is the realsecurity website, the one that says "coming soon" > in big green letters? Why didn't you just post these things there to > begin with? > > > BR, > -- > mike > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > From James.Deas at warnerbros.com Fri Jul 21 15:50:04 2006 From: James.Deas at warnerbros.com (Deas, Jim) Date: Fri, 21 Jul 2006 08:50:04 -0700 Subject: [Fedora-directory-devel] General use questions and diffs from Netscape Message-ID: <73534A7964A1FF448F75BAC53A6EBF66188E96@wbwburpexmb2.amer.warnerbros.com> I recently completed Redhats course on Directory Services and decided to setup a test deployment using Fedora. In the course of doing this I came across a couple of issues that I need to answer before I could use Directory as a valid authentication system. 1) The web interface appears to create/handle group entrys different from those migrated from the local files using the Redhat class altered paddle scripts. From the class I remember changing the 'group' schema to 'groups'. End result, is there a way to create/manage 'groups' schema entries using the Directory web page that match those created when my existing /etc/group was migrated using the altered paddle scripts. If not, why does Redhat suggest this change in their class? 2) Is there a way that the Directory web page can be used to create new user accounts that include an autogen uid and gid? Currently it appears to create a new user with all the posix data turned off. This is fine from a management position as long as a uid generator exist to keep me safe from producing duplicate uid/gid numbers. Any help is appreciated. Best Regards, JD From rmeggins at redhat.com Fri Jul 21 16:12:53 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 21 Jul 2006 10:12:53 -0600 Subject: [Fedora-directory-devel] General use questions and diffs from Netscape In-Reply-To: <73534A7964A1FF448F75BAC53A6EBF66188E96@wbwburpexmb2.amer.warnerbros.com> References: <73534A7964A1FF448F75BAC53A6EBF66188E96@wbwburpexmb2.amer.warnerbros.com> Message-ID: <44C0FD05.5020309@redhat.com> Deas, Jim wrote: > I recently completed Redhats course on Directory Services and decided to > setup a test deployment using Fedora. In the course of doing this I came > across a couple of issues that I need to answer before I could use > Directory as a valid authentication system. > > 1) The web interface appears to create/handle group entrys different > from those migrated from the local files using the Redhat class altered > paddle scripts. From the class I remember changing the 'group' schema to > 'groups'. End result, is there a way to create/manage 'groups' schema > entries using the Directory web page that match those created when my > existing /etc/group was migrated using the altered paddle scripts. If > not, why does Redhat suggest this change in their class? > Hmm - looks like we need to add support for posix groups to the ds gateway . . . > 2) Is there a way that the Directory web page can be used to create new > user accounts that include an autogen uid and gid? Currently it appears > to create a new user with all the posix data turned off. This is fine > from a management position as long as a uid generator exist to keep me > safe from producing duplicate uid/gid numbers. > There is no uid/gid number generator. > Any help is appreciated. > Best Regards, > JD > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From mj at sci.fi Fri Jul 21 16:07:01 2006 From: mj at sci.fi (Mike Jackson) Date: Fri, 21 Jul 2006 19:07:01 +0300 Subject: [Fedora-directory-devel] General use questions and diffs from Netscape In-Reply-To: <73534A7964A1FF448F75BAC53A6EBF66188E96@wbwburpexmb2.amer.warnerbros.com> References: <73534A7964A1FF448F75BAC53A6EBF66188E96@wbwburpexmb2.amer.warnerbros.com> Message-ID: <44C0FBA5.1040100@sci.fi> Deas, Jim wrote: > I recently completed Redhats course on Directory Services and decided to > setup a test deployment using Fedora. In the course of doing this I came > across a couple of issues that I need to answer before I could use > Directory as a valid authentication system. What did you think about the course? > 1) The web interface appears to create/handle group entrys different > from those migrated from the local files using the Redhat class altered > paddle scripts. From the class I remember changing the 'group' schema to > 'groups'. End result, is there a way to create/manage 'groups' schema > entries using the Directory web page that match those created when my > existing /etc/group was migrated using the altered paddle scripts. If > not, why does Redhat suggest this change in their class? The web interface is not meant to be a full-blown user management solution. You'd do much better with something like phpldapadmin, or writing your own command line tools. > 2) Is there a way that the Directory web page can be used to create new > user accounts that include an autogen uid and gid? Currently it appears > to create a new user with all the posix data turned off. This is fine > from a management position as long as a uid generator exist to keep me > safe from producing duplicate uid/gid numbers. I wrote a user addition script which supports uid uniqueness checking for manually specified uids, as well as auto incrementing of uid if desired (does a search, sorts the uid list, and adds 1). http://www.netauth.com/~jacksonm/ldap/newuser.pl Just edit the configuration section to match your setup, and you're all set. NOTE that this is not a very advanced tool, but the price is right :-) I have written some very advanced ones, but they are not open source... BR, Mike -- http://www.netauth.com - LDAP Directory Consulting From DJD at FISCHERINTERNATIONAL.COM Fri Jul 21 16:52:41 2006 From: DJD at FISCHERINTERNATIONAL.COM (Dan.Dagnall) Date: Fri, 21 Jul 2006 12:52:41 -0400 Subject: [Fedora-directory-devel] General use questions and diffs fromNetscape In-Reply-To: <44C0FBA5.1040100@sci.fi> Message-ID: <3671C2002ECC9149B2B5509290F533A62B08D4@fiscex.FISCHERINTERNATIONAL.COM> I am a newbie to Fedora DS. Is there anyone (or site) out there that can walk me through the steps needed? -----Original Message----- From: fedora-directory-devel-bounces at redhat.com [mailto:fedora-directory-devel-bounces at redhat.com] On Behalf Of Mike Jackson Sent: Friday, July 21, 2006 12:07 PM To: Fedora Directory server developer discussion. Subject: Re: [Fedora-directory-devel] General use questions and diffs fromNetscape Deas, Jim wrote: > I recently completed Redhats course on Directory Services and decided to > setup a test deployment using Fedora. In the course of doing this I came > across a couple of issues that I need to answer before I could use > Directory as a valid authentication system. What did you think about the course? > 1) The web interface appears to create/handle group entrys different > from those migrated from the local files using the Redhat class altered > paddle scripts. From the class I remember changing the 'group' schema to > 'groups'. End result, is there a way to create/manage 'groups' schema > entries using the Directory web page that match those created when my > existing /etc/group was migrated using the altered paddle scripts. If > not, why does Redhat suggest this change in their class? The web interface is not meant to be a full-blown user management solution. You'd do much better with something like phpldapadmin, or writing your own command line tools. > 2) Is there a way that the Directory web page can be used to create new > user accounts that include an autogen uid and gid? Currently it appears > to create a new user with all the posix data turned off. This is fine > from a management position as long as a uid generator exist to keep me > safe from producing duplicate uid/gid numbers. I wrote a user addition script which supports uid uniqueness checking for manually specified uids, as well as auto incrementing of uid if desired (does a search, sorts the uid list, and adds 1). http://www.netauth.com/~jacksonm/ldap/newuser.pl Just edit the configuration section to match your setup, and you're all set. NOTE that this is not a very advanced tool, but the price is right :-) I have written some very advanced ones, but they are not open source... BR, Mike -- http://www.netauth.com - LDAP Directory Consulting -- Fedora-directory-devel mailing list Fedora-directory-devel at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel ************************************************************************************************************************** This mail message may contain confidential and privileged information from Fischer International which is protected. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ************************************************************************************************************************** From James.Deas at warnerbros.com Fri Jul 21 19:33:26 2006 From: James.Deas at warnerbros.com (Deas, Jim) Date: Fri, 21 Jul 2006 12:33:26 -0700 Subject: [Fedora-directory-devel] General use questions and diffs fromNetscape Message-ID: <73534A7964A1FF448F75BAC53A6EBF66E6C2E5@wbwburpexmb2.amer.warnerbros.com> Thanks for the input. I would not recommend RH423 for those who are trying to immediately deploy ldap or Keberos across a network. There is just no way someone new to ldap/Kerberos can gain enough insight into all the possible problems and gotchas in four days of instruction! If you need to use ldap immediately hire a good consultant! I do highly recommend the course to those who have time to plot and plan their implementation. The course was very good about walking through all the cli tools and the steps needed to create and manage ldap. Even if you plan to use openldap directly and not Redhat Directory Service, the course is worth the time. It gives you a quick foundation to build on. Phpldapadmin is where I am going to start. Has anyone seen a practical implementation using Webmin? -----Original Message----- From: fedora-directory-devel-bounces at redhat.com [mailto:fedora-directory-devel-bounces at redhat.com] On Behalf Of Mike Jackson Sent: Friday, July 21, 2006 9:07 AM To: Fedora Directory server developer discussion. Subject: Re: [Fedora-directory-devel] General use questions and diffs fromNetscape Deas, Jim wrote: > I recently completed Redhats course on Directory Services and decided to > setup a test deployment using Fedora. In the course of doing this I came > across a couple of issues that I need to answer before I could use > Directory as a valid authentication system. What did you think about the course? > 1) The web interface appears to create/handle group entrys different > from those migrated from the local files using the Redhat class altered > paddle scripts. From the class I remember changing the 'group' schema to > 'groups'. End result, is there a way to create/manage 'groups' schema > entries using the Directory web page that match those created when my > existing /etc/group was migrated using the altered paddle scripts. If > not, why does Redhat suggest this change in their class? The web interface is not meant to be a full-blown user management solution. You'd do much better with something like phpldapadmin, or writing your own command line tools. > 2) Is there a way that the Directory web page can be used to create new > user accounts that include an autogen uid and gid? Currently it appears > to create a new user with all the posix data turned off. This is fine > from a management position as long as a uid generator exist to keep me > safe from producing duplicate uid/gid numbers. I wrote a user addition script which supports uid uniqueness checking for manually specified uids, as well as auto incrementing of uid if desired (does a search, sorts the uid list, and adds 1). http://www.netauth.com/~jacksonm/ldap/newuser.pl Just edit the configuration section to match your setup, and you're all set. NOTE that this is not a very advanced tool, but the price is right :-) I have written some very advanced ones, but they are not open source... BR, Mike -- http://www.netauth.com - LDAP Directory Consulting -- Fedora-directory-devel mailing list Fedora-directory-devel at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel From rmeggins at redhat.com Wed Jul 26 00:44:41 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 25 Jul 2006 18:44:41 -0600 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? Message-ID: <44C6BAF9.7040803@redhat.com> I'm trying to make admin server install and run without having to use setup, which means I have to use hard coded values. Since directory server listens to port 389, and I don't want to have admin server listen to a low port (< 1024), how about 1389? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From mj at sci.fi Wed Jul 26 00:38:30 2006 From: mj at sci.fi (Mike Jackson) Date: Wed, 26 Jul 2006 03:38:30 +0300 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? In-Reply-To: <44C6BAF9.7040803@redhat.com> References: <44C6BAF9.7040803@redhat.com> Message-ID: <44C6B986.7020501@sci.fi> Richard Megginson wrote: > I'm trying to make admin server install and run without having to use > setup, which means I have to use hard coded values. Since directory > server listens to port 389, and I don't want to have admin server listen > to a low port (< 1024), how about 1389? Hi, I have used 1500 for all of my servers: It's easy to remember! Just an idea... -- mike From nhosoi at redhat.com Wed Jul 26 00:57:45 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 25 Jul 2006 17:57:45 -0700 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? In-Reply-To: <44C6BAF9.7040803@redhat.com> References: <44C6BAF9.7040803@redhat.com> Message-ID: <44C6BE09.6010109@redhat.com> Richard Megginson wrote: > I'm trying to make admin server install and run without having to use > setup, which means I have to use hard coded values. Since directory > server listens to port 389, and I don't want to have admin server > listen to a low port (< 1024), how about 1389? Do you have a plan to keep retrying with some other value till it finds out an unused port? (e.g., p = 1389; p++; or p +=1000; ?) >------------------------------------------------------------------------ > >-- >Fedora-directory-devel mailing list >Fedora-directory-devel at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Jul 26 01:20:09 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 25 Jul 2006 19:20:09 -0600 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? In-Reply-To: <44C6BE09.6010109@redhat.com> References: <44C6BAF9.7040803@redhat.com> <44C6BE09.6010109@redhat.com> Message-ID: <44C6C349.1050809@redhat.com> Noriko Hosoi wrote: > Richard Megginson wrote: > >> I'm trying to make admin server install and run without having to use >> setup, which means I have to use hard coded values. Since directory >> server listens to port 389, and I don't want to have admin server >> listen to a low port (< 1024), how about 1389? > > Do you have a plan to keep retrying with some other value till it > finds out an unused port? (e.g., p = 1389; p++; or p +=1000; ?) No, this would be for the port value hardcoded in to the apache config file. So it's important to pick a good default that isn't used by another well known service. I'm thinking that it would be wise to allow the user to install the rpm/pkg and specify another port e.g. rpm --define 'adminport 983'. There will also be the usual setup script/program which will allow the user to change the port post-install. > >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Jul 26 01:30:50 2006 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 25 Jul 2006 18:30:50 -0700 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? In-Reply-To: <44C6C349.1050809@redhat.com> References: <44C6BAF9.7040803@redhat.com> <44C6BE09.6010109@redhat.com> <44C6C349.1050809@redhat.com> Message-ID: <44C6C5CA.1090704@redhat.com> Richard Megginson wrote: > Noriko Hosoi wrote: > >> Richard Megginson wrote: >> >>> I'm trying to make admin server install and run without having to >>> use setup, which means I have to use hard coded values. Since >>> directory server listens to port 389, and I don't want to have admin >>> server listen to a low port (< 1024), how about 1389? >> >> >> Do you have a plan to keep retrying with some other value till it >> finds out an unused port? (e.g., p = 1389; p++; or p +=1000; ?) > > No, this would be for the port value hardcoded in to the apache config > file. So it's important to pick a good default that isn't used by > another well known service. I'm thinking that it would be wise to > allow the user to install the rpm/pkg and specify another port e.g. > rpm --define 'adminport 983'. There will also be the usual setup > script/program which will allow the user to change the port post-install. Cool! I like your proposal. How about the admin user uid? It's "admin" by default and allowed to change it (you could do it later, too). Is it needed? I'm thinking how to simplify the Admin User cache for the auth... >> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-devel mailing list >>> Fedora-directory-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >>> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > >------------------------------------------------------------------------ > >-- >Fedora-directory-devel mailing list >Fedora-directory-devel at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Jul 26 01:36:41 2006 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 25 Jul 2006 19:36:41 -0600 Subject: [Fedora-directory-devel] Hard coded port number for admin server - 1389? In-Reply-To: <44C6C5CA.1090704@redhat.com> References: <44C6BAF9.7040803@redhat.com> <44C6BE09.6010109@redhat.com> <44C6C349.1050809@redhat.com> <44C6C5CA.1090704@redhat.com> Message-ID: <44C6C729.20404@redhat.com> Noriko Hosoi wrote: > Richard Megginson wrote: > >> Noriko Hosoi wrote: >> >>> Richard Megginson wrote: >>> >>>> I'm trying to make admin server install and run without having to >>>> use setup, which means I have to use hard coded values. Since >>>> directory server listens to port 389, and I don't want to have >>>> admin server listen to a low port (< 1024), how about 1389? >>> >>> >>> Do you have a plan to keep retrying with some other value till it >>> finds out an unused port? (e.g., p = 1389; p++; or p +=1000; ?) >> >> No, this would be for the port value hardcoded in to the apache >> config file. So it's important to pick a good default that isn't >> used by another well known service. I'm thinking that it would be >> wise to allow the user to install the rpm/pkg and specify another >> port e.g. rpm --define 'adminport 983'. There will also be the usual >> setup script/program which will allow the user to change the port >> post-install. > > Cool! I like your proposal. How about the admin user uid? It's > "admin" by default and allowed to change it (you could do it later, > too). Is it needed? I'm thinking how to simplify the Admin User > cache for the auth... Yes. I think admin by default. > >>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> Fedora-directory-devel mailing list >>>> Fedora-directory-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-devel mailing list >>> Fedora-directory-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: