Re: [Freeipa-users] New FreeIPA Install; Testing for Proof of Concept
On 08/12/2012 12:05 PM, Simo Sorce wrote: - Original Message - On 08/08/2012 08:07 PM, Simo Sorce wrote: On Wed, 2012-08-08 at 19:59 +0200, Petr Spacek wrote: On 08/08/2012 07:27 PM, Rob Ogilvie wrote: On Wed, Aug 8, 2012 at 9:06 AM, Petr Spacek pspa...@redhat.com wrote: Best way is to create subdomain UNIX.MYCOMPANY.COM and fill it with proper SRV records (or let IPA to manage it). Ugh, I hope this doesn't end up pushing us back to NIS. If I can get our infrastructure guys to buy off on making a unix.mycompany.com subdomain in DNS, would I need to move all the hosts to be under that subdomain in DNS? I have some services Definitely not. You can create subdomain UNIX.MYCOMPANY.COM, fill it with SRV records and leave this subdomain without hosts (maybe except IPA servers ...). It is not necessary to rename all hosts. Problem is simple - Kerberos libraries have to know where KDCs are located - and DNS is standardized way how to accomplish it. Let me quote another reply from this thread: On 08/08/2012 06:14 PM, KodaK wrote: You*could* use something like puppet to manage your krb5.conf files (I have to with our AIX machines.) Also, it's important to note that your REALM does NOT need to match your dns domain name It's a convenience, and it's very, very helpful to do so, but it is possible to have a REALM called MIDDLEEARTH if you wanted. I'm not sure how IPA would deal with that, but I know you can do it in straight up Kerberos. configured that are difficult to rename the DNS domain of. Could, for instance, host-one.mycompany.com be part of the UNIX.MYCOMPANY.COM realm, given a MYCOMPANY.COM realm also exists? Yes, it could. I could then put some SRV records into the subdomain's zone to point the kerberos stuff to the IPA server, change the domain on the IPA server, change the realm on the IPA server, re-register clients, and everything would be happy? I get lost in the renaming part. Can you describe your idea in bigger detail? Ugh... actually... now that I think about this, I don't think I want half my servers in a unix subdomain in DNS, which means DNS and realm wouldn't match... Thoughts? Aside from rebuilding the infrastructure I've built already? :-) Let all machines in MYCOMPANY.COM and use IPA realm UNIX.MYCOMPANY.COM. IMHO it is simplest way. This limitation comes from Kerberos: You are trying to use *single domain name* for *two independent Kerberos realms* - it is principally not possible. I just need to pint one one problem with leaving all machines under MYDOMAIN.COM, and that is if you later want to make a trust (option available starting from ipa 3.0) between the AD realm and the IPA realm, the machines in the mydomain.com domain will not be able to be accessed by the users of the AD realm. That is because the machines joined to the AD realm will think that the mydomain.com machines are always served up by the AD domain. On the IPA side you amy also have so issues as you will not be able to tell IPA clients that they need to ask the AD KDC for the hosts under mydomain.com So ultimately, I would put as many machines as you can under UNIX.MYDOMAIN.COM, to minimize confusion in case later on you want to establish a trust between the AD domain and the IPA domain. Simo. Is possible to workaround these problems with hostname-realm mappings? It is not clear solution, I know, but it should be doable for limited set of unix machines. AFAIK Windows AD (I tested it with 2008 R2) has ability to set hostname-realm mappings through Group policy. Yes from the Linux side it is possible to map single hostnames to a realm, so the top domain could be generally mapped to the AD realm, and then single hosts mapped to the IPA realm. This is not possible for windows machines in the AD domain though (afaik). Simo. It should be doable via AD Group Policy: http://support.microsoft.com/kb/947706/en-us Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Heads up on dynamic DNS TTL weird behaviour...
Hey all, Just a quick heads up in for the mailing list archive in case someone bumps into this after drilling through it a bit in IRC on Friday... If you are making use of --enable-dns-updates in ipa-client-install and for whatever reason your client may change its address more often than once per day after the first update other systems won't pick up the change for 24 hours... The cause is down to the difference in how the DNS record is created/updated on the initial install versus SSSD handling it later... The initial install has a hardcoded TTL of 1200 set at line 957 of /usr/sbin/ipa-client-install (as per Centos 6.3 current)... SSSD has a hardcoded TTL set of 86400 in the provider ipa/ipa_dyndns.c (line 989 or thereabouts)... The consequence is that when the system is first registered the DNS record that gets created only has a TTL of 1200 but if the IP address changes for that host then the record gets updated with a TTL of 86400 so that other DNS servers (or clients) will then have a day until it times out (unless caches can be manually cleared) and the correct address is found for any changes subsequent to that... This is a bit of an edge case given you'd need 2 changes of IP address since the initial registration and have SSSD configured to carry out the DNS updates (rather than a dhcpd/bind integration for example) for this to have an effect on the environment... I have filed a bug and a patch with the SSSD mailing list/trac but changing this locally requires a recompile of SSSD Moving forwards I plan to expose TTL in the IPA UI and provide a configurable value for TTL for both ipa-client-install and the sssd updates ... I'll update the list in a couple of weeks on any progress made... Kind regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NFS Ownership Gone
Check your idmapper configuration (idmapd.conf) - not quite sure if IPA cares about NFSv4 ID mapper configuration On Fri, Aug 10, 2012 at 2:54 PM, Rob Ogilvie r...@axpr.net wrote: Files accessed over NFS with users that are not local (FreeIPA users) are being squashed to nobody:nobody on my OEL6 box. My nfs is set to defaults on the client. As an addendum to this: I'm not interested in strong security in my NFS implementation; simplicity is what we use NFS for. If there's a simpler way than copying files across all the clients, I'm game. :-) Rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] migrate-ds fails with Can't contact LDAP server
Qing Chang wrote: Just installed a fresh RHEL 6.3 VM with IPA 2.2..0-16.el6 on our new ESXi host, after preparing migration mode as well as adding necessary objectclasses, tried to run following: ipa -d migrate-ds ldap://openldap:389 --bind-dn=cn=Manager --group-container=ou=group --schema=RFC2307 --with-compat --group-objectclass=posixGroup It failed promptly with this: = ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for CN=ipa1.sri.utoronto.ca,O=SRI.UTORONTO.CA ipa: DEBUG: handshake complete, peer = IP_of_ipa1:443 ipa: DEBUG: Caught fault 4203 from server http://ipa1.sri.utoronto.ca/ipa/xml: Can't contact LDAP server: ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: = /var/log/dirsrv/access shows: = [12/Aug/2012:07:53:26 -0400] conn=81 op=6 SRCH base=cn=accounts,dc=sri,dc=utoronto,dc=ca scope=2 filter=((uid=postfix)(objectClass=posixAccount)) attrs=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf nsUniqueId modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey [12/Aug/2012:07:53:26 -0400] conn=81 op=6 RESULT err=0 tag=101 nentries=0 etime=0 = Previous installation of VBox VM (RHEL 6.3 with IPA ) did not have this problem. Check your iptables/firewall configuration on both hosts. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] migrate-ds fails with Can't contact LDAP server
On 13/08/2012 10:39 AM, Rob Crittenden wrote: Qing Chang wrote: Just installed a fresh RHEL 6.3 VM with IPA 2.2..0-16.el6 on our new ESXi host, after preparing migration mode as well as adding necessary objectclasses, tried to run following: ipa -d migrate-ds ldap://openldap:389 --bind-dn=cn=Manager --group-container=ou=group --schema=RFC2307 --with-compat --group-objectclass=posixGroup It failed promptly with this: = ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for CN=ipa1.sri.utoronto.ca,O=SRI.UTORONTO.CA ipa: DEBUG: handshake complete, peer = IP_of_ipa1:443 ipa: DEBUG: Caught fault 4203 from server http://ipa1.sri.utoronto.ca/ipa/xml: Can't contact LDAP server: ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: = /var/log/dirsrv/access shows: = [12/Aug/2012:07:53:26 -0400] conn=81 op=6 SRCH base=cn=accounts,dc=sri,dc=utoronto,dc=ca scope=2 filter=((uid=postfix)(objectClass=posixAccount)) attrs=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf nsUniqueId modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey [12/Aug/2012:07:53:26 -0400] conn=81 op=6 RESULT err=0 tag=101 nentries=0 etime=0 = Previous installation of VBox VM (RHEL 6.3 with IPA ) did not have this problem. Check your iptables/firewall configuration on both hosts. rob I have disabled iptables on ipa1, ipa1 and openldap can ping each other. Thanks, Qing ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] migrate-ds fails with Can't contact LDAP server
My sincere apologies: I forgot to start slapd on my openldap server... Qing On 13/08/2012 10:39 AM, Rob Crittenden wrote: Qing Chang wrote: Just installed a fresh RHEL 6.3 VM with IPA 2.2..0-16.el6 on our new ESXi host, after preparing migration mode as well as adding necessary objectclasses, tried to run following: ipa -d migrate-ds ldap://openldap:389 --bind-dn=cn=Manager --group-container=ou=group --schema=RFC2307 --with-compat --group-objectclass=posixGroup It failed promptly with this: = ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for CN=ipa1.sri.utoronto.ca,O=SRI.UTORONTO.CA ipa: DEBUG: handshake complete, peer = IP_of_ipa1:443 ipa: DEBUG: Caught fault 4203 from server http://ipa1.sri.utoronto.ca/ipa/xml: Can't contact LDAP server: ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: = /var/log/dirsrv/access shows: = [12/Aug/2012:07:53:26 -0400] conn=81 op=6 SRCH base=cn=accounts,dc=sri,dc=utoronto,dc=ca scope=2 filter=((uid=postfix)(objectClass=posixAccount)) attrs=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf nsUniqueId modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey [12/Aug/2012:07:53:26 -0400] conn=81 op=6 RESULT err=0 tag=101 nentries=0 etime=0 = Previous installation of VBox VM (RHEL 6.3 with IPA ) did not have this problem. Check your iptables/firewall configuration on both hosts. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NFS Ownership Gone
On Sun, Aug 12, 2012 at 11:49 AM, ondr...@s3group.com wrote: Check your idmapper configuration (idmapd.conf) - not quite sure if IPA cares about NFSv4 ID mapper configuration We have a winner! I had to manually specify the domain and realm, likely because they don't match my DNS configuration. Rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] backup plan
for business use? ie do you want support? Licencing might be fun I use the free vsphere v4 VMware ESXi at home which allows a modest 1 pc setupnot sure if that can be used in business setting.you get no support at least, but its the best Virtualisation platform Ive come across. So I boot off a 4gb USB key with a hardware raid 1 from 2 x 1tb disk setup and a 1 x 2 tb green disk off the motherboard for backups. You can do db2ldif outputs, then rsync or scp those off to a small 128meg ram debian guest which is how I plan to do it. In terms of checkpointing or snapshoting they this tech is best described as spawn of the devil and avoided...multiple snapshots of considerable age impacts disk i/o regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of bin.e...@gmail.com [bin.e...@gmail.com] Sent: Tuesday, 14 August 2012 11:14 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] backup plan Hi all, I've been doing a bit of research on back up and restore of FreeIPA and so far the best plan seems to be just back up everything That's fine except for back up everything doesn't lend itself to automation on a bare metal instance (which is what my primary and replica are). To be safe I would need to take the machine down rather than try to do a hot back up. (sync everything and backup from an inactive fs of better yet unmounted fs) That got me thinking, how about a vm? They are easy to stop, checkpoint, back up and restart. I want to run this by everyone and see what you think: Install a replica on a vm and then use THAT to capture back ups. If it looks like a reasonable idea, does anyone have a suggestion for which hypervisor would be best to use? (preferably FOSS) I only have experience with VirtualBox but I'm not sure it's up to this type of project? Thanks! -Aaron ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] backup plan
The libvirt range of tools works very well with KVM, and with virt-manager, they are easy to setup on the desktop or from a remote desktop. QEMU-KVM suports the QCOW2 and LVM storage back-ends, both of which have snapshot capabilities, and the virsh tool makes it easy and scriptable. They are all licensed under the GPL or LGPL. http://libvirt.org http;//linux-kvm.org http://qemu.org If you're using a Red Hat-based distribution, installing them should be as easy as yum install libvirtd virt-manager qemu-kvm or similar. - *question everything*learn something*answer nothing* Lucas Yamanishi -- Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A On 08/13/2012 07:14 PM, bin.e...@gmail.com wrote: Hi all, I've been doing a bit of research on back up and restore of FreeIPA and so far the best plan seems to be just back up everything That's fine except for back up everything doesn't lend itself to automation on a bare metal instance (which is what my primary and replica are). To be safe I would need to take the machine down rather than try to do a hot back up. (sync everything and backup from an inactive fs of better yet unmounted fs) That got me thinking, how about a vm? They are easy to stop, checkpoint, back up and restart. I want to run this by everyone and see what you think: Install a replica on a vm and then use THAT to capture back ups. If it looks like a reasonable idea, does anyone have a suggestion for which hypervisor would be best to use? (preferably FOSS) I only have experience with VirtualBox but I'm not sure it's up to this type of project? Thanks! -Aaron ___ 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
