Thanks for the feedback. I was able to restart replication on the
system. There was a typo in the /etc/hosts file on sump causing it to
look at the wrong host on the networkand this came from earlier
troubleshooting of DNS issues.
I appreciate all of your help and patience in this issue.
On 05/22/2018 05:32 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> The mystery continues. It seems might be working but in reality it's
> not. The replica has stopped updating from the master and is unable
> to talk to the LDAP server. I'm fairly certain this is a
The mystery continues. It seems might be working but in reality it's
not. The replica has stopped updating from the master and is unable to
talk to the LDAP server. I'm fairly certain this is a certificate
issue. However, my certs appear to be valid.
So far, the ipa-replica-manage command
On 05/22/2018 11:24 AM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> Well I'm sure how this happened. It looks like I have an Identity
> server that has a replication agreement with itself. Is there a
> method to help clean this up?
>
>> # ipa-replica-manage list sump. -v
Well I'm sure how this happened. It looks like I have an Identity
server that has a replication agreement with itself. Is there a method
to help clean this up?
# ipa-replica-manage list sump. -v
Directory Manager password:
sump.: replica
last init status: None
last init ended:
Well... I made a what think is a major oopsie. I was working my way
through the guide from the link below. I was having good success
exporting the directory database and migrating the data to a failing
server. When attempting to load the data I overlooked the file
ownership and the import
While researching the steps to perform the offline initilalization I
notice peculiarity with the the replica aggrements on the system I plan
to use as my source data. Notice the duplicate hostname from the
ipa-csreplica-mange command. Is this yet another concern? If so, how
do I remove the
On 05/10/2018 03:30 PM, Rob Crittenden wrote:
> Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
>> Sigh... My replication agreements really do seem to be completely
>> jacked up. I would have expected the hostname replica agreements and
>> the hostname csreplica agreements to
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh... My replication agreements really do seem to be completely jacked
up. I would have expected the hostname replica agreements and the
hostname csreplica agreements to match.
This is fairly typical. You don't really need a
Sigh... My replication agreements really do seem to be completely jacked
up. I would have expected the hostname replica agreements and the
hostname csreplica agreements to match.
# ipa-replica-manage list fitch. -v
Directory Manager password:
kodiak.: replica
last init status: None
last
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look
good. Does this mean I'll be using the re-initialize option or some
variation?
ipa-csreplica-manage
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
ipa-cacert-manage -v 'fitch'
ipa: DEBUG: Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
Usage: ipa-cacert-manage renew [options]
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Rob for the win. When comparing the serial numbers there is big
difference, one digit on the failing system and 10 digits on the working
system. Upon further inspection, I noticed the ldapsearch returned two
usercertificates
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
So there are two possibilities here. One, "cn=Replication Manager
cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" does
not exist on the server, or two, you are using the wrong password for
this entry in the replication
On 05/10/2018 10:48 AM, Michael Rainey (Contractor, Code 7320) wrote:
>> So there are two possibilities here. One, "cn=Replication Manager
>> cloneAgreement1-fitch.-pki-tomcat,ou=csusers,cn=config" does
>> not exist on the server, or two, you are using the wrong password for
>> this entry in
SL7.5:
389-ds-base-snmp-1.3.6.1-28.el7_4.x86_64
389-ds-base-libs-1.3.6.1-28.el7_4.x86_64
389-ds-base-1.3.6.1-28.el7_4.x86_64
*Michael Rainey*
Network Representative
Naval Research Laboratory, Code 7320
Building 1009, Room C156
Stennis Space Center, MS 39529
On 05/09/2018 05:01 PM, Mark
On 05/09/2018 05:54 PM, Michael Rainey (Contractor, Code 7320) via
FreeIPA-users wrote:
> Along with the logs listed below, searching through the certificates
> is not possible. A message is returned:
>
>> Certificate operation cannot be completed: Unable to communicate with
>> CMS (Internal
Along with the logs listed below, searching through the certificates is
not possible. A message is returned:
Certificate operation cannot be completed: Unable to communicate with
CMS (Internal Server Error)
Certmonger is running and pki-tomcatd is not. "journalctl -u
Rob,
A big thank you for showing me howto bringthe service back. You are
correct the doesn't resolve the cause. I suspect I'm in a bit of
certificate hades. The first sign of problems start with pki-tomcatd
failing to start. Testing of the https: url says the
connection is refused. I haven't
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating
the bat signal seeking some help. We recently upgraded this system to
SL7.5 and ran the ipa-server-upgrade command. During the upgrade
21 matches
Mail list logo
