00:18 | pmatulis has quit IRC | |
00:47 | nicoAMG has joined #ltsp | |
00:48 | alkisg1 has joined #ltsp | |
00:48 | alkisg has quit IRC | |
00:55 | alkisg1 has quit IRC | |
00:59 | vagrantc has joined #ltsp | |
01:03 | vagrantc has quit IRC | |
01:26 | alkisg has joined #ltsp | |
01:29 | hanthana_ has joined #ltsp | |
01:44 | hanthana has quit IRC | |
01:47 | phantom has joined #ltsp | |
01:47 | F-GT has quit IRC | |
02:35 | mede has joined #ltsp | |
02:35 | <mede> hello everyone
| |
02:35 | i have a question here
| |
02:36 | how to setup multiple server
| |
02:38 | <cyberorg> mede, search for ltsp cluster
| |
03:02 | ogra_ has quit IRC | |
03:02 | ogra has quit IRC | |
03:02 | ogra_ has joined #ltsp | |
03:03 | ogra has joined #ltsp | |
03:10 | <mede> tq cyberorg..
| |
03:10 | but i have nothing idea with that
| |
03:10 | nubae1 has quit IRC | |
03:11 | nubae has joined #ltsp | |
03:12 | <cyberorg> mede, what distro?
| |
03:52 | hanthana_ is now known as hanthana | |
04:19 | russell_nash has joined #ltsp | |
04:19 | russell_nash has left #ltsp | |
04:45 | <mede> edubuntu
| |
04:45 | cyberorg
| |
04:45 | ogra_ has quit IRC | |
04:46 | <cyberorg> mede, see documentation link in the /topic look for get_hosts
| |
04:47 | alkisg has quit IRC | |
04:48 | <mede> ok...thanks
| |
04:49 | i will try to explore it
| |
04:49 | mede has quit IRC | |
05:44 | Shingoshi_ has joined #ltsp | |
05:45 | Shingoshi has quit IRC | |
06:03 | ogra_ has joined #ltsp | |
06:30 | mikkel has joined #ltsp | |
06:39 | danil has joined #ltsp | |
06:40 | <danil> Hi folks. Can't get working ltsp client cause of wrong resolution on my Samsung 940n monitor and geForce 6100 video. Could you give me an advice?
| |
06:42 | tried # X_MODE_0 = "1280x1024" 108 1280 1328 1440 1688 1024 1025 1028 1066
| |
06:42 | X_MODE_0 = "1280x1024@60i" 49.50 1280 1312 1496 1528 1024 1047 1053 1077 interl
| |
06:42 | but no luck
| |
07:10 | <nubae> danil: did u set X_CONF=True
| |
07:21 | <danil> i tried different combinations
| |
07:23 | when i use it, and provide custom xorg.conf i get blinking message : xauth tryin new authority file /root/.Xautority
| |
07:23 | and x fail to start even i've added copy_dir "/root" in ltsp-client-config file
| |
07:26 | half way to success: i 've switched to console 2 at thin client , dpkg-reconfigure xserver-xorg, after have added HorizSync 31-75 , VertRefresh 60-75 into new xorg.conf returned to console 7 and ctrl+alt+backspace so xorg started fine
| |
07:27 | in gnome now i can switch to right resolution for this monitor (1280x1024)
| |
07:28 | but question is : How add this settings right in lts.conf ? should i use custom xorg.conf or pass this parammetrs via monitor options?
| |
07:29 | phantom has quit IRC | |
07:31 | phantom has joined #ltsp | |
07:39 | <nubae> danil: either or should work for you
| |
07:44 | alkisg has joined #ltsp | |
07:45 | <danil> ok it's work via custom xorg.conf but disadvatage is need always ltsp-update-image if i change xorg.conf in /opt/ltsp/....
| |
07:46 | could you provide right syntax X_MONITOR_OPTION_01 HorizSync = 31-75
| |
07:46 | i would like change it via /var/lib/tftboot/i386/lts.conf
| |
07:47 | googled but nothing found
| |
07:54 | <nubae> !docs
| |
07:54 | <ltspbot`> nubae: "docs" is For the most current documentation, see http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspDocumentationUpstream
| |
07:55 | <nubae> u should find it in there ^^^
| |
07:56 | danil has left #ltsp | |
08:08 | mistik1 has quit IRC | |
08:12 | mistik1 has joined #ltsp | |
08:29 | <zamba> how can i change the default language used for my image?
| |
08:31 | <alkisg> ltsp-build-client --extra-help|grep locale
| |
08:33 | <zamba> alkisg: what if i've already built the image?
| |
08:33 | <alkisg> distro/version?
| |
08:33 | <zamba> itnrepid
| |
08:33 | eh
| |
08:33 | intrepid*
| |
08:33 | that being ubuntu
| |
08:34 | <alkisg> zamba: `cat /opt/ltsp/i386/etc/environment` - does it have your LANG there?
| |
08:35 | <zamba> nope
| |
08:35 | <alkisg> *sorry, I mean *any* LANG there?
| |
08:35 | (e.g. english)
| |
08:35 | <zamba> nope
| |
08:35 | nothing there
| |
08:35 | <alkisg> Nothing? not even the path?
| |
08:35 | Maybe you've build an amd64 chroot?
| |
08:36 | <zamba> nope.. it's i386
| |
08:36 | <alkisg> And the file exists and has nothing in there, or it doesn't exist at all?
| |
08:36 | <zamba> but i believe if the standard is used, then nothing is defined in /etc/environment
| |
08:37 | sure, the file's there
| |
08:38 | <alkisg> zamba: and this one? cat /opt/ltsp/i386/etc/default/locale
| |
08:38 | <zamba> haven't got that
| |
08:38 | <alkisg> Erm... what does /etc/environment have?
| |
08:38 | <zamba> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
| |
08:39 | <alkisg> I see - out of curiosity, what language did you install in? English?
| |
08:39 | <zamba> yeah
| |
08:42 | <alkisg> zamba: well, in jaunty the LANG goes in /opt/ltsp/i386/etc/environment - but it just get copied from /etc/environment
| |
09:03 | vvinet has joined #ltsp | |
09:14 | alkisg has quit IRC | |
09:20 | alkisg has joined #ltsp | |
10:00 | litlebuda has joined #ltsp | |
10:09 | yoshi has joined #ltsp | |
10:09 | yoshi is now known as Guest30963 | |
11:10 | nubae1 has joined #ltsp | |
11:12 | nubae has quit IRC | |
11:15 | alkisg has quit IRC | |
11:17 | vagrantc has joined #ltsp | |
11:19 | litlebuda has quit IRC | |
11:20 | litlebuda has joined #ltsp | |
11:24 | <zamba> is it possible to get my thin clients to authenticate against a central ldap server?
| |
11:24 | individually, that is
| |
11:24 | instead of going through the ltsp server
| |
11:25 | <vagrantc> of course it's possible. do you want to know if it's easy?
| |
11:25 | <zamba> yeah :)
| |
11:25 | point is.. i've set up my fat clients to authenticate against a central server and also map up the /home from the same server
| |
11:25 | and i want to have the identical setup for my thin clients as well
| |
11:26 | i see that /etc/fstab gets modified when booting the thin client?
| |
11:26 | <vagrantc> then set up your ltsp server to authenticate via ldap
| |
11:26 | <zamba> well.. i can get it working when logging in on the console
| |
11:26 | but not gdm
| |
11:26 | <vagrantc> how about ssh?
| |
11:27 | <zamba> works too
| |
11:27 | <vagrantc> !release
| |
11:27 | <ltspbot`> vagrantc: "release" is please mention the linux distro and release you're using :)
| |
11:27 | <zamba> what's the cow directory on /?
| |
11:28 | * vagrantc wonders what version zamba is running | |
11:28 | <zamba> intrepid
| |
11:29 | <vagrantc> zamba: so, unless you've explicitly configured it to use XDMCP, it will use LDM by default, which logs in via ssh.
| |
11:29 | zamba: so you need to configure ssh to authenticate via ldap.
| |
11:30 | gdm doesn't come into the picture.
| |
11:30 | <zamba> ssh authenticates using ldap
| |
11:30 | i've just confirmed it
| |
11:30 | and the thin client uses its own connection to the ldap server, without going through the ltsp server
| |
11:31 | <vagrantc> i thought you said you wanted your thin clients to behave like the fat clients you already had working?
| |
11:31 | <zamba> yeah
| |
11:31 | meaning they should authenticate to the ldap themselves, instead of going through the ltsp server
| |
11:32 | <vagrantc> the thin clients don't do any authentication.
| |
11:32 | <zamba> hm..
| |
11:32 | why can i log in directly to the thin client using ssh then?
| |
11:32 | <vagrantc> the thin clients provide a login screen, that logs into the server via ssh. so all authentication happens on the server.
| |
11:32 | <zamba> aha
| |
11:32 | got it
| |
11:33 | <vagrantc> 99% of the time, if you want to do something, you do it on the server.
| |
11:33 | installing packages, authentication, whatever. all happens on the server. NOT the thin client.
| |
11:33 | <zamba> the same goes for the mounting of the home directory?
| |
11:33 | <vagrantc> yes.
| |
11:35 | <zamba> this is a bit confusing :)
| |
11:35 | but i'll try
| |
11:35 | i thought everything happened in the chroot?
| |
11:35 | let's say i want to mount a /data directory that should be accessible for the thin clients?
| |
11:36 | do i mount it into the chroot or in the global /data directory?
| |
11:36 | will mounting it in the chroot even work?
| |
11:36 | then i'm thinking like: mount -t cifs //server/share /opt/ltsp/i386/data/
| |
11:37 | my first thought was to set up the mount in /opt/ltsp/i386/etc/fstab, but that won't work?
| |
11:37 | alkisg has joined #ltsp | |
11:38 | <vagrantc> zamba: do you want it accessible to the user who logs in from the thin client, or the server?
| |
11:38 | <zamba> the user who logs in from the thin client
| |
11:38 | the same goes with the home directory as well
| |
11:38 | <vagrantc> the user is logged in to the server, so it needs to be mounted on the server.
| |
11:38 | 99% of the time...
| |
11:38 | <zamba> but why setting up stuff in the chroot? i don't get that part of it :)
| |
11:38 | litlebuda has quit IRC | |
11:39 | <vagrantc> zamba: i guess you know better than i, i will stop annoying you now.
| |
11:39 | <zamba> if i want to install a new package, let's say openoffice, why do i first have to chroot into /opt/ltsp/i386 and then install it?
| |
11:39 | vagrantc: huh?
| |
11:39 | <vagrantc> zamba: because you're doing it wrong?
| |
11:39 | litlebuda has joined #ltsp | |
11:39 | <zamba> vagrantc: i'm confused, that's all.. i don't mean to be sarcastic or anything.. i just want to understand fully how this works
| |
11:40 | if i'm bothering you with my questions, feel free to just ignore them..
| |
11:40 | <vagrantc> zamba: i don't know how else to say it. NEARLY EVERYTHING happens on the server.
| |
11:40 | zamba: installation of packages, authentication, running processes, etc. all happens on the server.
| |
11:40 | <zamba> yeah, but i'm having problems differentiating between what happens in the chroot of the thin client and "globally" on the server
| |
11:41 | <cyberorg> zamba, simply put, don't mess with chroot ever unless you know what you are doing :)
| |
11:41 | hi vagrantc
| |
11:41 | <vagrantc> cyberorg: thank you!
| |
11:42 | <zamba> but chrooting is a way of installing packages that you only want accessible for the thin clients? like if you don't want the same package installed on the ltsp server?
| |
11:42 | (this is for the sake of discussion)
| |
11:42 | <vagrantc> zamba: no.
| |
11:42 | <zamba> http://www.ltsp.org/twiki/bin/view/Ltsp/MueKow
| |
11:43 | i'm reading under "A New Approach"
| |
11:43 | For example, If you want to install firefox into an LTSP tree on a Debian system, you'd run the following commands:
| |
11:43 | phantom has quit IRC | |
11:43 | <zamba> chroot /opt/ltsp/i386
| |
11:43 | apt-get install mozilla-firefox
| |
11:43 | <vagrantc> zamba: think of the thin client as an extra keyboard, mouse and monitor for your server. you wouldn't install packages on your keyboard, would you?
| |
11:43 | zamba: that's the 1%
| |
11:43 | <zamba> vagrantc: that's installing packages, isn't it?
| |
11:43 | which i'm doing and want to be doing
| |
11:43 | <vagrantc> zamba: that's talking about localapps.
| |
11:44 | <zamba> basically applications that consume CPU at the client versus the server, right?
| |
11:44 | <vagrantc> zamba: that's one distinction, yes.
| |
11:45 | <zamba> and it will also make the footprint of the image larger and more complex, right?
| |
11:45 | <vagrantc> zamba: for a genuine thin client, EVERYTHING is on the server. for a fat client, the server just provides disk. for LOCAL_APPS, you do a little of both.
| |
11:45 | <zamba> ah, ok
| |
11:45 | then i'm starting to get the idea here, i think
| |
11:45 | <vagrantc> zamba: first, understand what a regular thin client works, then start playing with other stuff.
| |
11:45 | phantom has joined #ltsp | |
11:46 | <vagrantc> zamba: burn that distinction into your brain.
| |
11:46 | <zamba> yeah
| |
11:46 | hanthana has quit IRC | |
11:46 | <zamba> i think i should just wipe the image i've created ;)
| |
11:46 | i've been installing quite a few packages chrooted :)
| |
11:47 | <alkisg> zamba, the LTSP docs describe pretty nicely what a thin client is: http://www.ltsp.org/~sbalneav/LTSPManual.html#id2518323
| |
11:47 | <zamba> another distinction would mean that i don't have to rebuild the image every time packages are being upgraded, right?
| |
11:48 | alkisg: ok, thanks, i'll read through it
| |
11:48 | hanthana has joined #ltsp | |
11:48 | <alkisg> zamba: e.g. to answer your last question: "All the regular maintenance (software updates, administration) takes place on the server."
| |
11:49 | <cyberorg> vagrantc, happy news is we finally managed to get sound with xrdp without writing to any file
| |
11:51 | it will still break on resume, we'll try to figure out setting pa server on resume
| |
11:51 | <vagrantc> cyberorg: ah, cool!
| |
11:51 | <cyberorg> xrdp requires patching
| |
12:08 | <vagrantc> stgraber: did the ltspfs local mounting work for you with jaunty? both the mounts as root as well as per-user mounts?
| |
12:20 | <stgraber> vagrantc: per-user I'm not sure, these as root I'm using in production (for rdesktop)
| |
12:20 | japerry has joined #ltsp | |
12:21 | <stgraber> cyberorg: are these changes to rdesktop/xrdp done upstream or is it OpenSUSE specific ?
| |
12:21 | <vagrantc> stgraber: gadi had added a couple commits after the upstream version in jaunty, didn't know if they made it in as patches.
| |
12:21 | <cyberorg> stgraber, at the moment they are only in a test machine :)
| |
12:21 | * vagrantc has heard xrdp upstream has been a little stubborn with regard to patches | |
12:22 | <cyberorg> vagrantc, last time i checked xrdp-devel mailing list had disappeared
| |
12:22 | <stgraber> vagrantc: nope, we don't have these two commits but haven't heard of issues without them though (probably because I didn't advertise that it should be working per-user)
| |
12:22 | <vagrantc> dead upstream!
| |
12:23 | stgraber: heh :)
| |
12:23 | stgraber: congrats on the release, by the way!
| |
12:23 | <stgraber> vagrantc: thanks. Working on the feature list for the next one now :) Will send that to ltsp-dev soon so everyone knows what I'll break in the next 6 months ;)
| |
12:24 | <vagrantc> heh :)
| |
12:24 | <stgraber> my main goal is integrating "ltsp-remoteapp" :)
| |
12:24 | it's a small script I'm working on basically doing the oposite of ltsp-localapp
| |
12:24 | so a localapp can start a software on the server
| |
12:24 | <vagrantc> heh
| |
12:24 | we're going crazy!
| |
12:25 | and we're not going to stop!
| |
12:25 | <cyberorg> stgraber, seamless rdesktop?
| |
12:25 | <stgraber> especially looking after that for firefox, basically all mimetypes would be sent to that script, it'll then copy the file if it's not accesible from the server and then start the application with xdg-open on the server.
| |
12:25 | for now it works perfectly with firefox and openoffice :) you click on a .odt on google and you get ooo starting on the server with your file.
| |
12:26 | <vagrantc> nice!
| |
12:26 | <stgraber> (but the script is really ugly and I don't have the mimetype integration yet)
| |
12:26 | <cyberorg> yup, great idea!
| |
12:26 | <vagrantc> seamless localremotelocalremoteapps!
| |
12:26 | <stgraber> cyberorg: I guess it'll depend if that's upstream or not :)
| |
12:27 | I can do without having to maintain patches on xrdp and rdesktop and having it upstream means that debian will do the work and I'll just have to sync :) (well, depends on how active is the maintainer in Debian for these two)
| |
12:28 | <vagrantc> ANYWHERE_APPS=True
| |
12:28 | <cyberorg> stgraber, sorry, didn't quite get you there, this work is using xrdp?
| |
12:28 | xrdp can't do localapps
| |
12:29 | <vagrantc> not yet!
| |
12:29 | <stgraber> cyberorg: nope, was talking of your RDP stuff :) it's somewhere on my list too but waiting on upstream inclusion before working on it.
| |
12:30 | and yeah, usually the issue with RDP is that it's a fullscreen app so won't work with localapps
| |
12:30 | I have the same issue with some NX deployments we're planning, you can't mix that with localapps and so limit it for very slow thin clients that can't do localapps.
| |
12:31 | <cyberorg> vagrantc, if it really works on xrdp, that is probably a way to go for ltsp default, but xrdp upstream is non-existent :(
| |
12:31 | we have local dev and sound working, only thing missing is localapps
| |
12:32 | stgraber, not just being a full screen app, the X server is actually running on the server, so whatever xprop we set stays over there
| |
12:32 | <ogra_> according to SF the xrdp code was last updated on jul 18 2008
| |
12:32 | doesnt seem to dead to me
| |
12:33 | <cyberorg> ogra_, right only few months left till one year :)
| |
12:36 | <ogra_> last commit 5 days ago actually on http://xrdp.cvs.sourceforge.net/viewvc/xrdp/xrdp/
| |
12:38 | <cyberorg> hmm, ML is back up again too
| |
12:40 | vagrantc has quit IRC | |
12:42 | <alkisg> Is this of any interest to LTSP? http://usbip.sourceforge.net/
| |
12:42 | <cyberorg> here is novell's changes http://sourceforge.net/mailarchive/forum.php?thread_name=1225400989.21992.83.camel%40opensuse-gnome.nomad&forum_name=xrdp-devel
| |
12:42 | <ogra_> alkisg, ancient
| |
12:43 | <alkisg> Meaning? obsolete, or that everyone already knows about it?
| |
12:43 | <cyberorg> alkisg, see ltsp-discuss/developers ML i sent instructions for how to test
| |
12:43 | <ogra_> i reviewed it yars ago when we looked for localdevice support
| |
12:43 | <alkisg> ogra_, so it isn't suited for LTSP environments?
| |
12:43 | cyberorg: looking...
| |
12:44 | <ogra_> alkisg, no idea what happened since then ... we decided for improving ltspfs for ltsp5 back then
| |
12:44 | <cyberorg> alkisg, no
| |
12:44 | it makes all usb ports unusable on the server
| |
12:44 | <ogra_> might have changed or improved
| |
12:44 | <cyberorg> some bug
| |
12:44 | <alkisg> cyberorg: you mean the local (server's) usb ports?
| |
12:44 | Guest30963 has quit IRC | |
12:44 | <ogra_> but iirc there were very intrusive kernel patches involved
| |
12:45 | <cyberorg> ogra_, it is part of the kernel now
| |
12:45 | <alkisg> Ah, I thought it was a clean module... with no patches involved
| |
12:45 | <ogra_> ah
| |
12:45 | it wasnt in 2005/6
| |
12:45 | <cyberorg> alkisg, no patches now :)
| |
12:45 | <alkisg> Right. Well, it sounded too good to be true :)
| |
12:45 | <ogra_> it was quite hackish once and not very secure
| |
12:46 | but as i said, its years ago that i looked
| |
12:46 | <alkisg> If it could work on a per user basis, and over the ssh tunnel...
| |
12:46 | <ogra_> and i personally wouldnt vote for replacinf ltspfs :)
| |
12:47 | <alkisg> ogra_, it would make things more clean - e.g. ntfs formatted sticks, cameras...
| |
12:47 | locale settings...
| |
12:47 | <ogra_> ntfs sticks work, cameras do ....
| |
12:47 | <cyberorg> ogra_, not secure at all, as there is no authentication mechanism
| |
12:47 | <ogra_> not sure what you mean
| |
12:48 | at least in ubuntu
| |
12:48 | if they dont its a bug
| |
12:49 | <cyberorg> ogra_, usbip does not have authentication
| |
12:49 | <ogra_> yes, you would need to hack it
| |
12:49 | <cyberorg> ogra_, oh, you meant cameras, they work on ltsp?
| |
12:50 | <ogra_> well, in disk mode in any case ... for ptp mode i think vagrant started some work
| |
12:50 | i did all my ltspfs development i ever did with one single usb key and my casio camera
| |
12:50 | would surprise me if it wouldnt work anymore
| |
12:51 | and for the ptp mode gphoto cams vagrant has an ltspfs branch somewhere ... we should merge that :)
| |
12:52 | <cyberorg> alkisg, some scripts for usbip http://groups.google.com/group/proj-uron/browse_thread/thread/a8c34aeb5f58113d#
| |
12:52 | ogra_, camera for video/webcams, not as storage device, that would work?
| |
12:53 | <ogra_> ah, well, no
| |
12:53 | but thats one of the usecases we started localapps for
| |
12:54 | better to have the cam app running locally than saturate the network with even more data tranfers
| |
12:54 | <stgraber> yeah, I've skype deployed as localapp in some schools, work just fine :)
| |
12:54 | <cyberorg> ogra_, thats what i thought :)
| |
12:54 | <ogra_> even with compression you have the same prob aqs in the other direction
| |
12:58 | <alkisg> cyberorg: thanks, I get the feeling that it would work on a per user basis (usbipd -D)... but also that security would be a problem... :(
| |
12:59 | <cyberorg> alkisg, once it is exported, anyone can connected to the usb device from anywhere in the network :)
| |
12:59 | <alkisg> There's an option to ""4> Export the device to 'host'"
| |
13:00 | ...meaning a specific host, but still, traffic won't be encrypted
| |
13:00 | <cyberorg> alkisg, with ltsp server everyone is on the same host = server :)
| |
13:01 | <nubae1> heh
| |
13:01 | funny how the server - client thing still trips up even the most hardened users ;-)
| |
13:01 | <alkisg> That could be arranged by asking for the same username somewhere in the code, but it would mean one more patch...
| |
13:03 | If it supported encrypted traffic, then it wouldn't even need to check for a username.
| |
13:04 | But I guess tcp is out of the question due to latency, so it would be like reimplementing ssh :P
| |
13:05 | <cyberorg> nubae1, sync up the latest -unstable iso, it has nomad working again
| |
13:06 | <nubae1> ok
| |
13:07 | nubae1 is now known as Nubae | |
13:19 | vagrantc has joined #ltsp | |
13:29 | nicoAMG has joined #ltsp | |
13:42 | yoshi has joined #ltsp | |
13:43 | yoshi is now known as Guest68446 | |
13:54 | bobby_C has joined #ltsp | |
14:01 | Shingoshi_ has quit IRC | |
14:07 | vvinet has quit IRC | |
14:16 | Egyptian[Home] has quit IRC | |
14:17 | Egyptian[Home] has joined #ltsp | |
14:24 | japerry_cat has joined #ltsp | |
14:40 | nicoAMG has joined #ltsp | |
14:40 | japerry has quit IRC | |
14:40 | cinch_ has quit IRC | |
15:02 | rjune_ has quit IRC | |
15:04 | alkisg has quit IRC | |
15:07 | rjune_ has joined #ltsp | |
15:33 | lucascoala has joined #ltsp | |
15:42 | nicoAMG has quit IRC | |
15:49 | bobby_C has quit IRC | |
15:56 | vagrantc has quit IRC | |
15:58 | vagrantc has joined #ltsp | |
16:03 | nicoAMG has joined #ltsp | |
16:10 | vagrantc has quit IRC | |
16:11 | vagrantc has joined #ltsp | |
16:59 | litlebuda has quit IRC | |
17:01 | japerry_cat has quit IRC | |
17:03 | litlebuda has joined #ltsp | |
17:21 | GodFather has joined #ltsp | |
17:26 | din_os has joined #ltsp | |
17:31 | mikkel has quit IRC | |
17:32 | din_os has left #ltsp | |
17:32 | <zamba> i have a question which i believe may fall into the 1% that you actually have to do in the chroot of the thin client.. when logging on the thin clients i need to use unionfs to mount a rw "layer" on top of a given user's home directory..
| |
17:33 | this is because all users share the same username when logging on and to prevent changes made by one user being replicated to the other users
| |
17:33 | litlebuda has quit IRC | |
17:34 | <zamba> i use pam.d to automatically mount the unionfs whenever a user logs on
| |
17:34 | the libpam-mount package in debian
| |
17:35 | if this is done on the server then the mount will in all practice be a permanent mount
| |
17:35 | and only related to the server instance and then all thin clients
| |
17:35 | if it's done on the thin clients, then it's only available on the different ones
| |
17:36 | <vagrantc> why not just use separate users for each login?
| |
17:37 | <zamba> simplicity
| |
17:37 | this is for a school with students aged 7 to 14
| |
17:38 | <vagrantc> you're not gaining any simplicity by setting up a dynamically mounted unionfs layer just to use the same user for all logins.
| |
17:38 | <zamba> it works perfectly for the fat clients
| |
17:39 | and it's also very important that all students see exactly the same desktop
| |
17:39 | for the learning environment
| |
17:40 | it's like communism :)
| |
17:43 | but my question is still.. this would probably fall into the 1% category?
| |
17:47 | <vagrantc> pam happens server side, so libpam-mount will probably not work well for what you're trying to do.
| |
17:48 | <zamba> hm
| |
17:48 | what would be the solution for my problem then?
| |
17:52 | <vagrantc> if you're clever enough to do crazy things with unionfs mounts at login, surely you can figure it out.
| |
17:52 | <zamba> i'm trying to figure out what exactly i did in my enqueries to personally insult you, but i've yet to find any valid reason..
| |
17:52 | <vagrantc> stgraber: i'm messing around with jaunty's LTSP ... i'm getting a squashfs error at boot, and /etc/resolv.conf on the thin clients is broken...
| |
17:53 | <zamba> vagrantc: i'm sorry i've wasted your precious time with my questions.. the next time just do me the favour of ignoring them
| |
17:53 | do us both the favour, that is
| |
17:58 | <vagrantc> zamba: well, most people are receptive to help, and you seemed insistant on ignoring it earlier. so i'll endeavor to be helpful, but i don't appreciate people wasting my time.
| |
17:58 | <stgraber> vagrantc: squashfs or nbd error ?
| |
17:59 | <vagrantc> stgraber: squashfs errors
| |
17:59 | <stgraber> vagrantc: how broken is your resolv.conf ? I was reported that when using lts.conf to change your DNS server the resolv.conf may be 000 and so be broken, other than that no issue were reported
| |
17:59 | <zamba> vagrantc: in what way am i ignoring your help?
| |
17:59 | <stgraber> hmm, did you try to rebuild your squashfs image then ? maybe something went wrong at build time
| |
18:01 | <vagrantc> stgraber: i'm about to. the really weird thing is it works with a virtualbox thin client
| |
18:01 | <stgraber> hmm, indeed that's really weird
| |
18:01 | <vagrantc> zamba: just when i repeatedly said everything happens on the thin client, and you still kept asking about things i mentioned explicitly that happen on the server.
| |
18:01 | stgraber: i'll try and re-build the image.
| |
18:02 | <zamba> vagrantc: when? earlier today? i told you i had a confusion about it and i needed some more examples on it.. i'm sorry that i don't just intuitively swallow knowledge like you do
| |
18:02 | yanqui has quit IRC | |
18:04 | <vagrantc> zamba: i'm sorry if i seemed short with you, i tried to help when i was busy with other things, and it was frankly unclear to me how you could have miscontrued a few things.
| |
18:06 | but it happens, and my apologies.
| |
18:08 | stgraber: the SQUASHFS error seems to happen between the first "Negotiation" right after "Setting up LTSP client" and the second "Negotiation" message
| |
18:08 | <zamba> ok, and i have to apologize for english not being my first language, so i often need a little more help than the "native speaker" :)
| |
18:08 | <vagrantc> though it also happens on the one that works as well.
| |
18:08 | vvinet has joined #ltsp | |
18:09 | MikeMc has joined #ltsp | |
18:09 | <stgraber> vagrantc: really weird, there was a race condition during the NBD reconnect but that was fixed. Usually all you should see is a read error then the nbd reconnection ...
| |
18:10 | <vagrantc> stgraber: if i don't set DNS_SERVER and SEARCH_DOMAIN the file ends up being unreadable ...
| |
18:11 | <stgraber> and what does it look like in /opt/ltsp/i386/etc/resolv.conf ?
| |
18:11 | <vagrantc> stgraber: "cat /etc/resolv.conf" results in "cat: /etc/resolv.conf: Input/Output Error" until i "touch /etc/resolv.conf"
| |
18:12 | stgraber: /opt/ltsp/i386/etc/resolv.conf is a normal file with your typical contents
| |
18:12 | stgraber: i even manually mounted the squashfs image, and it looks the same...
| |
18:13 | i'm going to try and rebuild the image and see what happens
| |
18:16 | <stgraber> so when mounting the squashfs image on the server without nbd you get the same input/output error ?
| |
18:16 | <vagrantc> stgraber: no, then it works fine :) just to make it really confusing.
| |
18:19 | <stgraber> I did a few test here and can't reproduce it ... looks like some kind of race condition at boot time. What is your thin client like ? fast/slow ?
| |
18:20 | BugsBunnyBR has joined #ltsp | |
18:22 | <vagrantc> stgraber: 1.2GHz, 512MB ram for the real thin clients ... my virtualbox thin client is running on a 1.2GHz laptop, with 64MB of ram...
| |
18:24 | <stgraber> hmm, ok, so if that's a race condition it's really weird I haven't seen it yet. Most of my users at the office are either on Atom 1.6 Ghz with 1GB of RAM or Via 1.0Ghz with 512MB of RAM ...
| |
18:25 | <vagrantc> stgraber: you do the disconnect/reconnect nbd thing to prevent what?
| |
18:26 | <stgraber> that's to reload nbd in persistent mode
| |
18:26 | because even if you start it with -persist from the initrd it won't work
| |
18:26 | the way it works on disconnect is that the nbd process disappears and is then respawned from its previous location in our case from the initrd that's no longer loaded
| |
18:26 | <vagrantc> i'll see if disabling that at least makes this other behavior go away...
| |
18:27 | <stgraber> you should be able to disable that by commenting the configure_nbd part of the init script
| |
18:27 | <vagrantc> and re-rolling the NBD image ...
| |
18:29 | japerry has joined #ltsp | |
18:29 | dark4og has joined #ltsp | |
18:34 | <vagrantc> stgraber: that fixed it!
| |
18:34 | stgraber: by breaking persistance ... how bad is that?
| |
18:36 | <stgraber> well, if for whatever reasons your inetd on the server crash you will find yourself without a working root filesystem
| |
18:37 | though I don't really understand why it's happening, the code was improved to avoid that kind of race condition by reconnecting the nbd as soon as possible
| |
18:38 | the only better way of fixing that that I could think of was to change nbd to handle the reconnection properly, either in the kernel or in the user-space binary
| |
18:38 | for now it looks like when the connection is lost the kernel module is respawning nbd-client so it can reconnect the nbd and that's just not working with the way the initramfs works ...
| |
18:43 | <BugsBunnyBR> someone here is having problems to do the terminal find tftp server in LTSP 5.0 on ubuntu 9.04?
| |
18:44 | the terminal find the right ip on the server..but can't charge the kernel file
| |
18:45 | the terminal get's time out
| |
18:59 | BugsBunnyBR has quit IRC | |
19:04 | dark4og has quit IRC | |
19:05 | MikeMc has quit IRC | |
19:06 | hanthana has quit IRC | |
19:10 | nubae1 has joined #ltsp | |
19:11 | Nubae has quit IRC | |
19:18 | nicoAMG has quit IRC | |
19:31 | <zamba> vagrantc: concerning my issue earlier.. do you have some suggestions to how i can solve it? i'm afraid i need to keep the single user, but maybe i can export the file system in a different way..?
| |
19:32 | <vagrantc> i've actually got to run right this second... will talk more later
| |
19:32 | vagrantc has quit IRC | |
19:37 | japerry has quit IRC | |
19:56 | <slashdotfx> oops, I've just upgrade ltsp chroot to 2.6.29 kernel
| |
19:56 | it say "squashfs error major/minor mismatch"
| |
19:57 | mksquashfs is not backward compatible
| |
20:00 | vvinet has quit IRC | |
20:06 | Faithful has joined #ltsp | |
20:19 | try2free has joined #ltsp | |
20:21 | <slashdotfx> try to upgrade to squashfs4 didn't work either
| |
20:30 | try2free has left #ltsp | |
20:39 | GodFather has quit IRC | |
20:40 | vvinet has joined #ltsp | |
20:55 | <slashdotfx> i see that squashfs4 need to support lzma, the author didn't work on it yet
| |
20:55 | since lzma afaik, isn't integrated into the current kernel
| |
20:59 | lucascoala has quit IRC | |
21:21 | dark4og has joined #ltsp | |
21:22 | dark4og has quit IRC | |
21:22 | dark4og has joined #ltsp | |
21:30 | vvinet has quit IRC | |
21:31 | try2free has joined #ltsp | |
21:36 | try2free has left #ltsp | |
22:40 | dark4og has quit IRC | |
22:56 | alkisg has joined #ltsp | |
23:00 | japerry has joined #ltsp | |
23:04 | aminus has joined #ltsp | |
23:04 | <aminus> hi im having trouble
| |
23:04 | booting a dell gx1
| |
23:39 | yoshi has joined #ltsp | |
23:39 | yoshi is now known as Guest68355 | |
23:47 | Guest68446 has quit IRC | |