Re: [Freeipa-users] Replica without CA: implications?
If, after identifying the dangling RUVs and attempting to clean them, you see this: [root@ipa-replica ~]# ipa-replica-manage clean-ruv 104 Clean the Replication Update Vector for ipa.example.com:389 Cleaning the wrong replica ID will cause that server to no longer replicate so it may miss updates while the process is running. It would need to be re-initialized to maintain consistency. Be very careful. Continue to clean? [no]: yes CLEANALLRUV task for replica id 104 already exists. This may be safely interrupted with Ctrl+C Does one have to use ldapmodify instead? Thanks, Dan [cid:image001.jpg@01D1C176.45C64B20]<http://www.high5games.com/> Daniel Alex Finkelstein| Senior Dev Ops Engineer dan.finkelst...@h5g.com<mailto:dan.finkelst...@h5g.com> | 212.604.3447 One World Trade Center, New York, NY 10007 www.high5games.com<http://www.high5games.com/> Play High 5 Casino<https://apps.facebook.com/highfivecasino/> and Shake the Sky<https://apps.facebook.com/shakethesky/> Follow us on: Facebook<http://www.facebook.com/high5games>, Twitter<https://twitter.com/High5Games>, YouTube<http://www.youtube.com/High5Games>, Linkedin<http://www.linkedin.com/company/1072533?trk=tyah> This message and any attachments may contain confidential or privileged information and are only for the use of the intended recipient of this message. If you are not the intended recipient, please notify the sender by return email, and delete or destroy this and all copies of this message and all attachments. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be unlawful. From: <freeipa-users-boun...@redhat.com> on behalf of Petr Vobornik <pvobo...@redhat.com> Date: Wednesday, June 8, 2016 at 06:55 To: Cal Sawyer <ca...@blue-bolt.com>, "freeipa-users@redhat.com" <freeipa-users@redhat.com> Subject: Re: [Freeipa-users] Replica without CA: implications? You need to identify which one is INCORRECT and then run ipa-replica-manage clean-ruv $incorrect command. The CORRECT one can identified with: ldapsearch -ZZ -h ipa2.localdomain.local -D "cn=Directory Manager" -W -b "dc=localdomain,dc=local" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsDS5ReplicaId" -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
Thanks very much for this, Petr. [08/Jun/2016:12:28:42 +0100] NSMMReplicationPlugin - CleanAllRUV Task (rid 8): Successfully cleaned rid(8). on master and all replicas. Voila - all error logs are now quiet Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com On 08/06/16 11:55, Petr Vobornik wrote: On 06/08/2016 11:15 AM, Cal Sawyer wrote: In /var/log/dirsrv/slapd-LOCALDOMAIN-LOCAL/errors on all IPA master/replicas:, there's a multitude of these messages. There are no other error messages and replication, from viewing access log, appears to be working [08/Jun/2016:10:06:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa.localdomain.local:389/dc%3Dlocaldomain%2Cdc%3Dlocal) failed. ipa-replica-manage list-ruv ipa.localdomain.local:389: 4 ipa4.localdomain.local:389: 28 ipa2.localdomain.local:389: 17 ipa3.localdomain.local:389: 29 ipa2.localdomain.local:389: 8 This is correct, yes? - c sawyer one of(probably 8): ipa2.localdomain.local:389: 17 ipa2.localdomain.local:389: 8 is incorrect. https://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records You need to identify which one is INCORRECT and then run ipa-replica-manage clean-ruv $incorrect command. The CORRECT one can identified with: ldapsearch -ZZ -h ipa2.localdomain.local -D "cn=Directory Manager" -W -b "dc=localdomain,dc=local" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsDS5ReplicaId" -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
On 06/08/2016 11:15 AM, Cal Sawyer wrote: > In /var/log/dirsrv/slapd-LOCALDOMAIN-LOCAL/errors on all IPA > master/replicas:, there's a multitude of these messages. There are no > other error messages and replication, from viewing access log, appears > to be working > > [08/Jun/2016:10:06:08 +0100] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ipa.localdomain.local:389/dc%3Dlocaldomain%2Cdc%3Dlocal) failed. > >> ipa-replica-manage list-ruv > > ipa.localdomain.local:389: 4 > ipa4.localdomain.local:389: 28 > ipa2.localdomain.local:389: 17 > ipa3.localdomain.local:389: 29 > ipa2.localdomain.local:389: 8 > > This is correct, yes? > > - c sawyer > one of(probably 8): ipa2.localdomain.local:389: 17 ipa2.localdomain.local:389: 8 is incorrect. https://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records You need to identify which one is INCORRECT and then run ipa-replica-manage clean-ruv $incorrect command. The CORRECT one can identified with: ldapsearch -ZZ -h ipa2.localdomain.local -D "cn=Directory Manager" -W -b "dc=localdomain,dc=local" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsDS5ReplicaId" -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
On 06/08/2016 11:05 AM, Cal Sawyer wrote: > > On 08/06/16 09:23, Martin Kosek wrote: >> On 06/07/2016 04:10 PM, Cal Sawyer wrote: >> ... >>> I found that installing a replica with firewalld enabled would consistently >>> fail >>> during initial replication. Disabling firewalld always allowed replication >>> and >>> later stages to complete >>> >>> [24/38]: setting up initial replication >>> Starting replication, please wait until this has completed. >>> >>> [ipa.localdomain.local] reports: Update failed! Status: [-1 - LDAP >>> error: >>> Can't contact LDAP server] >> This is strange. ipa-replica-install should have run the conncheck to exactly >> prevent issues like this. Did you by any chance run ipa-replica-install with >> --skip-conncheck option? >> > Yes, i did. There you go - pure PEBKAC :-) > Why i can't recall now but i just started using it. Once i'd > discovered firewalld was causing the connection problem, i neglected to stop > using it > Of course, once a replica is installed and working, there's little cause to > want to redo it to test conncheck's effectiveness. Might throw together > another, though, just to put my mind at ease For the record, you can also run ipa-replica-conncheck outside ipa-replica-install. > >>> The first master and all replicas are all CentOS Linux release 7.2.1511 >>> (Core) >>> with ipa-server-4.2.0-15.0.1.el7 >>> >>> >>> One other thing. if, during ipa-replica-install,+ you choose the default >>> answer >>> to the following: >>> >>> Existing BIND configuration detected, overwrite? [no]: >>> ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting >>> installation. >>> >>> Not sure if that is intended? Which BIND configuration is being detected? >> This should be only trigged if you install replica with DNS (--setup-dns) >> > Sorry - yes, i did use --setup-dns . I might have bothered to include the > ipa-replica-install command line i used. Still, that is what i got if i > answered No to the question. > Seems like it's the wrong default answer to the question in a --setup-dns > scenario? Yes. This means you do not want installer to modify and update named.conf for FreeIPA, i.e. it cannot install FreeIPA DNS module and has to abort. >>> Anyhow, up and running with 4 replicas, 2 of which will be split off to a >>> failover instance of ESXi in the future. When it works, it's a joy >>> >>> Now back to getting these Mac clients to play nicely with IPA ... >>> >>> thanks for the help and advice >> Thanks for sharing the results. >> Martin >> > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
In /var/log/dirsrv/slapd-LOCALDOMAIN-LOCAL/errors on all IPA master/replicas:, there's a multitude of these messages. There are no other error messages and replication, from viewing access log, appears to be working [08/Jun/2016:10:06:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa.localdomain.local:389/dc%3Dlocaldomain%2Cdc%3Dlocal) failed. > ipa-replica-manage list-ruv ipa.localdomain.local:389: 4 ipa4.localdomain.local:389: 28 ipa2.localdomain.local:389: 17 ipa3.localdomain.local:389: 29 ipa2.localdomain.local:389: 8 This is correct, yes? - c sawyer -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
On 08/06/16 09:23, Martin Kosek wrote: On 06/07/2016 04:10 PM, Cal Sawyer wrote: ... I found that installing a replica with firewalld enabled would consistently fail during initial replication. Disabling firewalld always allowed replication and later stages to complete [24/38]: setting up initial replication Starting replication, please wait until this has completed. [ipa.localdomain.local] reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP server] This is strange. ipa-replica-install should have run the conncheck to exactly prevent issues like this. Did you by any chance run ipa-replica-install with --skip-conncheck option? Yes, i did. Why i can't recall now but i just started using it. Once i'd discovered firewalld was causing the connection problem, i neglected to stop using it Of course, once a replica is installed and working, there's little cause to want to redo it to test conncheck's effectiveness. Might throw together another, though, just to put my mind at ease The first master and all replicas are all CentOS Linux release 7.2.1511 (Core) with ipa-server-4.2.0-15.0.1.el7 One other thing. if, during ipa-replica-install,+ you choose the default answer to the following: Existing BIND configuration detected, overwrite? [no]: ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting installation. Not sure if that is intended? Which BIND configuration is being detected? This should be only trigged if you install replica with DNS (--setup-dns) Sorry - yes, i did use --setup-dns . I might have bothered to include the ipa-replica-install command line i used. Still, that is what i got if i answered No to the question. Seems like it's the wrong default answer to the question in a --setup-dns scenario? Anyhow, up and running with 4 replicas, 2 of which will be split off to a failover instance of ESXi in the future. When it works, it's a joy Now back to getting these Mac clients to play nicely with IPA ... thanks for the help and advice Thanks for sharing the results. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
On 06/07/2016 04:10 PM, Cal Sawyer wrote: ... > I found that installing a replica with firewalld enabled would consistently > fail > during initial replication. Disabling firewalld always allowed replication > and > later stages to complete > >[24/38]: setting up initial replication > Starting replication, please wait until this has completed. > > [ipa.localdomain.local] reports: Update failed! Status: [-1 - LDAP error: > Can't contact LDAP server] This is strange. ipa-replica-install should have run the conncheck to exactly prevent issues like this. Did you by any chance run ipa-replica-install with --skip-conncheck option? > The first master and all replicas are all CentOS Linux release 7.2.1511 > (Core) > with ipa-server-4.2.0-15.0.1.el7 > > > One other thing. if, during ipa-replica-install,+ you choose the default > answer > to the following: > > Existing BIND configuration detected, overwrite? [no]: > ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting > installation. > > Not sure if that is intended? Which BIND configuration is being detected? This should be only trigged if you install replica with DNS (--setup-dns) > Anyhow, up and running with 4 replicas, 2 of which will be split off to a > failover instance of ESXi in the future. When it works, it's a joy > > Now back to getting these Mac clients to play nicely with IPA ... > > thanks for the help and advice Thanks for sharing the results. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
For the benefit, or added confusion, of future generations, some
observations
ipa-ca-install, run successful replica instantiation w/o --setup-ca
fails consistently with the errors in my orig post. Never figured out
what the script was finding that needed purging. After a multitude of
attempts (thank you, ESXi snapshots) with multiple ipa-server-install
--uninstall's , i gave up and rebuilt from the gound up withlatest
packages and --setup-ca which works great
I found that installing a replica with firewalld enabled would
consistently fail during initial replication. Disabling firewalld
always allowed replication and later stages to complete
[24/38]: setting up initial replication
Starting replication, please wait until this has completed.
[ipa.localdomain.local] reports: Update failed! Status: [-1 - LDAP
error: Can't contact LDAP server]
The first master and all replicas are all CentOS Linux release 7.2.1511
(Core) with ipa-server-4.2.0-15.0.1.el7
One other thing. if, during ipa-replica-install,+ you choose the
default answer to the following:
Existing BIND configuration detected, overwrite? [no]:
ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting
installation.
Not sure if that is intended? Which BIND configuration is being detected?
Anyhow, up and running with 4 replicas, 2 of which will be split off to
a failover instance of ESXi in the future. When it works, it's a joy
Now back to getting these Mac clients to play nicely with IPA ...
thanks for the help and advice
- cal
On 02/06/16 22:27, Rob Crittenden wrote:
Cal Sawyer wrote:
Apologies for the lengthy pause in getting back onto this. I ended up
destroying the replica and reprovisioning frmm scratch, but the replica
still lists as being CA-less.
Is what i'm seeing normal? Would this 2-node setup in this state
survive failure of the master?
It will until the certificates start expiring. You want at least 2
CA's to avoid a single point of failure situation.
-
ON MASTER ipa.localdomain.local
# ipa-replica-manage list
ipa2.localdomain.local: master
ipa.localdomain.local: master
# ipa-csreplica-manage list
>> ipa2.localdomain.local: CA not configured
ipa.localdomain.local: master
--
ON REPLICA ipa2.localdomain.local
# ipa-ca-install
Directory Manager (existing master) password:
>> CA is already installed.
ok
# ipa-ca-install -d
ipa.ipaserver.plugins.ldap2.ldap2: DEBUGCreated connection
context.ldap2_73731152
ipa.ipalib.plugins.config.config_show: DEBUGraw:
config_show(version=u'2.156')
ipa.ipalib.plugins.config.config_show: DEBUG config_show(rights=False,
all=False, raw=False, version=u'2.156')
ipa.ipapython.ipaldap.SchemaCache: DEBUGretrieving schema for
SchemaCache url=ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket
conn=
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUGraw:
ca_is_enabled(version=u'2.156')
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUG
ca_is_enabled(version=u'2.156')
ipa : DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 732, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 204, in main
install_master(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 191, in install_master
ca.install_check(True, None, options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
49, in install_check
sys.exit("CA is already installed.\n")
ipa : DEBUGThe ipa-ca-install command failed, exception:
SystemExit: CA is already installed.
>> CA is already installed.
It detects whether a CA is installed by the existence of something
like /var/lib/pki-tomcat/ca. You can use pkidestroy to remove any
remnants that might be left over from some previous failed install.
Or it could be that something wasn't updated properly in LDAP and
there actually is a working CA. You might try manually starting the CA
to see if it comes up, and/or run ipa-csreplica-manage to see if there
are any working agreements.
rob
thanks
- cal sawyer
On 09/03/16 16:13, Simo Sorce wrote:
On Wed, 2016-03-09 at 15:59 +, Cal Sawyer wrote:
Hi
Somehow i picked the wrong cookbook when i provisioned my first (and
only) replica and it lacks CA aso, as pointed out in a recent thread,
creates a single point of failure. Not ready to set up more 2
replicas
yet and am still in testing. Is it possible to replicate the master's
CA to the replica without destroying and reprovisioning with
--setup-ca
this time?
Use ipa-ca-install on the replica.
Simo.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
Cal Sawyer wrote:
Apologies for the lengthy pause in getting back onto this. I ended up
destroying the replica and reprovisioning frmm scratch, but the replica
still lists as being CA-less.
Is what i'm seeing normal? Would this 2-node setup in this state
survive failure of the master?
It will until the certificates start expiring. You want at least 2 CA's
to avoid a single point of failure situation.
-
ON MASTER ipa.localdomain.local
# ipa-replica-manage list
ipa2.localdomain.local: master
ipa.localdomain.local: master
# ipa-csreplica-manage list
>> ipa2.localdomain.local: CA not configured
ipa.localdomain.local: master
--
ON REPLICA ipa2.localdomain.local
# ipa-ca-install
Directory Manager (existing master) password:
>> CA is already installed.
ok
# ipa-ca-install -d
ipa.ipaserver.plugins.ldap2.ldap2: DEBUGCreated connection
context.ldap2_73731152
ipa.ipalib.plugins.config.config_show: DEBUGraw:
config_show(version=u'2.156')
ipa.ipalib.plugins.config.config_show: DEBUG config_show(rights=False,
all=False, raw=False, version=u'2.156')
ipa.ipapython.ipaldap.SchemaCache: DEBUGretrieving schema for
SchemaCache url=ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket
conn=
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUGraw:
ca_is_enabled(version=u'2.156')
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUG
ca_is_enabled(version=u'2.156')
ipa : DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 732, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 204, in main
install_master(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 191, in install_master
ca.install_check(True, None, options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
49, in install_check
sys.exit("CA is already installed.\n")
ipa : DEBUGThe ipa-ca-install command failed, exception:
SystemExit: CA is already installed.
>> CA is already installed.
It detects whether a CA is installed by the existence of something like
/var/lib/pki-tomcat/ca. You can use pkidestroy to remove any remnants
that might be left over from some previous failed install.
Or it could be that something wasn't updated properly in LDAP and there
actually is a working CA. You might try manually starting the CA to see
if it comes up, and/or run ipa-csreplica-manage to see if there are any
working agreements.
rob
thanks
- cal sawyer
On 09/03/16 16:13, Simo Sorce wrote:
On Wed, 2016-03-09 at 15:59 +, Cal Sawyer wrote:
Hi
Somehow i picked the wrong cookbook when i provisioned my first (and
only) replica and it lacks CA aso, as pointed out in a recent thread,
creates a single point of failure. Not ready to set up more 2 replicas
yet and am still in testing. Is it possible to replicate the master's
CA to the replica without destroying and reprovisioning with --setup-ca
this time?
Use ipa-ca-install on the replica.
Simo.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica without CA: implications?
Apologies for the lengthy pause in getting back onto this. I ended up
destroying the replica and reprovisioning frmm scratch, but the replica
still lists as being CA-less.
Is what i'm seeing normal? Would this 2-node setup in this state
survive failure of the master?
-
ON MASTER ipa.localdomain.local
# ipa-replica-manage list
ipa2.localdomain.local: master
ipa.localdomain.local: master
# ipa-csreplica-manage list
>> ipa2.localdomain.local: CA not configured
ipa.localdomain.local: master
--
ON REPLICA ipa2.localdomain.local
# ipa-ca-install
Directory Manager (existing master) password:
>> CA is already installed.
ok
# ipa-ca-install -d
ipa.ipaserver.plugins.ldap2.ldap2: DEBUGCreated connection
context.ldap2_73731152
ipa.ipalib.plugins.config.config_show: DEBUGraw:
config_show(version=u'2.156')
ipa.ipalib.plugins.config.config_show: DEBUG config_show(rights=False,
all=False, raw=False, version=u'2.156')
ipa.ipapython.ipaldap.SchemaCache: DEBUGretrieving schema for
SchemaCache url=ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket
conn=
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUGraw:
ca_is_enabled(version=u'2.156')
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUG ca_is_enabled(version=u'2.156')
ipa : DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 732, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 204, in main
install_master(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 191, in install_master
ca.install_check(True, None, options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
49, in install_check
sys.exit("CA is already installed.\n")
ipa : DEBUGThe ipa-ca-install command failed, exception:
SystemExit: CA is already installed.
>> CA is already installed.
thanks
- cal sawyer
On 09/03/16 16:13, Simo Sorce wrote:
On Wed, 2016-03-09 at 15:59 +, Cal Sawyer wrote:
Hi
Somehow i picked the wrong cookbook when i provisioned my first (and
only) replica and it lacks CA aso, as pointed out in a recent thread,
creates a single point of failure. Not ready to set up more 2 replicas
yet and am still in testing. Is it possible to replicate the master's
CA to the replica without destroying and reprovisioning with --setup-ca
this time?
Use ipa-ca-install on the replica.
Simo.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Replica without CA: implications?
Hi Somehow i picked the wrong cookbook when i provisioned my first (and only) replica and it lacks CA aso, as pointed out in a recent thread, creates a single point of failure. Not ready to set up more 2 replicas yet and am still in testing. Is it possible to replicate the master's CA to the replica without destroying and reprovisioning with --setup-ca this time? thanks - cal sawyer -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
