On 04/08/2014 02:42 PM, Rob Crittenden wrote:
Justin Brown wrote:
Dmitri,
I'd be more than happy to, but I'm having trouble figuring out where
it should go. Could you send me a link to a similar design page?
I'd put it under here: http://www.freeipa.org/page/V4_Proposals
There is a template at http://www.freeipa.org/page/Feature_template
So maybe something like http://www.freeipa.org/page/V4/Firewalld
Rob has beaten me to it, sorry.
I reviewed the page.
Pretty informative, thank you.
Couple comments:
a) No replication impact.
b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2
--forwarder=192.168.0.3
I think you want to add the --firewall at the end
c) Please be consistent in one place you use freeipa-.. in other just
ipa-.. but this is minor
d) No commands or config options.
e) It would be really nice to have a bit more information about what
kind of methods and calls you plan to use to interact with
NetworkManager and FirewallD. If you can spell out something like:
Logic:
Call NM and get blah using method X
For each port in the list
call FirewallD method Y
f) What would be error handling if something goes wrong? Would it abort
or create a special message?
g) How should it behave if some ports are already open? Will it print a
message or do it silently?
h) There is actually impact on restore, restore might also now check
that ports are configured in the same way they have been.
i) We should probably also record in the rollback log the ports that
have been opened and close them back if we have to roll back
installation or uninstall server.
j) We should differentiate whether the CA is being installed and open CA
ports only if the CA component is there.
k) We are planning to add other components like DRM and TPS We need to
figure out if we would have to do something on the upgades when we add
those services to add additional ports.
l) I suspect that there be cases where different tools and scripts in
IPA would need to check and open ports. This means that we should
probably create a reusble library that would provide check and update
methods.
This is so far what came to mind.
Thanks for doing it!
Really appreciated.
Dmitri
rob
Thanks,
Justin
On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal <d...@redhat.com> wrote:
On 04/07/2014 09:00 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
On 4.4.2014 09:17, Martin Kosek wrote:
On 04/04/2014 09:04 AM, Justin Brown wrote:
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.
If ipa-server-install does succeed without configuring the
firewalld,
then we
will indeed have no other option than to do it early.
I am thinking that we may want to put all the firewalld
configuration
in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the
installation.
Something like:
...
Configuring Firewall (firewalld)
[1/2]: looking up the right zone
[2/2]: allowing ports
Done configuring Firewall (firewalld).
...
The Service class derived object can be really simple, we would
just
reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.
It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.
In general I agree with the idea, thank you Justin for working on
that!
I would like to emphasis the necessity to work without
NetworkManager
and
FirewallD. New dependencies make Debian folks unhappy ...
On the other hand, it is perfectly fine to skip firewall
configuration
if
NM/FirewallD/DBus is not available.
Have a nice day!
Should be easy, probe for the dbus firewalld service and just skip
(not
error out) if it is not there.
Set a variable in that case that will cause the installer to throw
the
classic banner we have now which warns you about what ports need
to be
opened at the end of the install.
Probably just need to spit out a large, preferably flashing warning
that
the firewall has not been automatically configured. Perhaps even
multiple
times: one in-line and one at the install summary at the end.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Thanks for looking into this!
Would it be possible to summarize this thread in a design page on
the wiki?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
