15:02:00 <sgallagh> #startmeeting OpenLMI Bug Triage (2014-01-21)
15:02:00 <zodbot> Meeting started Tue Jan 21 15:02:00 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:10 <sgallagh> #chair sgallagh tsmetana rdoty
15:02:10 <zodbot> Current chairs: rdoty sgallagh tsmetana
15:02:18 <sgallagh> #topic Bug Triage
15:02:47 <tsmetana> the list is rather long again...
15:03:07 <sgallagh> Right, we had an excellent fresh batch come in thanks to the test day.
15:03:14 <sgallagh> Many thanks to anyone and everyone that participated.
15:03:50 <sgallagh> So we'll go through the NEEDS_TRIAGE milestone in the order they appear in https://fedorahosted.org/openlmi/report/9
15:04:38 <tsmetana> ok. #127
15:04:39 <sgallagh> Actually, to keep this meeting a sane length, perhaps we'll go through only major or higher priority tickets today.
15:04:58 * tsmetana is fine with that.
15:05:05 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/127 - [RFE] OpenLMI should configure PAM stack to avoid remote attacks
15:05:58 <sgallagh> While processing this ticket the other week, I realized that it introduces a risk of DoS against the root account.
15:06:18 <rdoty> The documentation should recommend using the pegasus user
15:06:25 <sgallagh> At present, a lot of our documentation talks about making access available to the root user, but I am thinking we should ... rdoty beat me
15:06:39 <rdoty> First time...
15:07:11 <sgallagh> Dmitri requested something more comprehensive here, but I think that may deserve a separate ticket to address.
15:07:35 <tsmetana> good. so -- we will change this to a documentation issue and target... 1.0.2?
15:07:41 <rdoty> Do we need to address this in the F21 timeframe or is F22 OK?
15:07:48 <sgallagh> tsmetana: There's still a code issue
15:07:51 <rdoty> (Documentation immediately)
15:08:03 <sgallagh> Changing the documentation doesn't address the original issue
15:08:31 <rdoty> Correct, but should be done anyway
15:08:34 <sgallagh> Specifically that we should have the default mode of operation disallow brute-force password attacks
15:08:47 <sgallagh> I have a patch attached already to address that.
15:08:49 <rdoty> Umm, considering the performance of pegasus, can someone actually use this for a DOS attack?
15:09:04 <sgallagh> rdoty: Yes.
15:09:32 <sgallagh> rdoty: If we have pam_tally2 in place, they only need to try a few times and the account gets locked for N seconds (usually five+ minutes)
15:09:45 <rdoty> OK. I would rather see the trigger point at 5 or 10; I sometimes fumble finger more than 3 times...
15:09:53 <sgallagh> So if we're allowing them to lock 'root', we can't even get in to tweak the firewall or take other actions
15:10:16 <sgallagh> rdoty: This patch gives three failures and locks for five minutes.
15:10:19 <rdoty> Is this locking system login or Pegasus?
15:10:29 <sgallagh> If you fumble that many times, you deserve the punishment ;-)
15:10:36 <rdoty> sgallagh: yes; I was recommending 5 or 10.
15:10:37 <sgallagh> rdoty: It's locking the account.
15:10:43 <sgallagh> There's no way in PAM to distinguish
15:11:23 <sgallagh> In certain circumstances (IPA), SSSD can differentiate that. But that's the exception, not the rule.
15:11:39 <rdoty> OK. Recommend setting it at 100; accidents won't lock the system and this doesn't let a brute force attack really get started.
15:11:52 <sgallagh> rdoty: Anyway, I'm okay with moving to 5 failures. I'd rather not go beyond that.
15:12:09 <rdoty> OK
15:12:10 <sgallagh> rdoty: By default, we don't ship with root enabled for remote
15:12:35 <rdoty> And if you are using the pegasus user you can't lock the system. Works for me.
15:12:40 <sgallagh> Right
15:12:45 <rdoty> Done?
15:13:02 <sgallagh> Let me summarize, so we're sure we're all in agreement
15:14:14 <sgallagh> #info Code changes to enable pam_tally2 will be made for OpenLMI 1.0.2 (actually in Pegasus package). Documentation should be updated to strongly encourage use of the 'pegasus' user rather than 'root'. Patch will be amended to allow 5 failures before locking the account.
15:14:22 <sgallagh> Sound right?
15:14:27 <tsmetana> yes
15:14:31 <sgallagh> Ok.
15:14:36 <rdoty> yes
15:15:03 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/128 - Test with IPv6
15:15:20 <sgallagh> We left this open last time. Any progress?
15:17:01 <tsmetana> sgallagh: nope. i asked rhack to run their tests with ipv6 but nothing really happened
15:17:41 <tsmetana> phatina: do you test lmishell on ipv6 sometimes?
15:18:52 * tsmetana will add a "ping?" comment into the ticket...
15:18:55 <phatina> tsmetana: not really, I tested it few times, when I was doing some fixes in pywbem (parsing IPv6 addresses), but on my local setup, no
15:19:08 <tsmetana> phatina: ok... nm.
15:19:43 <rdoty> Let's ask QE to test IPv6
15:19:58 <tsmetana> rdoty: yes. QE == rhack
15:20:05 <tsmetana> rdoty: the ticket assignee...
15:20:20 <phatina> tsmetana: do you know any plans for lmishell testing? are there any?
15:20:43 <phatina> not yet, right?
15:20:48 <tsmetana> phatina: only as a side-effect of all the other testing -- they automate the tests using the shell
15:21:26 <tsmetana> phatina: and from my experience most of the QA guys are not very familiar with the interactive interface...
15:23:19 <phatina> tsmetana: side-effect == lmishell's internals are covered, at least
15:23:44 <tsmetana> yes. but there is no effort focused on the shell testing itself
15:25:00 <tsmetana> i would skip this ticket again...
15:25:08 <sgallagh> ok, moving on
15:25:09 <tsmetana> let's put it up on some other meeting
15:25:21 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/249 - Article on OpenLMI Authentication
15:26:18 <tsmetana> "wiki edits"?
15:26:32 <sgallagh> Yes
15:26:47 <rdoty> If someone can provide the technical information or point me to it I'll be glad to write the article
15:27:38 <sgallagh> Additional comment: this actually rose out of a discussion about *authorization*, not authentication.
15:27:58 <sgallagh> Specifically that SSSD can be used to provide finer-grained authorization controls for the pegasus service
15:28:01 <rdoty> related question: can you use IPA or AD for pegasus authentication?
15:28:10 <sgallagh> As opposed to the default which is controlled by pam_access
15:28:13 <tsmetana> rdoty: through pam
15:28:19 <sgallagh> rdoty: Yes, through SSSD
15:28:31 <tsmetana> ah... sorry.
15:28:37 <rdoty> AH!
15:28:52 <sgallagh> tsmetana: Those two statements were not incompatible
15:29:00 <rdoty> sgallagh: can you draft the article? Or even write it?
15:29:04 <sgallagh> Pegasus would talk to SSSD via pam_sss
15:29:12 <sgallagh> rdoty: I'm planning to.
15:29:17 <sgallagh> tsmetana: Please reassign it to me.
15:29:25 <rdoty> Excellent!
15:29:26 <sgallagh> #agreed Move to "Wiki Edits", assign to sgallagh
15:29:29 <tsmetana> ok. milestone?
15:29:32 <tsmetana> ok
15:29:51 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/145 - [account] use static filters
15:30:49 <tsmetana> sgallagh: just spoke with tbzatek: he'll close the ticket tomorrow. we may not need any static filters in account since we don't use jobs.
15:31:15 <sgallagh> Ok, great
15:31:19 <tsmetana> sgallagh: but tbzatek_ wants to examine sw and storage providers for comparison of how things work there.
15:31:24 <sgallagh> #agreed Close as INVALID
15:31:30 <sgallagh> #undo
15:31:31 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x32129a90>
15:31:57 <sgallagh> #info tbzatek will examine sw and storage providers for comparison of how things work there. He will probably close this ticket as unnecessary
15:32:13 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/250 - openlmi-doc-class2rst can't process whole cim schema
15:32:52 <tsmetana> sgallagh: priority: minor
15:33:06 <sgallagh> Oops, I meant to skip this one
15:33:09 <sgallagh> #undo
15:33:09 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x30cf2750>
15:33:24 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/211 - lmi metacommand cannot print fancy characters with LANG=C
15:34:07 <sgallagh> I stumbled across a similar bug in another python program on Friday. Basically we must be forgetting to call str.encode() somewhere.
15:34:38 <sgallagh> Since it causes a crash in a common behavior (such as piping output), I think we need to fix this for 1.0.2
15:34:48 <tsmetana> ok
15:34:51 <rdoty> Agree
15:35:05 <sgallagh> 1.0.2/Critical?
15:35:44 <rdoty> OK
15:36:45 <sgallagh> #agreed Fix in 1.0.2 at "critical" priority.
15:37:06 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/212 - lmi --log-file does not work
15:37:40 <sgallagh> Seems like a pretty obvious missing feature.
15:37:50 <rdoty> Agree
15:37:52 <tsmetana> yes. michal is already working on that afaik.
15:38:01 <sgallagh> Two options: fix in 1.0.2 or drop the argument and re-add it in 1.1.0
15:38:28 <tsmetana> sgallagh: let's target 1.0.2 first. it may come handy when debugging things.
15:38:32 <sgallagh> Agreed
15:38:35 <rdoty> Agree
15:38:59 <sgallagh> #agreed Target 1.0.2
15:39:16 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/213 - lmi metacommand should not exit on error
15:39:42 <rdoty> This is one of my pet peeves - needs to be fixed
15:40:05 <sgallagh> Let's update the summary to read "Interactive lmi metacommand should not exit on error"
15:40:14 <tsmetana> yes. this was meant as a an usability nuisance at the test day. 1.0.2, priority "minor"
15:40:29 <rdoty> OK
15:40:52 <sgallagh> tsmetana: I agree. This should be the first to skip over if we don't get to it in time, though
15:40:55 <rdoty> I would propose priority major
15:41:21 <rdoty> This is a real nuisance when using lmi interactively
15:41:35 <rdoty> I would call this a major customer satisfaction issue
15:41:47 <rdoty> And rate it higher than, for example, the log file
15:42:06 <tsmetana> rdoty: that's why we're targeting 1.0.2.
15:42:29 <sgallagh> I should note that the 'lmi' metacommand is not part of the 1.x series as shipped in RHEL.
15:42:35 <sgallagh> It's part of the upstream-only add-ons
15:42:43 <rdoty> Yes, but priority minor and a suggestion that it can be skipped if we don't have time
15:42:58 <tsmetana> sgallagh: ah. that should go to the "scrpts" milestone then
15:43:45 <rdoty> Priority? I'm proposing major.
15:43:58 <sgallagh> Major for scripts sounds fine to me
15:44:05 <rdoty> Thank you.
15:44:14 * tsmetana capitulates
15:44:28 <sgallagh> #agreed Move to scripts milestone, set priority as major (due to high level of inconvenience)
15:45:43 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/214 - Different helps in lmi
15:47:00 <sgallagh> Looks like another 'scripts' target
15:47:02 <tsmetana> scripts again
15:47:13 <sgallagh> I call this a low-priority issue, personally.
15:47:27 <tsmetana> ok
15:47:29 <sgallagh> As long as the errors are reported, uniformity is merely nice-to-have
15:47:42 <rdoty> This is a polish and finish issue. Needs to be addressed, but not time critical.
15:47:48 <tsmetana> minor prio then
15:48:04 <rdoty> The big question is whether we are building up technical debt?
15:48:20 <rdoty> Should we fix it before we have more scripts?
15:48:20 <sgallagh> rdoty: We have plenty on this list that we *need*
15:48:37 <sgallagh> I'm going to say we make an effort to be uniform going forward and fix the stragglers later
15:48:51 <rdoty> That makes sense.
15:49:04 <tsmetana> rdoty: this is the lmi "framework" feature. we need to fix it just once no matter how many scripts we have
15:49:26 <rdoty> Ah, good. I thought it was implemented inside each script.
15:49:59 <sgallagh> @agreed Move to 'scripts' milestone, low priority.
15:50:40 <sgallagh> #agreed Move to 'scripts' milestone, low priority.
15:50:54 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/215 - lmi shows errors several times
15:51:14 <sgallagh> Same as above?
15:51:18 <sgallagh> Finishing work, but not urgent?
15:51:25 <rdoty> OK
15:51:29 <tsmetana> yes
15:51:39 <sgallagh> #agreed Move to 'scripts' milestone, low priority.
15:51:54 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/216 - lmi says it connects to https://localhost, while it uses unix socket
15:52:35 <rdoty> There are some different behaviors between local and remote, so this is worth fixing
15:52:35 <sgallagh> I vote we close this one.
15:52:48 <sgallagh> It should be addressed by the patch I sent last week
15:52:56 <tsmetana> invalid?
15:52:58 <rdoty> Ah, good.
15:53:09 <sgallagh> (Where if you pass http[s]:// it will ALWAYS actually use that interface)
15:53:12 <rdoty> How about "fixed by patch xxx"?
15:53:31 <sgallagh> You only get the UNIX socket if you specify localhost(or variants) without the scheme://
15:53:53 <rdoty> As I read it, this is reporting https when you are actually connected through the socket
15:54:03 <tsmetana> sgallagh: ok. do you have the patch review link at hand?
15:54:03 <sgallagh> rdoty: Yes and no
15:54:10 <sgallagh> It's reporting the exact URI passed to the command
15:54:24 <rdoty> Which leads to no need for lmi authentication when you are logged in as root
15:54:39 <sgallagh> The old way when we got "localhost" or any other command without a scheme: was to prepend https:// to the URI and then later check if it was actually localhost and shortcut to the socket
15:54:46 <rdoty> Resulting in different behavior between local and remote
15:54:46 <sgallagh> The new way handles that better
15:56:02 <sgallagh> FWIW, the related bug is https://fedorahosted.org/openlmi/ticket/210
15:56:43 <rdoty> OK
15:57:01 <sgallagh> Which actually shouldn't be "scripts" target, since it's lmishell
15:57:10 <sgallagh> 1.0.2?
15:57:32 <rdoty> Yes
15:57:58 <sgallagh> I need to run to another meeting. If you two can continue, feel free. I'll review it later.
15:58:16 <sgallagh> You both are #chair, so you can run the #topic, #info and #agreed commands.
15:58:24 <rdoty> I can keep going
15:58:26 <tsmetana> sgallagh: ok.
15:58:45 <tsmetana> rdoty: i have a few minutes only. so let's try a few more.
15:58:54 <rdoty> OK
15:59:16 <tsmetana> what about closing the #216 as a duplicate of #210 with a comment that the patch for #210 fixes #216?
15:59:30 <rdoty> Works for me
16:00:10 <tsmetana> #agreed Close as duplicate of #210
16:00:43 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/219
16:01:14 <rdoty> I would suggest fixing in next release of scripts. Useful information.
16:01:28 <tsmetana> scripts milestone then.
16:01:39 <tsmetana> it's "accpeted" already
16:02:39 <rdoty> Looks like the same thing for ticket 220
16:02:52 <tsmetana> #agreed scripts milestone
16:03:12 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/220 lmi partition create shows some debug output
16:03:29 <tsmetana> yes... scripts
16:03:35 <tsmetana> #agreed scripts milestone
16:04:11 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/221 Bad description of partition-list command
16:04:18 <tsmetana> same
16:04:20 <rdoty> Same thing
16:04:39 <tsmetana> #agreed scripts milestone
16:05:23 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/224 lmi help <any storage command> does not describe used units
16:05:27 <tsmetana> again
16:05:51 <rdoty> Same thing. Hmm, looking ahead, do we need to say something about how large a sector is? I'm thinking of 4K drives
16:06:16 <tsmetana> no idea. however this is a slightly different problem.
16:06:37 <rdoty> OK. Let's table that question.
16:06:51 <tsmetana> #agreed scripts milestone
16:07:37 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/226 help message should be generated also for subcommands
16:07:45 <rdoty> Yes.
16:08:08 <rdoty> At some point it would be nice to add more verbose help.
16:08:17 <rdoty> But that is a separate issue
16:08:35 <tsmetana> yes.
16:08:46 <tsmetana> so scripts milestone again.
16:09:01 <rdoty> Yes
16:09:10 <tsmetana> #agreed scripts milestone
16:09:48 <tsmetana> ok... let's do the last one. it seem that the rest would be the same anyway.
16:10:03 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/227 lmi fs list-supported should show filesystems in lower case
16:10:07 <rdoty> yes
16:10:38 <tsmetana> ok. scripts again.
16:11:03 <rdoty> Should we skip down the list? Perhaps look at 207?
16:11:20 <tsmetana> rdoty: ok
16:11:25 <tsmetana> #agreed scripts milestone
16:12:02 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/207 LMIShell RAID Create problems
16:12:42 <rdoty> Ah, I need to provide some more information. I'll do that today.
16:12:49 <tsmetana> ok.
16:13:03 <rdoty> How about 225?
16:13:21 <tsmetana> #agreed skip until there is more information
16:13:40 <tsmetana> #topic https://fedorahosted.org/openlmi/ticket/225 tab completion eats first 3 letters
16:13:52 <rdoty> This looks like a major to me
16:14:05 <tsmetana> it is. 1.0.2 then.
16:14:40 <rdoty> 198?
16:15:01 <tsmetana> #agreed move to 1.0.2
16:15:27 <tsmetana> rdoty: it's triaged already
16:15:41 <rdoty> good
16:15:50 <tsmetana> i'm sorry i need to run too.
16:16:00 <rdoty> I think we're done. Thanks!
16:16:02 <tsmetana> rdoty: thank you.
16:16:06 <tsmetana> #endmeeting