[Freeipa-users] How to get a new cert
Is there a guide anywhere for how to obtain an SSL certificate for a new server & service from the IPA CA master? Most of the guides I'm seeing online use web pages at the major CAs to do this and I'd like to keep it in the family. Thanks! -- *Bret Wortman* <http://wrapbuddies.co/> http://wrapbuddies.co/ -- 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] How to get a new cert
That looks like it worked, but I have a follow-on question: I need to provide my RabbitMQ instance with a cacert file, a cert, and a key file. These seem to be .pem files. Is there an easy way to gather these 3 files from a typical IPA client node? Merci! Bret On 09/27/2016 11:28 AM, Florence Blanc-Renaud wrote: Hi Bret, would the following be helpful? In "Linux Domain Identity, Authentication, and Policy Guide", Chapter 17.1.1 Requesting New Certificates for a User, Host, or Service [1] Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request On 09/27/2016 04:20 PM, Bret Wortman wrote: Is there a guide anywhere for how to obtain an SSL certificate for a new server & service from the IPA CA master? Most of the guides I'm seeing online use web pages at the major CAs to do this and I'd like to keep it in the family. Thanks! -- *Bret Wortman* <http://wrapbuddies.co/> http://wrapbuddies.co/ -- 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] How to get a new cert
Yeah, I'm still not getting this, and I'm probably missing something painfully obvious. I follow the steps here: 1. Log into the server for which I need the cert. 2. # certutil -R -d /etc/pki/nssdb -a -g 2048 -s "CN=testesk1.internal.net,O=INTERNAL.NET" > ssl.csr I then copy the contents of the csr file and paste it into the FreeIPA UI after selecting Actions->New Certificiate from the Host Settings page. 3. I then click Actions->Get Certificate on that same page to extract the contents and paste it into a new .pem file on the requesting host. But how do I get at the key that was used in the creation of this cert? I can get the cacert, and I've got the newly-issued cert, but what about the key? Thanks! Bret On 09/27/2016 02:00 PM, Bret Wortman wrote: That looks like it worked, but I have a follow-on question: I need to provide my RabbitMQ instance with a cacert file, a cert, and a key file. These seem to be .pem files. Is there an easy way to gather these 3 files from a typical IPA client node? Merci! Bret On 09/27/2016 11:28 AM, Florence Blanc-Renaud wrote: Hi Bret, would the following be helpful? In "Linux Domain Identity, Authentication, and Policy Guide", Chapter 17.1.1 Requesting New Certificates for a User, Host, or Service [1] Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request On 09/27/2016 04:20 PM, Bret Wortman wrote: Is there a guide anywhere for how to obtain an SSL certificate for a new server & service from the IPA CA master? Most of the guides I'm seeing online use web pages at the major CAs to do this and I'd like to keep it in the family. Thanks! -- *Bret Wortman* <http://wrapbuddies.co/> http://wrapbuddies.co/ -- 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] How to get a new cert
Perfect. That did the trick. Many thanks, Flo. Bret On 09/28/2016 09:47 AM, Florence Blanc-Renaud wrote: On 09/27/2016 08:00 PM, Bret Wortman wrote: That looks like it worked, but I have a follow-on question: I need to provide my RabbitMQ instance with a cacert file, a cert, and a key file. These seem to be .pem files. Is there an easy way to gather these 3 files from a typical IPA client node? Hi, you can retrieve the new cert using the GUI. Navigate to Identity tab, then Users or Hosts or Services and pick your user, host or service. You will find in the "Actions" button a command to "Get Certificate". This will open a new window with the content of the cert, that you can copy/paste into mycert.pem. Once you have obtained mycert.pem, you can add it to the NSS database that you used previously in order to generate the CSR: $ certutil -A -d path_to_database -i mycert.pem -t u,u,u -n mycert Add IPA CA to the nss database: $ certutil -A -d path_to_database -n "IPA CA" -t CT,, -a < /etc/ipa/ca.crt Then pk12util and openssl will allow you to extract the key and certs through a temp keys.p12 file: $ pk12util -o keys.p12 -n mycert -d path_to_database $ openssl pkcs12 -in keys.p12 -out mykey.pem -nodes The output is mykey.pem which contains the key, the new certificate and IPA CA certificate. HTH, Flo. Merci! Bret On 09/27/2016 11:28 AM, Florence Blanc-Renaud wrote: Hi Bret, would the following be helpful? In "Linux Domain Identity, Authentication, and Policy Guide", Chapter 17.1.1 Requesting New Certificates for a User, Host, or Service [1] Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request On 09/27/2016 04:20 PM, Bret Wortman wrote: Is there a guide anywhere for how to obtain an SSL certificate for a new server & service from the IPA CA master? Most of the guides I'm seeing online use web pages at the major CAs to do this and I'd like to keep it in the family. Thanks! -- *Bret Wortman* <http://wrapbuddies.co/> http://wrapbuddies.co/ -- 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] Signing certs with longer lifetimes (FreeIPA CA)
It seems all our certs being signed by the FreeIPA CA are given 2 year expirations. We'd like to increase that to 5 years. I've added "-v 60" to our certutil commands generating the CSRs, but the CA is still only issuing 24 month certs. What do I need to change to issue certs with longer lifetimes? We really don't want to go around every 2 years and reissue certs... -- *Bret Wortman* Damascus Products ph/fax: 1-855-644-2783 Wrap Buddies InDemand at http://bwortman.us/2ieQN4t -- 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] Signing certs with longer lifetimes (FreeIPA CA)
I'm generating CSRs like this:
# certutil -R -d $DB -a -g 2048 -v 60 -s "CN=${HOST},O=DAMASCUSGRP.COM" -8
${SHORTHOST},${HOST}
Then pasting this into the web interface of our IPA instance under
"Actions->New Certificate" on the host's page. I then use Actions->View
Certificate and see that it expires in 2019.
I want that cert to expire in 2022. What do I need to change to make
that happen, and what's the right way to do it? I looked at some of the
scripts & files under /etc/pki and see references to $DAYS that look to
do what I want, but I don't want to do something that'll get clobbered
at the next IPA upgrade.
Bret
On 01/19/2017 10:30 AM, Kimi Rachel wrote:
Mail
heyy Bret, how are you? lets talk details ..
On Thu, Jan 19, 2017 at 9:30 PM, Bret Wortman
mailto:bret.wort...@damascusgrp.com>>
wrote:
It seems all our certs being signed by the FreeIPA CA are given 2
year expirations. We'd like to increase that to 5 years. I've
added "-v 60" to our certutil commands generating the CSRs, but
the CA is still only issuing 24 month certs.
What do I need to change to issue certs with longer lifetimes? We
really don't want to go around every 2 years and reissue certs...
--
*Bret Wortman*
Damascus Products
ph/fax: 1-855-644-2783
Wrap Buddies InDemand at
http://bwortman.us/2ieQN4t
--
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] Best way to upgrade IPA servers from Fedora
Our IPA infrastructure is based entirely on servers running Fedora 21. We need (desperately) to upgrade these to C7 or RHEL. All are currently VMs. Does it make sense to: 1. Add a new host already running C7 to increase our total servers from 3 to 4 (call it IPA4) 2. Remove IPA1 and upgrade it to C7, install the IPA server packages and join it back into the collective 3. Remove IPA2 and upgrade it like IPA1. Add it back. 4. Somehow migrate the CA function to one of the C7 nodes from IPA3. Trash or repurpose this VM. What's the right way to do this? If I've got it right here, what's the best way to move the CA function from the node it's on now to one of the freshly-upgraded hosts? Thanks! -- *Bret Wortman* Damascus Products ph/fax: 1-855-644-2783 Wrap Buddies InDemand at http://bwortman.us/2ieQN4t -- 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] Best practices for core servers
We are planning to reconfigure our core Freeipa servers, basically building a replacement infrastructure and migrating to it. What we're planning right now is a core of three Freeipa servers each of which has a CA, with as much distribution of replication as we can manage. I imagine that means one of them replicates to the other two but am open to other ideas. For remote locations, we're planning to stand up caching-only DNS servers, as authenticating back to the main IPA servers works extremely well; it's just DNS that needs a little help. Any thoughts before I start setting these servers (VMs, most likely) up? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Error creating new freeipa-server
I'm trying to stand up a new ipa server on a clean box, and I keep
getting this error so _something_ is amiss but I'm not sure what:
:
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
[1/22]: creating certificate server user
[2/22]: configuring certificate server instance
ipa: CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
Configuration of CA failed
#
In the /var/log/ipaserver-install.log, I see this:
:
:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed.
2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR PKI
subsystem 'CA' for instance 'pki-tomcat' already exists!
2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
2014-04-28T11:43:46Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 622, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1074, in main
dm_password, subject_base=options.subject)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
478, in configure_instance
self.start_creation(runtime=210)
File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
604, in __spawn_instance
raise RUntimeError('Configuration of CA failed')
:
:
So it looks like somehow this has gotten configured already. Possibly
Puppet copied over something it shouldn't have. What do I need to remove
to make this step work without removing so much that I render something
inoperable?
--
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
Not to be thick, but what's the best way to check the DS instance for a
pki entry?
On 04/28/2014 07:57 AM, Dmitri Pal wrote:
On 04/28/2014 07:52 AM, Bret Wortman wrote:
I'm trying to stand up a new ipa server on a clean box, and I keep
getting this error so _something_ is amiss but I'm not sure what:
:
Configuring certificate server (pki-tomcatd): Estimated time 3
minutes 30 seconds
[1/22]: creating certificate server user
[2/22]: configuring certificate server instance
ipa: CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit
status 1
Configuration of CA failed
#
In the /var/log/ipaserver-install.log, I see this:
:
:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed.
2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR
PKI subsystem 'CA' for instance 'pki-tomcat' already exists!
2014-04-28T11:432:46Z CRITICAL failed to configure ca instance
Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned
non-zero exit status 1
2014-04-28T11:43:46Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 622, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1074, in main
dm_password, subject_base=options.subject)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 478, in configure_instance
self.start_creation(runtime=210)
File
"/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py", line
364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 604, in __spawn_instance
raise RUntimeError('Configuration of CA failed')
:
:
So it looks like somehow this has gotten configured already. Possibly
Puppet copied over something it shouldn't have. What do I need to
remove to make this step work without removing so much that I render
something inoperable?
Run uninstall several times. Each time uninstall might clean next
portion and untangle things so trying to do it several times pays off.
Then check if there is a DS instance for PKI. If there is remove it
and try again.
--
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
Great. I'll try that next.
Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman
> On Apr 28, 2014, at 8:33 AM, Petr Viktorin wrote:
>
>> On 04/28/2014 01:52 PM, Bret Wortman wrote:
>> I'm trying to stand up a new ipa server on a clean box, and I keep
>> getting this error so _something_ is amiss but I'm not sure what:
>>
>> :
>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
>> 30 seconds
>> [1/22]: creating certificate server user
>> [2/22]: configuring certificate server instance
>> ipa: CRITICAL failed to configure ca instance Command
>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
>> Configuration of CA failed
>> #
>>
>> In the /var/log/ipaserver-install.log, I see this:
>>
>> :
>> :
>> Installing CA into /var/lib/pki/pki-tomcat.
>>
>> Installation failed.
>>
>>
>> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR PKI
>> subsystem 'CA' for instance 'pki-tomcat' already exists!
>>
>> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command
>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status 1
>> 2014-04-28T11:43:46Z DEBUG File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>> line 622, in run_script
>> return_value = main_function()
>>
>> File "/usr/sbin/ipa-server-install", line 1074, in main
>> dm_password, subject_base=options.subject)
>>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>> 478, in configure_instance
>> self.start_creation(runtime=210)
>>
>> File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py",
>> line 364, in start_creation
>> method()
>>
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>> 604, in __spawn_instance
>> raise RUntimeError('Configuration of CA failed')
>> :
>> :
>>
>> So it looks like somehow this has gotten configured already. Possibly
>> Puppet copied over something it shouldn't have. What do I need to remove
>> to make this step work without removing so much that I render something
>> inoperable?
>
>
> According to the error you're getting, there is a CA instance already
> installed.
> After uninstalling IPA, destroy it with:
>pkidestroy -s CA -i pki-tomcat
>
>
>
> --
> Petr³
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME cryptographic signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
I thought that might be it and didn't see anything but will look again.
Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman
> On Apr 28, 2014, at 8:20 AM, Dmitri Pal wrote:
>
>> On 04/28/2014 08:06 AM, Bret Wortman wrote:
>> Not to be thick, but what's the best way to check the DS instance for
>> a pki entry?
>
> I do not remember the exact path and I do not have an instance handy.
> Something like /var/lib/dirsrv/PKI, do not want to mislead you.
>
>
>>
>>> On 04/28/2014 07:57 AM, Dmitri Pal wrote:
>>>> On 04/28/2014 07:52 AM, Bret Wortman wrote:
>>>> I'm trying to stand up a new ipa server on a clean box, and I keep getting
>>>> this error so _something_ is amiss but I'm not sure what:
>>>>
>>>> :
>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30
>>>> seconds
>>>> [1/22]: creating certificate server user
>>>> [2/22]: configuring certificate server instance
>>>> ipa: CRITICAL failed to configure ca instance Command
>>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status
>>>> 1
>>>> Configuration of CA failed
>>>> #
>>>>
>>>> In the /var/log/ipaserver-install.log, I see this:
>>>>
>>>> :
>>>> :
>>>> Installing CA into /var/lib/pki/pki-tomcat.
>>>>
>>>> Installation failed.
>>>>
>>>>
>>>> 2014-04-28T11:43:46Z DEBUG stderr=pkispawn : ERROR PKI
>>>> subsystem 'CA' for instance 'pki-tomcat' already exists!
>>>>
>>>> 2014-04-28T11:432:46Z CRITICAL failed to configure ca instance Command
>>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpX8RW20' returned non-zero exit status
>>>> 1
>>>> 2014-04-28T11:43:46Z DEBUG File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
>>>> 622, in run_script
>>>> return_value = main_function()
>>>>
>>>> File "/usr/sbin/ipa-server-install", line 1074, in main
>>>> dm_password, subject_base=options.subject)
>>>>
>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>> line 478, in configure_instance
>>>> self.start_creation(runtime=210)
>>>>
>>>> File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py",
>>>> line 364, in start_creation
>>>> method()
>>>>
>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>> line 604, in __spawn_instance
>>>> raise RUntimeError('Configuration of CA failed')
>>>> :
>>>> :
>>>>
>>>> So it looks like somehow this has gotten configured already. Possibly
>>>> Puppet copied over something it shouldn't have. What do I need to remove
>>>> to make this step work without removing so much that I render something
>>>> inoperable?
>>> Run uninstall several times. Each time uninstall might clean next portion
>>> and untangle things so trying to do it several times pays off.
>>> Then check if there is a DS instance for PKI. If there is remove it and try
>>> again.
>>>
>>>> --
>>>> Bret Wortman
>>>>
>>>> http://damascusgrp.com/
>>>> http://about.me/wortmanbret
>>>>
>>>>
>>>>
>>>> ___
>>>> Freeipa-users mailing list
>>>> Freeipa-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Sr. Engineering Manager IdM portfolio
>>> Red Hat, Inc.
>>>
>>>
>>> ___
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME cryptographic signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 08:33 AM, Petr Viktorin wrote: According to the error you're getting, there is a CA instance already installed. After uninstalling IPA, destroy it with: pkidestroy -s CA -i pki-tomcat I tried, this, but no joy. # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat /ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ... this 'CA' entry will NOT be deleted from security domain 'unknown'! pkidestroy : ERROR ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Uninstallation complete. # And then when I tried to run ipa-server-install, I got the same error again. I may just wipe the box and start over. It might take less time overall. Bret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 10:21 AM, Bret Wortman wrote: On 04/28/2014 08:33 AM, Petr Viktorin wrote: According to the error you're getting, there is a CA instance already installed. After uninstalling IPA, destroy it with: pkidestroy -s CA -i pki-tomcat I tried, this, but no joy. # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat /ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ... this 'CA' entry will NOT be deleted from security domain 'unknown'! pkidestroy : ERROR ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Uninstallation complete. # And then when I tried to run ipa-server-install, I got the same error again. I may just wipe the box and start over. It might take less time overall. Bret This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also dogtag-10.1.1-1). smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 10:48 AM, Rob Crittenden wrote: Bret Wortman wrote: On 04/28/2014 10:21 AM, Bret Wortman wrote: On 04/28/2014 08:33 AM, Petr Viktorin wrote: According to the error you're getting, there is a CA instance already installed. After uninstalling IPA, destroy it with: pkidestroy -s CA -i pki-tomcat I tried, this, but no joy. # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat /ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ... this 'CA' entry will NOT be deleted from security domain 'unknown'! pkidestroy : ERROR ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Uninstallation complete. # And then when I tried to run ipa-server-install, I got the same error again. I may just wipe the box and start over. It might take less time overall. Bret This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also dogtag-10.1.1-1). From the ipa-server installation output the error looks the same, but the underlying error should be different when there isn't already a PKI instance. If the PKI installer fails early enough we don't record that it was installed which is why ipa-server-install --uninstall doesn't remove it. We have a ticket open for this. rob So is there a recommended way to clean it up and get it working? smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 11:08 AM, Bret Wortman wrote: On 04/28/2014 10:48 AM, Rob Crittenden wrote: Bret Wortman wrote: On 04/28/2014 10:21 AM, Bret Wortman wrote: On 04/28/2014 08:33 AM, Petr Viktorin wrote: According to the error you're getting, there is a CA instance already installed. After uninstalling IPA, destroy it with: pkidestroy -s CA -i pki-tomcat I tried, this, but no joy. # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat /ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ... this 'CA' entry will NOT be deleted from security domain 'unknown'! pkidestroy : ERROR ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Uninstallation complete. # And then when I tried to run ipa-server-install, I got the same error again. I may just wipe the box and start over. It might take less time overall. Bret This, BTW, is on F20 using freeipa 3.3.4-3 and pki-ca 10.1.1-1 (also dogtag-10.1.1-1). From the ipa-server installation output the error looks the same, but the underlying error should be different when there isn't already a PKI instance. If the PKI installer fails early enough we don't record that it was installed which is why ipa-server-install --uninstall doesn't remove it. We have a ticket open for this. rob So is there a recommended way to clean it up and get it working? Never mind; I found the bug (953488) which said to: # pkidestroy -s CA -i pki-tomcat ERROR: PKI instance '/var/lib/pki/pki-tomcat' does NOT exist! # rm -rf /var/log/pki/pki-tomcat # rm -rf /etc/sysconfig/pki-tomcat # rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat # rm -rf /var/lib/pki/pki-tomcat # rm -rf /etc/pki/pki-tomcat # ipa-server-install --uninstall And re-run installation. This didn't work for me. Was there another bug that I missed? smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 11:17 AM, Rob Crittenden wrote:
Bret Wortman wrote:
So is there a recommended way to clean it up and get it working?
Re-run pkidestroy, then if the subsequent IPA install fails closely
examine the logs to determine the reason. The problem in cases like
this is that the first install fails and subsequent installs mask the
original failure with this PKI re-install failure.
rob
Okay, here's the log from when it starts configuring PKI:
2014-04-28T15:23:45Z DEBUG [2/22]: configuring certificate server instance
2014-04-28T15:23:45Z DEBUG Contents of pkispawn configuration file
(/tmp/tmpdCm6rt):
[CA]
pki_security_domain_name = IPA
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki-backup_password =
pki_client_database_dir = /tmp/tmp-rVoTR2
pki_client_database_password =
pki_client_database_purge = False
pki_client_pkcs12_password =
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password =
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=FOO.NET
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password =
pki_ds_base_dn = o=ipaca
pki_ds_database = ipaca
pki_subsystem_subject+dn = cn=CA Subsystem,O=FOO.NET
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FOO.NET
pki_ssl_server_subject_dn = cn=zsipa.foo.net,O=FOO.NET
pki_audit_signing_subject_dn = cn=CA Audit,O=FOO.NET
pki_ca_signing_subject_dn = cn-Certificate Authority,O=FOO.NET
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-ca
pki_ca_signing_nickname = caSigningCert cert-pki-ca
2014-04-28T15:23:45Z DEBUG Starting external process
2014-04-28T15:23:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt
2014-04-28T15:23:45Z DEBUG Process finished, return code=1
2014-04-28T15:23:45Z DEBUG stdout=Loading deployment configuration from
/tmp/tmpdCm6rt.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg
Installation failed.
2014-04-28T15:24:46Z DEBUG stderr=pkispawn : ERROR ... server
failed to restart
2014-04-28T15:24:46Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt' returned non-zero exit status 1
2014-04-28T15:24:46Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 622, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1074, in main
dm_password, subject_base=options.subject)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
478, in configure_instance
self.start_creation(runtime=210)
File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
604, in __spawn_instance
raise RUntimeError('Configuration of CA failed')
2014-04-28T15:24:46Z DEBUG The ipa-server-install command failed,
exception: RuntimeError: Configuration of CA failed
And that's the end of the log. Nothing here looks terribly informative
to me, and this is what the log looks like every time I look at it.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error creating new freeipa-server
On 04/28/2014 11:52 AM, Rob Crittenden wrote:
Bret Wortman wrote:
On 04/28/2014 11:17 AM, Rob Crittenden wrote:
Bret Wortman wrote:
So is there a recommended way to clean it up and get it working?
Re-run pkidestroy, then if the subsequent IPA install fails closely
examine the logs to determine the reason. The problem in cases like
this is that the first install fails and subsequent installs mask the
original failure with this PKI re-install failure.
rob
Okay, here's the log from when it starts configuring PKI:
2014-04-28T15:23:45Z DEBUG [2/22]: configuring certificate server
instance
2014-04-28T15:23:45Z DEBUG Contents of pkispawn configuration file
(/tmp/tmpdCm6rt):
[CA]
pki_security_domain_name = IPA
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki-backup_password =
pki_client_database_dir = /tmp/tmp-rVoTR2
pki_client_database_password =
pki_client_database_purge = False
pki_client_pkcs12_password =
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password =
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=FOO.NET
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password =
pki_ds_base_dn = o=ipaca
pki_ds_database = ipaca
pki_subsystem_subject+dn = cn=CA Subsystem,O=FOO.NET
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FOO.NET
pki_ssl_server_subject_dn = cn=zsipa.foo.net,O=FOO.NET
pki_audit_signing_subject_dn = cn=CA Audit,O=FOO.NET
pki_ca_signing_subject_dn = cn-Certificate Authority,O=FOO.NET
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-ca
pki_ca_signing_nickname = caSigningCert cert-pki-ca
2014-04-28T15:23:45Z DEBUG Starting external process
2014-04-28T15:23:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f
/tmp/tmpdCm6rt
2014-04-28T15:23:45Z DEBUG Process finished, return code=1
2014-04-28T15:23:45Z DEBUG stdout=Loading deployment configuration from
/tmp/tmpdCm6rt.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg
Installation failed.
2014-04-28T15:24:46Z DEBUG stderr=pkispawn : ERROR ... server
failed to restart
2014-04-28T15:24:46Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpdCm6rt' returned non-zero exit
status 1
2014-04-28T15:24:46Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 622, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1074, in main
dm_password, subject_base=options.subject)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
478, in configure_instance
self.start_creation(runtime=210)
File "/usr/lib/python2.7/site-packages/ipaserver/isntall/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
604, in __spawn_instance
raise RUntimeError('Configuration of CA failed')
2014-04-28T15:24:46Z DEBUG The ipa-server-install command failed,
exception: RuntimeError: Configuration of CA failed
And that's the end of the log. Nothing here looks terribly informative
to me, and this is what the log looks like every time I look at it.
The error is different whether there is an existing PKI instance or not.
The next set of logs to look at are in /var/log/pki. It says there is
a startup failure so I'd start with
*/var/log/pki/pki-tomcat/catalina.out* . Also interesting may be the
pki-ca-spawn and debug logs found within that directory structure.
I'd also look for SELinux errors with ausearch -m AVC -ts recent
This did the trick. Something was hanging out on port 8443, though
neither lsof nor netstat would show me what it was. I rebooted the
server and then it proceeded past this without a hiccup.
Thanks, Rob and everyone else for helping me navigate the logs!
Bret
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Can't use "ipa" commands on brand new ipa server instance
I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data. Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance
On 04/28/2014 01:19 PM, Bret Wortman wrote: I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data. Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs? BTW, we have this running on F20 on a different network and it works just fine. The network on which the failures are occurring isn't internet-connected; is there something that's trying to connect back to redhat? smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance
bash. On 04/28/2014 01:32 PM, Simo Sorce wrote: On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: On 04/28/2014 01:19 PM, Bret Wortman wrote: I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data. Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs? BTW, we have this running on F20 on a different network and it works just fine. The network on which the failures are occurring isn't internet-connected; is there something that's trying to connect back to redhat? no. What shell do you use ? Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance
On 04/28/2014 01:53 PM, Simo Sorce wrote: On 04/28/2014 01:32 PM, Simo Sorce wrote: On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote: On 04/28/2014 01:19 PM, Bret Wortman wrote: I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data. Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs? BTW, we have this running on F20 on a different network and it works just fine. The network on which the failures are occurring isn't internet-connected; is there something that's trying to connect back to redhat? no. What shell do you use ? On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote: bash. Does it make any difference if you redirect stdin before calling the command ? Simo. No, I found the problem. A "power" user had written a bash function that redefined "ipa" and dropped it into /etc/profile.d. We're about to have a little chat. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't use "ipa" commands on brand new ipa server instance
Oh, I like that idea. A lot.
On 04/28/2014 03:31 PM, Bill Peck wrote:
Let me guess, ipa logs you out so you can go have a beer?
On Mon, Apr 28, 2014 at 2:10 PM, Simo Sorce <mailto:s...@redhat.com>> wrote:
On Mon, 2014-04-28 at 14:05 -0400, Bret Wortman wrote:
> On 04/28/2014 01:53 PM, Simo Sorce wrote:
> >> On 04/28/2014 01:32 PM, Simo Sorce wrote:
> >>> On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote:
> >>>> On 04/28/2014 01:19 PM, Bret Wortman wrote:
> >>>>> I just got a new ipa server instantiated and haven't actually
> >>>>> installed any users or hosts on it yet. No replicas. No
migrated data.
> >>>>>
> >>>>> Yet when I run any "ipa" commands from the command line,
it behaves
> >>>>> exactly as our older, troubled servers do and exits the
login session
> >>>>> immediately, whether I'm connected at the console or via
ssh. Further,
> >>>>> when I run strace to try to capture what might be going
on, the
> >>>>> behavior stops. "Script" also prevents commands from
exiting, but this
> >>>>> is really disconcerting. I was chalking this up to the
fact that our
> >>>>> database had become corrupted by our replication problems,
but now I'm
> >>>>> thinking it might be environmental, though our original
IPA servers
> >>>>> are running F18 and this new instance is F20.
> >>>>>
> >>>>> I need some stability here, and CLI is part of that. What
might be
> >>>>> causing the CLI to not work at all when coupled to a TTY
device, as
> >>>>> that seems to be the critical piece? Could this be related
to the
> >>>>> servers being VMs?
> >>>>>
> >>>> BTW, we have this running on F20 on a different network and
it works
> >>>> just fine. The network on which the failures are occurring
isn't
> >>>> internet-connected; is there something that's trying to
connect back to
> >>>> redhat?
> >>> no.
> >>>
> >>> What shell do you use ?
> > On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote:
> >> bash.
> > Does it make any difference if you redirect stdin before
calling the
> > command ?
> >
> > Simo.
> >
> No, I found the problem. A "power" user had written a bash
function that
> redefined "ipa" and dropped it into /etc/profile.d. We're about
to have
> a little chat.
lol!
glad you found it :)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Switching a client from one set of IPA servers to another
I'd like to test migrating our clients from the old IPA infrastructure
to our newer F20-based servers but am having trouble with our first
clients. Unenrolling them from the old IPA servers went fine, but when I
try to enroll them with the newer ones, the logs report:
# ipa-client-install -U --server zsipa.foo.net --domain foo.net
--password obscured --mkhomdir --enable-dns-updates
LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has
been marked as not trusted by the user.
LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer has
been marked as not trusted by the user.
Failed to verify that zsipa.foo.net is an IPA Server.
This may mean that the remote server is not up or is not reachable due
to network or firewall settings.
:
:
Installation failed. Rolling back changes.
IPA client is not configured on this system.
# ps aux | grep firewalld| grep -v grep
# getenforce
Disabled
# cat /var/log/ipaclient-install.log
:
:
DEBUG [LDAP server check]
DEBUG Verifying that zsipa.foo.net (realm foo.net) is an IPA server
DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389
ERROR LDAP Error: Connect error: TLS error -8173:Peer's certificate
issuer has been marked as not trusted by the user.
DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net,
kdc=zsipa.foo.net, basedn=None
DEBUG Validated servers:
DEBUG will use discovered domain: foo.net
DEBUG IPA Server not found
DEBUG [IPA Discovery] Starting IPA discovery with domain=foo.net,
servers=['zsipa.foo.net'], hostname=jsutil.foo.net
DEBUG Server and domain forced
DEBUG [Kerberos realm search]
DEBUG Search DNS for TXT record of _kerberos.foo.net
DEBUG DNS record found:
DNSResult::name:_kerberos.foo.net.,type:16,class:1,rdata={data:FOO.NET}
DEBUG Search DNS for SRV record of
_kerberos._udp.foo.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:zsipa.foo.net.}
DEBUG [LDAP server check]
DEBUG Verifying that zsipa.foo.net (realm FOO.NET)is an IPA server
DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389
ERROR LDAP Error: Connect error: TLS error -8172:Peer's certificate
issuer has been marked as not trusted by the user.
DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net,
kdc=zsipa.foo.net, basedn=None
DEBUG Validated servers:
ERROR Failed to verify that zsipa.foo.net is an IPA Server.
ERROR This may mean that the remote server is not up or is not reachable
due to network or firewall settings.
INFO Please make sure the following ports are opened in the firewall
settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working
properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
DEBUG (zspia.foo.net: Provided as option)
ERROR Installation failed. Rolling back changes.
ERROR IPA client is not configured on this system.
I removed the timestamps for readability.
It seems to me that something from the old version is hanging around and
getting in the way, or that something in the setup of the new server
isn't quite complete -- which seems more likely, and where should I be
looking for the actual cause? Is this a problem with a certificate or
with the server not being discoverable?
--
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Switching a client from one set of IPA servers to another
Crap. Thought I caught this before I sent it.
# rm -f /etc/ipa/ca.crt
On 04/29/2014 01:22 PM, Bret Wortman wrote:
I'd like to test migrating our clients from the old IPA infrastructure
to our newer F20-based servers but am having trouble with our first
clients. Unenrolling them from the old IPA servers went fine, but when
I try to enroll them with the newer ones, the logs report:
# ipa-client-install -U --server zsipa.foo.net --domain foo.net
--password obscured --mkhomdir --enable-dns-updates
LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer
has been marked as not trusted by the user.
LDAP Error: Connect error: TLS error -8172:Peer's certificate issuer
has been marked as not trusted by the user.
Failed to verify that zsipa.foo.net is an IPA Server.
This may mean that the remote server is not up or is not reachable due
to network or firewall settings.
:
:
Installation failed. Rolling back changes.
IPA client is not configured on this system.
# ps aux | grep firewalld| grep -v grep
# getenforce
Disabled
# cat /var/log/ipaclient-install.log
:
:
DEBUG [LDAP server check]
DEBUG Verifying that zsipa.foo.net (realm foo.net) is an IPA server
DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389
ERROR LDAP Error: Connect error: TLS error -8173:Peer's certificate
issuer has been marked as not trusted by the user.
DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net,
kdc=zsipa.foo.net, basedn=None
DEBUG Validated servers:
DEBUG will use discovered domain: foo.net
DEBUG IPA Server not found
DEBUG [IPA Discovery] Starting IPA discovery with domain=foo.net,
servers=['zsipa.foo.net'], hostname=jsutil.foo.net
DEBUG Server and domain forced
DEBUG [Kerberos realm search]
DEBUG Search DNS for TXT record of _kerberos.foo.net
DEBUG DNS record found:
DNSResult::name:_kerberos.foo.net.,type:16,class:1,rdata={data:FOO.NET}
DEBUG Search DNS for SRV record of
_kerberos._udp.foo.net.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:zsipa.foo.net.}
DEBUG [LDAP server check]
DEBUG Verifying that zsipa.foo.net (realm FOO.NET)is an IPA server
DEBUG Init LDAP connection with: ldap://zsipa.foo.net:389
ERROR LDAP Error: Connect error: TLS error -8172:Peer's certificate
issuer has been marked as not trusted by the user.
DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=foo.net,
kdc=zsipa.foo.net, basedn=None
DEBUG Validated servers:
ERROR Failed to verify that zsipa.foo.net is an IPA Server.
ERROR This may mean that the remote server is not up or is not
reachable due to network or firewall settings.
INFO Please make sure the following ports are opened in the firewall
settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working
properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
DEBUG (zspia.foo.net: Provided as option)
ERROR Installation failed. Rolling back changes.
ERROR IPA client is not configured on this system.
I removed the timestamps for readability.
It seems to me that something from the old version is hanging around
and getting in the way, or that something in the setup of the new
server isn't quite complete -- which seems more likely, and where
should I be looking for the actual cause? Is this a problem with a
certificate or with the server not being discoverable?
--
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Best practices for core servers
I can already see from this that our key problem may have been that we had one server functioning as the hub and every other remote replica had just one agreement, but those agreements were all with the hub. So that hub had ten agreements. Badness. We'll give this some good attention as we move forward. Thanks for the pointer, Martin. Bret On 04/30/2014 03:15 AM, Martin Kosek wrote: On 04/28/2014 01:03 PM, Bret Wortman wrote: We are planning to reconfigure our core Freeipa servers, basically building a replacement infrastructure and migrating to it. What we're planning right now is a core of three Freeipa servers each of which has a CA, with as much distribution of replication as we can manage. I imagine that means one of them replicates to the other two but am open to other ideas. You can configure them to replica to each other. For remote locations, we're planning to stand up caching-only DNS servers, as authenticating back to the main IPA servers works extremely well; it's just DNS that needs a little help. Any thoughts before I start setting these servers (VMs, most likely) up? You may want to read our upstream Deployment Recommendations article, it may save you some bad decisions from the start: http://www.freeipa.org/page/Deployment_Recommendations If we see that we missed anything in this article, it would be great to enhance it. Martin smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA down hard. Kerberos?
Happy Monday to me -- I came in this morning to find all 3 of my IPA replicas are down. When I tried to start one of them, I got this: [root@ipa1 ~]# ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Job for krb5kdc.service failed. See 'systemctl status krb5kdc.service' and 'journalctl -xn' for details. Failed to start krb5kdc Service Shutting down Aborting ipactl [root@ipa1 ~]# systemctl status krb5kdc.service krb5kdc.service - Kerberos 5 KDC Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; disabled) Active: failed (Result: exit-code) since Mon 2014-05-19 06:46:24 EDT; 51s ago Process: 1835 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5kdc.pid $KRB5KDC_ARGS (code=exited, status=1/FAILURE) May 19 06:46:24 ipa1.foo.net systemd[1]: krb5kdc.service: control process exited, code=exited status=1 May 19 06:46:24 ipa1.foo.net systemd[1]: Failed to start Kerberos 5 KDC. May 19 06:46:24 ipa1.foo.net systemd[1]: Unit krb5kdc.service entered failed state. May 19 06:46:24 ipa1.foo.net systemd[1]: Stopped Kerberos 5 KDC. [root@ipa1 ~]# journalctl -xn -- Logs begin at Tue 2014-05-13 09:50:44 EDT, end at Mon 2014-05-19 06:47:03 EDT. -- May 19 06:46:42 ipa1.foo.net ntpd_intres[526]: host name not found: 2.fedora.pool.ntp.org May 19 06:46:58 ipa1.foo.net sshd[1855]: error: AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys returned status 1 May 19 06:47:00 ipa1.foo.net sshd[1855]: Accepted password for root from 192.168.2.13 port 42299 ssh2 May 19 06:47:00 ipa1.foo.net systemd[1]: Starting Session 5 of user root. -- Subject: Unit session-5.scope has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-5.scope has begun starting up. May 19 06:47:00 ipa1.foo.net systemd-logind[495]: New session 5 of user root. -- Subject: A new session 5 has been created for user root -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- -- A new session with the ID 5 has been created for the user root. -- -- The leading process of the session is 1855. May 19 06:47:00 ipa1.foo.net systemd[1]: Started Session 5 of user root. -- Subject: Unit session-5.scope has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-5.scope has finished starting up. -- -- The start-up result is done. May 19 06:47:00 ipa1.foo.net sshd[1855]: pam_unix(sshd:session): session opened for user root by (uid=0) May 19 06:47:03 ipa1.foo.net systemd[1]: Stopped 389 Directory Server WEDGEOFLI-ME.. -- Subject: Unit dirsrv@WEDGEOFLI-ME.service has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit dirsrv@WEDGEOFLI-ME.service has finished shutting down. May 19 06:47:03 ipa1.foo.net systemd[1]: Stopping 389 Directory Server. -- Subject: Unit dirsrv.target has begun shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit dirsrv.target has begun shutting down. May 19 06:47:03 ipa1.foo.net systemd[1]: Stopped target 389 Directory Server. -- Subject: Unit dirsrv.target has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit dirsrv.target has finished shutting down. [root@ipa1 ~]# Any thoughts on where to look next? There's nothing at all logged in /var/log/krb5kdc.log when I try to start it up, and there are so many pieces to this that I'm not sure where to focus my efforts. Thanks! -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] New replica won't accept replication
This occurs on our first attempt to join as a replica. I've erased this
box and rebaselined it but the same thing happens. No network ports
being blocked that we know of, and another replica I created at the same
time installed its replica file without issue.
asipa is the new replica, zsipa is the ca and original master on which
the replica file was created.
[24/34]: setting up initial replication
Starting replication, please wait until this has completed
Update in progress, 130 seconds elapsed
Update in progress yet not in progress
[ipamaster.foo.net] reports: Update failed! Status: [10 Total update
abortedLDAP error: Referral]
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
#
/var/log/ipareplica-install.log contains this:
2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
url=ldaps://asipa.fopo.net:636 conn=instance at 0x4faf170>
2014-05-21T14:31:08Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
return_value = main_function()
File "/usr/sbin/ipa-replica-install", line 663, in main
ds = install_replica_ds(config)
File "/usr/sbin/ipa-replica-install", line 188, in install_replica_ds
ca_file=config.dir + "/ca.crt",
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
360 in create_replica
self.start_creation(runtime=60)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
373, in __setup_replica
r_bindpw=self.dm_password()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 961, in setup_replication
raise RuntimeError("Failed to start replication")
2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Failed to start replication
Any guidance on where to start looking?
--
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New replica won't accept replication
On the new replica (asipa) I see in the access log almost 5000 entries
like this:
[21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT
oid="2.16.840.113730.3.5.6" name="Netscape Replication Total update Entry"
[21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120
nentries=0 etime=0
And these just repeat, increasing the "op" value until they terminate
with this one. The rest of it just looks like informational messages.
Over on zsipa (the CA master), errors contains:
[21/May/2014:14:31:06 +] NSMMReplciationPlugin - Schema
agmt="cn=meToasipa.foo.net" (asipa:389) must not be overwritten(set
replication log for additional info)
[21/May/2014:14:31:06 +] NSMMReplicationPlugin -
agmt="cn=meToasipa.foo.net" (asipa:389) Warning: unable to replicate
schema: rc=1
These two lines repeat at intervals for a while.
Nothing else leapt out at me.
On 05/21/2014 11:04 AM, Rob Crittenden wrote:
Bret Wortman wrote:
This occurs on our first attempt to join as a replica. I've erased this
box and rebaselined it but the same thing happens. No network ports
being blocked that we know of, and another replica I created at the same
time installed its replica file without issue.
asipa is the new replica, zsipa is the ca and original master on which
the replica file was created.
[24/34]: setting up initial replication
Starting replication, please wait until this has completed
Update in progress, 130 seconds elapsed
Update in progress yet not in progress
[ipamaster.foo.net] reports: Update failed! Status: [10 Total update
abortedLDAP error: Referral]
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
#
/var/log/ipareplica-install.log contains this:
2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
url=ldaps://asipa.fopo.net:636 conn=
2014-05-21T14:31:08Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
return_value = main_function()
File "/usr/sbin/ipa-replica-install", line 663, in main
ds = install_replica_ds(config)
File "/usr/sbin/ipa-replica-install", line 188, in install_replica_ds
ca_file=config.dir + "/ca.crt",
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
360 in create_replica
self.start_creation(runtime=60)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
373, in __setup_replica
r_bindpw=self.dm_password()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 961, in setup_replication
raise RuntimeError("Failed to start replication")
2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Failed to start replication
Any guidance on where to start looking?
Check the 389-ds access and error logs on both masters.
rob
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New replica won't accept replication
...but it did at least look like they were talking, right? Some level of
replication was happening:
(before the Netscape Replication Total update Entry began running away
with the logfile):
[21/May/2014:10:28:52 -0400] conn=2 op=2 RESULT err=0 tag=101 nentries=1
etime=0
[21/May/2014:10:28:53 -0400] conn=2 op=3 MOD dn="cn=IPA Version
Replication,cn=Plugins,cn=config"
[21/May/2014:10:28:53 -0400] conn=2 op=3 RESULT err=0 tag=103 nentries=0
etime=0
[21/May/2014:10:28:53 -0400] conn=2 op=4 UNBIND
On 05/21/2014 11:40 AM, Bret Wortman wrote:
On the new replica (asipa) I see in the access log almost 5000 entries
like this:
[21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT
oid="2.16.840.113730.3.5.6" name="Netscape Replication Total update
Entry"
[21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120
nentries=0 etime=0
And these just repeat, increasing the "op" value until they terminate
with this one. The rest of it just looks like informational messages.
Over on zsipa (the CA master), errors contains:
[21/May/2014:14:31:06 +] NSMMReplciationPlugin - Schema
agmt="cn=meToasipa.foo.net" (asipa:389) must not be overwritten(set
replication log for additional info)
[21/May/2014:14:31:06 +] NSMMReplicationPlugin -
agmt="cn=meToasipa.foo.net" (asipa:389) Warning: unable to replicate
schema: rc=1
These two lines repeat at intervals for a while.
Nothing else leapt out at me.
On 05/21/2014 11:04 AM, Rob Crittenden wrote:
Bret Wortman wrote:
This occurs on our first attempt to join as a replica. I've erased this
box and rebaselined it but the same thing happens. No network ports
being blocked that we know of, and another replica I created at the
same
time installed its replica file without issue.
asipa is the new replica, zsipa is the ca and original master on which
the replica file was created.
[24/34]: setting up initial replication
Starting replication, please wait until this has completed
Update in progress, 130 seconds elapsed
Update in progress yet not in progress
[ipamaster.foo.net] reports: Update failed! Status: [10 Total update
abortedLDAP error: Referral]
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
#
/var/log/ipareplica-install.log contains this:
2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
url=ldaps://asipa.fopo.net:636 conn=
2014-05-21T14:31:08Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
return_value = main_function()
File "/usr/sbin/ipa-replica-install", line 663, in main
ds = install_replica_ds(config)
File "/usr/sbin/ipa-replica-install", line 188, in
install_replica_ds
ca_file=config.dir + "/ca.crt",
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line
360 in create_replica
self.start_creation(runtime=60)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line
373, in __setup_replica
r_bindpw=self.dm_password()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 961, in setup_replication
raise RuntimeError("Failed to start replication")
2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Failed to start replication
Any guidance on where to start looking?
Check the 389-ds access and error logs on both masters.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New replica won't accept replication
It takes about 2 minutes. How would you like me to turn debugging on?
Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman
> On May 21, 2014, at 4:26 PM, Rob Crittenden wrote:
>
> Bret Wortman wrote:
>> On the new replica (asipa) I see in the access log almost 5000 entries
>> like this:
>>
>> [21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT
>> oid="2.16.840.113730.3.5.6" name="Netscape Replication Total update Entry"
>> [21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120
>> nentries=0 etime=0
>>
>> And these just repeat, increasing the "op" value until they terminate
>> with this one. The rest of it just looks like informational messages.
>
> How long does this take? Is there time to enable replication debugging?
> That may provide more output.
>
>>
>> Over on zsipa (the CA master), errors contains:
>>
>> [21/May/2014:14:31:06 +] NSMMReplciationPlugin - Schema
>> agmt="cn=meToasipa.foo.net" (asipa:389) must not be overwritten(set
>> replication log for additional info)
>> [21/May/2014:14:31:06 +] NSMMReplicationPlugin -
>> agmt="cn=meToasipa.foo.net" (asipa:389) Warning: unable to replicate
>> schema: rc=1
>
> I don't think this is related.
>
> I'd run ipa-replica-manage list -v `hostname` and ipa-csreplica-manage
> list -v `hostname` on the master you generated the replica install file
> on to see what agreements it has or thinks it has.
>
> rob
>
>>
>> These two lines repeat at intervals for a while.
>>
>> Nothing else leapt out at me.
>>
>>
>>
>>> On 05/21/2014 11:04 AM, Rob Crittenden wrote:
>>> Bret Wortman wrote:
>>>> This occurs on our first attempt to join as a replica. I've erased this
>>>> box and rebaselined it but the same thing happens. No network ports
>>>> being blocked that we know of, and another replica I created at the same
>>>> time installed its replica file without issue.
>>>>
>>>> asipa is the new replica, zsipa is the ca and original master on which
>>>> the replica file was created.
>>>>
>>>> [24/34]: setting up initial replication
>>>> Starting replication, please wait until this has completed
>>>> Update in progress, 130 seconds elapsed
>>>> Update in progress yet not in progress
>>>>
>>>> [ipamaster.foo.net] reports: Update failed! Status: [10 Total update
>>>> abortedLDAP error: Referral]
>>>>
>>>>
>>>> Your system may be partly configured.
>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>
>>>> Failed to start replication
>>>> #
>>>>
>>>> /var/log/ipareplica-install.log contains this:
>>>>
>>>> 2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
>>>> url=ldaps://asipa.fopo.net:636 conn=>>> instance at 0x4faf170>
>>>> 2014-05-21T14:31:08Z DEBUG File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>>>> line 638, in run_script
>>>> return_value = main_function()
>>>>
>>>> File "/usr/sbin/ipa-replica-install", line 663, in main
>>>> ds = install_replica_ds(config)
>>>>
>>>> File "/usr/sbin/ipa-replica-install", line 188, in install_replica_ds
>>>> ca_file=config.dir + "/ca.crt",
>>>>
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
>>>> 360 in create_replica
>>>> self.start_creation(runtime=60)
>>>>
>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>>>> line 364, in start_creation
>>>> method()
>>>>
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
>>>> 373, in __setup_replica
>>>> r_bindpw=self.dm_password()
>>>>
>>>> File
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
>>>> line 961, in setup_replication
>>>> raise RuntimeError("Failed to start replication")
>>>>
>>>> 2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
>>>> exception: RuntimeError: Failed to start replication
>>>>
>>>> Any guidance on where to start looking?
>>> Check the 389-ds access and error logs on both masters.
>>>
>>> rob
>
smime.p7s
Description: S/MIME cryptographic signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] openldap certs?
Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
What we're seeing is slow GDM logins, ssh authentications, and "sudo -i" responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and "sudo -i" responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New replica won't accept replication
Go figure. I rebuilt it (again) cleanly, and after starting replication
again, while I was madly trying to change the debug level on the new
replica...it completed replication this time.
Heisenbugs. Gotta love them. (I think this one was in my network
somewhere, not your code -- I just couldn't observe it enough and
someone must've changed something while I wasn't looking).
Bret
On 05/21/2014 10:19 PM, Rob Crittenden wrote:
Bret Wortman wrote:
It takes about 2 minutes. How would you like me to turn debugging on?
http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
I'm not sure if you should enable this on both sides of the agreement or
not. If you have the ability and don't mind potentially slowing down the
working master it might be useful to the 389-ds guys.
rob
Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman
On May 21, 2014, at 4:26 PM, Rob Crittenden wrote:
Bret Wortman wrote:
On the new replica (asipa) I see in the access log almost 5000 entries
like this:
[21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT
oid="2.16.840.113730.3.5.6" name="Netscape Replication Total update Entry"
[21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120
nentries=0 etime=0
And these just repeat, increasing the "op" value until they terminate
with this one. The rest of it just looks like informational messages.
How long does this take? Is there time to enable replication debugging?
That may provide more output.
Over on zsipa (the CA master), errors contains:
[21/May/2014:14:31:06 +] NSMMReplciationPlugin - Schema
agmt="cn=meToasipa.foo.net" (asipa:389) must not be overwritten(set
replication log for additional info)
[21/May/2014:14:31:06 +] NSMMReplicationPlugin -
agmt="cn=meToasipa.foo.net" (asipa:389) Warning: unable to replicate
schema: rc=1
I don't think this is related.
I'd run ipa-replica-manage list -v `hostname` and ipa-csreplica-manage
list -v `hostname` on the master you generated the replica install file
on to see what agreements it has or thinks it has.
rob
These two lines repeat at intervals for a while.
Nothing else leapt out at me.
On 05/21/2014 11:04 AM, Rob Crittenden wrote:
Bret Wortman wrote:
This occurs on our first attempt to join as a replica. I've erased this
box and rebaselined it but the same thing happens. No network ports
being blocked that we know of, and another replica I created at the same
time installed its replica file without issue.
asipa is the new replica, zsipa is the ca and original master on which
the replica file was created.
[24/34]: setting up initial replication
Starting replication, please wait until this has completed
Update in progress, 130 seconds elapsed
Update in progress yet not in progress
[ipamaster.foo.net] reports: Update failed! Status: [10 Total update
abortedLDAP error: Referral]
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
#
/var/log/ipareplica-install.log contains this:
2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
url=ldaps://asipa.fopo.net:636 conn=
2014-05-21T14:31:08Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
return_value = main_function()
File "/usr/sbin/ipa-replica-install", line 663, in main
ds = install_replica_ds(config)
File "/usr/sbin/ipa-replica-install", line 188, in install_replica_ds
ca_file=config.dir + "/ca.crt",
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
360 in create_replica
self.start_creation(runtime=60)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
373, in __setup_replica
r_bindpw=self.dm_password()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 961, in setup_replication
raise RuntimeError("Failed to start replication")
2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Failed to start replication
Any guidance on where to start looking?
Check the 389-ds access and error logs on both masters.
rob
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
It doesn't seem to have helped -- we're still pretty slow even with IP addresses in sssd.conf. On 05/22/2014 11:07 AM, Dmitri Pal wrote: On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and "sudo -i" responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Why would /etc/passwd get skipped?
If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long "ssh localhost" and trying to rule things out. -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
A. Then it's probably not the source of my performance problem. I know when I shut down SSSD, that user's ssh times speed up incredibly. Bret On 05/22/2014 01:06 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long "ssh localhost" and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
Yep, that initgroups change had the same effect as shutting down sssd, but without inconveniencing all the IPA-only users. The problem in this particular case was made worse by a lot of network latency, but even on network segments local to the ipa masters, it's taking seconds to authenticate. This will help out the local accounts, at least. Now to keep working on those that aren't local. Thanks for that tip, Simo! On 05/22/2014 01:15 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 13:12 -0400, Bret Wortman wrote: A. Then it's probably not the source of my performance problem. I know when I shut down SSSD, that user's ssh times speed up incredibly. This makes me think it *is* initgroups, as it normally will hit sssd even for non-sssd owned users. But the issue here clearly is that sssd is slow for you, bad network ? Simo. Bret On 05/22/2014 01:06 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long "ssh localhost" and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Export user and host list to a csv or text file
Yes, though it might be a bit more data than you're expecting.
Here's what we did to get the details out of a server (and import them
into another). I'm sure there's a more elegant solution, but this worked
for us. Also note that we didn't use all the data this export script
generated, but felt it was better to have it than to not.
EXPORT:
#!/bin/sh
#
# Generate latest ipa config files for possible re-import later.
#
# (C) 2014, The Damascus Group
#
CONFIGDIR=/opt/ipa_config
[ ! -d $CONFIGDIR ] && mkdir $CONFIGDIR
pushd $CONFIGDIR
ipa dnszone-find --all > dnszone.txt
grep 'Zone name' dnszone.txt | awk '{print $3}' | sed 's/\r//' > zones.txt
for line in $(cat zones.txt); do
fn=$(echo $line | sed 's/\.in-addr\.arpa\.//')
echo "For zone $line -> dnsrecord-$fn.txt"
ipa dnsrecord-find $line --sizelimit=9 --all --structured >
dnsrecord-${fn}.txt
done
ipa user-find --all > users.txt
ipa host-find --sizelimit=9 --all > hosts.txt
ipa policy-find --all > policy.txt
ipa sudorule-find --all > sudorule.txt
ipa sudocmdgroup-find --all > sudocmdgroup.txt
ipa sudocmd-find --all > sudocmd.txt
ipa role-find --all > roles.txt
ipa pwpolicy-find --all > pwpolicy.txt
ipa privilege-find --all > privilege.txt
ipa permission-find --all > permission.txt
ipa netgroup-find --all > netgroup.txt
ipa usergroup-find --all > usergroup.txt
ipa idrange-find --all > idrange.txt
ipa hostgroup-find --all > hostgroup.txt
ipahbacrule-find --all > hbacrule.txt
ipa hbacsvc-find --all > hbacsvc.txt
ipa group-find --all > group.txt
ipa cert-find --all > cert.txt
ipa automember-find --type=group --all > automember-group.txt
ipa automember-find --type=hostgroup --all > automember-hostgroup.txt
popd
--cut---
Then, for example, you can import these into a new IPA server using
something like these:
#!/bin/bash
#
# parse_hosts
#
# (C) 2014, The Damascus Group
#
FN=$1
OTP=MyOnetimePassword
RE_HOSTNAME="Host name:\s+(.*)$"
name=""
while read line; do
if [[ $line =~ "$name" ]]; then
if [[ -n "$name" ]]; then
echo "Adding $name"
ipa host-add $name --password $OTP --force
fi
name=${BASH_REMATCH[1]}
fi
done < $FN
echo "Adding $name"
ipa host-add $name --password $OTP --force
---cut--
And this for users:
#!/bin/bash
#
# parse_users
#
# (C) 2014, The Damascus Group
FN=$1
RE_DN="dn:\s+(.*)$"
RE_LOGIN="User login:\s+(.*)$"
RE_LAST="Last name:\s+(.*)$"
RE_FIRST="First name:\s+(.*)$"
RE_CN="Full name:\s+(.*)$"
RE_DISPLAYNAME="Display name:\s+(.*)$"
RE_INITIALS="Initials:\s+(.*)$"
RE_SHELL="Login shell:\s+(.*)$"
RE_HOMEDIR="Home directory:\s+(.*)$"
RE_PRINCIPAL="Kerberos principal:\s+(.*)$"
RE_EMAIL="Email address:\s+(.*)$"
RE_SSHPUBKEY="SSH public key:\s+(.*)$"
RE_UID="UID:\s+(.*)$"
RE_GID="GID:\s+(.*)$"
login=""
last=""
first=""
cn=""
displayname=""
initials=""
shell=""
homedir=""
prinicpal=""
email=""
sshpubkey=""
uid=""
gid=""
while read line; do
if [[ $line =~ $RE_DN ]]; then
ipa user-add $login \
--last=$last \
--first=$first \
--cn="$cn" \
--displayname="$displayname" \
--initials=$initials \
--shell=$shell \
--homedir=$homedir \
--principal=$principal \
--email=$email \
--sshpubkey="$sshpubkey" \
--uid=$uid \
--gid=$gid
login=""
last=""
first=""
cn=""
displayname=""
initials=""
shell=""
homedir=""
prinicpal=""
email=""
sshpubkey=""
uid=""
gid=""
fi
if [[ $line =~ $RE_LOGIN ]]; then
login=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_LAST ]]; then
last=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_FIRST ]]; then
first=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_CN ]]; then
cn=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_DISPLAYNAME ]]; then
displayname=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_INITIALS ]]; then
initials=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_SHELL ]]; then
shell=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_HOMEDIR ]]; then
homedir=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_PRINCIPAL ]]; then
principal=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_EMAIL ]]; then
email=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_SSHPUBKEY ]]; then
sshpubkey1=${BASH_REMATCH[1]}
read sshpubkey2
read sshpubkey3
sshpubkey="$sshpubkey1 $sshpubkey2 $sshpubkey3"
fi
if [[ $line =~ $RE_UID ]]; then
uid=${BASH_REMATCH[1]}
fi
if [[ $line =~ $RE_GID ]]; then
gid=${BASH_REMATCH[1]}
fi
done < $FN
ipa user-add $login \
--last=$last \
--first=$first \
--cn="$cn" \
--displayname="$displayname" \
--initials=$initials \
--shell=$shell \
--homedir=$homedir \
-
Re: [Freeipa-users] Export user and host list to a csv or text file
Is the Python API documented anywhere? I've looked around without success. On 05/23/2014 07:54 AM, Martin Kosek wrote: On 05/23/2014 06:42 AM, Sanju A wrote: Dear All, Is there any command to export the user and host list to a csv or text format There is no such command out of the shelf, I would personally just write a short Python script to export the hosts (or anything else) in a format I need. Example for host: ~ #!/usr/bin/python2 from ipalib import api api.bootstrap(context='exporter', debug=False) api.finalize() api.Backend.xmlclient.connect() hosts = api.Command['host_find']()['result'] for host in hosts: print host['fqdn'][0] ~ This will print one host for each new line. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] LDAP/SSSD/IPA performance
Collecting my various threads together under one big issue and adding this new data point: Our web UI on our slow network is exhibiting some strange behavior as well. When selecting, for example, the "Users", it can take up to 5 seconds to fetch 20 out of our 56 entries. When switching to "Hosts", it took 4 seconds for the footer to show that there would be 47 pages in total, then after 10 seconds total, the page loaded 20 of 939 entries. When I select a host, the previously-selected host will actually be displayed for upwards of 8-10 seconds (while the spinning cursor spins near the word Logout) until the host actually loads. Is it just me, or does this, plus everything else, start to sound like LDAP is struggling? I ran a test using ldapsearch in authenticated and unauthenticated mode from my workstation and here's what I found, which may tell us nothing: # time ldapsearch -x -H -ldap://zsipa.foo.net base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" : real0m2.047s user 0m0.000s sys 0m0.001s # time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" : real0m2.816s user 0m0.004s sys 0m0.002s When I did this locally on the ipa master: # ssh zsipa.foo.net # time ldapsearch -Y GSSAPI base="uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net" : real 0m0.847s user 0m0.007s sys 0m0.006s # -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP/SSSD/IPA performance
More soft/anecdotal: When executing "sudo -i" or "sudo -iu" the first time, we can expect a several second delay before the command completes. If we then exit the session and re-execute the command, it will complete almost instantly. So whatever cache is holding this information, if we could increase its duration, that would certainly make our pain less. Is this a settable value? Entering a password into a screensaver is particularly painful. 10+ seconds before the screensaver will exit. We are looking at environmental possibilities, like interfaces and such. This machine is running on a VMware VM, but we've had success deploying IPA on VMs in the past, and our faster network is running VMs as well (with one physical box). Bret On 05/23/2014 08:15 AM, Bret Wortman wrote: Collecting my various threads together under one big issue and adding this new data point: Our web UI on our slow network is exhibiting some strange behavior as well. When selecting, for example, the "Users", it can take up to 5 seconds to fetch 20 out of our 56 entries. When switching to "Hosts", it took 4 seconds for the footer to show that there would be 47 pages in total, then after 10 seconds total, the page loaded 20 of 939 entries. When I select a host, the previously-selected host will actually be displayed for upwards of 8-10 seconds (while the spinning cursor spins near the word Logout) until the host actually loads. Is it just me, or does this, plus everything else, start to sound like LDAP is struggling? I ran a test using ldapsearch in authenticated and unauthenticated mode from my workstation and here's what I found, which may tell us nothing: # time ldapsearch -x -H -ldap://zsipa.foo.net base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" : real0m2.047s user 0m0.000s sys 0m0.001s # time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" : real0m2.816s user 0m0.004s sys 0m0.002s When I did this locally on the ipa master: # ssh zsipa.foo.net # time ldapsearch -Y GSSAPI base="uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net" : real0m0.847s user 0m0.007s sys 0m0.006s # -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP/SSSD/IPA performance
I assumed. It obviously hasn't helped our sudo situation, but I wouldn't expect it to. I'll let you know how it plays against screensavers and such. On 05/23/2014 10:05 AM, Jakub Hrozek wrote: On Fri, May 23, 2014 at 04:03:44PM +0200, Jakub Hrozek wrote: On Fri, May 23, 2014 at 09:48:00AM -0400, Bret Wortman wrote: More soft/anecdotal: When executing "sudo -i" or "sudo -iu" the first time, we can expect a several second delay before the command completes. If we then exit the session and re-execute the command, it will complete almost instantly. So whatever cache is holding this information, if we could increase its duration, that would certainly make our pain less. Is this a settable value? Entering a password into a screensaver is particularly painful. 10+ seconds before the screensaver will exit. We are looking at environmental possibilities, like interfaces and such. This machine is running on a VMware VM, but we've had success deploying IPA on VMs in the past, and our faster network is running VMs as well (with one physical box). Can you try increasing this option: pam_id_timeout (integer) For any PAM request while SSSD is online, the SSSD will attempt to immediately update the cached identity information for the user in order to ensure that authentication takes place with the latest information. A complete PAM conversation may perform multiple PAM requests, such as account management and session opening. This option controls (on a per-client-application basis) how long (in seconds) we can cache the identity information to avoid excessive round-trips to the identity provider. Default: 5 I should also have explicitly said that the option belongs to the [pam] section. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP/SSSD/IPA performance
All I saw was additional output when I ran the command. On the slower system, there was a one second lag, then a burst of activity, then a one second lag, then completion. I’ll do it again Monday and see what the logs show. On May 23, 2014, at 2:44 PM, Dmitri Pal wrote: > On 05/23/2014 10:03 AM, Bret Wortman wrote: >> >> On 05/23/2014 09:53 AM, Mauricio Tavares wrote: >>> >>> >>> >>> On Fri, May 23, 2014 at 9:48 AM, Bret Wortman >>> wrote: >>> More soft/anecdotal: >>> >>> When executing "sudo -i" or "sudo -iu" the first time, we can expect a >>> several second delay before the command completes. If we then exit the >>> session and re-execute the command, it will complete almost instantly. So >>> whatever cache is holding this information, if we could increase its >>> duration, that would certainly make our pain less. Is this a settable value? >>> >>> Entering a password into a screensaver is particularly painful. 10+ seconds >>> before the screensaver will exit. >>> >>> We are looking at environmental possibilities, like interfaces and such. >>> This machine is running on a VMware VM, but we've had success deploying IPA >>> on VMs in the past, and our faster network is running VMs as well (with one >>> physical box). >>> >>> >>> Bret >>> >>> Did running sudo in debugging mode (SUDOERS_DEBUG 2 in ldap.conf) >>> give you any more clues? >>> >> No. I compared the output on both networks and there's no real difference >> once I accounted for HBAC on one (which produced 2 entries on the slower >> network that got filtered down to 1 user match and 1 host match). But the >> debug output was nearly identical. > > Did you see any gaps in time in the logs that are different? > The flow can be the same but some operations can take longer so there would > be hint to us on what to look for. > >> >>> >>> On 05/23/2014 08:15 AM, Bret Wortman wrote: >>>> Collecting my various threads together under one big issue and adding this >>>> new data point: >>>> >>>> Our web UI on our slow network is exhibiting some strange behavior as well. >>>> >>>> When selecting, for example, the "Users", it can take up to 5 seconds to >>>> fetch 20 out of our 56 entries. >>>> >>>> When switching to "Hosts", it took 4 seconds for the footer to show that >>>> there would be 47 pages in total, then after 10 seconds total, the page >>>> loaded 20 of 939 entries. When I select a host, the previously-selected >>>> host will actually be displayed for upwards of 8-10 seconds (while the >>>> spinning cursor spins near the word Logout) until the host actually loads. >>>> >>>> Is it just me, or does this, plus everything else, start to sound like >>>> LDAP is struggling? >>>> >>>> I ran a test using ldapsearch in authenticated and unauthenticated mode >>>> from my workstation and here's what I found, which may tell us nothing: >>>> >>>> # time ldapsearch -x -H -ldap://zsipa.foo.net >>>> base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" >>>> : >>>> real0m2.047s >>>> user 0m0.000s >>>> sys 0m0.001s >>>> # time ldapsearch -Y GSSAPI -H ldap://zsipa.foo.net >>>> base="uid=bretw,cn=users,cn=accounts,dc=foo,dc=net" >>>> : >>>> real0m2.816s >>>> user 0m0.004s >>>> sys 0m0.002s >>>> >>>> When I did this locally on the ipa master: >>>> >>>> # ssh zsipa.foo.net >>>> # time ldapsearch -Y GSSAPI >>>> base="uid=bretw,cn=uses,cn=accounts,dc=foo,dc=net" >>>> : >>>> real0m0.847s >>>> user 0m0.007s >>>> sys 0m0.006s >>>> # >>>> >>>> >>>> -- >>>> Bret Wortman >>>> >>>> http://damascusgrp.com/ >>>> http://about.me/wortmanbret >>>> >>>> >>>> >>>> ___ >>>> Freeipa-users mailing list >>>> Freeipa-users@redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> ___ >>> Freeipa-users mailing list >>> Freeipa-users@redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> ___ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP/SSSD/IPA performance
Crud. That was supposed to have a second comparison log too: I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net" method=128 version=3 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(cn=deraults)" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 nentries=2 etime=0 [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1 I think this shows, roughly, a 7 second elapsed time from start to finish, right? Granted, there were other request being serficed during this interval as well, but nothing that looked like outrageous volume. On our faster network, this same exchange went much faster: [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from 192.168.2.13 to 192.168.2.61 [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" method=128 version=3 [26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" [26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(cn=defaults)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND [26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1 Bret On 05/26/2014 09:51 AM, Bret Wortman wrote: Okay, I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net" method=128 version=3 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(cn=deraults)" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%su
Re: [Freeipa-users] LDAP/SSSD/IPA performance
I'll get with my network guys and start troubleshooting. Thanks! On 05/27/2014 09:20 AM, Dmitri Pal wrote: On 05/27/2014 08:41 AM, Rob Crittenden wrote: Bret Wortman wrote: Crud. That was supposed to have a second comparison log too: I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net" method=128 version=3 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(cn=deraults)" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 nentries=2 etime=0 [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1 I think this shows, roughly, a 7 second elapsed time from start to finish, right? Granted, there were other request being serficed during this interval as well, but nothing that looked like outrageous volume. I don't see anything unusual here. The directory server retrieved the data just as fast on both systems, the difference appears to be the network, in connection and shutdown times. +1, however the TLS handshake took longer. That probably required several DNS lookups so I wonder if DNS lookups might be slowing things down. I wonder if putting server records manually into the hosts file would make a difference. If yes then may be you need to take a look at your DNS setup for the slow network. On our faster network, this same exchange went much faster: [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from 192.168.2.13 to 192.168.2.61 [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" method=128 version=3 [26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" [26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(cn=defaults)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND [26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1 Bret On 05/26/2014 09:51 AM, Bret Wortman wrote: Okay, I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES
Re: [Freeipa-users] LDAP/SSSD/IPA performance
I just checked to be sure, and we do already put all the IPA servers in our client host tables just to be sure they can be reached even if DNS goes down. On 05/27/2014 09:20 AM, Dmitri Pal wrote: On 05/27/2014 08:41 AM, Rob Crittenden wrote: Bret Wortman wrote: Crud. That was supposed to have a second comparison log too: I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net" method=128 version=3 [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(cn=deraults)" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 nentries=2 etime=0 [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1 I think this shows, roughly, a 7 second elapsed time from start to finish, right? Granted, there were other request being serficed during this interval as well, but nothing that looked like outrageous volume. I don't see anything unusual here. The directory server retrieved the data just as fast on both systems, the difference appears to be the network, in connection and shutdown times. +1, however the TLS handshake took longer. That probably required several DNS lookups so I wonder if DNS lookups might be slowing things down. I wonder if putting server records manually into the hosts file would make a difference. If yes then may be you need to take a look at your DNS setup for the slow network. On our faster network, this same exchange went much faster: [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from 192.168.2.13 to 192.168.2.61 [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" method=128 version=3 [26/May/2014:09:22:56 -0400] conn=12896 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me" [26/May/2014:09:22:56 -0400] conn=12896 op=2 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(cn=defaults)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=3 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(|(sudoUser=bretw)(sudoUser=%bretw)(sudoUser=%#10042)(sudoUser=%admins)(sudoUser=%#38880)(sudoUser=ALL))" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=4 SRCH base="ou=SUDOers,dc=wedgeofli,dc=me" scope=2 filter="(sudoUser=+*)" attrs=ALL [26/May/2014:09:22:56 -0400] conn=12896 op=4 RESULT err=0 tag=101 nentries=0 etime=0 [26/May/2014:09:22:56 -0400] conn=12896 op=5 UNBIND [26/May/2014:09:22:56 -0400] conn=12896 op=5 fd=100 closed - U1 Bret On 05/26/2014 09:51 AM, Bret Wortman wrote: Okay, I found something in the slapd-FOO-NET/access log. I figured out which conn ID related to a sudo -i that I performed which took longer than expected and grepped for that conn ID: [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from 192.168.208.129 to 192.168.10.111 [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=
Re: [Freeipa-users] LDAP/SSSD/IPA performance
No problem. We forced a re installation of openldap, which helped. Pam login is still slow but sudo isn't. We'll keep chipping away at it. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On May 27, 2014, at 7:15 PM, Dmitri Pal wrote: > >> On 05/27/2014 09:44 AM, Bret Wortman wrote: >> I just checked to be sure, and we do already put all the IPA servers in our >> client host tables just to be sure they can be reached even if DNS goes down. > > Sorry, I am running out of ideas. > >> >>> On 05/27/2014 09:20 AM, Dmitri Pal wrote: >>>> On 05/27/2014 08:41 AM, Rob Crittenden wrote: >>>> Bret Wortman wrote: >>>>> Crud. That was supposed to have a second comparison log too: >>>>> >>>>> I found something in the slapd-FOO-NET/access log. I figured out which >>>>> conn ID related to a sudo -i that I performed which took longer than >>>>> expected and grepped for that conn ID: >>>>> >>>>> [26/May/2014:09:08:56 -0400] conn=183751 fd=111 slot=111 connection from >>>>> 192.168.208.129 to 192.168.10.111 >>>>> [26/May/2014:09:08:57 -0400] conn=183751 op=0 EXT >>>>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>>>> [26/May/2014:09:08:57 -0400] conn=183751 op=0 RESULT err=0 tag=120 >>>>> nentries=0 etime=0 >>>>> [26/May/2014:09:08:59 -0400] conn=183751 SSL 128-bit AES >>>>> [26/May/2014:09:08:59 -0400] conn=183751 op=1 BIND >>>>> dn="uid=sudo,cn=sysaccounts,cn=etc,dc=foo,dc=net" method=128 version=3 >>>>> [26/May/2014:09:08:59 -0400] conn=183751 op=1 RESULT err=0 tag=97 >>>>> nentries=0 etime=0 >>>>> [26/May/2014:09:09:00 -0400] conn=183751 op=2 SRCH >>>>> base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(cn=deraults)" attrs=ALL >>>>> [26/May/2014:09:09:00 -0400] conn=183751 op=2 RESULT err=0 tag=101 >>>>> nentries=0 etime=0 >>>>> [26/May/2014:09:09:00 -0400] conn=183751 op=3 SRCH >>>>> base="ou=SUDOers,dc=foo,dc=net" scope=2 >>>>> filter="(|(sudoUser=bretw)(sudoUser=%users)(sudoUser=%#100)(sudoUser=%admins)(sudoUser=%nonexp)(sudoUser=%sudoers)(sudoUser=$unrestricted)(sudoUser=%#185520)(sudoUser=%#1855204) >>>>> >>>>> (sudoUser=%#185526)(sudoUser=%#185527)(sudoUser=ALL))" attrs=ALL >>>>> [26/May/2014:09:09:00 -0400] conn=183751 op=3 RESULT erro=0 tag=101 >>>>> nentries=2 etime=0 >>>>> [26/May/2014:09:09:01 -0400] conn=183751 op=4 SRCH >>>>> base="ou=SUDOers,dc=foo,dc=net" scope=2 filter="(sudoUser=+*)" attrs=ALL >>>>> [26/May/2014:09:09:01 -0400] conn=183751op=4 RESULT err=0 tag=101 >>>>> nentries=0 etime=0 >>>>> [26/May/2014:09:09:03 -0400] conn=183751 op=5 UNBIND >>>>> [26/May/2014:09:09:03 -0400] conn=183751 op=5 fd=111 closed = U1 >>>>> >>>>> I think this shows, roughly, a 7 second elapsed time from start to >>>>> finish, right? Granted, there were other request being serficed during >>>>> this interval as well, but nothing that looked like outrageous volume. >>>> I don't see anything unusual here. The directory server retrieved the >>>> data just as fast on both systems, the difference appears to be the >>>> network, in connection and shutdown times. >>> +1, however the TLS handshake took longer. That probably required several >>> DNS lookups so I wonder if DNS lookups might be slowing things down. >>> I wonder if putting server records manually into the hosts file would make >>> a difference. If yes then may be you need to take a look at your DNS setup >>> for the slow network. >>> >>> >>>>> On our faster network, this same exchange went much faster: >>>>> >>>>> [26/May/2014:09:22:55 -0400] conn=12896 fd=100 slot=100 connection from >>>>> 192.168.2.13 to 192.168.2.61 >>>>> [26/May/2014:09:22:55 -0400] conn=12896 op=0 EXT >>>>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>>>> [26/May/2014:09:22:55 -0400] conn=12896 op=0 RESULT err=0 tag=120 >>>>> nentries=0 etime=0 >>>>> [26/May/2014:09:22:56 -0400] conn=12896 SSL 128-bit AES >>>>> [26/May/2014:09:22:56 -0400] conn=12896 op=1 BIND >>>>> dn="u
Re: [Freeipa-users] LDAP/SSSD/IPA performance
The CD is in the hands of the security folks now. I'll let you know when I have it and can transfer the logs over to you. It's only 2GB worth of data, but I hope it's informative. Bret On 05/28/2014 03:52 AM, Jakub Hrozek wrote: On Tue, May 27, 2014 at 07:34:58PM -0400, Bret Wortman wrote: No problem. We forced a re installation of openldap, which helped. Pam login is still slow but sudo isn't. We'll keep chipping away at it. As said earlier in the thread, logs might be the best way to move this forward. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] GSSAPIAuthentication setting in /etc/sshd_config?
Does this really need to be set to "yes" in /etc/sshd_config? I've looked through the documentation and it only seems to say this for HP-UX and AIX. We're running freeipa 3.3.5-1 and are seeing some slow logins via ssh that some users have reported speed up markedly when this setting is toggled to "no". Before I make any wholesale change recommendations, I wanted to check on this. Thanks! -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature -- 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] DNS not responding properly....
d, dn 'idnsname=_kerberos._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kerberos-master._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kerberos-master._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kpasswd._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kpasswd._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=_ntp._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=ipa-ca,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=ipa2,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=mcnetmon,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.320 update_record (syncrepl) failed, dn 'idnsname=asterisk,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.320 zone 252.168.192.in-addr.arpa/IN: loaded serial 1409933087 05-Sep-2014 12:04:47.320 1 zones from LDAP instance 'ipa' loaded (1 zones defined) -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature -- 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] DNS not responding properly....
Check. [root@ipa1 data]# ipa dnszone-show foo.net Zone name: foo.net Authoritative nameserver: ipa1.foo.net. Administrator e-mail address: hostmaster.foo.net. SOA serial: 1400521450 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone forwarders: 8.8.8.8 [root@ipa1 data]# On 09/05/2014 01:56 PM, Petr Spacek wrote: Hello, On 5.9.2014 18:14, Bret Wortman wrote: I've got an odd situation with one of our networks. Our systems are properly registered in DNS within IPA, and the web interface and IPA queries work to resolve the hosts, but named isn't playing along with us. [root@ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk Record name: asterisk A record: 192.168.252.155 Number of entries returned 1 [root@ipa1 data]# host asterisk.foo.net Host asterisk.foo.net not found: 3(NXDOMAIN) [root@ipa1 data]# cat /etc/resolv.conf search foo.net nameserver 192.168.252.61<- This is ipa1 nameserver 192.168.252.62 nameserver 192.168.252.63 [root@ipa1 data]# ifconfig ens192: flags=4163 mtu 1500 inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20 ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) RX packets 2189 bytes 332143 (324.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1523 bytes 428925 (418.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 1037 bytes 718872 (702.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1037 bytes 718872 (702.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ipa1 data]# When I dig into the named.run file, I see the trace below (I ran an "rndc reload" after seeing the request to do so at the end of an earlier section of the file; it obviously didn't help much). I'm not sure where else to look. /etc/named.conf and /var/named/named.ca both are in line with what we have on another similar system where everything is working just fine. Any thoughts? Please double check output from $ ipa dnszone-show foo.net It should contain line like: Active zone: TRUE Petr^2 Spacek 05-Sep-2014 12:04:47.111 received control channel command 'reload' 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADD
Re: [Freeipa-users] Howto re-deploy an IPA-client using kickstart
It works like a champ for me. -- Bret Wortman http://bretwortman.com/ http://twitter.com/bretwortman On Thursday, January 24, 2013 at 6:53 PM, Dmitri Pal wrote: > On 01/24/2013 11:34 AM, Matthew Barr wrote: > > Just reading this over, and the RFE, I've got another possible option. > > > > Our standard build uses a key tab of a user with permission to add a host, > > and that sets the OTP for the kickstart to use. > > > > Is it possible to reset the state of the host record to the state where it > > can use the same install command on an existing host record? Basically, set > > the OTP again? > > > > If i could run a single command to reset the state to allow the OTP to work > > it would work fairly well.. > > > > for example: ipa host-mod wiki01.ayisnap.com --password=foo > > Yes you can set it again. This is how we envisioned the feature to be used. > If it does not work it is a bug. > > > > > > > Background: > > > > We've got IPA & puppet. I have to purge the IPA host record & the puppet > > SSL keys, in order to regenerate them both. Satellite/Spacewalk allows for > > a rebuild command, but I'm not sure what Katello & foreman will do in the > > future. > > > > > > > > > > Matthew Barr > > Technical Architect > > E: mb...@snap-interactive.com > > AIM: matthewbarr1 > > c: (646) 727-0535 > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > --- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: : Could not connect to LDAP server host oldmaster.my.com port 7389 Error netscape.ldap.LDAPException: failed to connect to server ldap:// oldmaster.my.com:7389 (91) Feb 19, 2013 11:46:50 AM org.apache.catalina.startup.Catalina stopServer SEVERE: Catalina.stop: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) : : This certainly appears to be a problem, but everyone's authenticating against oldmaster just fine. Thoughts, anyone? * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 11:07 AM, Bret Wortman wrote: > Does anyone have an idea why I can't connect, or why this service isn't > running on my freeipa instance? It used to be, because I've created a > replica in the past > > > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 9:08 AM, John Dennis wrote: > >> On 02/19/2013 06:58 AM, Bret Wortman wrote: >> >>> I have a server running freeipa and I want to migrate it to a new host. >>> I had thought that the easiest way might be to create a replica and load >>> that onto the new host, but this is proving problematic: >>> >>> # ipa-replica-prepare ipamaster.my.com <http://ipamaster.my.com> >>> >>> --ip-address 10.0.0.46 >>> Directory Manager (existing master) password: >>> >>> Preparing replica for ipamaster.my.com <http://ipamaster.my.com> from >>> oldmaster.my.com <http://oldmaster.my.com> >>> >>> Creating SSL certificate for the Directory Server >>> preparation of replica failed: cannot connect to >>> 'https://oldmaster.my.com:**9444/ca/ee/ca/**profileSubmitSSLClient<https://oldmaster.my.com:9444/ca/ee/ca/profileSubmitSSLClient>': >>> [Errno >>> -5985] Cannot resolve oldmaster.my.com <http://oldmaster.my.com> using >>> >>> family PR_AF_INET6 >>> >>> And then a stack trace follows. >>> >>> # netstat -rn | grep 9444 >>> # lsof -i:9444 >>> # >>> _ >>> _ >>> I've also tried connecting to that URL via Firefox without success. It's >>> just not listening there. What do I need to check? Someone else is >>> running some apps (redmine and others) using Passenger on that server as >>> well; could it be obscuring the port somehow? >>> >>> We're not running IPV6, so I'm not sure why it's being referenced >>> >> >> I can't comment on why you can't connect but I can explain the error >> message. It's an internal mistake, if we can't connect we try another >> address family, that logic is incorrect and I thought we had fixed in this >> ticket >> https://fedorahosted.org/**freeipa/ticket/2695<https://fedorahosted.org/freeipa/ticket/2695>, >> but apparently we didn't. Anyway the error message is a red herring, your >> connection problems lie elsewhere. >> >> -- >> John Dennis >> >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
No, can't telnet to 7389 or 9444 either one: [root@ipamaster]# telnet oldmaster.my.com 7389 Trying 10.0.0.42... telnet: connect to address 10.0.0.42: COnnection refused [root@ipamaster]# I do note that I only have packages called dogtag-*-theme installed: [root@oldmaster]# yum list "*dogtag*" Loaded plugins: lnagpacks, presto, refresh-packagekit Installed Packages dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 @fedora dogtag-pki-common-theme.noarch 9.0.11-1.fc17 @fedora Available Packages dogtag-pki.noarch 9.0.0-13.fc17 @fedora : I also noticed that, according to /var/log/pki-ca/catalina.out and /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, I'm not sure what happened on that day to change things, but I'm trying to find out. (At least, I assume this logdir relates to dogtag) * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > >> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >> > <mailto:bret.wortman@**damascusgrp.com>> >> wrote: >> >> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >> >> : >> Could not connect to LDAP server host oldmaster.my.com >> <http://oldmaster.my.com> port 7389 Error >> >> netscape.ldap.LDAPException: failed to connect to server >> ldap://oldmaster.my.com:7389 <http://oldmaster.my.com:7389> (91) >> >> >> This certainly appears to be a problem, but everyone's >> authenticating against oldmaster just fine. Thoughts, anyone? >> >> >> can you connect to that port (7389) on oldmaster.my.com >> <http://oldmaster.my.com> from the other replica? (try telnetting to the >> port: telnet oldmaster.my.com <http://oldmaster.my.com> 7389) >> > > 7389 is port in the 389-ds instance used by dogtag. Is the instance > running on oldmaster? > > It isn't used for authentication which is why you aren't seeing problems > with clients. > > rob > > __**_ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Digging further into my logs this morning, I've discovered that there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 either. How can I tell why this isn't running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged to, it's just the PKI piece that seems to be dead. Nothing in /etc/pki-ca has changed since last year, and the last updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on Feb 5. I just can't tell what that change was Would a key change or certificate change have affected this? Worst case, if I do something like this: # ipa-server-install -U --uninstall # ipa-server-install will I lose the hosts, policies & users I already have configured? Does this stand a chance of getting me back up to where I can clone this box and get healthy again? * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 2:01 PM, Bret Wortman wrote: > No, can't telnet to 7389 or 9444 either one: > > [root@ipamaster]# telnet oldmaster.my.com 7389 > Trying 10.0.0.42... > telnet: connect to address 10.0.0.42: COnnection refused > [root@ipamaster]# > > I do note that I only have packages called dogtag-*-theme installed: > > [root@oldmaster]# yum list "*dogtag*" > Loaded plugins: lnagpacks, presto, refresh-packagekit > Installed Packages > dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 > @fedora > dogtag-pki-common-theme.noarch 9.0.11-1.fc17 > @fedora > Available Packages > dogtag-pki.noarch 9.0.0-13.fc17 > @fedora > : > > I also noticed that, according to /var/log/pki-ca/catalina.out and > /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, > I'm not sure what happened on that day to change things, but I'm trying to > find out. (At least, I assume this logdir relates to dogtag) > > > > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: > >> Natxo Asenjo wrote: >> >>> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >>> >> <mailto:bret.wortman@**damascusgrp.com>> >>> wrote: >>> >>> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >>> >>> : >>> Could not connect to LDAP server host oldmaster.my.com >>> <http://oldmaster.my.com> port 7389 Error >>> >>> netscape.ldap.LDAPException: failed to connect to server >>> ldap://oldmaster.my.com:7389 <http://oldmaster.my.com:7389> (91) >>> >>> >>> This certainly appears to be a problem, but everyone's >>> authenticating against oldmaster just fine. Thoughts, anyone? >>> >>> >>> can you connect to that port (7389) on oldmaster.my.com >>> <http://oldmaster.my.com> from the other replica? (try telnetting to the >>> port: telnet oldmaster.my.com <http://oldmaster.my.com> 7389) >>> >> >> 7389 is port in the 389-ds instance used by dogtag. Is the instance >> running on oldmaster? >> >> It isn't used for authentication which is why you aren't seeing problems >> with clients. >> >> rob >> >> __**_ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >> > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
And just in case this is informative: [root@oldmaster]# pkicontrol start ca PKI-IPA PKI-IPA is an invalid 'pki-ca' instance [root@oldmaster]# * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 8:08 AM, Bret Wortman wrote: > Digging further into my logs this morning, I've discovered that there's no > new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 either. How can I > tell why this isn't running? /var/log/dirsrv/slapd-MY-COM is getting > updated and logged to, it's just the PKI piece that seems to be dead. > > Nothing in /etc/pki-ca has changed since last year, and the last updates > to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on Feb 5. I just > can't tell what that change was > > Would a key change or certificate change have affected this? > > Worst case, if I do something like this: > > # ipa-server-install -U --uninstall > # ipa-server-install > > will I lose the hosts, policies & users I already have configured? Does > this stand a chance of getting me back up to where I can clone this box and > get healthy again? > > > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 2:01 PM, Bret Wortman < > bret.wort...@damascusgrp.com> wrote: > >> No, can't telnet to 7389 or 9444 either one: >> >> [root@ipamaster]# telnet oldmaster.my.com 7389 >> Trying 10.0.0.42... >> telnet: connect to address 10.0.0.42: COnnection refused >> [root@ipamaster]# >> >> I do note that I only have packages called dogtag-*-theme installed: >> >> [root@oldmaster]# yum list "*dogtag*" >> Loaded plugins: lnagpacks, presto, refresh-packagekit >> Installed Packages >> dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 >> @fedora >> dogtag-pki-common-theme.noarch 9.0.11-1.fc17 >> @fedora >> Available Packages >> dogtag-pki.noarch 9.0.0-13.fc17 >> @fedora >> : >> >> I also noticed that, according to /var/log/pki-ca/catalina.out and >> /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, >> I'm not sure what happened on that day to change things, but I'm trying to >> find out. (At least, I assume this logdir relates to dogtag) >> >> >> >> * >> * >> *Bret Wortman* >> <http://damascusgrp.com/> >> http://damascusgrp.com/ <http://bretwortman.com/> >> http://twitter.com/BretWortman >> >> >> On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: >> >>> Natxo Asenjo wrote: >>> >>>> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >>>> >>> <mailto:bret.wortman@**damascusgrp.com>> >>>> wrote: >>>> >>>> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >>>> >>>> : >>>> Could not connect to LDAP server host oldmaster.my.com >>>> <http://oldmaster.my.com> port 7389 Error >>>> >>>> netscape.ldap.LDAPException: failed to connect to server >>>> ldap://oldmaster.my.com:7389 <http://oldmaster.my.com:7389> (91) >>>> >>>> >>>> This certainly appears to be a problem, but everyone's >>>> authenticating against oldmaster just fine. Thoughts, anyone? >>>> >>>> >>>> can you connect to that port (7389) on oldmaster.my.com >>>> <http://oldmaster.my.com> from the other replica? (try telnetting to >>>> the >>>> port: telnet oldmaster.my.com <http://oldmaster.my.com> 7389) >>>> >>> >>> 7389 is port in the 389-ds instance used by dogtag. Is the instance >>> running on oldmaster? >>> >>> It isn't used for authentication which is why you aren't seeing problems >>> with clients. >>> >>> rob >>> >>> __**_ >>> Freeipa-users mailing list >>> Freeipa-users@redhat.com >>> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >>> >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: > On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: > > Digging further into my logs this morning, I've discovered that > > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 > > either. How can I tell why this isn't > > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged > > to, it's just the PKI piece that seems to be dead. > > > > > > Nothing in /etc/pki-ca has changed since last year, and the last > > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on > > Feb 5. I just can't tell what that change was > > What error do you get if you try to start it ? > [root@oldmaster]# pkicontrol start ca PKI-IPA PKI-IPA is an invalid 'pki-ca' instance [root@oldmaster]# Is there another, preferred way to start it? > > > > Would a key change or certificate change have affected this? > > An expired CA cert might cause the server to stop, but then you would > see expired certs all over and also the main IPA instance would not > start. > > > > Worst case, if I do something like this: > > > > > > # ipa-server-install -U --uninstall > > # ipa-server-install > > > You will completely obliterate all your data. > > > will I lose the hosts, policies & users I already have configured? > > Does this stand a chance of getting me back up to where I can clone > > this box and get healthy again? > > > Healthy will be, but with no data, don't do it. (and I suggest you make > a full backup just in case) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
I think this keeps coming back to the fact that ldap isn't listening on 7389 for some reason. When I try to *really* manually start pki-ca like this, it complains about ldap before dying: # sudo -u pkiuser -s /usr/lib/jvm/jre/bin/java -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki-ca -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/var/lib/pki-ca/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start : : Could not connect to LDAP server host oldmaster.my.com port 7389 Error netscape.ldap.LDAPException: failed to connect to server ldap:// oldmaster.my.com:7389 (91) [root@oldmaster]# This bears out what I see in /var/log/pki-ca/catalina.out too. * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 8:43 AM, Bret Wortman wrote: > On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: > >> On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: >> > Digging further into my logs this morning, I've discovered that >> > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 >> > either. How can I tell why this isn't >> > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged >> > to, it's just the PKI piece that seems to be dead. >> > >> > >> > Nothing in /etc/pki-ca has changed since last year, and the last >> > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on >> > Feb 5. I just can't tell what that change was >> >> What error do you get if you try to start it ? >> > > [root@oldmaster]# pkicontrol start ca PKI-IPA > PKI-IPA is an invalid 'pki-ca' instance > [root@oldmaster]# > > Is there another, preferred way to start it? > > > >> > >> > Would a key change or certificate change have affected this? >> >> An expired CA cert might cause the server to stop, but then you would >> see expired certs all over and also the main IPA instance would not >> start. >> > >> > Worst case, if I do something like this: >> > >> > >> > # ipa-server-install -U --uninstall >> > # ipa-server-install >> > >> You will completely obliterate all your data. >> >> > will I lose the hosts, policies & users I already have configured? >> > Does this stand a chance of getting me back up to where I can clone >> > this box and get healthy again? >> > >> Healthy will be, but with no data, don't do it. (and I suggest you make >> a full backup just in case) >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Eureka! Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now everything's working as expected. Thanks everyone for your contributions, patience, and indulgence. And for a wonderful product! * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:34 AM, Bret Wortman wrote: > I think this keeps coming back to the fact that ldap isn't listening on > 7389 for some reason. When I try to *really* manually start pki-ca like > this, it complains about ldap before dying: > > # sudo -u pkiuser -s /usr/lib/jvm/jre/bin/java -classpath > :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar > -Dcatalina.base=/var/lib/pki-ca -Dcatalina.home=/usr/share/tomcat6 > -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp > -Djava.util.logging.config.file=/var/lib/pki-ca/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > org.apache.catalina.startup.Bootstrap start > : > : > Could not connect to LDAP server host oldmaster.my.com port 7389 Error > netscape.ldap.LDAPException: failed to connect to server ldap:// > oldmaster.my.com:7389 (91) > [root@oldmaster]# > > This bears out what I see in /var/log/pki-ca/catalina.out too. > > > > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > > > On Wed, Feb 20, 2013 at 8:43 AM, Bret Wortman < > bret.wort...@damascusgrp.com> wrote: > >> On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: >> >>> On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: >>> > Digging further into my logs this morning, I've discovered that >>> > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 >>> > either. How can I tell why this isn't >>> > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged >>> > to, it's just the PKI piece that seems to be dead. >>> > >>> > >>> > Nothing in /etc/pki-ca has changed since last year, and the last >>> > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on >>> > Feb 5. I just can't tell what that change was >>> >>> What error do you get if you try to start it ? >>> >> >> [root@oldmaster]# pkicontrol start ca PKI-IPA >> PKI-IPA is an invalid 'pki-ca' instance >> [root@oldmaster]# >> >> Is there another, preferred way to start it? >> >> >> >>> > >>> > Would a key change or certificate change have affected this? >>> >>> An expired CA cert might cause the server to stop, but then you would >>> see expired certs all over and also the main IPA instance would not >>> start. >>> > >>> > Worst case, if I do something like this: >>> > >>> > >>> > # ipa-server-install -U --uninstall >>> > # ipa-server-install >>> > >>> You will completely obliterate all your data. >>> >>> > will I lose the hosts, policies & users I already have configured? >>> > Does this stand a chance of getting me back up to where I can clone >>> > this box and get healthy again? >>> > >>> Healthy will be, but with no data, don't do it. (and I suggest you make >>> a full backup just in case) >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
I'm running 2.2.0-1.fc17.x86_64 And FWIW, the replica data file I was able to create after this just installed successfully on the new host. * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:47 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Eureka! >> >> Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.**ldif. >> I replaced it from a saved copy and now everything's working as expected. >> >> Thanks everyone for your contributions, patience, and indulgence. And >> for a wonderful product! >> > > Glad you're up and running again. > > I'm curious, what version are you running? > > rob > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Mine was not. — Bret Wortman On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: > On 02/20/2013 06:00 PM, KodaK wrote: >> >> >> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman >> mailto:bret.wort...@damascusgrp.com>> >> wrote: >> >> Eureka! >> >> Someone had deleted the contents of >> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved >> copy and now everything's working as expected. >> >> Thanks everyone for your contributions, patience, and indulgence. >> And for a wonderful product! >> >> >> I wouldn't be too sure that someone deleted it. A couple of weeks ago >> I had a crash and half of my replicas had an empty dse.ldif. I think >> you and I may be hitting a bug. > were these virtual machines? >> >> --Jason >> >> >> ___ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Rich, 389-ds-base-1.2.11.5-1.fc17.x86_64. The box is a DL360G8. * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:03 PM, Rich Megginson wrote: > On 02/20/2013 06:43 PM, Bret Wortman wrote: > > Mine was not. > > What platform? What version of 389-ds-base? > > > — > Bret Wortman > > > On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: > >> On 02/20/2013 06:00 PM, KodaK wrote: >> >> >> >> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman < >> bret.wort...@damascusgrp.com> wrote: >> >>> Eureka! >>> >>> Someone had deleted the contents of >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now >>> everything's working as expected. >>> >>> Thanks everyone for your contributions, patience, and indulgence. And >>> for a wonderful product! >>> >>> >> I wouldn't be too sure that someone deleted it. A couple of weeks ago >> I had a crash and half of my replicas had an empty dse.ldif. I think you >> and I may be hitting a bug. >> >> >> were these virtual machines? >> >> >> --Jason >> >> >> ___ >> Freeipa-users mailing >> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
Thanks for the bug link. We let the developer we thought had messed things up out of the 4x4 cell we had stashed him in. He's still blinking from sunlight but the doctors tell us the facial twitching will stop in a month or two. * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Thu, Feb 21, 2013 at 10:54 AM, Rich Megginson wrote: > On 02/21/2013 07:11 AM, Bret Wortman wrote: > > Rich, > > 389-ds-base-1.2.11.5-1.fc17.x86_64. > > The box is a DL360G8. > > https://fedorahosted.org/389/ticket/518 > > > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > > > On Wed, Feb 20, 2013 at 9:03 PM, Rich Megginson wrote: > >> On 02/20/2013 06:43 PM, Bret Wortman wrote: >> >> Mine was not. >> >> What platform? What version of 389-ds-base? >> >> >> — >> Bret Wortman >> >> >> On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: >> >>> On 02/20/2013 06:00 PM, KodaK wrote: >>> >>> >>> >>> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman < >>> bret.wort...@damascusgrp.com> wrote: >>> >>>> Eureka! >>>> >>>> Someone had deleted the contents of >>>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now >>>> everything's working as expected. >>>> >>>> Thanks everyone for your contributions, patience, and indulgence. And >>>> for a wonderful product! >>>> >>>> >>> I wouldn't be too sure that someone deleted it. A couple of weeks ago >>> I had a crash and half of my replicas had an empty dse.ldif. I think you >>> and I may be hitting a bug. >>> >>> >>> were these virtual machines? >>> >>> >>> --Jason >>> >>> >>> ___ >>> Freeipa-users mailing >>> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> >> > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica installation failing
I'm now rebuilding on F17 and Martin's going to try my scenario, which should have worked. Who knows, I may have borked it somehow. — Bret Wortman On Tue, Mar 19, 2013 at 10:19 AM, Bret Wortman wrote: > Generation difference. Wrong version of the software -- the F18 version > apparently can't read the data generated by my F17 server. And backing it > down appears to be nontrivial. Upgrading the master to F18 is a nonstarter > as F18 isn't exactly stable in our environment. I guess I'm going to > rebuild this box on F17 and try again. > I'm kind of surprised that there isn't better backward compatibility here; > is it hard to maintain the ability to read the old formats, or are packages > you depend on changing too quickly? I'm not trying to be critical or start > a flame war here, just to understand. :-) > * > * > *Bret Wortman* > <http://damascusgrp.com/> > http://damascusgrp.com/ <http://bretwortman.com/> > http://twitter.com/BretWortman > On Tue, Mar 19, 2013 at 8:48 AM, Martin Kosek wrote: >> Ok. This looks like dirsrv errors from the master machine. Are there also >> any >> interesting errors on the replica machine? >> >> Martin >> >> On 03/19/2013 01:45 PM, Bret Wortman wrote: >> > Yes, it's still resolvable. >> > >> > In the errors log: >> > >> > [19/Mar/2013:08:39:53 -0400] slapi_ldap_bind - Error: could not send >> startTLS >> > request: error -1 (Can't contact LDAP server) errno 107 (Transport >> endpoint is >> > not connected) >> > [19/Mar/2013:08:39:53 -0400] NSMMReploicationPlugin - >> > agmt="cn=meTojsipa.damascusgrp.com <http://meTojsipa.damascusgrp.com>" >> > (jsipa:389) : Replication bind with SIMPLE auth failed: LDAP error -1 >> (Can't >> > contact LDAQP server) ((null)) >> > >> > and then the first error repeats every few seconds for a while. >> > >> > jsipa.damascusgrp.com <http://jsipa.damascusgrp.com> is resolvable on >> > ipamaster.damascusgrp.com <http://ipamaster.damascusgrp.com>. >> > >> > I _have_ noticed that when doing the ipa-server-install --uninstall to >> clean up >> > after this, that some ports (389, 636) don't get released unless I >> reboot. I >> > don't know if that's related or a red herring. >> > >> > >> > _ >> > _ >> > *Bret Wortman* >> > <http://damascusgrp.com/> >> > http://damascusgrp.com/ <http://bretwortman.com/> >> > http://twitter.com/BretWortman >> > >> > >> > On Tue, Mar 19, 2013 at 8:30 AM, Martin Kosek > > <mailto:mko...@redhat.com>> wrote: >> > >> > On 03/19/2013 01:12 PM, Bret Wortman wrote: >> > > Preparation of the replica data file went without a hitch, but on >> > installation: >> > > >> > > # ipa-replica-install --setup-dns --no-forwarders >> > > replica-info-jsipa.damascusgrp.com >> > <http://replica-info-jsipa.damascusgrp.com> >> > <http://replica-info-jsipa.damascusgrp.com> >> > > --skip-conncheck >> > > Directory Manager (existing master) password: >> > > >> > > Configuring NTP daemon (ntpd) >> > > : >> > > Configuring directory server (dirsrv): Estimated time 1 minute >> > > : >> > > : >> > > [21/30]: setting up initial replication >> > > Starting replication, please wait until this has completed. >> > > [ipamaster.damascusgrp.com <http://ipamaster.damascusgrp.com> >> > <http://ipamaster.damascusgrp.com>] reports: Update >> > > failed! Status: [-1 - LDAP error: Can't contact LDAP server] >> > > : >> > > # getenforce >> > > Disabled >> > > # systemctl status iptables.service >> > > iptables.service >> > > Loaded: error (Reason: No such file or directory) >> > > Active: inactive(dead) >> > > >> > > # >> > > >> > > Any ideas? This is a brand-new server just set up via kickstart. >> It's running >> > > Fedora 18 and IPA 3.1.0-2.fc18. >> > > >> > > _ >> > > _ >> > > *Bret Wortman* >> > > <http://damascusgrp.com/> >> > > http://damascusgrp.com/ <http://bretwortman.com/> >> > > http://twitter.com/BretWortman >> > > >> > >> > Hello Bret, >> > >> > Is ipamaster.damascusgrp.com <http://ipamaster.damascusgrp.com> >> still >> > resolvable from the replica machine? I would >> > try running: >> > >> > # host ipamaster.damascusgrp.com <http://ipamaster.damascusgrp.com> >> > >> > ... after the failed ipa-replica-install. There were issues in the >> past when >> > /etc/resolv.conf changed during replica installation and caused >> similar error >> > in a middle of ipa-replica-install. >> > >> > If the DNS resolution is OK, I would also check >> > /var/log/dirsvr/slapd-INST/errors on replica and on master - are >> there any >> > relevant errors? >> > >> > Martin >> > >> > >> >>___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica installation failing
I had already blown away the new replica and reinstalled it as F17, but I did so using the exact same replica file and it installed perfectly, without a hitch this time. It even passed the checks that had required me to use --skip-conncheck when installing on F18. I'll try it again in the near future on another VM and get back to you. * * *Bret Wortman* <http://damascusgrp.com/> http://damascusgrp.com/ <http://bretwortman.com/> http://twitter.com/BretWortman On Tue, Mar 19, 2013 at 12:31 PM, Martin Kosek wrote: > I tried this scenario and it worked for me. I installed a FreeIPA master > on F17 > machine (freeipa-server-2.2.2-1.fc17.x86_64), created a replica info file > for > fedora 18 machine and run ipa-replica-install on this one > (freeipa-server-3.1.2-1.fc18.x86_64) and the installation was successful. > > If you still have the development environment, can you please: > 1) Try to make sure you have up-to-date freeipa on f17 and f18, then > 2) Create a new replica info file for the replica, copy it on a replica > 3) Install the replica > > If it fails again, we will need to investigate 389-ds-base logs on both > server > and replica machines to see if that helps us see the root cause. > > Martin > > On 03/19/2013 03:42 PM, Bret Wortman wrote: > > I'm now rebuilding on F17 and Martin's going to try my scenario, which > should > > have worked. Who knows, I may have borked it somehow. > > > > — > > Bret Wortman > > > > > > On Tue, Mar 19, 2013 at 10:19 AM, Bret Wortman < > bret.wort...@damascusgrp.com > > <mailto:bret.wort...@damascusgrp.com>> wrote: > > > > Generation difference. Wrong version of the software -- the F18 > version > > apparently can't read the data generated by my F17 server. And > backing it > > down appears to be nontrivial. Upgrading the master to F18 is a > nonstarter > > as F18 isn't exactly stable in our environment. I guess I'm going to > > rebuild this box on F17 and try again. > > > > I'm kind of surprised that there isn't better backward compatibility > here; > > is it hard to maintain the ability to read the old formats, or are > packages > > you depend on changing too quickly? I'm not trying to be critical or > start > > a flame war here, just to understand. :-) > > > > > > _ > > _ > > *Bret Wortman* > > <http://damascusgrp.com/> > > http://damascusgrp.com/ <http://bretwortman.com/> > > http://twitter.com/BretWortman > > > > > > On Tue, Mar 19, 2013 at 8:48 AM, Martin Kosek > <mailto:mko...@redhat.com>> wrote: > > > > Ok. This looks like dirsrv errors from the master machine. Are > there > > also any > > interesting errors on the replica machine? > > > > Martin > > > > On 03/19/2013 01:45 PM, Bret Wortman wrote: > > > Yes, it's still resolvable. > > > > > > In the errors log: > > > > > > [19/Mar/2013:08:39:53 -0400] slapi_ldap_bind - Error: could > not send > > startTLS > > > request: error -1 (Can't contact LDAP server) errno 107 > (Transport > > endpoint is > > > not connected) > > > [19/Mar/2013:08:39:53 -0400] NSMMReploicationPlugin - > > > agmt="cn=meTojsipa.damascusgrp.com < > http://meTojsipa.damascusgrp.com> > > <http://meTojsipa.damascusgrp.com>" > > > (jsipa:389) : Replication bind with SIMPLE auth failed: LDAP > error -1 > > (Can't > > > contact LDAQP server) ((null)) > > > > > > and then the first error repeats every few seconds for a while. > > > > > > jsipa.damascusgrp.com <http://jsipa.damascusgrp.com> > > <http://jsipa.damascusgrp.com> is resolvable on > > > ipamaster.damascusgrp.com <http://ipamaster.damascusgrp.com> > > <http://ipamaster.damascusgrp.com>. > > > > > > I _have_ noticed that when doing the ipa-server-install > --uninstall > > to clean up > > > after this, that some ports (389, 636) don't get released > unless I > > reboot. I > > > don't know if that's related or a red herring. > > > > > > > > > _ > > > _ > &g
[Freeipa-users] Can't update ssh keys
Any time I try to use the command-line utilities to add a host (this includes ipa-client-install): #ipa host-mod host.damascusgrp.com<http://bl-1.com/click/load/U2IPPgRiUmdQNVY7ATI-b0231>--updatedns --sshpubkey="`cat /etc/ssh/ssh_host_rsa_key.pub`" ipa: ERROR: invliad 'sshpubkey': must be binary data I know I can use the GUI, but as we could be rolling out a large number of systems in coming months, that's not a good long-term option. So does anyone know a way to make the CLI tools work? Second question: is there a way to update the SSHFP records apart from using the CLI tools as above? Thanks! * * *Bret Wortman* http://damascusgrp.com/<http://bl-1.com/click/load/UGEKOwRiVGFQNQBtADA-b0231> http://about.me/wortmanbret<http://bl-1.com/click/load/ADFbalA2W25VMAZrVWQ-b0231> ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't update ssh keys
V3.1.something. I'm not at the office again till Monday. On Fri, Aug 9, 2013 at 1:22 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> Any time I try to use the command-line utilities to add a host (this >> includes ipa-client-install): >> >> #ipa host-mod host.damascusgrp.com >> <http://bl-1.com/click/load/U2IPPgRiUmdQNVY7ATI-b0231> --updatedns >> --sshpubkey="`cat /etc/ssh/ssh_host_rsa_key.pub`" >> ipa: ERROR: invliad 'sshpubkey': must be binary data >> >> I know I can use the GUI, but as we could be rolling out a large number >> of systems in coming months, that's not a good long-term option. So does >> anyone know a way to make the CLI tools work? >> >> Second question: is there a way to update the SSHFP records apart from >> using the CLI tools as above? > A pub key consists of 3 pieces of data: the key type, the key and a comment. > What version of IPA? IIRC in v2 only the key material itself was > supported. This cli command should work with a v3 server which requires > all 3 pieces. > I imagine you could use dnsrecord-mod/add to manage the SSHFP record but > that could lead to different values in the DNS and host entry if not > done carefully. > rob___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't update ssh keys
I can get the host keys in okay, it's the user keys that are giving me
fits. No combination of fields seems to work. Before we troubleshoot very
far, I will update to a newer release and try again. Every now and again, I
just need the right motivation to upgrade.
*
*
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
On Mon, Aug 12, 2013 at 11:10 AM, Rob Crittenden wrote:
> Bret Wortman wrote:
>
>> Rob,
>>
>> I'm running 2.2.1. Sorry about that, I got confused by my Cobbler
>> version on a different server. I guess we're looking at an upgrade!
>>
>
> For 2.x you might try:
>
> # ipa host-mod host.example.com --sshpubkey=`awk '{ print $2 '}
> /etc/ssh/ssh_host_rsa_key.pub`
>
> I'm not 100% sure that the pub key format is space-delimited so YMMV, but
> I think this is right.
>
> rob
>
>
>>
>> _
>> _
>> *Bret Wortman*
>>
>>
>> http://damascusgrp.com/
>> http://about.me/wortmanbret
>>
>>
>> On Fri, Aug 9, 2013 at 1:22 PM, Rob Crittenden > <mailto:rcrit...@redhat.com>> wrote:
>>
>> Bret Wortman wrote:
>>
>> Any time I try to use the command-line utilities to add a host
>> (this
>> includes ipa-client-install):
>>
>> #ipa host-mod host.damascusgrp.com <http://host.damascusgrp.com>
>>
>> <http://bl-1.com/click/load/__**U2IPPgRiUmdQNVY7ATI-b0231<http://bl-1.com/click/load/__U2IPPgRiUmdQNVY7ATI-b0231>
>>
>> <http://bl-1.com/click/load/**U2IPPgRiUmdQNVY7ATI-b0231<http://bl-1.com/click/load/U2IPPgRiUmdQNVY7ATI-b0231>>>
>> --updatedns
>>
>> --sshpubkey="`cat /etc/ssh/ssh_host_rsa_key.pub`**__"
>>
>> ipa: ERROR: invliad 'sshpubkey': must be binary data
>>
>> I know I can use the GUI, but as we could be rolling out a large
>> number
>> of systems in coming months, that's not a good long-term option.
>> So does
>> anyone know a way to make the CLI tools work?
>>
>> Second question: is there a way to update the SSHFP records
>> apart from
>> using the CLI tools as above?
>>
>>
>> A pub key consists of 3 pieces of data: the key type, the key and a
>> comment.
>>
>> What version of IPA? IIRC in v2 only the key material itself was
>> supported. This cli command should work with a v3 server which
>> requires all 3 pieces.
>>
>> I imagine you could use dnsrecord-mod/add to manage the SSHFP record
>> but that could lead to different values in the DNS and host entry if
>> not done carefully.
>>
>> rob
>>
>>
>>
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrade failed -- how to recover?
I just upgraded my IPA master from F17 to F18 and, in the process, updated IPA to 3.1.5-1. Apparently, though, all is not well, because there are a number of errors in /var/log/ipaupgrade.log<http://bl-1.com/click/load/BzZcbVU2VmpTOwFsCD4-b0231>, mostly related to things like (samples here; the server is on a private network so I'm having to transcribe, if it looks like a typo, it probably is): ERROR Cannot connect to LDAP to add DNS records: cannot connect to u'ldapi://%2fvar%2run%2fslapd-FOO-NET.socket': LDAP Server Down ERROR certmonger failed to start tracking certificate: Command '/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca -c dogtag-ipa-retrieve-agent-submit -B /usr/lib64/ipa/certmonger/stop_pkicad -C /usr/lib64/ipa/certmonger/restart_pkicad "auditSigningCert cert-pki-ca" -P -T auditSigningCert cert-pki-ca' returned non-zero exit status 1 and numerous certmonger errors similar to this one. Finally, there's a stacktrace from ipapython/admintool.py<http://bl-1.com/click/load/BzYIOV0-b0221AT1QOFc6BjE-b0231>, line 171 which ends the whole thing. What's my best plan for re-attempting this upgrade? * * *Bret Wortman* http://damascusgrp.com/<http://bl-1.com/click/load/VWQAMVQ3UGxVPQBtADQ-b0231> http://about.me/wortmanbret<http://bl-1.com/click/load/XWwMPV0-b0221UW0CagZrBjM-b0231> ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade failed -- how to recover?
I tried this, but no joy: # /usr/sbin/ipa-upgradeconfig --debug : : DEBUG: caSignedLogCert.cfg<http://bl-1.com/click/load/VWRaa1w-b0221U28CYQNlAT4-b0231>profile validity range is 720 INFO: [Certificate renewal should stop the CA] ERROR: Unable to find certmonger request ID for auditSigning Cert INFO: The ipa-upgradeconfig command was successful # But I still can't connect to http://ipamaster/ipa/ui/; I get a 903 error every time, and /var/log/httpd/error_log shows, in part: [Tue Aug 13 13:07:20.786566 2013] [:error] [pid 5890] KeyError: 'ipadnszone' [Tue Aug 13 13:07:20.786717 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net: json_metadata(None, None, object=u'all'): KeyError [Tue Aug 13 13:07:21.001525 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net: json_metadata(None, None, command=u'all'): SUCCESS DNS resolution, authentication and authorization all *appear* to be working fine. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Aug 13, 2013 at 10:29 AM, Bret Wortman wrote: > I just upgraded my IPA master from F17 to F18 and, in the process, updated > IPA to 3.1.5-1. Apparently, though, all is not well, because there are a > number of errors in > /var/log/ipaupgrade.log<http://bl-1.com/click/load/BzZcbVU2VmpTOwFsCD4-b0231>, > mostly related to things like (samples here; the server is on a private > network so I'm having to transcribe, if it looks like a typo, it probably > is): > > ERROR Cannot connect to LDAP to add DNS records: cannot connect to > u'ldapi://%2fvar%2run%2fslapd-FOO-NET.socket': LDAP Server Down > > ERROR certmonger failed to start tracking certificate: Command > '/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n > auditSigningCert cert-pki-ca -c dogtag-ipa-retrieve-agent-submit -B > /usr/lib64/ipa/certmonger/stop_pkicad -C > /usr/lib64/ipa/certmonger/restart_pkicad "auditSigningCert cert-pki-ca" -P > -T auditSigningCert cert-pki-ca' returned non-zero exit status 1 > > and numerous certmonger errors similar to this one. Finally, there's a > stacktrace from > ipapython/admintool.py<http://bl-1.com/click/load/BzYIOV0-b0221AT1QOFc6BjE-b0231>, > line 171 which ends the whole thing. > > What's my best plan for re-attempting this upgrade? > > * > * > *Bret Wortman* > > http://damascusgrp.com/<http://bl-1.com/click/load/VWQAMVQ3UGxVPQBtADQ-b0231> > http://about.me/wortmanbret<http://bl-1.com/click/load/XWwMPV0-b0221UW0CagZrBjM-b0231> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade failed -- how to recover?
Rob, I got past this, as you indicated, by doing that after first running: # ipa-ldap-updater --ldapi ./schema.update Using a schema.update tip file I found in a note from you after some hard core googling. Should that extra step have been necessary? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Aug 13, 2013 at 3:39 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> I tried this, but no joy: >> >> # /usr/sbin/ipa-upgradeconfig --debug >> : >> : >> DEBUG: caSignedLogCert.cfg >> <http://bl-1.com/click/load/**VWRaa1w-b0221U28CYQNlAT4-b0231<http://bl-1.com/click/load/VWRaa1w-b0221U28CYQNlAT4-b0231> >> **> profile >> >> validity range is 720 >> INFO: [Certificate renewal should stop the CA] >> ERROR: Unable to find certmonger request ID for auditSigning Cert >> INFO: The ipa-upgradeconfig command was successful >> # >> > > Run getcert list and sift through the output and see if you have a request > tracking for nickname auditSigningCert cert-pki-ca (or similar). > > But I still can't connect to http://ipamaster/ipa/ui/; I get a 903 error >> every time, and /var/log/httpd/error_log shows, in part: >> >> [Tue Aug 13 13:07:20.786566 2013] [:error] [pid 5890] KeyError: >> 'ipadnszone' >> [Tue Aug 13 13:07:20.786717 2013] [:error] [pid 5890] ipa: INFO: >> br...@foo.net <mailto:br...@foo.net>: json_metadata(None, None, >> >> object=u'all'): KeyError >> [Tue Aug 13 13:07:21.001525 2013] [:error] [pid 5890] ipa: INFO: >> br...@foo.net <mailto:br...@foo.net>: json_metadata(None, None, >> command=u'all'): SUCCESS >> >> DNS resolution, authentication and authorization all /appear/ to be >> working fine. >> > > The DNS schema was not updated properly. I'd run: > > # ipa-ldap-updater --upgrade > > rob > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade failed -- how to recover?
I believe you. I'm not upset at all that things go sideways every now and again. I'm surprised it doesn't happen more. Original failure (or, at least, first occurrence of "ERROR") follows: 2013-08-13T13:56:07Z INFO [Setting up Firefox extension] 2013-08-13T13:56:07Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2013-08-13T13:56:07Z INFO /usr/share/ipa/html/krb.js<http://bl-1.com/click/load/U2ILOlY2ADdTO1A9BDQ-b0231>exists, skipping install of Firefox extension 2013-08-13T13:56:07Z INFO [Add missing CA DNS records] 2013-08-13T13:56:07Z ERROR Cannot connect to LDAP to add DNS records: cannot connect to u'ldapi://%2fvar%2frun%2fslapd-SPX-NET.socket': LDAP Server Down 2013-08-13T13:56:07Z INFO [Enabling persistent search in DNS] 2013-08-13T13:56:07Z DEBUG [Saving StateFile to '/var/lib/ipa/sysupgrade/sysupgrade.state' 2013-08-13T13:56:07Z DEBUG Persistent search enabled 2013-08-13T13:56:07Z DEBUG Connections set to 4 Then it goes on for a while, leading to: 2013-08-13T13:56:11Z DEBUG Process finished, return code=1 2013-08-13T13:56:11Z DEBUG stdout=Error connecting to DBus. Please verify that the message bus (D-Bus) service is running. 2013-08-13T13:56:11Z DEBUG stderr= 2013-08-13T13:56:11Z ERROR cretmonger failed to start tracking certificate: Command '/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca -c dogtag-ipa-retrieve-agent-submit -B /usr/lib64/ipa/certmonger/stop_pkicad -C /usr/lib64/ipa/certmonger/restart_pkicad "auditSigningCert cert-pki-ca" -P -T auditSigningCert cert-pki-ca' returned non-zero exit status 1 2013-08-13T13:56:11Z DEBUG Starting external process 2013-08-13T13:56:11Z DEBUG args=/usr/bin/certutil -L -d/var/lib/pki-ca/alias -n ocspSigningCert cert-pki-ca 2013-08-13T13:56:11Z DEBUG Process finished, return code=0 Does that help at all? Do you need more? I'm upgrading a slave today and will try just doing the --upgrade (_if_ the automatic upgrade has issues again). * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 14, 2013 at 9:10 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Rob, I got past this, as you indicated, by doing that after first running: >> >> # ipa-ldap-updater --ldapi ./schema.update >> >> Using a schema.update tip file I found in a note from you after some >> hard core googling. Should that extra step have been necessary? >> > > No, it shouldn't be necessary. Can look in /var/log/ipaupgrade.log (likely > humongous) for the original failure and post that section of the log? > > Updating schema is hard. We are actually completely revamping the way we > handle schema changes between version which should be a lot more stable. > > rob > > >> >> _ >> _ >> *Bret Wortman* >> >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Tue, Aug 13, 2013 at 3:39 PM, Rob Crittenden > <mailto:rcrit...@redhat.com>> wrote: >> >> Bret Wortman wrote: >> >> I tried this, but no joy: >> >> # /usr/sbin/ipa-upgradeconfig --debug >> : >> : >> DEBUG: caSignedLogCert.cfg >> >> <http://bl-1.com/click/load/__**VWRaa1w-b0221U28CYQNlAT4-b0231<http://bl-1.com/click/load/__VWRaa1w-b0221U28CYQNlAT4-b0231> >> >> <http://bl-1.com/click/load/**VWRaa1w-b0221U28CYQNlAT4-b0231<http://bl-1.com/click/load/VWRaa1w-b0221U28CYQNlAT4-b0231> >> **>__> >> >> profile >> >> validity range is 720 >> INFO: [Certificate renewal should stop the CA] >> ERROR: Unable to find certmonger request ID for auditSigning Cert >> INFO: The ipa-upgradeconfig command was successful >> # >> >> >> Run getcert list and sift through the output and see if you have a >> request tracking for nickname auditSigningCert cert-pki-ca (or >> similar). >> >> But I still can't connect to http://ipamaster/ipa/ui/; I get a >> 903 error >> every time, and /var/log/httpd/error_log shows, in part: >> >> [Tue Aug 13 13:07:20.786566 2013] [:error] [pid 5890] KeyError: >> 'ipadnszone' >> [Tue Aug 13 13:07:20.786717 2013] [:error] [pid 5890] ipa: INFO: >> br...@foo.net <mailto:br...@foo.net> <mailto:br...@foo.net >> >> <mailto:br...@foo.net>>: json_metadata(None, None, >> >> object=u'all'): KeyError >> [Tue Aug 13 13:07:21.001525 2013] [:error] [pid 5890] ipa: INFO: >> br...@foo.net <mailto:br...@foo.net> <mailto:br...@foo.net >> >> <mailto:br...@foo.net>>: json_metadata(None, None, >> command=u'all'): SUCCESS >> >> DNS resolution, authentication and authorization all /appear/ to >> be >> working fine. >> >> >> The DNS schema was not updated properly. I'd run: >> >> # ipa-ldap-updater --upgrade >> >> rob >> >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Replication woes
My replication situation has gotten a bit messed up. I have four replicas that are up and running and two that I'm trying to delete (one is not a replica any more, one didn't upgrade well during its fedup upgrade from F17->F18 and as such I had to do a clean OS install). # ipa-replica-manage list bad1.foo.net <http://bl-1.com/click/load/VGVbaVI2BjtTO1ExAjY-b0231>: master bad2.foo.net <http://bl-1.com/click/load/ADEOPARgATxfN1Q0BjM-b0231>: master good1.foo.net: master good2.foo.net: master good3.foo.net: master good4.foo.net: master # ipa-replica-manage list ipamaster.foo.net<http://bl-1.com/click/load/BDUBM1I2UWxfN1c3V2U-b0231> good1.foo.net: replica good2.foo.net: replica good3.foo.net: replica good4.foo.net: replica # ipa-replica-manage del --force bad1.foo.net 'ipamaster.foo.net' has no replication agreement for 'bad1.foo.net' # ipa-replica-manage del --force bad2.foo.net 'ipamaster.foo.net' has no replication agreement for 'bad2.foo.net' # * * What I need to do is remove bad1 completely and then remove bad2 and re-add it as a replica. Any ideas? * * *Bret Wortman* http://damascusgrp.com/<http://bl-1.com/click/load/U2JdbwdjBThROQZmAzA-b0231> http://about.me/wortmanbret<http://bl-1.com/click/load/ATBZa1QwVmsHbwNjVWU-b0231> ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
The software is actually gone from both boxes -- one is dead and the other was reinstalled when the upgrade failed. So I can't get at the database for either one. Safe to just --cleanup in that case? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 10:26 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> My replication situation has gotten a bit messed up. >> >> I have four replicas that are up and running and two that I'm trying to >> delete (one is not a replica any more, one didn't upgrade well during >> its fedup upgrade from F17->F18 and as such I had to do a clean OS >> install). >> >> # ipa-replica-manage list >> bad1.foo.net: master >> bad2.foo.net: master >> good1.foo.net <http://good1.foo.net>: master >> good2.foo.net <http://good2.foo.net>: master >> good3.foo.net <http://good3.foo.net>: master >> good4.foo.net <http://good4.foo.net>: master >> # ipa-replica-manage list ipamaster.foo.net >> good1.foo.net <http://good1.foo.net>: replica >> good2.foo.net <http://good2.foo.net>: replica >> good3.foo.net <http://good3.foo.net>: replica >> good4.foo.net <http://good4.foo.net>: replica >> # ipa-replica-manage del --force bad1.foo.net <http://bad1.foo.net> >> 'ipamaster.foo.net <http://ipamaster.foo.net>' has no replication >> agreement for 'bad1.foo.net <http://bad1.foo.net>' >> # ipa-replica-manage del --force bad2.foo.net <http://bad2.foo.net> >> 'ipamaster.foo.net <http://ipamaster.foo.net>' has no replication >> agreement for 'bad2.foo.net <http://bad2.foo.net>' >> # >> >> _ >> _ >> What I need to do is remove bad1 completely and then remove bad2 and >> re-add it as a replica. Any ideas? >> > > I guess I'd start on bad1 and see what replication agreements it thinks it > has. It is worth it to double-check on all the good hosts too, just to be > sure that nobody has an agreement. > > Assuming it has no agreements, add the --cleanup flag to the del command. > This will prompt you to erase the replica as a master. We have lots of > warnings because this can be a pretty dangerous command. > > Once removed you can safely uninstall the replica and re-install if you'd > like. > > rob > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
Not according to my poll of the good ones, so here goes. Thanks, Rob. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 10:35 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> The software is actually gone from both boxes -- one is dead and the >> other was reinstalled when the upgrade failed. So I can't get at the >> database for either one. Safe to just --cleanup in that case? >> >> > Assuming that none of the good servers have an agreement with bad* then > yes, safe to use. > > rob > > >> _ >> _ >> *Bret Wortman* >> >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Mon, Aug 19, 2013 at 10:26 AM, Rob Crittenden > <mailto:rcrit...@redhat.com>> wrote: >> >> Bret Wortman wrote: >> >> My replication situation has gotten a bit messed up. >> >> I have four replicas that are up and running and two that I'm >> trying to >> delete (one is not a replica any more, one didn't upgrade well >> during >> its fedup upgrade from F17->F18 and as such I had to do a clean >> OS install). >> >> # ipa-replica-manage list >> bad1.foo.net <http://bad1.foo.net>: master >> bad2.foo.net <http://bad2.foo.net>: master >> good1.foo.net <http://good1.foo.net> <http://good1.foo.net>: >> master >> good2.foo.net <http://good2.foo.net> <http://good2.foo.net>: >> master >> good3.foo.net <http://good3.foo.net> <http://good3.foo.net>: >> master >> good4.foo.net <http://good4.foo.net> <http://good4.foo.net>: >> master >> # ipa-replica-manage list ipamaster.foo.net >> <http://ipamaster.foo.net> >> good1.foo.net <http://good1.foo.net> <http://good1.foo.net>: >> replica >> good2.foo.net <http://good2.foo.net> <http://good2.foo.net>: >> replica >> good3.foo.net <http://good3.foo.net> <http://good3.foo.net>: >> replica >> good4.foo.net <http://good4.foo.net> <http://good4.foo.net>: >> replica >> >> # ipa-replica-manage del --force bad1.foo.net >> <http://bad1.foo.net> <http://bad1.foo.net> >> >> 'ipamaster.foo.net <http://ipamaster.foo.net> >> <http://ipamaster.foo.net>' has no replication >> agreement for 'bad1.foo.net <http://bad1.foo.net> >> <http://bad1.foo.net>' >> # ipa-replica-manage del --force bad2.foo.net >> <http://bad2.foo.net> <http://bad2.foo.net> >> >> 'ipamaster.foo.net <http://ipamaster.foo.net> >> <http://ipamaster.foo.net>' has no replication >> agreement for 'bad2.foo.net <http://bad2.foo.net> >> <http://bad2.foo.net>' >> # >> >> _ >> _ >> What I need to do is remove bad1 completely and then remove bad2 >> and >> re-add it as a replica. Any ideas? >> >> >> I guess I'd start on bad1 and see what replication agreements it >> thinks it has. It is worth it to double-check on all the good hosts >> too, just to be sure that nobody has an agreement. >> >> Assuming it has no agreements, add the --cleanup flag to the del >> command. This will prompt you to erase the replica as a master. We >> have lots of warnings because this can be a pretty dangerous command. >> >> Once removed you can safely uninstall the replica and re-install if >> you'd like. >> >> rob >> >> >> >> >> __**_ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
How can I tell if this is working? It's been 10 minutes and it hasn't returned; IPA response is sluggish and top doesn't show anything obviously running & sucking up CPU. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 10:16 AM, Bret Wortman wrote: > My replication situation has gotten a bit messed up. > > I have four replicas that are up and running and two that I'm trying to > delete (one is not a replica any more, one didn't upgrade well during its > fedup upgrade from F17->F18 and as such I had to do a clean OS install). > > # ipa-replica-manage list > bad1.foo.net <http://bl-1.com/click/load/VGVbaVI2BjtTO1ExAjY-b0231>: > master > bad2.foo.net <http://bl-1.com/click/load/ADEOPARgATxfN1Q0BjM-b0231>: > master > good1.foo.net: master > good2.foo.net: master > good3.foo.net: master > good4.foo.net: master > # ipa-replica-manage list > ipamaster.foo.net<http://bl-1.com/click/load/BDUBM1I2UWxfN1c3V2U-b0231> > good1.foo.net: replica > good2.foo.net: replica > good3.foo.net: replica > good4.foo.net: replica > # ipa-replica-manage del --force bad1.foo.net > 'ipamaster.foo.net' has no replication agreement for 'bad1.foo.net' > # ipa-replica-manage del --force bad2.foo.net > 'ipamaster.foo.net' has no replication agreement for 'bad2.foo.net' > # > * > * > What I need to do is remove bad1 completely and then remove bad2 and > re-add it as a replica. Any ideas? > > * > * > *Bret Wortman* > > http://damascusgrp.com/<http://bl-1.com/click/load/U2JdbwdjBThROQZmAzA-b0231> > http://about.me/wortmanbret<http://bl-1.com/click/load/ATBZa1QwVmsHbwNjVWU-b0231> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
Well, my master ground to a halt and wasn't responding. I rebooted the system and now I can't access the web UI or ssh to the master either. I have console access but that's it. The services all say they're running, but the web UI gives an "Unknown Error" dialog and ssh fails with "ssh_exchange_identification: Connection closed by remote host" whenever I try to ssh to ipamaster. I think something has gone really wrong inside my master. Any ideas? Even after the reboot, --cleanup isn't helping and just hangs. The logfiles end (as of the time I ^C'd the process) with: NSMMReplicationPlugin - agmt="cn=meTogood3.spx.net" (good3:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)) NSMMReplicationPlugin - CleanAllRUV Task: Replica not online (agmt="cn= meTogood3.foo.net" (good3:389)) NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, retrying in 160 seconds..., So it looks like it's having trouble talking with one of my replicas and is doggedly trying to get the job done. Any idea how to get the master back working again while I troubleshoot this connectivity issue? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 11:11 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> How can I tell if this is working? It's been 10 minutes and it hasn't >> returned; IPA response is sluggish and top doesn't show anything >> obviously running & sucking up CPU. >> > > It should be nearly instantaneous. It doesn't actually do a lot. It > deletes the master from cn=masters, removes its entries from S4U2proxy > delegation and in newer versions attempts to save its DNA configuration, if > any. > > It should be safe to break out of it and re-run it. You may want to check > the 389-ds logs to see what it has already done. > > rob > > >> >> _ >> _ >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Mon, Aug 19, 2013 at 10:16 AM, Bret Wortman >> > <mailto:bret.wortman@**damascusgrp.com>> >> wrote: >> >> My replication situation has gotten a bit messed up. >> >> I have four replicas that are up and running and two that I'm trying >> to delete (one is not a replica any more, one didn't upgrade well >> during its fedup upgrade from F17->F18 and as such I had to do a >> clean OS install). >> >> # ipa-replica-manage list >> bad1.foo.net >> <http://bl-1.com/click/load/**VGVbaVI2BjtTO1ExAjY-b0231<http://bl-1.com/click/load/VGVbaVI2BjtTO1ExAjY-b0231> >> >: >> master >> bad2.foo.net >> <http://bl-1.com/click/load/**ADEOPARgATxfN1Q0BjM-b0231<http://bl-1.com/click/load/ADEOPARgATxfN1Q0BjM-b0231> >> >: >> master >> good1.foo.net <http://good1.foo.net>: master >> good2.foo.net <http://good2.foo.net>: master >> good3.foo.net <http://good3.foo.net>: master >> good4.foo.net <http://good4.foo.net>: master >> # ipa-replica-manage list ipamaster.foo.net >> >> <http://bl-1.com/click/load/**BDUBM1I2UWxfN1c3V2U-b0231<http://bl-1.com/click/load/BDUBM1I2UWxfN1c3V2U-b0231> >> > >> good1.foo.net <http://good1.foo.net>: replica >> good2.foo.net <http://good2.foo.net>: replica >> good3.foo.net <http://good3.foo.net>: replica >> good4.foo.net <http://good4.foo.net>: replica >> # ipa-replica-manage del --force bad1.foo.net <http://bad1.foo.net> >> 'ipamaster.foo.net <http://ipamaster.foo.net>' has no replication >> agreement for 'bad1.foo.net <http://bad1.foo.net>' >> # ipa-replica-manage del --force bad2.foo.net <http://bad2.foo.net> >> 'ipamaster.foo.net <http://ipamaster.foo.net>' has no replication >> agreement for 'bad2.foo.net <http://bad2.foo.net>' >> # >> _ >> _ >> >> What I need to do is remove bad1 completely and then remove bad2 and >> re-add it as a replica. Any ideas? >> >> _ >> _ >> *Bret Wortman* >> >> http://damascusgrp.com/ >> >> <http://bl-1.com/click/load/**U2JdbwdjBThROQZmAzA-b0231<http://bl-1.com/click/load/U2JdbwdjBThROQZmAzA-b0231> >> > >> http://about.me/wortmanbret >> >> <http://bl-1.com/click/load/**ATBZa1QwVmsHbwNjVWU-b0231<http://bl-1.com/click/load/ATBZa1QwVmsHbwNjVWU-b0231> >> > >> >> >> >> >> >> __**_ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
Digging further, I think this log entry might be the problem between the two servers that aren't talking: slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id[] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/localh...@spx.net not found in Kerberos database)) errno 2 (No such file or directory) Did I build something incorrectly when that server was set up originally? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 12:02 PM, Bret Wortman wrote: > I ran it on a good master, against a bad one. As in, I ran this command on > my master IPA node: > > # ipa-replica-manage del --force bad1.foo.net --cleanup > > Was that wrong? I was trying to delete the bad replica from the master, so > I figured the command needed to be run on the master. But again, my master > is now in a state where it's not resolving DNS, user logins, or sudo at the > very least. > > Oh, and I checked the node that it was complaining about earlier. The > network connection to it is the pits, but it's there. And it resolves. > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Mon, Aug 19, 2013 at 11:58 AM, Rob Crittenden wrote: > >> Rob Crittenden wrote: >> >>> Bret Wortman wrote: >>> >>>> Well, my master ground to a halt and wasn't responding. I rebooted the >>>> system and now I can't access the web UI or ssh to the master either. I >>>> have console access but that's it. >>>> >>>> The services all say they're running, but the web UI gives an "Unknown >>>> Error" dialog and ssh fails with "ssh_exchange_identification: >>>> Connection closed by remote host" whenever I try to ssh to ipamaster. I >>>> think something has gone really wrong inside my master. Any ideas? Even >>>> after the reboot, --cleanup isn't helping and just hangs. >>>> >>>> The logfiles end (as of the time I ^C'd the process) with: >>>> >>>> NSMMReplicationPlugin - agmt="cn=meTogood3.spx.net >>>> <http://meTogood3.spx.net>" (good3:389): Replication bind with GSSAPI >>>> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >>>> information (Cannot determine realm for numeric host address)) >>>> NSMMReplicationPlugin - CleanAllRUV Task: Replica not online >>>> (agmt="cn=meTogood3.foo.net <http://meTogood3.foo.net>" (good3:389)) >>>> NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, >>>> retrying in 160 seconds..., >>>> >>>> So it looks like it's having trouble talking with one of my replicas and >>>> is doggedly trying to get the job done. Any idea how to get the master >>>> back working again while I troubleshoot this connectivity issue? >>>> >>> >>> That suggests a DNS problem, and it might explain ssh as well depending >>> on your configuration. >>> >> >> To be clear, you ran --cleanup against one of the bad masters, not a good >> one, right? >> >> rob >> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
...and I got the web UI, authentication and sudo back via: # ipactl stop # ipactl start Not sure why that worked, but it did. I was grasping at straws, honestly. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 12:18 PM, Bret Wortman wrote: > Digging further, I think this log entry might be the problem between the > two servers that aren't talking: > > slapd_ldap_sasl_interactive_bind - Error: could not perform interactive > bind for id[] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic > failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more > information (Server ldap/localh...@spx.net not found in Kerberos > database)) errno 2 (No such file or directory) > > Did I build something incorrectly when that server was set up originally? > > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Mon, Aug 19, 2013 at 12:02 PM, Bret Wortman < > bret.wort...@damascusgrp.com> wrote: > >> I ran it on a good master, against a bad one. As in, I ran this command >> on my master IPA node: >> >> # ipa-replica-manage del --force bad1.foo.net --cleanup >> >> Was that wrong? I was trying to delete the bad replica from the master, >> so I figured the command needed to be run on the master. But again, my >> master is now in a state where it's not resolving DNS, user logins, or sudo >> at the very least. >> >> Oh, and I checked the node that it was complaining about earlier. The >> network connection to it is the pits, but it's there. And it resolves. >> >> >> * >> * >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Mon, Aug 19, 2013 at 11:58 AM, Rob Crittenden wrote: >> >>> Rob Crittenden wrote: >>> >>>> Bret Wortman wrote: >>>> >>>>> Well, my master ground to a halt and wasn't responding. I rebooted the >>>>> system and now I can't access the web UI or ssh to the master either. I >>>>> have console access but that's it. >>>>> >>>>> The services all say they're running, but the web UI gives an "Unknown >>>>> Error" dialog and ssh fails with "ssh_exchange_identification: >>>>> Connection closed by remote host" whenever I try to ssh to ipamaster. I >>>>> think something has gone really wrong inside my master. Any ideas? Even >>>>> after the reboot, --cleanup isn't helping and just hangs. >>>>> >>>>> The logfiles end (as of the time I ^C'd the process) with: >>>>> >>>>> NSMMReplicationPlugin - agmt="cn=meTogood3.spx.net >>>>> <http://meTogood3.spx.net>" (good3:389): Replication bind with GSSAPI >>>>> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>>> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >>>>> information (Cannot determine realm for numeric host address)) >>>>> NSMMReplicationPlugin - CleanAllRUV Task: Replica not online >>>>> (agmt="cn=meTogood3.foo.net <http://meTogood3.foo.net>" (good3:389)) >>>>> NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, >>>>> retrying in 160 seconds..., >>>>> >>>>> So it looks like it's having trouble talking with one of my replicas >>>>> and >>>>> is doggedly trying to get the job done. Any idea how to get the master >>>>> back working again while I troubleshoot this connectivity issue? >>>>> >>>> >>>> That suggests a DNS problem, and it might explain ssh as well depending >>>> on your configuration. >>>> >>> >>> To be clear, you ran --cleanup against one of the bad masters, not a >>> good one, right? >>> >>> rob >>> >>> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication woes
So, any idea how to fix the Kerberos problem? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 12:19 PM, Bret Wortman wrote: > ...and I got the web UI, authentication and sudo back via: > > # ipactl stop > # ipactl start > > Not sure why that worked, but it did. I was grasping at straws, honestly. > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Mon, Aug 19, 2013 at 12:18 PM, Bret Wortman < > bret.wort...@damascusgrp.com> wrote: > >> Digging further, I think this log entry might be the problem between the >> two servers that aren't talking: >> >> slapd_ldap_sasl_interactive_bind - Error: could not perform interactive >> bind for id[] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic >> failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more >> information (Server ldap/localh...@spx.net not found in Kerberos >> database)) errno 2 (No such file or directory) >> >> Did I build something incorrectly when that server was set up originally? >> >> >> >> * >> * >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Mon, Aug 19, 2013 at 12:02 PM, Bret Wortman < >> bret.wort...@damascusgrp.com> wrote: >> >>> I ran it on a good master, against a bad one. As in, I ran this command >>> on my master IPA node: >>> >>> # ipa-replica-manage del --force bad1.foo.net --cleanup >>> >>> Was that wrong? I was trying to delete the bad replica from the master, >>> so I figured the command needed to be run on the master. But again, my >>> master is now in a state where it's not resolving DNS, user logins, or sudo >>> at the very least. >>> >>> Oh, and I checked the node that it was complaining about earlier. The >>> network connection to it is the pits, but it's there. And it resolves. >>> >>> >>> * >>> * >>> *Bret Wortman* >>> >>> http://damascusgrp.com/ >>> http://about.me/wortmanbret >>> >>> >>> On Mon, Aug 19, 2013 at 11:58 AM, Rob Crittenden wrote: >>> >>>> Rob Crittenden wrote: >>>> >>>>> Bret Wortman wrote: >>>>> >>>>>> Well, my master ground to a halt and wasn't responding. I rebooted the >>>>>> system and now I can't access the web UI or ssh to the master either. >>>>>> I >>>>>> have console access but that's it. >>>>>> >>>>>> The services all say they're running, but the web UI gives an "Unknown >>>>>> Error" dialog and ssh fails with "ssh_exchange_identification: >>>>>> Connection closed by remote host" whenever I try to ssh to ipamaster. >>>>>> I >>>>>> think something has gone really wrong inside my master. Any ideas? >>>>>> Even >>>>>> after the reboot, --cleanup isn't helping and just hangs. >>>>>> >>>>>> The logfiles end (as of the time I ^C'd the process) with: >>>>>> >>>>>> NSMMReplicationPlugin - agmt="cn=meTogood3.spx.net >>>>>> <http://meTogood3.spx.net>" (good3:389): Replication bind with GSSAPI >>>>>> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>>>> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >>>>>> information (Cannot determine realm for numeric host address)) >>>>>> NSMMReplicationPlugin - CleanAllRUV Task: Replica not online >>>>>> (agmt="cn=meTogood3.foo.net <http://meTogood3.foo.net>" (good3:389)) >>>>>> NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, >>>>>> retrying in 160 seconds..., >>>>>> >>>>>> So it looks like it's having trouble talking with one of my replicas >>>>>> and >>>>>> is doggedly trying to get the job done. Any idea how to get the master >>>>>> back working again while I troubleshoot this connectivity issue? >>>>>> >>>>> >>>>> That suggests a DNS problem, and it might explain ssh as well depending >>>>> on your configuration. >>>>> >>>> >>>> To be clear, you ran --cleanup against one of the bad masters, not a >>>> good one, right? >>>> >>>> rob >>>> >>>> >>> >> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fwd: Replication woes
On my master (where this error is occurring), I've got, in /etc/hosts: 127.0.0.1 localhost localhost.localdomain ::1 localhost localhost.localdomain 1.2.3.4ipamaster.foo.net ipamaster So that should be okay, right? # host ipamaster.foo.net ipamaster.foo.net has address 1.2.3.4 # host ipamaster ipamaster.foo.net has address 1.2.3.4 # host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 # I checked the other system (the one I can't connect to) to be safe, and its /etc/hosts is similarly configured. It even has the master listed with its correct IP address. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 2:02 PM, Simo Sorce wrote: > On Mon, 2013-08-19 at 13:51 -0400, Bret Wortman wrote: > > So, any idea how to fix the Kerberos problem? > > > > If your server is trying to get a tgt for ldap/localhost it probably > means your /etc/hosts file is broken and has a line like this: > > 1.2.3.4 localhost my.real.name > > When GSSAPI tries to resolve my.realm.name it gets back that 'localhost' > is the canonical name so it tries to get a TGT with that name and it > fails. > > If /etc/host sis fine then the DNS server may be returning an IP address > that later resolves to localhost again. > > To unbreak make sure that if you have your fully qualified name > in /etc/hosts that it is on its own line pointing at the right IP > address and where the FQDN name is the first in line: > eg: > > this is ok: > 1.2.3.4 server.full.name server > > this is not: > 1.2.3.4 server server.full.name > > Simo. > > > > Bret Wortman > > > > > > http://damascusgrp.com/ > > > > http://about.me/wortmanbret > > > > > > > > On Mon, Aug 19, 2013 at 12:19 PM, Bret Wortman > > wrote: > > ...and I got the web UI, authentication and sudo back via: > > > > > > # ipactl stop > > # ipactl start > > > > > > Not sure why that worked, but it did. I was grasping at > > straws, honestly. > > > > > > > > > > > > Bret Wortman > > > > > > http://damascusgrp.com/ > > > > http://about.me/wortmanbret > > > > > > > > > > On Mon, Aug 19, 2013 at 12:18 PM, Bret Wortman > > wrote: > > Digging further, I think this log entry might be the > > problem between the two servers that aren't talking: > > > > > > slapd_ldap_sasl_interactive_bind - Error: could not > > perform interactive bind for id[] mech [GSSAPI]: LDAP > > error -2 (Local error) (SASL(-1): generic failure: > > GSSAPI Error: Unspecified GSS failure. Minor code may > > provide more information (Server > > ldap/localh...@spx.net not found in Kerberos > > database)) errno 2 (No such file or directory) > > > > > > Did I build something incorrectly when that server was > > set up originally? > > > > > > > > > > > > > > > > Bret Wortman > > > > > > http://damascusgrp.com/ > > > > http://about.me/wortmanbret > > > > > > > > > > On Mon, Aug 19, 2013 at 12:02 PM, Bret Wortman > > wrote: > > I ran it on a good master, against a bad one. > > As in, I ran this command on my master IPA > > node: > > > > > > # ipa-replica-manage del --force bad1.foo.net > > --cleanup > > > > > > Was that wrong? I was trying to delete the bad > > replica from the master, so I figured the > > command needed to be run on the master. But > > again, my master is now in a state where it's > > not resolving DNS, user logins, or sudo at the > > very least. > > > > > > Oh, and I checked the node that it was > > complaining about earlier. The network > > connection to it is the pits, but it's there. > > And it resolves. > > > > >
Re: [Freeipa-users] Replication woes
Okay, now I'm thinking I need to dump all my replicas and start them fresh. My /var/log/slapd-FOO-COM/errors is filled with messages like this: NSMMReplicationPlugin - changelog program - agmt="cn=meTogood1.foo.com" (good1:389): CSN 520a4964001d not found, we aren't as up to date, or we purged agmt="cn=meTogood1.foo.com" (good1:389) - Can't locate CSN 520a4964001d in the changelog (DB rc=-30988). The consumer may need to be reinitialized. I assume the "consumer" is the replica, right? At present, I have two replicas known to my master that are simply gone. Another is there but they can't talk. Three more have good communication but I'm getting errors like these. Is there a good, clean way to just clobber all the replicas and start over without trashing the DNS and other identity data that is inside my master and which *is* working? Deleting them from the master hasn't been working; it tends to hang the master's DNS and other services until I Ctrl-C out and "ipactl restart" it. I'm afraid to venture out without a net here and make things worse * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Aug 19, 2013 at 2:21 PM, Bret Wortman wrote: > On my master (where this error is occurring), I've got, in /etc/hosts: > > 127.0.0.1 localhost localhost.localdomain > ::1 localhost localhost.localdomain > 1.2.3.4ipamaster.foo.net ipamaster > > So that should be okay, right? > > # host ipamaster.foo.net > ipamaster.foo.net has address 1.2.3.4 > # host ipamaster > ipamaster.foo.net has address 1.2.3.4 > # host localhost > localhost has address 127.0.0.1 > localhost has IPv6 address ::1 > # > > I checked the other system (the one I can't connect to) to be safe, and > its /etc/hosts is similarly configured. It even has the master listed with > its correct IP address. > > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Mon, Aug 19, 2013 at 2:02 PM, Simo Sorce wrote: > >> On Mon, 2013-08-19 at 13:51 -0400, Bret Wortman wrote: >> > So, any idea how to fix the Kerberos problem? >> > >> >> If your server is trying to get a tgt for ldap/localhost it probably >> means your /etc/hosts file is broken and has a line like this: >> >> 1.2.3.4 localhost my.real.name >> >> When GSSAPI tries to resolve my.realm.name it gets back that 'localhost' >> is the canonical name so it tries to get a TGT with that name and it >> fails. >> >> If /etc/host sis fine then the DNS server may be returning an IP address >> that later resolves to localhost again. >> >> To unbreak make sure that if you have your fully qualified name >> in /etc/hosts that it is on its own line pointing at the right IP >> address and where the FQDN name is the first in line: >> eg: >> >> this is ok: >> 1.2.3.4 server.full.name server >> >> this is not: >> 1.2.3.4 server server.full.name >> >> Simo. >> > >> > Bret Wortman >> > >> > >> > http://damascusgrp.com/ >> > >> > http://about.me/wortmanbret >> > >> > >> > >> > On Mon, Aug 19, 2013 at 12:19 PM, Bret Wortman >> > wrote: >> > ...and I got the web UI, authentication and sudo back via: >> > >> > >> > # ipactl stop >> > # ipactl start >> > >> > >> > Not sure why that worked, but it did. I was grasping at >> > straws, honestly. >> > >> > >> > >> > >> > >> > Bret Wortman >> > >> > >> > http://damascusgrp.com/ >> > >> > http://about.me/wortmanbret >> > >> > >> > >> > >> > On Mon, Aug 19, 2013 at 12:18 PM, Bret Wortman >> > wrote: >> > Digging further, I think this log entry might be the >> > problem between the two servers that aren't talking: >> > >> > >> > slapd_ldap_sasl_interactive_bind - Error: could not >> > perform interactive bind for id[] mech [GSSAPI]: LDAP >> > error -2 (Local error) (SASL(-1): generic failure: >> > GSSAPI Error: Unspecified GSS failure. Minor code may >> > provide more information (Server >> > ldap/localh...@spx.net not found in Kerberos >> > database)) errn
Re: [Freeipa-users] Replication woes
If I were going to attempt to restore to an old backup, what directories/files should I make sure to restore? I've got a backup script that tars up: /usr/share/ipa /usr/lib64/ipa /var/lib/pia /var/lib/ipa-client /var/lib/dirsrv /etc Is that enough to "roll back" to a few days ago before I started down this path? I'm now seeing messages about having the max number of CleanAllRUV tasks (4) and not being able to enqueue any more. So I'm really stuck now and don't know how soon I can get the files requested over to Rich for analysis. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Aug 20, 2013 at 9:46 AM, Rich Megginson wrote: > On 08/20/2013 05:55 AM, Bret Wortman wrote: > > Okay, now I'm thinking I need to dump all my replicas and start them > fresh. My /var/log/slapd-FOO-COM/errors is filled with messages like this: > > NSMMReplicationPlugin - changelog program - agmt="cn=meTogood1.foo.com" > (good1:389): CSN 520a4964001d not found, we aren't as up to date, > or we purged > agmt="cn=meTogood1.foo.com" (good1:389) - Can't locate CSN > 520a4964001d in the changelog (DB rc=-30988). The consumer may need > to be reinitialized. > > I assume the "consumer" is the replica, right? At present, I have two > replicas known to my master that are simply gone. Another is there but they > can't talk. Three more have good communication but I'm getting errors like > these. Is there a good, clean way to just clobber all the replicas and > start over without trashing the DNS and other identity data that is inside > my master and which *is* working? Deleting them from the master hasn't > been working; it tends to hang the master's DNS and other services until I > Ctrl-C out and "ipactl restart" it. > > I'm afraid to venture out without a net here and make things worse > > > This looks like https://fedorahosted.org/389/ticket/47386 > > We've never been able to reproduce this in a "controlled" environment. > > The original reporter has been able to get this to work in some cases by > restarting ipa (ipactl restart). > > Before you do that, would you be able to provide some information for me? > > On the supplier and consumer: > ldapsearch -xLLL -D "cn=directory manager" -W -b "dc=FOO,dc=COM" > '(&(objectclass=nstombstone)(nsuniqueid=---))' > > ruv.ldif > > ldapsearch -xLLL -D "cn=directory manager" -W -b "cn=config" > '(objectclass=nsds5replicationagreement)' > agmt.ldif > > dbscan -f /var/lib/dirsrv/slapd-FOO-COM/cldb/*.db4 | head -200 > cldb.txt > > Be sure to obscure any sensitive data in ruv.ldif, agmt.ldif, and cldb.txt > - you can either attach to https://fedorahosted.org/389/ticket/47386 or > email to me directly. > > > > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Mon, Aug 19, 2013 at 2:21 PM, Bret Wortman < > bret.wort...@damascusgrp.com> wrote: > >>On my master (where this error is occurring), I've got, in /etc/hosts: >> >> 127.0.0.1 localhost localhost.localdomain >> ::1 localhost localhost.localdomain >> 1.2.3.4ipamaster.foo.net ipamaster >> >> So that should be okay, right? >> >> # host ipamaster.foo.net >> ipamaster.foo.net has address 1.2.3.4 >> # host ipamaster >> ipamaster.foo.net has address 1.2.3.4 >> # host localhost >> localhost has address 127.0.0.1 >> localhost has IPv6 address ::1 >> # >> >> I checked the other system (the one I can't connect to) to be safe, and >> its /etc/hosts is similarly configured. It even has the master listed with >> its correct IP address. >> >> >> >> * >> * >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Mon, Aug 19, 2013 at 2:02 PM, Simo Sorce wrote: >> >>> On Mon, 2013-08-19 at 13:51 -0400, Bret Wortman wrote: >>> > So, any idea how to fix the Kerberos problem? >>> > >>> >>> If your server is trying to get a tgt for ldap/localhost it probably >>> means your /etc/hosts file is broken and has a line like this: >>> >>> 1.2.3.4 localhost my.real.name >>> >>> When GSSAPI tries to resolve my.realm.name it gets back that 'localhost' >>> is the canonical name so it tries to get a TGT with that name and it >>> fails. >>> >>> If /etc/host sis
[Freeipa-users] Scorched earth
Today, I'm going to wipe my master, install f18 from scratch, then install the freeipa-server RPMs again and manually load all our hosts, dns entries, and users from scratch (I'm building scripts to do this for me using the command line tools). We'll then do the same for each replica so that our system will basically be starting clean again. Are there any files that I really ought to back up and restore as part of this effort, like certificates, that might make it easier for clients to deal with us after the master comes back on line? Or am I safe to just nuke the box and start clean? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fwd: Scorched earth
Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 28, 2013 at 9:56 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Today, I'm going to wipe my master, install f18 from scratch, then >> install the freeipa-server RPMs again and manually load all our hosts, >> dns entries, and users from scratch (I'm building scripts to do this for >> me using the command line tools). We'll then do the same for each >> replica so that our system will basically be starting clean again. >> >> Are there any files that I really ought to back up and restore as part >> of this effort, like certificates, that might make it easier for clients >> to deal with us after the master comes back on line? Or am I safe to >> just nuke the box and start clean? >> > > You'll end up with a new CA so you'll need to re-enroll any client > machines. Browsers will see the most grief as there will be a different CA > with the same subject. > > Depending on how you are migrating your users they will all likely need to > reset their passwords, or go through the migration step. > > rob > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
I was actually considering something like a few hours ago. It's a VM, so making another isn't that hard. Replication is the source of all my problems, though, so I'm concerned about whether it will work. Certainly worth the attempt! I'll report back later tomorrow. On Wed, Aug 28, 2013 at 8:56 PM, Jatin Nansi wrote: > On 08/29/2013 12:16 AM, Bret Wortman wrote: >> Ugh. Well that certainly hurts, but I just don't see an alternative. I >> hope Puppet can at least make the re-enrollment a bit easier. >> >> I'm still hand-copying some of the configuration and user group >> details and crafting the load scripts so if anyone has a bright idea >> in the next few hours, I'd love to hear it! > Is there a reason why you must scorch earth? You could try a rolling > update approach first - install a fresh IPA system, make it a replica of > the existing IPA setup. Then reinstall existing IPA systems and use the > updated system to set them up. > Jatin > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
Okay, I have a replica built and running. My original, "sick" server is ipamaster and the new one is ipamaster2. All I've done thus far on ipamaster2 is run ipa-replica-install --setup-dns --no-forwarders replica-info-ipamaster2.foo.net.gpg. What additional steps do I need to take to ensure that the process of shutting down ipamaster, wiping it out, building it up fresh and then replicating ipamaster2 back to ipamaster and making ipamaster again the center of the universe and my certificate authority work correctly, cleanly, and with minimal fuss? Given the mess I got our servers already, I figured I should ask *before* I start messing about today. I *think* the process should look something like this (I don't want you all thinking I'm looking for someone to do *all* my thinking for me): 1. Take snapshot of ipamaster (just in case) 2. [ipamaster2]# ipa-ca-install /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg<http://bl-1.com/click/load/UmNcb1c3BTVQNlMzBTU-b0231>(I should've done this during the ipa-ca-install, but since the ca step is so rare, I didn't have it in my wiki notes). 3. [ipamaster]# reboot This reboot will trigger a Cobbler & Puppet-based wipe of the system and reinstallation of F18 and freeipa-server. While that's going on: 4. [ipamaster2]# ipa-replica-prepare ipamaster.foo.net<http://bl-1.com/click/load/XWxZalAwUWFQNgdnBzY-b0231>1.2.3.4 When ipamaster is back up: 5. [ipamaster]# cd /var/lib/ipa && scp ipamaster2:/var/lib/ipa/replica-info-ipamaster.foo.net.gpg<http://bl-1.com/click/load/UmMKOVw8AjICZAdnVGo-b0231>. 6. [ipamaster]# ipa-replica-install --setup-dns --no-forwarders --setup-ca replica-info-ipamaster.foo.net.gpg<http://bl-1.com/click/load/Bjdcb1AwUGAEYgZmCTY-b0231> Usually, there's some reason I need to go back to ipamaster2 and either delete a dns entry or ipa host-del the system. After the replica install is done: 7. Shut down and delete the ipamaster2 VM. 8. Upgrade existing "replicas" to F18 and latest IPA version. 9. Establish replication agreements with now-functioning ipamaster. Does that sound right? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 28, 2013 at 10:01 PM, Bret Wortman wrote: > I was actually considering something like a few hours ago. It's a VM, so > making another isn't that hard. Replication is the source of all my > problems, though, so I'm concerned about whether it will work. Certainly > worth the attempt! > > I'll report back later tomorrow. > > > On Wed, Aug 28, 2013 at 8:56 PM, Jatin Nansi wrote: > >> On 08/29/2013 12:16 AM, Bret Wortman wrote: >> > Ugh. Well that certainly hurts, but I just don't see an alternative. I >> > hope Puppet can at least make the re-enrollment a bit easier. >> > >> > I'm still hand-copying some of the configuration and user group >> > details and crafting the load scripts so if anyone has a bright idea >> > in the next few hours, I'd love to hear it! >> Is there a reason why you must scorch earth? You could try a rolling >> update approach first - install a fresh IPA system, make it a replica of >> the existing IPA setup. Then reinstall existing IPA systems and use the >> updated system to set them up. >> >> Jatin >> >> ___ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
On Thu, Aug 29, 2013 at 9:09 AM, Simo Sorce wrote: > On Thu, 2013-08-29 at 08:07 -0400, Bret Wortman wrote: > > Okay, I have a replica built and running. My original, "sick" server > > is ipamaster and the new one is ipamaster2. All I've done thus far on > > ipamaster2 is run ipa-replica-install --setup-dns --no-forwarders > > replica-info-ipamaster2.foo.net.gpg. > > > > > > What additional steps do I need to take to ensure that the process of > > shutting down ipamaster, wiping it out, building it up fresh and then > > replicating ipamaster2 back to ipamaster and making ipamaster again > > the center of the universe and my certificate authority work > > correctly, cleanly, and with minimal fuss? Given the mess I got our > > servers already, I figured I should ask before I start messing about > > today. > > > > > > I think the process should look something like this (I don't want you > > all thinking I'm looking for someone to do all my thinking for me): > > > > > > 1. Take snapshot of ipamaster (just in case) > > 2. [ipamaster2]# > > ipa-ca-install /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg (I > > should've done this during the ipa-ca-install, but since the ca step > > is so rare, I didn't have it in my wiki notes). > > 3. [ipamaster]# reboot > > > > > > This reboot will trigger a Cobbler & Puppet-based wipe of the system > > and reinstallation of F18 and freeipa-server. While that's going on: > > > > > > 4. [ipamaster2]# ipa-replica-prepare ipamaster.foo.net 1.2.3.4 > > You need to use ipa-replica-manage to remove the original ipamaster > before you can prepare to add a new one. > > After it is fully removed and replica file generated you need to restart > at yleast 389ds on ipamaster2 this is due to the fact that DS does nto > purge valid tickets, and it holds a ticket valid for the old ipamaster, > however when you reinstall the new the name will match so replication > between ipamaster2 -> ipamaster may fail because ipamsater2 has a wrong > ticket (using old key you just nuked before the reinstall). > > > Got it. Glad I asked! I'll add these steps to my procedure. > > When ipamaster is back up: > > > > > > 5. [ipamaster]# cd /var/lib/ipa && scp > > You can copy in /root > > I usually do it in /var/lib/ipa I guess because that's where the server puts the file, so it makes it easy for me to remember that's where it is. But point taken. > > ipamaster2:/var/lib/ipa/replica-info-ipamaster.foo.net.gpg . > > 6. [ipamaster]# ipa-replica-install --setup-dns --no-forwarders > > --setup-ca replica-info-ipamaster.foo.net.gpg > > > > > > Usually, there's some reason I need to go back to ipamaster2 and > > either delete a dns entry or ipa host-del the system. > > Uh ? Sound like this is going to screw up things, why should you delete > DNS entries ? > ipa host-del of a master is *certainly* going to break replication and > basically everything. Is this what you did in your old setup ? > Only if ipa-replica-install said I needed to. > > > After the replica install is done: > > > > > > 7. Shut down and delete the ipamaster2 VM. > > Do not forget to ipa-replica-manage remove it first. > Awesome. This is why I asked. > > > 8. Upgrade existing "replicas" to F18 and latest IPA version. > > 9. Establish replication agreements with now-functioning ipamaster. > > > > > > Does that sound right? > > > > > See above. > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
Agreed, but not always possible. I had a replica crash hard and it wasn't possible to remove it. In other news: [ipamaster2]# ipa-ca-install replica-info-ipamaster2.spx.net.gpg A selfsign CA can not be added Is there a way around this? How can I ensure that I can transfer the CA back to ipamaster after it's been erased & reinstalled? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce wrote: > On Thu, 2013-08-29 at 09:14 -0400, Bret Wortman wrote: > > On Thu, Aug 29, 2013 at 9:09 AM, Simo Sorce wrote: > > On Thu, 2013-08-29 at 08:07 -0400, Bret Wortman wrote: > > > Okay, I have a replica built and running. My original, > > "sick" server > > > is ipamaster and the new one is ipamaster2. All I've done > > thus far on > > > ipamaster2 is run ipa-replica-install --setup-dns > > --no-forwarders > > > replica-info-ipamaster2.foo.net.gpg. > > > > > > > > > What additional steps do I need to take to ensure that the > > process of > > > shutting down ipamaster, wiping it out, building it up fresh > > and then > > > replicating ipamaster2 back to ipamaster and making > > ipamaster again > > > the center of the universe and my certificate authority work > > > correctly, cleanly, and with minimal fuss? Given the mess I > > got our > > > servers already, I figured I should ask before I start > > messing about > > > today. > > > > > > > > > I think the process should look something like this (I don't > > want you > > > all thinking I'm looking for someone to do all my thinking > > for me): > > > > > > > > > 1. Take snapshot of ipamaster (just in case) > > > 2. [ipamaster2]# > > > > > ipa-ca-install /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg > (I > > > should've done this during the ipa-ca-install, but since the > > ca step > > > is so rare, I didn't have it in my wiki notes). > > > 3. [ipamaster]# reboot > > > > > > > > > This reboot will trigger a Cobbler & Puppet-based wipe of > > the system > > > and reinstallation of F18 and freeipa-server. While that's > > going on: > > > > > > > > > 4. [ipamaster2]# ipa-replica-prepare ipamaster.foo.net > > 1.2.3.4 > > > > > > You need to use ipa-replica-manage to remove the original > > ipamaster > > before you can prepare to add a new one. > > > > After it is fully removed and replica file generated you need > > to restart > > at yleast 389ds on ipamaster2 this is due to the fact that DS > > does nto > > purge valid tickets, and it holds a ticket valid for the old > > ipamaster, > > however when you reinstall the new the name will match so > > replication > > between ipamaster2 -> ipamaster may fail because ipamsater2 > > has a wrong > > ticket (using old key you just nuked before the reinstall). > > > > > > > > > > > Got it. Glad I asked! I'll add these steps to my procedure. > > > > > When ipamaster is back up: > > > > > > > > > 5. [ipamaster]# cd /var/lib/ipa && scp > > > > > > You can copy in /root > > > > > > I usually do it in /var/lib/ipa I guess because that's where the > > server puts the file, so it makes it easy for me to remember that's > > where it is. But point taken. > > > > > > > ipamaster2:/var/lib/ipa/replica-info-ipamaster.foo.net.gpg . > > > 6. [ipamaster]# ipa-replica-install --setup-dns > > --no-forwarders > > > --setup-ca replica-info-ipamaster.foo.net.gpg > > > > > > > > > Usually, there's some reason I need to go back to ipamaster2 > > and > > > either delete a dns entry or ipa host-del the system. > > > > > > Uh ? Sound like this is going to screw up
Re: [Freeipa-users] Fwd: Scorched earth
A bit of googling has led me to understand that we must have created the original server with --selfsign, and that locked us into something bad which is now causing us problems. I'm not sure how this happened, since we actually created our original instance on a different server, created ipamaster as a replica of that one, then ran ipa-ca-install on ipamaster to make it the new CA. How did it end up in this state? Anyway, is there ANY way around this? Can I simply ignore this, break the replication agreement as Simo suggested, rebuild ipamaster, replicate ipamaster2 to the new ipamaster, and then somehow make ipamaster be a CA using Dogtag? Will that screw up all the clients? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 9:24 AM, Bret Wortman wrote: > Agreed, but not always possible. I had a replica crash hard and it wasn't > possible to remove it. > > In other news: > > [ipamaster2]# ipa-ca-install replica-info-ipamaster2.spx.net.gpg > A selfsign CA can not be added > > Is there a way around this? How can I ensure that I can transfer the CA > back to ipamaster after it's been erased & reinstalled? > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce wrote: > >> On Thu, 2013-08-29 at 09:14 -0400, Bret Wortman wrote: >> > On Thu, Aug 29, 2013 at 9:09 AM, Simo Sorce wrote: >> > On Thu, 2013-08-29 at 08:07 -0400, Bret Wortman wrote: >> > > Okay, I have a replica built and running. My original, >> > "sick" server >> > > is ipamaster and the new one is ipamaster2. All I've done >> > thus far on >> > > ipamaster2 is run ipa-replica-install --setup-dns >> > --no-forwarders >> > > replica-info-ipamaster2.foo.net.gpg. >> > > >> > > >> > > What additional steps do I need to take to ensure that the >> > process of >> > > shutting down ipamaster, wiping it out, building it up fresh >> > and then >> > > replicating ipamaster2 back to ipamaster and making >> > ipamaster again >> > > the center of the universe and my certificate authority work >> > > correctly, cleanly, and with minimal fuss? Given the mess I >> > got our >> > > servers already, I figured I should ask before I start >> > messing about >> > > today. >> > > >> > > >> > > I think the process should look something like this (I don't >> > want you >> > > all thinking I'm looking for someone to do all my thinking >> > for me): >> > > >> > > >> > > 1. Take snapshot of ipamaster (just in case) >> > > 2. [ipamaster2]# >> > > >> > ipa-ca-install /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg >> (I >> > > should've done this during the ipa-ca-install, but since the >> > ca step >> > > is so rare, I didn't have it in my wiki notes). >> > > 3. [ipamaster]# reboot >> > > >> > > >> > > This reboot will trigger a Cobbler & Puppet-based wipe of >> > the system >> > > and reinstallation of F18 and freeipa-server. While that's >> > going on: >> > > >> > > >> > > 4. [ipamaster2]# ipa-replica-prepare ipamaster.foo.net >> > 1.2.3.4 >> > >> > >> > You need to use ipa-replica-manage to remove the original >> > ipamaster >> > before you can prepare to add a new one. >> > >> > After it is fully removed and replica file generated you need >> > to restart >> > at yleast 389ds on ipamaster2 this is due to the fact that DS >> > does nto >> > purge valid tickets, and it holds a ticket valid for the old >> > ipamaster, >> > however when you reinstall the new the name will match so >> > replication >> > between ipamaster2 -> ipamaster may fail because ipamsater2 >> > has a wrong >> > ticket (using old key you just nuked before the reinsta
Re: [Freeipa-users] Fwd: Scorched earth
On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> A bit of googling has led me to understand that we must have created the >> original server with --selfsign, and that locked us into something bad >> which is now causing us problems. I'm not sure how this happened, since >> we actually created our original instance on a different server, created >> ipamaster as a replica of that one, then ran ipa-ca-install on ipamaster >> to make it the new CA. How did it end up in this state? >> >> Anyway, is there ANY way around this? Can I simply ignore this, break >> the replication agreement as Simo suggested, rebuild ipamaster, >> replicate ipamaster2 to the new ipamaster, and then somehow make >> ipamaster be a CA using Dogtag? Will that screw up all the clients? >> > > I think we should pause and take a look at your installation. > > I'd check all your current masters, whether they are currently working or > not. Look at the value of ra_plugin in /etc/ipa/default.conf. That controls > what IPA thinks the CA is. > > on ipamaster: ra_plugin=dogtag and either that same value or the ra_plugin doesn't exist on the replicas. On ipamaster2, the one I just installed, there is no ra_plugin in the file. > Then check to see if you have dogtag running on any of these systems. This > will include a 2nd 389-ds instance, /etc/dirsrv/slapd-PKI-IPA and, > depending on your distro, a PKI service like pki-tomcatd@pki-tomcat.**service. > You can optionally see if /etc/pki/pki-tomcat exists. > > ipamaster definitely has a /etc/dirsrv/slapd-PKI-IPA directory, with files updated fairly recently (within the past 30 minutes - lse.ldif and lse.ldif.bak, others updated yesterday). I also have a pki-tomcatd@.service file and a pki-tomcatd.target. no /etc/pki/pki-tomcat. ipamaster2 only has /etc/dirsrv/slapd-FOO-NET. It does have pki-tomcatd.target and pki-tomcatd@.service. No /etc/pki/pki-tomcat. > There is currently no way post-install to add a dogtag instance. > > rob > > >> >> _ >> _ >> *Bret Wortman* >> >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Thu, Aug 29, 2013 at 9:24 AM, Bret Wortman >> > <mailto:bret.wortman@**damascusgrp.com>> >> wrote: >> >> Agreed, but not always possible. I had a replica crash hard and it >> wasn't possible to remove it. >> >> In other news: >> >> [ipamaster2]# ipa-ca-install replica-info-ipamaster2.spx.**net.gpg >> A selfsign CA can not be added >> >> Is there a way around this? How can I ensure that I can transfer the >> CA back to ipamaster after it's been erased & reinstalled? >> >> >> _ >> _ >> *Bret Wortman* >> >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce > <mailto:s...@redhat.com>> wrote: >> >> On Thu, 2013-08-29 at 09:14 -0400, Bret Wortman wrote: >> > On Thu, Aug 29, 2013 at 9:09 AM, Simo Sorce > <mailto:s...@redhat.com>> wrote: >> > On Thu, 2013-08-29 at 08:07 -0400, Bret Wortman wrote: >> > > Okay, I have a replica built and running. My >> original, >> > "sick" server >> > > is ipamaster and the new one is ipamaster2. All >> I've done >> > thus far on >> > > ipamaster2 is run ipa-replica-install --setup-dns >> > --no-forwarders >> > > replica-info-ipamaster2.foo.**net.gpg. >> > > >> > > >> > > What additional steps do I need to take to ensure >> that the >> > process of >> > > shutting down ipamaster, wiping it out, building it >> up fresh >> > and then >> > > replicating ipamaster2 back to ipamaster and making >> > ipamaster again >> > > the center of the universe and my certificate >> authority work >> > > correctly, cleanly, and with minimal fuss? Given >> the mess I >> > got our >> > > servers already, I figured I should ask before I >> start >> > messing about >> >
[Freeipa-users] Fwd: Fwd: Scorched earth
On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden > <mailto:rcrit...@redhat.com>> wrote: >> >> Bret Wortman wrote: >> >> A bit of googling has led me to understand that we must have >> created the >> original server with --selfsign, and that locked us into >> something bad >> which is now causing us problems. I'm not sure how this >> happened, since >> we actually created our original instance on a different server, >> created >> ipamaster as a replica of that one, then ran ipa-ca-install on >> ipamaster >> to make it the new CA. How did it end up in this state? >> >> Anyway, is there ANY way around this? Can I simply ignore this, >> break >> the replication agreement as Simo suggested, rebuild ipamaster, >> replicate ipamaster2 to the new ipamaster, and then somehow make >> ipamaster be a CA using Dogtag? Will that screw up all the >> clients? >> >> >> I think we should pause and take a look at your installation. >> >> I'd check all your current masters, whether they are currently >> working or not. Look at the value of ra_plugin in >> /etc/ipa/default.conf. That controls what IPA thinks the CA is. >> >> on ipamaster: ra_plugin=dogtag >> >> and either that same value or the ra_plugin doesn't exist on the >> replicas. On ipamaster2, the one I just installed, there is no ra_plugin >> in the file. >> >> Then check to see if you have dogtag running on any of these >> systems. This will include a 2nd 389-ds instance, >> /etc/dirsrv/slapd-PKI-IPA and, depending on your distro, a PKI >> service like pki-tomcatd@pki-tomcat.__**service. You can optionally >> >> see if /etc/pki/pki-tomcat exists. >> >> ipamaster definitely has a /etc/dirsrv/slapd-PKI-IPA directory, with >> files updated fairly recently (within the past 30 minutes - lse.ldif and >> lse.ldif.bak, others updated yesterday). I also have a >> pki-tomcatd@.service file and a pki-tomcatd.target. no >> /etc/pki/pki-tomcat. >> >> ipamaster2 only has /etc/dirsrv/slapd-FOO-NET. It does have >> pki-tomcatd.target and pki-tomcatd@.service. No /etc/pki/pki-tomcat. >> > > Ok. When you created the replica file for ipamaster2, did you create it on > ipamaster? Only a replica that is a CA can create a replica with a CA. > > Yes. So I'm not sure what went askew. > If you generated the replica file on another master, I *think* what you > can safely do is this: > > - prepare a replica on ipamaster for ipamaster2 and copy the file there > - on ipamaster2 run ipa-ca-install against the updated replica file > > rob > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Fwd: Scorched earth
What passpharase would this be encrypted with? If it's something I set a year ago and never needed to know again, then we may be screwed. If it's saved somewhere, where should I look? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 11:58 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden > <mailto:rcrit...@redhat.com>>**wrote: >> >> Bret Wortman wrote: >> >> On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden >> mailto:rcrit...@redhat.com> >> <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> wrote: >> >> Bret Wortman wrote: >> >> A bit of googling has led me to understand that we must >> have >> created the >> original server with --selfsign, and that locked us into >> something bad >> which is now causing us problems. I'm not sure how this >> happened, since >> we actually created our original instance on a >> different server, >> created >> ipamaster as a replica of that one, then ran >> ipa-ca-install on >> ipamaster >> to make it the new CA. How did it end up in this state? >> >> Anyway, is there ANY way around this? Can I simply >> ignore this, >> break >> the replication agreement as Simo suggested, rebuild >> ipamaster, >> replicate ipamaster2 to the new ipamaster, and then >> somehow make >> ipamaster be a CA using Dogtag? Will that screw up all >> the clients? >> >> >> I think we should pause and take a look at your installation. >> >> I'd check all your current masters, whether they are >> currently >> working or not. Look at the value of ra_plugin in >> /etc/ipa/default.conf. That controls what IPA thinks the CA >> is. >> >> on ipamaster: ra_plugin=dogtag >> >> and either that same value or the ra_plugin doesn't exist on the >> replicas. On ipamaster2, the one I just installed, there is no >> ra_plugin >> in the file. >> >> Then check to see if you have dogtag running on any of these >> systems. This will include a 2nd 389-ds instance, >> /etc/dirsrv/slapd-PKI-IPA and, depending on your distro, a >> PKI >> service like pki-tomcatd@pki-tomcat.**service. You can >> >> optionally >> >> see if /etc/pki/pki-tomcat exists. >> >> ipamaster definitely has a /etc/dirsrv/slapd-PKI-IPA directory, >> with >> files updated fairly recently (within the past 30 minutes - >> lse.ldif and >> lse.ldif.bak, others updated yesterday). I also have a >> pki-tomcatd@.service file and a pki-tomcatd.target. no >> /etc/pki/pki-tomcat. >> >> ipamaster2 only has /etc/dirsrv/slapd-FOO-NET. It does have >> pki-tomcatd.target and pki-tomcatd@.service. No >> /etc/pki/pki-tomcat. >> >> >> Ok. When you created the replica file for ipamaster2, did you create >> it on ipamaster? Only a replica that is a CA can create a replica >> with a CA. >> >> Yes. So I'm not sure what went askew. >> > > Ok. I think we need to see what's in the prepared file. It is just a > gpg-encrypted tarball. Can you do something like: > > gpg -d replica-info-pacer.greyoak.**com.gpg |tar xf - > > This will create a realm_info subdirectory. The file cacert.p12 should be > in there. > > rob > > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fwd: Fwd: Fwd: Scorched earth
Morning update. I made the change Rob suggested to /etc/ipa/default.conf, which appeared to work, but didn't quite. It asked me to back out the whole server installation and start over: [ipamaster2]# ipa-ca-install --skip-conncheck replica-info-ipamaster2.foo.net.gpg Directory Manager (existing master) password: COnfiguring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exit status 1 Your system may be partly configured. Run/usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed. [ipamaster2]# Which uninstallation & cleanup I did. Now, when trying to re-install the replica file: [ipamaster2]# ipa-replica-install --setup-dns --no-forwarders --setup-ca /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg Directory manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipamaster.foo.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (686): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The followign list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@foo.net password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipamaster2.foo.net': Directory Service: Unsecure port (389): OK Directory Service: Secure port (686): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK The host ipamaster2.foo.net already exists on the master server. You should remove it before proceeding: % ipa host-del ipamaster2.foo.net ipa : ERRORCould not resolve hostname ipamaster.foo.net using DNS Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.) Continue? [no]: *yes* [ipamaster2]# host ipamaster.foo.net ipamaster.foo.net has address 1.2.3.4 No matter what answer I give to the "Continue?" prompt, it just exits. "nslookup" returns the same value, and I have three different nameservers configured for this host (including ipamaster and two of the older replicas). And this message is the one that has prompted me to want to delete hosts before installing in the past, Simo. Any thoughts on how best to proceed now? *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 2:59 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Okay, I got the cacert.p12 (turns out it was taking my passphrase, but >> the messages looked like errors to my addled eyes). This system is on a >> different network, so getting the file transferred would take me about >> 24 hours. Is there something I can get that'll tell you what you need >> but is plaintext? >> > > Ok, that's fine. > > Try this. Set ra_plugin to dogtag in /etc/ipa/default.conf. This will let > it get past the error and it should install a CA. I'm trying to think worst > case scenario what it might do and I'm not coming up with anything. I think > the worst that happens is that adding a CA fails later. > > rob > > >> I tried this and hope this subset of information is helpful: >> >> # openssl pkcs12 -in cacert.p12 -out cacert.pem.bdw -cacerts -nokeys >> # cat cacert.pem.bdw >> Bag Attributes: >> subject=/O=FOO.NET/CN=**Certificate <http://FOO.NET/CN=Certificate> < >> http://FOO.NET/CN=Certificate**> Authority/ >> issuer=/O=FOO.NET/CN=**Certificate <http://FOO.NET/CN=Certificate> < >> http://FOO.NET/CN=Certificate**> Authority >> >> -BEGIN CERTIFICATE- >> MIIDgzCCA... >> ...Iwk4r >> -END CERTIFICATE- >> # openssl pkcs12 -in cacert.p12 -out cert.pem.bdw -clcerts -nokeys >> # cat cert.pem.bdw >> Bag Attributes: >> localKeyID: 82 81 2D 6E 5C 13 43 9A 5F BB C8 4D F5 6B DE 6C A7 2E 53 >> 88 >> friendlyName: caSigningCert cert-pki-ca >> subject=/O=FOO.NET/CN=**Certificate <http://FOO.NET/CN=Certificate> < >> http://FOO.NET/CN=Certificate**>
Re: [Freeipa-users] Fwd: Fwd: Fwd: Scorched earth
On Fri, Aug 30, 2013 at 5:03 AM, Petr Viktorin wrote:
> On 08/30/2013 10:23 AM, Bret Wortman wrote:
>
>> Morning update. I made the change Rob suggested to
>> /etc/ipa/default.conf, which appeared to work, but didn't quite. It
>> asked me to back out the whole server installation and start over:
>>
>> [ipamaster2]# ipa-ca-install --skip-conncheck
>> replica-info-ipamaster2.foo.**net.gpg
>> Directory Manager (existing master) password:
>>
>> COnfiguring certificate server (pki-tomcatd): Estimated time 3 minutes
>> 30 seconds
>>[1/16]: creating certificate server user
>>[2/16]: configuring certificate server instance
>> ipa : CRITICAL failed to configure ca instance Command
>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exit
>> status 1
>>
>> Your system may be partly configured.
>> Run/usr/sbin/ipa-server-**install --uninstall to clean up.
>>
>
> Can you look into /var/log/ipareplica-ca-**install.log? It should have
> more information on what caused pkispawn to fail.
>
> Here's what it looks like:
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2013-08-30T07:37:24Z DEBUG stderr=pkispawn : WARNING .. unable to
validate security domain user/password through REST interface. Interface
not available
pkispawn : ERROR.. Exception from Java Configuration Servlet:
Failed to obtain installation token from security domain:
java.lang.NullPointerException
2013-08-30T07:37:24Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exist status
1
2013-08-30T07:37:24Z INFO File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
619, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 182, in main
config, dogtag_master_ds_port, postinstall=True)
:
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 744, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2013-08-30T07:37:24Z INFO The ipa-ca-install command failed, exception:
RuntimeError: Configuration of CA Failed
> Configuration of CA failed.
>> [ipamaster2]#
>>
>> Which uninstallation & cleanup I did.
>>
>> Now, when trying to re-install the
>> replica file:
>>
>> [ipamaster2]# ipa-replica-install --setup-dns --no-forwarders --setup-ca
>> /var/lib/ipa/replica-info-**ipamaster2.foo.net.gpg
>> Directory manager (existing master) password:
>>
>> Run connection check to master
>> Check connection from replica to remote master 'ipamaster.foo.net
>> <http://ipamaster.foo.net>':
>>
>> Directory Service: Unsecure port (389): OK
>> Directory Service: Secure port (686): OK
>> Kerberos KDC: TCP (88): OK
>> Kerberos Kpasswd: TCP (464): OK
>> HTTP Server: Unsecure port (80): OK
>> HTTP Server: Secure port (443): OK
>>
>> The followign list of ports use UDP protocol and would need to be
>> checked manually:
>> Kerberos KDC: UDP (88): SKIPPED
>> Kerberos Kpasswd: UDP (464): SKIPPED
>>
>> Connection from replica to master is OK.
>> Start listening on required ports for remote master check
>> Get credentials to log in to remote master
>> ad...@foo.net <mailto:ad...@foo.net> password:
>>
>>
>> Check SSH connection to remote master
>> Execute check on remote master
>> Check connection from master to remote replica 'ipamaster2.foo.net
>> <http://ipamaster2.foo.net>':
>>
>> Directory Service: Unsecure port (389): OK
>> Directory Service: Secure port (686): OK
>> Kerberos KDC: TCP (88): OK
>> Kerberos KDC: UDP (88): OK
>> Kerberos Kpasswd: TCP (464): OK
>> Kerberos Kpasswd: UDP (464): OK
>> HTTP Server: Unsecure port (80): OK
>> HTTP Server: Secure port (443): OK
>>
>> Connection from master to replica is OK.
>>
>> Connection check OK
>> The host ipamaster2.foo.net <http://ipamaster2.foo.net> already exists
>>
>> on the master server.
>> You should remove it before proceeding:
>> % ipa host-del ipamaster2.foo.net <http://ipamaster2.foo.net>
>>
>> ipa : ERRORCould not resolve hostname ipamaster.foo.net
>> <http://ipamaster.foo.net> using DNS Clients may not function properly.
>>
>> Please check your DNS setup. (Note that this check queries IPA DNS
>> directly and ignores /etc/hosts.)
>>
[Freeipa-users] Exporting data?
What's the right venue for making a suggestion? In particular, I'd like to toss out there that it would be really nice to be able to export, at a minimum, DNS and user data from IPA in the form of a zone file and a passwd/shadow file pair. I realize there might be security implications to the latter, and masking out passwords might be advisiable. And there's no easy way, necessarily, to get out sudo information. But having DNS and user details would at least permit a sysadmin having major issues (like I have been for the past two weeks) to get up and running in some form, using puppet or some other tool to distribute flat files with named running against a static zone file, or even to migrate off IPA if absolutely necessary. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Exporting data?
I guess what I was looking for was something really easy -- like a pushbutton in the UI. I've got 20+ zones, so even doing this means scripting to keep from missing something. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Sep 4, 2013 at 9:26 AM, Petr Spacek wrote: > On 4.9.2013 15:04, Bret Wortman wrote: > >> What's the right venue for making a suggestion? In particular, I'd like to >> toss out there that it would be really nice to be able to export, at a >> minimum, DNS and user data from IPA in the form of a zone file and a >> passwd/shadow file pair. >> >> I realize there might be security implications to the latter, and masking >> out passwords might be advisiable. And there's no easy way, necessarily, >> to >> get out sudo information. But having DNS and user details would at least >> permit a sysadmin having major issues (like I have been for the past two >> weeks) to get up and running in some form, using puppet or some other tool >> to distribute flat files with named running against a static zone file, or >> even to migrate off IPA if absolutely necessary. >> > > Hello, > > for DNS you can use normal zone transfer. Just configure IPA zone to allow > zone transfer to an IP address (localhost means 'localy to IPA server') and > use standard DNS tools, e.g. dig: > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > That is all you need for DNS, you have the standard zone file. > > > I believe that you can use SSSD (with enumeration enabled) to run "getent > passwd > /root/passwd.bck". I have no idea how it works with shadow > map/password. Try to ask > sssd-users@lists.fedorahosted.**org > . > > -- > Petr^2 Spacek > > __**_ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Exporting data?
My problems all seem to be with replication (see the threads with subjects "Scorched earth" and "Replication woes"), and Rob has found an engineer willing to look at log files for me. My problem is in getting the log files over to you for analysis. The system I'm working with is on a private network, so getting the logs off isn't trivial. In my case I'm looking for a way to basically start over with as little heartache as possible, and so far, after two weeks of trial and error, we're no closer to being restarted than we were, well, two weeks ago. My customer is getting antsy and I need to return our network to fully operational within the next 24-48 hours or I'm going to have to nuke it and start all over, which I know involves re-registering every single system with the new master (because it'll be a new CA) and entering the new users again, and setting up DNS over again. Which is why I was looking for a way to export as much as possible right now so I can re-import in case the worst happens and I have to nuke all my IPA servers and start over from scratch. I realize that no one can debug without logs and detailed information. It's just taken a long time to get to where I am, and it takes a full 24 hours or more for me to respond to any request for more detail. In other words, I'm trying to leave my system as it is so we can try to solve the problem it has and minimize the recovery effort, but I have to balance that against my need to get my network operational again, and we're having many, many problems with SSH, SSSD and other services since we don't have a single IPA server in the mix that's fully functional right now. My master is crippled with replication requests and the one good copy I made couldn't get the CA transfer to work. Frustrating for you because I can't always give quick data. Frustrating all around. But we'll get through it one way or the other. I hope to have the latest batch of logs over for analysis later this morning. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Sep 4, 2013 at 9:40 AM, Dmitri Pal wrote: > On 09/04/2013 09:26 AM, Petr Spacek wrote: > > On 4.9.2013 15:04, Bret Wortman wrote: > >> What's the right venue for making a suggestion? In particular, I'd > >> like to > >> toss out there that it would be really nice to be able to export, at a > >> minimum, DNS and user data from IPA in the form of a zone file and a > >> passwd/shadow file pair. > >> > >> I realize there might be security implications to the latter, and > >> masking > >> out passwords might be advisiable. And there's no easy way, > >> necessarily, to > >> get out sudo information. But having DNS and user details would at least > >> permit a sysadmin having major issues (like I have been for the past two > >> weeks) to get up and running in some form, using puppet or some other > >> tool > >> to distribute flat files with named running against a static zone > >> file, or > >> even to migrate off IPA if absolutely necessary. > > > > Hello, > > > > for DNS you can use normal zone transfer. Just configure IPA zone to > > allow zone transfer to an IP address (localhost means 'localy to IPA > > server') and use standard DNS tools, e.g. dig: > > > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > > > That is all you need for DNS, you have the standard zone file. > > > > > > I believe that you can use SSSD (with enumeration enabled) to run > > "getent passwd > /root/passwd.bck". I have no idea how it works with > > shadow map/password. Try to ask sssd-us...@lists.fedorahosted.org. > > > And to add to it: > IPA does not keep password in clear or the hashes that are used in > passwd and shadow files for security reasons so it can't generate these > files as you suggest. > > It is unclear what the problems are that you are facing and what made > you get back to local files. > I agree with Petr that SSSD has a lot of bells and whistles to make your > client experience smooth and help you recover from any server side > problems you might have. > > But may be we are missing something and there is something we can do. > If you can describe the problem you are facing we might be able to > suggest a solution. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > --- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
