[Freeipa-users] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones
Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) Pilsner - Future releases (with appropriate milestone description to set the expectations right) b) Beer Exchange - Backlog (with better description) c) Deferred - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] export user info
On 02/10/2014 12:01 PM, barry...@gmail.com wrote:
Dear all:
Which command can export /show all users a/c and info? better in table
format .
Regards
Barry
$ ipa user-find
Or in JSON-RPC command:
{method:user_find,params:[[],{sizelimit:0}]}
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts
On Mon, Feb 10, 2014 at 10:55:33AM -0500, Steve Dainard wrote: I've setup RHEL 7 beta IPA with a trust to an AD domain. When I use an AD domain login it takes roughly 9-14 seconds to get to a shell after entering a password. Is there any way to speed this process up? I thought supplemental logins would be quicker, but the login time is the same. This is either via console, or via ssh@localhost or ssh over the network. at a first glace I would say that the delay is in krb5_child. Can you send this log file as well? bye, Sumit IPA realm = miolinux.corp DC domain/forest = miovision.corp ... (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! ... *(Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] (0x0400): EOF received, client finished* ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts
Sure: (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [main] (0x0400): krb5_child started. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdain...@miovision.corp] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.c...@miolinux.corp]. (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [main] (0x0400): krb5_child started. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdain...@miovision.corp] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929 [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.c...@miolinux.corp]. (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [main] (0x0400): krb5_child started. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdain...@miovision.corp] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:16:57
Re: [Freeipa-users] CentOS 6.5 client install failing
On 02/08/2014 08:48 AM, Rob Crittenden wrote: Dave Jablonski wrote: FreeIPA Server: Fedora 16, freeipa 2.1.4 Latest CentOS 6.5 client When running: ipa-client-install --mkhomedir --enable-dns-updates The install fails with: trying https://server-name/ipa/xml Forwarding 'env' to server u'https://server-name/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name http://self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 736, in forward raise error(message=e.faultString) ipalib.errors.CCacheError: did not receive Kerberos credentials In /var/log/ipaclient-install.log: 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = SSLServer 2014-02-06T18:19:53Z DEBUG cert valid True for CN=server-name,O=domain 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 http://10.1.1.111:443 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server https://server-name/ipa/xml: did not receive Kerberos credentials We need to see more context from the client install log, preferably the whole thing. IPA v2 doesn't support session cookies but the 3.x client should have support for falling back to using TGT delegation. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Any chance to upgrade the server to something more modern? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUGstderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users What server provides DNS capabilities to the clients? Do you use IPA DNS or some other DNS? Clients seem to not be able to see replica KDC and try to access hidden master but they can know about this master only via DNS. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp
On 02/09/2014 09:52 PM, Mauricio Tavares wrote: On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainardsdain...@miovision.com wrote: I've noticed if ntpd is already running on the client when you run the ipa-client-install, you will get that error. I'm guessing its using ntpdate IP ADDRESS to sync time, and cannot do so when the daemon is running. I've noticed if ntpd is already running on the client when you run the ipa-client-install, you will get that error. I'm guessing its using ntpdate IP ADDRESS to sync time, and cannot do so when the daemon is running. Now that you mentioned that I would agree with you in that it is failing because ntpd is running already; I could not see it because of the option -s in [root@centos64 ~]# service ntpd status ntpd (pid 3721) is running... [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com [root@centos64 ~]# I could not find what all of those arguments mean in the centos 6.5 ntpdate man page, but here is what I found under ubuntu's: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. -s Divert logging output from the standard output (default) to the system syslog facility. This is designed primarily for conve‐ nience of cron scripts. -v Be verbose. This option will cause ntpdate's version identifica‐ tion string to be logged. In other words, -s is sending the output to syslog. And, if we check /var/log/messages we will find that Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting as you expected. Now, how did it detect the ntpdate failed? Steve On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavaresraubvo...@gmail.com wrote: Even though I already have a ntp server, I setup my newly created freeipa kdc to do that too (it is a slave to my primary ntp). I then build a centos host to be the test client. Just to make sure it can see and use auth's ntp, I tested with ntpdate: [root@centos64 ~]# ntpdate auth 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset -0.003097 sec [root@centos64 ~]# so far so good, so how about running ipa-client-install? [root@centos64 ~]# hostname centos64 [root@centos64 ~]# ipa-client-install --hostname=`hostname -f` Discovery was successful! Hostname: centos64.in.domain.com Realm: DOMAIN.COM DNS Domain: domain.com IPA Server: auth.in.domain.com BaseDN: dc=domain,dc=com [so far so good!] Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Password for ad...@domain.com: But, it had not problems using ntpdate against auth. to add insult to injury, the log claims it is using ntpdate: 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com 2014-02-08T13:14:31Z DEBUG stdout= 2014-02-08T13:14:31Z DEBUG stderr= 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Could it be it is pissed because it was in sync to begin with? I mean, if we run the exact command the log file claims to have run, [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| echo $? 0 [root@centos64 ~]# We see it was successful. I am feeling rather clueless here... ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This sounds like a bug to me but I would wait for European gurus to chime in the morning. If it is a bug we need a ticket. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CentOS 6.5 client install failing
Unfortunately no. I don't have access to the server. On Feb 10, 2014 2:36 PM, Dmitri Pal d...@redhat.com wrote: On 02/08/2014 08:48 AM, Rob Crittenden wrote: Dave Jablonski wrote: FreeIPA Server: Fedora 16, freeipa 2.1.4 Latest CentOS 6.5 client When running: ipa-client-install --mkhomedir --enable-dns-updates The install fails with: trying https://server-name/ipa/xml Forwarding 'env' to server u'https://server-name/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name http://self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 736, in forward raise error(message=e.faultString) ipalib.errors.CCacheError: did not receive Kerberos credentials In /var/log/ipaclient-install.log: 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = SSLServer 2014-02-06T18:19:53Z DEBUG cert valid True for CN=server-name,O=domain 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 http://10.1.1.111:443 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server https://server-name/ipa/xml: did not receive Kerberos credentials We need to see more context from the client install log, preferably the whole thing. IPA v2 doesn't support session cookies but the 3.x client should have support for falling back to using TGT delegation. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Any chance to upgrade the server to something more modern? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- IMPORTANT: This e-mail (including any attachments) is intended for the use of the individual or entity to which it is addressed and may contain information that is classified, private, or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. Thank you. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Lucas (sorry my previous email may have got sent improperly edited. My typical command looks like this (domain name changed due to disclosure reasons) # ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d master = ldap.mydomain.com replica = ldap2.mydomain.com I ran lsof while running a ipa-client-install and found the following kinit instances trying to access my master = ipa-clien 10443 root mem REG 253,0 334040 1704353 /lib64/libldap_r-2.4.so.2.5.6 ipa-clien 10443 root mem REG 253,0 61896 1444372 /usr/lib64/python2.6/site-packages/_ldap.so kinit 10545 root 3u IPv4 143621 0t0 UDP test500.mydomain.com:57166-ldap.mydomain.com:kerberos kinit 10545 root 4u IPv4 143636 0t0 TCP test500.mydomain.com:35574-ldap.mydomain.com:kerberos (SYN_SENT) = the client install also finds issue with syncing time during client install, but only gives warning. The time difference between master and client is within seconds. the client install also finds issue with Shreeraj Change is the only Constant ! On Sunday, February 9, 2014 4:44 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrade of Free ipa in CENTOS 6
Dear all: Any one have exp to upgrade ipa-server-3.0.0-26.el6_4.4.x86_64 to ipa-server-3.0.0-37.el6_4.4.x86_64 ( jus t minor patch/upgrade it think ) Is it just yum install then ok ??? i notice some official document but they are 3.3 free ipa of fedora ...just yum / run the rpm and not necessary shut down. Is it same in CENTOS ipa 3.0 server one ? http://www.freeipa.org/page/Releases/3.2.0#Upgrading ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Free-IPA in an AWS Base Image
I want to create an AWS AMI that when it starts up will register itself with a Free-IPA instance. The issue I have run into so far is every instance when it starts up uses the original instances hostname. What do I need to do to have free-ipa work in a DHCP environment like this? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
