[Freeipa-users] Re: failed to add IPA Replica(Centos 8) on existing IPA cluster (Centos 7) with CA role enabled.

[Dushyant Khobragade via FreeIPA-users]

Hi Rob,

I see CentOS 7.9 has IPA VERSION 4.6 and Alma Linux 8.6 has IPA version 4.9

So direct jump from ipa version 4.6 to 4.9 will work or do i need to do
intermediate updates

Thank you

On Wed, Nov 30, 2022, 2:03 AM Rob Crittenden  wrote:

> Dushyant Khobragade via FreeIPA-users wrote:
> > Hi Flo,
> >
> > Thanks, I was able to resolve the issue by following your feedback.
> > It was time sync issue between IPA master and new IPA replica.
> >
> > Moving further, I would like to check with you on recommended path on
> > upgrading IPA from Centos 7.9 (IPA v 4.6) to Alma Linux 8.6. Can we
> > directly add linux 8.6 replica on existing Centos 7.9 IPA master and
> > then promote it to CA certificate renewal node and decommission older
> > version.
>
> Yes.
>
> There is documentation guide on upgrading:
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/index
>
> rob
>
> >
> > Thanks & Regards,
> > Dushyant
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 25, 2022 at 9:01 AM Florence Blanc-Renaud  > > wrote:
> >
> > Hi,
> >
> > please keep the list in copy as the resolution steps can often help
> > other users.
> >
> > On Fri, Nov 25, 2022 at 4:55 PM Dushyant Khobragade
> > mailto:dushyantk@gmail.com>> wrote:
> >
> > Hi Flo,
> > Thank you for response.
> > I could see below logs in /var/log/ipareplica-install.log
> > <>>
> > 2022-11-25T15:43:46Z DEBUG certmonger request is in state
> > 'GENERATING_KEY_PAIR'
> > 2022-11-25T15:43:46Z DEBUG certmonger request is in state
> > 'SUBMITTING'
> > 2022-11-25T15:44:11Z DEBUG certmonger request is in state
> > 'CA_UNREACHABLE'
> > 2022-11-25T15:44:11Z DEBUG Cert request 20221125154346 failed:
> > CA_UNREACHABLE (Server at
> > https://innsv01p1.mylab.domain/ipa/json failed request, will
> > retry: 4001 (The service principal for subject alt name ipa-ca.
> > mylab.domain  in certificate request does not exist).)
> >
> >
> > Is IPA configured as DNS server? You can check with
> > # ipa config-show | grep DNS
> >   IPA DNS servers: fedora36.ipa.test
> >
> > If there is at least one server in the IPA DNS servers list, then
> > IPA is configured as DNS server. It should contain a DNS record for
> > ipa-ca.mylab.domain with the IP addresses of all the CA servers:
> > # ipa dnsrecord-show mylab.domain ipa-ca
> >   Record name: ipa-ca
> >   A record: xxx.xxx.xxx.xxx
> >
> > If you are using an external DNS server, make sure that there is an
> > A record for ipa-ca. You can generate an update file using
> > # ipa dns-update-system-records --dry-run
> >
> >
> > 2022-11-25T15:44:11Z DEBUG Giving up on cert request
> 20221125154346
> > 2022-11-25T15:44:11Z DEBUG certmonger request is in state
> > 'GENERATING_CSR'
> > 2022-11-25T15:44:12Z DEBUG certmonger request is in state
> > 'SUBMITTING'
> > 2022-11-25T15:44:13Z DEBUG certmonger request is in state
> > 'POST_SAVED_CERT'
> > 2022-11-25T15:44:14Z DEBUG certmonger request is in state
> > 'MONITORING'
> > 2022-11-25T15:44:14Z DEBUG Cert request 20221125154411 was
> > successful
> > <>>
> > ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP
> > server", 'ctrls': [], 'info': 'error:1416F086:SSL
> > routines:tls_process_server_certificate:certificate verify
> > failed (certificate is not yet valid)'}
> > 2022-11-25T15:45:40Z CRITICAL Failed to configure CA instance
> >
> > It's not clear if this error or the previous one is the root cause,
> > but the content of /var/log/pki/pki-ca-spawn..log on the
> > replica may give some hints.
> > /Certificate not yet valid/ would strongly suggest that the dates
> > are not in sync on the master and the replica.
> >
> > flo
> >
> >
> > 2022-11-25T15:45:40Z CRITICAL See the installation logs and the
> > following files/directories for more information:
> > 2022-11-25T15:45:40Z CRITICAL   /var/log/pki/pki-tomcat
> > 2022-11-25T15:45:40Z DEBUG Traceback (most recent call last):
> >   File
> > "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
> > line 635, in start_creation
> > run_step(full_msg, method)
> >   File
> > "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
> > line 621, in run_step
> > method()
> >   File
> >
>  "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py",
> > line 627, in __spawn_instance
> > nolog_list=nolog_list
> >   File
> >
>  "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
> > line 227, in spawn_instance
> >

[Freeipa-users] Re: failed to add IPA Replica(Centos 8) on existing IPA cluster (Centos 7) with CA role enabled.

[Rob Crittenden via FreeIPA-users]

Dushyant Khobragade via FreeIPA-users wrote:
> Hi Flo,
> 
> Thanks, I was able to resolve the issue by following your feedback. 
> It was time sync issue between IPA master and new IPA replica.
> 
> Moving further, I would like to check with you on recommended path on
> upgrading IPA from Centos 7.9 (IPA v 4.6) to Alma Linux 8.6. Can we
> directly add linux 8.6 replica on existing Centos 7.9 IPA master and
> then promote it to CA certificate renewal node and decommission older
> version.

Yes.

There is documentation guide on upgrading:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/index

rob

> 
> Thanks & Regards,
> Dushyant 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Nov 25, 2022 at 9:01 AM Florence Blanc-Renaud  > wrote:
> 
> Hi,
> 
> please keep the list in copy as the resolution steps can often help
> other users.
> 
> On Fri, Nov 25, 2022 at 4:55 PM Dushyant Khobragade
> mailto:dushyantk@gmail.com>> wrote:
> 
> Hi Flo,
> Thank you for response.
> I could see below logs in /var/log/ipareplica-install.log
> <>>
> 2022-11-25T15:43:46Z DEBUG certmonger request is in state
> 'GENERATING_KEY_PAIR'
> 2022-11-25T15:43:46Z DEBUG certmonger request is in state
> 'SUBMITTING'
> 2022-11-25T15:44:11Z DEBUG certmonger request is in state
> 'CA_UNREACHABLE'
> 2022-11-25T15:44:11Z DEBUG Cert request 20221125154346 failed:
> CA_UNREACHABLE (Server at
> https://innsv01p1.mylab.domain/ipa/json failed request, will
> retry: 4001 (The service principal for subject alt name ipa-ca.
> mylab.domain  in certificate request does not exist).)
> 
> 
> Is IPA configured as DNS server? You can check with
> # ipa config-show | grep DNS
>   IPA DNS servers: fedora36.ipa.test
> 
> If there is at least one server in the IPA DNS servers list, then
> IPA is configured as DNS server. It should contain a DNS record for
> ipa-ca.mylab.domain with the IP addresses of all the CA servers:
> # ipa dnsrecord-show mylab.domain ipa-ca
>   Record name: ipa-ca
>   A record: xxx.xxx.xxx.xxx
> 
> If you are using an external DNS server, make sure that there is an
> A record for ipa-ca. You can generate an update file using
> # ipa dns-update-system-records --dry-run
> 
> 
> 2022-11-25T15:44:11Z DEBUG Giving up on cert request 20221125154346
> 2022-11-25T15:44:11Z DEBUG certmonger request is in state
> 'GENERATING_CSR'
> 2022-11-25T15:44:12Z DEBUG certmonger request is in state
> 'SUBMITTING'
> 2022-11-25T15:44:13Z DEBUG certmonger request is in state
> 'POST_SAVED_CERT'
> 2022-11-25T15:44:14Z DEBUG certmonger request is in state
> 'MONITORING'
> 2022-11-25T15:44:14Z DEBUG Cert request 20221125154411 was
> successful
> <>>
> ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP
> server", 'ctrls': [], 'info': 'error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify
> failed (certificate is not yet valid)'}
> 2022-11-25T15:45:40Z CRITICAL Failed to configure CA instance
> 
> It's not clear if this error or the previous one is the root cause,
> but the content of /var/log/pki/pki-ca-spawn..log on the
> replica may give some hints.
> /Certificate not yet valid/ would strongly suggest that the dates
> are not in sync on the master and the replica.
> 
> flo
>  
> 
> 2022-11-25T15:45:40Z CRITICAL See the installation logs and the
> following files/directories for more information:
> 2022-11-25T15:45:40Z CRITICAL   /var/log/pki/pki-tomcat
> 2022-11-25T15:45:40Z DEBUG Traceback (most recent call last):
>   File
> "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
> line 635, in start_creation
>     run_step(full_msg, method)
>   File
> "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
> line 621, in run_step
>     method()
>   File
> "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py",
> line 627, in __spawn_instance
>     nolog_list=nolog_list
>   File
> 
> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
> line 227, in spawn_instance
>     self.handle_setup_error(e)
>   File
> 
> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
> line 606, in handle_setup_error
>     ) from None
> RuntimeError: CA configuration failed.
> 2022-11-25T15:45:40Z DEBUG   [error] RuntimeError: CA
> configuration failed.
> 2022-11-25T15:45:40Z DEBUG Removing /root/.dogtag/pki-tomcat/ca
> 

[Freeipa-users] Re: failed to add IPA Replica(Centos 8) on existing IPA cluster (Centos 7) with CA role enabled.

[Dushyant Khobragade via FreeIPA-users]

Hi Flo,

Thanks, I was able to resolve the issue by following your feedback.
It was time sync issue between IPA master and new IPA replica.

Moving further, I would like to check with you on recommended path on
upgrading IPA from Centos 7.9 (IPA v 4.6) to Alma Linux 8.6. Can we
directly add linux 8.6 replica on existing Centos 7.9 IPA master and then
promote it to CA certificate renewal node and decommission older version.


Thanks & Regards,
Dushyant







On Fri, Nov 25, 2022 at 9:01 AM Florence Blanc-Renaud 
wrote:

> Hi,
>
> please keep the list in copy as the resolution steps can often help other
> users.
>
> On Fri, Nov 25, 2022 at 4:55 PM Dushyant Khobragade <
> dushyantk@gmail.com> wrote:
>
>> Hi Flo,
>> Thank you for response.
>> I could see below logs in /var/log/ipareplica-install.log
>> <>>
>> 2022-11-25T15:43:46Z DEBUG certmonger request is in state
>> 'GENERATING_KEY_PAIR'
>> 2022-11-25T15:43:46Z DEBUG certmonger request is in state 'SUBMITTING'
>> 2022-11-25T15:44:11Z DEBUG certmonger request is in state 'CA_UNREACHABLE'
>> 2022-11-25T15:44:11Z DEBUG Cert request 20221125154346 failed:
>> CA_UNREACHABLE (Server at https://innsv01p1.mylab.domain/ipa/json failed
>> request, will retry: 4001 (The service principal for subject alt name
>> ipa-ca. mylab.domain  in certificate request does not exist).)
>>
>
> Is IPA configured as DNS server? You can check with
> # ipa config-show | grep DNS
>   IPA DNS servers: fedora36.ipa.test
>
> If there is at least one server in the IPA DNS servers list, then IPA is
> configured as DNS server. It should contain a DNS record for
> ipa-ca.mylab.domain with the IP addresses of all the CA servers:
> # ipa dnsrecord-show mylab.domain ipa-ca
>   Record name: ipa-ca
>   A record: xxx.xxx.xxx.xxx
>
> If you are using an external DNS server, make sure that there is an A
> record for ipa-ca. You can generate an update file using
> # ipa dns-update-system-records --dry-run
>
>
> 2022-11-25T15:44:11Z DEBUG Giving up on cert request 20221125154346
>> 2022-11-25T15:44:11Z DEBUG certmonger request is in state 'GENERATING_CSR'
>> 2022-11-25T15:44:12Z DEBUG certmonger request is in state 'SUBMITTING'
>> 2022-11-25T15:44:13Z DEBUG certmonger request is in state
>> 'POST_SAVED_CERT'
>> 2022-11-25T15:44:14Z DEBUG certmonger request is in state 'MONITORING'
>> 2022-11-25T15:44:14Z DEBUG Cert request 20221125154411 was successful
>> <>>
>> ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP server",
>> 'ctrls': [], 'info': 'error:1416F086:SSL
>> routines:tls_process_server_certificate:certificate verify failed
>> (certificate is not yet valid)'}
>> 2022-11-25T15:45:40Z CRITICAL Failed to configure CA instance
>>
> It's not clear if this error or the previous one is the root cause, but
> the content of /var/log/pki/pki-ca-spawn..log on the replica may give
> some hints.
> *Certificate not yet valid* would strongly suggest that the dates are not
> in sync on the master and the replica.
>
> flo
>
>
>> 2022-11-25T15:45:40Z CRITICAL See the installation logs and the following
>> files/directories for more information:
>> 2022-11-25T15:45:40Z CRITICAL   /var/log/pki/pki-tomcat
>> 2022-11-25T15:45:40Z DEBUG Traceback (most recent call last):
>>   File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
>> line 635, in start_creation
>> run_step(full_msg, method)
>>   File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
>> line 621, in run_step
>> method()
>>   File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py", line
>> 627, in __spawn_instance
>> nolog_list=nolog_list
>>   File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
>> line 227, in spawn_instance
>> self.handle_setup_error(e)
>>   File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
>> line 606, in handle_setup_error
>> ) from None
>> RuntimeError: CA configuration failed.
>> 2022-11-25T15:45:40Z DEBUG   [error] RuntimeError: CA configuration
>> failed.
>> 2022-11-25T15:45:40Z DEBUG Removing /root/.dogtag/pki-tomcat/ca
>> >>Truncted>>
>>
>>
>> Thanks & Regards,
>> Dushyant
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 25, 2022 at 7:18 AM Florence Blanc-Renaud 
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Nov 25, 2022 at 3:59 PM dushyant k via FreeIPA-users <
>>> freeipa-users@lists.fedorahosted.org> wrote:
>>>
 I am trying to add new replica Centos 8 IPA v.4.7 to my existing centos
 7 IPA cluster which has IPA version 4.6

 I am able to add centos 8 replica as ipa client however while adding as
 replica with setup-ca. it failing.

 Please provide the logs from the failing replica
>>> (/var/log/ipareplica-install.log).
>>>
>>>
 Also it would be great if anyone can provide documents on migrating IPA
 to centos 8 from centos 7

>>> The doc is available here:
>>> 

[Freeipa-users] Re: Local account override IPA account

[Jochen Kellner via FreeIPA-users]

Hello Kevin,

Kevin Vasko via FreeIPA-users 
writes:

> I know this is probably stupid but we have a server with a local
> account (let’s call this local user “user1”). This server and its
> install predated our IPA install. This local user also has sudoers
> exception for this account for a “NOPASSWD” locally on this machine
> and this machine alone.
>
> After some period of time (it’s been like this for years), we added
> this “user1” account to FreeIPA so we could use it on other select
> machine. We kept using the local account as if nothing changed.
>
...
>
> If I remove “sss” from the nsswitch sudoers line it works as expected. 
>
> Is this a regression in sssd or something else Im missing?

I don't think it's a pure regression. I think the supported way to
"migrate" a former local user to IPA with another uid or others is to
define an id view for user1 on the ubuntu host and use uid 1000 there.
I'd hope that deleting the local user just changes the password to the
IPA one and sudo starts working.

If you want to debug your install further, you'd probably need to enable
tracing in sssd and look for clues,

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: IPA servers stopped replicating and cannot get them to replicate again.

[Rob Crittenden via FreeIPA-users]

Kelly Fergason via FreeIPA-users wrote:
> Hello all,
> 
> I have inherited an IPA setup that has some issues.  I was unfamiliar
> with the IPA software, but am learning a lot
> really fast.  They had 4 servers, ipa01-04.  Replication went from 01 to
> 02 to 03, and I don't recall how 04 was updated.
> 
> Replication stopped working from ipa01 to ipa02, and I have not been
> able to get it going again.
> At this time, we have one working ipa server, with no redundancy.
> Ipa02 and 03 are shutdown at the moment, ipa04 was rebuilt and I used it
> to try to create a new replica.
> 
> I have tried to reinitialize the replication to ipa02, and I have tried
> to create new replicas.
> These are set as domainlevel 1, so the process is to create a replica by
> promoting a client.
> 
> The general process used here was to clear up any replication agreements
> between servers and attempt to
> reinitialize or install the new replica.  It pretty much always fails
> the same way.
> 
> We had a consultant work with us, and they were unable to determine what
> the problem was.
> 
> Some basics about the setup.  We are running Oracle Linux 7.9,
> ipa-server 4.6.8-5.0.1.  I have also tried
> Oracle Linux 8, and ipa-server 4.9.10, but there is no difference.
> DNS is not managed by the ipa server.
> 
> Replication seems to be the basis for DR and upgrading, so it would be
> really nice to get this
> working again.
> 
> I am attaching the console output of the ipa-replica-install command,
> and the install log file.
> Any insights as to how to get this going again would be greatly
> appreciated.
> If anyone needs more information, please let me know.

We need to see the 389-ds access and error logs for the respective servers.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Local account override IPA account

[Kevin Vasko via FreeIPA-users]

I know this is probably stupid but we have a server with a local account (let’s 
call this local user “user1”). This server and its install predated our IPA 
install. This local user also has sudoers exception for this account for a 
“NOPASSWD” locally on this machine and this machine alone. 

After some period of time (it’s been like this for years), we added this 
“user1” account to FreeIPA so we could use it on other select machine. We kept 
using the local account as if nothing changed.

This server with the local “user1” account was on Ubuntu 18.04 and with this 
set up was working fine. We upgraded it to Ubuntu 20.04 and it broke the 
sudoers “NOPASSWD”. This local account can no longer execute commands without a 
password as it seems sssd is overriding the “local account” and going back to 
IPA and asking for its authentication (user1 on this box is local and has a uid 
of 1000, the freeipa user1 had the random freeIPA generated 123456789 UID). 

In my nsswitch.conf 

For passwd, group, sudoers all of them have “files” listed first which should 
instruct sssd to prioritize local account information first, correct? 

If I remove “sss” from the nsswitch sudoers line it works as expected. 

Is this a regression in sssd or something else Im missing?


-Kevin
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue