Re: [Freeipa-users] Are replica gpg files reusable?
This type of behavior is generally beyond what Puppet should do because it involves two systems retrieving information directly from one another and the puppet master can't reasonably serve as the repository of that information. Using a separate tool will likely work better. There's at least two ways that you could go with this. 1) Script and SSH The IPA master has a simple script that will just invoke ipa-replica-setup with the proper options and passwords. The new replica will get a Puppet exec resource that will SSH into the master, run the script, scp the resulting replica file, and invoke the replica install with that info. The problem with this solution is that credentials are sprinkled all over the place, and security is not good. Your Puppet manifest will need SSH credentials/keys, the master script needs IPA credentials, and the Puppet logs for the exec resource may contain passwords depending on how you implement it. 2) MCollective You'll need to write a MCollective agent that resides on the replica and master. The new replica will get a Puppet exec resource that will run the MCollective agent. The agent will connect to the master and invoke its half of the agent, which will create the replica file and read it back to the replica. Then, there's a second Puppet exec resource that will run ipa-replica-install. Security is better for a couple of reasons. First, ACLs can be used with MCollective to limit who can run this agent. Second, there's no SSH keys/passwords to exchange. Third, we can store the IPA DM and admin passwords in puppet facts (this works for the previous solution, too.). Both solutions are pretty simple and will get the job done, but I think the second one is better but does require MCollective installed and Ruby knowledge. On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden rcrit...@redhat.com wrote: Dmitri Pal wrote: On 04/25/2014 05:06 AM, Petr Spacek wrote: On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? The downside is you could end up issuing a whole ton of certificates for the same service, the majority of which aren't being used, and are unrevoked. rob ___ 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] Partial Domain Authority
I'm sure that I'm doing this very wrong, but I'm wondering if anyone can offer any solutions. I currently have a relatively small domain that's used internally. Let's say fandingo.org. This domain covers various class C networks on 192.168.0.0/16. Currently, there's an Active Directory server that provides internal (and forwarding) DNS for fandingo.org. I'm in the experimentation phase with FreeIPA in this environment and don't want to modify anything outside of FreeIPA for the time being. FreeIPA is setup with DNS and has the fandingo.org domain controllers setup as forwarders. I have my laptop joined to the FreeIPA domain, but that's where the problem starts. I can correctly resolve any *.fandingo.org resource in FreeIPA. The problem is that I want to resolve *.fandingo.org resources that are defined in the Active Directory DNS. Does anyone know how I can configure FreeIPA/BIND to forward all requests (even those for its own domain) that it can't satisfy rather than returning NXDOMAIN? Thanks, Justin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Server Ports
Petr, I'll try another replica for testing tomorrow, and unfortunately the logs were purged when I reinstalled. The error message was not helpful and said something along the lines of CA installation failed, but did not list any reason. I'll get you the exact message tomorrow. I'll also try some more network tests as I have all of the ports that you listed plus some additional Dogtag ports, which I've come to understand are now proxied through 7389. Patches are welcome :-) Yes, you've got me. ;) I'll review the Firewalld packaging in more detail and try to come up with a workable solution. It's not currently possible to do meta-services in firewalld, and I'm sure the FreeIPA developers don't want a hard dependency on firewalld via a hypothetical freeipa-server-firewalld dependency. I'm sure some solution is possible -- maybe even just in the documentation. Thanks, Justin On Thu, Apr 3, 2014 at 2:25 AM, Petr Spacek pspa...@redhat.com wrote: On 3.4.2014 07:55, Justin Brown wrote: I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). http://www.freeipa.org/page/Documentation is the ultimate source of documentation. Latest documentation build is on http://www.freeipa.org/docs/master/html-desktop/index.html I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except dogtag, which I made myself and is defined at the end. ipa-replica-conncheck utility should tell you what is missing. On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Patches are welcome :-) -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Server Ports
I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except dogtag, which I made myself and is defined at the end. rule family=ipv4 source address=192.168.0.0/16/ service name=http/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=https/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=dogtag/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=dns/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=kerberos/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=kpasswd/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ldap/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ldaps/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ntp/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ssh/ accept/ /rule Services dns, kerberos, and kpasswd are TCP+UDP. Service ntp is UDP only. The others are TCP only. = services/dogtag.xml: ?xml version=1.0 encoding=utf-8? service port protocol=tcp port=9180/ port protocol=tcp port=9443/ port protocol=tcp port=9444/ port protocol=tcp port=9445/ port protocol=tcp port=9446/ port protocol=tcp port=9701/ port protocol=tcp port=7389/ /service = On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Thanks, Justin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 3.1.5 User Guide published!
I'm also a big fan of the documentation and reference it frequently. I know that documentation is not release notes, but it would be nice to have some relation between the two. Two ideas: * If the docs are released at the same time as the software, the release notes should include links to the relevant sections of the documentation. * For particularly large features, it may make sense to put a *temporary* note that feature X is new in version Y (and the note would be removed in Z or Z+1). The second idea is taken from Python's documentation and how they do an excellent job of specifying when certain features were added. Now, FreeIPA doesn't have near the varying number of versions and legacy environments that a programming language has. That's why I wouldn't want tags like added in 2.1.0 still hanging around. Lastly, the documentation needs some release notes of it's own. The document change history isn't that useful. Two ideas: * A better what's new in the docs page that specifically links to new sections. * Asterisks or some other markup on the table of contents that mark links that have substantively changed. A user browsing the table of contents may become interested in checking out a new feature since she knows that the typical high-quality FreeIPA documentation is right there to help. How would the freeipa-docs package work? PDFs in a directory or would they be accessible from my FreeIPA web interface? I would definitely be interested in the package if its the later. Otherwise, I'll probably stick to the Fedora Docs website. Excellent work. Thanks Deon and company. Lastly, Fedora 19 is nigh upon us. Time to dive right back into the fire. Cheers, Justin On Tue, Jun 25, 2013 at 2:10 PM, Andrew Tranquada andrew.tranqu...@mailtrust.com wrote: I am aware of the documentation and have found it invaluable so far, one of the better documented projects out there. Personally, I would love this guide released frequently and really like the idea of having the documentation in a sub package. Thanks!!! On 6/25/13 12:07 PM, Martin Kosek mko...@redhat.com wrote: Hello, The FreeIPA Team has published a User Guide for FreeIPA 3.1.x series introduced in Fedora 18: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/index.htm l Big thanks to Deon Lackey who was the main contributor for this docs! On a side note, FreeIPA team is in process of re-considering and improving our user/development documentation and I am just curious - are FreeIPA users well aware of this documentation, do you use it frequently when you seek FreeIPA related information? Any ideas for improvements? Do you want to continue us to release this guide frequently with FreeIPA releases? For sake of future, we are also considering releasing this User Guide right during FreeIPA release, in a special subpackage (e.g. freeipa-docs). Thanks for any feedback. -- 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 ___ 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
Re: [Freeipa-users] Anyone tried to authenticate Jenkins user through freeIPA?
William, I am no FreeIPA expert, but I did find some instructions for configuring LDAP with Zimbra for FreeIPA. http://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA Have you tried something similar? Regards, Justin On Mon, Jun 24, 2013 at 5:35 PM, William Muriithi william.murii...@gmail.com wrote: Hello all, I have been struggling to get jenkins authenticating through FreeIPA and it seem this is currently not possible. The problem is, jenkins is not capable of using Kerberos as far as I can tell. Also, I am not sure FreeIPA can authenticate directly through LDAP, as far as I understand, LDAP is only used for authorization and authentication is through kerberos. I am planning to set up apache and run it as reverse proxy for Jenkins as a work around. Would this be the best way forward or would anyone know of a better way around this? I have noticed that the FreeIPA project uses jenkins, how have you guys got around this? Thanks in advance. Regards, William ___ 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
