13:04:12 <alinefm> #startmeeting
13:04:12 <kimchi-bot> Meeting started Wed Jul  9 13:04:12 2014 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:12 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:04:12 <alinefm> #meetingname scrum
13:04:12 <kimchi-bot> The meeting name has been set to 'scrum'
13:04:31 <alinefm> #info Agenda 1) Status 2) Open discussion
13:04:31 <alinefm> anything else?
13:05:47 <alinefm> so let's get started
13:05:59 <alinefm> #topic Status
13:05:59 <alinefm> #info Please provide your status using the #info command: #info <nickname> <status>
13:06:18 <alinefm> #info alinefm reviewed and commented all RFC sent to ML
13:06:44 <alinefm> #info alinefm investigated a way to implement federation and figure out openSLP is a good solution for us
13:06:55 <YuXin> <YuXin> Authorization: Assign VM to user  working
13:10:11 <wenwang> #info wenwang working authorization: remove host/template tabs for non-root users
13:11:00 <alinefm> #info alinefm is working on openSLP implementation
13:11:22 <wenwang> #info wenwang working on remove actions menu from storage/network tabs for non-rooot users/ emove [+] icon from non-root users view
13:11:37 <alinefm> #info alinefm got agreement about the authorization design - I will do some adjustments in the backend
13:12:46 <shaohef> #info shaohef is working on vm ticket.
13:14:26 <wenwang> #info wenwang working on widget that offer multiple choice works for  assigning VM to users(assisting YuXin)
13:17:18 <alinefm> anything else?
13:19:00 <alinefm> ok
13:19:04 <alinefm> let's move on
13:19:44 <alinefm> #topic Open Discussion
13:19:53 <alinefm> what do you want to discuss today?
13:20:39 <YuXin> any idea about filter users/groups?
13:22:09 <YuXin> shaohe, filter by whether the user has a home directory is reliable?
13:22:36 <alinefm> YuXin, from what I investigated yesterday we could do some filtering by the UID but it is not secure
13:22:57 <lagarcia> YuXin, you cannot filter by user with home dir cause not all user need to have a home dir.
13:23:02 <alinefm> some linux distributions do not follow the rules
13:24:09 <shaohef> alinefm: yes, qemu has no home directory
13:24:43 <YuXin> so the user without home dir should be filtered out?
13:24:59 <lagarcia> YuXin, I don't agree with this.
13:25:08 <lagarcia> YuXin, I can have a user without home dir and still log in with it.
13:25:11 <alinefm> YuXin, I don't think so
13:25:29 <lagarcia> YuXin, there is no reliable way to filter out users
13:26:08 <lagarcia> YuXin, what we can do is a smart interface that shows the most probable users at first (for instance, users with UID > 500), but has a button or an option to expand and show all system users.
13:26:09 <YuXin> ok, I will add a filter box for kimchi user to quickly get the user he want
13:26:22 <lagarcia> YuXin, that is also ok.
13:26:28 <alinefm> YuXin, that is a good feature to have
13:26:30 <shaohef> usually the we create user, and create a home dir and shell environment.
13:26:42 <lagarcia> shaohef, usually, but not *always*
13:26:53 <shaohef> lagarcia: yes.
13:27:35 <shaohef> but if the user has no shell environment, we can filter them out
13:27:40 <shaohef> IMHO
13:27:59 <shaohef> lagarcia: what about you?
13:28:44 <lagarcia> shaohef, where is the user shell enviorment stored?
13:28:53 <lagarcia> s/enviorment/environment
13:29:20 <lagarcia> shaohef, you mean the shell environment in /etc/passwd?
13:29:30 <shaohef> lagarcia: yes。
13:29:45 <lagarcia> shaohef, If this is standard among all distros, we can filter out all the users with shell environment equals to "/sbin/nologin"
13:30:03 <lagarcia> shaohef, not sure if this is standard among all distros kimchi support. we shall verify.
13:30:16 <lagarcia> shaohef, if it is common among all distros, I am OK with your proposal.
13:30:17 <shaohef> lagarcia: yes. we need to look into it.
13:30:53 <shaohef> lagarcia: OK.  I also agree. YuXin what about you?
13:30:58 <lagarcia> shaohef, I know this works on RHEL and Fedora. Not sure about SLES, OpenSuSe and Ubuntu
13:31:03 <YuXin> ok
13:31:24 <shaohef> lagarcia: let's check on SLES, OpenSuSe and Ubuntu.
13:32:12 <lagarcia> shaohef, agree
13:32:20 <shaohef> YuXin: we need some investigation.
13:32:33 <YuXin> sure
13:33:35 <YuXin> no matter whether backend can get a reliable way to make it better, I tend to add a filter box on UI
13:33:37 <alinefm> about the groups, any idea to filter?
13:33:48 <alinefm> YuXin, agree
13:33:58 <lagarcia> YuXin, agree
13:34:31 <lagarcia> alinefm, I think you can filter out groups with no user associated to them.
13:34:44 <lagarcia> alinefm, this will probably get the group list down to 5 or 6 entries.
13:35:40 <lagarcia> alinefm, however, there is one exception to this: groups with name equal to a user id doesn't need to list the user as part of the group
13:36:13 <lagarcia> alinefm, hence, I think the rule should be: merge two lists 1) groups whose name is equal to a user name listed in the users lists; and 2) groups with users associated with them.
13:36:15 <shaohef> lagarcia: yes. such as ftp groups only include ftp user.
13:36:41 <lagarcia> shaohef, yes, that's why I think we need only to list groups whose names are also in the user list (already filtered by login shell)
13:37:01 <shaohef> lagarcia: total agree.
13:39:37 <alinefm> lagarcia, a group with the same name of the user will always have this user in this group, right?
13:39:51 <lagarcia> alinefm, yes
13:40:00 <lagarcia> alinefm, that's my understanding
13:40:27 <alinefm> so check the groups has at least one user associated is enough
13:41:41 <lagarcia> alinefm, not really, cause a group that has no user associated to it can have a user associated to it (the user whose id is the same as the group name)
13:42:27 <lagarcia> alinefm, sorry, I think I  misunderstood your previous question... a group with the same name of the user will always have this user in this group, but it is not necessary to explicitly list the user in /etc/group. It is implicit
13:44:25 <lagarcia> alinefm, for instance, in my system, I have two users: laggarcia and guest. In my /etc/group, I have these entries:
13:44:37 <lagarcia> laggarcia:x:1000:laggarcia
13:45:02 <lagarcia> and this one has an explicitly association between my laggarcia user and the laggarcia group (I had typed this association by hand)
13:45:13 <lagarcia> guest:x:1001:
13:45:43 <lagarcia> but for the guest group, I don't have any user associated with it. However, as the guest user has the same id as the guest group name, it is implicit included in this group.
13:46:02 <alinefm> got it
13:46:10 <alinefm> lagarcia, could you do a test for me?
13:46:19 <lagarcia> alinefm, sure
13:47:00 <alinefm> lagarcia, http://fpaste.org/116641/40491361/
13:47:08 <alinefm> check if the "guest" group will be listed
13:47:42 <alinefm> not sure grp module works only with /etc/group or if it is smarter
13:48:06 <lagarcia> alinefm, ['bin', 'mail', 'maildrop', 'nogroup', 'video']
13:48:11 <lagarcia> no, the guest group is not listed
13:48:37 <shaohef> In [4]: [g.gr_name for g in grp.getgrall() if len(g.gr_mem) > 0]
13:48:38 <shaohef> Out[4]: ['wheel', 'shhfeng', 'kvm']
13:49:02 <alinefm> lagarcia, shaohef, thanks
13:49:44 <lagarcia> alinefm, ops, the result of my test is actually : ['wheel', 'kvm', 'laggarcia', 'desktop_admin_r', 'boinc']
13:49:46 <shaohef> in /etc/passwd
13:49:46 <shaohef> guest:x:1001:1001::/home/guest:/bin/bash
13:49:54 <lagarcia> which makes more sense... the other test I was running on a test machine with no users :)
13:50:07 <lagarcia> shaohef, yes, exactly
13:50:46 <lagarcia> ok, I think we have an agreement already
13:51:11 <alinefm> ok - so we need to investigate if /etc/passwd behaves the same way in all distros, if so use shell != /nologin to filter
13:52:01 <alinefm> and filter groups as lagarcia said: 1) groups whose name is equal to a user name listed in the users lists; and 2) groups with users associated with them.
13:52:52 <alinefm> any more topics?
13:56:38 <alinefm> ok
13:56:50 <alinefm> thanks everyone for joining
13:57:07 <alinefm> and let's be Holland today =P
13:58:28 <alinefm> #endmeeting