Repair replication

[Herb Burnswell <herbert.burnswell@xxxxxxxxx>]

On Tue, Apr 3, 2012 at 2:59 PM, <389-users-request@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Send 389-users mailing list submissions to
       389-users@xxxxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
       https://admin.fedoraproject.org/mailman/listinfo/389-users
or, via email, send a message with subject or body 'help' to
       389-users-request@xxxxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
       389-users-owner@xxxxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of 389-users digest..."


Today's Topics:

  1.  Repair replication (Herb Burnswell)
  2. Re: Repair replication (Jim Finn)


----------------------------------------------------------------------

Message: 1
Date: Tue, 3 Apr 2012 14:55:37 -0700
From: Herb Burnswell <herbert.burnswell@xxxxxxxxx>
To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx
Subject:  Repair replication
Message-ID:
       <CAOuzmw4659u30rHUn+D9r2zbh9dFFPyKYmc+5A2LxOfDEEdD8g@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

---------- Forwarded message ----------
From: Rich Megginson <rmeggins@xxxxxxxxxx>
Date: Mon, Apr 2, 2012 at 7:37 PM
Subject: Re: Fwd: Repair replication
To: "General discussion list for the 389 Directory server project." <
389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Cc: Herb Burnswell <herbert.burnswell@xxxxxxxxx>


 On 04/02/2012 05:48 PM, Herb Burnswell wrote:



---------- Forwarded message ----------
From: Rich Megginson <rmeggins@xxxxxxxxxx>
Date: Mon, Apr 2, 2012 at 3:23 PM
Subject: Re: Repair replication
To: "General discussion list for the 389 Directory server project." <
389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Cc: Herb Burnswell <herbert.burnswell@xxxxxxxxx>


 On 04/02/2012 04:13 PM, Herb Burnswell wrote:



On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins@xxxxxxxxxx>wrote:

>  On 03/23/2012 11:09 AM, Herb Burnswell wrote:
>
> Thanks for the reply David.
>
> >> 1. How can I find out which system(s) is/are master, consumer, hub, etc?
> >>>>You should be able to determine the role of the Directory Server for
> each
> >>>>system by logging into the LDAP console under
> >>>>"Configuration->Replication".  The role is either "Single Master",
> "Hub" or
> >>>>"Dedicated Consumer".
>
> >I was able to determine that we have two "Multiple Master" systems.
> Let's call >them 'A' and 'B'.  System A has been the only system running
> for what appears to >be several years (it is being backed up nightly).
> System B has been off for some >time but is running now.
>
> >> 2. How do I confirm that the systems have the correct credentials for
> >replication? (I am receiving: "Unable to acquire replica: Permission
> >denied.")
>    >a. How can I change the bind dn "cn=replication,cn=config" credentials
> >on each system to ensure replication will work?
> >>>>You can do that on the console as well.  Just navigate down the
> directory
> >>>>tree and manually reset the password for the replication user account.
> >>>>There's a possibility that your replication user account's password
> expired.
>
> >I can navigate to the screen to reset the password for the replication
> user account.  I >have not reset the passwords yet as I am reading
> documentation to confirm that >system B will simply update it's data to
> system A's upon resuming replication.
>
>  >When you change the password of the replication user on B, you'll also
> have to update >those credentials in the replication agreement on A for the
> agreement from A to B.
>
> >Note that if replication has been down for years, you will have to
> perform a manual >replica initialization procedure - replication will not
> automatically "catch up" if it has >been down that long.
>
>   Rich - Thank you for the response. I was diverted to another urgent
issue but have come back to this replication fix.

I've confirmed that there are two Dedicated Consumer's (C and D) to go
along with the two Dual Master's (A and B). I want to replicate to one of
the dedicated consumers, C, prior to syncing the dual master B. I changed
the passwords for dn:cn=replication,cn=config on A via the Directory
Manager console, and via ldapmodify on C. I am confident that the passwords
are the same on both systems.


 >What exactly did you do?
>Note that you'll have to update the password in cn=replication,cn=config
on the >consumer (C) and update the replication agreement on A for the
replication agreement >between A and C.

Thanks for the reply Rich.  Yes, I updated the password on A and C.  I
apologize as I left out the link in my below reference to section 8.10.5.1:
http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html.
I used bak2db with backup files from A.  After which, I see: "Unable to
acquire replica: permission denied. The bind dn "cn=replication,cn=config"
does not have permission to supply replication updates to the replica. Will
retry later." on system A's error logs..

>I think doing the restore is resetting the password.  After doing the
bak2db, change the >passwords.

Well, I'm kind of at a loss here.  I've reset the passwords on A and C
after doing the bak2db.  Same error:


Unable to acquire replica: permission denied. The bind dn
"cn=replication,cn=config" does not have permission to supply replication
updates to the replica. Will retry later.

Next, I removed and re-added the replication agreement on Master A to
Consumer C, same error above.

Is there any way that I can output the settings/password information for
cn=replication,cn=config on both A and C via the command line to compare?
I have read that there needs to be a 'person' entry on the consumer for
cn=replication,cn=config that is used for the replication of the data.  Is
there a way I can confirm this configuration to ensure it is set up
correctly?

I'm also seeing this error in the logs on consumer C:

 NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree": Unable to acquire
replica: error: permission denied



>I followed section 8.10.5.1 on initializing the consumer replica from
backup files and it >worked with the following:

>[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
>[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value
/new/path/from/master/server
>[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value
/old/path/from/consumer
>[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is
different from backed up configuration; The backup is restored.

>First, do I need to reset these attributes back to 'readonly' and the
original nsslapd-directory?

>Second, I am now receiving the following error from the master A:
>Unable to acquire replica: permission denied. The bind dn
"cn=replication,cn=config" >does not have permission to supply replication
updates to the replica. Will retry later.

>On another note, I see plain text passwords in the error logs on A for the
consumers >but passwd = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B,
the other >master. Is there specific reason for this?

>As always, any guidance that can be provided is greatly appreciated.

TIA,

Herb

>
> >> 3. I assume that upon repairing replication (apparently it has not been
> working for several years) the systems will all replicate to the most
> recent information.  Correct?
> >>>>I think that's the tricky part.  Make sure you backup your directory
> on all
> >>>>the LDAP first so you have something to roll back.  I *believe* the
> last
> >>>>step when setting up replication is initializing the directory and that
> >>>>will wipe out directory on the other LDAP.  Someone on the list might
>  be
> >>>>able to provide a better on this but I am just giving you a heads up
> that
> >>>>this can be a complicated process.
>
> Given the fact that system B has not been running for some time, ideally
> it would simply replicate to the current data on system A.  After
> replication is reestablished the systems are set up to "Always keep
> directories in sync".  If anyone can confirm the behavior that will occur
> upon replication on these two systems it would be greatly appreciated.
>
> Thanks in advance,
>
> Herb
>
>
>  ------------------------------
>>
>> Message: 2
>> Date: Thu, 22 Mar 2012 10:40:34 -0400
>> From: Chun Tat David Chu <beyonddc.storage@xxxxxxxxx>
>> To: "General discussion list for the 389 Directory server project."
>>        <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>> Subject: Re: Repair replication
>> Message-ID:
>>        <
>> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g@xxxxxxxxxxxxxx>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hey Herb,
>>
>> You should refer to the Red Hat Directory Server administration guide for
>> detail about setting up replication which you can locate in here.
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
>>
>> >> 1. How can I find out which system(s) is/are master, consumer, hub,
>> etc?
>> You should be able to determine the role of the Directory Server for each
>> system by logging into the LDAP console under
>> "Configuration->Replication".  The role is either "Single Master", "Hub"
>> or
>> "Dedicated Consumer".
>>
>> >> 2. How do I confirm that the systems have the correct credentials for
>> replication? (I am receiving: "Unable to acquire replica: Permission
>> denied.")
>>    a. How can I change the bind dn "cn=replication,cn=config" credentials
>> on each system to ensure replication will work?
>> You can do that on the console as well.  Just navigate down the directory
>> tree and manually reset the password for the replication user account.
>> There's a possibility that your replication user account's password
>> expired.
>>
>> >> 3. I assume that upon repairing replication (apparently it has not been
>> working for several years) the systems will all replicate to the most
>> recent information.  Correct?
>> I think that's the tricky part.  Make sure you backup your directory on
>> all
>> the LDAP first so you have something to roll back.  I *believe* the last
>> step when setting up replication is initializing the directory and that
>> will wipe out directory on the other LDAP.  Someone on the list might  be
>> able to provide a better on this but I am just giving you a heads up that
>> this can be a complicated process.
>>
>> Good luck
>>
>> - David
>>
>> 2012/3/21 Herb Burnswell <herbert.burnswell@xxxxxxxxx>
>>
>> > Hi All,
>> >
>> > I'm new to LDAP administration and have been tasked with fixing the
>> system
>> > replication of 4 Linux systems running Fedora Directory Services.  I am
>> > very comfortable working with Linux/Unix but am not experienced with
>> LDAP.
>> > I've been reading the communications from this user group and reading as
>> > much as I can from documentation.  I believe this environment is not too
>> > complex but I am looking for some guidance, any assistance is greatly
>> > appreciated.
>> >
>> > Info:
>> >
>> > OS: Fedora Core 4
>> > LDAP: Fedora Directory Server v 7.1
>> >
>> > First, I know that both the systems and FDS versions are ancient.
>> > However, at this point I need to get the replication working prior to
>> > putting together a migration plan.  I have access to the Directory
>> Manager
>> > console and am comfortable running command line commands as well.
>>  Either
>> > way is fine.
>> >
>> > Questions:
>> >
>> > 1. How can I find out which system(s) is/are master, consumer, hub, etc?
>> >
>> > 2. How do I confirm that the systems have the correct credentials for
>> > replication? (I am receiving: "Unable to acquire replica: Permission
>> > denied.")
>> >     a. How can I change the bind dn "cn=replication,cn=config"
>> credentials
>> > on each system to ensure replication will work?
>> >
>> > 3. I assume that upon repairing replication (apparently it has not been
>> > working for several years) the systems will all replicate to the most
>> > recent information.  Correct?
>> >
>> > Again, any guidance is greatly appreciated.
>> >
>> > Thanks in advance,
>> >
>> > Herb
>> >
>> > --
>> > 389 users mailing list
>> > 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edfe5e8f/attachment-0001.html
>> >
>>
>>
>
> --
> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>


--
389 users mailing
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120403/834cbb94/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 3 Apr 2012 16:59:38 -0500
From: Jim Finn <jamespfinn@xxxxxxxxx>
To: "General discussion list for the 389 Directory server project."
       <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Repair replication
Message-ID:
       <CAHx81c8Qw+3LMMbPC7+7gAXsJaMXPUTh=gD-S20h681oUMsX+A@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

This can be caused by replication dn having an expired password.

Thanks Jim.  Yea, I've reset the passwords on the Master and Consumer several times to no avail.  I continually receive the errors:

Master = Unable to acquire replica: permission denied. The bind dn "cn=replication,cn=config" does not have permission to supply replication updates to the replica. Will retry later.

Consumer = NSMMReplicationPlugin - conn=198 op=3 replica="o=mytree": Unable to acquire replica: error: permission denied

 

On Tue, Apr 3, 2012 at 4:55 PM, Herb Burnswell
<herbert.burnswell@xxxxxxxxx>wrote:

>
> ---------- Forwarded message ----------
> From: Rich Megginson <rmeggins@xxxxxxxxxx>
>  Date: Mon, Apr 2, 2012 at 7:37 PM
> Subject: Re: Fwd: Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: Herb Burnswell <herbert.burnswell@xxxxxxxxx>
>
>
>  On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>
>
>
> ---------- Forwarded message ----------
> From: Rich Megginson <rmeggins@xxxxxxxxxx>
> Date: Mon, Apr 2, 2012 at 3:23 PM
> Subject: Re: Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: Herb Burnswell <herbert.burnswell@xxxxxxxxx>
>
>
>  On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>
>
>
> On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins@xxxxxxxxxx>wrote:
>
>>  On 03/23/2012 11:09 AM, Herb Burnswell wrote:
>>
>> Thanks for the reply David.
>>
>> >> 1. How can I find out which system(s) is/are master, consumer, hub,
>> etc?
>> >>>>You should be able to determine the role of the Directory Server for
>> each
>> >>>>system by logging into the LDAP console under
>> >>>>"Configuration->Replication".  The role is either "Single Master",
>> "Hub" or
>> >>>>"Dedicated Consumer".
>>
>> >I was able to determine that we have two "Multiple Master" systems.
>> Let's call >them 'A' and 'B'.  System A has been the only system running
>> for what appears to >be several years (it is being backed up nightly).
>> System B has been off for some >time but is running now.
>>
>> >> 2. How do I confirm that the systems have the correct credentials for
>> >replication? (I am receiving: "Unable to acquire replica: Permission
>> >denied.")
>>    >a. How can I change the bind dn "cn=replication,cn=config" credentials
>> >on each system to ensure replication will work?
>> >>>>You can do that on the console as well.  Just navigate down the
>> directory
>> >>>>tree and manually reset the password for the replication user account.
>> >>>>There's a possibility that your replication user account's password
>> expired.
>>
>> >I can navigate to the screen to reset the password for the replication
>> user account.  I >have not reset the passwords yet as I am reading
>> documentation to confirm that >system B will simply update it's data to
>> system A's upon resuming replication.
>>
>>  >When you change the password of the replication user on B, you'll also
>> have to update >those credentials in the replication agreement on A for the
>> agreement from A to B.
>>
>> >Note that if replication has been down for years, you will have to
>> perform a manual >replica initialization procedure - replication will not
>> automatically "catch up" if it has >been down that long.
>>
>>   Rich - Thank you for the response. I was diverted to another urgent
> issue but have come back to this replication fix.
>
> I've confirmed that there are two Dedicated Consumer's (C and D) to go
> along with the two Dual Master's (A and B). I want to replicate to one of
> the dedicated consumers, C, prior to syncing the dual master B. I changed
> the passwords for dn:cn=replication,cn=config on A via the Directory
> Manager console, and via ldapmodify on C. I am confident that the passwords
> are the same on both systems.
>
>
>  >What exactly did you do?
> >Note that you'll have to update the password in cn=replication,cn=config
> on the >consumer (C) and update the replication agreement on A for the
> replication agreement >between A and C.
>
> Thanks for the reply Rich.  Yes, I updated the password on A and C.  I
> apologize as I left out the link in my below reference to section 8.10.5.1:
>
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html.
> I used bak2db with backup files from A.  After which, I see: "Unable to
> acquire replica: permission denied. The bind dn "cn=replication,cn=config"
> does not have permission to supply replication updates to the replica. Will
> retry later." on system A's error logs..
>
> >I think doing the restore is resetting the password.  After doing the
> bak2db, change the >passwords.
>
> Well, I'm kind of at a loss here.  I've reset the passwords on A and C
> after doing the bak2db.  Same error:
>
>
> Unable to acquire replica: permission denied. The bind dn
> "cn=replication,cn=config" does not have permission to supply replication
> updates to the replica. Will retry later.
>
> Next, I removed and re-added the replication agreement on Master A to
> Consumer C, same error above.
>
> Is there any way that I can output the settings/password information for
> cn=replication,cn=config on both A and C via the command line to compare?
> I have read that there needs to be a 'person' entry on the consumer for
> cn=replication,cn=config that is used for the replication of the data.  Is
> there a way I can confirm this configuration to ensure it is set up
> correctly?
>
> I'm also seeing this error in the logs on consumer C:
>
>  NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree": Unable to acquire
> replica: error: permission denied
>
>
>
>
> >I followed section 8.10.5.1 on initializing the consumer replica from
> backup files and it >worked with the following:
>
> >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
> >[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value
> /new/path/from/master/server
> >[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value
> /old/path/from/consumer
> >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is
> different from backed up configuration; The backup is restored.
>
> >First, do I need to reset these attributes back to 'readonly' and the
> original nsslapd-directory?
>
> >Second, I am now receiving the following error from the master A:
> >Unable to acquire replica: permission denied. The bind dn
> "cn=replication,cn=config" >does not have permission to supply replication
> updates to the replica. Will retry later.
>
> >On another note, I see plain text passwords in the error logs on A for
> the consumers >but passwd = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for
> B, the other >master. Is there specific reason for this?
>
> >As always, any guidance that can be provided is greatly appreciated.
>
> TIA,
>
> Herb
>
>>
>> >> 3. I assume that upon repairing replication (apparently it has not been
>> working for several years) the systems will all replicate to the most
>> recent information.  Correct?
>> >>>>I think that's the tricky part.  Make sure you backup your directory
>> on all
>> >>>>the LDAP first so you have something to roll back.  I *believe* the
>> last
>> >>>>step when setting up replication is initializing the directory and
>> that
>> >>>>will wipe out directory on the other LDAP.  Someone on the list might
>>  be
>> >>>>able to provide a better on this but I am just giving you a heads up
>> that
>> >>>>this can be a complicated process.
>>
>> Given the fact that system B has not been running for some time, ideally
>> it would simply replicate to the current data on system A.  After
>> replication is reestablished the systems are set up to "Always keep
>> directories in sync".  If anyone can confirm the behavior that will occur
>> upon replication on these two systems it would be greatly appreciated.
>>
>> Thanks in advance,
>>
>> Herb
>>
>>
>>  ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 22 Mar 2012 10:40:34 -0400
>>> From: Chun Tat David Chu <beyonddc.storage@xxxxxxxxx>
>>> To: "General discussion list for the 389 Directory server project."
>>>        <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>>> Subject: Re: Repair replication
>>> Message-ID:
>>>        <
>>> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g@xxxxxxxxxxxxxx>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hey Herb,
>>>
>>> You should refer to the Red Hat Directory Server administration guide for
>>> detail about setting up replication which you can locate in here.
>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
>>>
>>> >> 1. How can I find out which system(s) is/are master, consumer, hub,
>>> etc?
>>> You should be able to determine the role of the Directory Server for each
>>> system by logging into the LDAP console under
>>> "Configuration->Replication".  The role is either "Single Master", "Hub"
>>> or
>>> "Dedicated Consumer".
>>>
>>> >> 2. How do I confirm that the systems have the correct credentials for
>>> replication? (I am receiving: "Unable to acquire replica: Permission
>>> denied.")
>>>    a. How can I change the bind dn "cn=replication,cn=config" credentials
>>> on each system to ensure replication will work?
>>> You can do that on the console as well.  Just navigate down the directory
>>> tree and manually reset the password for the replication user account.
>>> There's a possibility that your replication user account's password
>>> expired.
>>>
>>> >> 3. I assume that upon repairing replication (apparently it has not
>>> been
>>> working for several years) the systems will all replicate to the most
>>> recent information.  Correct?
>>> I think that's the tricky part.  Make sure you backup your directory on
>>> all
>>> the LDAP first so you have something to roll back.  I *believe* the last
>>> step when setting up replication is initializing the directory and that
>>> will wipe out directory on the other LDAP.  Someone on the list might  be
>>> able to provide a better on this but I am just giving you a heads up that
>>> this can be a complicated process.
>>>
>>> Good luck
>>>
>>> - David
>>>
>>> 2012/3/21 Herb Burnswell <herbert.burnswell@xxxxxxxxx>
>>>
>>> > Hi All,
>>> >
>>> > I'm new to LDAP administration and have been tasked with fixing the
>>> system
>>> > replication of 4 Linux systems running Fedora Directory Services.  I am
>>> > very comfortable working with Linux/Unix but am not experienced with
>>> LDAP.
>>> > I've been reading the communications from this user group and reading
>>> as
>>> > much as I can from documentation.  I believe this environment is not
>>> too
>>> > complex but I am looking for some guidance, any assistance is greatly
>>> > appreciated.
>>> >
>>> > Info:
>>> >
>>> > OS: Fedora Core 4
>>> > LDAP: Fedora Directory Server v 7.1
>>> >
>>> > First, I know that both the systems and FDS versions are ancient.
>>> > However, at this point I need to get the replication working prior to
>>> > putting together a migration plan.  I have access to the Directory
>>> Manager
>>> > console and am comfortable running command line commands as well.
>>>  Either
>>> > way is fine.
>>> >
>>> > Questions:
>>> >
>>> > 1. How can I find out which system(s) is/are master, consumer, hub,
>>> etc?
>>> >
>>> > 2. How do I confirm that the systems have the correct credentials for
>>> > replication? (I am receiving: "Unable to acquire replica: Permission
>>> > denied.")
>>> >     a. How can I change the bind dn "cn=replication,cn=config"
>>> credentials
>>> > on each system to ensure replication will work?
>>> >
>>> > 3. I assume that upon repairing replication (apparently it has not been
>>> > working for several years) the systems will all replicate to the most
>>> > recent information.  Correct?
>>> >
>>> > Again, any guidance is greatly appreciated.
>>> >
>>> > Thanks in advance,
>>> >
>>> > Herb
>>> >
>>> > --
>>> > 389 users mailing list
>>> > 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>>> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>>> >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edfe5e8f/attachment-0001.html
>>> >
>>>
>>>
>>
>> --
>> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>
>
> --
> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
> --
> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120403/ec9bb479/attachment.html>

------------------------------

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

End of 389-users Digest, Vol 83, Issue 9
****************************************

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users