Main page
[00:27] F-GT (~phantom@ppp121-44-206-152.lns20.syd7.internode.on.net) left irc: Ping timeout: 246 seconds
[00:38] vagrantc (~vagrant@c-76-27-239-73.hsd1.or.comcast.net) left irc: Quit: leaving
[00:43] F-GT (~phantom@ppp121-44-66-25.lns20.syd6.internode.on.net) joined #ltsp.
[01:19] Lns (~Lns@pdpc/supporter/professional/lns) left irc: Ping timeout: 240 seconds
[01:31] jaime_david (~jd@223.Red-88-2-124.staticIP.rima-tde.net) joined #ltsp.
[01:32] [jaime_david] Hi I'm using K12Linux, can i ltsp-build-client --arch ppc from a x64 server?
[01:33] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[01:33] [jaime_david] Hi
[01:34] [jaime_david] I'm using K12Linux, can i ltsp-build-client --arch ppc from a x64 server?
[01:40] jaime_david (jd@223.Red-88-2-124.staticIP.rima-tde.net) left #ltsp ("Saliendo").
[02:02] Selveste1 (~Selveste1@88.83.86.20.static.dong.customer.smilecontent.dk) joined #ltsp.
[02:30] alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
[03:24] highvoltage (~highvolta@ubuntu/member/highvoltage) joined #ltsp.
[04:02] hersonls (~hersonls@187.40.58.231) joined #ltsp.
[04:04] artista_frustrad (~artista_f@201-15-206-240.ctame704.dsl.brasiltelecom.net.br) left irc: Ping timeout: 265 seconds
[04:16] artista_frustrad (~artista_f@201-15-206-240.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[04:28] artista_frustrad (~artista_f@201-15-206-240.ctame704.dsl.brasiltelecom.net.br) left irc: Ping timeout: 276 seconds
[04:40] artista_frustrad (~artista_f@201-24-239-233.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[04:48] artista_frustrad (~artista_f@201-24-239-233.ctame704.dsl.brasiltelecom.net.br) left irc: Ping timeout: 246 seconds
[04:50] pmatulis (~peter@mail.papamike.ca) joined #ltsp.
[05:02] artista_frustrad (~artista_f@201-24-239-233.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[05:11] ogra (~ogra@ubuntu/member/ogra) left irc: Read error: Connection reset by peer
[05:11] _UsUrPeR_ (~jsass@fw.acurrus.com) joined #ltsp.
[05:12] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[05:12] jammcq (~jam@c-76-112-250-102.hsd1.mi.comcast.net) left irc: Quit: leaving
[05:15] artista_frustrad (~artista_f@201-24-239-233.ctame704.dsl.brasiltelecom.net.br) left irc: Ping timeout: 268 seconds
[05:28] artista_frustrad (~artista_f@201-24-239-233.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[05:28] scottmaccal (~scottmacc@sentry.jayschools.org) joined #ltsp.
[05:29] astigmata (~astigmata@i01m-62-35-17-156.d4.club-internet.fr) joined #ltsp.
[05:29] [astigmata] hi all
[05:30] [astigmata] I m connected with ltsp atm
[05:30] [astigmata] but my problem, I can't see or mount local harddisk
[05:30] [astigmata] is possible to auto-mount HDD with ltsp ?
[05:52] hersonls (~hersonls@187.40.58.231) left irc: Remote host closed the connection
[05:53] hersonls (~hersonls@187.40.58.231) joined #ltsp.
[06:01] rjune (~rjune@oh-67-76-200-198.sta.embarqhsd.net) left irc: Remote host closed the connection
[06:01] try2free (~send2us@125.160.154.141) joined #ltsp.
[06:08] ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp.
[06:08] ogra (~ogra@ubuntu/member/ogra) left irc: Ping timeout: 265 seconds
[06:09] Nick change: ogra_ -> ogra
[06:09] ogra (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Changing host
[06:09] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[06:16] try2free (send2us@125.160.154.141) left #ltsp.
[06:16] epaphus (~epaphus@190.10.68.228) joined #ltsp.
[06:23] astigmata (~astigmata@i01m-62-35-17-156.d4.club-internet.fr) left irc: Remote host closed the connection
[06:47] jammcq (~jam@70-91-230-209-BusName-Michigan.hfc.comcastbusiness.net) joined #ltsp.
[07:04] epaphus (~epaphus@190.10.68.228) left irc: Ping timeout: 246 seconds
[07:07] Faithful (~Faithful@202.6.145.116) left irc: Ping timeout: 258 seconds
[07:24] CAN-o-SPAM (~chatzilla@fw.acurrus.com) joined #ltsp.
[07:45] dark4og (~chatzilla@208-189-52-61.twu514.org) joined #ltsp.
[07:49] [dark4og] We have been using Ubuntu LTSP for that past year, We are now in need of desktop scanners at all of our thin clients. Sane will not recognize the attached. thin client USB Scanner. I can get it to scan if I drop to a root on the thin client, (ctl-alt-f1) yet not available on the to any useres.. Any help would be GREAT!
[07:51] [dark4og] I have set the thin client to a static IP and am running localapps, of firefox and flash
[07:52] [dark4og] This is on a "Disklessworkstation" and PXE boot. LTSP5, Ubuntu 9.10.
[07:56] [jammcq] dark4og: so the scanner works with SANE, but just not on the thin client?
[07:58] [jammcq] dark4og: you'll need saned running on the thin client. that should make the scanner available via the network. Then, you need to set some environment variables on the server so that your scanner-aware apps can see it
[08:02] romel (~romel@unaffiliated/romel) joined #ltsp.
[08:09] staffencasa (~staffenca@128-193-154-144.oregonstate.edu) joined #ltsp.
[08:39] runout (runout@81-223-23-159.goesting.xdsl-line.inode.at) left #ltsp.
[08:46] loomis53 (~loomis53@precisionresearchinc.com) left irc:
[08:49] Faithful (~Faithful@119.12.226.159) joined #ltsp.
[08:51] [moldy] dark4og: you could run the applications that need to access the scanner as local apps
[08:54] Faithful (~Faithful@119.12.226.159) left irc: Ping timeout: 248 seconds
[09:01] Lns (~Lns@pdpc/supporter/professional/lns) joined #ltsp.
[09:27] nubae (~quassel@87.223.151.121) joined #ltsp.
[09:31] nubae (~quassel@87.223.151.121) left irc: Read error: No route to host
[09:31] nubae (~quassel@87.223.151.121) joined #ltsp.
[09:31] epaphus (~epaphus@190.10.68.230) joined #ltsp.
[09:32] nubae_ (~quassel@87.223.151.121) left irc: Read error: No route to host
[09:32] [epaphus] Hello, whats a good way to see if a particular video chipset is supported in LTSP ??
[09:33] [johnny] if it's supported by linux
[09:33] [johnny] it's supported by ltsp
[09:33] [johnny] so that's not a useful question
[09:34] [johnny] the same could be said of most hardware
[09:34] [johnny] except local cd/dvd burners and scanners
[09:35] [johnny] hopefully the need for saned will die ..
[09:35] [epaphus] hmm..
[09:35] [johnny] and that won't be a problem anymore
[09:35] [johnny] for scanners
[09:35] [epaphus] understood
[09:35] [johnny] the cd/dvd burner stuff is alot more difficult tho :(
[09:36] alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
[09:37] [epaphus] thanks johnny
[09:43] [dark4og] jammcq: Yes the scanner works on the thin client if i log in as root, through (ctrl-alt-f1) then run scanimage.
[09:45] [dark4og] moldy: When I run it as a localapps, i get nothing. nada... I added the sane to the image, and rebuilt the img files. still nothing.
[09:48] Lns (~Lns@pdpc/supporter/professional/lns) left irc: Ping timeout: 276 seconds
[09:51] [moldy] dark4og: hm, that's weird
[09:54] [alkisg] Maybe the user needs to be in some special group, like, I don't know, plugdev?
[09:54] john (~john@216-102-74-141.scoe.org) joined #ltsp.
[09:55] [alkisg] crw-rw---- 1 root disk 21, 1 2010-04-05 19:35 /dev/sg1
[09:55] [john] I'm having a login problem on a brand new install with Ubuntu 9.10, basically the LDM screen acts like it's going to login, then the session is closed. /var/log/auth.log offers no explanation
[09:56] [john] where else can I look to troubleshoot this issue?
[09:56] [alkisg] john: do you see a successful authentication in the server auth.log?
[09:59] [john] http://pastebin.com/Kcx71Gj5 will show the log
[09:59] [john] Looks like it authenticates just fine, but then during the login the session is closed
[10:00] [alkisg] john: I've seen those symptoms with compiz problems. Can you try disabling compiz?
[10:00] [alkisg] !compiz
[10:00] [ltspbot`] alkisg: "compiz" :: if compiz is giving you problems, one way to disable it for all users is: sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity
[10:01] [john] that worked!
[10:01] [alkisg] Wow, fast testing :)
[10:05] vagrantc (~vagrant@c-76-27-239-73.hsd1.or.comcast.net) joined #ltsp.
[10:06] [john] I had two servers, both with the same problem. Now they are fixed, thanks!
[10:07] *** alkisg thinks that if the ltsp package shipped with a file in /usr/share/gconf/defaults/10-compiz, which made compiz==off by default, it would save people some trouble...
[10:27] [stgraber] alkisg: well, the way LTSP works currently is that it matches the distro's behavior that you'd have if you installed the distro directly on the thin client
[10:28] [stgraber] alkisg: my goal for Ubuntu is to have LTSP's user experience identical to a regular desktop one, unfortunately this also means having the same bugs ;)
[10:28] [alkisg] stgraber: sure, but some cards have compiz problems with LTSP while they don't have them as normal workstations
[10:28] [stgraber] so in these cases, a bug should probably be opened against compiz so that this specific hardware is blacklisted in compiz itself
[10:28] [alkisg] Because of the remote X that is involved
[10:29] [stgraber] alkisg: really ? We had that kind of issues when we were using the compiz-launcher that bypassed most checks, now we are using compiz's own checks and it seems to work for most broken hardware here (as in, compiz gets disabled)
[10:30] [stgraber] for the others, the bug should really be opened against compiz so that additional checks are added to blacklist these cards (or to fix the bug that prevent them from working properly)
[10:31] [stgraber] ideally I'd add a COMPIZ=false in lts.conf that'd let people disable compiz though Ubuntu's completely frozen right now and that's a new feature so that won't go through feature freeze easily
[10:31] [alkisg] Hmmm good idea though
[10:32] [john] In our case compiz does not really accomplish much anyway, 6 year olds don't seem to care to much for the features
[10:33] [alkisg] john, out of curiosity, what cards are these? lspci -nn...
[10:33] [alkisg] !localxterm
[10:33] [ltspbot`] alkisg: "localxterm" :: while sitting on a thin client, open a gnome terminal. In that, run: ltsp-localapps xterm. An xterm will open. That xterm runs locally, so any commands you enter there are executed directly on the client.
[10:33] [stgraber] it's not that much compiz that I want by default, it's compositing and compiz is probably the best compositing manager out there
[10:34] [stgraber] when a thin client runs a compositing manager, windows are stored as textures and cached locally. It essentially makes the network usage lower and makes the UI almost two times faster to use.
[10:34] [stgraber] it's basically what makes the LTSP desktop feels as it was a regular desktop. No more lag when moving/maximizing windows, ...
[10:34] [alkisg] But it also increases xorg ram requirements, I believe, so that COMPIZ=false option could have an additional use for low end PCs...
[10:35] [john] VIA Technologies, Inc. CN400/PM800/PM880/PN800/PN880 [S3 UniChrome Pro]
[10:35] [stgraber] alkisg: right, though in my tests, a whole desktop running with two monitors at 1680x1050 with 24bits color, take less than 90MB of RAM (for the whole system, not only X)
[10:36] [john] looks like VIA chipset for everything on this client, the client is a Wyse V50
[10:37] [alkisg] Hmmm I think I have a unichrome client with the same problem, but unfortunately it only has 128mb ram, so I cannot try it as a standalone client to see if the compiz problem is there as well...
[10:38] klausade (~klaus@cm-84.215.176.49.getinternet.no) joined #ltsp.
[10:39] [alkisg] stgraber: do you have anything in ltsp cluster for executing commands on the clients?
[10:39] [alkisg] Like, an ssh server on the chroot, or a daemon that listens for commands from the server etc?
[10:39] [stgraber] we usually run a ssh server in the chroot
[10:40] [stgraber] in the next generation of ltsp-cluster we have an XML+RPC daemon running on each thin clients and application servers with a plugin infrastructure that can be used to remotely execute actions or get data
[10:40] [alkisg] stgraber: I'm working on something like that, that's why I"m asking - do you have any code atm?
[10:40] ogra__ (~ogra@p4FDA6D80.dip.t-dialin.net) joined #ltsp.
[10:41] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[10:41] *** alkisg has written server+client code in bash, and is rewriting them on C/Python...
[10:41] ogra_cmpc (~ogra@p4FDA6D80.dip.t-dialin.net) left irc: Ping timeout: 265 seconds
[10:41] [johnny] no.. not xmlrpc stgraber :(
[10:41] [johnny] yuck
[10:41] [johnny] either use something stateful like xmpp
[10:41] [johnny] or something more restful like atompub or json
[10:42] [johnny] or use dbus
[10:42] [johnny] over tcp
[10:42] [johnny] please.. just not xmlrpc :(
[10:42] [alkisg] I'm looking to use something with "select" on the server, because e.g. python's socketserver needed 10 MB RAM for each client
[10:42] [alkisg] So for 100 clients 1Gb of RAM would be needed - yuck...
[10:42] [johnny] alkisg, considered having something on the client that inotifies ?
[10:42] [johnny] like incron ?
[10:42] [alkisg] johnny: inotify doesn't work over sshfs / nfs
[10:43] [johnny] sure.. but why not watch for a tmpfs/aufsed writable dir?
[10:43] [stgraber] alkisg: we have an xml+rpc server somewhere on launchpad with a relatively easy to use plugin infrastructure
[10:43] [alkisg] With "select" no forks/threads are neccessary, so the RAM requirements will be very low
[10:43] [johnny] stgraber, xmlrpc should die :(
[10:43] [johnny] seriously you should consider an xmpp server or dbus tho.. if you are keeping state..
[10:43] [stgraber] the server side is PHP, doing XML+RPC for communication with the daemons and a REST+JSON interface for the web UI and scripting
[10:43] [alkisg] johnny: I'm looking to implement reverse connections, for safety reasons
[10:43] [alkisg] stgraber: I'm guessing that won't run for 64 MB clients... :-/
[10:44] [alkisg] johnny: i.e. all clients connect to the server, they don't accept connections from anyone
[10:44] [alkisg] I'm reusing the ssh channel so it's also encrypted...
[10:44] [alkisg] stgraber: do you have some link handy?
[10:44] [stgraber] alkisg: not really an issue for us right now as we don't have anything with less than 1GB ;) But worst case we'll rewrite the daemon running on the thin clients in C, that should make things better.
[10:45] [alkisg] Oooh that would be perfect. I need to have this ready in a month or so, so if there's any code around, I might be able to utilize it / rewrite it / test it etc...
[10:46] [stgraber] johnny: dbus over TCP doesn't work that well when you have your server running on Windows and JSON is great to use with AJAX web interfaces but not that good when you need proper support of variable types and exceptions
[10:48] [johnny] ah.. server running on windows..
[10:48] klausade (~klaus@cm-84.215.176.49.getinternet.no) left irc: Quit: leaving
[10:48] [stgraber] not always but it can and our agent should ideally be the same for all appservs, be that Linux or Windows
[10:48] [johnny] sure..
[10:48] [johnny] just didn't think people would want to do that.. but i guess they might..
[10:49] [stgraber] well, we work with governments, large school districts and multi-nationals corporation, so ...
[10:49] klausade (~klaus@cm-84.215.176.49.getinternet.no) joined #ltsp.
[10:49] [johnny] xmpp with pubsub still sounds like a good idea tho..
[10:50] [stgraber] yeah, would need to look at that and see if I can get a single server to work with over 10000 thin clients
[10:51] [johnny] prosody seems like it could with libev
[10:52] [johnny] of course.. the main prosody dev is always lookin for xmpp related work.. so.. if you ever need somebody to code it up.. he could :)
[10:55] [stgraber] alkisg: bzr get lp:~ltsp-cluster-team/ltsp-cluster/ltsp-cluster-agent that's what I currently have in our internal bzr but I'm guessing it's missing quite a few revisions
[10:55] [alkisg] thanks stgraber :)
[10:56] [stgraber] alkisg: today is an holiday here so I'll poke the guy working on that tomorrow so he updates on LP (he always forget to push his changes ...)
[10:56] [johnny] alkisg, btw.. prosody runs on an openwrt
[10:56] [johnny] so.. it's tiny
[10:57] *** alkisg googles for prosody...
[10:57] [johnny] as in.. it can run on that..
[11:16] japerry (~japerry@drupal.org/user/45640/view) joined #ltsp.
[11:23] john (~john@216-102-74-141.scoe.org) left irc: Disconnected by services
[11:33] *** alkisg doesn't see any remote control implementations using reverse connections... :-/
[11:34] john (~john@216-102-74-141.scoe.org) joined #ltsp.
[11:38] [johnny] alkisg, cuz it's hard to do..
[11:39] [alkisg] johnny: Running a remote shell through XMPP: http://snippets.dzone.com/posts/show/6097
[11:39] [alkisg] 30 lines or less...
[11:39] [johnny] it could also be done in lua as a prosody module
[11:39] [johnny] you can probably convince mattj to write it for ya :)
[11:40] [johnny] ejabberd has one, but the ram footprint is alot higher
[11:40] [alkisg] If an XMPP server was running on the server, and the clients connected to it and gave it remote control capabilities, that would be reverse connections
[11:40] [alkisg] I just don't want daemons running on the clients, as they're insecure by design..
[11:40] [alkisg] *accepting connections
[11:40] [johnny] not as insecure as you think tho..
[11:40] [johnny] i think you'er makign too much of it
[11:40] [johnny] you already run with ldm directx on anyways don't you??
[11:41] [alkisg] Sure, but if I'm going to invest some time on something, I prefer to do it right if I can...
[11:41] [alkisg] Also, reverse connections enable the server to keep track of each client/user
[11:41] [johnny] well.. sure.. if the clients run an xmpp client on them.. of course you can trakc em
[11:42] [johnny] using telepathy would probably be a good idea here..
[11:42] [johnny] but i don't know if they have libraries and clients that are slim enough for your needs
[11:42] [johnny] that's probably the biggest problem
[11:42] [alkisg] There's already an ssh connection, so it'd be nice if that was reused (I'm currently port-forwarding the ports I use, and connect to localhost instead)
back next →
1 2 3 4
up
Generated by logs2html module for eggdrop v.2.3.4
Find latest version at http://sourceforge.net/projects/logs2html or http://shmupsik.osetia.org