Fedora Server Role D-BUS API Design Discussion

Tue Mar 25 17:14:21 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/24/2014 05:02 PM, Miloslav Trmač wrote:
> 2014-03-19 14:47 GMT+01:00 Stephen Gallagher <sgallagh at redhat.com 
> <mailto:sgallagh at redhat.com>>:
> 
> 2) We do not need to have a single generic API that will work for
> any conceivable Role. We've identified in the past that the
> selection of Featured roles will (for the conceivable future)
> remain a small, manageable list. For this reason, it is acceptable
> for the deployment and post-deployment configuration APIs to be
> entirely different between two roles. However, some functionality
> such as the backup and firewall queries should be stable between
> all roles.
> 
> 
> (I.e. the universal Role in the proposal doesn't even have a
> DeployRole method.)
> 
> I don't think this is efficient—every "universal" client (and there
> will be at least one or perhaps two, fedora-role-manage, 
> anaconda/initial-setup kickstart processing) would have to build 
> essentially the same abstraction over these role differences.
> 
> Wouldn't it be cleaner to have generic ValidateSettings(settings) 
> DeployRole(settings) as the abstraction used by the "universal"
> clients (with "settings" possibly having some universal settings,
> like our favorite firewall_enabled_after_deploy, but mostly
> role-specific, only using a standard format, perhaps JSON or some
> object graph with similar capabilities)?
> 

That's an idea. I'm not sure it's doing anything other than moving the
problem to the settings object instead of the method call, but *shrug*.

> The kickstart processor would only decode JSON and pass it to the
> API without understanding the contents; the Role-specific GUIs
> would have specific knowledge of settings to set—or specific Roles
> could even provide helper APIs, say
> AutodetectDefaultReplicaControllerSettings() to query the network
> and give the GUI information about what the role thinks is
> appropriate for the specific situation.)
> 
> 

*nod*

> 
> /org/fedoraproject/server/ServerRoleManager: * properties: *
> all_roles * staging_roles * active_roles
> 
> 
> Isn't this redundant with the per-role properties specifying the
> role's state?  (Even if it were redundant, it wouldn't be a huge
> deal—just a little work that we might be able to avoid.)
> 

Yes, see Jan's response as well. Better to leave that to the D-BUS
object manager.

> 
> 
> /org/fedoraproject/server/role/$ROLE: * properties: * loaded:
> Bool: whether the packages are installed * deployed:         Bool:
> whether the Role has been deployed
> 
> 
> (Nitpicking?  Rather an enum to eliminate possibilities of
> paradoxes like deployed & ~loaded.)
> 

See also Jan's reply. We also need a "deploying" state, so maybe an
enum is the right idea here.

> 
> * methods: * GetFirewallPorts: list of port/protocol pairs that the
> Role needs
> 
> 
> I'd much rather have FirewallRestriction enum (LocalhostOnly, 
> Unrestricted, Complex) or something like that, or, if we decided
> to depend on firewalld, an object reference to a firewalld service.
> Roles will be asking for ICMP, new IP protocols, and whatnot, and
> we don't need to start with that complexity in the API and the
> clients.
> 

Sorry, that was a little thin. Could you go into a bit more detail
here, please?

> 
> 
> e.g. /org/fedoraproject/server/role/DomainController * methods: *
> DeployPrimaryDomainController: Set up the first domain controller
> in the domain. * DeployReplicaDomainController: Add a new replica
> domain controller to the domain
> 
> See above.
> 
> 
> * AddCertificateAuthority:       Add a certificate authority to
> this domain controller * EnableDisableDNS:              Enable or
> disable the DNS server on this server
> 
> 
> This would of course work.  A philosophical question, though: would
> we rather move to closer to the "cattle" model, i.e.
> 
> settings = role.GetCurrentSettings() settings.enableDNS = False
> 
> role.Redeploy(settings)
> 
> ?
> 
> A "redeploy" is more work for the role, having to compare the
> settings with current deployment and apply them, but it also ensure
> that that code path works; with the individual configuration
> modification operations, the roles could still provide a
> GetCurrentSettings method, but we would have two completely
> separate paths (EnableDisableDNS vs. Deploy) to test, and the risk
> of them diverging.
> 

Hmm, but redeploy may not be possible (or idempotent) for all possible
setting changes. For example, if we deploy FreeIPA with a built-in
Certificate Authority, we can't redeploy without it, since the whole
system will have been predicated on it. (Not without having a
mechanism for redeploy being effectively a complete migration...
possibly between VMs or containers?)

> 
> 1) How do we handle configuring the Firewall? I think we want to
> have a Firewall object
> (/org/fedoraproject/server/RoleFirewallManager) available to query
> the firewall as a whole, but we may also want to be able to view
> and apply firewall rules from the Role objects directly. (Note: I'm
> not suggesting we need a complete firewall solution here. This
> should be a wrapper that deals only with the Roles). Firewalld 
> already provides a more comprehensive firewall interface for the 
> general case.
> 
> 
> If we provide a limited firewall facade so that Fedora Server can
> work without firewalld, IMHO it should literally be the simplest
> possible "role.FirewallPreventsNonLocalhostAccess" value; not even
> listing the ports involved.  If we provide something closer to a
> full-featured D-Bus API firewall, we might just as well require
> firewalld directly instead of writing a firewalld competitor.

I think my original statement failed to get my point across, but I
think I was pretty much saying the same thing you are. First of all,
we *did* agree to use firewalld as the proper solution. I just meant
that in terms of defining the Role-firewall interop, it should *not*
try to be a complete set of firewall rules. For that, we should allow
a Role to have a 'managed_firewall=False' setting[1] or something like
it, and that admins would be expected to handle the firewall
appropriately through firewalld/iptables. But if we *are* managing it,
it's probably acceptable for it to be essentially either blocked or
allowed on a whitelist of interfaces ('lo' being just a special case).
Anyone requiring more control than that should set
managed_firewall=False and do it themselves.

[1] The reason for this being so that UIs can note that this is under
manual control and also so that later Role upgrades don't attempt to
open or close ports.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMxuWwACgkQeiVVYja6o6MuYwCgim8J9OVKmmZ+69ClZa762GL6
sS4AnRns9c9OsH/LmpW0PwckV5xKXOv9
=+K0s
-----END PGP SIGNATURE-----