[00:30] stgraber: please try to reproduce issues with latest PA (1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu1) first [00:31] sbalneav: interesting ideas all (just read backscroll). I do think books, maps, alphabets are interesting (and also am concerned with my or other suggestions perhaps walking the line of being "Western hemisphere-centric") [13:20] Good Morning [13:21] I'm trying to run a piece of software, a beta version that is a port of a commercial product to ubuntu--still commercial I think though not sure. [13:23] This software allows you to connect an interface box with all kinds of probes eg temp, air pressure, O2 and CO2 concentration, heart rate monitor, force, acceleration, and many dozens more, to a computer. [13:24] It allows students to easily design data collection and run it. Very cool. I'd like to run it with LTSP, but get this error: [13:25] dgroos@gcos2:~$ loggerpro [13:25] main.cc main(156) : Ubuntu 9.04: 2.6.28-17-generic [13:25] Working dir /home/dgroos [13:25] Top Level Folder: '/usr/local/share/LoggerPro/' [13:25] Our runtime support folder is: /tmp/VST_Support_rLmpwh/ [13:25] terminate called after throwing an instance of 'std::logic_error' [13:25] what(): basic_string::_S_construct NULL not valid [13:25] Aborted [13:25] Is there some kernal of wisdom ;) I could pass on to the developers to make it work on thin clients? [13:26] Should I ask this at #ltsp instead? [13:33] dgroos: I guess I would run it through strace, it might give them some useful feedback [13:35] highvoltage: thanks, I'll google that and give it a try. [13:38] dgroos: you basically just install strace and type strace before the command, it will then spew lots and lots of information you could use for debugging [13:40] Cool, I'm just seeing that (your explanation was understandable as opposed to this line from the wiki: "strace -Ff -tt 2>&1 | tee strace-.log" :) [13:41] * stgraber waves [13:43] I know there's a way to get the output to print to a file and I need to do that since the output is way more than can be shown in a terminal window. How do I do this? [13:43] Good (early) morning stgraber [13:43] dgroos: some_command > some_file [13:44] thanks moldy! [13:44] np [13:47] moldy: I only get this in the file using the command you mentioned: [13:47] Working dir /home/dgroos [13:47] Top Level Folder: '/usr/local/share/LoggerPro/' [13:47] Our runtime support folder is: /tmp/VST_Support_Wyt4AP/ [13:48] dgroos: sorry, try this: some_command 2>&1 > some_file [13:49] dgroos: no, sorry. this way: some_command > some_file 2>&1 [13:49] dgroos: otherwise, you only get standard output in the file... you probably want standard error output, too [13:51] that did the trick! :) [13:52] dgroos: also see http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html for background information [14:19] morning [14:45] Morning all [14:46] morning [14:46] morning mhall119|work, sbalneav [14:48] Morning mhall119|work, sbalneav, highvoltage :) [14:50] morning alkisg [16:12] alkisg: yo [16:12] Hi LaserJock :) [16:12] one sec, brb [16:15] alkisg: put on your users-admin thinking cap [16:15] Wow [16:15] * alkisg puts a donkey hat whatsyamacallit [16:15] omg, it's LaserJock! [16:15] the Dr. is in [16:16] alkisg: have you looked at the new users-admin tool in Lucid yet? [16:16] sbalneav: yes, it looks like someone put some work on it [16:16] right. [16:17] In your professional opinion as an educator, is it useful? [16:17] And, what do we want to do about bulk import? [16:17] sbalneav: does it have bulk import? [16:17] No [16:17] Well, for a school, where one wants to manage a lot of students, the previous list-type-interface was much better [16:18] (it couldn't even sort by columns, but you know, the idea) [16:18] alkisg: laserjock came up with a patch for the sorting [16:18] then discovered the tool changed completely [16:18] I think the current users-admin is oriented towards desktop systems, with only a handful of users [16:18] right. [16:19] So, we have a few choices. [16:19] it would be nice if you could list by group [16:19] or in a school environment, by classroom or grade [16:19] Right. kuser does a lot of those things [16:20] I just looked at the new users-admin and it seems to have the same old problems in terms of usability [16:20] highvoltage: How do you store classroom/grade info? In the gecos field? [16:20] Or even fedora's users management GUI (but that's also to be abandoned) [16:21] So, here's the question. Do we: [16:22] 1) try to add functionality to users-admin? (probably hard) [16:22] 2) ship something that's closer (kusers) [16:22] 3) Write our own tool that's uniquely designed for managing classrooms? [16:23] 1 => yeah, and a python-based tool would also be more maintainable [16:23] 2 => well we could use that for Lucid, as I don't think we'll have time for (3), [16:24] 3 => you're de man! [16:24] We could distribute 3 via the edubuntu-ppa's after release. [16:24] If (3) also allowed plugins (=actions) for the selected users, it would be much more helpfull for classrooms [16:25] alkisg: ok, you're the sole educator among us. [16:25] Could I ask you to create a wiki page with all the design features you'd like to see for a user management tool? [16:26] I'd be willing to take this on, and solve it for us once and for all. [16:26] sbalneav: sure, but the plugins I'll mention there will only scratch the surface. If you did the plugin system, then the teachers themselves would come up with the needed plugins. [16:27] alkisg: sure, but I need to know what kind of things you want the plugin system to accomplish [16:27] scratch that [16:27] Sure [16:27] interface of the plugin system [16:27] sbalneav: do we want this to be LTSP oriented? [16:27] i.e. what do you want passed to the plugin? I.e. userid, home dir. etc. [16:28] alkisg: well, for now, lets just assume it's a general user admin tool. [16:28] I mean, suppose a teacher has 12 standalone workstations with students on them. What does users admin do for him? [16:28] if there's ltsp specific things, maybe we handle those with plugins. [16:28] alkisg: handle ldap maybe [16:28] or pam-sshauth [16:28] Right, or pamssh... that [16:29] Could the plugin show him who's logged on? [16:29] * LaserJock is back [16:29] Eeeerr... the tool [16:29] Because different actions are needed if the users are logged on, and different if they aren't [16:29] well, I'd say "no" since now you're making it a monitoring tool as well. [16:29] No, the actions are no different. [16:29] Or maybe we could leave that for italc or a similar tool :) [16:29] I think it might be wise to separate the idea of managing the system's user information (name, password, etc.) from performing actions on the user [16:30] I'd say so yes. [16:30] LaserJock++ [16:30] right, lets solve a smaller problem. [16:30] managing the user database [16:30] LaserJock: if you already have the users there, why not allow the sysadmin to execute some actions upon them? [16:31] because it may well prevent us from having the tool in the first place [16:31] alkisg: that would be your plugin thing [16:31] right click on the user drops down list of plugins [16:31] what I think would be a good target would be to get something in upstream GNOME [16:31] click on plugin, plugin gets called for that users [16:31] in the Admin section [16:31] Yes, if the tool was designed with plugins in mind... [16:32] Gee, if only there were a gnome developer amongst us who has git.gnome.org access.... [16:32] heh :D [16:32] LaserJock: so... take kuser for example. Would you need anything more, for the admin section? [16:32] I don't know [16:33] what I'd like to see is educators/enterprise users get together and list what is needed [16:33] but not too pie in the sky [16:33] It has ldap management, import/export from .csv etc [16:33] LaserJock: I asked alkisg to create a wiki page with requirements [16:33] It's fine for enterprise usage [16:34] I wouldn't need anything else for account management. [16:34] But for *user* management, I'd need more [16:34] you and your endless requirements, tsk [16:34] ok, but we need account management first :-) [16:34] one user per PC is enough ! [16:34] :) [16:34] ogra: well, give us a good offer for arm netbooks :) We're waiting! [16:34] hey LaserJock [16:35] ogra: hi! [16:35] yeah, and they sit on the console. [16:35] So, if we want an account management tool, I'd say kuser is fine. Not gnome, but in edubuntu, we don't care much as we already have all the KDE stuff. [16:35] right, I'm concerned about GNOME though [16:35] For a user management tool, a plugin approach would be needed. [16:36] LaserJock: I don't think edubuntu should be concerned about account management. It's more of an enterprise concern, let them do it, they have more resources :D [16:36] ok, but account management is sort of a prerequisite to a lot of other things [16:37] i.e. sabayon, etc. [16:37] effective use of account management could be a very useful thing [16:37] I think it could be a paradigm changer [16:38] how we think of users affects a whole lot of other decisions [16:38] including things like user managment [16:39] if it was trivial to import/export users, change groups on the fly, etc. do you think it would change how educators do user management? [16:40] I've given this a lot of thought. I know exactly what I was as a computer teacher (=also sysadmin): an all-in-one tool. To be able to send 10 files to class A or put a firefox bookmark in class B from the same UI. [16:40] It's not something enterprise admins would like, though :) [16:41] maybe, maybe not [16:41] In other words: the user management tools in windows are sophisticated [16:41] They allow for group changes, policy changes etc [16:41] but the foundation of either is account management I'd think [16:41] They 're NOT suitable for educators [16:41] why not? [16:42] sbalneav: well. even if you could put them in a unix group [16:42] Because they're enterprise oriented [16:42] sbalneav: well. even if you could put them in a unix group 'grade7' and display by that it would help, but gecos could be useful as well for more taggy things [16:42] how so? [16:42] You cannot expect a teacher to understand about "resultand set of policies"... :) [16:42] that why we make the tool!!! [16:43] the idea is to abstract the nuts and bolts to something that teachers find useful [16:43] That's why I'm saying that I don't really care about an account management tool [16:44] I'd like a users management tool. In all the existing tools, windows, kde, fedora's etc, I don't see any actions to do on users [16:44] ok, but it sounds to me like you're saying that you don't want an account management tool because account management tools suck [16:44] No, they're doing their job fine [16:44] You guys are making this over complicated. With your plugin idea, we don't have to worry about that right off the bat. [16:44] All you need to do is: [16:45] 1) create an account management tool that handles account management fine. [16:45] 2) have 2 sets of plugin dirs: one for user actions, one for group actions. [16:45] you alow multi-select on the user and group lists [16:46] when you right-click on a selected set of users, then you get a dropdown menu with the available plugins (i.e. list of files in /usr/share/foo-manager/user-plugins [16:46] you select the plugin [16:46] plugin is passed a list of user or group id's that have been selected. [16:47] so if you want a plugin that copies bookmarks, or whatever, you just write one. [16:47] Right. Perfect. [16:47] that won't be OUR problem to solve [16:47] The teachers themselves can solve this, if the mechanism is there. [16:47] then as people write plugins, we can either: [16:48] 1) package these up as either individual or groups of plugins [16:48] or [16:48] 2) simply provide a place where people can advertise plugins they've written (wiki, or what have you) [16:49] so the question is, can this be done in users-admin, and if not how can we get it upstream? [16:49] sbalneav, but but ... then we wouldnt have the fun to explain garymc the .desktop file copying every month in #ltsp ... that would automate everything [16:50] Hehehehe [16:50] sbalneav, that makes us jobless !!!! [16:50] Don't worry, we'll hire you as a plugin writer :) [16:50] pffft :) [16:50] I don't think users-admin is suitable for plugins [16:50] So, really, what we need is: [16:51] Python is better for that instead of C [16:51] 1) something like the old users-admin in terms of interface [16:51] 2) written in python [16:51] 3) need a plugin architecture for "user supplied plugins" [16:51] that's not that hard. [16:51] well [16:51] hey guys [16:51] technically *no* [16:51] I'm users-admin's maintainer [16:51] but socially? [16:52] milanbv!!! [16:52] milanbv: awesome to see you [16:52] Hello milanbv [16:52] hi! :-) [16:52] milanbv: I've been talking to Edubuntu folks in order to know how to respond to your email [16:52] it's arer to see so much enthusiasm for the gnome-system-tools [16:53] s/arer/rare/ [16:53] if you're going to write a new app, I'd suggest you to base on the new work by mclasen rather than on the system tools backends [16:53] Hi!!! [16:54] milanbv: is that from Red Hat? [16:54] yeah [16:54] http://cgit.freedesktop.org/accountsservice/tree/ [16:54] http://blogs.fedoraproject.org/wp/mclasen/2010/01/15/old-promises/ [16:54] thanks [16:55] the thing that concerns me is if it would be hard to get another tool into GNOME [16:55] I can see where the new users-admin is a nicer UI for the "typical" users [16:55] n, it's already in: http://git.gnome.org/browse/accounts-dialog/ [16:55] but is there enough of a distinction between home users and educational/enterprise users that a separate project is worth while? [16:56] what separate project? yours? [16:56] good grief [16:56] everybody needs to get together and come up with a single set of tools [16:56] :-) [16:56] (that was a real question :-p ) [16:57] About the UI, I think kuser has a lot of good ideas. The dbus backend also sounds sexy... [16:57] milanbv, all existing tools are lacking multi user management [16:57] ogra: kuser supports multi user management (I think) [16:57] what do you mean by that? [16:57] milanbv, and the UI simplification going on, while its beautiful doesnt make it easier [16:57] milanbv, imagine you manage 500 users on one server [16:57] you want to be able to group and sort in the UI [16:57] OK, multi = many [16:58] yes, that's why I was wondering [16:58] or to apply the same set of changes to a certain set etc [16:58] sorting is rather trivial [16:58] milanbv: not only that. Suppose you want to change the groups on 100 users simultaneously [16:58] I.e. remove them from "audio" and put them on "sambashare" [16:58] or you want to just throw a .csv at the tool and have everything synced [16:59] hmm, that's not on our scope, sadly [16:59] right [16:59] that would need a separate tool [16:59] kuser supports that [16:59] all existing user management apps lack such features and the focus of future improvements seems to always be on single desktop systems with in max 10 users or so [16:59] milanbv: so do you think there would be support within GNOME for such a tool? [16:59] I'm not sure [16:59] (/me talking about gnome desktops here) [16:59] the question is not really whether it would enter GNOME [16:59] you need somebody to work on it [17:00] well [17:00] I'm willing to put my code time to something like that [17:00] little as it is [17:00] that may not be too hard, yes [17:00] but I don't want to work on something that has no chance of getting upstream [17:00] do you really need it to go upstream? why? [17:01] because I want GNOME to work for educators [17:01] that could stay a separate tool shipped with distributions like Edubuntu [17:01] it's part of my secret plot to make GNOME rule the world, one school at a time .... mwhuahahahahahahaaha [17:02] ok, so maybe not ;-) [17:02] but I have issues with tools that just stay within a single distro [17:02] I think it should be more broadly useful [17:02] agreedù [17:03] but the first step is to make it work ;-) [17:03] sure [17:03] milanbv: are there thoughts to make the dbus-based backend a "global" solution? I.e. thoughts for it to manage LDAP users? Or to be used by other DEs as well? [17:03] and you could get it into something like fifth toe ... [17:03] the fatal flaw in my world domination plans, drat [17:03] doesnt need to be 100% upstream that way, but would be available through upstream [17:03] alkisg: the system tools backends are not really maintained actually [17:04] I was the only person working on it [17:04] milanbv: I mean the new one, that uses dbus [17:04] http://cgit.freedesktop.org/accountsservice/tree/ [17:04] and now mclasen seems to want to create a better D-Bus service [17:04] that one would support LDAP [17:04] so yes :-) [17:04] that's the plan, but it's only starting [17:04] So maybe we could use it as a backend too, and only design a suitable front end [17:05] sure, avoiding duplication is always good [17:05] Maybe it's worth waiting then, and not start the project now. [17:05] you should discuss with him what you need [17:05] basic support is here ATM [17:05] ++ [17:05] http://cgit.freedesktop.org/accountsservice/tree/data/org.freedesktop.Accounts.xml [17:05] communication helps sometimes :) [17:05] http://cgit.freedesktop.org/accountsservice/tree/data/org.freedesktop.Accounts.User.xml [17:06] what do you need actually? [17:08] Personally, I'd like something like kuser (https://help.ubuntu.com/5.10/kubuntu/images/C/kubuntu-kuser.png) with multiple select / edit and with a plugins architecture [17:09] So that I could select 10 users and put them in group A or invoke the plugin "set a firefox bookmark" on them. [17:09] but that's the GUI's job [17:09] Yes [17:09] I meant: what do you need from the backend? [17:09] Oh [17:09] The information on the .xml seems enough, but is it going to be stable? [17:10] no [17:10] :-) [17:10] That's why I said maybe we should wait :) [17:10] but I'm not sure that's a great problem [17:11] the hard work will be the interface parts [17:11] you could also start with the system tools backends, and switch when it's ready [17:11] if the backend is abstracted enough, that won't be hard [17:12] Well if we're going to do our own user "abstraction" then we won't mind the backend changing, but if we're going to use the same structures as the backend, we'll need a lot of changes in the code for e.g. s-t-b => new stuff migration [17:12] for you, the base structure is only following /etc/passwd an /etc/group [17:12] so those fields are not going to change much [17:12] (if at all) [17:13] I'm not sure that's the case [17:13] E.g. consolekit has info on who's logged on. That may be useful for some plugins [17:13] Or, the "Desktop" / "Επιφάνεια εργασίας" xdg dirs could also be useful [17:14] hmm, that's another issues [17:14] who's logged in is not a problem, even the GUI can do that [17:15] liboobs is doing it for users-admin, it's not in the system tools backends [17:15] So if we're going to "pass" users around to plugins, we'll need those as fields of the objects/structures... [17:15] are there other "special" settings other than XDG that you may need? [17:16] At some point "special" settings it the responsibility of the plugin (e.g. where's the firefox dir?) [17:16] that would be more complex [17:16] plugins on the backend side would really make it harder [17:17] you'd need another system [17:17] I agree, those should be frontend-plugins [17:17] Sorry, was afk for a bit, workping [17:17] * sbalneav reads scrollback [17:18] but on the frontend side, you wouldn't be able to install files into Firefox's dir [17:19] maybe you should combine two backends: the user management one, and another custom one, allowing to install some files and things like that [17:22] * alkisg doesn't know how PolicyKit works behind the scenes, so has now clue on how to design that [17:23] s/now/no [17:23] not very hard [17:23] the backend runs as root, and asks PolicyKit when a frontend wants to do something [17:23] it's either yes or no, PK takes care of authentication [17:24] I'm having to learn pk for sabayon, so I might end up knowing something more about it soon than I know now. [17:24] Which is nothing [17:27] Well the plugins would contain arbitrary commands. So I guess the backend should be able to take the scripts as a parameter, and execute them... Will need extra checks for security :) [17:27] for that, simply use gksu from the frontend, then [17:28] E.g. "put a firefox bookmark for the selected users" [17:29] The frontend shows a dialog, gets the bookmark, notifies the backend to run "addbookmark $selected_users" [17:30] so use libgksu to run the plugin from the frontend [17:30] The backend should then invoke that (python?) plugin, pass it the selected users info, and let it add the bookmark... [17:30] you don't need PolicyKit to run arbitrary commands [17:30] that's cheating :-) [17:30] So for each action a gksu dialog would be displayed? Wouldn't that be annoying? [17:31] no idea [17:31] Or should the whole frontend run with gksu? [17:31] no [17:31] never run GUI as root [17:31] well, that might be something to consider further down the road [17:31] there's another [17:32] otion [17:32] perhaps to start with you just want to limit what scripts can do [17:32] and not let them be arbitrary [17:32] you could install plugins in a dir where your custom backends knows about them [17:32] * alkisg looks at /usr/share/applications/sabayon.desktop... "gksu sabayon" :P :D [17:32] and then use a generic command that runs the plugin with some arguments [17:33] for example, you could send to the backend "run firefox_bookmark (["user1", "user2"], "bookmark file")" [17:34] and the PolicyKit action would either be "run any plugin", or "run firefox bookmark plugin" [17:34] That's what I meant above with "notifies the backend to run "addbookmark $selected_users""... [17:35] The plugins would be python modules or something like that, in standard dirs [17:35] And the whole users objects would need to be passed, not just the user names... [17:35] yeah [17:36] you'd need to restrict scripts that you run to a special folder where the plugins are installed [17:36] and you would define a user struct that you would pass to the plugins, of which they would do what they want [17:36] but this has to be independent from the general user management backend [17:37] so you need to choose your struct anyway [17:38] gtg [17:38] milanbv: so... if we did a tool like kuser (multiple selection/editing etc), which depended on the new dbus backend for user management, [17:38] and also a plugin mechanism (frontend/backend), [17:38] could the tool (without the plugins) be integrated to gnome? [17:38] (or with the plugins...) Or should it remain an edu* project? [17:39] hey, I'm not the GNOME release team :-) [17:39] you could ask on #release-team [17:39] they will give you an insight [17:39] anyway I'm going [17:39] :) thanks a lot man [17:39] Bye.. [17:40] if you want to grab me, I'm on #ubuntu-desktop, or on #gst (on irc.gimp.net) [17:40] and file reports in Launchpad if some minor bugs could help you [17:40] Thanks! [17:43] * sbalneav has been in and out of the office on work matters [17:43] so what was the end result? Are we adding things to the new users admin? [17:47] sbalneav: well YOU SHOULD BE HERE to ask that :D [17:48] well [17:48] I think he said "hmm, that's not on our scope, sadly" about multiple selection etc [17:48] Yeah, well, I have this thing called a JOB which allows me to do all this other stuff, and they kinda needed me :) [17:48] it seemed fairly clear to me that users-admin is not where mass-user is going [17:48] So, a separate project. [17:49] We could use their backend, though [17:49] but, maybe we can use their PK backends [17:49] I asked rick spencer (Desktop Team manager) about the Red Hat tool and if Ubuntu had any plans [17:49] right [17:49] he basically said they didn't but they'd likely just use whatever was the GNOME default tool [17:52] so .... [17:54] So, we'll use their pk backend for adding the users and getting auth [17:54] have a more "large # of users" frontend [17:54] and a plugin system. [17:55] It'll be an Edubuntu sponsored project, and be something unique that we add to the process. [17:55] Unfortunately, Ahmuk-jr's not here to see it :) [17:58] A good user manager is a much needed tool. But I don't think it's my first priority at this point. E.g. I think fat clients are a lot more important... [17:58] Maybe we could propose kuser for some time, and see how that goes? [17:59] I don't know why, but I have the feeling that for the next LTS some new tools or backends will be there. [17:59] alkisg: Sure, I wasn't even going think about looking at this until after we got close to lucid release. [18:00] * alkisg also started his phd and is already behind schedule, so after lucid is released will devote most time in it [18:00] I've got enough on my plate ATM. But post lucid, it could be a "killer feature" for edubuntu, and we could still give it to lucidusers via the edubuntu-ppa's === stgraber_ is now known as stgraber [19:04] So over my lunchtime walk, I solved the most important problem with this user manager we're talking about. [19:04] The name. [19:04] See'um [19:04] Simple, Elegant, Extensible User Manager [19:04] Now that I've solved the hard part, the rest should be easy ;) [19:06] Heh... I'll do the icon [19:06] Now with the most 2 difficult parts done, we just need a humble programmer to do the monkey typing thing [19:07] Like I say, I'll take that one on. Post lucid. [19:08] * alkisg will help, do most of the plugins [19:10] I'll start a wiki page tonight, point you at it in the morning. [19:12] What I mapped out in my mind over lunch is that we do *very little* natively in the gui. Very simple: add, delete, modify users & groups [19:12] most functionality will come from plugins. [19:12] I'll put my thoughts in order tonight, get 'em on a wiki page. [19:15]