00:05 | tarbo has joined #ltsp | |
00:12 | tarbo has quit IRC | |
00:13 | shogunx has joined #ltsp | |
00:15 | shamino has quit IRC | |
00:18 | arevamp has quit IRC | |
00:25 | artista_frustrad has joined #ltsp | |
00:30 | Sarten-X has quit IRC | |
00:31 | Sarten-X has joined #ltsp | |
00:32 | artista_frustrad has quit IRC | |
00:46 | vagrantc has joined #ltsp | |
00:51 | tarbo has joined #ltsp | |
00:56 | * vagrantc looks for gadi | |
01:00 | tarbo has quit IRC | |
01:00 | <panthera> vagrantc: congratulations, btw ;)
| |
01:00 | <vagrantc> panthera: thanks :)
| |
01:11 | tarbo has joined #ltsp | |
01:14 | alkisg has quit IRC | |
01:15 | alkisg has joined #ltsp | |
01:18 | tarbo has quit IRC | |
01:31 | tarbo has joined #ltsp | |
01:37 | tarbo has quit IRC | |
01:49 | Kicer86 has joined #ltsp | |
01:51 | tarbo has joined #ltsp | |
01:58 | tarbo has quit IRC | |
02:03 | alkisg has quit IRC | |
02:04 | alkisg has joined #ltsp | |
02:19 | vagrantc has quit IRC | |
02:47 | sene has quit IRC | |
02:51 | lucascoala has quit IRC | |
02:55 | mikkel has joined #ltsp | |
02:57 | artista_frustrad has joined #ltsp | |
02:58 | ogra has quit IRC | |
03:01 | gnunux has joined #ltsp | |
03:02 | artista_frustrad has quit IRC | |
03:14 | artista_frustrad has joined #ltsp | |
03:19 | artista_frustrad has quit IRC | |
03:41 | lucascoala has joined #ltsp | |
03:42 | waranha has joined #ltsp | |
03:42 | klausade has joined #ltsp | |
03:47 | waranha has quit IRC | |
03:50 | ball has joined #ltsp | |
03:51 | LumberCartel has joined #ltsp | |
03:51 | <LumberCartel> Hello folks. In NetBSD, ball has been telling me about this product.
| |
03:52 | I'm wondering, is there a Windows-client (similar to the VNC Viewer which is used for RFB)?
| |
03:52 | Thanks in advance.
| |
03:52 | s/NetBSD/#NetBSD/
| |
03:53 | <ball> hello LumberCartel
| |
03:55 | sepski is now known as sep | |
03:55 | <LumberCartel> Hello ball.
| |
03:55 | <sep> there are many rfb/vnc clients for windows, tightvnc ultravnc realvnc
| |
03:55 | <LumberCartel> sep: Correct.
| |
03:55 | <cyberorg> LumberCartel, rdesktop?
| |
03:56 | <LumberCartel> Have a link?
| |
03:56 | Is "rdesktop" what you folks use for your clients? I thought it was X.
| |
03:56 | <sep> rdesktop is a rdp client tho.
| |
03:56 | LumberCartel, i thought you asked about rfb..
| |
03:56 | <LumberCartel> Oh, RDP. Doesn't Microsoft own patents on that?
| |
03:56 | <sep> any X server will do. like Xming.
| |
03:56 | <LumberCartel> sep: No. I used RFB as a comparison to try to clarify my question.
| |
03:56 | <sep> sorry.
| |
03:56 | <- confused
| |
03:56 | <LumberCartel> sep: I was asking if there is a windows-version of the thin-client for LTSP.
| |
03:57 | sep: Sorry about that.
| |
03:57 | <sep> LumberCartel, for windows access i use x2go. since i feel that's easier then xming+putty+scripts
| |
03:57 | but then you need a x2go server as well ofcourse.
| |
03:57 | <LumberCartel> sep: I'm looking for a one-application solution that doesn't require a whole bunch of other stuff to be installed.
| |
03:57 | Perhaps I've misunderstood the purpose of LTSP.
| |
03:57 | <sep> and since ltsp is about network booting a client. you can take your windows machine. reboote it and pick pxe in your bios boot meny. and have it be a ltsp client
| |
03:58 | * LumberCartel glances at ball. | |
03:58 | <LumberCartel> sep: Hmm. It looks like I've misunderstoon what LTSP is. Heheh.
| |
03:58 | <ball> LumberCartel: I think you've misunderstood what LTSP does.
| |
03:58 | ;-)
| |
03:59 | <sep> ltsp is a system where you network boot machines and make them a X terminal. if you allready booted windows.. you dont need to boot with ltsp. and you can use whatever X method you like to get your X desktop and applications. Xming, freenx x2go
| |
03:59 | or run rdp server on linux and use remote desktop connection on windows
| |
03:59 | or vnc server and any vnc client on windows
| |
04:00 | <LumberCartel> ball: It has become clear to me that I have misunderstood what LTSP is.
| |
04:00 | * ball nods | |
04:00 | <LumberCartel> sep: Okay, so LTSP focuses on network booting an OS, so that workstations don't need hard disks?
| |
04:00 | <ball> LumberCartel: what did you think it did?
| |
04:01 | LumberCartel: they're not workstations, they're just terminals
| |
04:01 | <sep> LumberCartel, well yes ++
| |
04:01 | <ball> (ideally)
| |
04:01 | <LumberCartel> ball: Well, we were discussing what VNC Viewer needs (e.g., audio, encryption, etc.), and then you suggested LTSP.
| |
04:01 | sep: So the OS is virtualized on a server, and LTSP provides the thin-client to it?
| |
04:01 | <ball> I /mentioned/ LTSP as an example of a graphical terminal ("thin client") environment
| |
04:02 | LumberCartel: needn't be virtualised
| |
04:02 | ...though it could be, if you want.
| |
04:03 | <LumberCartel> sep: Thank you for your time. I appreciate your help.
| |
04:03 | ball: It's not really what I'm after. I'm looking for a replacement for VNC (if RFB doesn't evolve) or RDP (because Microsoft holds patents on it).
| |
04:04 | * ball isn't aware of any alternatives that are open (Sun Ray is closed). | |
04:06 | lucascoala has quit IRC | |
04:07 | <LumberCartel> Thanks ball.
| |
04:11 | Kicer86 has quit IRC | |
04:12 | LumberCartel has left #ltsp | |
04:30 | * alkisg just wrote a wiki page about remote controlling the clients: https://help.ubuntu.com/community/UbuntuLTSP/PasswordlessSSH | |
04:32 | <appiah> yay \o/
| |
04:33 | should that script be included in docs examples or similar?
| |
04:36 | <alkisg> I do have a private ltsp-build-client plugin for that, that does it automatically...
| |
04:37 | I'll ask the other devs later on if they think I should include it upstream, as an option
| |
04:37 | i.e. ltsp-build-client --copy-ssh-keys or something
| |
05:01 | <appiah> that would be really nice
| |
05:03 | hersonls has joined #ltsp | |
05:08 | <appiah> ball: alternatives that are open?
| |
05:08 | alternative to what?
| |
05:08 | <ball> appiah: I am cold.
| |
05:08 | appiah: alternatives to VNC for LumberCartel's purposes.
| |
05:09 | <appiah> he wanted to run one application of a linuxserver?
| |
05:10 | oh well he left
| |
05:10 | <ball> appiah: No.
| |
05:10 | Faithful has joined #ltsp | |
05:16 | <ball> appiah: what made you think he only wanted one app?
| |
05:35 | <appiah> ah nevermind
| |
05:41 | shamino has joined #ltsp | |
05:43 | artista_frustrad has joined #ltsp | |
05:48 | artista_frustrad has quit IRC | |
05:52 | wwx has quit IRC | |
05:54 | wwx has joined #ltsp | |
05:57 | otavio has quit IRC | |
05:57 | otavio has joined #ltsp | |
05:57 | otavio has joined #ltsp | |
06:01 | artista_frustrad has joined #ltsp | |
06:06 | artista_frustrad has quit IRC | |
06:18 | pmatulis has joined #ltsp | |
06:21 | hersonls has quit IRC | |
06:23 | hersonls has joined #ltsp | |
06:28 | scottmaccal has joined #ltsp | |
06:45 | etyack has joined #ltsp | |
06:48 | ball has quit IRC | |
06:49 | vvinet has quit IRC | |
07:06 | evilx_ has quit IRC | |
07:08 | arevamp has joined #ltsp | |
07:11 | evilx has joined #ltsp | |
07:13 | hersonls has quit IRC | |
07:22 | hersonls has joined #ltsp | |
07:26 | alexqwesa has quit IRC | |
07:27 | vvinet has joined #ltsp | |
07:41 | monteslu has joined #ltsp | |
07:50 | alexqwesa has joined #ltsp | |
08:07 | yanu has quit IRC | |
08:13 | Gadi has joined #ltsp | |
08:27 | mikkel has quit IRC | |
08:35 | <Gadi> alkisg: ping
| |
08:35 | <alkisg> Hello Gadi
| |
08:35 | <Gadi> morning
| |
08:35 | saw ur commits
| |
08:35 | <alkisg> Ooops I feel something wrong coming up :)
| |
08:35 | <Gadi> can we remove the now superfluous entries in configure_resolver() in ltsp-init-common
| |
08:35 | ?
| |
08:36 | <alkisg> Ah. /me looks...
| |
08:36 | <Gadi> should speed things up, too (no call to hostname)
| |
08:36 | * Gadi is on a non-shell-primitive killing spree | |
08:37 | <alkisg> Heh
| |
08:38 | <Gadi> did u realize that a call to "hostname" takes twice as log as cat /etc/hostname
| |
08:38 | :)
| |
08:39 | <alkisg> We also have a cat something | grep something somewhere, we should also ditch the cat there :D
| |
08:39 | Well we can remove the first if in that function
| |
08:39 | <Gadi> cool
| |
08:39 | I got it
| |
08:40 | <alkisg> But I wonder what other boot methods exist
| |
08:41 | I mean, cases where nfs-bottom/ltsp wouldn't be called...
| |
08:42 | <Gadi> well, then your other code is in the wrong place
| |
08:42 | :)
| |
08:43 | either way, we shouldn't do the same thing twice
| |
08:43 | etyack has quit IRC | |
08:43 | * alkisg notes that he didn't _place_ any coded - just added an if in the existing code ;) | |
08:44 | <alkisg> *code
| |
08:44 | etyack has joined #ltsp | |
08:44 | <Gadi> hehe - you running for president?
| |
08:44 | ;)
| |
08:44 | <alkisg> Heh
| |
08:45 | It's amazing how easily bugs come out, though... I just added an innocent looking if, and on the next boot, my hostname was blank!
| |
08:45 | I didn't see that `. /tmp/net-*.conf` was modifying HOSTNAME in the mean time...
| |
08:48 | _UsUrPeR_ has quit IRC | |
08:49 | _UsUrPeR_ has joined #ltsp | |
08:49 | <_UsUrPeR_> Gadi: ping!
| |
08:52 | <Gadi> _UsUrPeR_: pong
| |
08:52 | <_UsUrPeR_> Gadi: heyyy :)
| |
08:53 | ok, remember the issues I was having with mic boost?
| |
08:53 | <Gadi> yeah
| |
08:56 | <_UsUrPeR_> ok, so I had set up a script in /opt/ltsp/i386/usr/share/ltsp/xinitrc.d
| |
08:57 | it was an alsactl command which restored previous alsamixer settings from /opt/ltsp/i386/asound.state
| |
08:57 | unfortunately, it has proved intermittant
| |
08:57 | sometimes it works, sometimes it does not
| |
09:00 | I'm trying to figure out how that could ben
| |
09:01 | s/ben/be
| |
09:01 | <Gadi> intermittent = works on some boots and not others OR works and then doesn't when x initializes again
| |
09:04 | also, it might help if you put some debugging stuff in ur script - like a nice: echo "Restoring alsa..." >/tmp/debug
| |
09:04 | right before the command
| |
09:04 | and then have ur command do a: 2>>/tmp/debug
| |
09:04 | so stderr goes to that file, too
| |
09:04 | <alkisg> Gadi, how would you feel about making this (https://help.ubuntu.com/community/UbuntuLTSP/PasswordlessSSH) an ltsp-build-client option? Any security concerns?
| |
09:04 | <Gadi> then, when it doesn't work, you can look at /tmp/debug
| |
09:05 | litlebuda has joined #ltsp | |
09:05 | mikkel has joined #ltsp | |
09:06 | <alkisg> DNS_SERVER without SEARCH_DOMAIN, cool :)
| |
09:07 | <Gadi> alkisg: it's definitely a security risk
| |
09:07 | but, the more philosophical question is
| |
09:07 | <alkisg> Gadi: but I think DNS_SERVERS are space-separated... (from udhcpc)
| |
09:07 | <Gadi> whether we feel comfortable having security holes as *options*
| |
09:08 | which I am always for :)
| |
09:08 | <alkisg> :)
| |
09:08 | <Gadi> as long as the risks are noted to the admin
| |
09:08 | <_UsUrPeR_> gadi: sorry. intermittant = works on some boots but not others
| |
09:08 | <Gadi> like, with this plugin, anyone can mount your image and get the LTSP server's host key and use it to compromise the system
| |
09:08 | :)
| |
09:09 | <alkisg> Gadi, it only takes the *public* key...
| |
09:09 | How would he compromise the system?
| |
09:09 | <Gadi> oh, yeah
| |
09:09 | look at that
| |
09:09 | :)
| |
09:09 | * Gadi reads too quickly | |
09:09 | <alkisg> :)
| |
09:10 | <_UsUrPeR_> .... :)
| |
09:10 | litlebuda has quit IRC | |
09:10 | <Gadi> yeah, vagrantc had issues with this approach - and I never understood why
| |
09:10 | seems perfectly safe to me
| |
09:10 | <alkisg> If we also disable password authentication in sshd_config, I don't see why wouldn't it be safe
| |
09:11 | <Gadi> but, as they say, locks are for honest people
| |
09:11 | <alkisg> I'll check with vagrantc later on, I'm sure he'll have some concerns nevertheless :D
| |
09:12 | <sbalneav> Morning all
| |
09:12 | <alkisg> !s
| |
09:12 | <ltspbot> alkisg: "s" :: Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
| |
09:12 | <Gadi> alkisg: is udhcp passing DNS_SERVER?
| |
09:12 | <alkisg> Gadi, yes
| |
09:12 | <Gadi> huh
| |
09:13 | * alkisg looks again... | |
09:13 | <alkisg> Ah right
| |
09:13 | We didn't support it, so I left it out
| |
09:13 | read dns0 dns1 rest_dns <<EOF
| |
09:13 | $dns
| |
09:13 | EOF
| |
09:13 | ==> I only took the first 2 dns servers
| |
09:14 | IPV4DNS0='$dns0'
| |
09:14 | IPV4DNS1='$dns1'
| |
09:14 | And exported them in the usual net*.conf style - and there they got "lost"
| |
09:14 | So no, it doesn't currently support it, but now with your patch, I can just leave all the dns servers in one line
| |
09:15 | <Gadi> cool - so, should I change to space delimited or comma is fine?
| |
09:15 | * Gadi did comma thinking of dhcpd.conf | |
09:15 | <alkisg> udhcpc uses space delimited
| |
09:16 | <Gadi> grr...
| |
09:16 | <alkisg> Maybe we should keep that, it saves us from an additional IFS meddling... :)
| |
09:17 | <Gadi> I suppose
| |
09:18 | ok, I'll change it
| |
09:19 | * alkisg notes down to modify udhcpc accordingly | |
09:24 | <Gadi> alkisg: does udhcp just populate the environment that the initscripts see OR does it write to lts.conf?
| |
09:24 | <alkisg> It indirectly modifies the environment
| |
09:24 | (it outpus a /tmp/params.conf file which init sources later on)
| |
09:24 | <Gadi> ah
| |
09:25 | is that just ubuntu's init
| |
09:25 | <alkisg> I've no idea :)
| |
09:25 | It's in the "run_scripts" function, but I haven't seen any other distros, so... :)
| |
09:26 | I think it's valid for Debian as well
| |
09:30 | * alkisg also notes that udhcpc needs major code-styling changes :D | |
09:34 | gentgeen__ has quit IRC | |
09:34 | <alkisg> Gadi, are you going to test with multiple dns servers? I think only a single line needs changing in init-premount/udhcp:
| |
09:34 | DNS_SERVER='$dns0' ==> DNS_SERVER='$dns'
| |
09:34 | So if you do, maybe you could test that in the same time...
| |
09:36 | gentgeen__ has joined #ltsp | |
09:54 | bobby_C has joined #ltsp | |
09:54 | The_Code has joined #ltsp | |
10:01 | bobby_C has quit IRC | |
10:16 | arevamp has quit IRC | |
10:21 | rjune has joined #ltsp | |
10:31 | litlebuda has joined #ltsp | |
10:39 | johnny has joined #ltsp | |
10:40 | silvergti has joined #ltsp | |
10:40 | <silvergti> hi
| |
10:41 | need some help...
| |
10:42 | I made a new install. LTSP on Ubuntu 64 bits
| |
10:42 | build the image with i386 arch
| |
10:42 | but the clients are a little slow
| |
10:43 | network Server, clients and network are Gigabit
| |
10:43 | artista_frustrad has joined #ltsp | |
10:43 | <silvergti> any tip?
| |
10:47 | gnunux is now known as Guest15610 | |
10:49 | artista_frustrad has quit IRC | |
10:53 | Egyptian[Home]1 has joined #ltsp | |
10:54 | <alkisg> silvergti: try to see what your bottleneck is. Server CPU? client cpu? network bandwidth?
| |
10:55 | <silvergti> well, I don't think the problem is there... maybe display drivers... the behaviour is similar at a normal pc without the gpu drivers
| |
10:56 | Egyptian[Home] has quit IRC | |
10:56 | <silvergti> but this was working out of the box with ubuntu 8.10
| |
11:00 | alking, do you know how can I configure this?
| |
11:02 | <johnny> silvergti, so.. your thin clients use nvidia or ati proprietary drivers?
| |
11:02 | otherwise.. the display drivers should be detected automatically
| |
11:02 | litlebuda has quit IRC | |
11:02 | <johnny> the proprietary ones are the only ones that don't
| |
11:02 | except in buggy drivers of course :)
| |
11:03 | <silvergti> nop. Not nvidia or ati
| |
11:06 | <johnny> you can see the log to see what drvers were used by setting SCREEN_02=shell in lts.conf and logging into the console
| |
11:06 | and looking at /var/log/Xorg.0.log
| |
11:07 | <alkisg> Even with the wrong drivers, there's would still be a bottleneck = the client CPU usage
| |
11:07 | <johnny> sure.. but the right drivers would ease that :)
| |
11:07 | <alkisg> E.g. if you try to play a fullscreen video with the nv driver, you get 100% CPU so you do have a bottleneck...
| |
11:07 | <silvergti> load average: 0.03, 0.06, 0.02
| |
11:07 | <johnny> alkisg, nouveau is coming soon for you :)
| |
11:07 | thats not cpu..
| |
11:08 | that's io load mostly
| |
11:08 | <alkisg> Not for Lucid unfortunately :(
| |
11:08 | <johnny> alkisg, didn't they say it was?
| |
11:08 | <silvergti> Cpu(s): 2.7%us, 0.9%sy, 0.0%ni, 95.4%id, 0.1%wa, 0.2%hi, 0.6%si, 0.0%st
| |
11:08 | <johnny> pretty sure i've read that like 20 times
| |
11:08 | <alkisg> johnny: I think it's not gonna make it, too buggy
| |
11:08 | I think it's scheduled for Lucid+1 or something like that
| |
11:08 | I hope I'm wrong... :(
| |
11:08 | <silvergti> and Mem: 8068148k total, 6398896k used
| |
11:09 | <alkisg> silvergti: try to play a video on a client
| |
11:09 | When it does that, run: ltsp-localapps xterm
| |
11:09 | on the xterm that will open, run: top
| |
11:09 | And see the cpu usage of the client...
| |
11:10 | <silvergti> it's always doing...
| |
11:10 | when i scroll a doc, it comes "slided"
| |
11:10 | Ahmuck has joined #ltsp | |
11:10 | cliebow has joined #ltsp | |
11:10 | <Ahmuck> in a ltsp system are there levels of administration?
| |
11:12 | <johnny> no more than the unix system it is based on..
| |
11:12 | <alkisg> silvergti: did you try with LDM_DIRECTX=false ?
| |
11:12 | err True?
| |
11:12 | !ldm_directx
| |
11:12 | <ltspbot> alkisg: Error: "ldm_directx" is not a valid command.
| |
11:12 | <alkisg> Bah
| |
11:12 | !lts.conf
| |
11:12 | <ltspbot> alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
| |
11:12 | <silvergti> alksig, i dind't touch the lts.conf, just now to try the SCREEN_02=shell
| |
11:13 | <alkisg> OK see the description for LDM_DIRECTX there ^^
| |
11:13 | It's speeds vs security
| |
11:13 | <silvergti> ok, ty :)
| |
11:13 | <johnny> Ahmuck, ubuntu doesn't really have ship with any of the internesting access control models
| |
11:13 | so.. not really
| |
11:13 | of course. neither do most distros..
| |
11:13 | no standard there..
| |
11:16 | <silvergti> alksing, i just added that in /var/lib/tftpboot/ltsp/i386/lts.conf
| |
11:16 | now i just need to logout and login right? no build need anymore
| |
11:17 | <alkisg> silvergti: no build, but a reboot of the clients is needed
| |
11:17 | <silvergti> oh, ok
| |
11:17 | ok, to get the "new" image
| |
11:17 | <alkisg> btw, pressing tab will autocomplete my name correctly :)
| |
11:17 | <silvergti> alkisg: nice ;)
| |
11:20 | <alincoln> with up to date lucid (kernel -dfa sample.dfa
| |
11:20 | -v sample.dict
| |
11:20 | -h acoustic_model_files/hmmdefs
| |
11:20 | -hlist acoustic_model_files/tiedlist
| |
11:20 | oh, sorry!
| |
11:20 | hah.
| |
11:20 | paste fail.
| |
11:21 | <silvergti> alkisg: it's still the same... got this on lts.conf LDM_DIRECTX = True
| |
11:21 | <alkisg> silvergti: you need a [Default] on top of that
| |
11:22 | Without the [Default] section, it doesn't take any effect
| |
11:22 | <silvergti> trying
| |
11:23 | <alincoln> with up to date lucid (2.6.32-12-generic), and using upstream ldm, ldm crashes when you log out of a session. it comes up fine at first and logging in works, but once you log out ldm doesn't reappear. ldm.log shows an error for waitid in ldm.c, and after adding some debugging stuff, the call to waitid in line 208 is returning EINTR.
| |
11:24 | i noted the kernel because this didn't seem to be a problem with 2.6.32-11-generic
| |
11:24 | i'll keep looking into it, but wanted to mention it here.
| |
11:26 | <silvergti> alkisg: samething :(
| |
11:28 | <Gadi> alincoln: upstream == 2.0.54 ?
| |
11:29 | tarbo has joined #ltsp | |
11:29 | yanu has joined #ltsp | |
11:29 | yanu has joined #ltsp | |
11:29 | <alkisg> silvergti: post your lts.conf to pastebin
| |
11:30 | <silvergti> only 2 lines...
| |
11:30 | [Default]
| |
11:30 | #SCREEN_02 = shell
| |
11:30 | LDM_DIRECTX = True
| |
11:31 | <alincoln> Gadi: i think... what's in launchpad's ltsp project's ltsp-upstream/ldm branch
| |
11:31 | <alkisg> silvergti: what graphics card do your clients have?
| |
11:31 | <alincoln> it still says 2.0.52 in changelog, but is there a more up-to-date branch somewhere?
| |
11:31 | <Gadi> alincoln: have you been using upstream ltsp, as well?
| |
11:31 | <alincoln> Gadi: yeah, i'm trying to base my work on all upstream branches
| |
11:32 | <Gadi> last upstream tag was 2.0.54
| |
11:32 | <silvergti> alkisg: just give me a moment to log Thin OS to check
| |
11:33 | <Gadi> alincoln: ur taking: ~ltsp-upstream/ltsp/ldm-trunk/
| |
11:33 | <alkisg> silvergti: try with SCREEN_07=ldm
| |
11:33 | <Gadi> right?
| |
11:33 | <alkisg> SCREEN_02=shell
| |
11:33 | silvergti: this way you'll get both an ldm and a shell
| |
11:33 | <alincoln> Gadi: oh, oops. i forgot. yes, you're right, that's what i'm using. the 2.0.52 comes from vagrantc's packaging branch, which i base my packaging off of
| |
11:33 | but doesn't affect the ldm code
| |
11:33 | but yes, using that latest upstream.
| |
11:33 | <Gadi> hmm... I dont have that problem
| |
11:33 | on karmic
| |
11:34 | plus that version
| |
11:34 | hmmm....
| |
11:34 | <alincoln> Gadi: yeah, it's only been since the .32-12 kernel on lucis
| |
11:34 | checking .32-11 now
| |
11:35 | tarbo has quit IRC | |
11:36 | arreyder has quit IRC | |
11:36 | arreyder has joined #ltsp | |
11:36 | otavio has quit IRC | |
11:37 | otavio has joined #ltsp | |
11:44 | spectra has joined #ltsp | |
11:44 | <alincoln> Gadi: problem is in .32-11 also, but now I'm remembering that it was .32-10 it worked under. checking there.
| |
11:45 | <silvergti> the right place to the lts.conf is /var/lib/tftpboot/ltsp/i386/, correct?
| |
11:47 | <alkisg> if you have i386 clients, yes
| |
11:47 | silvergti: if you put that :
| |
11:47 | [Default]
| |
11:47 | SCREEN_02=shell
| |
11:47 | SCREEN_07=ldm
| |
11:48 | and you
| |
11:48 | 're not seeing a prompt when you press alt+ctrl+f2, then your lts.conf doesn't reach the clients
| |
11:49 | tarbo has joined #ltsp | |
11:51 | <silvergti> now it's working...
| |
11:51 | can't use space between the = and the value
| |
11:52 | hersonls has quit IRC | |
11:53 | <johnny> that's what i keep saying to people :) nobody believes me :)
| |
11:53 | <silvergti> i do
| |
11:54 | :-P
| |
11:55 | ok, this is a SiS 771/671 PCIE
| |
11:55 | tarbo has quit IRC | |
11:55 | <silvergti> and its using sis_agp
| |
11:55 | akuepker has joined #ltsp | |
11:58 | <akuepker> anyone have a good algorithm for determining X_VIDEO_RAM settings? Wondering if I need to bump ours up as the users are complaining of responsiveness delays on rather powerful GX260 terminals.
| |
12:00 | <silvergti> how can I force a gpu driver?
| |
12:01 | xserver="module" ?
| |
12:01 | otavio has quit IRC | |
12:01 | otavio has joined #ltsp | |
12:04 | <akuepker> yes, that's how a graphics driver is manually specified. if it's under [default] it applies to all terminals and if set under a specific terminal's header, it applies to only that terminal.
| |
12:05 | <silvergti> ty :)
| |
12:05 | <akuepker> don't know about the other distros, but there's a file named /usr/share/doc/ltsp-server/lts-parameters.txt in Ubuntu with the valid options
| |
12:05 | at least in karmic
| |
12:06 | <alkisg> akuepker: that's deprecated, use man lts.conf from now on ;)
| |
12:06 | !lts.conf
| |
12:06 | <ltspbot> alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
| |
12:07 | monteslu has quit IRC | |
12:07 | <akuepker> k,thanx. little short on coffee this AM.
| |
12:08 | small wonder. no 'man lts.conf' in karmic either.
| |
12:09 | tarbo has joined #ltsp | |
12:12 | <alkisg> akuepker: you need to install ltsp-docs or something
| |
12:12 | <silvergti> alkisg: thank for your help :)
| |
12:13 | <alkisg> silvergti: sorry I didn't know anything about your driver :)
| |
12:13 | <silvergti> no problem, will ask to google
| |
12:16 | tarbo has quit IRC | |
12:17 | monteslu has joined #ltsp | |
12:27 | <alkisg> Yup lts.conf is there in Karmic: http://manpages.ubuntu.com/manpages/karmic/en/man5/lts.conf.5.html
| |
12:29 | <silvergti> alkisg: got a sis671_drv.so file in my server. now, how can I "import" to the image
| |
12:29 | <alkisg> It's not there on the image?
| |
12:29 | <silvergti> nop
| |
12:30 | <alkisg> dpkg -S path/to/file to see what package owns it...
| |
12:30 | tarbo has joined #ltsp | |
12:30 | <silvergti> xorg-driver-sis671: /usr/lib/xorg/modules/drivers/sis671_drv.so
| |
12:30 | Lns has joined #ltsp | |
12:31 | <alkisg> Then maybe you should just install that driver on the chroot?
| |
12:31 | * alkisg has no clue about drivers | |
12:31 | <silvergti> oh... lol
| |
12:31 | <Gadi> silvergti: is this something you got from a package?
| |
12:31 | <silvergti> yes
| |
12:32 | <Gadi> what package?
| |
12:32 | ah
| |
12:32 | xorg-driver-sis671
| |
12:32 | right?
| |
12:32 | <silvergti> yep
| |
12:32 | <alkisg> Why would that be installed on the server and not on the chroot? Is it proprietary?
| |
12:32 | <Gadi> sudo chroot /opt/ltsp/i386 apt-get install xorg-driver-sis671
| |
12:33 | then, sudo ltsp-update-image --arch i386
| |
12:33 | and, you may need: XSERVER=sis671 in your lts.conf
| |
12:33 | <alkisg> (08:33:42 μμ) ubottu: Package xorg-driver-sis671 does not exist in karmic
| |
12:33 | ?
| |
12:33 | <silvergti> it's a deb package, so wget in chroot
| |
12:33 | dpkg -i package.deb
| |
12:33 | The_Code has quit IRC | |
12:34 | * Lns reminds channel that Gadi is the X/driver MASTA | |
12:34 | <Gadi> hehe - far from it
| |
12:34 | :P
| |
12:34 | <Lns> don't kid yourself =)
| |
12:34 | <alkisg> Also the audio master... so maybe "the multimedia master" :D
| |
12:34 | <silvergti> hehe
| |
12:35 | <Gadi> silvergti: just don't forget to chroot before you dpkg
| |
12:35 | <silvergti> done :)
| |
12:35 | testing
| |
12:37 | tarbo has quit IRC | |
12:37 | * Lns nominates Gadi as the LTSP multimedia masta | |
12:37 | <Lns> which includes a trophy filled with his favorite beverage
| |
12:39 | otavio has quit IRC | |
12:39 | otavio has joined #ltsp | |
12:40 | <alkisg> silvergti: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/301958
| |
12:41 | It says there that no driver exists in any ubuntu version - only patched ones...
| |
12:41 | <silvergti> :(
| |
12:41 | <alkisg> So yup, that deb was needed :)
| |
12:42 | <silvergti> but still not getting results...
| |
12:43 | <alkisg> It's weird how it was working for you with 8.10
| |
12:44 | <silvergti> step by step...
| |
12:45 | sudo chroot /opt/ltsp/i386
| |
12:45 | dpkg -i xorg-driver-sis671_0.9_i386.deb
| |
12:45 | logout
| |
12:45 | ltsp-update-image --arch i386
| |
12:46 | how can i see the right name of the module?
| |
12:46 | modprobe -l | grep sis
| |
12:46 | that command after chroot
| |
12:46 | don't show the sis671
| |
12:47 | <Gadi> modprobe is for kernel modules not Xorg modules
| |
12:47 | did you add: XSERVER=sis671 to your lts.conf?
| |
12:48 | and reboot the client
| |
12:48 | <silvergti> "out of range"
| |
12:48 | <Gadi> thats ur monitor talking
| |
12:48 | <silvergti> indeed
| |
12:48 | <Gadi> set:
| |
12:49 | X_HORZSYNC = "30-100"
| |
12:49 | X_VERTREFRESH = "55-75"
| |
12:50 | <silvergti> ok
| |
12:50 | rebooting
| |
12:50 | <Gadi> you may need to adjust the ranges to suit the monitor
| |
12:50 | but, whatever default mode that driver is choosing, it is out of range for the monitor
| |
12:51 | anybody know what the current state of sabayon is?
| |
12:51 | <alincoln> Gadi: occurs on old karmic kernel too. i wonder what i did to cause this.
| |
12:51 | anyway, i'll keep poking.
| |
12:51 | <silvergti> still out of range
| |
12:51 | <Gadi> alincoln: it's probably an rc.d/ script
| |
12:52 | thats holding you up
| |
12:52 | tarbo has joined #ltsp | |
12:52 | <Gadi> silvergti: what is the make/model of the monitor?
| |
12:52 | ogra has joined #ltsp | |
12:53 | <silvergti> Input Frequency Range Horizontal31 ~ 82 KHz
| |
12:53 | Vertical 56 ~ 76 Hz
| |
12:53 | gona try that
| |
12:53 | <Gadi> ah
| |
12:53 | yeah
| |
12:53 | <silvergti> rebooting
| |
12:54 | wired... got the same error
| |
12:56 | <Gadi> can you ctrl-alt-f2 to the shell still?
| |
12:56 | if so, you can look at /var/log/X*log on the client
| |
12:56 | for answers
| |
12:57 | <silvergti> ok, I go take a look
| |
12:59 | tarbo has quit IRC | |
13:00 | <silvergti> there's a line " Using SiS300/315/330/340/350 series HW Xv by default on CRT1"
| |
13:01 | i think this don't help me :S
| |
13:03 | <cliebow> c
| |
13:03 | Golly..thought i'd never get back on
| |
13:04 | <Gadi> silvergti: why don't you scp that file to the server and then paste it in pastebot
| |
13:05 | !pastebot
| |
13:05 | <ltspbot> Gadi: "pastebot" :: The LTSP pastebot is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
| |
13:06 | ogra has quit IRC | |
13:10 | <silvergti> http://ltsp.pastebin.com/m5c8069ce
| |
13:11 | cliebow has quit IRC | |
13:11 | cliebow has joined #ltsp | |
13:13 | <Gadi> silvergti: the driver is not honoring DDC or the frequencies you put
| |
13:13 | and is instead setting the mode to 1600x1200
| |
13:14 | you may want to try: XRANDR_MODE_0 = 1280x1024
| |
13:14 | OR: XRANDR_SIZE_0 = 1280x1024
| |
13:14 | <silvergti> the first, is the max of the screen
| |
13:14 | <Gadi> OR: XRANDR_DISABLE = True and X_MODE_0 = 1280x1024
| |
13:15 | tarbo has joined #ltsp | |
13:18 | <silvergti> Gadi! it's working :D
| |
13:18 | thank you a lot!
| |
13:18 | <Gadi> np - which one worked (of the above)?
| |
13:19 | <silvergti> XRANDR_MODE_0 = True
| |
13:19 | X_MODE_0 = 1280x1024
| |
13:19 | tryed that one first
| |
13:19 | and worked
| |
13:19 | <Gadi> you mean XRANDR_DISABLE = True
| |
13:19 | <silvergti> tried*
| |
13:19 | both
| |
13:19 | <Gadi> ah, ok, so you only need XRANDR_DISABLE and X_MODE_0
| |
13:20 | <silvergti> wait
| |
13:20 | i got this:
| |
13:20 | XRANDR_MODE_0 = True
| |
13:20 | <Gadi> what that does is it hard codes 1280x1024 as the only valid mode for the x server
| |
13:20 | <silvergti> X_MODE_0 = 1280x1024
| |
13:20 | ogra has joined #ltsp | |
13:21 | <Gadi> well, the first does not make sense
| |
13:21 | <silvergti> don't have this XRANDR_DISABLE
| |
13:21 | the X_MODE i understand what it does
| |
13:21 | the other not really
| |
13:21 | <Gadi> try with just X_MODE_0
| |
13:22 | so, XRANDR_MODE_0 tries to set the mode using xrandr
| |
13:22 | X_MODE_0 limits the Xserver to that mode in the xorg conf file
| |
13:22 | tarbo has quit IRC | |
13:23 | <silvergti> ok, with X_MODE_0 it's working
| |
13:24 | now must do the changes on production server... :P
| |
13:24 | <Gadi> ah - and I just checked - we have backwards compat with older ltsp options, so X_MODE_0 == XRANDR_MODE_0 (unless you do XRANDR_DISABLE)
| |
13:24 | <alkisg> Gadi, got a minute to look at lines 23-24 of client/initramfs/hooks/ltsp_nbd ? It's a mismatched casing problem (X vs ${x})...
| |
13:24 | I'm thinking of deleting the "force_load" calls below that, but I'm not sure that I understand what's going on there :)
| |
13:25 | <Gadi> sure - 1 sec
| |
13:26 | <silvergti> now, if i do this, only the same branded thin will work right? the only way to change this is declaring one by one?
| |
13:26 | <Gadi> silvergti: I would do this:
| |
13:27 | make another entry in lts.conf:
| |
13:27 | [SIS671]
| |
13:27 | X_MODE_0=1280x1024
| |
13:27 | XSERVER=sis671
| |
13:27 | or whatever
| |
13:27 | and then you can have:
| |
13:27 | [aa:bb:cc:dd:ee:ff]
| |
13:27 | LIKE=SIS671
| |
13:28 | and have an entry like that for each mac address of a sis671 unit
| |
13:28 | <johnny> hmm.. too bad the config isn't more like yaml..
| |
13:28 | <Gadi> alkisg: force_load()
| |
13:28 | {
| |
13:28 | manual_add_modules ${@}
| |
13:28 | echo "${@}" >>"${DESTDIR}/conf/modules"
| |
13:28 | }
| |
13:28 | <alkisg> Gadi, yes, that's why I'm thinking of deleting them
| |
13:29 | <silvergti> for the moment only SIS671 clients
| |
13:29 | <alkisg> They seem redudant - seems like ogra put them there because he didn't notice the X / ${x} case problem
| |
13:29 | <Gadi> alkisg: force_load will make sure they are loaded, while manual_add_modules only makes them present in the initramfs
| |
13:29 | <silvergti> it's easier to add the non-SIS
| |
13:29 | <Gadi> alkisg: keep the force_load, but dump the manual add
| |
13:29 | <alkisg> Ah, Gadi, then the 3 lines above should be removed?
| |
13:29 | <ogra> hmm ?
| |
13:29 | <silvergti> thank you a lot Gadi and alkisg
| |
13:29 | <alkisg> ogra, nm, ancient history :)
| |
13:30 | silvergti: you're welcome
| |
13:30 | artista_frustrad has joined #ltsp | |
13:30 | cliebow has quit IRC | |
13:30 | <Gadi> silvergti: the value "none" is a reserved one
| |
13:30 | cliebow has joined #ltsp | |
13:30 | <ogra> alkisg, they were not redundant back when they were added, the script wasnt upgraded according to the changes in initramfs-tools
| |
13:30 | <alkisg> ogra, case mismatch in lines 23-24 in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/annotate/head%3A/client/initramfs/hooks/ltsp_nbd
| |
13:30 | <Gadi> which should unset an inherited value
| |
13:30 | <alkisg> ogra, X vs ${x}
| |
13:31 | <ogra> oh
| |
13:31 | <Gadi> hehe
| |
13:31 | * ogra wonders how that every worked then | |
13:31 | <alkisg> So those lines didn't really do anything for some time...
| |
13:32 | <ogra> well, if they didnt do anything back in the time when initramfs wasnt smart enough to load these modules ltsp would have been broken
| |
13:32 | <alkisg> force_load did the work, as far as I understand, so the others were just cosmetic...
| |
13:34 | What happens if force_load nbd is called twice?
| |
13:34 | Is that a bad thing?
| |
13:34 | (I think it is called twice, that's why I'm asking...)
| |
13:34 | <Gadi> no, it's fine
| |
13:34 | artista_frustrad has quit IRC | |
13:35 | <alkisg> OK, removing those add_modules then
| |
13:35 | Ty
| |
13:37 | tarbo has joined #ltsp | |
13:38 | cliebow has quit IRC | |
13:38 | cliebow has joined #ltsp | |
13:42 | cliebow has quit IRC | |
13:42 | cliebow has joined #ltsp | |
13:42 | akuepker has quit IRC | |
13:44 | tarbo has quit IRC | |
13:44 | vagrantc has joined #ltsp | |
13:45 | akuepker has joined #ltsp | |
13:45 | <ogra> alkisg, hrm you should probably have done it the other way round, instead of keeping the force_load
| |
13:46 | <alkisg> ogra, that's what I proposed, but Gadi told me otherwise. I don't really understand modules, so whatever you guys think is best, either commit it or tell me to.
| |
13:47 | etyack has quit IRC | |
13:47 | <ogra> well, the force_load is definately a sledgehammer while manual_add_modules performes some checks and the like
| |
13:47 | artista_frustrad has joined #ltsp | |
13:48 | <Gadi> ogra: the only diff between force_load and manual_add is the addition of:
| |
13:48 | echo "${@}" >>"${DESTDIR}/conf/modules"
| |
13:49 | <ogra> doesnt it also doy copy and check for existence etc ?
| |
13:49 | i think it at least did that once
| |
13:50 | oh, i see what you mean
| |
13:50 | force_load wraps around it
| |
13:51 | * ogra hads Gadi a waldorf salad | |
13:51 | <ogra> you win :)
| |
13:51 | alkisg, so Gadi is right, keep it as is
| |
13:51 | <alkisg> ok :)
| |
13:53 | artista_frustrad has quit IRC | |
13:58 | silvergti has left #ltsp | |
14:01 | tarbo has joined #ltsp | |
14:03 | <vagrantc> Gadi: gah.
| |
14:04 | Gadi: or rather, i *really* liked your ltsp-remoteapps cleanup the other day. :)
| |
14:04 | Gadi: and gah. /etc/hostname tweaking in initscripts is still needed on debian.
| |
14:05 | artista_frustrad has joined #ltsp | |
14:07 | tarbo has quit IRC | |
14:09 | artista_frustrad has quit IRC | |
14:11 | <Gadi> vagrantc: oops - sorry about that -> if you put it back, have it check for /etc/init.d/hostname.sh before calling it
| |
14:11 | <vagrantc> Gadi: how bout "hostname=$(hostname)" ?
| |
14:12 | <Gadi> vagrantc: run: time hostname; time cat /etc/hostname
| |
14:12 | <vagrantc> oh, and then there's the other use case...
| |
14:13 | Gadi: read hostname < /etc/hostname ; test -z "$hostname" && hostname=$(hostname) ?
| |
14:13 | if you really want to make it speedy :)
| |
14:13 | <Gadi> oops
| |
14:13 | just checked
| |
14:13 | I got it backwards
| |
14:13 | hostname is faster than cat /etc/hostname
| |
14:13 | *blush*
| |
14:14 | <vagrantc> read is even faster
| |
14:14 | well, depends on if /etc/hostname is cached or not...
| |
14:16 | <alkisg> vagrantc: Hi! I made an ltsp-build-client plugin for passwordless ssh to the clients, do you think it belongs upstream (of course optional)? https://help.ubuntu.com/community/UbuntuLTSP/PasswordlessSSH
| |
14:16 | etyack has joined #ltsp | |
14:16 | <vagrantc> Gadi: i'm getting wildly unpredictable results...
| |
14:17 | alkisg: curious :)
| |
14:17 | alkisg: it does have the classic problem of man-in-the-middle attacks.
| |
14:18 | <alkisg> vagrantc, meaning?
| |
14:18 | How could the man in the middle get the server's private key?
| |
14:19 | <vagrantc> alkisg: how do you ssh to the client with a key that's publicly exported?
| |
14:19 | <alkisg> I put that in the root's authorized keys... ?
| |
14:19 | <vagrantc> alkisg: not the /opt/ltsp/i386/root/.ssh/authorized_keys, but /opt/ltsp/i386/etc/ssh_host*key
| |
14:19 | <alkisg> No, I'm using the server's key, not the chroot one
| |
14:20 | /etc/ssh/ssh_host_rsa_key
| |
14:20 | <vagrantc> alkisg: so you're on the server, you do soemthing like ssh -f /etc/ssh/ssh_host_rsa_key $some_client_ip ... you get a prompt if the host key of the client is the one you're expecting...
| |
14:21 | <alkisg> Right
| |
14:21 | <vagrantc> alkisg: there's no way to properly verify that you're connecting to a client and nobody's in between you and the client
| |
14:21 | <alkisg> Right, same as every first-time ssh connection
| |
14:21 | <vagrantc> because the client's private key is publicly available.
| |
14:21 | alkisg: no, it's even worse... anyone on your network has access to the *private* key of *all* of the thin clients.
| |
14:22 | this comes up pretty regularly.
| |
14:22 | <alkisg> So they can fake to be an ltsp client, why is that a problem?
| |
14:22 | They can do that without ssh as well...
| |
14:23 | <vagrantc> alkisg: without ssh?
| |
14:24 | tarbo has joined #ltsp | |
14:24 | <alkisg> I mean, they have access to the whole chroot
| |
14:24 | <vagrantc> the problem is you're using ssh to connect to the thin client, and they could use that to monitor the processes of anyone logged into that thin client.
| |
14:24 | <alkisg> How would they do that?
| |
14:25 | <vagrantc> alkisg: and an ssh server isn't installed by default... so normally that's not an issue...
| |
14:26 | alkisg: when you ssh root@clientA from serverB, hackerC pretends to be clientA and gains root access to clientA... all further logins on clientA are compromised.
| |
14:26 | alkisg: or more specifically...
| |
14:27 | spectra has quit IRC | |
14:27 | <vagrantc> alkisg: hackerC pretends to be clientA, relaying the conversation to the actualy clientA, but keeps the session running after the admin from serverB logs out
| |
14:27 | with root privledges.
| |
14:27 | there are rootkits that handle this sort of things.
| |
14:27 | <Lns> zoikes
| |
14:28 | * vagrantc feels like a non-native speaker today | |
14:28 | <alkisg> vagrantc: ok, got it. That assumes a man in the middle, that got there _after_ the client boots. It'd be much easier to be there, in the middle, from the start, and doing the exact same thing...
| |
14:28 | <vagrantc> alkisg: which is why it's a dangerous thing to use ssh in that way.
| |
14:29 | <alkisg> I mean, if the hacker is in the middle, he already can intercept everything, with or without ssh..
| |
14:29 | Why would he bother to only start being in the middle when the ssh connection starts?
| |
14:30 | <vagrantc> yes, but *normally* ssh is supposed to prevent people from being able to actually participate in the conversation and inject their code.
| |
14:30 | when using ssh, you shouldn't hvae to worry about man in the middle attacks, because you establish a trust path to verify the key properly.
| |
14:30 | <alkisg> What I mean is, that it doesn't impose any *additional* security risks that LTSP doesn't already have...
| |
14:30 | tarbo has quit IRC | |
14:31 | <vagrantc> alkisg: it allows people to remotely log into the thin clients, whereas before the man-in-the-middle risk is using the known_hosts over an insecure connection.
| |
14:31 | alkisg: it's basically making it bad security from all directions, instead of just one.
| |
14:31 | and actually easier to implement.
| |
14:32 | and gives the illusion of more solid security
| |
14:32 | you may as well use telnet.
| |
14:32 | ok, it's not that bad... order of magnitude harder than telnet.
| |
14:32 | <alkisg> :)
| |
14:33 | <vagrantc> but it's an illusion of security that is very dangerous
| |
14:33 | <alkisg> If I'm a man in the middle, I can send a different ssh key to the clients
| |
14:33 | That works in any way
| |
14:33 | Both directions
| |
14:33 | pmatulis has quit IRC | |
14:33 | <vagrantc> alkisg: normally the only ssh keys on a thin client are known_hosts entries for the servers.
| |
14:34 | avena has quit IRC | |
14:34 | <Lns> alkisg: but you don't have the private host key
| |
14:34 | <vagrantc> bingo.
| |
14:34 | * vagrantc thanks lns | |
14:34 | <alkisg> I can send a different known_hosts file
| |
14:34 | For my own private key...
| |
14:34 | <vagrantc> alkisg: and connect to your own private server...
| |
14:34 | <Lns> that's more of a hijack than a mitm
| |
14:35 | <vagrantc> and that server could probably relay the connection to the real server, monitoring all the while
| |
14:35 | so that's the same basic problem.
| |
14:35 | <alkisg> Right, that's why I'm saying that I don't see any _additional_ holes...
| |
14:35 | avena has joined #ltsp | |
14:35 | <vagrantc> alkisg: it's a new hole in a new direction
| |
14:36 | <alkisg> LTSP can handle listeners, but not men in the middle...
| |
14:36 | <vagrantc> you want in through the back door, the front door, the window, or the secret passageway connected to the sewers?
| |
14:37 | the more options you make available, the more likely someone will exploit it
| |
14:37 | the most insecure problem LTSP really has is no means of verifying the boot process.
| |
14:37 | <alkisg> Why is it more difficult to fake the known_hosts file than the private ssh key?
| |
14:38 | As far as I understand, the same process would be needed for both...
| |
14:38 | <vagrantc> alkisg: you'd have to hijack the root filesystem and/or boot process
| |
14:38 | alkisg: whereas for private keys a little packet injection would be enough
| |
14:39 | it's *bad* to use a shared private key. just *bad*.
| |
14:39 | <alkisg> The client reads /etc/ssh/known_hosts from nfs, right? Why can't I change that with packet injection?
| |
14:40 | <vagrantc> i suppose so... but to do so without corrupting the root filesystem in a way the client notices?
| |
14:41 | NFS makes a lot of calls for every file read (that's why it's so slow) ... you've have to make sure they all work right
| |
14:41 | <alkisg> How would I do it for the /etc/ssh/rsa key then?
| |
14:41 | <vagrantc> i guess there's more rootkits out there that man-in-the-middle ssh.
| |
14:42 | mgariepy has joined #ltsp | |
14:43 | <alkisg> vagrantc: in any case thank you, I hadn't thought of all that :)
| |
14:43 | <vagrantc> i should make a link to this conversation in ltspbot
| |
14:43 | it comes up every few months
| |
14:44 | <alkisg> Heh
| |
14:45 | <vagrantc> it's not easy... and i haven't ever done it... but i know it's a risk and people often are stubborn to accept that it's a problem at all...
| |
14:45 | <alkisg> I'm pretty sure that I can make a man in the middle attack for the known_hosts file, though...
| |
14:45 | <vagrantc> the real security issues with LTSP are insecure boot processes
| |
14:46 | <alkisg> I bet 512-byte chunks are transferred (or even more), so I wouldn't even need to look at the headers, just the chunk
| |
14:46 | <vagrantc> or, the more likely scenario
| |
14:46 | tarbo has joined #ltsp | |
14:46 | <vagrantc> i wonder the relative merits of NFS vs. NBD there
| |
14:47 | <alkisg> squashfs might make it a little harder...
| |
14:47 | <vagrantc> the easiest hijack is a rouge dhcp server
| |
14:47 | then you have it all.
| |
14:48 | <Lns> is there anything in gpxe that can verify who it's getting an ip from, from the get-go?
| |
14:48 | <vagrantc> i think there are some mechanisms in gPXE for signed boot images and such...
| |
14:48 | <Lns> hmm
| |
14:48 | <vagrantc> you'd have to flash all your thin clients with that every time you need a new signing key... but that's pretty secure.
| |
14:49 | alkisg: gonna work on some LTSP rootkits? :)
| |
14:49 | <alkisg> Heh... nah, I just want to be able to remotely shutdown my cilents :)
| |
14:49 | <vagrantc> we could commit them upstream and everything
| |
14:50 | <alkisg> ...and some other, fat-client-related stuff
| |
14:50 | <Lns> NO! WE CAN'T LET ANYONE KNOW ABOUT OUR VULNERABILITIES! lol
| |
14:50 | <vagrantc> alkisg: i used to run a little daemon on the thin client that checked for the presence of a file and did stuff ... worked really simply with NFS.
| |
14:51 | a little trickier with NBD ... but you could have an nfs layer for such communications.
| |
14:51 | <alkisg> Nah, I'm not worried about man in the middle attacks in schools here. If someone is determined to do it, he can do it with or without ssh.
| |
14:52 | Academically, I would agree with you that it opens another hole. But practially, I wouldn't...
| |
14:52 | <vagrantc> alkisg: sure.
| |
14:52 | <alkisg> And ssh gives a lot more power than some other daemon, especially for fat clients
| |
14:53 | <vagrantc> Gadi: ok, so regarding the hostname issue ...
| |
14:53 | Gadi: did we come up with anything?
| |
14:53 | <alkisg> I can even change lts.conf on the fly, restart ldm, and force autologon with a specific user...
| |
14:53 | tarbo has quit IRC | |
14:53 | <Gadi> vagrantc: you started talking about inconsistencies, but then you went off on some security tirade ;)
| |
14:53 | <vagrantc> Gadi: ah yes.
| |
14:53 | * alkisg hides :) | |
14:54 | <Lns> alkisg: man, i would really love for you to join the dev team i'm putting together :) we're in need of some more developers and you would just be perfect for what we're trying to accomplish
| |
14:54 | <alkisg> Lns, do you mean tcm-ng?
| |
14:54 | <Lns> alkisg: kind of, but a different (but related) project
| |
14:55 | alkisg: basically a mechanism for raw ltsp server < -- > ltsp client communications
| |
14:55 | <alkisg> Lns, see the second screenshot there: http://wiki.ubuntu-gr.org/sch-scripts/screenshots
| |
14:55 | <vagrantc> Gadi: so, security aside... various ways of reading hostname are ... hostname .... read hostname < /etc/hostname ... hostname=$(cat /etc/hostname)
| |
14:55 | <alkisg> It'll have remote ltsp management, automatic building of thin/fat chroots, 80% of italc functionality, video broadcasting.. you name it
| |
14:55 | <vagrantc> Gadi: /etc/hostname may be empty on debian
| |
14:55 | <Lns> alkisg: wow
| |
14:56 | stgraber has quit IRC | |
14:56 | stgraber has joined #ltsp | |
14:56 | <Lns> looks like a tcm replacement
| |
14:56 | <Gadi> vagrantc: go for hostname
| |
14:56 | like we had it
| |
14:56 | <vagrantc> Gadi: just revert it entirely?
| |
14:56 | <alkisg> Lns: Pretty much. We're even making our own mini-language for making such scripts easier...
| |
14:56 | <Gadi> but, don't just call /etc/init.d/hostname.sh without checking for it
| |
14:56 | <vagrantc> Gadi: ok.
| |
14:56 | bobby_C has joined #ltsp | |
14:56 | <Gadi> and make sure you need it before you revert
| |
14:56 | <Lns> alkisg: why not take a looksie at the code at https://launchpad.net/tcm-ng - I'd love to hear what you have to say about it
| |
14:57 | <alkisg> Lns: e.g. the script to transfer a bunch of files to the documents folder of the connected clients, is just 1 line... Exec=cp @{f.name} ${u.documents}
| |
14:57 | <Lns> it's not really usable but the code has been completely cleaned up and modularized
| |
14:57 | * Gadi wonders why initramfs doesnt set it on debian | |
14:57 | <Gadi> vagrantc: did you test?
| |
14:57 | <alkisg> Lns, I do like the code base but I don't like the interface. I want the teacher/admin to be able to select stuff (users, PCs, groups, files) and to be able to invoke actions on them
| |
14:58 | <vagrantc> Gadi: i'd have to make /etc/hostname writeable...
| |
14:58 | Gadi: it's been knocking in the back of my head for a while for ltsp to handle writeable directories from initramfs... but i've never gotten around to it.
| |
14:58 | <Lns> alkisg: do you have anything from your program that's distributable?
| |
14:59 | <Gadi> vagrantc: ah - damn writable requirement
| |
14:59 | :)
| |
14:59 | <alkisg> Lns, no, not yet. It runs now, but only with manual installation. We do write the code comments in english, and the menus (=standard .desktop files) will be internationalized, but some stuff is in Greek...
| |
14:59 | <vagrantc> Gadi: yeah, that always gets y'all..
| |
15:00 | <alkisg> Lns: when it's done (I hope in time for Lucid) I'll tell you - if you're interested in helping internationalizing it...
| |
15:00 | <ogra> vagrantc, take a look at udev
| |
15:00 | <vagrantc> might be more feasible to have a writeable FS by default...
| |
15:00 | <Gadi> vagrantc: maybe the initscript can be more graceful
| |
15:00 | one sec...
| |
15:00 | <vagrantc> ogra: for writeable fs in initramfs?
| |
15:00 | <ogra> yes
| |
15:00 | <Lns> alkisg: i really, really like the idea of performing actions on non-specific entities (user/group/client/whtaever)
| |
15:00 | <ogra> it uses a tmpfs mount and then move mounts the stuff it needs in the final system
| |
15:00 | <Lns> alkisg: i've never done language work but i do know english pretty well =)
| |
15:01 | <ogra> you should be able to do something similar
| |
15:01 | (though it might be different in ubuntus udev vs debian)
| |
15:01 | <vagrantc> seems like it's even in lenny
| |
15:01 | <ogra> ah, good
| |
15:01 | <alkisg> Lns, my team has thought most of it through, so it's "just" about 70% of the implementation remaining :) I hope it'll be ready in 3 months, we can work together then if you like the result.
| |
15:02 | Lns, is work on tcm-ng ongoing?
| |
15:02 | <Lns> alkisg: please do
| |
15:02 | scottmaccal has quit IRC | |
15:02 | <alkisg> We could exchange some code, e.g. how we detect the clients, mac addresses, hostnames etc..
| |
15:03 | <Lns> alkisg: yes, we've got another dev that just joined us, we stalled for a while because of the lack of developers (our main guy got a new job recently) so i'm trying to do some community building around it
| |
15:03 | * alkisg has just finished a minimal lts.conf parser in python | |
15:03 | <vagrantc> hmmmm.... i'm tempted to do all sorts of crazy things.
| |
15:03 | <Gadi> vagrantc: maybe we can just do: cat /proc/sys/kernel/hostname > ${rootmnt}/etc/hostname
| |
15:03 | in the initscript
| |
15:03 | <vagrantc> Gadi: maybe.
| |
15:04 | <Lns> alkisg: why not add #lns to your chanlist and maybe we can throw some ideas back and forth?
| |
15:04 | <Gadi> instead of reverting
| |
15:04 | since the initramfs hook writes to /proc
| |
15:04 | <alkisg> Lns, sure....
| |
15:05 | <vagrantc> Gadi: initramfs hook writes to proc?
| |
15:05 | <Gadi> echo "$HOSTNAME" > /proc/sys/kernel/hostname
| |
15:05 | yup
| |
15:06 | <vagrantc> hmmm.
| |
15:07 | Gadi: drop writing /etc/hostname from the initramfs?
| |
15:08 | i really want to enable writeable dirs from the initramfs...
| |
15:08 | <Gadi> well, we can write it twice
| |
15:08 | for now
| |
15:08 | <vagrantc> in fact... the initramfs code doesn't even need to support it. i could just run it chrooted from the initramfs.
| |
15:09 | keeps the initramfs simple...
| |
15:09 | tarbo has joined #ltsp | |
15:09 | <Gadi> so just add another nfs-bottom script that chroots and does the bind-mount thing?
| |
15:09 | <vagrantc> yeah!
| |
15:10 | <Gadi> makes too much sense
| |
15:10 | Q-FUNK has joined #ltsp | |
15:10 | <Gadi> it'll never work
| |
15:10 | :)
| |
15:10 | <Q-FUNK> ah. familiar faces.
| |
15:10 | <Gadi> Q-FUNK: !! wow
| |
15:10 | ltns
| |
15:10 | <Q-FUNK> indeed
| |
15:10 | <vagrantc> Gadi: and i could just source ltsp-init-common for the function.
| |
15:10 | <Q-FUNK> vagrantc: congrats on the DD.
| |
15:11 | <vagrantc> Q-FUNK: thanks :)
| |
15:11 | if i had known years ago i
| |
15:12 | d get so many "congrats"
| |
15:12 | i would have wrapped it up like *that*
| |
15:12 | :)
| |
15:12 | <Q-FUNK> does anyone still have any GX2 hardware they could test what's in GIT with before we release the tarball? stgraber? Gadi?
| |
15:12 | <vagrantc> all it means is i have more opportunity to do more work.
| |
15:12 | <Q-FUNK> exactly
| |
15:13 | and opportunity is what I always missed at Debian, hence why my motivation to stay involved there has pretty much vanished.
| |
15:15 | tarbo has quit IRC | |
15:21 | <vagrantc> it just stalled my application till it was ridiculous i didn't wrap it up... :)
| |
15:31 | tarbo has joined #ltsp | |
15:37 | tarbo has quit IRC | |
15:40 | bobby_C has quit IRC | |
15:47 | <Q-FUNK> well, here, they back-peddled and even refused me DM, simply because I never got around completing Tasks in NM.
| |
15:49 | <vagrantc> ah, no good.
| |
15:50 | <alincoln> Gadi: yep, that ldm problem was my mistake. sorry you can't get those 5 minutes back. :D
| |
15:51 | <vagrantc> Gadi: i should have tried mounting from the initramfs years ago. it was on my TODO list for ages... but this is so simple and works like a charm.
| |
15:51 | <Q-FUNK> not to mention some people getting all personal over it, prompting DAM to declare that at least he's not gonna support giving me DM if some people have issues -
| |
15:51 | be they unsubstanciated and stated along the spineless lines of "well, I don't like his attitude and if anyone wants to know why, send me a private message."
| |
15:53 | <Gadi> alincoln: cool
| |
15:53 | vagrantc: does it fix ur localdev issues at the same time?
| |
15:53 | Q-FUNK: I have the hardware but prolly not the time :( - I will try my best
| |
15:54 | <Q-FUNK> Gadi: alright. thanks!
| |
15:54 | tarbo has joined #ltsp | |
15:54 | <vagrantc> Gadi: oooh... i didn't check.
| |
15:58 | talntid has joined #ltsp | |
16:01 | tarbo has quit IRC | |
16:01 | <vagrantc> Gadi: *sigh* no dice.
| |
16:02 | * vagrantc tries another idea along those lines | |
16:03 | mgariepy has quit IRC | |
16:04 | <talntid> Is there any way to make the video refresh from the server go... faster? :)
| |
16:04 | so, for example, if I wanted to watch a video on the client, it would be less choppy
| |
16:04 | <vagrantc> run as a local app.
| |
16:05 | !localapps
| |
16:05 | <ltspbot> vagrantc: "localapps" :: to access a tutorial on setting up localapps on jaunty, see https://help.ubuntu.com/community/UbuntuLTSP/LTSPLocalAppsJaunty
| |
16:06 | <alkisg> For anyone interested, here's a small lts.conf reader in python: http://ltsp.pastebin.com/m77deb64d
| |
16:06 | I'm using it to get e.g. the HOSTNAME that corresponds to a specific mac address entry, because getltscfg doesn't have a --mac-address option
| |
16:06 | <vagrantc> alkisg: -n doesn't work?
| |
16:06 | <talntid> I have read about localapps..
| |
16:06 | <rjune> !g
| |
16:06 | <ltspbot> rjune: "g" :: Gadi!!!!!!!!!!!!!!!!!!!!!!!!
| |
16:07 | <vagrantc> Gadi: *sigh* for some reason... it just ain't there.
| |
16:07 | <alkisg> vagrantc: -n == specify a hostname, I want to specify the mac address and _get_ the hostname...
| |
16:08 | Urm
| |
16:08 | Can I pass a mac address as the hostname? :O
| |
16:08 | <vagrantc> alkisg: i thought it treats hostname, mac address, ip address all the same.
| |
16:08 | alkisg: it's just taking a string
| |
16:09 | * alkisg wasted an hour for nothing :D | |
16:09 | <vagrantc> alkisg: well, at least you didn't waste more hours :)
| |
16:09 | mikkel has quit IRC | |
16:10 | <vagrantc> alkisg: suppose we should update the docs and/or help output
| |
16:10 | <alkisg> Maybe... at least the man page
| |
16:10 | Anyway, I'll leave it up to johnny to create a php-based lts.conf-ng :P
| |
16:11 | <vagrantc> i've definitely been thinking i'd like more hooks into configuration that what getltscfg and lts.conf can provide ...
| |
16:12 | i'd like the option to detect certain criteria such as ram and processor speed and conditionally set LTSP_FATCLIENT, for example...
| |
16:14 | <alkisg> From the initramfs: wget http://server?mac=this&ram=that ...
| |
16:14 | https, even
| |
16:14 | <vagrantc> i'm thinking some run-parts hooks into ltsp_config
| |
16:14 | tarbo has joined #ltsp | |
16:14 | <vagrantc> ltsp_config.d
| |
16:16 | it would take a little performance hit to check for the presence of the directory... but not much.
| |
16:17 | and give a lot of flexibility.
| |
16:22 | tarbo has quit IRC | |
16:24 | Q-FUNK has quit IRC | |
16:25 | vvinet has quit IRC | |
16:36 | tarbo has joined #ltsp | |
16:37 | etyack has quit IRC | |
16:43 | tarbo has quit IRC | |
16:45 | Lns has quit IRC | |
16:55 | japerry has joined #ltsp | |
16:57 | tarbo has joined #ltsp | |
17:02 | moldy has joined #ltsp | |
17:05 | vvinet has joined #ltsp | |
17:05 | tarbo has quit IRC | |
17:20 | tarbo has joined #ltsp | |
17:21 | talntid has quit IRC | |
17:26 | alkisg has quit IRC | |
17:28 | tarbo has quit IRC | |
17:34 | korcan has quit IRC | |
18:01 | arevamp has joined #ltsp | |
18:02 | <Gadi> vagrantc: ping
| |
18:03 | * vagrantc waves | |
18:04 | * vagrantc hits Gadi with a ping-pong ball | |
18:04 | <Gadi> vagrantc: you know you still have bind_unmounts in ltsp-setup, right?
| |
18:05 | (not really sure how the magic works, only that its there)
| |
18:05 | <vagrantc> Gadi: i was just looking at that
| |
18:05 | Gadi: i don't think it'll break... and other distros are still using it.
| |
18:06 | <Gadi> why is it called later?
| |
18:06 | it seems like it just cleans up tmpdirs
| |
18:07 | <vagrantc> it's probably a relic from some very old code
| |
18:07 | <Gadi> well, it should prolly be merged with bind_mounts
| |
18:08 | just clean up the tmpdirs when you're finished using them
| |
18:08 | tarbo has joined #ltsp | |
18:09 | <vagrantc> the tmpfs_copy_dir was used to copy the debconf database into ram so that i could use it to generate an XF86Config/xorg.conf with xdebconfiguration
| |
18:09 | xdebconfigurator
| |
18:09 | so it needed to happen later.
| |
18:09 | <Gadi> but, if you have a writable space, why do you need the tempdir?
| |
18:10 | <vagrantc> because it took up too much ram to leave it around.
| |
18:10 | so we'd clean it
| |
18:10 | it can probably be removed entirely...
| |
18:10 | <Gadi> oh
| |
18:11 | well, code's definitely getting cleaner
| |
18:12 | * Gadi looks forward to stgraber's next bootchart | |
18:12 | <Gadi> :)
| |
18:14 | <vagrantc> the way i handle the bind mounts is a little ugly... i almost want to code copy the bind_mounts function out of ltsp-init-common so i don't need all that cruft.
| |
18:14 | tarbo has quit IRC | |
18:15 | <vagrantc> in fact, i could ditch ltsp-setup.defaults and just use lts.conf...
| |
18:16 | ltsp_config.d opens so many doors....
| |
18:16 | <Gadi> heh - well, I'll leave u to it
| |
18:16 | have fun
| |
18:16 | :)
| |
18:17 | Gadi has left #ltsp | |
18:25 | <johnny> vagrantc, i use it
| |
18:25 | so be careful when doing anything to the bind mounts code
| |
18:25 | my code is almost the same as yours .. except slightly gentooified
| |
18:26 | <vagrantc> johnny: yeah, i've been looking at the other distros that use it and trying not to do y'all wrong :)
| |
18:27 | johnny: i'm moving almost all of the bind mounting code for Debian (and Ubuntu, should anyone deviate from the defaults) into a separate script that gets called from the initramfs... though it actually resides in the chroot.
| |
18:29 | tarbo has joined #ltsp | |
18:29 | sbalneav has quit IRC | |
18:34 | ltspbot has joined #ltsp | |
18:34 | sbalneav has joined #ltsp | |
18:36 | ogra has quit IRC | |
18:36 | tarbo has quit IRC | |
18:40 | staffencasa has quit IRC | |
18:41 | ogra has joined #ltsp | |
18:48 | <vagrantc> figure ltsp 5.2 is time for a few changes that have been on my TODO list for a long time...
| |
18:48 | <sbalneav> vagrantc: Do tell!
| |
18:49 | tarbo has joined #ltsp | |
18:51 | <vagrantc> sbalneav: today's commit log is part of it ...
| |
18:52 | etyack has joined #ltsp | |
18:52 | <vagrantc> sbalneav: i'm not ready to abandon read-only / ... but i moved the writeable tmpfs bind mount stuff so that it can be called from the initramfs (although it's still stored in the chroot)
| |
18:53 | <johnny> hmm.. i can't do that in gentoo until we have a sane initramfs system
| |
18:53 | <vagrantc> the crazy tarball to stdout method i felt was best to have the full suite utilities available.
| |
18:53 | <johnny> i'm gonna see if i can convince knipwin to use dracut
| |
18:53 | <vagrantc> johnny: living without an initrd is... painful.
| |
18:54 | <johnny> well we have one.. it's just the generator is painful
| |
18:54 | the semi official one that is..
| |
18:54 | <vagrantc> sure... to the point where you're dealing with ltsp without it?
| |
18:54 | <johnny> sure.. it pivots asap
| |
18:55 | it's not really pluggable
| |
18:55 | <vagrantc> sbalneav: and a really simple commit that gives huge flexibility to setting ltsp variables: ltsp_config.d
| |
18:55 | <johnny> it also loads all these modules serially.. so a default boot takes waay too long :(
| |
18:55 | tarbo has quit IRC | |
18:58 | <vagrantc> sbalneav: and the bind mount directories get their configuration from lts.conf values now...
| |
18:59 | these all seem like small things... but they really add up to a lot :)
| |
19:00 | stgraber: i just added an ltsp_config.d structure... might make sense to just include hooks for ltsp-cluster into that instead of special casing it...
| |
19:04 | lucascoala has joined #ltsp | |
19:07 | <sbalneav> Cool
| |
19:07 | ogra has quit IRC | |
19:07 | <vagrantc> ltsp-trunk is looking rather nice ...
| |
19:07 | * vagrantc gives it a whirl | |
19:09 | shawnp0wers has joined #ltsp | |
19:09 | shawnp0wers has joined #ltsp | |
19:10 | tarbo has joined #ltsp | |
19:11 | ogra has joined #ltsp | |
19:14 | <ogra> now thats a laptop boot as it should be: http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png
| |
19:18 | rjune has quit IRC | |
19:18 | tarbo has quit IRC | |
19:31 | tarbo has joined #ltsp | |
19:31 | <vagrantc> sbalneav: so your cdpinger syslogging is definitely useful!
| |
19:32 | sbalneav: the first thing i'm noticing is ...
| |
19:33 | sbalneav: it's attempting to mount it about once every 3 seconds...
| |
19:33 | no mount shows, however.
| |
19:33 | Feb 1 17:33:22 ltsp20 /usr/sbin/cdpinger[1085]: Disk detected. Mounting
| |
19:33 | <sbalneav> Hm.
| |
19:37 | <vagrantc> i'll put some hooks into ltspfs_entry to see if it actually gets called...
| |
19:38 | tarbo has quit IRC | |
19:38 | HardDisk has quit IRC | |
19:39 | alexqwesa_ has joined #ltsp | |
19:41 | alexqwesa has quit IRC | |
19:42 | <vagrantc> so cdpinger is not even calling ltspfs_entry...
| |
19:43 | i'll give the same setup a whirl with NBD+aufs
| |
19:44 | HardDisk has joined #ltsp | |
19:44 | <vagrantc> i wonder if the syntax on g_spawn* has changed or something...
| |
19:52 | tarbo has joined #ltsp | |
20:00 | tarbo has quit IRC | |
20:13 | tarbo has joined #ltsp | |
20:20 | tarbo has quit IRC | |
20:25 | lucascoala has quit IRC | |
20:26 | <vagrantc> sbalneav: i still haven't tested on real hardware... maybe it's a qemu bug.
| |
20:29 | lucascoala has joined #ltsp | |
20:34 | tarbo has joined #ltsp | |
20:41 | lucascoala has quit IRC | |
20:42 | tarbo has quit IRC | |
20:54 | tarbo has joined #ltsp | |
21:01 | tarbo has quit IRC | |
21:08 | avena has quit IRC | |
21:08 | ogra has quit IRC | |
21:16 | <stgraber> vagrantc: did you find what was the issue with nbd-proxy in your setup ?
| |
21:16 | tarbo has joined #ltsp | |
21:16 | <vagrantc> stgraber: it was ldm-trunk/rc.d/I01-nbd-checkupdate
| |
21:17 | stgraber: i haven't tried with newer ldm than 2.0.52 ... but am in the process of building them all right now
| |
21:17 | <stgraber> vagrantc: yeah, it was slightly broken, I should have fixed it though
| |
21:17 | <vagrantc> stgraber: the way you fixed it will it work with plain NBD and nbd-proxy?
| |
21:18 | hopefully, that is :)
| |
21:18 | <stgraber> vagrantc: at least it seems to work here (but I still don't get why it's not killing nbd-client correctly when I do a nbd-client -d ... I'd love to get rid of that kill -9 ...)
| |
21:18 | vagrantc: yeah, it's supposed to be (at least I hope I thought of that ;))
| |
21:23 | tarbo has quit IRC | |
21:24 | <vagrantc> stgraber: i don't know if ubuntu uses sendsigs anymore, but the patch i just committed will allow it to shut down properly without killing nbd-client/nbd-proxy.
| |
21:25 | stgraber: oh!
| |
21:25 | stgraber: i haven't had any luck with nbd-proxy from trunk.
| |
21:25 | stgraber: 5.1.99 works reasonably well
| |
21:29 | <stgraber> vagrantc: any idea what's failling with current trunk ?
| |
21:29 | <vagrantc> stgraber: it blocks indefinitely immediately after initramfs
| |
21:30 | <stgraber> vagrantc: any error in the syslog on the server side ?
| |
21:30 | <vagrantc> eventually it starts spitting out messages saying process foo has blocked for 120 seconds or more...
| |
21:30 | nope
| |
21:31 | <stgraber> I'm updating -trunk with what I currently have in the dev branch at the office, it's supposed to be more stable though it didn't go through extensive testing yet and I'm not sure about performance either
| |
21:31 | <sbalneav> vagrantc: Ok, mr. hotshot-debian-uploader, here's a good one for you...
| |
21:31 | I've got a single shell script, an possibly a man page.
| |
21:31 | <vagrantc> heh
| |
21:32 | <sbalneav> got an example of how to do packaging for that?
| |
21:32 | Oh, wait
| |
21:32 | heh
| |
21:32 | think I may have one myself :)
| |
21:32 | <vagrantc> sbalneav: ltsp-docs is probably not too far
| |
21:32 | <stgraber> vagrantc: pushed
| |
21:33 | <vagrantc> sbalneav: it just makes use of debhelper 7, which figures nearly everything out automatically.
| |
21:34 | <stgraber> vagrantc: http://pastebin.com/f36fba9a1 <-- use that if you want to do a very quick test build of nbd-proxy, then push to /usr/sbin/ and rebuild the initramfs + ltsp-update-kernel
| |
21:34 | <vagrantc> sbalneav: though you'd probably have to put the shell script in debian/foo.install and manpage in debian/foo.manpages
| |
21:37 | tarbo has joined #ltsp | |
21:39 | <vagrantc> stgraber: nah, quick tests usually seem to burn me more often than help :)
| |
21:39 | i use a different build environment anyways, so it's just easier to do a standard build for me...
| |
21:44 | tarbo has quit IRC | |
21:57 | tarbo has joined #ltsp | |
21:58 | <stgraber> what happened to ltsp-setup.default ?
| |
21:58 | * vagrantc notes that ltspfs has an order of magnitude less commits than either ltsp or ldm | |
21:59 | <vagrantc> stgraber: i killed it :)
| |
21:59 | <stgraber> I just got a snapshot build failure because of it being missing ;)
| |
21:59 | vagrantc: it's no longer used at all ?
| |
21:59 | <vagrantc> stgraber: shouldn't need it anymore ... all it had was the read-write variables for read-only root filesystems
| |
21:59 | <stgraber> ok, dropping it from the packaging then ;)
| |
22:00 | <vagrantc> stgraber: and i moved all that into ltsp-bindmounts, which is called from the initramfs
| |
22:00 | and if you do need writeable dirs mounted, you can configure it in lts.conf
| |
22:00 | * vagrantc hides from the documentation gods | |
22:01 | <vagrantc> stgraber: i did enough tinkering that it's probably good to read through the diffs a bit and nudging packaging appropriately :)
| |
22:02 | <stgraber> vagrantc: yeah, I usually do a big "bzr st" before an actual release to check if I missed something
| |
22:02 | though my snapshot build script doesn't really care ;) all it does is a new tarball, set the revision in the changelog and dput that to LP ;)
| |
22:02 | <vagrantc> stgraber: runs automated, or just when you tell it to?
| |
22:03 | <stgraber> just when I tell it
| |
22:03 | <vagrantc> would be kind of interested to have automated daily builds or some such
| |
22:03 | <stgraber> I could make it fully automated though looking at the number of commit we get at the moment, I'm not sure I want to spam LP that much :)
| |
22:04 | <vagrantc> i wasn't thinking of something with automated uploads...
| |
22:04 | tarbo has quit IRC | |
22:04 | <vagrantc> but just to check if it builds
| |
22:13 | shawnp0wers has quit IRC | |
22:16 | cyberorg has quit IRC | |
22:18 | tarbo has joined #ltsp | |
22:26 | tarbo has quit IRC | |
22:37 | <stgraber> /tmp/mkinitramfs_uojkRk/scripts/nfs-bottom/ltsp: 12: chroot: not found
| |
22:37 | vagrantc: ^
| |
22:39 | vagrantc: that's when doing a update-initramfs -u on r1619
| |
22:39 | tarbo has joined #ltsp | |
22:39 | <vagrantc> stgraber: you've got some weird bug in initramfs-tools that executes the scripts meant to be run at run-time.
| |
22:41 | <stgraber> vagrantc: well, it doens't usually do that ;)
| |
22:41 | <vagrantc> well, sure... i added some code that chroot's from the initramfs.
| |
22:41 | but alkisg was saying he had some sort of problem like that when writing some other code...
| |
22:42 | stgraber: and it has to use /usr/bin/test, otherwise it doesn't work right... maybe could copy the test binary into the initramfs to work better...
| |
22:43 | i.e. dash, bash, busybox test builtins behave differently.
| |
22:44 | <stgraber> + /tmp/mkinitramfs_cbSpqA/scripts/nfs-bottom/ltsp prereqs
| |
22:44 | might be an issue
| |
22:44 | (I just +x ed update-initramfs to see what it was doing)
| |
22:45 | <vagrantc> ah.
| |
22:49 | tarbo has quit IRC | |
22:50 | cyberorg has joined #ltsp | |
22:59 | tarbo has joined #ltsp | |
23:05 | tarbo has quit IRC | |
23:16 | loathing has quit IRC | |
23:20 | tarbo has joined #ltsp | |
23:23 | loathing has joined #ltsp | |
23:27 | tarbo has quit IRC | |
23:28 | <vagrantc> stgraber: looks like it's hanging.
| |
23:28 | stgraber: nbd-proxy
| |
23:39 | hrm... didn't test the new code with plain NBD
| |
23:40 | tarbo has joined #ltsp | |
23:43 | Selveste1 has quit IRC | |
23:47 | <vagrantc> ah, i figured out what was wrong...
| |
23:47 | tarbo has quit IRC | |
23:47 | johnny has left #ltsp | |
23:48 | johnny has joined #ltsp | |
23:49 | <vagrantc> or not
| |
23:55 | * vagrantc doesn't hold breath | |
23:56 | <vagrantc> it's because the nbd-client initramfs-tools hooks uses the "local" script... so it doesn't handle the ltsp hooks.
| |
23:58 | ok, now i got the right hooks... but i got a "short read" error.
| |