[01:23] Evening all [01:27] hi, sbalneav [04:30] evening all [04:30] sbalneav: just saw your mail, got to know I'm not the only one who hates AD's broken implementation of primary groups ;) [04:31] unfortunately a lot of other companies are doing the same mistake ... I saw the same kind of setup on a lot of eDirectory and even openldap setup :) [04:32] my current workaround being a script that I put in /etc/ltspfs/.../ on the application server and that fixes the permissions at mount time [04:32] (it was that or doing some hack in the C code ....) [04:33] I'll fix it in C [04:35] where "fix" means changing directory permissions to 700 I guess ? [04:35] we'll & all the perms with ( S_IRUSR | S_IWUSR | S_IXUSR ) [04:36] so things will either be forced to either drwx------ -rwx------ or -rw------- [04:36] I *hate* having to butcher perms like that [04:36] in a way it makes sense, as with fuse you simply can't enter another's users directory even if you had the unix right to do that (even root can't enter a fuse-mounted directory IIRC) [04:37] Well, you *can* if you specify -o allow_other [04:37] but a user should have his own primary group and we shouldn't have to do it ... [04:37] right [04:37] ah, right, it's just not default behaviour [04:37] but, we'll fix this and put it to bed. [04:38] Yeah, one less hack I'll be carrying around ;) (I don't think I have any customer except Revolution Linux itself where I didn't have to install that hack) [04:38] the likelyhood of ltspfs being used anywhere outside of LTSP's vanishingly small, so it's not going to hurt anything. [04:39] It'll win us some good karma, even though it grinds my gears that I have to *break* normal filesystem perm semantics to work around a MicroSoft product. [04:39] buuuuuut, whatever :) [04:39] I suppose I could add a flag to allow for default behavior. [04:40] i.e. ltspfs --dont-break-perms-on-account-of-stupid-ad [04:40] stgraber: read my libpam-sshauth page? [04:41] I've been hacking with some example code tonight. [04:41] well, I guess when we'll actually need that we'll just implement an optional configuration file on the server ;) [04:41] yeah, I read your mailing-list posts, lots of work to do there ! [04:41] yeah. [04:42] that's a two or 3 month solid bit of hacking just to get something to the point of working. [04:42] oh, btw, I have two guys implementing my NBD proxy at Revolution Linux, so we should have rock solid NBD probably by the end of the week [04:42] Realistically, I think LTSP6 will be ready for 12.04 [04:42] sounds reasonable [04:42] Ah, that'll be nice. [04:43] That sit on the client or on the server? [04:43] on the client [04:44] small? [04:44] basically, it'll be started in the initrd as the first thing at boot time, then connect to the actual nbd server and listen for connection from the kernel (so, instead of a remote nbd we actually connect on 127.0.0.1) [04:44] then it perfectly handles loss of connection and reconnection [04:44] without any I/O error [04:45] my proof of concept was 30 lines of python, now they reimplemented in C to have something that fits in the initrd and had to implement the nbd protocol completely in order to correctly handle loss of connection when getting data [04:45] but it was still only 200 lines or so today [04:46] and it depends on pretty much nothing [04:46] They got a bzr branch somewhere? [04:46] I'd love to have a look. [04:46] they have one internally I think (as backup of their laptop ;)), I'll have a look see if it's up to date or not. If it's I'll just push it some place public [04:47] on bug day we also gotta look into the awk runaway thing on ltspfs too. [04:47] Gadi found what was happening there, basically every-time a udev event happens on a block device, we source ltsp_config again [04:48] and I didn't have SERVER defined in my lts.conf, making it start to guess what my server is [04:48] triggering a lot of awk/grep/... [04:48] my idea here is to implement ltsp_config caching [04:48] so first time it'll run, it'll dump the generated environment to some file in /var, then next time, it'll simply source it instead of doing all the magic again [04:49] makes sense. [04:49] we can implement that bug day. [04:49] oh, they actually updated their branch ! let me push that somewhere [04:51] bzr get lp:~ltsp-upstream/ltsp/nbd-proxy.dev [04:57] not sure of how far they managed to go today with the implementation but at least I can start the proxy and connect to it, then mount the nbd device correctly here [04:58] They also need all the standard goodies like a configure.ac, Makefile.am, etc. [04:58] I'll get all that going for them. [04:58] I should be able to push to that, yeah? [04:59] yep [04:59] kk [05:00] I guess until there's a clear number of people wanting that a separate project, I'll just include it in ltsp-trunk as a subdirectory (similar to what we did for localapps) [05:00] it'll make it easier for distro to include as it'll just require a small packaging change and not having a whole new package to get it + depend on [05:02] ok, current code correctly handles reconnecting but doesn't work if there's data transfer at the moment where we loose the server, though I see they added a lot of debug so they're probably working on that now :) [05:02] Who's the authors? All 3 of you? [05:02] Julien Desfossez, David Goulet and I [05:03] k moving some stuff around [05:03] these two are our C/kernel coders :) [05:05] they're both starting a Master's degree in Computer Science working on the Linux Trace Toolkit (a kernel patch to trace pretty much everything that happens on your system) [05:09] Type your full name with the accent so I can cut-n-paste it into Authors :) [05:09] Stéphane [05:09] (you don't even have a US int layout ? ;)) [05:29] stgraber: update your tree [05:29] rev 4 pushed [05:30] http://bazaar.launchpad.net/~ltsp-upstream/ltsp/nbd-proxy.dev/files [05:33] ./configure && make && make install should "do the right thing" [05:33] there's even a very bad man page :) [05:33] yeah ! thanks [05:34] Do they hang around in the channel? Have 'em pop by, say hello. [05:35] they usually aren't on IRC except when they need to poke someone but I'll try to get them to connect a bit more often :) [05:36] I already managed to get mgariepy to open his xchat from time to time, I can probably get some more to connect ;) [05:37] I'll poke through the actual C code a bit tomorrow morning, see if I can help out. [05:37] But now, to bed methinks [05:37] To sleep, perchance to dream [05:37] night stgraber [05:37] if you wait 2min, you'll be able to see some of the new ajaxy ltsp-cluster ;) [05:39] https://ltsp-control01.stgraber.org/loadbalancer/overview [05:39] here you go ;) === alkisg1 is now known as alkisg [14:49] Morning all [14:50] Good Morning sbalneav. [14:51] Saw your posting [14:51] Quick answer is: "there's no quick answer" [14:51] :( [14:52] simply moving one /etc to another isn't likely to give you a satisfactory experience. [14:52] the *usual* way this is handled by professional sysadmins is: [14:53] 1) When you make a change to something in /etc, document it. I have a wiki at work for this kind of thing. [14:53] 2) When you upgrade, do a fresh install. [15:00] So, I did number 2. Does that mean fresh install of users as well or can one migrate user stuff as well: directories and password info? Any other critical stuff? [15:01] Did you keep your old /etc/passwd, /etc/shadow etc? [15:03] Actually, I'm still running the server plus I've got another server with the fresh install of Karmic. That is, I've not done anything to the current running server. [15:04] Are you using ldap or anything else for user accounts? Or simple /etc/passwd? [15:05] No LDAP. Just /etc/passwd. [15:07] If you don't find any other way, I have a python script (heh) for passwd/group/shadow/gshadow migration. You run it in the old system, export the user info in a .csv, and then you run it in the new system and import the .csv. It keeps all the info it can (passwords, expiration dates etc). [15:07] Downside: it's not internationalized yet, so greek only :( But you only need an export/import, so it shouldn't be too difficult... [15:08] dgroos: sorry got called away [15:09] 3) look at the new programs, make sure there's been no conf file changes for the ones you modifiedd [15:09] 4) If not, then you move over THOSE conf files [15:09] 5) If there have been format changes, then re-do your configs. [15:10] keeping a bzr or git archive with copies of conffiles you've touched is another handy tool. [15:12] And always, ALWAYS test [15:13] You maintain a test server that you test your upgrade process on FIRST [15:13] then once you've upgraded, you test that everything works post upgrade, with no regressions. [15:13] Legal Aid has a testing plan that we follow. [15:14] then you start work on the production servers. [15:18] I want to do something like RPC, they way iTalc does it: the teacher clicks on a button "I want to run this command on the clients", and a *listener* on the clients runs the command from inside their sessions. [15:18] So `ssh client command` won't do, as it won't be inside the user session [15:18] I'm thinking of using the python interface to inotify: [15:19] to write the command in a directory which can only be read/written by the user, e.g. ~/.myproject/commands-to-execute, [15:19] and a listener on the clients will be invoked because that file has changed, and it will parse it and execute the command [15:20] Does that sound sane? [15:20] Any better ideas? [15:20] alkisg and sbalneav--also got called away and students are coming! back later and thanks for your ideas--I'll check them out! [15:21] Well, at the risk of sounding like the thing I hate, is't DBUS BLARGHL!L!L!! supposed to handle this stuff? i.e. shouldn't some whacky message go on some bus to make some majic happen? [15:22] They are remote systems... I don't think dbus covers that case [15:22] (i.e. server/client are different PCs - not using LTSP...) [15:25] ah [15:25] yeah, we're back to the "remote dbus" problem that it's up to me to solve :) [15:26] So I guess that's a classic RPC problem, but I want to use it from batch files or from python, so I'm not looking for any difficult libraries... [15:26] alkisg: what about some kind of xmlrpc based daemon? Send it well-formed messages [15:27] python's got excellent xmlrpc libs [15:27] How would I authenticate for that? [15:27] http://docs.python.org/library/xmlrpclib.html [15:27] Not sure. [15:28] Can you see anything extremely wrong with the file system based approach? :) [15:28] How about doing something whacky and xatoms based? [15:28] Ah, xatoms... we already have a listener, right... [15:29] I'd still have to put authentication over it, but it's a thought... [15:29] !info grep hardy [15:29] grep (source: grep): GNU grep, egrep and fgrep. In component main, is required. Version 2.5.3~dfsg-3 (hardy), package size 149 kB, installed size 1144 kB [15:32] I'd like to eventually integrate the xatoms listener as a thread within ldm itself. [15:32] that'll be a ltsp6 thing [15:34] sbalneav: so ldm (the backend) would be doing some X stuff ? wasn't that something that was limited to the greeter (at the moment) ? [15:36] yeah, so far it's only the greeter that talks X. I dunno, I'm not committed to the idea, just thought it might save some moemory not having a looping shell process. [15:36] But I'm not committed to the idea. [15:38] What I was sort of hoping was by next BTS, I'd have the libpam-ssauth, libnss-sshauth, and libpam-dbusconnect components written, then we could map out all the chanes we want to do to ldm, etc, to tie it all together. [15:38] I'm in the "tossing ideas around" stage [15:41] well, RL actually received some external funding for R&D on ldm ;) [15:41] and we need to do that by May (IIRC), so we'll probably be able to improve a few things [15:42] Well, do you want to spend that money on ldm, or on getting libpam-sshauth going sooner? [15:42] (only issue at the moment is that I don't have someone to put on ldm development but that's another issue ;)) [15:42] well, unfortunately the agreement with NLNet (the organism funding the development) is on improving LDM [15:42] so we can do some work on the side but the main focus must be ldm itself [15:43] let me find the actual agreement, I don't remember how detailed it's [15:43] Well, one of the things I've wanted to do, but haven't had the time, is actually getting a proper glib main() into ldm [15:43] stgraber: could I somehow help more with iTalc? E.g. to integrade LP #367960 and put it in the edubuntu devs ppa for people to test? (/me is just trying to save stgraber some time...) [15:43] Launchpad bug 367960 in italc ""power down" request fails on 9.04; logout instead" [Medium,Incomplete] https://launchpad.net/bugs/367960 [15:43] so we can proerly do event handling, etc. [15:44] if your funding went to that, then when we get things going to move from screen-scraping to a proper pam implementation, we'll already have glib'd mainline. [15:45] sbalneav: ok, so we have: [15:45] - Improved GUI to allow for change between SSH and DIRECTX from ldm itself [15:45] - Support for other protocols (NX and RDP) [15:46] - Improved theming engine [15:46] libssh2 supports the "none" cipher [15:46] So maybe LDM_DIRECTX won't be needed anymore.. [15:46] though these are more suggestions than must-have, the actual project title is "LDM improvement" and isn't defined in much detail [15:47] Well, depends on how far you stretch it :) [15:47] Do you want to set up a conference call on it at some point? [15:48] yep, would probably be a good idea, it's actually the only part of the NLNet-funded development I haven't started yet ;) [15:48] they also fund LTSP-Cluster current development + LTSP-Cluster website (that I'd like to become LTSP's at some point) + EC2 image for NX in the cloud (already done this one) [15:48] Sure, name a time, I'll phone in. [15:49] ok, I have a meeting about it in 10 minutes with highvoltage and our CEO, things should be a bit clearer after that [15:50] highvoltage there yet? [15:50] Or still in SA [15:50] sbalneav: still in .za [15:50] I'll also try to get someone here assigned for work on LDM so whatever we decide will actually be implemented by someone (I'm doing a lot of LTSP-Cluster myself, highvoltage does LTSP and Edubuntu at the moment, so I need someone else for LDM) [15:50] sbalneav: I'll probably have my visa in around 3 weeks [15:50] heh [15:50] * stgraber loves publicly funded development ;) [15:51] cool, ping me, I'll phone in we can stratergize [15:51] I can actually speak about them on a public IRC channel :) [15:51] synergize [15:51] pie-in-the-sky-ize [15:51] oh, btw, the Edubuntu menu editor is almost done, I have mgariepy working on it at the moment and it works very well ! [15:52] the idea was to have something working by today's meeting [15:53] stgraber: will mgariepy be available for a quick update on that at the edubuntu meeting later on? [15:55] highvoltage: yep [15:55] highvoltage: I booked both of you in Zimbra for the Edubuntu meeting [15:58] indeed [15:59] oops, wrong window, but... close enough :) [15:59] highvoltage: hehe, getting mixed up between jabber and IRC :) [18:50] meeting in 10 minutes ! [18:55] meeting in 5 minutes ! [18:55] heh [18:57] highvoltage: what meeting? I don't see anything edu on the calendar today?? [18:57] HedgeMage: I think something went wrong, I added it to the goole fridge calendar but I don't see it there either :/ [18:57] HedgeMage: https://wiki.ubuntu.com/Edubuntu/Meetings/Agenda [18:59] meeting in 1 minute ! [18:59] * highvoltage teleports to #ubuntu-meeting [19:02] ping alkisg [19:02] Hey dgroos [19:02] or is it alkisg ping? [19:03] :) [19:03] highvoltage: those sorts of things should really end up on the fridge so people know about them :P [19:03] :) [19:03] sbalneav: want to join #ubuntu-meeting for edubuntu meeting? [19:04] so I'm lunching now and have a chance to read what you've written. I thought you might have a script or two hanging around :) [19:04] HedgeMage: they have been the last few weeks... except for today :/ [19:04] Can I try those 2 scripts? [19:04] (sorry) [19:04] dgroos: sure - and if you want I can help you with vnc, as the gui is in greek :) [19:05] Awesome! (you know the expression, 'it's greek to me?' :)) [19:07] highvoltage: np, it happens, I was just confused (As usual) [19:07] You know what I did with the firefox pref file you gave me is run it through a babble translator and that got me through. So, I could give that a go and as needed I'll accept your offer--'k? [19:07] Thanks! [19:07] dgroos: sudo python import-export-users.py [19:08] The first menu means "Users" [19:09] And it's menu items mean: 1) read the users from the system (done automatically), 2) import from a specific file format => you don't need that, 3) import from csv 4) export to csv 5) add the user list to the system [19:09] So you need to do: [19:09] a) on the old server, run (4), export to csv [19:09] b) on the new server, run (3), import from csv, and then (5), add those users to the system [19:10] And you're done. Always run it as root though, so that it saves the passwords etc [19:11] right--translations won't work so well in this situation... I'll give it a try with the help you gave above and let you know tomorrow how it went--might need some vnc-help--we'll see. How many different scripts do you have/use over a year's time? [19:12] I've got a large collection of them, ever growing, called "sch-scripts". I'm looking to internationalize them, but I'd like someone to proof-read my broken english... [19:14] alkisg: i can help with that if you'd like [19:14] Lns, sure, I'd like that. Because if I try to ship it with broken english, and someone corrects me afterwards, I'd have to change all of the .po files as well :) [19:15] just let me know where you need me to proofread [19:15] do you have the scripts available for d/l? [19:17] Yes they're in bazaar/launchpad/ppa etc, but I'm switching the main gui to python (from ncurses) so I'll need some weeks before I have something usuable again [19:20] what's that, glade? [19:20] I'm also changing the menus to use standard .desktop files and xdg .directory files... [19:21] Before, it was using whiptail for the ncurses dialogs, and only some of the scripts (like the import/export users) were using py/glade [19:21] Now the main gui will be using pygtk, with no glade, as it'll be mostly constructed live [19:22] cool! [19:23] It'll basically have 3 tabs: users, PCs and file system, and 4 menus: "generic actions", "actions for users", "actions for workstations" and "actions based on files" [19:23] E.g. select some files and scp them to the selected users, or select a video and broadcast it with vlc [19:27] is it ltsp specific or no? [19:29] Some of them, e.g. "remove dhcp3-server and install/configure dnsmasq" [19:30] But it targets mixed-mode labs, both ltsp/non-ltsp, so only a few of the scripts are ltsp specific [19:31] that's great though - many people will have mixed setups anyway [19:33] I want to try highvoltage's fat client script, if it works as good as ltsp does (of course with newer clients) then I might drop the mixed setups support and focus on thin/fat clients only :D [19:34] is highvoltage's fatclient script what's being included in 9.10? [19:35] No, but it's going to be in Lucid [19:36] err.that's what i meant =p [19:36] hehe [19:36] * Lns still has to count forward sometimes from 8.04 [19:36] :) [19:52] alkisg: "...correct my broken English..." Say what?! I've not seen that once here on the irc. Your English may well be better than mine. [19:53] Heh... thanks, but I'm sure that's untrue :) [19:53] Lns: yes it's in lucid [19:53] Anyway, if it something I understand I'd be happy to lend it another set of eyes. [19:53] OK, you guys convinced me, the next sch-scripts version will be internationalized :) [19:54] woohoo! more tools! =) [19:54] Well, the part I know is true is that you've not had a single spelling/gramatical error as I've noticed (and I don't go looking for them of course). [19:55] dhillon-v10: hi there [19:55] HedgeMage, edge is the latest development version of launchpad available to the beta testers :) [19:55] dhillon-v10: ahh :) [19:56] HedgeMage, hey my kernel just updated, mind if I restart and get back to you in like 5 mins. [19:57] np! [19:57] brb [19:58] yay, fitted in an hour! [19:58] just copying and pasting to send the notes to the list... [19:58] eek, there's something we missed [19:59] next meeting time :) [19:59] doodle isn't really working and it's a pain to choose every week [19:59] stgraber: will you be around in the edubuntu bug day? (for some iTalc-related stuff... :D) [19:59] shall we make it a static time again, at least for a while? [19:59] highvoltage: next week, same time ? looks like we had everyone at the meeting (at least the council) [20:00] alkisg: I should be around, I can't guarantee to spend much time on iTalc though ;) [20:00] stgraber: agreed [20:00] alkisg: I have most of your patches in my branch, waiting for the next upload though. I should probably upload that at some point. [20:00] HedgeMage, alright I am back :) [20:00] stgraber: ok, understandable, that's why I'm trying to save you time with the patches ;) [20:00] Thanks [20:01] dhillon-v10: welcome back :) [20:02] HedgeMage, so what are we going to be working on [20:04] dhillon-v10: what have you done before? anything in particular you're good at or are you happy with HedgeMage just handing you out work? :) [20:04] dhillon-v10: you can check out http://github.com/HedgeMage/edubuntuorg/issues/closed to see what I've already done. Once we have a private repo, I'll commit what I have so we can collaborate more easily. If you give me an idea of what you are interested in and what you have experience with I can help you pick out what you want to work on. [20:05] highvoltage, I guess you can check my launchpad page: https://edge.launchpad.net/~dhillon-v10 that might give you a better idea :D [20:06] HedgeMage, alright, I am good at web designing and programming, so I can pick just about anything :) [20:06] dhillon-v10: and Drupal exp? [20:07] dhillon-v10: great [20:07] HedgeMage, just started with it, learning the API [20:07] looks like the Edubuntu chapter might be slated for removal from the official ubuntu book [20:07] I am guessing the same is slated for the Kubuntu chapter as well [20:07] nixternal, hi :D [20:08] sbalneav: would you say, if they rip edubuntu from the official book, that they should in fact keep LTSP but move it over to the server book? would you agree with that? [20:08] hi dhillon-v10 [20:08] HedgeMage, I am working on a spec with the Ubuntu drupal team right now so, if you guys work with drupal it would be a good experience for me :) [20:09] nixternal, sorry I am a little late with my docs. I will *definitely* finish then by the end of this week [20:09] nixternal: That would make sense [20:09] sbalneav: OK, I kind of figured already and passed it on to the publisher [20:11] HedgeMage, are you there ? [20:12] dhillon-v10: I do Drupal for a living, that's how I ended up helping with edubuntu.org [20:12] dhillon-v10: I'm in and out randomly, I'm working and my 6yo is home on break from school [20:12] HedgeMage, awesome so you must be super good at it :) [20:13] yes, Edubuntu is getting ripped from the Official book, and the educational apps will just get a mention in the "other apps" chapter I guess [20:13] dhillon-v10: I try :) [20:13] HedgeMage, I see that some of the issues aren't really hard to deal with, just a little time and that's it [20:15] dhillon-v10: Right. The only one I definitely want to do myself is the theme -- I want to make sure it's coded cleanly for accessibility, search-engine friendliness, and ease of upgrading. I'll probably end up doing the back-end QA too, just because I look at this stuff all day every day and can probably skim through and notice problems faster/easier than most. [20:15] HedgeMage: I think we might as well make this timeslot semi-permanent, I've set it to repeat on the fridge calendare every week [20:15] highvoltage: nifty [20:15] highvoltage: are we doing these weekly or bimonthly? [20:17] HedgeMage: weekly [20:17] HedgeMage, okay :) I am not really good with art stuff anyways so I guess I can work with the site modules, what do you think [20:17] HedgeMage: it helps keep momentum doing it regularly, we've been doing it weekly again for a while now and it makes a big difference [20:19] dhillon-v10: once we get the issues copied over, assign yourself one or two and have at it :) [20:19] highvoltage: cool [20:19] HedgeMage, okay :) so should we start copying the issues [20:20] highvoltage, dhillon-v10: Do you two prefer that I set up a sandbox of the new site for us to work on and make regular commits of what we do there, or are you guys comfortable using drush to make a revision-control friendly db dump and committing yourselves? [20:21] highvoltage, dhillon-v10: if the former, I can just add the code for all the modules we'll be needing now, then we'll just have to enable as we go. [20:21] dhillon-v10: start whenever you want. I have work I need to get back to once I'm done eating lunch, so I won't be able to touch it for a few hours. [20:21] HedgeMage, I prefer a sandbox if it doesn't take too much of your time, and if it does then let's go with the second on, what about you highvoltage [20:22] dhillon-v10: I do it a lot for work, it'll just take about 10 minutes plus however long it takes for DNS to propogate. [20:22] HedgeMage: I quite like the idea of having a sandbox site [20:22] HedgeMage, okay then let's go with the second choice if that takes less time. I just got back from school so I am tired, probably going to sleep, so is it okay if I start sometime around evening [20:23] highvoltage, it seems like its going to take HedgeMage quite a bit of time so [20:23] 10 minutes isn't that much time :) [20:23] dhillon-v10: HedgeMage works quite fast, you'd be surprised! [20:23] I'll set up the sandbox [20:23] HedgeMage, okay then :) [20:24] edubuntu.frogandowl.org work for everyone ? [20:24] highvoltage, HedgeMage I am off to sleep and will talk to you guys in the evening bye and take care, thanks again for giving me a chance to help out [20:24] HedgeMage, that works :) [20:25] I can't seem to resolve that host, probably my isp having some hang-ups [20:29] highvoltage: I haven't set it up yet, I was asking if the URL was okay with you :P [20:30] highvoltage: do we have access to create a sandbox.edubuntu.org ? [20:30] HedgeMage: aah, yep [20:30] HedgeMage: it's just for us inernally so I don't care too much about the URL :) [20:31] alkisg: I guess we could set up the dns so that sandbox.edubuntu.org goes to HedgeMage's server [20:31] sounds like a plan :) [20:31] I think we used proto.edubuntu.org or something similar in the past [20:34] whatever works [20:40] let me know when it's configured, then I'll file a ticket on RT [20:48] highvoltage: it's already don, but only as of a few minutes ago, so wait for DNS to refresh [20:48] I think mine only goes every 20 minutes IIRC [20:49] ok [20:53] HedgeMage: and thanks again for all the energy you're putting in to this :) [21:00] highvoltage: np :) [21:04] !info ltsp karmic [21:04] Package ltsp does not exist in karmic [21:04] !info lsp-server karmic [21:04] Package lsp-server does not exist in karmic [21:04] !info ltsp-server karmic [21:04] ltsp-server (source: ltsp): Basic LTSP server environment. In component main, is optional. Version 5.1.90-0ubuntu3 (karmic), package size 103 kB, installed size 1204 kB [21:04] !infor ltsp-server hardy [21:05] !info ltsp-server hardy [21:06] ltsp-server (source: ltsp): Basic LTSP server environment. In component main, is optional. Version 5.0.40~bzr20080212-0ubuntu7 (hardy), package size 75 kB, installed size 808 kB [21:10] Can someone please check and see if edubuntu.frogandowl.org has propogated yet? [21:11] HedgeMage: I see it properly in Greece, and we don't have the best dns servers here :) [21:12] cool :) [21:13] * alkisg loves liquid layouts :) [21:13] * HedgeMage too [21:18] alkisg: what you see on there now is just the default Drupal theme (called "Garland"), we'll be replacing it with the custom one as soon as it's written. === moldy_ is now known as moldy [23:12] alkisg: tried the script and got halted there. Here's output: http://pastebin.ubuntu.com/352571 [23:13] Am I doing something basic, incorrectly? [23:13] dgroos: is that with plain ssh? It's a gui app... [23:14] ah duh, I better ssh first, ay? :) [23:14] So you need at least "ssh -X" [23:14] dgroos: wait [23:14] How are you connecting/logging in on the server? [23:14] E.g. does it have a monitor, and you're sitting there? Are you connecting to it remotely? [23:15] embarrassedly I say, I was just typing it on a thin client! [23:15] I'll ssh-X... [23:15] dgroos: ehm, no, it should work from a thin client [23:16] dgroos: well... if you run "sudo gedit" on that same terminal where you tried to run the program, does gedit open ? [23:16] OK, I was sitting at a thin client, opened terminal, and just typed in the sudo python command... [23:17] Strange... no it doesn't, often though I've used gedit from the terminal... [23:18] OK, there's the problem [23:18] yea... restart server? [23:18] cure-all when not sure :) [23:18] You shouldn't have to... but sure, I'm all in for the easy solutions :) [23:20] Maybe I hurt it's feelings when I had it turned off during break ;) [23:28] alas... computer don't wanna reboot. And, I need to head home. Once I get it booted, if I can't get gedit to boot any initial thoughts where I should start poking around? [23:28] None at all - if you just logon on a terminal and you're doing "sudo gedit" and it doesn't start, I don't have a clue :) [23:29] Alright :) [23:29] I'll see what happens when I get it booted. Have a good evening (12:30 your time?) [23:30] 1:30 - thanks, you too! [23:30] :) [23:32] (OK... gedit works now. I'll be giving the script a try again tomorrow. Let's give it up for restarts!)