IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 March 2010 (all times are UTC)
| 00:01 | F-GT has joined #ltsp | |
| 00:22 | japerry has quit IRC | |
| 00:22 | japerry_cat has joined #ltsp | |
| 00:38 | Egyptian[Home] has quit IRC | |
| 00:53 | Egyptian[Home] has joined #ltsp | |
| 00:57 | ogra_cmpc has quit IRC | |
| 00:59 | ogra_cmpc has joined #ltsp | |
| 01:15 | japerry_cat has quit IRC | |
| 01:15 | japerry has joined #ltsp | |
| 01:44 | pths has joined #ltsp | |
| 03:03 | pths has quit IRC | |
| 03:36 | Shingoshi has joined #ltsp | |
| 03:36 | Shingoshi has quit IRC | |
| 03:42 | Shingoshi has joined #ltsp | |
| 04:36 | try2free has joined #ltsp | |
| 04:37 | try2free has left #ltsp | |
| 04:45 | NeonLicht has joined #ltsp | |
| 06:08 | hersonls has joined #ltsp | |
| 06:23 | vmlintu has quit IRC | |
| 06:28 | Egyptian[Home] has quit IRC | |
| 06:32 | vmlintu has joined #ltsp | |
| 06:35 | pmatulis has joined #ltsp | |
| 06:48 | ogra has quit IRC | |
| 06:48 | ogra has joined #ltsp | |
| 07:20 | zirconiumks has joined #ltsp | |
| 07:22 | GodFather_ has joined #ltsp | |
| 07:30 | cliebow has joined #ltsp | |
| 07:39 | otavio has quit IRC | |
| 07:39 | otavio has joined #ltsp | |
| 07:41 | alkisg has quit IRC | |
| 08:24 | evilx_ has quit IRC | |
| 08:25 | slidesinger has joined #ltsp | |
| 08:26 | GodFather_ is now known as GodFather | |
| 08:33 | zirconiumks has quit IRC | |
| 08:48 | leio has joined #ltsp | |
| 08:58 | vvinet_ has joined #ltsp | |
| 09:36 | bobby_C has joined #ltsp | |
| 09:36 | mikkel has joined #ltsp | |
| 10:03 | nubae_ has joined #ltsp | |
| 10:04 | nubae has quit IRC | |
| 10:17 | staffencasa has joined #ltsp | |
| 10:35 | mgariepy has joined #ltsp | |
| 10:43 | Faithful has quit IRC | |
| 10:50 | klausade has joined #ltsp | |
| 10:58 | Faithful has joined #ltsp | |
| 10:58 | GodFather has quit IRC | |
| 11:05 | akuepker has joined #ltsp | |
| 11:16 | <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.
| |
| 11:16 | 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.
| |
| 11:17 | alkisg has joined #ltsp | |
| 11:17 | <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.
| |
| 11:18 | I wish truss could give me some data on it, but since it's stuck that's no help either.
| |
| 11:20 | alkisg: have you done much with Ubuntu?
| |
| 11:20 | <alkisg> akuepker: erm, what do you mean?
| |
| 11:21 | <akuepker> trying to duplicate a problem I'm seeing with Ubuntu dbus where the messagebus locks up.
| |
| 11:21 | I think I've correlated the messagebus freeze with large numbers of small files moved from USB local devices to the server.
| |
| 11:22 | <alkisg> You mean an ltspfsd related problem? I don't really use ltspfsd...
| |
| 11:23 | <akuepker> ah. am trying to figure out if it only occurs with LDM_DIRECTX='true' or if it will occur in both situations.
| |
| 11:23 | <alkisg> ...but I wonder how is ltspfsd related to dbus...
| |
| 11:23 | <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?
| |
| 11:24 | <alkisg> No idea...
| |
| 11:24 | <akuepker> meaning I think ltspfsd would simply be a coincidence in this case
| |
| 11:25 | <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..
| |
| 11:26 | <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.
| |
| 11:27 | <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?
| |
| 11:31 | <akuepker> ok. I'll see if I can get some folks to take an interest in this. Thanks much.
| |
| 11:35 | NeonLicht has quit IRC | |
| 11:35 | NeonLicht has joined #ltsp | |
| 11:40 | vagrantc has joined #ltsp | |
| 11:42 | Lns has joined #ltsp | |
| 11:43 | <Lns> Hey is there an ltsp-config.d/ now? Or is that more under the hood than lts.conf ? (re: alkis's list post)
| |
| 11:45 | <vagrantc> there is an ltsp_config.d, but isn't necessarily created by default
| |
| 11:47 | if people don't object, i think it would be good to split ltsp_config into separate snippets in ltsp_config.d
| |
| 11:48 | though i'm tempted to add support in /etc/ltsp/ltsp_config.d
| |
| 11:48 | as sysadmins should be able to add plugins somewhere that conventionally gets backed up, whereas packages should be able to drop into /usr/share
| |
| 11:49 | andrea has joined #ltsp | |
| 11:49 | andrea is now known as Guest69716 | |
| 11:50 | shamael has joined #ltsp | |
| 11:51 | <shamael> hi! How can I control the umask of local devices plugged into thin clients (like thumbdrives and cds)?
| |
| 11:52 | <vagrantc> recent versions make it only readable/writeable
| |
| 11:52 | by the user
| |
| 11:52 | ltspfs 0.5.14+
| |
| 11:53 | <shamael> so there's no way to set a custom umask
| |
| 11:54 | <vagrantc> don't believe so.
| |
| 11:55 | shamael: you need other people to read/write to it?
| |
| 11:55 | <johnny> hmm.. would be nice to have command plugins that map to the names
| |
| 11:55 | so you don't have to have if isset, and if is boolean everywhere..
| |
| 11:56 | <shamael> ideally, I'd like files copied off cds to inherit permissions based on the standard user's umask
| |
| 11:57 | <vagrantc> shamael: that's not something specific to ltsp, really.
| |
| 11:59 | <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.
| |
| 12:01 | <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)? :)
| |
| 12:01 | <vagrantc> alkisg: i'm supportive of moving everything into ltsp_config.d
| |
| 12:02 | <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?
| |
| 12:02 | <vagrantc> alkisg: why not?
| |
| 12:03 | i mean, there are packaging changes, sure.
| |
| 12:03 | but i don't see that as a reason to not move forward.
| |
| 12:03 | <alkisg> Ah, but they could be done independently from the ltsp_config.d directory, got it
| |
| 12:03 | <vagrantc> they have to be done independently
| |
| 12:04 | <alkisg> So, can I just go ahead an create a ltsp-trunk/client/ltsp_config.d/enable_wol file?
| |
| 12:04 | *and
| |
| 12:05 | <vagrantc> i'm fine with it
| |
| 12:05 | <alkisg> Thanks!
| |
| 12:06 | <vagrantc> well... the plugin does what?
| |
| 12:06 | <alkisg> It adds a new lts.conf variable
| |
| 12:06 | ENABLE_WOL=False by default
| |
| 12:06 | (erm, unset by default)
| |
| 12:06 | <vagrantc> ltsp_config.d should only set variables, not actually do anything
| |
| 12:06 | <alkisg> If the user sets it to true, and if ethtool is present, it executes ethtool -s eth0 wol g
| |
| 12:07 | It's a network card setting..
| |
| 12:07 | Hmm...
| |
| 12:08 | * alkisg wonders where that would go... | |
| 12:08 | <alkisg> ltsp-init-common is also growing too big...
| |
| 12:08 | <vagrantc> doesn't execute any code
| |
| 12:09 | <alkisg> I meant a function there, with the appropriate call in ltsp-setup
| |
| 12:10 | <vagrantc> ah, right
| |
| 12:10 | that's more an appropriate way to handle it
| |
| 12:12 | * alkisg also wonders if ltsp-init-common should be broken in separate scripts :D | |
| 12:13 | <alkisg> Anyway, I'll put it there and leave all the splitting to more experienced devs :)
| |
| 12:16 | epaphus has joined #ltsp | |
| 12:16 | <alkisg> (or if it could offer an ltsp-init.d directory...)
| |
| 12:17 | <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?
| |
| 12:17 | hello alkisg :)
| |
| 12:17 | <alkisg> Hi epaphus
| |
| 12:18 | cliebow has quit IRC | |
| 12:36 | <Lns> vagrantc, I remember the discussion about ltsp-conf.d dir, that would be really really nice
| |
| 12:37 | would be easy (easier) to write tools for automated individual terminal config too that way
| |
| 12:37 | <vagrantc> it's already there
| |
| 12:37 | <Lns> what might be nice too is to have a README or similar with a master list of all possible variables
| |
| 12:37 | oh. =p well thanks!
| |
| 12:37 | <vagrantc> !ltsp-docs
| |
| 12:37 | <ltspbot> vagrantc: Error: "ltsp-docs" is not a valid command.
| |
| 12:38 | <vagrantc> !docs
| |
| 12:38 | <ltspbot> vagrantc: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
| 12:38 | * Lns goes to read | |
| 12:38 | <vagrantc> it's not perfect, but it's got most of the documentation
| |
| 12:39 | or the ltsp-docs packages in debian
| |
| 12:40 | looks like it got pulled into ubuntu, too
| |
| 12:42 | <Lns> very nice, i haven't looked at the upstream doc in a while!
| |
| 12:44 | 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"
| |
| 12:44 | * Lns wants to bring back 'terminal' | |
| 12:46 | <alkisg> lTsp ;)
| |
| 12:46 | <vagrantc> ltcsp
| |
| 12:47 | <Lns> linux terminal/thin client/fat client/thin client with localapps/fat client with remote apps server project
| |
| 12:47 | <vagrantc> ldsp
| |
| 12:48 | <Lns> ?
| |
| 12:48 | <vagrantc> "desktop"
| |
| 12:48 | <Lns> ah
| |
| 12:48 | but then what about mobile users? ;)
| |
| 12:48 | <vagrantc> we don't yet support mobile so much
| |
| 12:48 | <Lns> but we WILL!
| |
| 12:49 | runout has joined #ltsp | |
| 12:49 | <Lns> think of it... android thin clients
| |
| 12:49 | * vagrantc fights the robots | |
| 12:50 | <Lns> bbiab
| |
| 12:50 | Lns has quit IRC | |
| 12:51 | <johnny> uhmm.. it's called webapps..
| |
| 12:51 | there are webapps for almost anything now
| |
| 12:51 | just not heavy games, video/audio production
| |
| 12:51 | everything else can be done via webapps
| |
| 12:51 | <vagrantc> lwsp
| |
| 12:53 | <akuepker> just don't crash your dbus and break your browsers like I manage to do =)
| |
| 12:58 | <alkisg> How can I say Option "RenderAccel" "off" in lts.conf?
| |
| 13:01 | * alkisg tries X_OPTION_01 = "\"RenderAccell\" \"Off\"" | |
| 13:10 | johnny has left #ltsp | |
| 13:20 | ogra_cmpc has quit IRC | |
| 13:20 | <stgraber> vagrantc: ltsp-docs updated in ubuntu
| |
| 13:24 | Lns has joined #ltsp | |
| 13:26 | shamael has quit IRC | |
| 13:29 | nubae has joined #ltsp | |
| 13:29 | nubae_ has quit IRC | |
| 13:30 | <vagrantc> stgraber: yeah, i saw ;)
| |
| 13:32 | <stgraber> vagrantc: did you try 5.2.1 on Debian ?
| |
| 13:32 | zirconiumks has joined #ltsp | |
| 13:33 | ogra_cmpc has joined #ltsp | |
| 13:34 | <vagrantc> stgraber: not yet... should do that today...
| |
| 13:36 | vagrantc has quit IRC | |
| 13:37 | vagrantc has joined #ltsp | |
| 13:41 | ogra_cmpc has quit IRC | |
| 13:42 | ogra_cmpc has joined #ltsp | |
| 13:56 | <alkisg> Ah, `nomodeset` helps for TCs that hang in plymouth in Lucid...
| |
| 13:56 | staffencasa has quit IRC | |
| 14:00 | <vagrantc> this whole fgconsole thing doesn't seem to work so well
| |
| 14:01 | <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?
| |
| 14:01 | <vagrantc> it only downloads what is used
| |
| 14:02 | <vbundi> so when I run ltsplocalapps firefox it copies firefox to the local ramdisk?
| |
| 14:02 | <vagrantc> no
| |
| 14:03 | it just loads the program into ram over the network filesystem
| |
| 14:03 | just like it normally loads a program into ram over a disked filesystem
| |
| 14:03 | <vbundi> ohh
| |
| 14:03 | nubae_ has joined #ltsp | |
| 14:03 | <Lns> ltsp isn't THAT bulky... ;)
| |
| 14:04 | nubae has quit IRC | |
| 14:04 | <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
| |
| 14:04 | <vbundi> well yeah I was kinda confused how firefox was transfering over my 100M and loading in 4 seconds heh
| |
| 14:05 | <vagrantc> 100M ain't all that slow.
| |
| 14:05 | <Lns> oooo, SHUTDOWN_TIME ... *drool*
| |
| 14:05 | <stgraber> Lns: hey, your pastebin doesn't work (or expired)
| |
| 14:05 | <Lns> oh
| |
| 14:06 | 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..
| |
| 14:06 | I can probably dig it up if you need it
| |
| 14:06 | (latest ubu 10.04 w/your ppa)
| |
| 14:07 | it was for ltsp-client-core or something similar related to ltsp
| |
| 14:07 | <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?
| |
| 14:08 | i found a scp process running on the client which does the strange copy
| |
| 14:08 | <vagrantc> grrrr.
| |
| 14:09 | oh, i guess NFS_HOME isn't a boolean...
| |
| 14:09 | does getltscfg allow setting an empty value?
| |
| 14:11 | <alkisg> vagrantc: I'm using "NFS_HOME=/home"... empty value, as in NFS_HOME="" ? I think it'll allow it...
| |
| 14:11 | <vbundi> I'm gonna be making a new LTSP server from scratch for production, would you say it's a good idea to just wait till 10.04 is released?
| |
| 14:11 | <vagrantc> alkisg: NFS_HOME=server-ip:/path/to/home ?
| |
| 14:12 | <alkisg> Yup
| |
| 14:12 | <vagrantc> alkisg: NFS_HOME=/home ... would do?
| |
| 14:12 | <akuepker> has anyone tried to 9.10 > 10.04 upgrade path?
| |
| 14:12 | <alkisg> vagrantc: yes, it's using server-ip in that case
| |
| 14:12 | <vbundi> I'm not in a huge rush to do this thing, so if I'm gonna be waiting on 10.04 I'd be happy to help with any testing
| |
| 14:12 | <Lns> vbundi: the more testing the better :)
| |
| 14:12 | I'm doing the same atm
| |
| 14:13 | will roll out 10.04 in August for schools, testing at my own office right now
| |
| 14:13 | <vagrantc> stgraber: * Turn off chroot compression by default. As it makes NBD unstable. ?? using squashfs without compression now?
| |
| 14:15 | <Lns> makes updates much faster ;)
| |
| 14:15 | <vagrantc> why not just use ext2 at that point?
| |
| 14:15 | then you can edit the image directly...
| |
| 14:15 | <alkisg> ext2 would be much better :)
| |
| 14:16 | * alkisg is using a separate partition for fat clients... | |
| 14:16 | <alkisg> ...published with nbd
| |
| 14:16 | No update necessary at all
| |
| 14:17 | <Lns> huh? Tell me more
| |
| 14:17 | <vagrantc> the downside to using ext2 is that editing the image while running clients are using it can result in filesystem corruption from the running thin clients
| |
| 14:17 | <Lns> well updating the image will do the same thing, right?
| |
| 14:17 | i've always noticed that if i had terminals up while i update the image, when i go to shut down from ldm, it hangs
| |
| 14:17 | <vagrantc> no, because you actually generate a new file, and the old connections continue to use the old one
| |
| 14:18 | <Lns> oh...weird then
| |
| 14:18 | <vagrantc> might be another issue
| |
| 14:18 | <Lns> 8.04 issue
| |
| 14:18 | <stgraber> vagrantc: I'd have to check but during my tests, ext2 would still be 20% larger than uncompressed squashfs because squashfs is designed to be ready-only, doesn't have any empty space in it (free inodes, space for additional inodes, ...)
| |
| 14:18 | <vagrantc> stgraber: true enough ... but direct editability is pretty sweet.
| |
| 14:19 | <stgraber> and has you pointed out, users are likely to try and update the image as it's being used which would pretty much crash all your clients ;)
| |
| 14:19 | <vagrantc> stgraber: is there a bzr repository with the diffs in your packaging dirs?
| |
| 14:19 | <stgraber> yeah, hang on a sec
| |
| 14:20 | lp:~stgraber/ltsp/ltsp.lucid
| |
| 14:20 | <alkisg> Lns: I just put "2000 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/nbdrootd /dev/sda3" in /etc/inetd.conf. /dev/sda3 is unmounted, and I only mount it when I want to update it.
| |
| 14:20 | <vagrantc> direct images... crazy.
| |
| 14:20 | <alkisg> Lns: this way, no ltsp-update-image is necessary. It helps me in fat client testing, because generating an 11 Gb nbd takes a loooong time...
| |
| 14:21 | <Lns> that should totally be integrated into ltsp
| |
| 14:21 | of course you'd need to make sure you set up that partition =)
| |
| 14:21 | <alkisg> But as stgraber says, I don't want this for my users, because the mounting/unmounting is not yet automated by the tools...
| |
| 14:22 | Lns, if you mount /dev/sda3 to /opt/ltsp/i386 when you create the chroot, you don't need anything else. Or you can just copy it aftewards
| |
| 14:22 | <Lns> sure
| |
| 14:24 | <vagrantc> stgraber: is ubuntu moving to dpkg source format v3 at all?
| |
| 14:27 | <alkisg> Lns, what I'd like is to change the ltsp initscripts a bit, so that an nbd fat partition could be booted directly from the ltsp server. This way the teachers would customize the chroot normally, like they do with any linux installation... i.e. synaptic to install programs, sabayon/gconf for locking etc
| |
| 14:28 | That would also ensure that they don't update the chroot while clients are running ;)
| |
| 14:32 | <stgraber> vagrantc: some packages have
| |
| 14:32 | vagrantc: LP started to support it early this cycle I believe and I've upload one or two packages that were using v3
| |
| 14:33 | <vagrantc> stgraber: seems like v3 would make your image management so much simpler
| |
| 14:33 | <stgraber> and I sort of hoped LTSP was v3 when uploading that .png in debian/ the other day ... had to use base64 to have diff stop complaining ...
| |
| 14:33 | <vagrantc> uuencoding and whatnot is pretty ugly
| |
| 14:33 | or base64 or whatever
| |
| 14:34 | <stgraber> yeah, ldm used to have the same hack though now that it's a separate source package we don't have that issue anymore
| |
| 14:35 | litlebuda has joined #ltsp | |
| 14:38 | <vagrantc> right
| |
| 14:38 | * vagrantc pushed for that for years | |
| 14:39 | litlebuda has quit IRC | |
| 14:42 | <Lns> Ok, so is LOCAL_APPS_WHITELIST after actual typed commands for programs, or .desktop files like LOCAL_APPS_MENU_ITEMS ?
| |
| 14:42 | Desc. says "Used to allow only specified space-separated commands to be run as local apps, allow all is default if unset. Full-paths are required for each command. No spaces in the names are allowed."
| |
| 14:44 | <vagrantc> Lns: it's a whitelist of actually commands, so you could have a .desktop file that doesn't have the ability to actually execute the binary...
| |
| 14:44 | hopefully the menu generator verifies that before tweaking .desktop menus
| |
| 14:45 | <Lns> hmmm
| |
| 14:45 | vagrantc: you mean, if an app isn't installed on the server itself, it wouldn't execute via .desktop file?
| |
| 14:46 | <vagrantc> Lns: it has to be installed in the thin-client for localapps to work, not on the server
| |
| 14:46 | <Lns> right
| |
| 14:47 | but what you said above was a little confusing to me
| |
| 14:47 | <alkisg> Lns, if you have firefox.desktop in the chroot, but LOCAL_APPS_WHITELIST=chromium-browser, then firefox won't run
| |
| 14:47 | <Lns> so let's say I want to only run rdesktop as a localapp.. i can put that in a whitelist such as "LOCAL_APPS_WHITELIST = /usr/bin/rdesktop" and it will be guaranteed to only run as a localapp?
| |
| 14:47 | <vagrantc> well, LOCAL_APPS_MENU_ITEMS creates .desktop files on the thin client that are copied to the server into a temporary directory...
| |
| 14:48 | <Lns> oh ok
| |
| 14:48 | and those override the server .desktop files right?
| |
| 14:49 | <vagrantc> Lns: no, LOCAL_APPS_WHITELIST will only allow those applications to run as localapps, so if someone tried to run another command as a localapp, it will fail.
| |
| 14:49 | <Lns> oooooh.
| |
| 14:49 | <vagrantc> yeah, the .desktop files override the server entries
| |
| 14:49 | the LOCAL_APPS_MENU thing is related, but different
| |
| 14:50 | <Lns> because you could normally do 'ltsp-localapps programname' from a console and get it as a localapp aside from whats in lts.conf
| |
| 14:50 | <vagrantc> Lns: sure.
| |
| 14:50 | <Lns> *click* thanks
| |
| 14:50 | <vagrantc> or even manually do what ltsp-localapps does, if ltsp-localapps wasn't installed
| |
| 14:50 | it's practically a one-liner
| |
| 14:50 | <Lns> ?
| |
| 14:51 | <vagrantc> read ltsp-localapps, it's a very short script
| |
| 14:51 | <Lns> ok
| |
| 14:51 | <vagrantc> someone could run that manually
| |
| 14:51 | basically.
| |
| 14:52 | zirconiumks has quit IRC | |
| 14:53 | <Lns> oh wow. I kinda thought before it was done through ssh tunnel or something.
| |
| 14:54 | <vagrantc> it uses x properties
| |
| 14:55 | it just uses the X server.
| |
| 14:55 | so it's as secure as any application on the thin client.
| |
| 14:57 | <Lns> man...after so many years of understanding how x works, this kinda stuff still baffles me =)
| |
| 14:58 | I remember about 7 years ago messing around with just running apps from one computer, displaying on another..that was such an epiphany for me and *nix
| |
| 14:59 | wwx has quit IRC | |
| 15:02 | <vagrantc> Lns: i hear ya.
| |
| 15:04 | wwx has joined #ltsp | |
| 15:05 | pmatulis has quit IRC | |
| 15:12 | <Lns> vagrantc: so, xprop is merely used as kind of a listener for property changes so it knows to execute the command locally? Is xprop the best way to do that? I don't think I understand, unless it was for simplicity's sake to use it.
| |
| 15:13 | <vagrantc> Lns: xprop sets a property in the X server, and on the thin client there's a daemon that listens for changes to the x property.
| |
| 15:13 | <Lns> right
| |
| 15:13 | <vagrantc> Lns: it makes it easy to have localapps work the same weather using LDM_DIRECTX or not
| |
| 15:14 | it's also a relatively simple communication channel... both the thin client and the server can read/write x properties
| |
| 15:14 | so it's bi-directional communication
| |
| 15:14 | <Lns> ok, so xprop functionality itself isn't crucial to how localapps works besides that it sets a property and localappsd listens for it and executes when a change is detected?
| |
| 15:14 | <vagrantc> Lns: right. could implement the xprop functionality through some other shared communication method
| |
| 15:15 | <Lns> ooooh ok :) cool.
| |
| 15:15 | <vagrantc> sounded like alkisg had some ideas setting up a listener on the ssh socket or something like that
| |
| 15:15 | <Lns> yeah, i was just thinking that could be used for all sorts of things!
| |
| 15:15 | arbitrary commands run on the terminal/client via xprop
| |
| 15:16 | <alkisg> My main problem is that only the root has access to the ssh socket
| |
| 15:16 | <Lns> such as shutdown
| |
| 15:16 | <alkisg> I'd like the listener to be ran as the local user...
| |
| 15:16 | <vagrantc> well, right now only root on the local display has access to the x properties
| |
| 15:16 | <Lns> what about rootless x? isn't that implemented?
| |
| 15:17 | <vagrantc> Lns: the newer shutdown features are implemented using x properties
| |
| 15:17 | <Lns> oh yeah? neat!!
| |
| 15:18 | <vagrantc> the x properties communication channel is pretty elegant. i guess the upstream X.org folks are cautious about abusing it... there's some potentially overhead if you use it too much ... but for occasional things it seems quite elegant
| |
| 15:21 | <alkisg> Would a special ltsp user with no shell be considered as a security problem? (nx does the same...)
| |
| 15:22 | <vagrantc> nx is considered a security problem...
| |
| 15:22 | :)
| |
| 15:23 | alkisg: how different is your ssh listener from the x properties listener? they both run as root
| |
| 15:23 | olitask has joined #ltsp | |
| 15:23 | <alkisg> vagrantc: it's not; it just provides for feedback
| |
| 15:23 | <vagrantc> they both accept information from untrusted sources...
| |
| 15:23 | <alkisg> vagrantc: the client is authenticated, so it's not untrusted
| |
| 15:24 | With an ssh listener, the server can run commands on the client and get feedback
| |
| 15:25 | I.e. send me your ram / hostname whatever
| |
| 15:25 | <vagrantc> alkisg: it's a server-side listener?
| |
| 15:25 | <alkisg> No, it runs on the client over the ssh socket that is created when the user logs on
| |
| 15:25 | <vagrantc> alkisg: ah, you're talking about something pre-login?
| |
| 15:25 | <alkisg> But there's a server side as well
| |
| 15:25 | <vagrantc> hm.
| |
| 15:25 | <alkisg> I think I'll describe it better if I say what I want to do :)
| |
| 15:26 | I want the teacher to be able to e.g. lock the user screen or cut the internet or turn off the sound or launch a firefox page etc
| |
| 15:26 | <vagrantc> ah, you could determine localapps/remoteapps/fatclient support at login time based on client resources?
| |
| 15:26 | <alkisg> That should work in thin/fat clients and in localapps, so it can't be done server-side only
| |
| 15:26 | <vagrantc> sure
| |
| 15:27 | <alkisg> And I want to get thumbnails of the clients screens, so I also need feedback, not just one-way commands
| |
| 15:27 | <vagrantc> alkisg: basically italc/controlaula type stuff?
| |
| 15:27 | <alkisg> vagrantc: yes, but with lots and lots more options, and more ltsp-oriented
| |
| 15:27 | <vagrantc> sure
| |
| 15:28 | <alkisg> So if I could use the ssh channel to run apps inside the user session, that would be the best
| |
| 15:28 | But that's hard to do because only the root has access to the socket...
| |
| 15:28 | * alkisg hasn't thought all of this through yet | |
| 15:29 | <olitask> hello, I'm looking for help to use a eeepc as thin client . It boot on the server but after a moment i have this error : can't open /tmp/net-eth0.conf eth0 on the eeepc is a Attansic L2 100 Mbit Ethernet Adapter
| |
| 15:29 | <vagrantc> it's kind of a weird idea... but what about creating a temp directory on the server, and sshfs mounting it on the client
| |
| 15:30 | akuepker has quit IRC | |
| 15:30 | <vagrantc> then you could read and write to files on either side...
| |
| 15:30 | <alkisg> vagrantc: the problem is that inotify doesn't work over ssh or nfs
| |
| 15:31 | Neither do pipes
| |
| 15:32 | So for fat clients/localapps it would need to go server => ssh channel => client root => file or socket => client user
| |
| 15:33 | olitask: afaik you need to insert the module manually in the initramfs
| |
| 15:35 | olitask: I wrote a wiki page for that, it might help you: https://help.ubuntu.com/community/UbuntuLTSP/AddingModules
| |
| 15:36 | <vagrantc> stgraber: well, ltsp 5.2.1 + ldm 2.1.1 is a bust for debian...
| |
| 15:36 | ldm just plain doesn't start.
| |
| 15:36 | seems like it doesn't even try to start it
| |
| 15:37 | oh, wait... it worked when i just left the defaults...
| |
| 15:37 | but with SCREEN_07=ldm and SCREEN_08=shell, it seems like it didn't even try to start the ldm screen script.
| |
| 15:38 | <olitask> alkisg> thank you i will test
| |
| 15:38 | <vagrantc> all this rewriting of screen script handling seems really invasive.
| |
| 15:38 | vvinet has quit IRC | |
| 15:41 | <Lns> LDM_ALLOW_USER seems really nice, but it makes me think that LDM_ALLOW_GROUP would be nice too for catch-alls
| |
| 15:42 | for users within a group to be allowed on
| |
| 15:42 | <alkisg> Lns, the TCs do not know which groups exist on the server... so they don't know the groups of the user that tries to login, before he actually does
| |
| 15:43 | <Lns> ah yes
| |
| 15:56 | <vagrantc> stgraber: so here's the curiosity. if i specify only one SCREEN_NN in lts.conf (or the default SCREEN_07=ldm), the ldm screen script works fine, but if i specify multiple SCREEN_07, SCREEN_08, SCREEN_09 ... only one of them works.
| |
| 16:01 | Egyptian[Home] has joined #ltsp | |
| 16:02 | <vbundi> vagrantc: I had this problem too where I"d specify screen_02 for shell, screen_06 for rdesktop and 07 for ldm and only LDM would work
| |
| 16:03 | vagrantc: I changed my configuration file one day and they all started working.... I don't know what the reasoning was for it though
| |
| 16:04 | <vagrantc> vbundi: what version of ltsp are you talking about? i'm testing 5.2.1
| |
| 16:04 | i haven't had this problem at all on other versions, although debian carried a patch to revert one use of fgconsole
| |
| 16:04 | <vbundi> I'm using stephen's ppa
| |
| 16:04 | so not sure.. runnin 9.10 ubuntu tho
| |
| 16:05 | mgariepy has quit IRC | |
| 16:06 | <vbundi> vagrantc: I'
| |
| 16:06 | nubae has joined #ltsp | |
| 16:06 | <vbundi> vagrantc: not sure if this would affect things.. but at one point I had my screen settings out of order in lts.conf, ie having the line specifying screen 6 AFTER the one that specifies screen 7...
| |
| 16:06 | <vagrantc> yup... commented out another instance of fgconsole, and it works.
| |
| 16:07 | nubae_ has quit IRC | |
| 16:07 | <vagrantc> aha.
| |
| 16:07 | <vbundi> ?
| |
| 16:08 | <vagrantc> fgconsole returns 8, and SCREEN_NUM is set to 08 ... so they never match and it ends up in an infinite loop
| |
| 16:08 | <vbundi> ahh
| |
| 16:09 | hersonls has quit IRC | |
| 16:09 | runout has left #ltsp | |
| 16:18 | <vagrantc> hmmm... so... fgconsole is returning 8 for screen_session on 7
| |
| 16:18 | <alkisg> vagrantc: [ 08 -ne 8 ] || echo "They're equal"
| |
| 16:19 | <vagrantc> alkisg: yeah, that didn't fix it
| |
| 16:19 | seems like it's being run from the wrong console.
| |
| 16:19 | while [ $(fgconsole) -ne ${SCREEN_NUM#0} ]; do sleep 2
| |
| 16:19 | is what's broken
| |
| 16:20 | <alkisg> That's supposed to wait until the users switches to that console
| |
| 16:20 | So e.g. when I put SCREEN_02=shell, I need to switch to vt2 before the shell screen script is executed..
| |
| 16:20 | <vagrantc> that console is not switchable.
| |
| 16:20 | i can't switch to a console that doesn't exist
| |
| 16:20 | <alkisg> I reported that to Gadi but I thought stgraber fixed it afterwards..
| |
| 16:21 | <vagrantc> all kinds of not working for me.
| |
| 16:22 | will try with ldm at a higher screen number than shell
| |
| 16:22 | * alkisg has had so many plymouth related problems that didn't have time to test the new vt switching code... | |
| 16:22 | <vagrantc> might just be different behavior between debian/ubuntu
| |
| 16:24 | well, if i comment out the while loop, it works fine.
| |
| 16:24 | at least, as best i can tell
| |
| 16:25 | nothing that a little && /bin/false can't fix.
| |
| 16:27 | hrm.
| |
| 16:27 | if i set SCREEN_08=shell and SCREEN_09=ldm, it ends up on the shell by default
| |
| 16:27 | if i set SCREEN_07=ldm and SCREEN_08=shell, it shows ldm by default.
| |
| 16:29 | Lns has quit IRC | |
| 16:29 | <alkisg> ltsp-core: for screen in 01 02 03 04 05 06 07 08 09 10 11 12; do
| |
| 16:29 | I think if you reverse that, you'll get the opposite results...
| |
| 16:29 | <vagrantc> right
| |
| 16:29 | <alkisg> (for screen in 12 11 10...)
| |
| 16:30 | <vagrantc> in the ancient times of ltsp 5.2(.0) and earlier, it would always come up with ldm as the default, unless there was another competing X-related SCREEN_ thing
| |
| 16:30 | <alkisg> In LTSP 5.2.0 it was broken in Ubuntu
| |
| 16:31 | <vagrantc> worked in debian, although i reverted one of the uses of fgconsole
| |
| 16:31 | <alkisg> Last time it was working OK it was in Karmic... it was never working in Lucid
| |
| 16:32 | <vagrantc> this was a major rewrite, and it's just plain broken.
| |
| 16:34 | <alkisg> Yeah... and 3-4 people worked on it, noone managed to get it right. /me blames plymouth :)
| |
| 16:36 | Gadi has joined #ltsp | |
| 16:37 | <vagrantc> Gadi: you and your crazy vt switching!
| |
| 16:37 | <Gadi> heh - I was just checking the logs and saw u guys talking
| |
| 16:37 | :)
| |
| 16:37 | figured I should hop in real quick
| |
| 16:37 | <vagrantc> it's real borked for debian :)
| |
| 16:37 | <Gadi> it's really borked all over
| |
| 16:38 | <vagrantc> it touches so many files in so many places, it's a little tricky to revert...
| |
| 16:38 | <Gadi> this all started with a quest for flickerless boot or some such
| |
| 16:38 | but it revealed a whole mess of race conditions that were always persent
| |
| 16:38 | and never dealt with properly
| |
| 16:38 | * vagrantc craves flicker | |
| 16:38 | * Gadi too | |
| 16:39 | <Gadi> so, this is what *should* happen:
| |
| 16:39 | all screen scripts should wait in a holding pattern until switched to
| |
| 16:39 | then, the initscript should switch to one specific vt on boot
| |
| 16:40 | (should be the highest numbered or SCREEN_DEFAULT if specified)
| |
| 16:40 | on Ubuntu, the only problem I have found is if you specify your SCREEN_DEFAULT to be a shell screen, shell won't ctrl-alt-* to change vt
| |
| 16:40 | (which I think is a problem with how we drop into shell)
| |
| 16:41 | otherwise, I *was* getting consistent and reliable default screens
| |
| 16:41 | at least on Ubuntu
| |
| 16:41 | evidently, not so much on debian
| |
| 16:42 | <vagrantc> i haven't tried multiple ldm's or anything like that
| |
| 16:42 | pmatulis has joined #ltsp | |
| 16:42 | sbalneav has quit IRC | |
| 16:43 | <vagrantc> Gadi: well, i think everything works as you've described... except i can't actually switch to the vt's that didn't start out as default
| |
| 16:43 | so they're never able to start
| |
| 16:43 | <Gadi> vagrantc: not even if the defaul t is ldm?
| |
| 16:43 | <vagrantc> i haven't played with SCREEN_DEFAULT, but consistantly, the highest numbered screen is the one that gets switched to
| |
| 16:44 | <alkisg> console-setup uses tty[1-6] as the default, so if SCREEN_07=shell or higher are used, and they're not the default, we can't switch to them
| |
| 16:44 | <vagrantc> but then there's no vt to switch to get the other... weather shell or ldm is on the lower numbered tty
| |
| 16:45 | i could try disabling the getty's on tty 2-6 and see if i can get better results playing with lower numbered ttys ...
| |
| 16:45 | <Gadi> well, I dont quite understand what magic console-setup does
| |
| 16:46 | <alkisg> I think it just opens the vt
| |
| 16:47 | <Gadi> well, in theory, openvt opens the vts, too
| |
| 16:48 | but, evidently not enough to allow you to switch to them
| |
| 16:48 | <vagrantc> not if you're in an infinite while loop
| |
| 16:48 | <Gadi> where's the infinite loop?
| |
| 16:48 | <alkisg> In ltsp-core
| |
| 16:48 | <vagrantc> no
| |
| 16:49 | <Gadi> you mean the holding pattern?
| |
| 16:49 | <alkisg> Erm sorry
| |
| 16:49 | screen-session: while [ $(fgconsole) -ne ${SCREEN_NUM} ]; do
| |
| 16:49 | <vagrantc> screen_session: while [ $(fgconsole) -ne ${SCREEN_NUM} ]
| |
| 16:49 | <Gadi> but that loop should break when you switch to it
| |
| 16:49 | <vagrantc> but what if it's not initialized sufficiently to "switch" to
| |
| 16:50 | <Gadi> on the current screen, that loop is broken
| |
| 16:50 | on the target screen, that loop is active
| |
| 16:50 | <vagrantc> so, as a test, i disabled the getty's on tty2-6, configured ldm and shell to run screen scripts there, and i can switch to them.
| |
| 16:50 | some something about what alkisg was saying is right...
| |
| 16:51 | <Gadi> ohh....
| |
| 16:51 | actually, I think I tried something before I left to travel that worked
| |
| 16:51 | you guys are right
| |
| 16:51 | bec openvt does not kick in until after the loop
| |
| 16:51 | so, you need to run the loop in openvt
| |
| 16:51 | and I think that fixes it
| |
| 16:52 | ie: openvt ..... while.....
| |
| 16:52 | i think that worked
| |
| 16:53 | let me see if I can find exact syntax
| |
| 16:56 | <alkisg> Hmmm -w -s is the reason it always switches to rdesktop when it times out... :)
| |
| 16:57 | btw, how are & and wait different than not using & at all?
| |
| 17:00 | <vbundi> new lucid theme is nice... but I dunno about those mac style titlebar buttons..
| |
| 17:00 | <vagrantc> Gadi: i used openvt to execute /bin/true before the while loop ...
| |
| 17:00 | seems a little hackish, but works.
| |
| 17:01 | also has a 0-2 second delay starting the screen script
| |
| 17:01 | could potentially switch past it before the sleep times out
| |
| 17:01 | olitask has quit IRC | |
| 17:02 | <Gadi> vagrantc: right - I just didnt want to overrun the CPU
| |
| 17:02 | <vagrantc> how hard of a hit is fgconsole?
| |
| 17:02 | <Gadi> every second?
| |
| 17:03 | not sure
| |
| 17:03 | <vagrantc> as compared to every 2 seconds?
| |
| 17:03 | if it's really bad at every second, every two seconds probably isn't all that good either
| |
| 17:03 | <Gadi> agreed
| |
| 17:03 | ok, change it to every second
| |
| 17:03 | I guess I was being paranoid
| |
| 17:04 | <vagrantc> but it seems to be working... so basically, we can use openvt to "initialize" the console...
| |
| 17:04 | <Gadi> yeah
| |
| 17:04 | excellent
| |
| 17:04 | <alkisg> In my Lucid, I can switch to vt11. In a thin client, I can't. What's opening vt11 in a normal Lucid workstation?
| |
| 17:05 | <vagrantc> this does change apparently behavior... i routinely used SCREEN_07=ldm SCREEN_08=shell to test
| |
| 17:05 | <alkisg> Hmm openvt -c 11 /bin/true does the trick without wasting memory
| |
| 17:06 | <vagrantc> but... when it's been broken for so long, what can you do
| |
| 17:06 | <Gadi> vagrantc: so, set SCREEN_DEFAULT=7 in debian
| |
| 17:06 | :)
| |
| 17:06 | alkisg and I went back and forth over what the default screen should be if none spec'd - highest or lowest
| |
| 17:07 | * alkisg had 2 more votes so he won :P | |
| 17:07 | <Gadi> in the end, I think debian and Ubuntu should just drop in a SCREEN_DEFAULT=${SCREEN_DEFAULT:-7}
| |
| 17:07 | perhaps in ur ltsp_config.d/
| |
| 17:07 | :)
| |
| 17:07 | <vagrantc> i almost think we should just document the change
| |
| 17:08 | <alkisg> BTW, why do we set DISPLAY=:7 when normal workstations use DISPLAY=:0 ?
| |
| 17:08 | highvoltage has quit IRC | |
| 17:08 | <vagrantc> because hard-coding a default of 7, if not SCREEN_07 is specified... is wrong
| |
| 17:08 | alkisg: to keep track of multiple displays easier
| |
| 17:08 | <alkisg> Ah
| |
| 17:08 | <vagrantc> alkisg: you know DISPLAY=:7 is on tty7, DISPLAY=:8 is on tty8, etc.
| |
| 17:09 | <Gadi> vagrantc: [ -n "$SCREEN_07" ] && SCREEN_DEFAULT=${SCREEN_DEFAULT:-7}
| |
| 17:09 | <vagrantc> there was a time where it was actually tty-1
| |
| 17:09 | <alkisg> Ugh
| |
| 17:09 | <Gadi> (just do that after you specify SCREEN_07=ldm when none is set
| |
| 17:10 | ah, the good old days of running X on screen 1
| |
| 17:10 | where it makes the most sense
| |
| 17:10 | :)
| |
| 17:10 | (and where Gadi still likes to run it)
| |
| 17:10 | <vagrantc> er, tty$((N - 1))
| |
| 17:11 | <Gadi> anyhow, vagrantc: [ -n "$SCREEN_07" ] && SCREEN_DEFAULT=${SCREEN_DEFAULT:-7}
| |
| 17:11 | <vagrantc> Gadi: seems like, in the default case, it's running on 7 and 7 will be the highest, so why set it at all?
| |
| 17:11 | <Gadi> for all you folks who do SCREEN_07=ldm; SCREEN_08=shell
| |
| 17:11 | ;)
| |
| 17:11 | <vagrantc> i.e. if i manually specified SCREEN_07=shell and SCREEN_08=ldm, in the old way ldm still would have stolen the console
| |
| 17:12 | <Gadi> right - but who does that?
| |
| 17:12 | <vagrantc> it just seems like we can't replicate old behavior, so may as well just document the change
| |
| 17:12 | <Gadi> fair 'nuff
| |
| 17:12 | I just change things
| |
| 17:12 | :)
| |
| 17:12 | I leave it to you to bring sanity to the changes
| |
| 17:13 | but, I do really like not having a race condition anymore
| |
| 17:13 | ok, off to help the wifer... good weekend, guys
| |
| 17:14 | Gadi has left #ltsp | |
| 17:17 | * vagrantc watches gadi ride off into the sunset, assured the gadi will appear when needed in the next episode | |
| 17:19 | epequeno has joined #ltsp | |
| 17:22 | <vagrantc> ah, this is the fun game of openvt possibly being installed in different places depending on which distro or even packages are installed
| |
| 17:24 | and then the error messages about that...
| |
| 17:25 | highvoltage has joined #ltsp | |
| 17:30 | <alkisg> Why can't we just run openvt?!
| |
| 17:31 | There's no $PATH set?
| |
| 17:32 | <vagrantc> i do recall some debate about it way back when...
| |
| 17:37 | well, committed a patch to use openvt to initialize the console.
| |
| 17:39 | it's slightly sloppy, in that the error checking/logging for the presence of openvt should really happen sooner, but i just wanted a minimal change that should work.
| |
| 17:39 | <alkisg> vagrantc: /bin/openvt -f -c ${SCREEN_NUM#0} /bin/true
| |
| 17:39 | ==> $openvt -f -c ${SCREEN_NUM#0} /bin/true
| |
| 17:40 | <vagrantc> doh.
| |
| 17:41 | <alkisg> (and maybe -f isn't needed there...)
| |
| 17:41 | <vagrantc> maybe. but this worked. :)
| |
| 18:00 | bobby_C has quit IRC | |
| 18:10 | vagrantc has quit IRC | |
| 18:29 | epaphus has quit IRC | |
| 18:30 | alkisg has quit IRC | |
| 18:46 | nubae_ has joined #ltsp | |
| 18:46 | nubae has quit IRC | |
| 19:00 | nubae has joined #ltsp | |
| 19:26 | vagrantc has joined #ltsp | |
| 19:39 | mikkel has quit IRC | |
| 19:59 | jammcq has joined #ltsp | |
| 19:59 | <jammcq> hello my friends
| |
| 20:00 | * vagrantc waves | |
| 20:00 | <jammcq> hey vagrantc, how are you ?
| |
| 20:02 | <vagrantc> a little grounds for grumbling, but decent nevertheless :)
| |
| 20:02 | had to roll into work to on a day off to fix some networking problems
| |
| 20:02 | <jammcq> how's freegeek going?
| |
| 20:02 | we've got a "Motor city freegeek" now
| |
| 20:03 | <vagrantc> it's strong.
| |
| 20:03 | <jammcq> something that was started after I came back from portland and I had the DVD with me. I showed it at our lug, and there was someone who was VERY interested
| |
| 20:30 | vagrantc has quit IRC | |
| 20:57 | nubae has quit IRC | |
| 20:57 | nubae_ has quit IRC | |
| 21:09 | try2free has joined #ltsp | |
| 21:10 | rjune__ has quit IRC | |
| 21:10 | try2free has left #ltsp | |
| 21:19 | nubae has joined #ltsp | |
| 21:20 | nubae_ has joined #ltsp | |
| 21:20 | rjune__ has joined #ltsp | |
| 22:30 | pmatulis has quit IRC | |
| 23:28 | F-GT has quit IRC | |
| 23:39 | alkisg has joined #ltsp | |