Thanks for the feedback Martin. > I would actually do it the opposite way and open the ports after the FreeIPA > server is fully configured. After all, I do not think we want to open the > ports when the server is just half-configured and for example some ACIs are > missing.
My thinking was that nothing would be listening on these ports if the install doesn't succeed, but there's really necessity to modify the firewall configuration early. (All of the internal install communication will be over a local interface (to netfilter) and unblock anyways. I don't have any problem in delaying firewall configuration to the end of install. > We print list of ports that FreeIPA uses at the end of ipa-server-install > process. I would report firewalld/iptables related information there. (We for > example also create here example BIND zone content and pass it to user, it > may make sense to have this around this location). Agreed and noted. > Hm, I would personally prefer to avoid complicating the feature and start > with something easy to configure and straightforward. We can always extend it > if we see an interest. In general, ipa-server-install does the basic, > functional and recommended configuration - fine tuning is left for the > administrator to continue after that. But I will leave that up to you and > other developers. > I think it would be better to have them all in a single XML file though (like > freeipa.xml), less chance of name collisions and we would have all ports in > one place. > Not sure about the names, but it may be good idea to prefix the port names > with "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to > avoid collisions. My thinking here was that it is quite cumbersome to restrict a FirewallD service to specific networks (i.e. taking a service assigned to a zone and replacing it with rich rules that do allow source restrictions). I'm not sure how people actually use FreeIPA outside my use-case, but if users are unable to restrict server-ipa-install firewall configuration to specific networks, they'll most likely need to depend on an external firewall (e.g. Amazon's EC2 firewall). On the other hand, I totally agree with your apprehension to add more options to ipa-server-install. I'll prepare two patch sets that just add the service (without source restrictions) and another that allows network restrictions. That will make it easier for the project to choose the correct solution and have an implementation for either solution. As to the specific service name, FirewallD already has most service definitions that FreeIPA needs (http(s), kerberos, kpasswd, ntp, etc.). I would imagine that these services will always be available, but I'm going to inquire with the FirewallD project to make sure. If we are sure those services will always be there, I would greatly prefer to use those built-in services as much as possible. For example, FirewallD includes a ldap service, and I don't think there's a good reason to include a freeipa-ldap that covers the same ports. > Ok. We also should not crash if the directory is not available. There are > some recommendations about the XML contents in a Bugzilla comment: Yep. I'm always vigilant to catch exceptions. Thanks, Justin On Fri, Apr 4, 2014 at 1:26 AM, Martin Kosek <mko...@redhat.com> wrote: > On 04/03/2014 06:33 PM, Justin Brown wrote: >> This discussion morphs out of some questions that I asked over on the >> user's mailing list: >> https://www.redhat.com/archives/freeipa-users/2014-April/msg00033.html. >> It's also related to Trac #2110. (The subject says ipa-server-install, >> but this will also apply to replica installs, too.) >> >> What is the expected compatibility with RHEL 5 and 6? Neither of those >> comes with FirewallD. Integrating with iptables is bound to be messy, >> and I feel like there's too many ways to get into trouble with >> destroying a user's iptables configuration. (Due to the unsafety of >> `iptables-restore`, there's no way to guarantee that the user's >> configuration will persist through a reboot.) Seeing as FirewallD has >> been the default in Fedora since 18 and will be in RHEL 7, it seems >> like a reasonable thing to do. Would there be opposition to making >> FirewallD the only firewall that ipa-server-install will configure, >> and just print out iptables (or iptables-save fragments) for >> non-FirewallD systems? > > Right. I do not think there will be opposition for firewalld. As you said, it > is present in recent Fedoras and RHEL-7.0 and we do not plan to release > FreeIPA > 4.0 in older systems than that. > > >> The implementation should be pretty simple and straightforward, but I >> wanted to run over it briefly to see if there were any initial >> feedback. > > +1. > >> First, there's a question of dependence. FirewallD exposes a DBus >> interface on the system bus. While it is possible to interact with >> shell commands, I would greatly prefer to make use of DBus directly. >> That will require pulling in python-dbus as a package dependency. > > I personally have nothing against using python-dbus interface (dbus-python > package in Fedora), it is programmatically easier to control that parsing > output from commands. > >> >> Second, FirewallD operates on "zones" to which interfaces are >> attached. To apply any sort of configuration, we'll need to attach a >> freeipa-server FirewallD service to the proper zone. During the >> current installation program, we already know the server's IP address >> from a call to installutils.get_server_ip_address(). I'll need to >> resolve on which interface this IP resides, and then FirewallD can >> tell me which zone should be modified. It is possible to scrape the >> output of `ip address` to determine, but that's a messy solution. The >> better method is to use the NetworkManager DBus interfaces to query >> for this information. This gets back to my compatibility question >> above. Fedora doesn't really work without NetworkManager anymore, and >> I assume that will hold for RHEL 7. > > Right, I personally do not see a problem here in your thoughts. > >> Third, do we want to allow the user to limit the network access? I >> think that it makes sense to allow users to specify a network (e.g. >> 192.168.0.0/16) to limit accessibility to their FreeIPA server. Yet, >> there's always some trade-off to adding more options to >> ipa-server-install. > > Hm, I would personally prefer to avoid complicating the feature and start with > something easy to configure and straightforward. We can always extend it if > wee > see an interest. In general, ipa-server-install does the basic, functional and > recommended configuration - fine tuning is left for the administrator to > continue after that. But I will leave that up to you and other developers. > >> Fourth, FirewallD configuration is simple and quick, so I think it >> makes sense to get it out of the way early in the install process. I'm >> thinking right after ipaservices.backup_and_replace_hostname() (line >> 1,038) runs. > > I would actually do it the opposite way and open the ports after the FreeIPA > server is fully configured. After all, I do not think we want to open the > ports > when the server is just half-configured and for example some ACIs are missing. > >> >> >> Implementation Walkthrough >> ---------------------------------------- >> >> ~$ ipa-server-install --firewall --firewall-allow 192.168.0.0/24 >> --firewall-allow 192.168.1.0/24 [...] >> [skip to line 1038] >> 1. Detect if FirewallD is running via DBus. (If not generate sample >> iptables rules, print/log them, and continue normal install.) > > We print list of ports that FreeIPA uses at the end of ipa-server-install > process. I would report firewalld/iptables related information there. (We for > example also create here example BIND zone content and pass it to user, it may > make sense to have this around this location). > > On the beginning of the installation (in the interactive part of > ipa-server-install) I would just check if firewalld is available and if not, I > would print a warning to user so that he can for example exit the wizard and > fix firewalld before continuing. > >> 2. Use NM DBus to resolve IP->interface. (If NM not available, >> potentially fallback to scrapping `ip a`.) >> 3. Use FirewallD DBus to resolve interface to zone. >> 4. FreeIPA will include a service XML template (like >> dsinstance.INF_TEMPLATE) that specifies the necessary ports/protocols. >> Write this service file to /etc/firewalld/services/. > > Ok. We also should not crash if the directory is not available. There are some > recommendations about the XML contents in a Bugzilla comment: > > https://bugzilla.redhat.com/show_bug.cgi?id=885483#c2 > > I think it would be better to have them all in a single XML file though (like > freeipa.xml), less chance of name collisions and we would have all ports in > one > place. > > Not sure about the names, but it may be good idea to prefix the port names > with > "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid > collisions. > > >> 5. If the user provided --firewall-allow args, generate rich rules >> based on the template, and add them to the proper zone. If not, the >> service is still added as a rich rule (for consistency and ease of >> uninstall). > > Ok. > >> >> >> Thanks, >> Justin > > I think you are on a good path Justin, good luck! > > Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
