[Freeipa-users] search filter with non-existent attribute
hi, This works: $ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn (|(mail=admin*)(uid=admin)) uid dn: uid=admin,cn=users,cn=accounts,dc=cxn uid: admin This not: $ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn (|(aaa=admin*)(uid=admin)) uid $ If there is search filter with non-existent attribute there is no result. Is that intentional? In CentOS 6.6 it worked just fine. 10x tamas -- 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] Antwort: clean-run doesn't work
On 06/19/2015 11:12 AM, Christoph Kaminski wrote: for this problem you can see the thread Haunted servers? here on ml. There is a solution from me for this but it doesnt work 100% :/ I would rather rerun the replication. we have a Ticket @Red Hat for this problem, (https://access.redhat.com/support/cases/#/case/01429034if you have rh support) But is really sad/silly how RH support works (read the whole ticket). Unfortunately I don't have access there. In fact we have a bigger issue here, but I don't know, if it's related. The whole story is the following: I migrated (ipa migrate-ds) about 150 users between two ldap databases. Old one was v3.0 (centos 6.6), the new one is v4.1 (centos 7.1). After migrating users I switched off old servers and replaced centos 6.6 machines with centos 7.1. Than replica servers was installed. One replicas had to be reinstalled one time, because the replica process was hanged up for some reason. Now two servers (not the reinstalled one, but the original master and one other) crash quite frequently with sigsegv. It's like something is leaking. I tuned the the nsslapd-cachememsize value of the following config entries: dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config dn: cn=config, cn=ldbm database, cn=plugins, cn=config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config It helped a lot, but not enough. I had seen this before years ago, when I started using ipa. It was on Fedora and the bleeding edge Freeipa version. At that time I switched to CentOS because I trusted more in the well tested enterprise distribution. But now it's not an option:) Any suggestion? Thanks, tamas -- 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] Antwort: Re: Antwort: clean-run doesn't work
On 06/22/2015 10:49 AM, Christoph Kaminski wrote: In my particular case I'm interested, whether it can crash servers. Does it for you? I don't see it in that thread. tamas yes... we has had a really often a crash on virtual machines installations. On bare metal we had 2-3x a crash. That was the reason for us to destroy all IPA VM's. There seems to be an IO issue on VM's with IPA (rhev virtualisation here). You can see it extremly if you turn the debug level higher. Thanks! tamas -- 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] Antwort: clean-run doesn't work
On 06/22/2015 10:31 AM, Christoph Kaminski wrote: Unfortunately I don't have access there. In fact we have a bigger issue here, but I don't know, if it's related. The whole story is the following: I migrated (ipa migrate-ds) about 150 users between two ldap databases. Old one was v3.0 (centos 6.6), the new one is v4.1 (centos 7.1). After migrating users I switched off old servers and replaced centos 6.6 machines with centos 7.1. Than replica servers was installed. One replicas had to be reinstalled one time, because the replica process was hanged up for some reason. Now two servers (not the reinstalled one, but the original master and one other) crash quite frequently with sigsegv. It's like something is leaking. I tuned the the nsslapd-cachememsize value of the following config entries: dn: cn=changelog,cn=ldbm database,cn=plugins,cn=config dn: cn=config, cn=ldbm database, cn=plugins, cn=config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config It helped a lot, but not enough. I had seen this before years ago, when I started using ipa. It was on Fedora and the bleeding edge Freeipa version. At that time I switched to CentOS because I trusted more in the well tested enterprise distribution. But now it's not an option:) Any suggestion? As I have mentioned above, see at the Haunted servers? thread here on list. There are solutions etc for a similiar problem. This is all there what I know about this problem. (The RH Ticket has far less informations and not really a solution for it (sad :/ )) In my particular case I'm interested, whether it can crash servers. Does it for you? I don't see it in that thread. tamas -- 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] Antwort: Re: Antwort: clean-run doesn't work
Fascinating. Can you Red Hat guys reproduce this in you test environment? Thanks, tamas On 06/22/2015 11:42 AM, Alexander Frolushkin wrote: Hello everyone. I can confirm this on VMWare, recently we have the similar issue when enabled dirsrv debug on 4 of our 19 IPA servers L WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 *From:*freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Christoph Kaminski *Sent:* Monday, June 22, 2015 2:50 PM *To:* Tamas Papp *Cc:* freeipa-users@redhat.com *Subject:* [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't work In my particular case I'm interested, whether it can crash servers. Does it for you? I don't see it in that thread. tamas yes... we has had a really often a crash on virtual machines installations. On bare metal we had 2-3x a crash. That was the reason for us to destroy all IPA VM's. There seems to be an IO issue on VM's with IPA (rhev virtualisation here). You can see it extremly if you turn the debug level higher. Greetz Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] Antwort: Re: Antwort: clean-run doesn't work
On 06/22/2015 02:20 PM, thierry bordaz wrote: On 06/22/2015 11:50 AM, Tamas Papp wrote: Fascinating. Can you Red Hat guys reproduce this in you test environment? Most of my tests are on RHEV with RHEL 7.1, I have not seen a crash of DS. About the test case, you installed a server+replicas (version ?), then turn on errorlog-level (do you remember what level). All are CentOS 7.1 (IPA 4.1). I didn't touch erorlog-level. That would slow down the DS instance and fill errors log. Then you hit extremely frequently a crash. Do you remember what kind of the load search/mod/add/del ? We currently see about 1 crash / day. add/del/mod: basically 0 search: We're investigating, on some servers we probably didn't enabled nscd for caching. In that case they probably received quite high load. otherwise it's also should be extremely low. We don't use kerberos, do not join clients, just the ldap feature. Thanks, tamas -- 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] clean-run doesn't work
hi All,
$ ipa-replica-manage list-ruv
unable to decode: {replica 6} 55832e8e00030006 55832e8e00030006
ipa31.bph.cxn:389: 8
ipa12.bpo.cxn:389: 5
ipa32.bph.cxn:389: 7
ipa11.bpo.cxn:389: 3
ipa.cxn.com:389: 4
$ ipa-replica-manage clean-ruv 6
unable to decode: {replica 6} 55832e8e00030006 55832e8e00030006
Replica ID 6 not found
Background: yesterday I deployed this ldap cluster and migrated users
to. Everything worked fine, except one time I had to recreate the
replication, because the process didn't finish successfully (due to a
closed firewall port). After the command 'ipa-server-install
--uninstall' it worked like a charm.
But now I see the above on the replica master.
in addition, I can see numerous and various errors on other replicas, eg:
[19/Jun/2015:10:53:43 +0200] attrlist_replace - attr_replace
(nsslapd-referral, ldap://ipa.cxn.com:389/o%3Dipaca) failed.
There is in the mailing list archives, that the solution is running
clean-run.
Thanks,
tamas
--
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] migrating 3.0 - 4.1: passwords not migrated?
On 06/10/2015 03:33 PM, Martin Kosek wrote: On 06/10/2015 03:18 PM, Tamas Papp wrote: hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? My guess is that their Kerberos key is also migrated. The key is not valid on the new installation as also Kerberos master key is different. So I would suggest stripping the users from their Kerberos attributes first. Some advise here: https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Hmm, this should be all. Except if the users were members of for examples roles or privileges, you would need to migrate that membership too as mere presence of memberOf attribute in the sys account will not be enough. hi, Eventually this still doesn't work as expected. After migrating users they cannot login to the webui. However after logging successfully in without kerberos, in other words in a service bound to the ldap server they can login fine on the webui too. It's enough in our case, but normally it's not OK, I guess. 10x tamas -- 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] Is something.local hostname possible
I can't answer you, but don't use .local, it conflicts with avahi.
--
Sent from mobile
On June 12, 2015 17:45:52 James Benson james.ben...@utsa.edu wrote:
Hi all,
I'm trying to duplicate freeIPA on a local host but I keep on getting
errors, primarily a RuntimeError('CA did not start in %%ss' %timeout).
Has anyone tried this before and succeeded or have suggestions?
Thanks
James
--
--
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
--
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] migrating 3.0 - 4.1: passwords not migrated?
On 06/10/2015 03:35 PM, Martin Kosek wrote: On 06/10/2015 03:32 PM, Christopher Lamb wrote: Hi Tamas I think the general advice is to replicate rather than to migrate. I am sure Martin K will jump in on this. Yes :-) However some weeks ago, when doing a very similar move to yours, we chose to migrate (we were misled by some very old FreeIPA docus that have since been archived). In our case passwords were successfully migrated, so the users were able to use the same user / password combo as before. I will see if I can dig out the migrate command we used at the time. Did you use the migration command advised in https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA ? hi Martin, https://www.freeipa.org/page/Howto/Migration#Upgrading_to_new_FreeIPA_release I would be satisfied with this procedure. However, earlier you (actually Dmitri) posted a different one: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html Which is the right one? In my opinion the second one is too complicated, I would rather choose 'ipa migrate-ds' (we don't have machine accounts). Thanks, tamas -- 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] migrating 3.0 - 4.1: passwords not migrated?
hi, Currently there are CentOS 6.5 servers and IPA 3.0. The goal is migrating users to CentOS 7.1 and IPA 4.1. This is the command I use: $ ipa migrate-ds ldap://ipa11 --user-container=cn=users,cn=accounts,dc=foo --group-container=cn=groups,cn=accounts,dc=foo --base-dn=dc=foo --with-compat ~/.pw.manager Users are migrated successfully but password must be reset, otherwise they cannot logon. Any idea, what's going on? I also have a bonus question. How can I migrate the cn=sysaccounts,cn=etc,dc=cxn tree? Do I need to export/import it as ldif and that's all? Thanks, tamas -- 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] LDAP authentication for JIRA using FreeIPA
Yes, it's fine. -- Sent from mobile On June 8, 2015 18:47:41 Christopher Lamb christopher.l...@ch.ibm.com wrote: Hi All we are interested to know if anybody has succeeded (or for that matter failed) in using FreeIPA to provide user authentication for Atlassian products such as JIRA or Confluence? Somewhere in an Atlassian ticket I saw that FreeIPA is not officially supported, so I guess that should set our expectations . If anyone has succeeded, then of course any tips on how best to do so would be fantastic! Thanks Chris -- 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 -- 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] password expiration
On 06/02/2015 10:30 AM, Sandor Juhasz wrote: It is confirmed, the password policy was changed with password expiration beyond 2038. Question is, how can we restore the pw policy without a working admin user? hi Martin, Additional info: ipa-server-3.0.0-42.el6.centos.x86_64 CentOS 6.6 Thanks, tamas -- 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] password expiration
On 06/02/2015 02:00 PM, Martin Kosek wrote: On 06/02/2015 11:42 AM, Tamas Papp wrote: On 06/02/2015 10:35 AM, Martin Kosek wrote: You would need to do the modifications as Directory Manager or other user in adminsgroup. To resolve this, you would need manually fix admin entry attribute krbPasswordExpiration to some future date, kinit as admin and then fixing the global policy with some sane value (pwpolicy-mod). How can this work? It forces me to change the password again after kinit. You would need to use ldapmodify and bind as Directory Manager to do this, you cannot change krbPasswordExpiration with IPA user (IIRC). I mean I changed that entry with ldapmodify, than kinit admin and it forced me to change the password, GOTO 1:) But if I understand correctly I should have changed other attribute as well;) For some reason another user with admin rights was able to login and we were able to fix the policy so far. With that other admin user, you can simply call ipa passwd on the original admin, assign temporary password and have him change it on the first login. Yes, everything is back to normal operation now. Thanks for your prompt attention! tamas -- 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] password expiration
On 06/02/2015 10:35 AM, Martin Kosek wrote: You would need to do the modifications as Directory Manager or other user in adminsgroup. To resolve this, you would need manually fix admin entry attribute krbPasswordExpiration to some future date, kinit as admin and then fixing the global policy with some sane value (pwpolicy-mod). How can this work? It forces me to change the password again after kinit. For some reason another user with admin rights was able to login and we were able to fix the policy so far. Cheers, tamas -- 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] password expiration
hi All, I'm stuck: $ kinit admin Password for admin@CXCLIENTS: kinit: Password incorrect while getting initial credentials [root@ipa-clients1 ~]$ kinit admin Password for admin@CXCLIENTS: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials $ kinit admin Password for admin@CXCLIENTS: Password expired. You must change it now. Enter new password: Enter it again: Password change rejected: Current password's minimum life has not expired Password not changed.. Please try again. Enter new password: What can I do now? Thanks, tamas -- 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] upgrade 3.0 - 4.1
hi All, I have CentOS 6.6 server and want to upgrade to 7.1. What is the upgrade path, can I do it directly or first I need to make it to 3.3? Also is there any known issue I should expect with workarounds? Thanks, tamas -- 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] upgrade 3.0 - 4.1
On 04/03/2015 03:46 PM, Brian Topping wrote: On Apr 3, 2015, at 6:48 AM, Tamas Papp tom...@martos.bme.hu wrote: hi All, I have CentOS 6.6 server and want to upgrade to 7.1. What is the upgrade path, can I do it directly or first I need to make it to 3.3? Also is there any known issue I should expect with workarounds? I just did this yesterday, so here's my experience. If you have a simple single-server installation with no custom LDAP DIT modifications, you should find yum upgrade does the right thing. If you do have DIT mods, you should ask yourself why they are there and whether the data will still be accessible after the ACLs are changed. In my case, I had Postfix using a LDAP hash and mail delivery stopped working (although the domain data was still there just fine). Note that the ACLs will propagate from the 4.1 server to your 3.0 if they are replicated. To be safe, back up all replicas (snapshot or whatnot) before the first upgrade and if you decide to restore any of them, be sure everything is shut down and restore all of them to avoid 4.x schema contaminating 3.0 as they come up. Ouch, that must have hurt:) As far as I recall, we have just very small custom changes. Thanks, t -- 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] freeipa-server from copr repo
hi All, -- Finished Dependency Resolution Error: Package: freeipa-server-4.1.1-1.1.el7.centos.x86_64 (mkosek-freeipa) Requires: pki-ca = 10.2.0-3 Available: pki-ca-10.0.5-3.el7.noarch (base) pki-ca = 10.0.5-3.el7 Available: pki-ca-10.1.2-3.el7.centos.noarch (mkosek-freeipa) pki-ca = 10.1.2-3.el7.centos You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Ho can I fix this? 10x tamas -- 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] freeipa-server from copr repo
I am good in waiting;) Thanks for the prompt reply. -- Sent from mobile On November 19, 2014 11:54:40 AM Martin Kosek mko...@redhat.com wrote: On 11/19/2014 11:37 AM, Tamas Papp wrote: hi All, -- Finished Dependency Resolution Error: Package: freeipa-server-4.1.1-1.1.el7.centos.x86_64 (mkosek-freeipa) Requires: pki-ca = 10.2.0-3 Available: pki-ca-10.0.5-3.el7.noarch (base) pki-ca = 10.0.5-3.el7 Available: pki-ca-10.1.2-3.el7.centos.noarch (mkosek-freeipa) pki-ca = 10.1.2-3.el7.centos You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest We are working on a fix right now. So hopefully, the fixed CentOS repo would be available during today. Ho can I fix this? Waiting a bit and then trying to install again :-) 10x tamas -- 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] freeipa-server from copr repo
hi Martin,
Much better:)
Unfortunately not perfect yet.
[...]
Done configuring DNS key synchronization service (ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
ipa : ERRORNamed service failed to start (Command
''/bin/systemctl' 'restart' 'named-pkcs11.service'' returned non-zero
exit status 1)
named service failed to start
Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files
Restarting the web server
Unexpected error - see /var/log/ipaserver-install.log for details:
CalledProcessError: Command ''/bin/systemctl' 'restart' 'ipa.service''
returned non-zero exit status 1
This helped:
chmod 777 /var/named/dyndb-ldap/ipa/
Probably chown or chgrp named would be just enough.
Cheers,
tamas
On 11/19/2014 05:41 PM, Martin Kosek wrote:
It is highly probable the issue is caused by SELinux (check for AVCs in
/var/log/audit/audit.log).
Can you try with SELinux permissive? We specifically did not build
selinux-policy as we do not think we should be the ones maintaining it for
CentOS.
HTH,
Martin
- Original Message -
From: Bill Peck b...@pecknet.com
To: Martin Kosek mko...@redhat.com
Cc: Tamas Papp tom...@martos.bme.hu, freeipa-users@redhat.com
Sent: Wednesday, November 19, 2014 5:34:10 PM
Subject: Re: [Freeipa-users] freeipa-server from copr repo
Hi Marin,
I was able to install from the copr repo now as well. Thank you!
However I wasn't able to finish the install:
[23/27]: configure certmonger for renewals
[24/27]: configure certificate renewals
[error] DBusException: org.fedorahosted.certmonger.bad_arg: The location
/etc/pki/pki-tomcat/alias could not be accessed due to insufficient
permissions.
Don't know if you need the command for how I was installing ipa. But here
is the line from my anseible playbook.
shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername
}} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns
--forwarder={{ dnsforwarder }} -U creates={{ slapd }}
On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek mko...@redhat.com wrote:
On 11/19/2014 11:57 AM, Tamas Papp wrote:
I am good in waiting;)
Thanks for the prompt reply.
Ok Tamas, I think we *finally* got somewhere. Can you please try the
mkosek/freeipa Copr repo now?
I was able to install upstream freeipa-server 4.1.1 package on my
RHEL-7.0
machine (should be the same for CentOS) and run ipa-server-install:
# yum install freeipa-server --enablerepo=mkosek-freeipa
...
Resolving Dependencies
-- Running transaction check
--- Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be installed
...
Transaction Summary
Install 1 Package (+338 Dependent packages)
Upgrade ( 11 Dependent packages)
Total download size: 146 M
...
# rpm -q freeipa-server
freeipa-server-4.1.1-1.2.el7.centos.x86_64
# ipa-server-install --setup-dns
# kinit admin
Password for ad...@example.com:
Thanks,
Martin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
--
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] freeipa-server from copr repo
On 11/19/2014 09:29 PM, Martin Kosek wrote: Ah, yes. This one is not a problem with the CentOS port, but rather existing problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all platforms, including Fedora 21 and CentOS. See upstream ticket: https://fedorahosted.org/freeipa/ticket/4716 Until this is fixed, correct workaround is to chown this directory by named:named and chmod rights to 0770. I will with the team when 4.1.2 is about to be released, if it is not soon, I can just add the patch to the 4.1.1 in Copr repo. Thanks for all. Just a question. My understanding is that 4.x will not hit RH 7 ever. So for IPA 4.x we have to wait until RH8, am I correct? Thanks, tamas -- 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] freeipa-server from copr repo
On 11/19/2014 10:27 PM, Martin Kosek wrote: Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) Very good! Then everything is good for testing:) t -- 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] can ipa-client-install be updated to call username/password from a file?
On 10/01/2014 10:19 AM, Les Stott wrote: Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following…. /usr/sbin/ipa-client-install -p admin -w admin_password -U --no-ntp While this works, while it runs, the admin_password value is visable in the output of a ps –ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ? 00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w plain_text_password -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. Try it with '-W pwfile'. t -- 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] gravatar image, IM fields
On 09/29/2014 12:35 PM, Martin Kosek wrote: On 09/29/2014 11:51 AM, Tamas Papp wrote: hi All, Is there a solution to integrate gravatar images and IPA? Something like a field for the gravatar url or actually I am not sure, what the right solution would be. Also is there a solution the add IM details to users, like skype id, hangouts id..etc? 10x tamas Hello Tamas, For the custom user fields, I think the best way will be to simply write a plugin extending the User object allowing these attribute in new objectClass. You can check an example with favoriteColorName in this presentation: http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf Thanks Martin. Is there any plan to officially integrate such a fields? Just out of curiosity any plan to add fields easier (from gui or with ipa command)? Can a plugin make a server future upgrade broken? Thanks, tamas -- 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] gravatar image, IM fields
hi All, Is there a solution to integrate gravatar images and IPA? Something like a field for the gravatar url or actually I am not sure, what the right solution would be. Also is there a solution the add IM details to users, like skype id, hangouts id..etc? 10x tamas -- 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] json api docs
On 09/12/2014 02:47 PM, Martin Kosek wrote: On 09/11/2014 02:06 AM, Dmitri Pal wrote: On 09/10/2014 07:10 PM, Tamas Papp wrote: hi All, Is there an offficial API documentation available? Unfortunately not much. You can search archives and find some recommendations that helped people in the past. https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html We also have a ticket https://fedorahosted.org/freeipa/ticket/3129 We also have a ticket https://fedorahosted.org/freeipa/ticket/4233 targeted on FreeIPA 4.1 to see the actual JSON queries that ipa command sends. It would make it easier to see how we use the API. Actually what is the recommended way to use ipa as a simple ldap backend for a service without kerberos? In fact the service does not need kerberos and things like that, but I like the helper tools of ipa, like ipa command, web UI, easy replication etc. Can I make trouble by writing the directory directly though ldap (add/delete/modify users + groups). 10x tamas -- 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] json api docs
On 09/12/2014 07:02 PM, Dmitri Pal wrote: You have seen other answers but I think a fair question to ask here is what does the service do and what kind of ldap info it needs? Is it read only or read write? Currently we have a forum, where users can register to a mysql database. W would like to migrate or use it together with ldap, so the registered customers could authenticate from a central user database. It would be like if I register to fedoraproject.org and with that I would get access to redhat bugzilla at the same time. The difference is that I need ldap backend for the targeted services. Cheers, tamas -- 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] json api docs
hi All, Is there an offficial API documentation available? Also is there a simple way to logon and run commands through API without a kerberos ticket? Thanks, tamas -- 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] authentication against compat
hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn=uid=USER,cn=users,cn=compat,dc=foo method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? Any idea? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn=uid=USER,cn=users,cn=compat,dc=foo method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? slapi-nis module in RHEL 6.x (and CentOS) does not support bind against compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). In older versions slapi-nis issues LDAP referral to the original LDAP entry with the hope that an LDAP client would follow it and perform a bind against the referral. Unfortunately, there is virtually no client software that supports the referral on bind operation. In short, you cannot do LDAP bind against compat tree in RHEL before 7.0. I forgot to mention, the client would be Ubuntu 12.04 and it works/worked with IPA 3.3 and F20. If I understand correctly, you're referring to the client side, are you? Or it is true for the server side as well? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn=uid=USER,cn=users,cn=compat,dc=foo method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? slapi-nis module in RHEL 6.x (and CentOS) does not support bind against compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). In older versions slapi-nis issues LDAP referral to the original LDAP entry with the hope that an LDAP client would follow it and perform a bind against the referral. Unfortunately, there is virtually no client software that supports the referral on bind operation. In short, you cannot do LDAP bind against compat tree in RHEL before 7.0. I forgot to mention, the client would be Ubuntu 12.04 and it works/worked with IPA 3.3 and F20. It worked with IPA 3.3 because of what I wrote above -- I implemented LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP referral to the original entry's DN. If I understand correctly, you're referring to the client side, are you? No. Or it is true for the server side as well? It is purely server-side issue. slapi-nis 0.47.5 does not support proper authentication against compat tree that LDAP clients understand. OK, that's clear now. Sorry I wasn't aware of slapi-nis behaviour:) Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn=uid=USER,cn=users,cn=compat,dc=foo method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? slapi-nis module in RHEL 6.x (and CentOS) does not support bind against compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). In older versions slapi-nis issues LDAP referral to the original LDAP entry with the hope that an LDAP client would follow it and perform a bind against the referral. Unfortunately, there is virtually no client software that supports the referral on bind operation. In short, you cannot do LDAP bind against compat tree in RHEL before 7.0. I forgot to mention, the client would be Ubuntu 12.04 and it works/worked with IPA 3.3 and F20. It worked with IPA 3.3 because of what I wrote above -- I implemented LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP referral to the original entry's DN. If I understand correctly, you're referring to the client side, are you? No. Or it is true for the server side as well? It is purely server-side issue. slapi-nis 0.47.5 does not support proper authentication against compat tree that LDAP clients understand. Actually I'd like to authenticate shell users on Ubuntu. For the records I figured out, that switching from nscd to nslcd did the trick. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 03:04 PM, Petr Spacek wrote: On 12.2.2014 15:01, Tamas Papp wrote: On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn=uid=USER,cn=users,cn=compat,dc=foo method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? slapi-nis module in RHEL 6.x (and CentOS) does not support bind against compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). In older versions slapi-nis issues LDAP referral to the original LDAP entry with the hope that an LDAP client would follow it and perform a bind against the referral. Unfortunately, there is virtually no client software that supports the referral on bind operation. In short, you cannot do LDAP bind against compat tree in RHEL before 7.0. I forgot to mention, the client would be Ubuntu 12.04 and it works/worked with IPA 3.3 and F20. It worked with IPA 3.3 because of what I wrote above -- I implemented LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP referral to the original entry's DN. If I understand correctly, you're referring to the client side, are you? No. Or it is true for the server side as well? It is purely server-side issue. slapi-nis 0.47.5 does not support proper authentication against compat tree that LDAP clients understand. Actually I'd like to authenticate shell users on Ubuntu. For the records I figured out, that switching from nscd to nslcd did the trick. BTW why you don't use SSSD? It is packaged for Ubuntu for sure. NSCD is ... obsolete. SSSD has some very nice features like off-line cache etc. I don't know it. After a quick look I wasn't able to set it up correctly, 'id USER' didn't connected to it's socket like with nscd/nlscd, however nsswitch.conf was configured. Maybe with the upcoming 14.04 or do you have a working howto for 12.04? Thx, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 09:53 PM, Jakub Hrozek wrote: On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: I don't know it. After a quick look I wasn't able to set it up correctly, 'id USER' didn't connected to it's socket like with nscd/nlscd, however nsswitch.conf was configured. Maybe with the upcoming 14.04 or do you have a working howto for 12.04? Please check SSSD web site for guidelines and if you have any questions do not hesitate to ask on the sssd-users list. SSSD is the best you can get nowadays for the connection of the client systems to the central identity stores. If you plan to use it with IPA you ho not need to configure sssd manually. ipa-client-install will do the trick. Just install ipa-client package and run the command. If realmd is available for your distribution, then I would highly recommend using it to set up SSSD. It isn't in 12.04, but will be available in 14.04. Thanks for suggestion. tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 11:29 PM, Alexander Bokovoy wrote: On Wed, 12 Feb 2014, Tamas Papp wrote: On 02/12/2014 09:53 PM, Jakub Hrozek wrote: On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: I don't know it. After a quick look I wasn't able to set it up correctly, 'id USER' didn't connected to it's socket like with nscd/nlscd, however nsswitch.conf was configured. Maybe with the upcoming 14.04 or do you have a working howto for 12.04? Please check SSSD web site for guidelines and if you have any questions do not hesitate to ask on the sssd-users list. SSSD is the best you can get nowadays for the connection of the client systems to the central identity stores. If you plan to use it with IPA you ho not need to configure sssd manually. ipa-client-install will do the trick. Just install ipa-client package and run the command. If realmd is available for your distribution, then I would highly recommend using it to set up SSSD. It isn't in 12.04, but will be available in 14.04. Thanks for suggestion. https://launchpad.net/~sssd/+archive/updates I meant realmd is not in 12.04. tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
On 02/12/2014 07:30 PM, Dmitri Pal wrote: Please check SSSD web site for guidelines and if you have any questions do not hesitate to ask on the sssd-users list. SSSD is the best you can get nowadays for the connection of the client systems to the central identity stores. If you plan to use it with IPA you ho not need to configure sssd manually. ipa-client-install will do the trick. Just install ipa-client package and run the command. It was quite pathetic, when last time I tried on ubuntu. I'll try sssd again, if I have spare time. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] CA replication
hi All,
I'm trying to replicate the CA server:
$ ipa-replica-install -p XXX --setup-ca -d --mkhomedir
replica-info-ipa11.bpo.cxn.gpg
Without --setup-ca it works correctly.
The output of the above command:
[...]
ipa : DEBUGStarting external process
ipa : DEBUGargs=/bin/systemctl is-enabled dirsrv.target
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=disabled
ipa : DEBUGstderr=
ipa : DEBUGSaving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
ipa : DEBUGStarting external process
ipa : DEBUGargs=/bin/systemctl disable dirsrv.target
ipa : DEBUGProcess finished, return code=0
ipa : DEBUGstdout=
ipa : DEBUGstderr=
ipa : DEBUG duration: 0 seconds
ipa : DEBUGDone configuring directory server (dirsrv).
Done configuring directory server (dirsrv).
ipa : DEBUGLoading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
ipa : DEBUGLoading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
ipa : DEBUGConfiguring certificate server (pki-tomcatd):
Estimated time 3 minutes 30 seconds
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
ipa : DEBUG [1/19]: creating certificate server user
[1/19]: creating certificate server user
ipa : DEBUGca user pkiuser exists
ipa : DEBUG duration: 0 seconds
ipa : DEBUG [2/19]: configuring certificate server instance
[2/19]: configuring certificate server instance
ipa : DEBUGContents of pkispawn configuration file
(/tmp/tmpoRxk1S):
[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-XPC2YR
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=CXN
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=CXN
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=CXN
pki_ssl_server_subject_dn = cn=ipa11.bpo.cxn,O=CXN
pki_audit_signing_subject_dn = cn=CA Audit,O=CXN
pki_ca_signing_subject_dn = cn=Certificate Authority,O=CXN
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
pki_security_domain_hostname = ipa12.bpo.cxn
pki_security_domain_https_port = 443
pki_security_domain_user = admin
pki_security_domain_password =
pki_clone = True
pki_clone_pkcs12_path = /tmp/ca.p12
pki_clone_pkcs12_password =
pki_clone_replication_security = TLS
pki_clone_replication_master_port = 389
pki_clone_replication_clone_port = 389
pki_clone_replicate_schema = False
pki_clone_uri = https://ipa12.bpo.cxn:443
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/pkispawn -s CA -f /tmp/tmpoRxk1S
And it's waiting here forever, not even timeout.
strace output of pkispawn shows up it's trying to get data from the
local ldap service:
open(/etc/hosts, O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=281, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f46307e2000
read(4, 127.0.0.1 localhost localhost.localdomain localhost4
localhost4.localdomain4\n::1 localhost localhost.localdomain
localhost6 localhost6.localdomain6\n\n10.0.0.73\tipa12.bpo.cxn
ipa12\n10.128.0.5\tipa31.bph.cxn ipa31\n10.128.0.6\tipa32.bph.cxn
ipa32\n10.0.0.12\tipa11.bpo.cxn ipa11\n, 4096) = 281
read(4, , 4096) = 0
close(4)= 0
munmap(0x7f46307e2000, 4096)= 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr(10.0.0.12)}, 16) = 0
write(4, 0%\2\1\1c
\4\0\n\1\0\n\1\0\2\1\0\2\1\0\1\1\0\207\vobjectClass0\0, 39) = 39
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 4294967295
If I run ldapsearch -x -h ipa11, then indeed, I can see the same behaviour.
strace output of ns-slapd:
[pid 2028] accept(6, {sa_family=AF_INET6, sin6_port=htons(59587),
inet_pton(AF_INET6, :::10.0.0.12, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 24
[pid 2028] fcntl(24, F_GETFL) = 0x2 (flags O_RDWR)
[pid 2028] fcntl(24, F_SETFL,
[Freeipa-users] sig11
hi All, Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in libc-2.17.so[7f438b5fc000+1b6000] Nov 11 08:56:15 ipa31 systemd[1]: dirsrv@CXN.service: main process exited, code=killed, status=11/SEGV Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv@CXN.service entered failed state. We have two freeipa servers on Fedora 19. On one of them the service stopped. The above messages are from the messages log files. No I updated some packages by yum, but otherwise the system was uptodate: Installing: kernel x86_64 3.11.7-200.fc19 updates 30 M Updating: glibc x86_64 2.17-19.fc19 updates 3.6 M glibc-common x86_64 2.17-19.fc19 updates 11 M hwdata noarch 0.257-1.fc19 updates 1.1 M libdrm x86_64 2.4.47-1.fc19 updates 115 k libgcrypt x86_64 1.5.3-2.fc19 updates 256 k libipa_hbac x86_64 1.11.2-1.fc19 updates 60 k libipa_hbac-python x86_64 1.11.2-1.fc19 updates 54 k libsss_idmap x86_64 1.11.2-1.fc19 updates 64 k libsss_nss_idmap x86_64 1.11.2-1.fc19 updates 63 k mod_nss x86_64 1.0.8-24.fc19 updates 94 k openldap x86_64
Re: [Freeipa-users] sig11
On 11/11/2013 09:37 AM, Alexander Bokovoy wrote: On Mon, 11 Nov 2013, Tamas Papp wrote: hi All, Nov 11 08:56:15 ipa31 kernel: [324701.614162] traps: ns-slapd[1333] general protection ip:7f438b682731 sp:7f43637fb9a8 error:0 in libc-2.17.so[7f438b5fc000+1b6000] Nov 11 08:56:15 ipa31 systemd[1]: dirsrv@CXN.service: main process exited, code=killed, status=11/SEGV Nov 11 08:56:15 ipa31 systemd[1]: Unit dirsrv@CXN.service entered failed state. We have two freeipa servers on Fedora 19. On one of them the service stopped. The above messages are from the messages log files. Please run # debuginfo-install 389-ds-base freeipa This would install debuginfo packages for the directory server and FreeIPA modules to it. Then try to restart ipa -- if crash would be reproducible, we should see full stacktrace in the journal. OK. Let's see if it crashes again. If so, I'll do this. 10x tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/06/2013 02:08 AM, Rich Megginson wrote: On 11/05/2013 04:23 PM, Tamas Papp wrote: On 11/05/2013 09:25 PM, Rich Megginson wrote: On 11/05/2013 01:03 PM, Tamas Papp wrote: On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. freeipa-admintools-3.3.2-1.fc19.x86_64 freeipa-client-3.3.2-1.fc19.x86_64 freeipa-python-3.3.2-1.fc19.x86_64 freeipa-server-3.3.2-1.fc19.x86_64 libipa_hbac-1.11.1-4.fc19.x86_64 libipa_hbac-python-1.11.1-4.fc19.x86_64 sssd-ipa-1.11.1-4.fc19.x86_64 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 389-ds-base-1.3.1.12-1.fc19.x86_64 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Fedora 19. How can I fix it? ldapmodify -x -D cn=directory manager -W EOF dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on EOF Do this on all of your servers. I tried this, but no joy. Still not good:/ Can you describe the exact steps you took, on all replicas? I created ldif files: # cat replication_ignore-time-skew.ldif dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on Then: $ ldapmodify -x -D cn=directory manager -W -f replication_ignore-time-skew.ldif But I don't see the changes: # ldapsearch -x|grep -i ignore ldapsearch -x -D cn=directory manager -W -s base -b cn=config 'objectclass=*' nsslapd-ignore-time-skew You're right, I tried it with wrong base dn. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/06/2013 02:07 AM, Rich Megginson wrote: On 11/05/2013 04:34 PM, Tamas Papp wrote: On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. Eventually you were right, it looks, that the problem is related to the virtualization, thanks for the tip. Although I wouldn't say, it's because of messy VMs. It definitely must be a software bug or misconfiguration, otherwise a VM should always looks the same as a bare metal machine. Actually in my specific case I don't see the reason, why it is working with clock offset='utc'/ and not with clock offset='localtime'/ if the time in the VM synchronized after bootup. You can file a ticket. I'm not absolutely sure, that this was the root cause of the problem. tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/06/2013 04:16 AM, Rob Crittenden wrote: 5. If I have a network like this: A1__B1 A2 B2 A2 and B1,2 are replicated from A1 If the connection gets lost between A and B site, are B1 and 2 (and A1,2) replicated fine? I assume from the above that B1 does not know about B2 (and vice versa)? Well, that is actually one of the questions. B1 and B2 are on the same sites and failover nodes from point of view of clients. You can manage the replication topology with ipa-replica-manage connect and disconnect. So if you want B1 and B2 connected you can do that. Once connectivity between sites A and B restored, all unreplicated data will be replicated. There could be conflicts if there were changes on both sides during the split but majority of them are solved automatically by 389-ds. The main question is that B1 and B2 are not replicated to each other automatically? What about the case if A1 -- replication -- A2 --- replication --- B1 -- replication -- B2 If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized? Especially automatically...? Is there such a failover configuration? No, the masters only replicate to the ones you tell them to, so if B1 went away forever then B2 would never get any other updates unless you explicitly made a connection to A1 or A2. Can the replication agreement be circular? *A2*-A1-B1-B2-*A**2*? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ui login error and questions about replication
hi, The systems are uptodate F19 KVM guests. I'm trying to login the web ui with no success: Your session has expired. Please re-login. To login with Kerberos, please make sure you have valid tickets (obtainable via kinit) and configured http://ipa31.bph.cxn/ipa/config/unauthorized.html the browser correctly, then click Login. To login with username and password, enter them in the fields below then click Login. Then after a while something happens and it starts working. In logs: On the primary node: [05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin - agmt=cn=meToipa12.bpo.cxn (ipa12:389): Replication bind with GSSAPI auth resumed On the secondary node: [05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time skew (-1658 secs). Current seqnum=3 [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time skew (-811 secs). Current seqnum=a [05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time skew (-812 secs). Current seqnum=1 [05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time skew (-811 secs). Current seqnum=1 [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time skew (-800 secs). Current seqnum=4 [05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time skew (-801 secs). Current seqnum=1 [05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time skew (-800 secs). Current seqnum=1 Date shows up the same system time on both machines: Tue Nov 5 12:59:29 CET 2013 I called as primary the machine that was installed initially and secondary is the one that was deployed by replication. Finally, I have some questions:) 1. How can this happen, what's the problem? Is it something about the design, I screwed up something, or maybe the virtualization layer..? How can I avoid it and if it happens, how can I fix it immediately? 2. What is the difference between 'primary' and 'secondary'. What does happen, if the primary machine gets destroyed? 4. How many master can I use? 5. If I have a network like this: A1__B1 A2 B2 A2 and B1,2 are replicated from A1 If the connection gets lost between A and B site, are B1 and 2 (and A1,2) replicated fine? 6. If a client is installed with ipa-client-install using A1 and A1 gets lost, does the client know, where it needs to connect (failover..)? 7. Can I install slave (read-only) replicas so clients access them only for queries and for changes (like pw change) they access master servers? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. freeipa-admintools-3.3.2-1.fc19.x86_64 freeipa-client-3.3.2-1.fc19.x86_64 freeipa-python-3.3.2-1.fc19.x86_64 freeipa-server-3.3.2-1.fc19.x86_64 libipa_hbac-1.11.1-4.fc19.x86_64 libipa_hbac-python-1.11.1-4.fc19.x86_64 sssd-ipa-1.11.1-4.fc19.x86_64 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 389-ds-base-1.3.1.12-1.fc19.x86_64 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Fedora 19. How can I fix it? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. freeipa-admintools-3.3.2-1.fc19.x86_64 freeipa-client-3.3.2-1.fc19.x86_64 freeipa-python-3.3.2-1.fc19.x86_64 freeipa-server-3.3.2-1.fc19.x86_64 libipa_hbac-1.11.1-4.fc19.x86_64 libipa_hbac-python-1.11.1-4.fc19.x86_64 sssd-ipa-1.11.1-4.fc19.x86_64 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 389-ds-base-1.3.1.12-1.fc19.x86_64 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Fedora 19. How can I fix it? ldapmodify -x -D cn=directory manager -W EOF dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on EOF Do this on all of your servers. I tried this, but no joy. Still not good:/ What I really don't understand, why I cannot login to ui (or to an installed client machine) if the replication doesn't work. Is it a normal behaviour? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 09:09 PM, Rob Crittenden wrote: Tamas Papp wrote: On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. You see the same time NOW. The logs were reflecting a difference at that time. I saw the same, when the log messages appeared. Is there a way to get the time it sees from the other side? I tried this, but no joy. Still not good:/ What I really don't understand, why I cannot login to ui (or to an installed client machine) if the replication doesn't work. Is it a normal behaviour? These issues are probably not related, unless perhaps the time skew is also throwing off the Kerberos tickets and/or session cache in the IPA framework. You didn't say how you were trying to log into the UI. Are you using Kerberos or the form-based authentication? Latter. There is no kerberos configured on my computer. But I've also tried with ssh on a normal computer. Both failed. tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 09:20 PM, Tamas Papp wrote: On 11/05/2013 09:09 PM, Rob Crittenden wrote: Tamas Papp wrote: On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. You see the same time NOW. The logs were reflecting a difference at that time. I saw the same, when the log messages appeared. Is there a way to get the time it sees from the other side? I tried this, but no joy. Still not good:/ What I really don't understand, why I cannot login to ui (or to an installed client machine) if the replication doesn't work. Is it a normal behaviour? These issues are probably not related, unless perhaps the time skew is also throwing off the Kerberos tickets and/or session cache in the IPA framework. You didn't say how you were trying to log into the UI. Are you using Kerberos or the form-based authentication? Latter. There is no kerberos configured on my computer. But I've also tried with ssh on a normal computer. Both failed. Recently I'm able to login to the UI. I made couple of changes, but probably this was the tricky one: One of the host machine was configured to UTC. So I changed the VM configuration as well: From clock offset='localtime'/ to clock offset='utc'/ Before this change the 'RTC time:' line was lacking from the output of timedatectl and after the VM reboot the default time was wrong (though it could be fixed by ntpdate easily). After reboot it seems to be working, but: [05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time skew (-2852 secs). Current seqnum=1 [05/Nov/2013:23:33:24 +0100] NSMMReplicationPlugin - agmt=cn=meToipa12.bpo.cxn (ipa12:389): Replication bind with GSSAPI auth resumed [05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time skew (-2853 secs). Current seqnum=1 [05/Nov/2013:23:33:25 +0100] csngen_new_csn - Warning: too much time skew (-2853 secs). Current seqnum=1 [[05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2828 secs). Current seqnum=1 [05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2829 secs). Current seqnum=1 [05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time skew (-2830 secs). Current seqnum=1 [05/Nov/2013:23:33:53 +0100] csngen_new_csn - Warning: too much time skew (-2829 secs). Current seqnum=1 [05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time skew (-2749 secs). Current seqnum=1 [05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time skew (-2750 secs). Current seqnum=1 [05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time skew (-2742 secs). Current seqnum=1 [05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time skew (-2743 secs). Current seqnum=1 # ldapsearch -x -D cn=directory manager -W |grep -i nsslapd-ignore-time-skew Enter LDAP Password: No I don't understand, why it was resumed and why it is working in spite of skewed time. And still I don't understand, why I cannot login, when the replication is not working. tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 09:25 PM, Rich Megginson wrote: On 11/05/2013 01:03 PM, Tamas Papp wrote: On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. What do you mean by this? I definitely see the same time on the machines. Also I can see in the log, that the replication is resumed. There is no messages about the broken replication after the resume message. freeipa-admintools-3.3.2-1.fc19.x86_64 freeipa-client-3.3.2-1.fc19.x86_64 freeipa-python-3.3.2-1.fc19.x86_64 freeipa-server-3.3.2-1.fc19.x86_64 libipa_hbac-1.11.1-4.fc19.x86_64 libipa_hbac-python-1.11.1-4.fc19.x86_64 sssd-ipa-1.11.1-4.fc19.x86_64 389-ds-base-libs-1.3.1.12-1.fc19.x86_64 389-ds-base-1.3.1.12-1.fc19.x86_64 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Fedora 19. How can I fix it? ldapmodify -x -D cn=directory manager -W EOF dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on EOF Do this on all of your servers. I tried this, but no joy. Still not good:/ Can you describe the exact steps you took, on all replicas? I created ldif files: # cat replication_ignore-time-skew.ldif dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew nsslapd-ignore-time-skew: on Then: $ ldapmodify -x -D cn=directory manager -W -f replication_ignore-time-skew.ldif But I don't see the changes: # ldapsearch -x|grep -i ignore # Probably you realized, I'm not an ldap expert:) But I assume it's because it doesn't exist right now, therefore it should be add ot modify? I don't wan't to try it now, because currently it's working. Maybe when it gets fail again. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ui login error and questions about replication
On 11/05/2013 03:58 PM, Rich Megginson wrote: On 11/05/2013 07:53 AM, Tamas Papp wrote: On 11/05/2013 03:17 PM, Rich Megginson wrote: https://fedorahosted.org/389/ticket/47516 This has been fixed upstream and in some releases - to allow replication to proceed despite excessive clock skew - what is your 389-ds-base version and platform? What is the clock skewed? The date and time is the same on both machines. VMs are notorious for having the clocks get out of sync - even temporarily. Eventually you were right, it looks, that the problem is related to the virtualization, thanks for the tip. Although I wouldn't say, it's because of messy VMs. It definitely must be a software bug or misconfiguration, otherwise a VM should always looks the same as a bare metal machine. Actually in my specific case I don't see the reason, why it is working with clock offset='utc'/ and not with clock offset='localtime'/ if the time in the VM synchronized after bootup. It looks a software bug to me. But using UTC on (only) one machine is definitely a misconfiguration:) Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Required services are not started after reboot
On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] memberOf
hi All, I have a fedora directory server with memberOf attributes. I'm able to migrate users to Freeipa, but I can see there are no such attributes at the new place. If I understand correctly, a memberOf plugin should be enabled. How can I do that? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] memberOf
On 10/07/2013 06:06 PM, Tamas Papp wrote: hi All, I have a fedora directory server with memberOf attributes. I'm able to migrate users to Freeipa, but I can see there are no such attributes at the new place. If I understand correctly, a memberOf plugin should be enabled. How can I do that? I wasn't correct here. This works: # ldapsearch -Y GSSAPI 2/dev/null |grep memberOf|wc -l 2424 This not: # ldapsearch -x 2/dev/null |grep memberOf|wc -l 0 I miss something, but I don't know, what. I'm not really an ldap or IPA expert, please give me some advise:) Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] memberOf
On 10/07/2013 08:59 PM, Dmitri Pal wrote: On 10/07/2013 12:32 PM, Tamas Papp wrote: On 10/07/2013 06:06 PM, Tamas Papp wrote: hi All, I have a fedora directory server with memberOf attributes. I'm able to migrate users to Freeipa, but I can see there are no such attributes at the new place. If I understand correctly, a memberOf plugin should be enabled. How can I do that? I wasn't correct here. This works: # ldapsearch -Y GSSAPI 2/dev/null |grep memberOf|wc -l 2424 This not: # ldapsearch -x 2/dev/null |grep memberOf|wc -l 0 I miss something, but I don't know, what. I'm not really an ldap or IPA expert, please give me some advise:) With anonymous bind you do not see any data. With GSSAPI you authenticate and thus entitled to see what you are looking for. I see, that's true. Although I don't understand why memberOf not works if every other information available? ldapsearch -x uid=user and ldapsearch -x cn=group works fine. Therefore all information is available, just not showed up right. Am I wrong? Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] service not starting after reboot
hi All, I installed freeipa on F19 by yum and ipa-server-install. It works fine until I reboot the machine, then it's not starting anymore: # ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Failed to data from service file: Failed to get list of services to probe status: Directory Server is stopped Shutting down I'm not really familiar with systemd. Is there something I missed? # systemctl status dirsrv.target dirsrv.target - 389 Directory Server Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled) Active: inactive (dead) since Fri 2013-10-04 19:14:45 CEST; 2min 23s ago Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Starting 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Reached target 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopping 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopped target 389 Directory Server. Thank you, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] service not starting after reboot
On 10/04/2013 05:25 PM, Martin Kosek wrote: It seems that dirsrv fails to start or ipactl is unable to read from it. Can you please: 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? Hmm, you're right, I could start with this. There was no /var/run/dirsrv I guess it supposed to be created by the init script? 2) Check if there were not AVCs logged by FreeIPA installation or start? # ausearch -m avc -ts today No result. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] service not starting after reboot
On 10/04/2013 05:51 PM, Martin Kosek wrote: This bug is probably the reason https://bugzilla.redhat.com/show_bug.cgi?id=1008306 Tamas, can you try updating to 389-ds-base-1.3.1.11-1.fc19 and checking if it fixes the /var/run/dirsrv issue? Works like a charm. Thanks, tamas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
