[Freeipa-users] Re: FreeIPA having problem after upgrading from Fedora 30 to 31

2019-10-29 Thread Patrick Dung via FreeIPA-users 
Looks like it's the second problem (on pagure)

-- Logs begin at Wed 2019-10-30 02:34:10 HKT, end at Wed 2019-10-30
06:28:21 HKT. --
Oct 30 03:39:43 home.local.nonet systemd[1]: Starting PKI Tomcat Server
pki-tomcat...
Oct 30 03:39:44 home.local.nonet pki-server[57211]:

Oct 30 03:39:44 home.local.nonet pki-server[57211]: pki-tomcat instance
migrated
Oct 30 03:39:44 home.local.nonet pki-server[57211]:

Oct 30 03:39:44 home.local.nonet systemd[1]: Started PKI Tomcat Server
pki-tomcat.
Oct 30 03:39:44 home.local.nonet server[57330]: Java virtual machine used:
/usr/lib/jvm/jre-1.8.0-openjdk/bin/java
Oct 30 03:39:44 home.local.nonet server[57330]: classpath used:
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
Oct 30 03:39:44 home.local.nonet server[57330]: main class used:
org.apache.catalina.startup.Bootstrap
Oct 30 03:39:44 home.local.nonet server[57330]: flags used:
-Djava.library.path=/usr/lib64/nuxwdog-jni
Oct 30 03:39:44 home.local.nonet server[57330]: options used:
-Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp
-Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.security.manager
-Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy
Oct 30 03:39:44 home.local.nonet server[57330]: arguments used: start
Oct 30 03:40:03 home.local.nonet server[57330]: WARNING: Exception
processing realm [com.netscape.cms.tomcat.ProxyRealm@296c31c9] background
process
Oct 30 03:40:03 home.local.nonet server[57330]:
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Oct 30 03:40:03 home.local.nonet server[57330]: at
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:142)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1137)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5566)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Oct 30 03:40:03 home.local.nonet server[57330]: at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Oct 30 03:40:03 home.local.nonet server[57330]: at
java.lang.Thread.run(Thread.java:748)

The pki-tomcat instance is running. It would output error when I browse
https://home.local.nonet:8443/ca, but https://home.local.nonet:8443/pki/ is
ok
  Instance ID: pki-tomcat
  Active: True
  Unsecure Port: 8080
  Secure Port: 8443
  AJP Port: 8009
  Tomcat Port: 8005

  CA Subsystem:
Type:Subordinate CA (Security Domain)
SD Registration URL: https://home.local.nonet:443
Enabled: True
Unsecure URL:http://home.local.nonet:8080/ca/ee/ca
Secure Agent URL:https://home.local.nonet:8443/ca/agent/ca
Secure EE URL:   https://home.local.nonet:8443/ca/ee/ca
Secure Admin URL:https://home.local.nonet:8443/ca/services
PKI Console URL: https://home.local.nonet:8443/ca

Thanks,
Patrick

On Wed, Oct 30, 2019 at 5:44 AM Alex Scheel  wrote:

> You might try checking journalctl output.
>
> It might be this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1766451
>
> Otherwise, it is a perfect match for this bug:
> https://pagure.io/dogtagpki/issue/3111
>
> Which I'd also like journalctl output on, if you have any to share. :)
>
>
> I should have a Bodhi update out tonight ye

[Freeipa-users] Re: FreeIPA having problem after upgrading from Fedora 30 to 31

2019-10-29 Thread Alex Scheel via FreeIPA-users 
You might try checking journalctl output. 

It might be this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1766451

Otherwise, it is a perfect match for this bug:
https://pagure.io/dogtagpki/issue/3111

Which I'd also like journalctl output on, if you have any to share. :)


I should have a Bodhi update out tonight yet for the issue in the BZ. Without
more information, I'm not sure we'd know what cause for the second issue
is.

- Alex

- Original Message -
> From: "Patrick Dung via FreeIPA-users" 
> To: freeipa-users@lists.fedorahosted.org
> Cc: "Patrick Dung" 
> Sent: Tuesday, October 29, 2019 5:29:09 PM
> Subject: [Freeipa-users] FreeIPA having problem after upgrading from Fedora 
> 30 to 31
> 
> Hello,
> 
> I got problem upgrading from FC30 to FC31.
> Before upgrade the FreeIPA in FC30 is running fine.
> 
> After OS upgrade, IPA cannot start and checked that it stuck at the CA part.
> I run ipa-server-upgrade manually but there is problem.
> 
> 2019-10-29T21:03:58Z DEBUG request GET
> https://home.local.nonet:8443/ca/rest/account/login
> 2019-10-29T21:03:58Z DEBUG request body ''
> 2019-10-29T21:03:58Z DEBUG response status 500
> 2019-10-29T21:03:58Z DEBUG response headers Content-Type:
> text/html;charset=utf-8
> Content-Language: en
> Content-Length: 2481
> Date: Tue, 29 Oct 2019 21:03:58 GMT
> Connection: close
> 
> 
> 2019-10-29T21:03:58Z DEBUG response body (decoded): b' lang="en">HTTP Status 500 \xe2\x80\x93 Internal Server
> Errorh1
> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
> h2
> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
> h3
> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
> body
> {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
> p
> {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
> a {color:black;} a.name {color:black;} .line
> {height:1px;background-color:#525D76;border:none;}HTTP
> Status 500 \xe2\x80\x93 Internal Server Error />Type Exception ReportMessage Subsystem
> unavailableDescription The server encountered an unexpected
> condition that prevented it from fulfilling the
> request.Exceptionjavax.ws.rs.ServiceUnavailableException:
> Subsystem
> unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:150)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:515)\n\tcom.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)\n\torg.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)\n\torg.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)\n\torg.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)\n\torg.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)\n\torg.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\nNote
> The full stack trace of the root cause is available in the server
> logs.Apache Tomcat/9.0.26'
> 2019-10-29T21:03:58Z ERROR IPA server upgrade failed: Inspect
> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
> 2019-10-29T21:03:58Z DEBUG   File
> "/usr/lib/python3.7/site-packages/ipapython/admintool.py", line 179, in
> execute
> return_value = self.run()
>   File
> "/usr/lib/python3.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
> line 54, in run
> server.upgrade()
>   File
> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
> line 2223, in upgrade
> upgrade_configuration()
>   File
> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
> line 2093, in upgrade_configuration
> ca_enable_ldap_profile_subsystem(ca)
>   File
> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
> line 414, in ca_enable_ldap_profile_subsystem
> cainstance.migrate_profiles_to_ldap()
>   File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py",
> line 1937, in migrate_profiles_to_ldap
> _create_dogtag_profile(profile_id, profile_data, overwrite=False)
>   File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py",
> line 1943, in _create_dogtag_profile
> with api.Backend.ra_certprofile as profile_

[Freeipa-users] FreeIPA having problem after upgrading from Fedora 30 to 31

2019-10-29 Thread Patrick Dung via FreeIPA-users 
Hello,

I got problem upgrading from FC30 to FC31.
Before upgrade the FreeIPA in FC30 is running fine.

After OS upgrade, IPA cannot start and checked that it stuck at the CA part.
I run ipa-server-upgrade manually but there is problem.

2019-10-29T21:03:58Z DEBUG request GET
https://home.local.nonet:8443/ca/rest/account/login
2019-10-29T21:03:58Z DEBUG request body ''
2019-10-29T21:03:58Z DEBUG response status 500
2019-10-29T21:03:58Z DEBUG response headers Content-Type:
text/html;charset=utf-8
Content-Language: en
Content-Length: 2481
Date: Tue, 29 Oct 2019 21:03:58 GMT
Connection: close


2019-10-29T21:03:58Z DEBUG response body (decoded): b'HTTP Status 500 \xe2\x80\x93 Internal Server
Errorh1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 500 \xe2\x80\x93 Internal Server ErrorType Exception ReportMessage Subsystem
unavailableDescription The server encountered an unexpected
condition that prevented it from fulfilling the
request.Exceptionjavax.ws.rs.ServiceUnavailableException:
Subsystem
unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:150)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:515)\n\tcom.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)\n\torg.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)\n\torg.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)\n\torg.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)\n\torg.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)\n\torg.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\nNote
The full stack trace of the root cause is available in the server
logs.Apache Tomcat/9.0.26'
2019-10-29T21:03:58Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2019-10-29T21:03:58Z DEBUG   File
"/usr/lib/python3.7/site-packages/ipapython/admintool.py", line 179, in
execute
return_value = self.run()
  File
"/usr/lib/python3.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 54, in run
server.upgrade()
  File
"/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
line 2223, in upgrade
upgrade_configuration()
  File
"/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
line 2093, in upgrade_configuration
ca_enable_ldap_profile_subsystem(ca)
  File
"/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py",
line 414, in ca_enable_ldap_profile_subsystem
cainstance.migrate_profiles_to_ldap()
  File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py",
line 1937, in migrate_profiles_to_ldap
_create_dogtag_profile(profile_id, profile_data, overwrite=False)
  File "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py",
line 1943, in _create_dogtag_profile
with api.Backend.ra_certprofile as profile_api:
  File "/usr/lib/python3.7/site-packages/ipaserver/plugins/dogtag.py", line
1315, in __enter__
raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA
REST API'))

2019-10-29T21:03:58Z DEBUG The ipa-server-upgrade command failed,
exception: RemoteRetrieveError: Failed to authenticate to CA REST API
2019-10-29T21:03:58Z ERROR Unexpected error - see /var/log/ipaupgrade.log
for details:
RemoteRetrieveError: Failed to authenticate to CA REST API
2019-10-29T21:03:58Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information

>From /var/log/pki/pki-tomcat/ca/debug log file:
2019-10-30 05:03:50 [main] FINE: LdapAuthInfo: init()
2019-10-30 05:03:50 [main] FINE: LdapAuthInfo: init begins
2019-10-30 05:03:50 [main] FINEST: Getting
internaldb.ldapauth.authtype=SslClientAuth
2019-10-30 05:03:50 [main] FINE: Lda

[Freeipa-users] Re: Can't resolve external users on clients, but I can on servers

2019-10-29 Thread Sumit Bose via FreeIPA-users 
On Tue, Oct 29, 2019 at 02:37:50PM +, TOULMONDE Sébastien (SPC/DCS) via 
FreeIPA-users wrote:
> Hi Sumit,
> 
> I'll try to search if there's any duplicates, but it seems unlikely... 
> Nevertheless - this bug is only hit when the domain search order is null?

Hi,

no, changing the domain resolution order just might mitigate the issue,
Because if some of the information from one domain is already in the
cache this might help to avoid that the IPA client has to ask the IPA
server for both objects with the colliding name during one request.

bye,
Sumit

> 
> Thanks,
> Seb.
> 
> 
> 
> This e-mail cannot be used for other purposes than Proximus business use. See 
> more on https://www.proximus.be/maildisclaimer

> ___
> 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
___
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

[Freeipa-users] Re: Can't resolve external users on clients, but I can on servers

2019-10-29 Thread SPC/DCS 
Hi Sumit,

I'll try to search if there's any duplicates, but it seems unlikely... 
Nevertheless - this bug is only hit when the domain search order is null?

Thanks,
Seb.



This e-mail cannot be used for other purposes than Proximus business use. See 
more on https://www.proximus.be/maildisclaimer
___
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

[Freeipa-users] Re: number of topology segments for 3 servers clean setup?

2019-10-29 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:

On 29/10/2019 08:51, Alexander Bokovoy wrote:

On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:

hi everyone,

I wanted to ask about number of segments after a clean IPA setup with 3
servers.

I see for both 'domain' & 'ca' two segments created by master/replica
installations, which makes me wonder - should there not be three? no/yes
& why?

You really need to show what you have rather than assume we know what
you have.

For three masters, there are several ways of connecting them so that
there are two segments. Or may be you connected all three in a triangle.

For example: A <-> B <-> C, B <-> A <-> C, A <-> B <-> C <-> A

Without knowing your topology it is not possible to say what is correct
and what is not.


sorry was being vague. Question was not about correct or not but rather
I sought to confirm that what IPA replicas (3 masters in total)
installers created in topology - which was two segments - was what IPA
does by default (and not seek to create every every possible chain in
topology, in my case it'd be that triangle) and not a result of some
error/problem.

I now assume that it simply is - each replica installation process
creates just one segment: new-replica <-> used_master ?

Yes, you are proceeding with one replica at a time and for that pair
(master,replica) there is a topology segment being created.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

[Freeipa-users] Re: Can't resolve external users on clients, but I can on servers

2019-10-29 Thread Sumit Bose via FreeIPA-users 
On Tue, Oct 29, 2019 at 01:26:32PM +, TOULMONDE Sébastien (SPC/DCS) via 
FreeIPA-users wrote:
> Ok, so here’s the solution I found almost by accident…
> 
> If I specify the domain search order to ‘ad.domain:ipa.domain’ -> the clients 
> can now resolve the external users
> If, for whatever reason, the search order is empty, the clients are back to 
> ipa-only resolve…

Hi,

is there a chance that there are users or groups in AD and IPA with the
same short name? In this case you might have hit
https://bugzilla.redhat.com/show_bug.cgi?id=1746878.

bye,
Sumit

> 
> Hope it helps someone  😊
> 
> 
> Sébastien Toulmonde
> Linux Engineering | ITS Linux CC
> 
> M +32 (0)475 49 81 45
> 
> [Proximus]
> 
> Connect with us on:
> 
> [Proximus Facebook]   [Proximus Twitter] 
> [Proximus YouTube] 
> [Proximus LinkedIn] 
> 
> 
> 
> 
> 
> This e-mail cannot be used for other purposes than Proximus business use. See 
> more on https://www.proximus.be/maildisclaimer

> ___
> 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
___
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

[Freeipa-users] Re: number of topology segments for 3 servers clean setup?

2019-10-29 Thread Angus Clarke via FreeIPA-users 
Just some user notes

I really like the IPA server topology graph through the web front end, 
visualising the agreements between servers is really useful. You can add or 
remove agreements here too, for both domain and CA (for servers that have CA 
enabled)

I've deployed 6 IPA servers equally across our three main sites and enabled CA 
on all of them, this seems to work fine and I've succefully moved the CA 
renewal master twice (due to external reasons.)

Check the red hat documentation on replication agreements, I recall there are 
some useful notes there on planning.

Regards
Angus



From: lejeczek via FreeIPA-users 
Sent: Tuesday, 29 October 2019, 14:24
To: FreeIPA users list
Cc: lejeczek
Subject: [Freeipa-users] Re: number of topology segments for 3 servers clean 
setup?

On 29/10/2019 08:51, Alexander Bokovoy wrote:
> On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:
>> hi everyone,
>>
>> I wanted to ask about number of segments after a clean IPA setup with 3
>> servers.
>>
>> I see for both 'domain' & 'ca' two segments created by master/replica
>> installations, which makes me wonder - should there not be three? no/yes
>> & why?
> You really need to show what you have rather than assume we know what
> you have.
>
> For three masters, there are several ways of connecting them so that
> there are two segments. Or may be you connected all three in a triangle.
>
> For example: A <-> B <-> C, B <-> A <-> C, A <-> B <-> C <-> A
>
> Without knowing your topology it is not possible to say what is correct
> and what is not.
>
sorry was being vague. Question was not about correct or not but rather
I sought to confirm that what IPA replicas (3 masters in total)
installers created in topology - which was two segments - was what IPA
does by default (and not seek to create every every possible chain in
topology, in my case it'd be that triangle) and not a result of some
error/problem.

I now assume that it simply is - each replica installation process
creates just one segment: new-replica <-> used_master ?

many thanks, L.


___
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

[Freeipa-users] Re: Can't resolve external users on clients, but I can on servers

2019-10-29 Thread SPC/DCS 
Ok, so here’s the solution I found almost by accident…

If I specify the domain search order to ‘ad.domain:ipa.domain’ -> the clients 
can now resolve the external users
If, for whatever reason, the search order is empty, the clients are back to 
ipa-only resolve…

Hope it helps someone  😊


Sébastien Toulmonde
Linux Engineering | ITS Linux CC

M +32 (0)475 49 81 45

[Proximus]

Connect with us on:

[Proximus Facebook]   [Proximus Twitter] 
[Proximus YouTube] 
[Proximus LinkedIn] 





This e-mail cannot be used for other purposes than Proximus business use. See 
more on https://www.proximus.be/maildisclaimer
___
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

[Freeipa-users] Re: number of topology segments for 3 servers clean setup?

2019-10-29 Thread lejeczek via FreeIPA-users 
On 29/10/2019 08:51, Alexander Bokovoy wrote:
> On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:
>> hi everyone,
>>
>> I wanted to ask about number of segments after a clean IPA setup with 3
>> servers.
>>
>> I see for both 'domain' & 'ca' two segments created by master/replica
>> installations, which makes me wonder - should there not be three? no/yes
>> & why?
> You really need to show what you have rather than assume we know what
> you have.
>
> For three masters, there are several ways of connecting them so that
> there are two segments. Or may be you connected all three in a triangle.
>
> For example: A <-> B <-> C, B <-> A <-> C, A <-> B <-> C <-> A
>
> Without knowing your topology it is not possible to say what is correct
> and what is not.
>
sorry was being vague. Question was not about correct or not but rather
I sought to confirm that what IPA replicas (3 masters in total)
installers created in topology - which was two segments - was what IPA
does by default (and not seek to create every every possible chain in
topology, in my case it'd be that triangle) and not a result of some
error/problem.

I now assume that it simply is - each replica installation process
creates just one segment: new-replica <-> used_master ?

many thanks, L.



pEpkey.asc
Description: application/pgp-keys
___
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

[Freeipa-users] Re: Full Server backup fails with IPA version error

2019-10-29 Thread Rob Crittenden via FreeIPA-users 
Saurabh Garg wrote:
> Hi Rob, Thanks for your reply.
> 
> In our case we need to put in place a procedure/steps that can helps us
> to come out from a situation where our complete IPA server setup
> (original server and its replica both) is lost/deleted and need to get
> the same setup back from the scheduled full-server-backups (through cron
> jobs) available at some object storage location.

Install a server with the same OS level as the backup and run the
restore. Additional new masters can be created from that.

You'll want to keep track of which masters run which optional services
and be sure to backup one (or more) running the CA.

rob
> 
> Please advice.
> 
> Thanks,
> Saurabh Garg
> 
> 
> 
> On Fri, Oct 25, 2019 at 6:12 PM Rob Crittenden  > wrote:
> 
> Saurabh Garg via FreeIPA-users wrote:
> > Background -
> > We are trying to restore "full server" from an existing IPA server
> (with replication ON to another server) to a newly created IPA
> Server from the same golden image as all other servers.
> 
> There is no restore with replication on. It would cause endless
> problems.
> 
> Restore is expected to be for a single master in a catastrophic
> situation. The others will require re-init from this master.
> 
> > Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
> > # ipa-server-install --version
> > 4.6.4
> >
> > Destination IPA Server: Red Hat Enterprise Linux Server release
> 7.7 (Maipo)
> > # ipa-server-install --version
> > 4.6.4
> >
> > Problem Statement -
> > While running  "ipa-restore" (exact command: # ipa-restore
> /root/backup/) on the new IPA server for full server backup, system
> throws the following error lines in iparestore.log:
> >
> >
> > 2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to
> be upgraded (expected version '4.6.4-10.el7_6.6', current version
> '4.6.4-10.el7_6.3')
> > Automatically running upgrade, for details see /var/log/ipaupgrade.log
> > Be patient, this may take a few minutes.
> > Automatic upgrade failed: Update complete
> > Upgrading the configuration of the IPA services
> > [Verifying that root certificate is published]
> > [Migrate CRL publish directory]
> > Publish directory already set to new location
> > [Verifying that CA proxy configuration is correct]
> > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
> command ipa-server-upgrade manually.
> > CA did not start in 300.0s
> > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log
> for more information
> 
> It is very persnickety. The versions do not match.
> 
> There are sometimes subtle differences between versions of IPA, even in
> minor releases, so it is not considered safe to restore between
> versions.
> 
> You could hack out the version check and roll the dice, or downgrade the
> packages to match the backed-up value.
> 
> 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

[Freeipa-users] Re: FreeIPA: Cannot login to AD User from IPA client, login from server works

2019-10-29 Thread Sumit Bose via FreeIPA-users 
On Mon, Oct 28, 2019 at 03:56:56PM -, Danijel Bojic via FreeIPA-users wrote:
> Hi Alexander
> 
> Thanks for clarifying.
> 
> I don't see anything in the sssd_domain.log
> I see something though in the sssd_nss.log file.
> I crosschecked my sssd.conf file and corrected some spelling error and
> it seems to work now. I can su and ssh with the AD Domain users on the
> ipa client. Only thing now is that when i try to login in the gui, it
> just restarts the gui.

Hi,

please send the part of /var/log/secure (or the journalctl output)
covering the time you try to log in with gdm.


> Maybe you have an idea what to look into with this issue.
> Here's the output of nss.log:

I didn't see anything suspicious here.

bye,
Sumit
___
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

[Freeipa-users] Re: DNS - IPA masters' own PTR records in a classless subnet

2019-10-29 Thread lejeczek via FreeIPA-users 
On 29/10/2019 09:23, Alexander Bokovoy wrote:
> On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:
>> On 28/10/2019 12:16, Alexander Bokovoy wrote:
>>> On ma, 28 loka 2019, lejeczek via FreeIPA-users wrote:
 On 23/10/2019 12:28, lejeczek via FreeIPA-users wrote:
> hi everybody
>
> when I install a replica and have DNS use cname records to a
> classless
> zone I see:
>
> Configuring DNS (named)
>   [1/8]: generating rndc key file
>   [2/8]: setting up our own record
>   [error] ValidationError: invalid 'cnamerecord': CNAME record is not
> allowed to coexist with any other record (RFC 1034, section 3.6.2
> ..
>
> This happens if the replica has existing ptr record at the time of
> installation.
> If I remove ptr record for the replica from the parent reverse zone
> (all managed by the same IPA) then installation proceeds but should
> masters' records in reverse zone be in resolved with/via cnames in
> classless subnet? (which howto says it should -
> https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation)
>
>
> Or should IPA be not hosting the parent zone if itself is in a
> classless IP subnet?
> It's bit confusing to me I confess.
>
> many thanks, L.
>
> ___
>
 Not even IPA's own devel would comment?

 Is what I wrote above somewhat unclear? Should I try to rephrase it
 better?
>>>
>>> Yes, please provide more details, like examples of your DNS zone and
>>> records. The error message points you to RFC and concrete section about
>>> the problem already.
>>
>> my IPA is locate in a classless subnet 10.5.5.128/25.
>>
>> If I setup IPA with --reverse-zone=128/25.10.5.5.in-addr.arpa then
>> installer creates two rev zones:
>>
>> 128/25.10.5.5.in-addr.arpa & 10.5.5.in-addr.arpa
>>
>> Now, if prior to subsequent masters installation I create PTR records
>> and I follow:
>> https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation
>> (which will make 10.5.5.in-addr.arpa use cnames) then when I install a
>> replica which already has PTR records I get:
>>
>> Configuring DNS (named)
>>   [1/8]: generating rndc key file
>>   [2/8]: setting up our own record
>>   [error] ValidationError: invalid 'cnamerecord': CNAME record is not
>> allowed to coexist with any other record (RFC 1034, section 3.6.2
>> ..
>>
>> What confuses me when I think about it - if I remove ptr(or rather
>> cname) record from the parent reverse zone (10.5.5.in-addr.arpa) then
>> installation proceeds of that subsequent masters proceeds okey and then
>> I think...
>>
>> Should that mean that IPA should/can not be setup on/as classless subnet
>> the way that howto instructs?
>
> Yes, this howto predates FreeIPA 3.2. The change was done in the
> following commit that removed support for this:
>
> commit 42c401a87795fe3a2067155460ae276ad2d3e360
> Author: Martin Kosek 
> Date:   Tue Apr 2 11:58:31 2013 +0200
>
>    Improve CNAME record validation
>       Refactor DNS RR conflict validator so that it is better
> extensible in
>    the future. Also check that there is only one CNAME defined for
>    a DNS record.
>       PTR+CNAME record combination is no longer allowed as we found
> out it
>    does not make sense to have this combination.
>       https://fedorahosted.org/freeipa/ticket/3450
>
>
>
>> I can change records in partent zone(to which IPA installers inserted
>> PTR records) to use cname and forward to 128/25.10.5.5.in-addr.arpa
>> later, and IPA seems to work okey, but... I was hoping for
>> no-doubts-clarification case that all makes me bit uncertain.
>
> May be you could provide modification to the howto?
>
>
I'd love to but first I have to be certain about things I would want to
put in there.

and I still have questions...

IPA installers, when setting up without forwarders and a parent zone
for/of a classless subnet does not exists, insist & create parent
zone(s) because

a) IPA servers' own PTR records cannot!! be resolved via cname

b) because parent rev zone was not found and parent zone must exist

c) a & b

many thanks, L.



pEpkey.asc
Description: application/pgp-keys
___
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

[Freeipa-users] Re: DNS - IPA masters' own PTR records in a classless subnet

2019-10-29 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:

On 28/10/2019 12:16, Alexander Bokovoy wrote:

On ma, 28 loka 2019, lejeczek via FreeIPA-users wrote:

On 23/10/2019 12:28, lejeczek via FreeIPA-users wrote:

hi everybody

when I install a replica and have DNS use cname records to a classless
zone I see:

Configuring DNS (named)
  [1/8]: generating rndc key file
  [2/8]: setting up our own record
  [error] ValidationError: invalid 'cnamerecord': CNAME record is not
allowed to coexist with any other record (RFC 1034, section 3.6.2
..

This happens if the replica has existing ptr record at the time of
installation.
If I remove ptr record for the replica from the parent reverse zone
(all managed by the same IPA) then installation proceeds but should
masters' records in reverse zone be in resolved with/via cnames in
classless subnet? (which howto says it should -
https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation)

Or should IPA be not hosting the parent zone if itself is in a
classless IP subnet?
It's bit confusing to me I confess.

many thanks, L.

___


Not even IPA's own devel would comment?

Is what I wrote above somewhat unclear? Should I try to rephrase it
better?


Yes, please provide more details, like examples of your DNS zone and
records. The error message points you to RFC and concrete section about
the problem already.


my IPA is locate in a classless subnet 10.5.5.128/25.

If I setup IPA with --reverse-zone=128/25.10.5.5.in-addr.arpa then
installer creates two rev zones:

128/25.10.5.5.in-addr.arpa & 10.5.5.in-addr.arpa

Now, if prior to subsequent masters installation I create PTR records
and I follow:
https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation
(which will make 10.5.5.in-addr.arpa use cnames) then when I install a
replica which already has PTR records I get:

Configuring DNS (named)
  [1/8]: generating rndc key file
  [2/8]: setting up our own record
  [error] ValidationError: invalid 'cnamerecord': CNAME record is not
allowed to coexist with any other record (RFC 1034, section 3.6.2
..

What confuses me when I think about it - if I remove ptr(or rather
cname) record from the parent reverse zone (10.5.5.in-addr.arpa) then
installation proceeds of that subsequent masters proceeds okey and then
I think...

Should that mean that IPA should/can not be setup on/as classless subnet
the way that howto instructs?


Yes, this howto predates FreeIPA 3.2. The change was done in the
following commit that removed support for this:

commit 42c401a87795fe3a2067155460ae276ad2d3e360
Author: Martin Kosek 
Date:   Tue Apr 2 11:58:31 2013 +0200

   Improve CNAME record validation
   
   Refactor DNS RR conflict validator so that it is better extensible in

   the future. Also check that there is only one CNAME defined for
   a DNS record.
   
   PTR+CNAME record combination is no longer allowed as we found out it

   does not make sense to have this combination.
   
   https://fedorahosted.org/freeipa/ticket/3450





I can change records in partent zone(to which IPA installers inserted
PTR records) to use cname and forward to 128/25.10.5.5.in-addr.arpa
later, and IPA seems to work okey, but... I was hoping for
no-doubts-clarification case that all makes me bit uncertain.


May be you could provide modification to the howto?


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

[Freeipa-users] Re: DNS - IPA masters' own PTR records in a classless subnet

2019-10-29 Thread lejeczek via FreeIPA-users 
On 28/10/2019 12:16, Alexander Bokovoy wrote:
> On ma, 28 loka 2019, lejeczek via FreeIPA-users wrote:
>> On 23/10/2019 12:28, lejeczek via FreeIPA-users wrote:
>>> hi everybody
>>>
>>> when I install a replica and have DNS use cname records to a classless
>>> zone I see:
>>>
>>> Configuring DNS (named)
>>>   [1/8]: generating rndc key file
>>>   [2/8]: setting up our own record
>>>   [error] ValidationError: invalid 'cnamerecord': CNAME record is not
>>> allowed to coexist with any other record (RFC 1034, section 3.6.2
>>> ..
>>>
>>> This happens if the replica has existing ptr record at the time of
>>> installation.
>>> If I remove ptr record for the replica from the parent reverse zone
>>> (all managed by the same IPA) then installation proceeds but should
>>> masters' records in reverse zone be in resolved with/via cnames in
>>> classless subnet? (which howto says it should -
>>> https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation)
>>>
>>> Or should IPA be not hosting the parent zone if itself is in a
>>> classless IP subnet?
>>> It's bit confusing to me I confess.
>>>
>>> many thanks, L.
>>>
>>> ___
>>>
>> Not even IPA's own devel would comment?
>>
>> Is what I wrote above somewhat unclear? Should I try to rephrase it
>> better?
>
> Yes, please provide more details, like examples of your DNS zone and
> records. The error message points you to RFC and concrete section about
> the problem already.

my IPA is locate in a classless subnet 10.5.5.128/25.

If I setup IPA with --reverse-zone=128/25.10.5.5.in-addr.arpa then
installer creates two rev zones:

128/25.10.5.5.in-addr.arpa & 10.5.5.in-addr.arpa

Now, if prior to subsequent masters installation I create PTR records
and I follow:
https://www.freeipa.org/page/Howto/DNS_classless_IN-ADDR.ARPA_delegation
(which will make 10.5.5.in-addr.arpa use cnames) then when I install a
replica which already has PTR records I get:

Configuring DNS (named)
  [1/8]: generating rndc key file
  [2/8]: setting up our own record
  [error] ValidationError: invalid 'cnamerecord': CNAME record is not
allowed to coexist with any other record (RFC 1034, section 3.6.2
..

What confuses me when I think about it - if I remove ptr(or rather
cname) record from the parent reverse zone (10.5.5.in-addr.arpa) then
installation proceeds of that subsequent masters proceeds okey and then
I think...

Should that mean that IPA should/can not be setup on/as classless subnet
the way that howto instructs?

I can change records in partent zone(to which IPA installers inserted
PTR records) to use cname and forward to 128/25.10.5.5.in-addr.arpa
later, and IPA seems to work okey, but... I was hoping for
no-doubts-clarification case that all makes me bit uncertain.

>
> I would also point out that people tend to live their own lives. There
> are might be holidays, vacations, hard times (no ability to look at
> community mailing lists, etc). Do not expect that every email will be
> answered immediately and even in a week or two. We are humans, not
> robots. While there is an effort to help, there are also no obligations
> to answer every single question.
>
>
I'm of the same mind. That was why I sat quiet & waited patiently for
five days then I though I'd gently poke about again.

I agree, I do not nor I think anybody should expect here 3-hours
response business service in any shape of form. I think everybody here
knows it.

many thanks, L.



pEpkey.asc
Description: application/pgp-keys
___
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

[Freeipa-users] Re: Full Server backup fails with IPA version error

2019-10-29 Thread Angus Clarke via FreeIPA-users 
Sorry that's out of my depth

I took it that you still had a remaining replica, in which case you should be 
able to follow the path I mentioned earlier. If so, you just need to understand 
the CA situation. I build all my IPA servers in the way I mentioned and specify 
--setup-ca on all of them.

Regards
Angus


From: Saurabh Garg 
Sent: Tuesday, October 29, 2019 9:08:06 AM
To: Angus Clarke 
Cc: FreeIPA users list 
Subject: Re: [Freeipa-users] Re: Full Server backup fails with IPA version error

Thanks Angus for the reply.

In my case, original IPA server is completely damaged / deleted, and now I am 
attempting to create an exactly similar server using "full-server" backup.
Do you have any suggestions for such a scenario?

Thanks
sgarg

On Fri, Oct 25, 2019 at 6:05 PM Angus Clarke 
mailto:p...@angusclarke.com>> wrote:
Hi

An alternative approach would be to setup your new server as an IPA client and 
then to promote it.

On new server:
# ipa-client-install

Followed by
# ipa-replica-install

Check the man pages for options suitable to your environment, otherwise I 
specify --setup-ca for all our new IPA instances.

I use this process for rolling out new IPA servers when we add new environments.

Regards
Angus


From: Saurabh Garg via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
Sent: Friday, October 25, 2019 11:55:40 AM
To: 
freeipa-users@lists.fedorahosted.org
 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Saurabh Garg mailto:saurabh@gmail.com>>
Subject: [Freeipa-users] Full Server backup fails with IPA version error

Background -
We are trying to restore "full server" from an existing IPA server (with 
replication ON to another server) to a newly created IPA Server from the same 
golden image as all other servers.

Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Problem Statement -
While running  "ipa-restore" (exact command: # ipa-restore /root/backup/) on 
the new IPA server for full server backup, system throws the following error 
lines in iparestore.log:


2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be upgraded 
(expected version '4.6.4-10.el7_6.6', current version '4.6.4-10.el7_6.3')
Automatically running upgrade, for details see /var/log/ipaupgrade.log
Be patient, this may take a few minutes.
Automatic upgrade failed: Update complete
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
Publish directory already set to new location
[Verifying that CA proxy configuration is correct]
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command 
ipa-server-upgrade manually.
CA did not start in 300.0s
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more 
information

See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade 
again
Aborting ipactl

2019-10-25T08:19:26Z INFO Restoring umask to 23
2019-10-25T08:19:26Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", 
line 428, in run
run(['ipactl', 'start'])
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))

2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception: 
CalledProcessError: Command 'ipactl start' returned non-zero exit status 1
2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit status 
1
2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See 
/var/log/iparestore.log for more information

In case you are aware of its fix/workaround, kindly share the steps.

Thanks,
sgarg
___
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312&sdata=P9YiAhfLP52C%2FuH0C%2BqyJYWovpEM90fMVy8VBgGsZh0%3D&reserved=0
List Guideli

[Freeipa-users] Re: number of topology segments for 3 servers clean setup?

2019-10-29 Thread Alexander Bokovoy via FreeIPA-users 

On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:

hi everyone,

I wanted to ask about number of segments after a clean IPA setup with 3
servers.

I see for both 'domain' & 'ca' two segments created by master/replica
installations, which makes me wonder - should there not be three? no/yes
& why?

You really need to show what you have rather than assume we know what
you have.

For three masters, there are several ways of connecting them so that
there are two segments. Or may be you connected all three in a triangle.

For example: A <-> B <-> C, B <-> A <-> C, A <-> B <-> C <-> A

Without knowing your topology it is not possible to say what is correct
and what is not.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

[Freeipa-users] number of topology segments for 3 servers clean setup?

2019-10-29 Thread lejeczek via FreeIPA-users 
hi everyone,

I wanted to ask about number of segments after a clean IPA setup with 3
servers.

I see for both 'domain' & 'ca' two segments created by master/replica
installations, which makes me wonder - should there not be three? no/yes
& why?

many thanks, L.



pEpkey.asc
Description: application/pgp-keys
___
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

[Freeipa-users] Re: Full Server backup fails with IPA version error

2019-10-29 Thread Saurabh Garg via FreeIPA-users 
Hi Rob, Thanks for your reply.

In our case we need to put in place a procedure/steps that can helps us to
come out from a situation where our complete IPA server setup (original
server and its replica both) is lost/deleted and need to get the same setup
back from the scheduled full-server-backups (through cron jobs) available
at some object storage location.

Please advice.

Thanks,
Saurabh Garg



On Fri, Oct 25, 2019 at 6:12 PM Rob Crittenden  wrote:

> Saurabh Garg via FreeIPA-users wrote:
> > Background -
> > We are trying to restore "full server" from an existing IPA server (with
> replication ON to another server) to a newly created IPA Server from the
> same golden image as all other servers.
>
> There is no restore with replication on. It would cause endless problems.
>
> Restore is expected to be for a single master in a catastrophic
> situation. The others will require re-init from this master.
>
> > Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
> > # ipa-server-install --version
> > 4.6.4
> >
> > Destination IPA Server: Red Hat Enterprise Linux Server release 7.7
> (Maipo)
> > # ipa-server-install --version
> > 4.6.4
> >
> > Problem Statement -
> > While running  "ipa-restore" (exact command: # ipa-restore
> /root/backup/) on the new IPA server for full server backup, system throws
> the following error lines in iparestore.log:
> >
> >
> > 2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be
> upgraded (expected version '4.6.4-10.el7_6.6', current version
> '4.6.4-10.el7_6.3')
> > Automatically running upgrade, for details see /var/log/ipaupgrade.log
> > Be patient, this may take a few minutes.
> > Automatic upgrade failed: Update complete
> > Upgrading the configuration of the IPA services
> > [Verifying that root certificate is published]
> > [Migrate CRL publish directory]
> > Publish directory already set to new location
> > [Verifying that CA proxy configuration is correct]
> > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
> command ipa-server-upgrade manually.
> > CA did not start in 300.0s
> > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
> more information
>
> It is very persnickety. The versions do not match.
>
> There are sometimes subtle differences between versions of IPA, even in
> minor releases, so it is not considered safe to restore between versions.
>
> You could hack out the version check and roll the dice, or downgrade the
> packages to match the backed-up value.
>
> 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

[Freeipa-users] Re: Full Server backup fails with IPA version error

2019-10-29 Thread Saurabh Garg via FreeIPA-users 
Thanks Angus for the reply.

In my case, original IPA server is completely damaged / deleted, and now I
am attempting to create an exactly similar server using "full-server"
backup.
Do you have any suggestions for such a scenario?

Thanks
sgarg

On Fri, Oct 25, 2019 at 6:05 PM Angus Clarke  wrote:

> Hi
>
> An alternative approach would be to setup your new server as an IPA client
> and then to promote it.
>
> On new server:
> # ipa-client-install
>
> Followed by
> # ipa-replica-install
>
> Check the man pages for options suitable to your environment, otherwise I
> specify --setup-ca for all our new IPA instances.
>
> I use this process for rolling out new IPA servers when we add new
> environments.
>
> Regards
> Angus
>
> --
> *From:* Saurabh Garg via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org>
> *Sent:* Friday, October 25, 2019 11:55:40 AM
> *To:* freeipa-users@lists.fedorahosted.org <
> freeipa-users@lists.fedorahosted.org>
> *Cc:* Saurabh Garg 
> *Subject:* [Freeipa-users] Full Server backup fails with IPA version error
>
> Background -
> We are trying to restore "full server" from an existing IPA server (with
> replication ON to another server) to a newly created IPA Server from the
> same golden image as all other servers.
>
> Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
> # ipa-server-install --version
> 4.6.4
>
> Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
> # ipa-server-install --version
> 4.6.4
>
> Problem Statement -
> While running  "ipa-restore" (exact command: # ipa-restore /root/backup/)
> on the new IPA server for full server backup, system throws the following
> error lines in iparestore.log:
>
>
> 2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be
> upgraded (expected version '4.6.4-10.el7_6.6', current version
> '4.6.4-10.el7_6.3')
> Automatically running upgrade, for details see /var/log/ipaupgrade.log
> Be patient, this may take a few minutes.
> Automatic upgrade failed: Update complete
> Upgrading the configuration of the IPA services
> [Verifying that root certificate is published]
> [Migrate CRL publish directory]
> Publish directory already set to new location
> [Verifying that CA proxy configuration is correct]
> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command
> ipa-server-upgrade manually.
> CA did not start in 300.0s
> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
> more information
>
> See the upgrade log for more details and/or run
> /usr/sbin/ipa-server-upgrade again
> Aborting ipactl
>
> 2019-10-25T08:19:26Z INFO Restoring umask to 23
> 2019-10-25T08:19:26Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in
> execute
> return_value = self.run()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", line
> 428, in run
> run(['ipactl', 'start'])
>   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562,
> in run
> raise CalledProcessError(p.returncode, arg_string, str(output))
>
> 2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception:
> CalledProcessError: Command 'ipactl start' returned non-zero exit status 1
> 2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit
> status 1
> 2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See
> /var/log/iparestore.log for more information
>
> In case you are aware of its fix/workaround, kindly share the steps.
>
> Thanks,
> sgarg
> ___
> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312&sdata=P9YiAhfLP52C%2FuH0C%2BqyJYWovpEM90fMVy8VBgGsZh0%3D&reserved=0
> List Guidelines:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312&sdata=211CDIyJCx7zCeyfeAfx34CRw08LGZbzneFgGZX%2Bggg%3D&reserved=0
> List Archives:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org&data=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312&sdata=nSLzErDuiZ6F0w5PD5WQLwobi3xqjvl6o9iu06daywo%3D&reserved=0
>
___
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.fedoraproj