open ldap configuration on rhel3-u4

Nilesh Joshi nileshnjoshi at gmail.com
Thu Aug 20 02:14:15 UTC 2009


Hi,

Sorry for late reply. I have copied the file you suggested for me.

It's working for both. I mean for manager and users.

Thanks a lot for the help.

Regards,
-Nilesh

On Tue, Aug 18, 2009 at 2:59 PM, Rick Stevens <ricks at nerd.com> wrote:

> Nilesh Joshi wrote:
>
>> Hi,
>>
>> I think problem got fixed after reediting the slapd.com file.
>>
>
> Did you use my slapd.conf or your own and what did you find that was
> screwey?  Just curious.
>
> I am able to do search now.
>>
>
> As the normal user or only as the root DN?
>
>
> On Mon, Aug 17, 2009 at 12:35 PM, Rick Stevens <ricks at nerd.com> wrote:
>>
>> Nilesh Joshi wrote:
>>>
>>> Hi,
>>>>
>>>> I have done suggested changes in my slapd.com file. Still I see same
>>>> issue.
>>>>
>>>> When I execute command with -Z option, i see:
>>>>
>>>> [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>> "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh"
>>>> ldap_start_tls: Protocol error (2)
>>>>       additional info: unsupported extended operation
>>>> ldap_bind: Invalid credentials (49)
>>>> $
>>>>
>>>> As you can see, the "-Z" forces a TLS startup which we weren't seeing
>>> before.
>>>
>>> My first guess is that your LDAP server or your ldapsearch is not linked
>>> to the OpenSSL libraries or they're using the GnuTLS libraries.  Try
>>> running ldd against your LDAP server and ldapsearch commands:
>>>
>>>       ldd `which slapd`
>>>       ldd `which ldapsearch`
>>>
>>> Verify that "libssl.so*" is listed before any "libgnutls*" files.  If
>>> you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your
>>> ldap.conf, then the order of the certificates in that file has to be
>>> reversed (the CA cert must be the last one in the file).  If you're
>>> using the "TLS_CACERTDIR" option, you may need to rearrange things in
>>> that directory using the "c_rehash" command that's part of the OpenSSL
>>> packages.
>>>
>>> conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389)
>>>
>>>> conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>>>> do_extended: unsupported operation "1.3.6.1.4.1.1466.20037"
>>>> conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation
>>>> conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128
>>>> conn=77 op=1 RESULT tag=97 err=49 text=
>>>> conn=77 fd=10 closed (connection lost
>>>>
>>>> Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT
>>>> IF
>>>> YOU USE SASL.
>>>> How can I verify?
>>>>
>>>> Verify that you're using SASL?  If you don't use the -Z (or -ZZ) and -x
>>> options to ldapsearch you're using SASL by default.  Note that -x alone
>>> tries to do a simple bind to the server.  That's not allowed by default
>>> unless you allow V2 anonymous binds to the LDAP server by adding a line
>>> such as
>>>
>>>       allow bind_v2 bind_anon_cred bind_anon_dn
>>>
>>> to your slapd.conf.  You should also comment out the "security" line in
>>> slapd.conf.  This unsecures your server.  You should then be able to
>>> access it using the root DN.
>>>
>>> I'd recommend you get an LDAP client such as GQ or ldapvi to look at
>>> the entries in the database.  They'll tell you if the password is
>>> encrypted or not.  If you use ldapvi and you don't see anything in curly
>>> braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's
>>> value, then the password is in cleartext and the data you see is the
>>> password.
>>>
>>>
>>>  Hi,
>>>
>>>>   I htink error 49 is not gone till now. It was not showing any output.
>>>>>> I
>>>>>> restarted openladp and started getting same error:
>>>>>> My slapd.conf looks like below (removed commented lines):
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> include         /etc/openldap/schema/core.schema
>>>>>> include         /etc/openldap/schema/cosine.schema
>>>>>> include         /etc/openldap/schema/inetorgperson.schema
>>>>>> pidfile         /usr/var/run/slapd.pid
>>>>>> argsfile        /usr/var/run/slapd.args
>>>>>>  access to dn.base="" by * read
>>>>>>  access to dn.base="cn=Subschema" by * read
>>>>>>  access to *
>>>>>>      by self write
>>>>>>      by users read
>>>>>>      by anonymous auth
>>>>>>     access to attrs=userPassword
>>>>>>             by anonymous auth
>>>>>>             by self write
>>>>>>             by * none
>>>>>>
>>>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem
>>>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem
>>>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem
>>>>>>
>>>>>> database        bdb
>>>>>> suffix          "dc=test,dc=com"
>>>>>> rootdn          "cn=Manager,dc=test,dc=com"
>>>>>> rootpw          XXXX
>>>>>> directory       /usr/var/openldap-data/test.com
>>>>>> index   objectClass     eq
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------------------
>>>>>>
>>>>>> I think need to concentrate on error=49 only.
>>>>>>
>>>>>> You have to be very careful about formatting.  If this is an exact cut
>>>>>>
>>>>> and paste, you still have authentication issues.
>>>>>
>>>>> A leading space in slapd.conf lines can be used to continue previous
>>>>> directives if they can take multiple values such as the "access"
>>>>> directive
>>>>> can.  In the above, you have "access to attrs=userPassword"
>>>>> as a subdirective of the previous "access" directive.
>>>>>
>>>>> Re-edit your config file and make it look like this:
>>>>>
>>>>> include         /etc/openldap/schema/core.schema
>>>>> include         /etc/openldap/schema/cosine.schema
>>>>> include         /etc/openldap/schema/inetorgperson.schema
>>>>> pidfile         /usr/var/run/slapd.pid
>>>>> argsfile        /usr/var/run/slapd.args
>>>>>
>>>>> access to dn.base="" by * read
>>>>>
>>>>> access to dn.base="cn=Subschema" by * read
>>>>>
>>>>> access to *
>>>>>      by self write
>>>>>      by users read
>>>>>      by anonymous auth
>>>>> access to attrs=userPassword
>>>>>      by anonymous auth
>>>>>      by self write
>>>>>      by * none
>>>>>
>>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem
>>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem
>>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem
>>>>>
>>>>> database        bdb
>>>>> suffix          "dc=test,dc=com"
>>>>> rootdn          "cn=Manager,dc=test,dc=com"
>>>>> rootpw          XXXX
>>>>> directory       /usr/var/openldap-data/test.com
>>>>> index   objectClass     eq
>>>>>
>>>>> I suspect that's where things are getting weird.  Personally, I prefer
>>>>> to indent my access directives, so the above bit would look like:
>>>>> ---------------------------------------
>>>>> access to dn.base=""
>>>>>      by * read
>>>>>
>>>>> access to dn.base="cn=Subschema"
>>>>>      by * read
>>>>>
>>>>> access to *
>>>>>      by self write
>>>>>      by users read
>>>>>      by anonymous auth
>>>>>
>>>>> access to attrs=userPassword
>>>>>      by anonymous auth
>>>>>      by self write
>>>>>      by * none
>>>>> ---------------------------------------
>>>>> But that's just me.
>>>>>
>>>>> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not
>>>>> being
>>>>> used, so you're using simple SASL authentication...and again the
>>>>> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL.  Most
>>>>> Linux systems will use an MD5 encryption and that won't work with SASL.
>>>>>
>>>>> You might also want to try adding "-d 255" to the ldapsearch command.
>>>>> That will spit out lots of debug info that may help you sort out just
>>>>> exactly where the thing's dying.
>>>>>
>>>>>
>>>>>
>>>>> What you say?
>>>>>
>>>>>> Regards,
>>>>>> -Nilesh
>>>>>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens <ricks at nerd.com> wrote:
>>>>>>
>>>>>> Nilesh Joshi wrote:
>>>>>>
>>>>>> Hi Rick,
>>>>>>>
>>>>>>> I have generated cert again and started slapd.
>>>>>>>>
>>>>>>>> Now I see following in logs:
>>>>>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389)
>>>>>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128
>>>>>>>> It's same for below 2 commands:
>>>>>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh"
>>>>>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh"
>>>>>>>>
>>>>>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and
>>>>>>>> restarted
>>>>>>>> openldap, the result is same.
>>>>>>>>
>>>>>>>> It looks like error 49 is gone.
>>>>>>>>
>>>>>>>> Ok, if error 49 is gone, but you're not getting any data back, then
>>>>>>>>
>>>>>>>> user "nilesh" probably doesn't have read access to the database.  If
>>>>>>> you have your slapd manual handy, read up on the "access" directives.
>>>>>>>
>>>>>>> If you want a user to see any and all of their info, then you need a
>>>>>>> directive such as:
>>>>>>>
>>>>>>>     access to *
>>>>>>>         by self read
>>>>>>>         by * none
>>>>>>>
>>>>>>> in slapd.conf.  That permits someone to read their own data.  If you
>>>>>>> want to let them modify their data:
>>>>>>>
>>>>>>>     access to *
>>>>>>>         by self write
>>>>>>>         by * none
>>>>>>>
>>>>>>> (note that "write" permission also includes all lower permissions
>>>>>>> such
>>>>>>> as auth, read, search, etc.)
>>>>>>>
>>>>>>> What else I need to do to fix this issue.
>>>>>>> Looks like you're authenticating fine now, but you have to set up
>>>>>>> access
>>>>>>> rules to allow users to see things.  Here's a good on-line reference
>>>>>>> book on how to manage an LDAP server:
>>>>>>>
>>>>>>>     http://www.zytrax.dom/books/ldap
>>>>>>>
>>>>>>> Also, the OpenLDAP System Admin Guide should have been placed in
>>>>>>>
>>>>>>>     /usr/share/doc/openldap-servers-version/guide.html
>>>>>>>
>>>>>>> (replace "version" with the appropriate version number) when you
>>>>>>> installed the OpenLDAP server RPM.  You can view it by opening a
>>>>>>> browser
>>>>>>> and going to
>>>>>>>
>>>>>>>     file:///usr/share/doc/opeenldap-servers-version/guide.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks and Regards,
>>>>>>>
>>>>>>> -Nilesh
>>>>>>>>
>>>>>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens <ricks at nerd.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Nilesh Joshi wrote:
>>>>>>>>
>>>>>>>> Thanks Rick.
>>>>>>>>
>>>>>>>>> I have checked using -w password. The exact command I tried was:
>>>>>>>>>
>>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)'
>>>>>>>>>>
>>>>>>>>>> Did you enclose the password in single quotes to mask its value?
>>>>>>>>>>
>>>>>>>>>> Also added:
>>>>>>>>>>
>>>>>>>>>   access to attrs=userPassword
>>>>>>>>>
>>>>>>>>>           by anonymous auth
>>>>>>>>>>           by self write
>>>>>>>>>>           by * none
>>>>>>>>>>
>>>>>>>>>> That may not be adequate.  That simply allows a user to
>>>>>>>>>> authenticate
>>>>>>>>>>
>>>>>>>>>> against the LDAP database.  It does NOT allow a regular user to
>>>>>>>>>>
>>>>>>>>> search
>>>>>>>>> the entire database.  Let's get rid of the error 49 first, then
>>>>>>>>> we'll
>>>>>>>>> worry about the rest.
>>>>>>>>>
>>>>>>>>> However the result was same. I have confirmed that password is
>>>>>>>>> password
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>> now.
>>>>>>>>>
>>>>>>>>> If you're using SASL, remember that all the passwords must be
>>>>>>>>>> stored
>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>> cleartext.  If the password you're going to use is in the LDAP
>>>>>>>>>>
>>>>>>>>> database,
>>>>>>>>> it must be stored in cleartext--NOT some excrypted format such as
>>>>>>>>>
>>>>>>>>>    {MD5} cypherstring
>>>>>>>>>    {SSHA} cypherstring
>>>>>>>>>
>>>>>>>>> If the password is in the Cyrus SASL database, it too has to be in
>>>>>>>>> cleartext.  This is one of the weaknesses of SASL.
>>>>>>>>>
>>>>>>>>> If you're going to use encrypted passwords in the database, you'll
>>>>>>>>> need
>>>>>>>>> to use SSL or KRB5 as the transport mechanism.
>>>>>>>>>
>>>>>>>>> I think, I am missing something in configuration. Can I use LDAP
>>>>>>>>> without
>>>>>>>>>
>>>>>>>>> sasl and if yes, what I need to do?
>>>>>>>>>
>>>>>>>>> You can, but it's not recommended.  Try putting this line in
>>>>>>>>>> slapd.conf:
>>>>>>>>>>
>>>>>>>>>>    allow bind_v2 bind_anon_cred bind_anon_dn
>>>>>>>>>>
>>>>>>>>> Oh, and by the way, we prefer bottom posting on the list.
>>>>>>>>>
>>>>>>>>>  On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens <ricks at nerd.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  Nilesh Joshi wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have installed openldap-2.0.27-23 on my server.
>>>>>>>>>>>
>>>>>>>>>>> I have configured certificate and path is mentioned in slapd.conf
>>>>>>>>>>>> file.
>>>>>>>>>>>>
>>>>>>>>>>>> I am able to create root DN and also able to add user to it.
>>>>>>>>>>>>
>>>>>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me
>>>>>>>>>>>> correct
>>>>>>>>>>>> answers.
>>>>>>>>>>>> Howere, whenever I search using user id, I see error 49.
>>>>>>>>>>>>
>>>>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)'
>>>>>>>>>>>>
>>>>>>>>>>>> In logs, I see:
>>>>>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389)
>>>>>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com"
>>>>>>>>>>>> method=128
>>>>>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text=
>>>>>>>>>>>> conn=11 fd=10 closed (connection lost)
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to have openldap running without sasl.
>>>>>>>>>>>>
>>>>>>>>>>>> How should I configure the same? How can I fix this issue?
>>>>>>>>>>>>
>>>>>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> ldapsearch the right password for the user you're trying to bind
>>>>>>>>>>>> as.
>>>>>>>>>>>>
>>>>>>>>>>>> Try it again, but rather than using the "-W" (interactive) flag,
>>>>>>>>>>> try:
>>>>>>>>>>>
>>>>>>>>>>>   -w 'your-password-here'
>>>>>>>>>>>
>>>>>>>>>>> If the password has shell metacharacters in it, they may be being
>>>>>>>>>>> interpreted by the shell before being handed to the ldapsearch
>>>>>>>>>>> command.
>>>>>>>>>>> Using the -w and the password enclosed in single quotes prevents
>>>>>>>>>>> that.
>>>>>>>>>>>
>>>>>>>>>>> You also have to make sure that the user you're trying to bind as
>>>>>>>>>>> has
>>>>>>>>>>> access to the userPassword attribute in the slapd.conf file:
>>>>>>>>>>>
>>>>>>>>>>>   access to attrs=userPassword
>>>>>>>>>>>           by anonymous auth
>>>>>>>>>>>           by self write
>>>>>>>>>>>           by * none
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>>> - Rick Stevens, Systems Engineer
>>>>>>>>>>>  ricks at nerd.com-
>>>>>>>>>>> - AIM/Skype: therps2        ICQ: 22643734            Yahoo:
>>>>>>>>>>> origrps2
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>>  -
>>>>>>>>>>> - I never drink water because of the disgusting things that fish
>>>>>>>>>>> do
>>>>>>>>>>>  -
>>>>>>>>>>> -                                  in it.
>>>>>>>>>>>  -
>>>>>>>>>>> -                                                      -- WC.
>>>>>>>>>>> Fields
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Redhat-install-list mailing list
>>>>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>>>>> Subject: unsubscribe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Redhat-install-list mailing list
>>>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>>>> Subject: unsubscribe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> - Rick Stevens, Systems Engineer
>>>>>>>>>  ricks at nerd.com-
>>>>>>>>> - AIM/Skype: therps2        ICQ: 22643734            Yahoo:
>>>>>>>>> origrps2
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>>  -
>>>>>>>>> -   Never test for an error condition you don't know how to handle.
>>>>>>>>>  -
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Redhat-install-list mailing list
>>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>>> Subject: unsubscribe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Redhat-install-list mailing list
>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>> Subject: unsubscribe
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> - Rick Stevens, Systems Engineer                      ricks at nerd.com-
>>>>>>> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2
>>>>>>> -
>>>>>>> -
>>>>>>>  -
>>>>>>> -        Brain:  The organ with which we think that we think.
>>>>>>>  -
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Redhat-install-list mailing list
>>>>>>> Redhat-install-list at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>> redhat-install-list-request at redhat.com
>>>>>>> Subject: unsubscribe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Redhat-install-list mailing list
>>>>>> Redhat-install-list at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>> redhat-install-list-request at redhat.com
>>>>>> Subject: unsubscribe
>>>>>>
>>>>>>
>>>>>> --
>>>>> ----------------------------------------------------------------------
>>>>> - Rick Stevens, Systems Engineer                      ricks at nerd.com -
>>>>> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
>>>>> -                                                                    -
>>>>> -                    Do you know where _your_ towel is?              -
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Redhat-install-list mailing list
>>>>> Redhat-install-list at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>> redhat-install-list-request at redhat.com
>>>>> Subject: unsubscribe
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Redhat-install-list mailing list
>>>> Redhat-install-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>> redhat-install-list-request at redhat.com
>>>> Subject: unsubscribe
>>>>
>>>>
>>> --
>>> ----------------------------------------------------------------------
>>> - Rick Stevens, Systems Engineer                      ricks at nerd.com -
>>> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
>>> -                                                                    -
>>> -           What is a "free" gift?  Aren't all gifts free?           -
>>>
>>> ----------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Redhat-install-list mailing list
>>> Redhat-install-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>> redhat-install-list-request at redhat.com
>>> Subject: unsubscribe
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Redhat-install-list mailing list
>> Redhat-install-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>> To Unsubscribe Go To ABOVE URL or send a message to:
>> redhat-install-list-request at redhat.com
>> Subject: unsubscribe
>>
>
>
> --
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer                      ricks at nerd.com -
> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
> -                                                                    -
> -     "Daddy, why doesn't this magnet pick up this floppy disk?"     -
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/redhat-install-list/attachments/20090819/d8b2f404/attachment.htm>


More information about the Redhat-install-list mailing list