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


Channel log from 1 February 2010   (all times are UTC)

00:05tarbo has joined #ltsp
00:12tarbo has quit IRC
00:13shogunx has joined #ltsp
00:15shamino has quit IRC
00:18arevamp has quit IRC
00:25artista_frustrad has joined #ltsp
00:30Sarten-X has quit IRC
00:31Sarten-X has joined #ltsp
00:32artista_frustrad has quit IRC
00:46vagrantc has joined #ltsp
00:51tarbo has joined #ltsp
00:56* vagrantc looks for gadi
01:00tarbo has quit IRC
01:00
<panthera>
vagrantc: congratulations, btw ;)
01:00
<vagrantc>
panthera: thanks :)
01:11tarbo has joined #ltsp
01:14alkisg has quit IRC
01:15alkisg has joined #ltsp
01:18tarbo has quit IRC
01:31tarbo has joined #ltsp
01:37tarbo has quit IRC
01:49Kicer86 has joined #ltsp
01:51tarbo has joined #ltsp
01:58tarbo has quit IRC
02:03alkisg has quit IRC
02:04alkisg has joined #ltsp
02:19vagrantc has quit IRC
02:47sene has quit IRC
02:51lucascoala has quit IRC
02:55mikkel has joined #ltsp
02:57artista_frustrad has joined #ltsp
02:58ogra has quit IRC
03:01gnunux has joined #ltsp
03:02artista_frustrad has quit IRC
03:14artista_frustrad has joined #ltsp
03:19artista_frustrad has quit IRC
03:41lucascoala has joined #ltsp
03:42waranha has joined #ltsp
03:42klausade has joined #ltsp
03:47waranha has quit IRC
03:50ball has joined #ltsp
03:51LumberCartel 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:55sepski 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:06lucascoala has quit IRC
04:07
<LumberCartel>
Thanks ball.
04:11Kicer86 has quit IRC
04:12LumberCartel 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:03hersonls 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:10Faithful has joined #ltsp
05:16
<ball>
appiah: what made you think he only wanted one app?
05:35
<appiah>
ah nevermind
05:41shamino has joined #ltsp
05:43artista_frustrad has joined #ltsp
05:48artista_frustrad has quit IRC
05:52wwx has quit IRC
05:54wwx has joined #ltsp
05:57otavio has quit IRC
05:57otavio has joined #ltsp
05:57otavio has joined #ltsp
06:01artista_frustrad has joined #ltsp
06:06artista_frustrad has quit IRC
06:18pmatulis has joined #ltsp
06:21hersonls has quit IRC
06:23hersonls has joined #ltsp
06:28scottmaccal has joined #ltsp
06:45etyack has joined #ltsp
06:48ball has quit IRC
06:49vvinet has quit IRC
07:06evilx_ has quit IRC
07:08arevamp has joined #ltsp
07:11evilx has joined #ltsp
07:13hersonls has quit IRC
07:22hersonls has joined #ltsp
07:26alexqwesa has quit IRC
07:27vvinet has joined #ltsp
07:41monteslu has joined #ltsp
07:50alexqwesa has joined #ltsp
08:07yanu has quit IRC
08:13Gadi has joined #ltsp
08:27mikkel 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:43etyack 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:44etyack 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:05litlebuda has joined #ltsp
09:05mikkel 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:10litlebuda 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:34gentgeen__ 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:36gentgeen__ has joined #ltsp
09:54bobby_C has joined #ltsp
09:54The_Code has joined #ltsp
10:01bobby_C has quit IRC
10:16arevamp has quit IRC
10:21rjune has joined #ltsp
10:31litlebuda has joined #ltsp
10:39johnny has joined #ltsp
10:40silvergti 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:43artista_frustrad has joined #ltsp
10:43
<silvergti>
any tip?
10:47gnunux is now known as Guest15610
10:49artista_frustrad has quit IRC
10:53Egyptian[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:56Egyptian[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:02litlebuda 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:10Ahmuck has joined #ltsp
11:10cliebow 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:29tarbo has joined #ltsp
11:29yanu has joined #ltsp
11:29yanu 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:35tarbo has quit IRC
11:36arreyder has quit IRC
11:36arreyder has joined #ltsp
11:36otavio has quit IRC
11:37otavio has joined #ltsp
11:44spectra 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:49tarbo has joined #ltsp
11:51
<silvergti>
now it's working...
11:51
can't use space between the = and the value
11:52hersonls 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:55tarbo has quit IRC
11:55
<silvergti>
and its using sis_agp
11:55akuepker 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:01otavio has quit IRC
12:01otavio 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:07monteslu 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:09tarbo 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:16tarbo has quit IRC
12:17monteslu 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:30tarbo has joined #ltsp
12:30
<silvergti>
xorg-driver-sis671: /usr/lib/xorg/modules/drivers/sis671_drv.so
12:30Lns 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:33The_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:37tarbo 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:39otavio has quit IRC
12:39otavio 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:52tarbo has joined #ltsp
12:52
<Gadi>
silvergti: what is the make/model of the monitor?
12:52ogra 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:59tarbo 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:06ogra has quit IRC
13:10
<silvergti>
http://ltsp.pastebin.com/m5c8069ce
13:11cliebow has quit IRC
13:11cliebow 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:15tarbo 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:20ogra 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:22tarbo 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:30artista_frustrad has joined #ltsp
13:30cliebow has quit IRC
13:30
<Gadi>
silvergti: the value "none" is a reserved one
13:30cliebow 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:34artista_frustrad has quit IRC
13:35
<alkisg>
OK, removing those add_modules then
13:35
Ty
13:37tarbo has joined #ltsp
13:38cliebow has quit IRC
13:38cliebow has joined #ltsp
13:42cliebow has quit IRC
13:42cliebow has joined #ltsp
13:42akuepker has quit IRC
13:44tarbo has quit IRC
13:44vagrantc has joined #ltsp
13:45akuepker 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:47etyack 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:47artista_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:53artista_frustrad has quit IRC
13:58silvergti has left #ltsp
14:01tarbo 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:05artista_frustrad has joined #ltsp
14:07tarbo has quit IRC
14:09artista_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:16etyack 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:24tarbo 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:27spectra 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:30tarbo 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:33pmatulis has quit IRC
14:33
<vagrantc>
alkisg: normally the only ssh keys on a thin client are known_hosts entries for the servers.
14:34avena 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:35avena 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:42mgariepy 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:46tarbo 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:53tarbo 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:56stgraber has quit IRC
14:56stgraber 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:56bobby_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:02scottmaccal 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:09tarbo 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:10Q-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:15tarbo has quit IRC
15:21
<vagrantc>
it just stalled my application till it was ridiculous i didn't wrap it up... :)
15:31tarbo has joined #ltsp
15:37tarbo has quit IRC
15:40bobby_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:54tarbo has joined #ltsp
15:54
<vagrantc>
Gadi: oooh... i didn't check.
15:58talntid has joined #ltsp
16:01tarbo has quit IRC
16:01
<vagrantc>
Gadi: *sigh* no dice.
16:02* vagrantc tries another idea along those lines
16:03mgariepy 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:09mikkel 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:14tarbo 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:22tarbo has quit IRC
16:24Q-FUNK has quit IRC
16:25vvinet has quit IRC
16:36tarbo has joined #ltsp
16:37etyack has quit IRC
16:43tarbo has quit IRC
16:45Lns has quit IRC
16:55japerry has joined #ltsp
16:57tarbo has joined #ltsp
17:02moldy has joined #ltsp
17:05vvinet has joined #ltsp
17:05tarbo has quit IRC
17:20tarbo has joined #ltsp
17:21talntid has quit IRC
17:26alkisg has quit IRC
17:28tarbo has quit IRC
17:34korcan has quit IRC
18:01arevamp 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:08tarbo 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:14tarbo 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:17Gadi 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:29tarbo has joined #ltsp
18:29sbalneav has quit IRC
18:34ltspbot has joined #ltsp
18:34sbalneav has joined #ltsp
18:36ogra has quit IRC
18:36tarbo has quit IRC
18:40staffencasa has quit IRC
18:41ogra 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:49tarbo has joined #ltsp
18:51
<vagrantc>
sbalneav: today's commit log is part of it ...
18:52etyack 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:55tarbo 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:04lucascoala has joined #ltsp
19:07
<sbalneav>
Cool
19:07ogra has quit IRC
19:07
<vagrantc>
ltsp-trunk is looking rather nice ...
19:07* vagrantc gives it a whirl
19:09shawnp0wers has joined #ltsp
19:09shawnp0wers has joined #ltsp
19:10tarbo has joined #ltsp
19:11ogra 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:18rjune has quit IRC
19:18tarbo has quit IRC
19:31tarbo 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:38tarbo has quit IRC
19:38HardDisk has quit IRC
19:39alexqwesa_ has joined #ltsp
19:41alexqwesa 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:44HardDisk has joined #ltsp
19:44
<vagrantc>
i wonder if the syntax on g_spawn* has changed or something...
19:52tarbo has joined #ltsp
20:00tarbo has quit IRC
20:13tarbo has joined #ltsp
20:20tarbo has quit IRC
20:25lucascoala has quit IRC
20:26
<vagrantc>
sbalneav: i still haven't tested on real hardware... maybe it's a qemu bug.
20:29lucascoala has joined #ltsp
20:34tarbo has joined #ltsp
20:41lucascoala has quit IRC
20:42tarbo has quit IRC
20:54tarbo has joined #ltsp
21:01tarbo has quit IRC
21:08avena has quit IRC
21:08ogra has quit IRC
21:16
<stgraber>
vagrantc: did you find what was the issue with nbd-proxy in your setup ?
21:16tarbo 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:23tarbo 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:37tarbo 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:44tarbo has quit IRC
21:57tarbo 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:04tarbo has quit IRC
22:04
<vagrantc>
but just to check if it builds
22:13shawnp0wers has quit IRC
22:16cyberorg has quit IRC
22:18tarbo has joined #ltsp
22:26tarbo 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:39tarbo 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:49tarbo has quit IRC
22:50cyberorg has joined #ltsp
22:59tarbo has joined #ltsp
23:05tarbo has quit IRC
23:16loathing has quit IRC
23:20tarbo has joined #ltsp
23:23loathing has joined #ltsp
23:27tarbo 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:40tarbo has joined #ltsp
23:43Selveste1 has quit IRC
23:47
<vagrantc>
ah, i figured out what was wrong...
23:47tarbo has quit IRC
23:47johnny has left #ltsp
23:48johnny 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.