IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 26 March 2010   (all times are UTC)

00:01F-GT has joined #ltsp
00:22japerry has quit IRC
00:22japerry_cat has joined #ltsp
00:38Egyptian[Home] has quit IRC
00:53Egyptian[Home] has joined #ltsp
00:57ogra_cmpc has quit IRC
00:59ogra_cmpc has joined #ltsp
01:15japerry_cat has quit IRC
01:15japerry has joined #ltsp
01:44pths has joined #ltsp
03:03pths has quit IRC
03:36Shingoshi has joined #ltsp
03:36Shingoshi has quit IRC
03:42Shingoshi has joined #ltsp
04:36try2free has joined #ltsp
04:37try2free has left #ltsp
04:45NeonLicht has joined #ltsp
06:08hersonls has joined #ltsp
06:23vmlintu has quit IRC
06:28Egyptian[Home] has quit IRC
06:32vmlintu has joined #ltsp
06:35pmatulis has joined #ltsp
06:48ogra has quit IRC
06:48ogra has joined #ltsp
07:20zirconiumks has joined #ltsp
07:22GodFather_ has joined #ltsp
07:30cliebow has joined #ltsp
07:39otavio has quit IRC
07:39otavio has joined #ltsp
07:41alkisg has quit IRC
08:24evilx_ has quit IRC
08:25slidesinger has joined #ltsp
08:26GodFather_ is now known as GodFather
08:33zirconiumks has quit IRC
08:48leio has joined #ltsp
08:58vvinet_ has joined #ltsp
09:36bobby_C has joined #ltsp
09:36mikkel has joined #ltsp
10:03nubae_ has joined #ltsp
10:04nubae has quit IRC
10:17staffencasa has joined #ltsp
10:35mgariepy has joined #ltsp
10:43Faithful has quit IRC
10:50klausade has joined #ltsp
10:58Faithful has joined #ltsp
10:58GodFather has quit IRC
11:05akuepker 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:17alkisg 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:35NeonLicht has quit IRC
11:35NeonLicht has joined #ltsp
11:40vagrantc has joined #ltsp
11:42Lns 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:49andrea has joined #ltsp
11:49andrea is now known as Guest69716
11:50shamael 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:16epaphus 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:18cliebow 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:49runout has joined #ltsp
12:49
<Lns>
think of it... android thin clients
12:49* vagrantc fights the robots
12:50
<Lns>
bbiab
12:50Lns 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:10johnny has left #ltsp
13:20ogra_cmpc has quit IRC
13:20
<stgraber>
vagrantc: ltsp-docs updated in ubuntu
13:24Lns has joined #ltsp
13:26shamael has quit IRC
13:29nubae has joined #ltsp
13:29nubae_ has quit IRC
13:30
<vagrantc>
stgraber: yeah, i saw ;)
13:32
<stgraber>
vagrantc: did you try 5.2.1 on Debian ?
13:32zirconiumks has joined #ltsp
13:33ogra_cmpc has joined #ltsp
13:34
<vagrantc>
stgraber: not yet... should do that today...
13:36vagrantc has quit IRC
13:37vagrantc has joined #ltsp
13:41ogra_cmpc has quit IRC
13:42ogra_cmpc has joined #ltsp
13:56
<alkisg>
Ah, `nomodeset` helps for TCs that hang in plymouth in Lucid...
13:56staffencasa 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:03nubae_ has joined #ltsp
14:03
<Lns>
ltsp isn't THAT bulky... ;)
14:04nubae 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:35litlebuda has joined #ltsp
14:38
<vagrantc>
right
14:38* vagrantc pushed for that for years
14:39litlebuda 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:52zirconiumks 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:59wwx has quit IRC
15:02
<vagrantc>
Lns: i hear ya.
15:04wwx has joined #ltsp
15:05pmatulis 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:23olitask 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:30akuepker 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:38vvinet 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:01Egyptian[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:05mgariepy has quit IRC
16:06
<vbundi>
vagrantc: I'
16:06nubae 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:07nubae_ 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:09hersonls has quit IRC
16:09runout 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:29Lns 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:36Gadi 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:42pmatulis has joined #ltsp
16:42sbalneav 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:01olitask 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:08highvoltage 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:14Gadi 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:19epequeno 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:25highvoltage 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:00bobby_C has quit IRC
18:10vagrantc has quit IRC
18:29epaphus has quit IRC
18:30alkisg has quit IRC
18:46nubae_ has joined #ltsp
18:46nubae has quit IRC
19:00nubae has joined #ltsp
19:26vagrantc has joined #ltsp
19:39mikkel has quit IRC
19:59jammcq 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:30vagrantc has quit IRC
20:57nubae has quit IRC
20:57nubae_ has quit IRC
21:09try2free has joined #ltsp
21:10rjune__ has quit IRC
21:10try2free has left #ltsp
21:19nubae has joined #ltsp
21:20nubae_ has joined #ltsp
21:20rjune__ has joined #ltsp
22:30pmatulis has quit IRC
23:28F-GT has quit IRC
23:39alkisg has joined #ltsp