On 1.9.2014 12:16, Dmitri Pal wrote:
On 09/01/2014 12:05 PM, Martin Kosek wrote:
On 09/01/2014 07:50 AM, Dmitri Pal wrote:
On 08/29/2014 09:32 PM, Matthew Sellers wrote:
Hi Everyone!
I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to
send notifies to non-IPA slaves,
Martin Kosek wrote:
On 09/03/2014 09:02 AM, Martin Kosek wrote:
In the meantime, you can use the workaround that Rob sent, you would just
need
to delete it again when the fix is in, so that the permissions do not step on
each other.
Actually, wait a minute. I think Rob's ACI example may
On 09/03/2014 03:08 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 09/03/2014 09:02 AM, Martin Kosek wrote:
In the meantime, you can use the workaround that Rob sent, you would just
need
to delete it again when the fix is in, so that the permissions do not step
on
each other.
Greetings,
I'm running freeipa 3.0 with multimaster between 3 machines. The first
system, the original installation machine and thus the keepers of the
CA, etc, is not replicating with the other two. The other two are fine.
Additionally, the original machine is no longer using the freeIPA
running
That worked, but having issues get it to work with the OSX Directory
Utility.
I'm wondering if it's because when you go against the OU normally it's
returning more info about the user versus what's being returned from the
compat view I'm going to experiment with the attributes it's returning
and
Great! Btw +1 for running on IPA 3.3.3, it has much more to offer than
RHEL/CentOS 6.x one.
Martin
On 09/03/2014 06:08 PM, Zip Ly wrote:
@Martin
Ah that explains everything. We were using centos 6.5 + ipa 3.0.0
Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted.
@Martin
Ah that explains everything. We were using centos 6.5 + ipa 3.0.0
Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted.
Thank all for the help!
On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek mko...@redhat.com wrote:
On 09/02/2014 10:42 AM, Zip Ly wrote:
@Martin
user-find sees a user but user-del cannot remove it. What can I do?
Thanks.
Regards,
Ron
[root@ipa]# ipa user-find --login phys210e
--
1 user matched
--
User login: phys210e
First name: Testing
Last name: Phys210
Home directory: /home2/phys210e
Login shell:
Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL
operation and see what was the error code that DS gave when it refused to
delete the user?
Martin
On 09/03/2014 06:18 PM, Ron wrote:
user-find sees a user but user-del cannot remove it. What can I do?
Thanks.
Regards,
Martin Kosek wrote:
Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL
operation and see what was the error code that DS gave when it refused to
delete the user?
Were I to guess the issue is that this is a replication conflict entry.
If you do:
# ipa user-show --all
Chris Whittle wrote:
That worked, but having issues get it to work with the OSX Directory
Utility.
I'm wondering if it's because when you go against the OU normally it's
returning more info about the user versus what's being returned from the
compat view I'm going to experiment with the
Jim Kinney wrote:
Greetings,
I'm running freeipa 3.0 with multimaster between 3 machines. The first
system, the original installation machine and thus the keepers of the
CA, etc, is not replicating with the other two. The other two are fine.
Additionally, the original machine is no longer
On Wed, 2014-09-03 at 13:48 -0400, Rob Crittenden wrote:
Jim Kinney wrote:
Greetings,
I'm running freeipa 3.0 with multimaster between 3 machines. The first
system, the original installation machine and thus the keepers of the
CA, etc, is not replicating with the other two. The other
Thanks Rob for the explanation!
I think I have it working, I just have to test a machine and verify.
On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden rcrit...@redhat.com wrote:
Chris Whittle wrote:
That worked, but having issues get it to work with the OSX Directory
Utility.
I'm
Here is what is in the /var/log/dirsrv/slapd-YOUR-REALM/access... logfile:
conn=17342 fd=86 slot=86 connection from 142.103.xxx.xx to 142.103.xxx.xx
conn=17342 op=0 BIND dn= method=sasl version=3 mech=GSSAPI
conn=17342 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in
progress
conn=17342
Ott, Dennis wrote:
I may need a little more direction here.
The output from getcert list-cas does not contain the string 'ca_renewal'.
What does this indicate?
I don't have a 2 - 3 updated server handy so I'm going on best guesses
from reading the code. It is probably ok. You really just
Ron wrote:
And here is the result of the user-show command:
[root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e
ipa: ERROR: phys210e: user not found
Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e
user-show is going to have the same issue as user-delete.
[root@ipa]# ipa user-find --all --raw --login phys210e | grep dn:
dn:
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca
On 09/03/2014 12:26 PM, Rob Crittenden wrote:
Ron wrote:
And here is the result of the user-show command:
[root@ipa
Success here is my LDIF if anyone needs to do this with a MAC
dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config
objectClass: top
objectClass: extensibleObject
cn: Mac Users
schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com
schema-compat-search-filter:
By the way, all three replica servers show the same:
[root@ipa]# ipa user-find --all --raw --login phys210e | grep dn:
dn:
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca
[root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn:
On 09/03/2014 02:44 PM, Ron wrote:
By the way, all three replica servers show the same:
[root@ipa]# ipa user-find --all --raw --login phys210e | grep dn:
dn:
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca
[root@ipa01]# ipa user-find
The output of getcert list-cas from the replica is below. It contains both the
'renew' and the 'retrieve' items.
As previously stated, the services are not running on the replica. I have been
nervous about starting them; not wanting to impact the functional master. But,
it is sounding like
So in my case I would need to do the Renaming an Entry with a
Multi-Valued Naming Attribute procedure on both IPA01 and IPA02?
Would another way of doing this be to remove IPA01 (and later IPA02) as
a replication-master and then re-add it? I ask this because I have
about 70 of these entries. I
23 matches
Mail list logo
