fedora-meeting-1
LOGS
14:59:04 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2014-03-18)
14:59:04 <zodbot> Meeting started Tue Mar 18 14:59:04 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:06 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
14:59:06 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
14:59:11 <sgallagh> #topic roll call
14:59:14 * nirik waves. morning.
14:59:16 <sgallagh> .hellomynameis sgallagh
14:59:17 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:59:39 <adamw> .hellomynameis adamw
14:59:40 <adamw> grr
14:59:42 <zodbot> adamw: adamw 'Adam Warski' <adam@warski.org>
14:59:43 <adamw> .hellomynameis adamwill
14:59:45 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
14:59:52 <adamw> CURSE YOU, WARSKI
14:59:59 <adamw> CURSE YOOOOOOOOUUUUUUUUUUU
15:00:33 <sgallagh> #info adamw curses Warski
15:00:38 <sgallagh> #undo
15:00:38 <zodbot> Removing item from minutes: INFO by sgallagh at 15:00:33 : adamw curses Warski
15:00:41 <sgallagh> (I'm not that mean)
15:00:44 <mitr> Hello
15:01:48 * sgallagh looks for one more for quorum
15:01:56 <tuanta> .fas tuanta
15:01:56 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:02:02 <tuanta> hello
15:02:20 * tuanta is here
15:02:36 <sgallagh> Ok, let's get started and folks can filter in as they do
15:02:44 <sgallagh> #topic Server Role PoC
15:03:03 * jzb lurking
15:03:20 <sgallagh> Last week, we left off with a tentative plan to have simo, nirik and I meet up to look into hacking up a proof-of-concept straw-man for the Domain Controller ROle
15:03:30 <sgallagh> That meeting did not happen, but I've been hacking on it anyway
15:03:40 <nirik> cool. yeah, I have been busy... sorry.
15:03:50 <tuanta> cool
15:04:06 <adamw> anywhere we can see?
15:04:52 * mizmo-out here sorry
15:04:59 <simo> sigh true
15:05:14 <sgallagh> adamw: It's still pretty rough, but I'm going to put up my WIP either tonight or tomorrow, depending on time
15:05:44 <sgallagh> I'm just hacking up a D-BUS service with dbus-python that implements a rough set of the interfaces we want
15:05:54 <nirik> excellent!
15:07:08 <adamw> cool.
15:07:23 <sgallagh> Might not be the worst idea for us to discuss the preferred interface today, then
15:07:51 * adamw prepares to nod intelligently
15:07:53 <simo> sgallagh: do you have an idea what the API should look like yet ?
15:08:08 <sgallagh> I'm looking at base classes that will abstract a set of common methods that the individual Roles need to implement
15:08:37 <sgallagh> The two primary ones I'm currently calling PreloadRole and DeployRole, which is basically the package-installation and config-and-start APIs we've discussed before
15:09:47 <sgallagh> I've also got GetFirewallPorts which is a thin wrapper around getting the firewall properties from the D-BUS object
15:10:17 <sgallagh> My thought is that the Role should only tell us what it wants, and that we should have a separate interface to firewalld to check whether it's available and on what interfaces
15:10:39 <sgallagh> (I think that agrees with mitr's statements in the past as well)
15:11:03 <simo> sgallagh: sounds ok to me
15:11:03 <mitr> sgallagh: I wouldn't mind roles building a facade over firewalld
15:11:03 <sgallagh> You know what, give me two minutes, I'll push this to github now (warts and all)
15:11:37 <mitr> sgallagh: I'd prefer for it to refer to firewalld services though, instead of having its own port list (... which would inevitably be extended to support non-UDP/TCP IP protocols, and ICMP, and ...)
15:12:20 <sgallagh> mitr: I thought the firewalld 'services' were hard-coded. Are they definable/configurable through the public interface?
15:12:21 <nirik> I think we want to try and avoid re-implementing firewalld. ;)
15:13:03 <mitr> sgallagh: /usr/lib/firewalld/services/*.xml, firewalld.service(5)
15:13:49 <sgallagh> #url https://github.com/sgallagher/server_roles_poc
15:13:57 <simo> sgallagh: so you'd just return a set of protocol/port pairs ?
15:13:57 <adamw> sgallagh: it uses a /usr, /etc, /home config override system, like is currently in vogue, iirc
15:14:17 <sgallagh> #info mitr notes that firewalld 'services' are configurable using local files
15:14:30 <sgallagh> simo: That's pretty much what I'm doing right now, yes.
15:14:32 <adamw> sgallagh: so i think you could override the definition of a service for firewalld purposes, but it wouldn't be entirely obvious what was going on. you can certainly create new ones.
15:15:05 <mitr> hm, having httpd and fedora-role-httpd would be rather confusing
15:15:19 <sgallagh> (Be aware, the above is one day's frantic hacking with no prior knowledge of dbus-python)
15:15:19 <simo> sgallagh: PreloadRole, it's unclear to me why the caller should pass in a list of packages ?
15:15:23 <mitr> Can we bet on being lucky and having the non-role and role configs be the same/
15:15:30 <sgallagh> simo: They shouldn't
15:15:47 <sgallagh> simo: The child classes should call the super-class with the appropriate set
15:16:21 <simo> ok
15:17:17 <sgallagh> mitr: Well, a role may be a superset of other services
15:17:43 <sgallagh> i.e. the Domain Controller role is going to need to enable httpd, ldap, kerberos, dns...
15:17:59 <mitr> sgallagh: right, that shouldn't be a problem ("domain-controller" != "dhcpd" or "freeipa").  I was worried about wordpress-the-package vs. wordpress-the-role
15:18:22 <sgallagh> Wordpress-the-role is something I don't want to deal with immediately :)
15:18:31 <mitr> sure :)
15:19:17 <adamw> are we sure we're only going to have precisely one possible firewall configuration per role? (just thinking about the name of GetFirewallPorts)
15:19:38 <adamw> trying to think of cases where the names might be too generic and we wind up having to rename them or have misleading ones later
15:20:04 <sgallagh> adamw: Can you come up with an example? I don't follow.
15:20:19 <mitr> adamw: I do think we should have a single "object that can be enabled" per role, yes.  The list of the ports might change depending on role configuration.
15:20:24 <sgallagh> This is really just the list of ports the Role is listening on that it doesn't consider purely internal
15:20:30 <simo> adamw: no we are not
15:20:42 <simo> sgallagh: freeipa server without DNS or CA
15:20:43 <adamw> i'm just thinking it's the kind of thing where maybe we work out later that some deployments of a role might want port X open but others not, or something like that
15:20:47 <simo> == different set of port
15:20:49 <simo> s
15:20:56 <adamw> a case where we have, I dunno, MandatoryFirewallPorts and OptionalFirewallPorts, or something...
15:21:02 <adamw> right, good example.
15:21:04 <sgallagh> simo: Yes, but the set of ports wouldn't be different on the same deployment
15:21:16 <simo> sgallagh:  ?
15:21:20 <adamw> mm, true
15:21:21 <mitr> simo: Would the user want to enable/disable the _firewall ports_, or the functionality behind them?
15:21:22 <sgallagh> Sorry, I see the disconnect here
15:21:38 <simo> mitr: both go hand in hand
15:21:41 <sgallagh> The idea is that GetFirewallPorts is the *current* state of needs for the Role. Not a fixed value.
15:21:57 <sgallagh> If the Role has optional components that open additional ports, this property gets updated to include it.
15:22:05 <simo> sgallagh: ok and that is determined how ? Do we store some data or the function is expected to do some probing ?
15:22:10 <sgallagh> (if and only if that option is in place)
15:22:16 <simo> I guess probing is the only sane way
15:22:25 <sgallagh> No
15:22:28 <simo> no ?
15:22:41 <simo> how do you know if you need to open DNS ports ?
15:22:43 <sgallagh> Part of DeployRole needs to update the set of ports at the end of operation
15:22:44 <mitr> simo: We are supposed to have a remote configuration API, so we need to have some local configuration storage (native to the underlying package or supplied by the role)
15:22:57 <simo> sgallagh: it would go out of sync *very* quick
15:23:00 <sgallagh> and by extension whatever function we have that deploys optional components will need to update that
15:23:02 <sgallagh> simo: Why?
15:23:15 <simo> sgallagh: because in freeipa services are controlled via LDAP
15:23:30 <simo> I can change the list of services for a server from a completely different server just writing to LDAP
15:23:42 <mitr> simo: can't the role query the same LDAP?
15:23:46 <sgallagh> ah, right. I forgot about that...
15:24:09 <sgallagh> Yeah, so in the Domain Controller case, we'd probably want to override the superclass and implement a proper lookup.
15:24:39 <sgallagh> Of course, that means we can't push a PropertiesChanged signal on port changes
15:25:11 <simo> sgallagh: we could have a persistent search but it seem kind of a waste of resources
15:25:25 <simo> sgallagh: also the change is not immediated
15:25:41 <simo> we should probably just check if named is running or not
15:26:00 <simo> or even better if netstat says someone is listening on 53
15:26:04 <mitr> simo: Could we hook up the role to the freeipa reconfiguration mechanism (so that it pings the role at the same time that it detects the change and starts/stops named)?
15:26:17 <sgallagh> simo: That doesn't help us if some other process (or attacker) took that over...
15:26:27 <simo> mitr: do you want to write plugins to freeipa's LDAP server ? don;t think oit makes sense
15:26:48 <simo> sgallagh: if an attacker was able to open 53 it means he got root and it is already game over
15:26:57 <mitr> (cockpit is enthusiastic about the GUI immediately reflecting changes that are done by non-cockpit tools)
15:27:10 <sgallagh> simo: Sure, but that won't be guaranteed for the general case
15:27:14 <simo> mitr: then we should listen on netlink to see if nmaed opens port 53
15:27:17 <mitr> simo: If we want the firewall managed by the role, and the role needs to know if the configuration changes...
15:27:17 <simo> and react to that
15:27:26 <sgallagh> We might have a > 1024 port for some other Role
15:27:30 <simo> mitr: the role knows
15:27:37 <simo> sgallagh: we could write data out of ipactl
15:27:48 <simo> ipactl decides what services to start or not
15:27:48 <mitr> simo: OK, listening on netlink works - we need the role to notice, _how_ it notices is role-specific implementation
15:27:59 <simo> sgallagh: so I guess we can have a local list
15:28:09 <sgallagh> simo: Question about changes to the service list: does it only take effect on ipactl restart?
15:28:13 <simo> we just need to make ipactl update it when it strats/restarts services
15:28:19 <simo> sgallagh: yup, so far
15:28:32 <sgallagh> ok, then we could probably hook in there.
15:28:35 <mitr> Yes
15:28:59 <mitr> (We don't actually need a local _copy of the list_ - we can live with the only copy with LDAP; we just need to know when a change either happens or takes effect)
15:31:12 <sgallagh> Ok, so let's back up and talk about the set of interfaces we need first
15:31:23 <sgallagh> And try to avoid digging into the implementation for a little while :)
15:32:00 <mitr> sgallagh: 1) is DeployRole intended to be idempotent?  2) Is this API an implementation detail or the API remote callers would be interacting with?
15:32:42 <mitr> If the latter, I'd expect DeployRole to e.g. deal with the firewall already; the API shouldn't be asking for a 10-step checklist
15:32:51 <sgallagh> 1) Good question. I haven't thought about that yet.
15:33:23 <sgallagh> 2) I'm expecting this to be the API that fedora-role-manage CLI and Cockpit would talk to
15:35:02 <sgallagh> mitr: Yes, we may want to have DeployRole include at least an option to have it go and tell firewalld to give it the ports.
15:35:30 <sgallagh> But as we'll still want to be able to manipulate the firewall configuration later, I figured being able to retrieve the desired ports was valuable
15:35:39 <mitr> yes
15:35:56 <sgallagh> I'm not sure if we can guarantee that DeployRole is idempotent, because that's going to depend heavily on the underlying tech
15:36:16 <simo> sgallagh: so I am trying to understand what DeployRole would do in the freeipa case
15:36:28 <simo> sgallagh: our installation script is allowed to ask questions and requires inputs
15:36:33 <sgallagh> simo: Essentially it would call ipa-server-install
15:36:34 <simo> how would that work ?
15:36:44 <mitr> ... actually, the _API_ is perfectly fine.  For implementation, we might want the superclass to handle the firewall automatically (depending on a setting that is shared by all roles) - DomainControllerRoleObject would not touch the firewall, but set a property indicating the default state, and the API implementation of DeployRole would modify the state depending on both settings and the desired default state.
15:36:55 <sgallagh> We would feed it the necessary information for an unattended install of freeipa
15:37:24 <simo> sgallagh: so you have to do all the detection ipa-server-install normally does and then ask questions if it fails ?
15:37:29 <mitr> ... if the sufficient information is available in the settings.  If it isn't?  In a TUI we can just ask on the console, for the GUI - we fail?
15:37:35 <simo> or you just ask questions upfront ?
15:37:54 <sgallagh> simo: Upfront was the plan
15:38:04 <sgallagh> We'll be able to get certain information ahead of time
15:38:04 <mitr> Does that mean that we need an API describing the expected settings for each role, or would it be only documented?
15:38:13 <sgallagh> like the hostname
15:38:20 <simo> I was thinking some questions can be popped back up as 'property changes' and the listener will turn them into requests to the user and feed back the property with the data
15:38:23 <simo> but sounds hackish
15:38:30 <mitr> ... That's probably strongly related to the configuration reading/writing API
15:38:56 <sgallagh> mitr: RE: expected settings. That's one of the things we need to discuss, clearly.
15:39:01 <simo> sgallagh: so I guess what we need is to provide an API that tells what data is needed ?
15:39:02 <mitr> Asking for a property is not really a property change - the question would be a property change from what to what?
15:39:34 <simo> mitr: data_missing turns from False to True :-)
15:40:07 <sgallagh> I'd rather see there be a "conversation" API, if that's going to be common.
15:40:09 <mitr> simo: I'm not 100% sure, we might only need documentation.  Do we expect a "generic role deployer" UI that would need the metadata?  OTOH having metadata would allow us to validate the deployment settings in the generic layer
15:40:45 <mitr> sgallagh: Doing conversation APIs for GUIs is hard.  PAM kind of did it but one-question-at-a-time, which is already fairly awkward.
15:40:55 <sgallagh> Please, let's not reimplement PAM
15:41:15 <simo> well
15:41:27 <simo> for freeipa we know what questions we are going to make
15:41:29 <sgallagh> The plan of record from previous meetings was that since we expect to have a relatively small number of official Roles, it's acceptable to have unique, statically-typed deployments for them
15:41:34 <mitr> I'm inclined to punt on GUI, and only allow role-specific GUIs that completely fill the deployment data; for TUI, we can have a conversation API, or just require interactive stdin/stdout and let the role do whatever it wants.
15:41:44 <simo> the problem is developing a probe that only tells back what's missing and what we discovered
15:42:02 <simo> sgallagh: I think this will require some upstream work, but shouldn't be a lot of work
15:42:15 <sgallagh> simo: What parts of "discovery" are mandatory?
15:42:31 <sgallagh> Because I'm not sure we should ever be relying on discovery in a Role deployment
15:42:35 <mitr> simo: You mean that the set of attributes that need to be supplied for the deployment varies between computers/situations?
15:42:42 <sgallagh> In that environment, we should be able to get that information ourselves
15:42:48 <simo> for the server we need to find out hostname, and then we need to give back the defaults we derive from it
15:42:58 <simo> although you could simply recalculate them as well
15:43:02 <sgallagh> simo: That doesn't have to be the same channel
15:43:07 <simo> we haven't discussed what to do for a replica
15:43:50 <simo> mitr: well if the hostname is 'foo' it is not good (not fully qualified) so you'll have to ask for stuff and change it on the machine
15:44:01 <simo> or just refuse to deploy and return an error that the hostname is no good
15:44:09 <sgallagh> simo: The latter would be my preference
15:44:37 <sgallagh> Whatever console we're using to do deployments will have to be capable of detecting and making hostname changes.
15:44:38 <mitr> Well... It Would Be Cleaner(tm) to just make it impossible to install with such a host name :)
15:44:41 <sgallagh> We can safely assume that
15:44:50 <simo> but once we have a hostname we derive a number of properties -> domain name, REALM name
15:45:01 <simo> then we need to ask for passwords for admi and DM user
15:45:12 <simo> and we need to ask whether they want to install DNS or CA
15:45:27 <simo> for DNS that means also need to install additional packages in some cases
15:45:40 <simo> I think this is probably all doable in a static interface though
15:45:48 <simo> as long as the required inputs are available
15:46:01 <sgallagh> FYI, just to bring this back up: http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/
15:46:03 <simo> the main issue being to stay in lockstep with upstream should we change something
15:46:35 <mitr> We can have optional requirements (you need to supply $foo if $bar is enabled);  that does call for a ValidateSettings method though
15:46:52 <sgallagh> simo: The CA isn't optional anymore, I thought
15:46:58 <sgallagh> Or do you mean chaining it to a higher CA?
15:47:27 <sgallagh> DNS at least I would say we shouldn't have as part of standard deployment and do that as an optional add-on after
15:48:14 <sgallagh> mitr: Yes, I think we do want a ValidateSettings method for pre-testing the responses before we actually call DeployRole
15:48:59 <simo> sgallagh: we have the option of using the IPA CA or no CA at all
15:49:09 <simo> in the second case you need to provide certs yourself
15:49:36 <simo> sgallagh: DNS as part of inistial install is actually quite critical
15:49:37 <sgallagh> simo: I'd suggest that we opt not to support that case in the Role
15:49:57 <simo> sgallagh: well we can add features later
15:50:00 <sgallagh> And always use the built-in CA with the ability to chain it to a superior CA
15:50:08 <sgallagh> (Right, I meant initially)
15:50:08 <simo> imo DNS must be a default option that you turn off if you do not want it
15:50:23 <sgallagh> simo: I can work with that
15:50:57 <simo> sgallagh: what about replicas ?
15:51:10 <adamw> so in general terms we're kinda saying a role should have only one possible deploy-time configuration?
15:51:20 <sgallagh> simo: I somewhat wonder if a replica should be treated as a separate role
15:51:36 <simo> the installation method is still a 2 step process, but if we can use ssh we can make it look like something you run only on the replica
15:51:42 <sgallagh> adamw: Yes, we've been saying that from the beginning
15:51:53 <sgallagh> With possibly optional components being available as an add-on later
15:52:13 * nirik is following along, but also dealing with email piles. ;)
15:52:47 <sgallagh> simo: Let's ask a more general question first:
15:52:59 <mitr> sgallagh: huh?  Optional components are a different configuration.  Do you mean that we would ask the user to do a two-step deployment, "deploy role" and then "add this component", or something else?
15:53:05 <sgallagh> "Do we want to address the case of replicas in F21 or just focus on the primary DC?"
15:53:31 <sgallagh> mitr: Yes, that's what I meant. A UI might hide that as an implementation detail of course.
15:53:40 <simo> sgallagh: well replicas are quite easy, if we can I would do that
15:54:04 <simo> but won't cry if we find out we have no time to get replica role management in
15:54:14 <mitr> sgallagh: In that case I'd rather have the settings with conditional/optional parts, and have the role abstract the multiple steps required away (the same way it abstracts setting up 3 daemons already)
15:54:25 <sgallagh> Well, as you noted, they require action on both the existing DC and the pending replica
15:54:40 <simo> sgallagh: the thing is, one poart of the role imo is detecting if there are conflicting servers on the network already
15:55:01 <mitr> sgallagh: Having a domain controller as a SPOF is kind of awkward, so having replica support would be desirable - but probably not blocking
15:55:06 <sgallagh> mitr: But there will be Roles where we'll want to install pieces later on. We need to address that too
15:55:08 <simo> so from there to telling a user: we found X existing, do you want to install a replica for X domain ?
15:55:16 <simo> is not a big deal
15:55:37 <mitr> sgallagh: To me that's a redeployment with changed configuration (.. .in the "DeployRole is idempotent" model)
15:55:45 <sgallagh> simo: Yes, but can we do that entirely from the new replica machine?
15:55:49 <mitr> sgallagh: I would never want to install packages without changing the "Settings"
15:55:50 <simo> sgallagh: indeed adding DNS or CAs to an existing replica is one of the cases we 'should' support
15:56:15 <simo> sgallagh: well assuming we can ssh into one of the existing servers on the network, then yes we can drive it
15:56:23 <sgallagh> simo: I'm not sure we can assume that
15:56:29 <simo> sgallagh: the main annoyance being the need to ask for 3 passwords I guess :/
15:56:40 <simo> sgallagh: cockpit needs ssh access
15:56:50 <simo> sgallagh: I thought we assume ssh is available
15:57:08 <sgallagh> hmm
15:57:14 <simo> sgallagh: well I guess cokpit could be used instead of ssh too I guss
15:57:18 <simo> *guess*
15:57:19 <mitr> ... and if cockpit needs ssh, we might make it a role requirement?  It wouldn't make me _completely_ happy security-wise because there's no practical way to constrain what ssh can do
15:57:38 <simo> mitr: cockpit can use its http port too I think
15:57:50 <nirik> ssh would be available I would think, but it might also be key only or the like, so you couldn't actually use it from another machine.
15:57:58 <simo> mitr: what ssh can do depends on what the user sshing in can do
15:58:17 <simo> nirik: true
15:58:21 <sgallagh> nirik: Well, we're presuming a FreeIPA deployment here, which by default means GSSAPI
15:58:25 <simo> nirik: but then we just fail to install
15:58:35 * nirik nods. all true.
15:58:45 <simo> sgallagh: except we need access as root for replica installation in this case and root is not kerberized
15:58:56 <sgallagh> crud
15:59:16 <sgallagh> I think in this case, we may just want to deal with it via documentation
15:59:33 <simo> well we could use admin's creds to set up sudo rules :7
15:59:33 <sgallagh> "You want to add this machine as a replica? You need to perform the following steps on an existing master first..."
15:59:38 <nirik> yeah, inter-host communication could get tricky
16:00:03 <sgallagh> simo: Why does the replica-prep need root?
16:00:11 <mitr> simo: Pie-in-the-sky:  master providing an appropriately authenticated API to add a replica?  Or is that just moving the problem to a different port?
16:00:32 <sgallagh> mitr: That's where I was going too
16:00:47 <simo> sgallagh: needs to copy certs and other secrets
16:01:21 <simo> mitr: I've been thinking of how to do that for quite a while, but it will take long to do upstream, won't be done for F21
16:01:35 <sgallagh> BTW, we're over the hour. Do we want to continue?
16:01:36 <simo> sgallagh: I think the prep thing for now is fine
16:01:58 <simo> sgallagh: only if we have things to discuss ?
16:02:05 <simo> I have another mtg in 1 hour
16:02:07 <mitr> sgallagh: I'm not sure whether it was intentional, but the invite is for 2 hours now
16:02:20 <simo> so if I can take a lunch break now I'd like it
16:02:35 <sgallagh> I did that because we've been going over for a while. I figured I'd block out the realistic time
16:03:13 <sgallagh> I think we have a lot to discuss RE: the API, but maybe we need to open an email thread first
16:03:25 <adamw> yeah, i have trouble following this kinda thing on IRC.
16:03:44 <simo> sgallagh: I think we sorted out the basic here, mail thread seem more productive now
16:03:44 <sgallagh> adamw: You're not alone :)
16:03:49 <simo> and more inclusive
16:03:59 <simo> we shouldn;t really do development in these meeting only steer it
16:04:15 <sgallagh> Ok, I'll try to summarize what was discussed here and start a discussion on the list
16:04:23 * nirik nods.
16:04:25 <simo> ack, thanks a lot
16:04:28 * simo runs
16:04:49 <sgallagh> #action sgallagh to summarize API design discussion and start discussion on the server list
16:04:59 <sgallagh> #topic Open Floor
16:05:09 <sgallagh> Anyone have other items to discuss before we adjourn?
16:08:12 <sgallagh> Ok, thanks everyone
16:08:18 <sgallagh> #endmeeting