On 07/31/2017 08:44 PM, Mark Haney via FreeIPA-users wrote:
On 07/24/2017 10:25 PM, Fraser Tweedale wrote:
Could you provide more of the /var/log/pki/pki-tomcat/ca/debug log
file (ideally the whole thing)?
Also to clarify: ``ipa-replica-install --setup-ca'' installs a new
replica including the
On 08/01/2017 12:54 AM, bdlamprecht--- via FreeIPA-users wrote:
I've been trying to get this to work for a few days now all to no avail...
I'm been running "FreeIPA, version: 4.3.1" for a few months now to authenticate
a number of VMs that I grew tired of managing permissions on a individual ba
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
On 07/31/2017 11:34 AM, Rob Crittenden wrote:
Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had apparently had
updates run but had not been restarted. ipactl says pki-tomcatd would
not start
On 08/01/2017 03:26 AM, None via FreeIPA-users wrote:
I'm really at a loss on this one.
I have a bunch of old server images (from 2 months ago) that can run
ipa-client-install just fine. When I created a new image, though, I get
this error (from the install logs):
DEBUG flushing ldap://ipa.s
I have the same error.
I established two-way trust with AD which went fine.
Authentication with Kerberos to AD is working.
Since I have one test FreeIPA which is working correctly (relatively) I
compared logs and pinpointed problem to strange LDAP search which is FreeIPA
sending to DC:
(&(sAMAcco
Hey,
I checked the logs and found this:
conn=3295 op=3 SRCH
base="cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=services,dc=example"
scope=2 filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey
cacertificate;binary ipaKeyTrust ipaCertIssuerS
Slight update: I tried precreating /etc/ipa/ca.crt, and when running the
install, I get the same Python error I did before:
File "/usr/sbin/ipa-client-install", line 3099, in
sys.exit(main())
File "/usr/sbin/ipa-client-install", line 3080, in main
rval = install(options, env, fstore,
On 08/01/2017 03:26 AM, Florence Blanc-Renaud wrote:
another user hit the same problem as you (ipa-replica-install
--setup-ca fails during pkispawn and the PKI debug log shows an error
related to updateNumberRange). He managed to workaround the issue by
un-enrolling the failing replica and re
On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
On 07/31/2017 11:34 AM, Rob Crittenden wrote:
Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had apparently had
updates run but had not be
Further update: I'm pretty sure I found out the problem.
Basically, my old server is running pyasn1==0.2.3 and the new one has
pyasn1==0.3.1. Per the pyasn1 documentation, they made a breaking change
to __init__ and a few other functions in 0.3.1, so I guess FreeIPA 4.3.1
isn't compatible with th
None via FreeIPA-users wrote:
> Further update: I'm pretty sure I found out the problem.
>
> Basically, my old server is running pyasn1==0.2.3 and the new one has
> pyasn1==0.3.1. Per the pyasn1 documentation, they made a breaking change
> to __init__ and a few other functions in 0.3.1, so I guess
Hello everyone,
I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a series of
unfortunate events which resulted in the entire cluster being offline for a
matter of a couple weeks during which the certificate in /etc/httpd/alias
expired. I rolled back the clocks on all of the s
I've got a server with multiple replication agreements that just went
toes up. The tail end of the startup output says:
Aug 01 14:21:22 zsipa systemd[1]: dirsrv@DG-NET.service: main process
exited, code=exited, status=1/FAILURE
Aug 01 14:21:22 zsipa systemd[1]:
Aug 01 14:21:22 zsipa systemd[1]
On 08/01/2017 03:11 PM, Ian Harding wrote:
On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
On 07/31/2017 11:34 AM, Rob Crittenden wrote:
Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that h
Stupid return key.
I solved this and was trying to delete the email. Sorry for the spam.
On 08/01/2017 10:28 AM, Bret Wortman via FreeIPA-users wrote:
I've got a server with multiple replication agreements that just went
toes up. The tail end of the startup output says:
Aug 01 14:21:22 zsi
ok thats great news! But I just want to make sure even if the server IS ALREADY
DOWN due to this bug we can still manually edit the database (dse.ldif) for
this value and then bring up the processes. Would that work?
___
FreeIPA-users mailing list -- fr
I'd appreciate any advise on how to even troubleshoot this further. KRB_TRACE
is the only utility that I'm aware to assist with this.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le.
On 08/01/2017 04:42 PM, pgb 205 via FreeIPA-users wrote:
ok thats great news! But I just want to make sure even if the server IS ALREADY
DOWN due to this bug we can still manually edit the database (dse.ldif) for
this value and then bring up the processes. Would that work?
yes, that should wo
The resolv.conf is identical on both systems, DNS is solid. SRV records are
functioning as expected.
I looked at everything and failing to find a resolution, sought advice here
on the board.
Now that these are out of sync, how would one manually initiate a sync? I
haven’t found this in t
also, any repercussions to leaving the CSN number skewed like this long-term(as
nsslapd -ignore-time-skew will only mask the problem). I take it that there
aren't. We'll just get log messages but no ill effects otherwise.
thank you
___
FreeIPA-users m
On 08/01/2017 03:11 PM, Mark Haney via FreeIPA-users wrote:
On 08/01/2017 03:26 AM, Florence Blanc-Renaud wrote:
another user hit the same problem as you (ipa-replica-install
--setup-ca fails during pkispawn and the PKI debug log shows an error
related to updateNumberRange). He managed to wor
On 08/01/2017 11:01 AM, Florence Blanc-Renaud wrote:
Hi,
you can connect to IPA web UI on the server to revoke the cert:
https://server.ipadomain.com/ipa/ui, then navigate to Authentication >
Certificates, click on the certificate corresponding to the replica
which failed installation (CN=,o
On 08/01/2017 03:50 PM, Jason B. Nance via FreeIPA-users wrote:
Hello everyone,
I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a series of
unfortunate events which resulted in the entire cluster being offline for a
matter of a couple weeks during which the certificate in /e
On 08/01/2017 11:01 AM, Florence Blanc-Renaud wrote:
you can connect to IPA web UI on the server to revoke the cert:
https://server.ipadomain.com/ipa/ui, then navigate to Authentication >
Certificates, click on the certificate corresponding to the replica
which failed installation (CN=,o=DOM.
Yes, this information helped.
In summary, I needed to create a "Service Account" that my application could
bind to.
I'm not sure why as it was able to BIND just fine using my credentials, but
that is not a question for this group.
It took some trial and error to get it to work correctly, but I
On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 03:11 PM, Ian Harding wrote:
On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
On 07/31/2017 11:34 AM, Rob Crittenden wrote:
Ian Harding via FreeIPA-users wrote
On Tue, Aug 01, 2017 at 11:20:16AM -, Igor Sever via FreeIPA-users wrote:
> I have the same error.
> I established two-way trust with AD which went fine.
> Authentication with Kerberos to AD is working.
> Since I have one test FreeIPA which is working correctly (relatively) I
> compared logs a
Mark Haney via FreeIPA-users wrote:
> On 08/01/2017 11:01 AM, Florence Blanc-Renaud wrote:
>>
>> you can connect to IPA web UI on the server to revoke the cert:
>> https://server.ipadomain.com/ipa/ui, then navigate to Authentication >
>> Certificates, click on the certificate corresponding to the r
Ian Harding wrote:
> On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:
>> On 08/01/2017 03:11 PM, Ian Harding wrote:
>>> On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
>
>
> On 07/31/2017 11:34 AM, Rob Crittenden
We have observed the following situationreplication agreement between server1
and server2 exists
ipa-replica-manage list server2>server1
However some of the users, hosts etc that are added on server1 are not making
it to server2.
In sssd/error logs I can see the following which looks relevant:
Have a strange use case - this may be a mostly sssd.conf config question
I think ...
I've got a high performance computing grid running in AWS. The front-end
and user login nodes are managed IPA clients and things are working well
even for the complex AD topology we have with lots of child-dom
On 08/01/2017 12:03 PM, Rob Crittenden wrote:
Ian Harding wrote:
On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 03:11 PM, Ian Harding wrote:
On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
On 07/31/2017 1
The users in /etc/passwd have nothing to do with the users in IPA, you can
configure them to have the same UID / GID as the users in IPA, and you can
name them the way you want (ie, just the username without the domain
suffix). This will break in interesting ways if you need to sync updates to
the
33 matches
Mail list logo
