Re: ipa-replica-install --principal admin --admin-password <secret> --setup-ca Traceback
by Florence Blanc-Renaud
On 03/12/2018 06:09 PM, Amit wrote:
> Hello Flo,
>
> PFA replica-install log.
>
Hi,
sorry if I was not clear, but I meant 389-ds access logs, located in
/var/log/dirsrv/slapd-DOMxxx/access. The ones from the master and the
soon-to-be-replica may provide more information.
The customer may also try ipa-replica-install with the -d option, which
will add debug information to the ipareplica-install.log file.
Flo
> Thanks
>
>
> On 03/12/2018 01:59 PM, Florence Blanc-Renaud wrote:
>> On 03/10/2018 12:07 PM, Amit via FreeIPA-devel wrote:
>>> Ping!!
>>>
>>>
>>> On 03/09/2018 02:08 PM, Amit wrote:
>>>> Hello,
>>>>
>>>> Any thoughts would be helpful.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On 03/07/2018 02:57 PM, Amit wrote:
>>>>> Hello,
>>>>>
>>>>> This is scenario in customer env.
>>>>> Customer is using fresh machine to install replica.
>>>>>
>>>>> * IPA-Server
>>>>> * # ipa-server-install --no-ntp //Success
>>>>>
>>>>> *IPA Replica*
>>>>> # ipa-replica-install --principal admin --admin-password <secret>
>>>>> --setup-ca
>>>>> DEBUG Traceback (most recent call last):
>>>>> File
>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
>>>>> 504, in start_creation run_step(full_msg, method)
>>>>> File
>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
>>>>> 494, in run_step method()
>>>>> File
>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
>>>>> line
>>>>> 439, in __setup_replica cacert=self.ca_file)
>>>>> File
>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
>>>>> line 1666, in setup_promote_replication raise
>>>>> RuntimeError("Failed to
>>>>> start replication")
>>>>> RuntimeError: Failed to start replication
>>>>> 2018-02-06T06:56:48Z DEBUG [error] RuntimeError: Failed to start
>>>>> replication
>>>>> 2018-02-06T06:56:48Z DEBUG Destroyed connection
>>>>> context.ldap2_113870544
>>>>> 2018-02-06T06:56:48Z DEBUG Backing up system configuration file
>>>>> '/etc/ipa/default.conf'
>>>>> 2018-02-06T06:56:48Z DEBUG Saving Index File to
>>>>> '/var/lib/ipa/sysrestore/sysrestore.index'
>>>>> 2018-02-06T06:56:48Z DEBUG File
>>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
>>>>> 172, in
>>>>> execute
>>>>> return_value = self.run()
>>>>>
>>>>> While I cannot repro in my local lab
>>>>>
>>>
>>
>> Hi Amit,
>>
>> without any logs it is difficult to tell what could go wrong. The part
>> of code that is failing is doing 2 tasks:
>> - starts the replication by performing a LDAP modification on the
>> replication agreement (dn:
>> cn=meTo$master,cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping
>> tree,cn=config) in order to set the attribute
>> nsds5BeginReplicaRefresh=start
>> - checks the replication status by reading the replication agreement
>> status (attributes nsds5BeginReplicaRefresh,
>> nsds5replicaUpdateInProgress, nsds5ReplicaLastInitStatus,
>> nsds5ReplicaLastInitStart and nsds5ReplicaLastInitEnd).
>>
>> So if you have 389-ds access logs, you can start by checking if the
>> mod was successful. Then check the replication status.
>>
>> Flo
>
> --
> Thanks
> Amit Kumar
> !!If you stumble, get back up.
> What happened yesterday, no longer matters.
> Today is another day to move closer to your GOAL!!
>
6 years, 2 months
decision for F28
by Rob Crittenden
freeIPA in Fedora 28 is currently broken for a number of reasons:
- The NSS switch to sqlite
- 389-ds now provides a default security entry
- many changes in dogtag
FESCO has given us and dogtag a reprieve on the beta deadline but we
need to get something working ASAP.
The dogtag team has their code in mostly working shape now.
For IPA we need to decide what to release. I see the choices as:
1. Use 4.6.3 + NSS and other patches
2. Release 4.7.0 now even though it doesn't have everything we planned
and ship that with F-28
3. Do a 4.7.0 pre-release (set IPA_VERSION_PRE_RELEASE in VERSION and
release a tarball).
4. Use a git pull from master for F-28 and name it something that will
be upgradable (this is the tricky bit).
Options #1 and #2 have been tested independently by Christian and I,
with him focusing on testing master and my testing of 4.6.3. Testing of
both cannot be described as thorough, mostly consisting of basic installs.
Upgrade from F-27 to 4.6.3+patches can work but it is still a little
bumpy, requiring a few post-install steps. We may be able to smooth this
out as well.
Should we allow upgrades at all given this unknown state? We can
probably add an rpm pretrans scriptlet to prevent upgrades.
rob
6 years, 2 months