Main page
[00:59] pths (~pts@89.87.213.193.static.cust.telenor.com) left irc: Quit: Ex-Chat
[01:31] Shingoshi (~Shingoshi@c-98-246-121-125.hsd1.or.comcast.net) joined #ltsp.
[01:32] Shingoshi (~Shingoshi@c-98-246-121-125.hsd1.or.comcast.net) left irc: Remote host closed the connection
[01:38] Shingoshi (~Shingoshi@c-98-246-121-125.hsd1.or.comcast.net) joined #ltsp.
[02:31] try2free (~send2us@118.96.121.24) joined #ltsp.
[02:32] try2free (send2us@118.96.121.24) left #ltsp.
[02:41] NeonLicht (~NeonLicht@darwin.ugr.es) joined #ltsp.
[04:03] hersonls (~hersonls@187.40.66.128) joined #ltsp.
[04:18] vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) left irc: Ping timeout: 252 seconds
[04:23] Egyptian[Home] (~EgyptianH@62.117.45.19) left irc: Read error: Connection reset by peer
[04:28] vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp.
[04:31] pmatulis (~peter@64.34.151.178) joined #ltsp.
[04:44] ogra (~ogra@ubuntu/member/ogra) left irc: Quit: Verlassend
[04:44] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[05:15] zirconiumks (~zirconium@123.201.93.142) joined #ltsp.
[05:17] GodFather_ (~rcc@c-98-209-42-178.hsd1.mi.comcast.net) joined #ltsp.
[05:26] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[05:34] otavio (~otavio@debian/developer/otavio) left irc: Quit: leaving
[05:35] otavio (~otavio@debian/developer/otavio) joined #ltsp.
[05:37] alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
[06:20] evilx_ (~evilx@70.230.174.20) left irc: Quit: Leaving
[06:21] slidesinger (~slidesing@c-68-44-99-50.hsd1.nj.comcast.net) joined #ltsp.
[06:22] Nick change: GodFather_ -> GodFather
[06:29] zirconiumks (~zirconium@123.201.93.142) left irc: Quit: Leaving
[06:43] leio (~leio@gentoo/developer/leio) joined #ltsp.
[06:54] vvinet_ (~vince@smtpin.revolutionlinux.com) joined #ltsp.
[06:54] vvinet_ (~vince@smtpin.revolutionlinux.com) left irc: Client Quit
[07:31] bobby_C (~bobby@188.20.161.210) joined #ltsp.
[07:32] mikkel (~mikkel@84-238-113-66.u.parknet.dk) joined #ltsp.
[07:59] nubae_ (~quassel@87.223.126.135) joined #ltsp.
[08:00] nubae (~quassel@87.223.140.22) left irc: Ping timeout: 240 seconds
[08:13] staffencasa (~staffenca@128-193-153-225.oregonstate.edu) joined #ltsp.
[08:31] mgariepy (~mgariepy@ubuntu/member/mgariepy) joined #ltsp.
[08:39] Faithful (~Faithful@202.6.145.116) left irc: Ping timeout: 258 seconds
[08:46] klausade (~klaus@cm-84.215.176.49.getinternet.no) joined #ltsp.
[08:54] Faithful (~Faithful@202.6.145.116) joined #ltsp.
[08:54] GodFather (~rcc@c-98-209-42-178.hsd1.mi.comcast.net) left irc: Quit: Ex-Chat
[09:01] akuepker (~akuepker@dsl254-058-194.sea1.dsl.speakeasy.net) joined #ltsp.
[09:12] [akuepker] Would anyone be interested in helping me duplicate an experiment? I'm having problems with some of my Ubuntu 9.10 LTSP implementations where the dbus messagebus process will effectively lock up and use 100% of one of the CPU. This prevents all dbus-dependent apps from operating well and LDM also breaks preventing login with valid credentials.
[09:12] [akuepker] It's happened 5 times across 2 different servers but only on our biggest servers where our Administrative folks are on terminals. Notably, these seem to have a correlation with users moving a large number of small files off a USB local device to the server through the Gnome Nautilus interface.
[09:13] alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
[09:13] [akuepker] If it just broke LDM it might be acceptable to schedule a reboot for later, but it also breaks Firefox which is problematic since 90% of our users rely on that for database web apps.
[09:14] [akuepker] I wish truss could give me some data on it, but since it's stuck that's no help either.
[09:15] [akuepker] alkisg: have you done much with Ubuntu?
[09:16] [alkisg] akuepker: erm, what do you mean?
[09:16] [akuepker] trying to duplicate a problem I'm seeing with Ubuntu dbus where the messagebus locks up.
[09:17] [akuepker] I think I've correlated the messagebus freeze with large numbers of small files moved from USB local devices to the server.
[09:18] [alkisg] You mean an ltspfsd related problem? I don't really use ltspfsd...
[09:18] [akuepker] ah. am trying to figure out if it only occurs with LDM_DIRECTX='true' or if it will occur in both situations.
[09:19] [alkisg] ...but I wonder how is ltspfsd related to dbus...
[09:19] [akuepker] I'm new to GNome since we used to be a KDE shop, but the Gnome file transfer status window would use dbus right?
[09:20] [alkisg] No idea...
[09:20] [akuepker] meaning I think ltspfsd would simply be a coincidence in this case
[09:21] [alkisg] If it's solely dbus related, then it isn't ltsp related, right? I mean, maybe you could get better help in some other channel..
[09:22] [akuepker] ok thanks. I'm kinda stuck since most of the Ubuntu folks I talk with consider it an "LTSP problem" since they don't see that error on their 9.10 single-user installs or understand why it can't simply be fixed by rebooting the system. Needless to say, I'm not a very popular sysadmin if I have to kick our entire executive team off the server for mid-day reboots on a regular basis.
[09:23] [alkisg] But ltsp doesn't have to do anything with dbus... if you said it's an ltspfsd problem, then yeah, it'd be an ltsp problem, but dbus?
[09:26] [akuepker] ok. I'll see if I can get some folks to take an interest in this. Thanks much.
[09:31] NeonLicht (~NeonLicht@darwin.ugr.es) left irc: Quit: leaving
[09:31] NeonLicht (~NeonLicht@darwin.ugr.es) joined #ltsp.
[09:36] vagrantc (~vagrant@c-76-27-239-73.hsd1.or.comcast.net) joined #ltsp.
[09:38] Lns (~Lns@pdpc/supporter/professional/lns) joined #ltsp.
[09:39] [Lns] Hey is there an ltsp-config.d/ now? Or is that more under the hood than lts.conf ? (re: alkis's list post)
[09:41] [vagrantc] there is an ltsp_config.d, but isn't necessarily created by default
[09:43] [vagrantc] if people don't object, i think it would be good to split ltsp_config into separate snippets in ltsp_config.d
[09:43] [vagrantc] though i'm tempted to add support in /etc/ltsp/ltsp_config.d
[09:44] [vagrantc] as sysadmins should be able to add plugins somewhere that conventionally gets backed up, whereas packages should be able to drop into /usr/share
[09:44] andrea (~andrea@ip-117-134.sn2.eutelia.it) joined #ltsp.
[09:44] Nick change: andrea -> Guest69716
[09:45] Guest69716 (~andrea@ip-117-134.sn2.eutelia.it) left irc: Client Quit
[09:46] shamael (~shamael@ip-117-134.sn2.eutelia.it) joined #ltsp.
[09:47] [shamael] hi! How can I control the umask of local devices plugged into thin clients (like thumbdrives and cds)?
[09:47] [vagrantc] recent versions make it only readable/writeable
[09:47] [vagrantc] by the user
[09:47] [vagrantc] ltspfs 0.5.14+
[09:49] [shamael] so there's no way to set a custom umask
[09:50] [vagrantc] don't believe so.
[09:50] [vagrantc] shamael: you need other people to read/write to it?
[09:50] [johnny] hmm.. would be nice to have command plugins that map to the names
[09:51] [johnny] so you don't have to have if isset, and if is boolean everywhere..
[09:51] [shamael] ideally, I'd like files copied off cds to inherit permissions based on the standard user's umask
[09:52] [vagrantc] shamael: that's not something specific to ltsp, really.
[09:54] [shamael] well gconf allows for custom mount options depending on the filesystem, but since the mounting is actually done by ltspfs, that setting gets bypassed. So I think it is a bit specific to ltsp.
[09:56] [alkisg] vagrantc: hi - any thoughts about ltsp_config.d? Should I commit ENABLE_WOL in ltsp_config or should I wait for ltsp_config.d (or should I put it in a site-specific package)? :)
[09:57] [vagrantc] alkisg: i'm supportive of moving everything into ltsp_config.d
[09:58] [alkisg] vagrantc: I think there are packaging changes involved, right? I mean, I can't just go ahead an create an ltsp_config.d directory in the sources... correct?
[09:58] [vagrantc] alkisg: why not?
[09:58] [vagrantc] i mean, there are packaging changes, sure.
[09:58] [vagrantc] but i don't see that as a reason to not move forward.
[09:59] [alkisg] Ah, but they could be done independently from the ltsp_config.d directory, got it
[09:59] [vagrantc] they have to be done independently
[10:00] [alkisg] So, can I just go ahead an create a ltsp-trunk/client/ltsp_config.d/enable_wol file?
[10:00] [alkisg] *and
[10:01] [vagrantc] i'm fine with it
[10:01] [alkisg] Thanks!
[10:01] [vagrantc] well... the plugin does what?
[10:01] [alkisg] It adds a new lts.conf variable
[10:01] [alkisg] ENABLE_WOL=False by default
[10:02] [alkisg] (erm, unset by default)
[10:02] [vagrantc] ltsp_config.d should only set variables, not actually do anything
[10:02] [alkisg] If the user sets it to true, and if ethtool is present, it executes ethtool -s eth0 wol g
[10:02] [alkisg] It's a network card setting..
[10:02] [alkisg] Hmm...
[10:03] *** alkisg wonders where that would go...
[10:04] [alkisg] ltsp-init-common is also growing too big...
[10:04] [vagrantc] doesn't execute any code
[10:05] [alkisg] I meant a function there, with the appropriate call in ltsp-setup
[10:06] [vagrantc] ah, right
[10:06] [vagrantc] that's more an appropriate way to handle it
[10:08] *** alkisg also wonders if ltsp-init-common should be broken in separate scripts :D
[10:08] [alkisg] Anyway, I'll put it there and leave all the splitting to more experienced devs :)
[10:11] epaphus (~name@190.10.68.228) joined #ltsp.
[10:12] [alkisg] (or if it could offer an ltsp-init.d directory...)
[10:12] [epaphus] hello. Iam installing a LTSP server with Ekiga as a local app (works good) . However ekiga needs to work with USB headphones. Is it possible to only allow USB headsets but disable usb-storage devices?
[10:13] [epaphus] hello alkisg :)
[10:13] [alkisg] Hi epaphus
[10:14] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) left irc: Quit: Leaving
[10:32] [Lns] vagrantc, I remember the discussion about ltsp-conf.d dir, that would be really really nice
[10:32] [Lns] would be easy (easier) to write tools for automated individual terminal config too that way
[10:33] [vagrantc] it's already there
[10:33] [Lns] what might be nice too is to have a README or similar with a master list of all possible variables
[10:33] [Lns] oh. =p well thanks!
[10:33] [vagrantc] !ltsp-docs
[10:33] [ltspbot] vagrantc: Error: "ltsp-docs" is not a valid command.
[10:33] [vagrantc] !docs
[10:33] [ltspbot] vagrantc: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
[10:33] *** Lns goes to read
[10:34] [vagrantc] it's not perfect, but it's got most of the documentation
[10:35] [vagrantc] or the ltsp-docs packages in debian
[10:36] [vagrantc] looks like it got pulled into ubuntu, too
[10:38] [Lns] very nice, i haven't looked at the upstream doc in a while!
[10:39] [Lns] though, not just through that doc but others, and kind of moot i guess, but it would be nice to standardize on a single term for "thin client/terminal/system/etc"
[10:39] *** Lns wants to bring back 'terminal'
[10:41] [alkisg] lTsp ;)
[10:42] [vagrantc] ltcsp
[10:42] [Lns] linux terminal/thin client/fat client/thin client with localapps/fat client with remote apps server project
[10:43] [vagrantc] ldsp
[10:43] [Lns] ?
[10:43] [vagrantc] "desktop"
[10:43] [Lns] ah
[10:43] [Lns] but then what about mobile users? ;)
[10:44] [vagrantc] we don't yet support mobile so much
[10:44] [Lns] but we WILL!
[10:44] runout (~runout@81-223-23-159.goesting.xdsl-line.inode.at) joined #ltsp.
[10:44] [Lns] think of it... android thin clients
[10:45] *** vagrantc fights the robots
[10:45] [Lns] bbiab
[10:45] Lns (~Lns@pdpc/supporter/professional/lns) left irc: Quit: Leaving
[10:46] [johnny] uhmm.. it's called webapps..
[10:46] [johnny] there are webapps for almost anything now
[10:47] [johnny] just not heavy games, video/audio production
[10:47] [johnny] everything else can be done via webapps
[10:47] [vagrantc] lwsp
[10:48] [akuepker] just don't crash your dbus and break your browsers like I manage to do =)
[10:54] [alkisg] How can I say Option "RenderAccel" "off" in lts.conf?
[10:56] *** alkisg tries X_OPTION_01 = "\"RenderAccell\" \"Off\""
[11:06] johnny (spectrum@johnny-pt.tunnel.tserv4.nyc4.ipv6.he.net) left #ltsp.
[11:15] ogra_cmpc (~ogra@p4FDA67D3.dip.t-dialin.net) left irc: Ping timeout: 246 seconds
[11:15] [stgraber] vagrantc: ltsp-docs updated in ubuntu
[11:19] Lns (~lns@pdpc/supporter/professional/lns) joined #ltsp.
[11:21] shamael (~shamael@ip-117-134.sn2.eutelia.it) left irc: Quit: Sto andando via
[11:24] nubae (~quassel@87.223.128.112) joined #ltsp.
[11:25] nubae_ (~quassel@87.223.126.135) left irc: Ping timeout: 258 seconds
[11:26] [vagrantc] stgraber: yeah, i saw ;)
[11:28] [stgraber] vagrantc: did you try 5.2.1 on Debian ?
[11:28] zirconiumks (~zirconium@123.201.10.176) joined #ltsp.
[11:28] ogra_cmpc (~ogra@p4FDA40BE.dip.t-dialin.net) joined #ltsp.
[11:29] [vagrantc] stgraber: not yet... should do that today...
[11:32] vagrantc (~vagrant@c-76-27-239-73.hsd1.or.comcast.net) left irc: Read error: Connection reset by peer
[11:32] vagrantc (~vagrant@c-76-27-239-73.hsd1.or.comcast.net) joined #ltsp.
[11:37] ogra_cmpc (~ogra@p4FDA40BE.dip.t-dialin.net) left irc: Ping timeout: 265 seconds
[11:37] ogra_cmpc (~ogra@p4FDA40BE.dip.t-dialin.net) joined #ltsp.
[11:52] [alkisg] Ah, `nomodeset` helps for TCs that hang in plymouth in Lucid...
[11:52] staffencasa (~staffenca@128-193-153-225.oregonstate.edu) left irc: Quit: Leaving
[11:56] [vagrantc] this whole fgconsole thing doesn't seem to work so well
[11:57] [vbundi] hey so the disadvantages to having many localapps installed would be a large chroot which in turn would take longer/more bandwidth to push out to clients?
[11:57] [vagrantc] it only downloads what is used
[11:58] [vbundi] so when I run ltsplocalapps firefox it copies firefox to the local ramdisk?
[11:58] [vagrantc] no
[11:58] [vagrantc] it just loads the program into ram over the network filesystem
[11:58] [vagrantc] just like it normally loads a program into ram over a disked filesystem
[11:58] [vbundi] ohh
[11:59] nubae_ (~quassel@87.223.127.150) joined #ltsp.
[11:59] [Lns] ltsp isn't THAT bulky... ;)
[11:59] nubae (~quassel@87.223.128.112) left irc: Ping timeout: 264 seconds
[11:59] [vagrantc] so a little more bandwidth on the network filesystem transfers, but way less constant bandwidth updating every mouse movement or change on the screen
[12:00] [vbundi] well yeah I was kinda confused how firefox was transfering over my 100M and loading in 4 seconds heh
[12:00] [vagrantc] 100M ain't all that slow.
[12:00] [Lns] oooo, SHUTDOWN_TIME ... *drool*
[12:00] [stgraber] Lns: hey, your pastebin doesn't work (or expired)
[12:01] [Lns] oh
[12:02] [Lns] stgraber: I got complaints when upgrading (I think?) my i386 chroot .. it said something about runlevel 2 not being default in LFS 1,2,3,4,5,6 or something similar..
[12:02] [Lns] I can probably dig it up if you need it
[12:02] [Lns] (latest ubu 10.04 w/your ppa)
[12:02] [Lns] it was for ltsp-client-core or something similar related to ltsp
[12:03] [runout] sometimes clients are doing crazy things. causing user processes to hang on the server and trashing the users homedir with the filesystem of the client machine until the whole harddisk is full. (jaunty). any idea?
[12:04] [runout] i found a scp process running on the client which does the strange copy
[12:04] [vagrantc] grrrr.
[12:04] [vagrantc] oh, i guess NFS_HOME isn't a boolean...
[12:04] [vagrantc] does getltscfg allow setting an empty value?
[12:06] [alkisg] vagrantc: I'm using "NFS_HOME=/home"... empty value, as in NFS_HOME="" ? I think it'll allow it...
back next →
1 2 3
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