14:06:17 <sgallagh> #startmeeting OpenLMI Public IRC Meeting (2013-11-18)
14:06:17 <zodbot> Meeting started Mon Nov 18 14:06:17 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:06:26 <sgallagh> #topic Roll Call
14:06:34 <sgallagh> .hellomynameis sgallagh
14:06:35 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:07:00 <tsmetana> .hellomynameis tsmetana
14:07:01 <zodbot> tsmetana: tsmetana 'Tomas Smetana' <tsmetana@redhat.com>
14:07:21 <sgallagh> #chair sgallagh tsmetana jsafrane
14:07:21 <zodbot> Current chairs: jsafrane sgallagh tsmetana
14:07:52 <rnovacek> .hellomynameis rnovacek
14:07:54 <zodbot> rnovacek: rnovacek 'Radek Novacek' <rnovacek@redhat.com>
14:08:05 <aledvink> .hellomynameis aledvink
14:08:07 <zodbot> aledvink: aledvink 'None' <aledvink@redhat.com>
14:09:03 <sgallagh> jsafrane: Are you around?
14:09:13 <jsafrane> sgallagh: yup
14:09:19 <sgallagh> ok
14:09:37 <sgallagh> #topic Pegasus per-user provider invocation
14:09:51 <sgallagh> jsafrane: You were telling me earlier about this? Mind repeating it for the meeting notes?
14:10:17 <jsafrane> Pegasus starts new provider for each logged-in user. One provider binary can run in parallel several times, each with different user.
14:10:28 <sgallagh> #info Pegasus starts new provider for each logged-in user. One provider binary can run in parallel several times, each with different user.
14:10:49 <sgallagh> These are separate processes, correct?
14:10:50 <jsafrane> This must be explicitly configured per-provider, we currently run everything as root (=only once)
14:10:58 <jsafrane> sgallagh: yes, separate processes
14:11:39 <sgallagh> So this is probably a little memory-heavy, but it does afford us the opportunity to use something like PolicyKit to track the audit as the user all the way through.
14:12:02 <sgallagh> The providers themselves are shared libraries that are dlopen()ed, right?
14:12:08 <jsafrane> yes
14:12:45 <jsafrane> forked from pegasus, through few exec()s to get the righ selinux context and dlopen() in the end
14:14:12 <sgallagh> Ok, so one good thing about that is that if I understand the shared library functionality of Linux correctly, there should only be one copy of that lib in memory.
14:15:07 <sgallagh> Of course, we don't really expect there to be more than one user operating on it at a time anyway
14:15:56 <tsmetana> don't we? i can imagine one user to list partitions while another one is creating a new one for example
14:16:11 <sgallagh> So, for the purposes of auditing, we probably want to go this route, since it will ensure that we know exactly what user is performing an action.
14:16:25 <aledvink> sgallagh: will there be exception to one person rule: r/o automated monitoring + r/w admin.
14:16:29 <sgallagh> tsmetana: Sorry, I should have phrased it as "in the common case, there will likely only be one user at a time"
14:16:52 <sgallagh> Or perhaps more importantly "We don't ever expect to be handling large numbers of users concurrently"
14:17:22 <tsmetana> sgallagh: yes... quite similar to the usual administration from a ssh session.
14:17:28 <sgallagh> Right
14:17:55 <sgallagh> #info OpenLMI does not expect to handle large numbers of users concurrently, but must be able to support more than one at a time.
14:18:05 <sgallagh> ^^ Satisfactory?
14:18:15 * tsmetana nods
14:19:34 <sgallagh> OK, so we should look into adjusting how we launch these providers (and authorize them with PolicyKit) in the next major development cycle of OpenLMI.
14:19:40 <sgallagh> Which is a good segue into...
14:19:53 <sgallagh> #topic Planning the next major development cycle of OpenLMI
14:20:27 <sgallagh> At this point, for a variety of reasons including business drivers, we have effectively frozen the first stable release of OpenLMI
14:21:13 <sgallagh> Collectively, I've been calling this "OpenLMI 1.0", even though the package versions of -providers, -storage, -networking, etc* have varied wildly.
14:21:45 <sgallagh> It might be prudent to formally declare a project level version to make it easier to talk about.
14:22:37 <tsmetana> let's name the -providers 0.4 and the dependant packages the OpenLMI 1.0
14:22:49 <sgallagh> Does anyone have a problem if we start talking about OpenLMI 1.0 as being "openlmi-providers 0.4.x, openlmi-storage 0.7.x, etc.)?
14:23:21 <tsmetana> i don't.
14:23:30 <aledvink> should add action to update the project page
14:23:54 <sgallagh> ok, so the one action item there would be for us to tweak the spec file for -providers so that the 'openlmi' metapackage identifies as 1.0.0
14:24:37 <sgallagh> tsmetana: Does that seem reasonable? The metapackage will then have strict Requires: identifying those versions that make it up.
14:24:38 <jsafrane> sgallagh: how often do we expect to bump the version?
14:24:56 <sgallagh> So if you have that package installed, it makes sure they all upgrade together (nothing gets ahead)
14:25:03 <sgallagh> jsafrane: Rarely, I'd say.
14:25:09 <tsmetana> sgallagh: yes. sounds good.
14:25:36 <jsafrane> I don't want to end up with OpenLMI 42.0.0 anytime soon
14:25:37 <sgallagh> jsafrane: The stable branches will be mainly bug and security fixes, not new functionality.
14:25:56 <sgallagh> jsafrane: Far from it; I'd be thinking of 1.0.1 and 1.0.2 there,
14:26:16 <tsmetana> jsafrane: the openlmi-1.0.0 metapackage would only pull the correct (bugfix) versions of the other packages (like openlmi >= 0.4.0 and <= 0.5.0)
14:26:26 <sgallagh> Maybe going to 1.1.0 if we add decide to include a few new features.
14:26:38 <jsafrane> sgallagh: so we'll keep the API compatibility principle? Use 2.0.0 only when API changes?
14:26:49 <sgallagh> tsmetana: Actually, I'd fix the versions to be ==, so we can guarantee which ones are tested together
14:27:13 <sgallagh> jsafrane: Tricky question :)
14:27:27 <tsmetana> sgallagh: hm... ok.
14:27:29 <sgallagh> I was thinking of marketing versions
14:27:48 <sgallagh> i.e. it becomes 2.0.0 when we have added something of extreme interest
14:28:12 <sgallagh> Whereas 1.1.0 is "we added a new provider and didn't change the others in an incompatible way"
14:28:20 <tsmetana> and 1.1.0 when we add something boring... and keep the api, right?
14:28:33 <tsmetana> ok.
14:28:53 <sgallagh> jsafrane: So if we ever made an incompatible change, that MUST bump the X release
14:29:09 <sgallagh> but we can choose to bump it just for our own reasons too.
14:29:14 <sgallagh> Does that seem reasonable?
14:29:59 <jsafrane> sgallagh: fine for me
14:30:03 <sgallagh> This isn't an API version number, just a label so that when we talk about OpenLMI 1.0, we know exactly which functionality was in it.
14:30:04 <tsmetana> yes
14:30:44 <sgallagh> #agreed We will declare OpenLMI 1.0.0 with the current releases of the assorted components
14:31:08 <sgallagh> #agreed Bumping the Z component will happen if we make bugfix releases of the components.
14:31:27 <sgallagh> #agreed Bumping the Y component will be for minor functionality additions with no compatibility breakage
14:31:51 <sgallagh> #agreed Bumping the X component will be for major functionality additions or any compatibility breakage.
14:32:21 <sgallagh> Ok, so with that in mind, shall we discuss plans for OpenLMI 1.1 and 2.0?
14:32:52 <sgallagh> I think if we're going to change the security/audit policy as discussed above, that's probably worthy of the 2.0 name, yes?
14:33:35 <jsafrane> sgallagh: is it that important change? imo it's just minor evolutionary change
14:34:17 <tsmetana> jsafrane: i wonder... do we plan to add some authorization/roles along with that? like using more namespaces for unprivileged users, etc.
14:34:18 <sgallagh> jsafrane: I was concerned it might be an incompatible change. If it's not, then sure
14:34:32 <sgallagh> tsmetana: I'd suggest that we probably don't want to do that in the first pass.
14:34:55 <sgallagh> And actually, we shouldn't need that if we're going the PolicyKit route, because that engine will handle the authorization for us.
14:35:04 <tsmetana> sgallagh: all right. then it's almost invisible from the (openlmi) user's perspective. in fact totally invisible if done right.
14:35:06 <sgallagh> We won't be able to *hide* functionality, but we'll be able to prevent its use
14:35:22 <sgallagh> tsmetana: Sounds great to me
14:36:09 <sgallagh> In the first pass, I suspect we'll just deliver with the standard fallback PolicyKit policy of "if you're in the %wheel group... have fun"
14:36:15 <tsmetana> sgallagh: this allows it to get introduced in some of the 1.y releases.
14:36:16 <sgallagh> And deny everyone else
14:37:42 <tsmetana> what exactly needs to be done for this feature?
14:37:46 <sgallagh> #agreed Converting to per-user provider backends will be an OpenLMI 1.1 feature
14:38:22 <sgallagh> tsmetana: In many cases, nothing. Since basically all of the D-BUS services we're talking to are already using PolicyKit authorization
14:38:31 <sgallagh> We're just going in as root, so it's auto-authorized.
14:39:12 <jsafrane> sgallagh: well, most services don't use dbus
14:39:45 <sgallagh> So for those services, we'll need to see which actions should be privileged and make sure they have a PolicyKit escalation attached.
14:40:11 <sgallagh> Where this is needed should become fairly obvious the moment we start invoking things as a user instead of as root
14:40:38 <sgallagh> Particularly if our test coverage is decent
14:41:29 <sgallagh> But it is certainly possible that I am oversimplifying the situation
14:43:05 <tsmetana> hm. we still use things like libuser, blivet, lm_sensors, hw detecting libraries (libpci, calling smartctl...), those need to be examined.
14:43:31 * sgallagh nods
14:43:44 <sgallagh> In a pinch, we can use pk_exec as well
14:44:12 <jsafrane> sgallagh: I'm pretty sure that blivet architecture doesn't support such operations
14:44:27 <jsafrane> sgallagh: it might get better with udisks
14:44:38 <sgallagh> Yeah, I know udisks *does*
14:44:59 <sgallagh> We don't necessarily have to switch everything over at once.
14:45:09 <sgallagh> We can improve things as the option becomes available
14:45:27 <sgallagh> And live with just the Pegasus and kernel audit logging for the gaps until we close them
14:46:13 <sgallagh> But like I said, if it came to it, we could always use pkexec(), which allows us to essentially wrap any other executable in a PolicyKit check
14:46:27 <sgallagh> So then we'd at least have logging at that layer
14:48:58 <sgallagh> Changing topics, besides this, what are some other high-level features we'd want to roll into 1.1?
14:49:26 <tsmetana> wsman support in the client?
14:49:28 <sgallagh> I think we may want to consider supporting a WS-MAN interface at that point
14:49:35 <sgallagh> tsmetana: You read my mind :)
14:50:12 <sgallagh> tsmetana: Support in just the client or also offering e.g. openwsman from the managed systems for other consoles to interact with?
14:50:54 <tsmetana> sgallagh: the latter should be fairly easy with the new pegasus. hopefully...
14:50:59 <tsmetana> jsafrane: right? ^^^
14:51:11 <jsafrane> sgallagh: I checked last week that it's enough to enable wsman in Pegasus and it just works
14:51:43 <sgallagh> jsafrane: I thought I remembered hearing a while back that Pegasus' WS-MAN support was experimental and flaky.
14:52:05 <tsmetana> sgallagh: i run into problems with openwsman on top of pegasus.
14:52:08 <sgallagh> How does the built-in WS-MAN support compare with openwsman?
14:52:12 <sgallagh> hmm...
14:52:55 <jsafrane> sgallagh: it's hard to compare as we don't have any application which would test it thoroughly, just few simple scripts
14:52:56 <tsmetana> sgallagh: openwsman acts more like a proxy translating the wsman requests to cim-xml
14:53:11 <tsmetana> jsafrane: true.
14:53:45 <tsmetana> the wsman feature is quite new in pegasus i think. not sure how well it was tested by the others.
14:53:50 * sgallagh wishes kkampf was around today
14:55:19 <sgallagh> #info OpenLMI 1.1 should convert any providers for which there exists PolicyKit support to using per-user provider backends.
14:55:33 <sgallagh> #info OpenLMI 1.1 should add WS-MAN support for both client and managed systems
14:55:49 <sgallagh> We can dig into the details at a later date.
14:56:31 <sgallagh> We're about at the top of the hour. Let's plan to discuss OpenLMI 1.1 more at the next meeting.
14:56:37 <tsmetana> yes. we need to do some research on the protocol itself. the shell offers some features which might be complicted to mimick with wsman.
14:56:57 <sgallagh> #action sgallagh Add OpenLMI 1.1 planning to next week's agenda
14:57:25 <sgallagh> #topic Open Floor
14:57:34 <sgallagh> Three minutes left: anything for the open floor?
14:58:54 <tsmetana> nothing from me.
14:59:08 <jsafrane> nope
14:59:58 <aledvink> sgallagh: it's quite some time since I last asked pegasus upstream on the default settings for the wsman server part in pegasus. the answer was not clearly stating that it is problematic but in the meaning it's probably that ways since nobody checked the defaults for quite some time.
15:00:57 <sgallagh> aledvink: So we may be taking a lot of support efforts upon ourselves if we enable it?
15:01:05 <tsmetana> all: thank you. i have another meeting now...
15:01:26 <sgallagh> Thank you all. We'll resume this next week.
15:01:30 <sgallagh> #endmeeting