<div dir="ltr"><div><div>2014-03-25 18:14 GMT+01:00 Stephen Gallagher <<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>>:<br>> On 03/24/2014 05:02 PM, Miloslav Trmač wrote:<br>>> 2014-03-19 14:47 GMT+01:00 Stephen Gallagher <<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a><br>
>> Wouldn't it be cleaner to have generic ValidateSettings(settings)<br>>> DeployRole(settings) as the abstraction used by the "universal"<br>>> clients (with "settings" possibly having some universal settings,<br>
>> like our favorite firewall_enabled_after_deploy, but mostly<br>>> role-specific, only using a standard format, perhaps JSON or some<br>>> object graph with similar capabilities)?<br>><br>> That's an idea. I'm not sure it's doing anything other than moving the<br>
> problem to the settings object instead of the method call, but *shrug*.<br><br>Right, it would be even better to provide role-specific APIs (or a generic API with schema enforcement) to change values within the settings object :) in order to make typos in settings names obvious, and that point it is really similar.<br>
<br>It does only one structurally significant thing: encode the "settings format" (JSON/whatever) as a canonical way to describe/dump/persistently store role deployment configuration, giving the API users precisely the same facilities they have during installation.<br>
<br><br>>> * methods: * GetFirewallPorts: list of port/protocol pairs that the<br>>> Role needs<br>>><br>>><br>>> I'd much rather have FirewallRestriction enum (LocalhostOnly,<br>>> Unrestricted, Complex) or something like that, or, if we decided<br>
>> to depend on firewalld, an object reference to a firewalld service.<br>>> Roles will be asking for ICMP, new IP protocols, and whatnot, and<br>>> we don't need to start with that complexity in the API and the<br>
>> clients.<br>><br>> Sorry, that was a little thin. Could you go into a bit more detail<br>> here, please?<br><br>Stepping back a little, the role <i>implementation</i> and <i>external API</i> should be different. The implementation obviously does need to actually contain port numbers and the like somewhere, but I don't think we want them in the role's public API.<br>
<br></div>The reason is that this introduces too much complexity into the API, at a level that isn't interesting to many important users of the API. The complexity is in all the things a role might need (TCP ports, UDP ports, IP protocols, specific multicast addresses, perhaps even conntrack modules), and the presumed callers of a "Role deploy API" just don't care, they want the role deployed firewalled/not firewalled, and a service dashboard needs to to know whether it has been firewalled. Receiving a list of half-a-dozen different individual firewall concepts to check isn't all that helpful, the public API should be able to give a simple yes/no answer (well, a "yes/no/"it's complicated" answer, which are the badly-explained LocalhostOnly/Unrestricted/Complex values above).<br>
<br></div>Depending on firewalld, it seems simplest for roles to provide firewalld services, and refer to callers to them. We might still want a simple facade above, providing only the ability set LocalhostOnly/Unrestricted, and to receive current status as one of the three values. That would be appropriate for a simple dashboard, more detailed management would be done on the firewalld service object directly using the firewalld API.<br>
<div><div><div><br><br>>> * AddCertificateAuthority: Add a certificate authority to<br>>> this domain controller * EnableDisableDNS: Enable or<br>>> disable the DNS server on this server<br>
>><br>>> This would of course work. A philosophical question, though: would<br>>> we rather move to closer to the "cattle" model, i.e.<br>>><br>>> settings = role.GetCurrentSettings() settings.enableDNS = False<br>
>> role.Redeploy(settings)<br>>> ?<br>>><br>>> A "redeploy" is more work for the role, having to compare the<br>>> settings with current deployment and apply them, but it also ensure<br>
>> that that code path works; with the individual configuration<br>>> modification operations, the roles could still provide a<br>>> GetCurrentSettings method, but we would have two completely<br>>> separate paths (EnableDisableDNS vs. Deploy) to test, and the risk<br>
>> of them diverging.<br>>><br>><br>> Hmm, but redeploy may not be possible (or idempotent) for all possible<br>> setting changes.<br><br></div><div>It's always possible to delete all data and start fresh :) An API to redeploy that doesn't delete data needs the option to fail, sure—but any functionality that can be done using a GetValue/SetValue-like API should be equally possible to do using a Redeploy model; in the role-already-deployed case, it's just a series of<br>
> if (settings.option_name != role.GetValue(option_name))<br></div><div>> role.setValue(option_name, settings.option_name)<br></div><div>and<br></div><div>> if (settings.immutable_option_name != role.GetValue(immutable_option_name)<br>
</div><div>> fail;<br></div><div>snippets.<br></div><div><br></div><div>So semantically the two are sort of equivalent, this is primarily a matter of how we want to encourage the users to work with the system: keep a pet and modify it over time with the API, or have a settings file managed in a VCS somewhere and use the API only to sync the VCS and the deployment?<br>
</div><div><br><br>>> If we provide a limited firewall facade so that Fedora Server can<br>>> work without firewalld, IMHO it should literally be the simplest<br>>> possible "role.FirewallPreventsNonLocalhostAccess" value; not even<br>
>> listing the ports involved. If we provide something closer to a<br>>> full-featured D-Bus API firewall, we might just as well require<br>>> firewalld directly instead of writing a firewalld competitor.<br>
><br>> I think my original statement failed to get my point across, but I<br>> think I was pretty much saying the same thing you are.<br></div><div>I think so too.<br></div><div><br>> First of all,<br>> we *did* agree to use firewalld as the proper solution. I just meant<br>
> that in terms of defining the Role-firewall interop, it should *not*<br>> try to be a complete set of firewall rules. For that, we should allow<br>> a Role to have a 'managed_firewall=False' setting[1] or something like<br>
> it, and that admins would be expected to handle the firewall<br>> appropriately through firewalld/iptables. But if we *are* managing it,<br>> it's probably acceptable for it to be essentially either blocked or<br>
> allowed on a whitelist of interfaces ('lo' being just a special case).<br>> Anyone requiring more control than that should set<br>> managed_firewall=False and do it themselves.<br><br></div><div>We could even have the managed_firewall=False implicit, as "service is not assigned to the Public or Drop zones" (... which would leave even the "allow on a whitelist of interfaces" case up to non-Role-API firewalld calls; I have no idea whether this would be appropriate).<br>
</div><div> Mirek<br></div></div></div></div>