Scratch that. Decided to be daring and run "getcert resubmit -i" for
each cert (after verifying the first one worked), then shut ipa down,
advanced the date, re-enabled ntpd and started it back up. Looks clean.
On 04/29/2016 01:22 PM, Bret Wortman wrote:
Of course, I just remembered that the
Of course, I just remembered that the server still thinks it's April 4,
and I still have some certs that are expiring as of 4-17-16. Before I
screw anything else up, what's the RIGHT way to renew those certs and
move the server back to real time?
On 04/29/2016 01:07 PM, Bret Wortman wrote:
Hot damn! It's up and running. Web UI works. CLI works.
The chgrp did the trick.
Thank you Rob, Petr and Christian!
Bret
On 04/29/2016 01:04 PM, Rob Crittenden wrote:
Bret Wortman wrote:
We run with selinux disabled.
# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl
Bret Wortman wrote:
We run with selinux disabled.
# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting
We run with selinux disabled.
# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to
On 2016-04-29 18:17, Bret Wortman wrote:
> I'll put the results inline here, since they're short.
>
> [root@zsipa log]# ls -laZ /etc/httpd/
> drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
> drwxr-xr-x. root root system_u:object_r:etc_t:s0 ..
> drwxr-xr-x. root root
I'll put the results inline here, since they're short.
[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0 ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias
drwxr-xr-x. root root
On 2016-04-29 16:51, Bret Wortman wrote:
> It is contacting the correct machine. I tried again by IP with the same
> results.
>
> /etc/httpd/conf.d/ipa-pki-proxy.conf is dated May 20 2014.
>
> Web UI won't load. CLI won't respond either. Commands just hang.
>
> # netstat -ln | grep 443
> tcp6
It is contacting the correct machine. I tried again by IP with the same
results.
/etc/httpd/conf.d/ipa-pki-proxy.conf is dated May 20 2014.
Web UI won't load. CLI won't respond either. Commands just hang.
# netstat -ln | grep 443
tcp6 0 0 :::8443 :::* LISTEN
On 2016-04-29 16:08, Petr Vobornik wrote:
> On 04/29/2016 02:53 PM, Bret Wortman wrote:
>> Despite "ipactl status" indicating that all processes were running after
>> step 1, step 2 produces "Unable to establish SSL connection."
>>
>> Full terminal session is at http://pastebin.com/ZuNBHPy0
>
>
On 04/29/2016 02:53 PM, Bret Wortman wrote:
> Despite "ipactl status" indicating that all processes were running after
> step 1, step 2 produces "Unable to establish SSL connection."
>
> Full terminal session is at http://pastebin.com/ZuNBHPy0
Hm, it doesn't help me much.
Does it contact the
On 04/29/2016 02:53 PM, Bret Wortman wrote:
> Despite "ipactl status" indicating that all processes were running after
> step 1, step 2 produces "Unable to establish SSL connection."
>
> Full terminal session is at http://pastebin.com/ZuNBHPy0
>
> On 04/29/2016 07:29 AM, Petr Vobornik wrote:
>>
Despite "ipactl status" indicating that all processes were running after
step 1, step 2 produces "Unable to establish SSL connection."
Full terminal session is at http://pastebin.com/ZuNBHPy0
On 04/29/2016 07:29 AM, Petr Vobornik wrote:
On 04/29/2016 12:03 PM, Bret Wortman wrote:
The date
On 04/29/2016 12:03 PM, Bret Wortman wrote:
> The date change was due (I think) to me changing the date back to 4/1
> yesterday, though I left it there and haven't updated it again until
> this morning, when I went back to 4/1 again.
>
> I put the results of the commands you requested at
>
The date change was due (I think) to me changing the date back to 4/1
yesterday, though I left it there and haven't updated it again until
this morning, when I went back to 4/1 again.
I put the results of the commands you requested at
https://pastebin.com/s7cHAh6R. Thanks for your help, Petr.
comments inline
On 04/28/2016 06:30 PM, Bret Wortman wrote:
> Look, I'll be honest. When IPA is in this much of a knot, I don't know how to
> do
> the simplest things with its various components. For example, I've no clue
> how
> to search the ldap database for anything. Or even how to
Okay, I ran 'ldapsearch -x -h zsipa -p 389 -b 'ou=people,o=ipaca' and
dumped that to a file. I'm still not clear on what I'm supposed to be
looking for in the output, though.
The result of systemctl | grep dirsrv@ was pretty uninformative. If the
answer was "dirsrv", then I don't find that in
Look, I'll be honest. When IPA is in this much of a knot, I don't know
how to do the simplest things with its various components. For example,
I've no clue how to search the ldap database for anything. Or even how
to authenticate since Kerberos isn't running. IPA has sheltered me from
ldap for
Okay. I got hung up on the first link doing some checking using
pki-server. I don't see any reference to ldapsearch in either message,
but I'll do what I can.
On 04/28/2016 12:04 PM, Petr Vobornik wrote:
On 04/28/2016 05:49 PM, Bret Wortman wrote:
My system shows pki-server is installed and
On 04/28/2016 05:49 PM, Bret Wortman wrote:
> My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
> have the pki-server binary itself. Will reinstalling this rpm hurt me in
> any way? Without it, I'm not sure how to check my system against the
> messages you provided below.
My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
have the pki-server binary itself. Will reinstalling this rpm hurt me in
any way? Without it, I'm not sure how to check my system against the
messages you provided below.
On 04/28/2016 11:07 AM, Petr Vobornik wrote:
On
On 04/28/2016 04:07 PM, Bret Wortman wrote:
> Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't
> work, but I got something new and interesting in the debug log, which I've
> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out
> which doesn't
Okay. This morning, I turned back time to 4/1 and started up IPA. It
didn't work, but I got something new and interesting in the debug log,
which I've posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk
came pouring out which doesn't happen when I'm set to real time. Is
/this/
I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
looks logical to me, but I can't spot anything that looks like a root
cause error. The selftests are all okay, I think. The debug log might
have something, but it might also just be complaining about ldap not
being up because
Bret Wortman wrote:
So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?
I don't believe there is a way.
We have a replica that's still up and running and we've
Was this at all informative?
On 04/26/2016 02:06 PM, Bret Wortman wrote:
On 04/26/2016 01:45 PM, Rob Crittenden wrote:
Bret Wortman wrote:
I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.
I mistyped one of these -- the 2016-03-11
On 04/26/2016 01:45 PM, Rob Crittenden wrote:
Bret Wortman wrote:
I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.
I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.
As for the
Bret Wortman wrote:
I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.
I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.
As for the unknowns, the first says status: CA_REJECTED and
I should also note that /var/log/dirsrv/slapd-PRIVATE-NET/errors ends
with a series of "csngen_new_csn - Warning: too much time skew (-2153860
secs). Current seqnum=1" errors.
On 04/26/2016 12:57 PM, Bret Wortman wrote:
I think I've found a deeper problem, in that I can't update these
I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.
I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.
As for the unknowns, the first says status: CA_REJECTED and the error
says
On 04/26/2016 06:00 PM, Bret Wortman wrote:
> # getcert list | grep expires
> expires: 2018-04-02 13:04:51 UTC
> expires: 2018-04-02 13:04:31 UTC
> expires: unknown
> expires: 2016-04-17 18:19:19 UTC
> expires: 2016-04-17 18:19:18 UTC
> expires: 2016-04-17 18:19:19
# getcert list | grep expires
expires: 2018-04-02 13:04:51 UTC
expires: 2018-04-02 13:04:31 UTC
expires: unknown
expires: 2016-04-17 18:19:19 UTC
expires: 2016-04-17 18:19:18 UTC
expires: 2016-04-17 18:19:19 UTC
expires: 2016-04-01 20:16:39 UTC
expires: 2016-04-17
On 04/26/2016 03:26 PM, Bret Wortman wrote:
> On our non-CA IPA server, this is happening, in case it's related and
> illustrative:
>
> # ipa host-del zw113.private.net
> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
> certificate/key database is in an old, unsupported
33 matches
Mail list logo
