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


Channel log from 18 March 2008   (all times are UTC)

00:00abadger1999 has quit IRC
00:10cyberorg has joined #ltsp
00:13tux_440volt has quit IRC
00:27slashdotfx has joined #ltsp
00:27tux_440volt has joined #ltsp
01:06tux_440volt has quit IRC
01:49chup has joined #ltsp
01:51chupa has quit IRC
02:10deavi1 has joined #ltsp
02:41Pascal_1 has joined #ltsp
02:44
<Pascal_1>
hello
02:46
i come back with the same question i put the log of my problem here : http://pastebin.fr/1223. it seems that the diconnection from (thin client ldm ) doesnt works fine. anybody could help me ?
02:49
is it a similar bug as this : https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/131259 ?
02:50captain_magnus_ has joined #ltsp
02:50captain_magnus has quit IRC
03:01
<Pascal_1>
it seems to be the same problem as this : http://marc.info/?l=ltsp-discuss&m=120079141117871&w=2
03:04
is there a way to see ldm logs ?
03:11
salut !
03:20daya has quit IRC
03:23
<Pascal_1>
anybody to help me ?
03:31subir has quit IRC
03:32subir has joined #ltsp
03:45
<daduke>
Pascal_1: if you're on Ubuntu, ogra is the man to talk to.
03:45
<Pascal_1>
i'm on debian etch
03:46
<daduke>
Pascal_1: then I might help, I'm on etch too. Are you using the alioth ldm backports?
03:47makghosh has joined #ltsp
03:51
<Pascal_1>
what you mean by alioth ldm ?
03:51
i made an install of debian etch then install ltsp-server and build client
03:52
<daduke>
Pascal_1: http://pkg-ltsp.alioth.debian.org/debian/ the stock etch ltsp/ldm packages are horribly outdated. here's my install notes: https://nic.phys.ethz.ch/readme/233
03:55Faithful has joined #ltsp
03:58
<Pascal_1>
daduke, thanks a lot for your links
03:59
why it's better to use these package ?
03:59
the normal install doesnt works for debian ?
04:02emilk_ has joined #ltsp
04:02
<daduke>
Pascal_1: errr because they work? and the stock ones don't? I think that's what you've just realized yourself..
04:02
<Pascal_1>
ok ;-)
04:02
i try this
04:02
thanks a lot again
04:02
i told you the result
04:03
<daduke>
Pascal_1: you're welcome. We run this setup in production here. we've had some problems in the past, but when we reported back to vagrantc, bugs were closed very quickly
04:06
<Pascal_1>
when you say "#make sure it's from alioth!!!" what is the best way to be sure ?
04:06
and why you install ltspfs ?
04:08
<daduke>
Pascal_1: well check the version with aptitude show
04:08
Pascal_1: ltspfs is for local USB devices
04:08
<Pascal_1>
i use apt-get it's the same ?
04:08
ok
04:08
<daduke>
Pascal_1: yup
04:13chupa has joined #ltsp
04:14chup has quit IRC
04:17
<Pascal_1>
daduke, when i do apt-cache show ltsp-server it show me the 2 version how to be sure that apt-get install install the good one ?
04:18
<daduke>
Pascal_1: dpkg -l ltsp* | egrep ^ii ; dpkg --root=/opt/ltsp/i386 -l ltsp* ldm | egrep ^ii
04:19
<Pascal_1>
i remove ltsp
04:19
and the build client :-(
04:19
<daduke>
Pascal_1: aptitude install will install the newer one
04:19
<Pascal_1>
aptitude seems to be better than apt-get
04:19
<daduke>
Pascal_1: indeedy
04:21
<Pascal_1>
this version dont use nfs now ?
04:23
hmm i try all
04:23
with your tuto
04:33tux_440volt has joined #ltsp
04:37
<Pascal_1>
daduke, it doesnt works anymore it's the same thing as my pastebin
04:38tux_440volt has joined #ltsp
04:43basanta has joined #ltsp
04:50
<daduke>
Pascal_1: and you're > 5.0.23 now?
04:55emilk__ has joined #ltsp
05:01
<Pascal_1>
Version : 5.0.40~bzr20080214-1~40.etch.0
05:06
<daduke>
Pascal_1: looks good. no clue about your prob then.
05:06
<Pascal_1>
your tuto is from a fresh install of debian ?
05:09
<daduke>
Pascal_1: no, it's ontop of our big installation, LDAP users and stuff
05:11emilk_ has quit IRC
05:15mnemoc has quit IRC
05:15mnemoc has joined #ltsp
05:20
<Pascal_1>
daduke, you saw my problem ? it's only at the disconnection that there is a probleù
05:22
daduke, did you disable avahi on your debian ?
05:22
i dont know if it's the problem but i disabled it
05:32mikkel has joined #ltsp
05:35subir has quit IRC
05:38basanta has quit IRC
06:07latarsky has left #ltsp
06:09Pascal_2 has joined #ltsp
06:12Faithful has quit IRC
06:12Pascal_1 has quit IRC
06:12Pascal_2 is now known as Pascal_1
06:12ogra_cmpc has quit IRC
06:13ogra_cmpc has joined #ltsp
06:14ogra__ has joined #ltsp
06:17daya has joined #ltsp
06:24tux_440volt has quit IRC
06:28daya is now known as nep
06:28nep is now known as daya
06:30ogra_ has quit IRC
06:51tux_440volt has joined #ltsp
06:52tux_440volt has quit IRC
06:52daya has quit IRC
06:56tux_440volt has joined #ltsp
06:56TelnetManta has joined #ltsp
07:05mhterres has joined #ltsp
07:07Guaraldo has joined #ltsp
07:15otavio has joined #ltsp
07:20makghosh has quit IRC
07:22Guaraldo has quit IRC
07:23Guaraldo has joined #ltsp
07:38slidesinger has joined #ltsp
07:41jammcq has quit IRC
07:48tux_440volt has quit IRC
08:08DonSilver has joined #ltsp
08:09
<Pascal_1>
re
08:11deavi1 has quit IRC
08:12
<Pascal_1>
i made a new install of my debian etch followed by an install of ltsp with the backports i've got always the same problem. i notice that when i disconnect i've got 2 process still alive : "gnome-power-manager" and "nm-applet --sm-disable"
08:14
<daduke>
Pascal_1: no clue, sorry. Never seen anything like this. wait for vagrantc, he's the man.
08:15
<Pascal_1>
ok
08:15
i dont understand i reinstall everything :-(
08:16
<daduke>
Pascal_1: what if you use another session instead of gnome?
08:16
<Pascal_1>
what you mean how i do that ?
08:16
<daduke>
Pascal_1: well change your session when logging in
08:16gentgeen__ has quit IRC
08:17
<Pascal_1>
in the login screen i 've those choice default gnome or failsafe xterm
08:17
i try with failsafe xterme ?
08:17
i try with failsafe xterm ?
08:17
<daduke>
Pascal_1: sure.
08:25cliebow_ has joined #ltsp
08:25
<cliebow_>
!seen sbalneav
08:25
<ltspbot>
cliebow_: sbalneav was last seen in #ltsp 20 hours, 5 minutes, and 56 seconds ago: <sbalneav> Ah, there he is
08:25
<Pascal_1>
daduke, the same :-(
08:28
<daduke>
Pascal_1: no clue then
08:29slidesinger has quit IRC
08:30jammcq has joined #ltsp
08:30slidesinger has joined #ltsp
08:32slidesinger has joined #ltsp
08:49elisboa has joined #ltsp
09:19
<mhterres>
hello jammcq
09:19
:-)
09:19
<jammcq>
mhterres: hey
09:20
<mhterres>
Jim, did you decide about what are you will talk in fisl ?
09:21
I want to put your lecture in our program as soon as possible :-)
09:22sep has quit IRC
09:24
<daduke>
!seen vagrantc
09:24
<ltspbot>
daduke: vagrantc was last seen in #ltsp 15 hours, 30 minutes, and 36 seconds ago: <vagrantc> nice.
09:24
<daduke>
!seen ogra_cmpc
09:24
<ltspbot>
daduke: ogra_cmpc was last seen in #ltsp 13 hours, 31 minutes, and 24 seconds ago: <ogra_cmpc> johnny, i didnt find the time to care for finishing the move yet ....
09:27elisboa has quit IRC
09:27elisboa has joined #ltsp
09:31vagrantc has joined #ltsp
09:32
<daduke>
vagrantc: my man!
09:32* vagrantc is a free spirit
09:33
<daduke>
vagrantc: sorry, my bad ;) what's the status of rdesktop w/ LTSP? in 4.x once could say screen02=rdesktop or something, but this doesn't seem to work in 5?
09:34chup has joined #ltsp
09:35
<ogra_cmpc>
daduke, should work if you install rdesktop manually (we do that by default in ubuntu since hardy)
09:35
the screen.d script is there, the default chroot just doesnt have the rdesktop binary
09:36chupa has quit IRC
09:36
<daduke>
ogra_cmpc: thing is, as soon as I put screen02=rdesktop in lts.conf, X won't start any more
09:36
<ogra_cmpc>
hmm, i thought scott had r4ewritten the rdesktop screen script in gutsy
09:37
<daduke>
ogra_cmpc: with or w/o screen01=startx, doesn't matter
09:37
ogra_cmpc: and I'm on etch
09:37
<ogra_cmpc>
but using the backports
09:37
which usually have such fixes
09:37
<daduke>
ogra_cmpc: true
09:38
<ogra_cmpc>
gutsy is old enough that i belive vagrant pulled the fix in
09:38
<Pascal_1>
vagrantc, could you help me about this problem : http://pastebin.fr/1223. i made the test which daduke told me to do (install ltsp from backport) but i've got the same problem
09:39
<vagrantc>
daduke: you have rdesktop installed?
09:39
daduke: dpkg --root=/opt/ltsp/i386 -l rdesktop | egrep ^ii
09:40
<daduke>
vagrantc: well not yet, I took the line out of lts.conf as soon as X didn't start any more.
09:40
<vagrantc>
i don't think i've added rdesktop as a dependency yet, due to some RC bugs
09:40
<ltsppbot>
"ogra" pasted "rdesktop screen script in hardy" (50 lines) at http://pastebot.ltsp.org/475
09:40
<ogra_cmpc>
yours should look like that
09:40
<daduke>
vagrantc: now I've got it.
09:41
<vagrantc>
i'll consider adding it by default in the next upload
09:42
daduke: another think, only use SCREEN_07-SCREEN_12
09:42
daduke: unless you disable things running on tty1-6
09:42
<daduke>
vagrantc, ogra_cmpc: the rdesktop script is the same
09:43
vagrantc: ahh that was probably it, thanks! didn't think about it.
09:43* daduke slaps his head
09:43
<ogra_cmpc>
might be that you need to set RDP_SERVER
09:43
(as the script header says)
09:44emilk__ has quit IRC
09:44
<Pascal_1>
vagrantc, could you help me ?
09:44
<vagrantc>
Pascal_1: in a few minutes maybe
09:44
<Pascal_1>
ok sorry
09:45
<daduke>
vagrantc, ogra_cmpc: thanks guys, I'll give it a try. Now we can try to help Pascal_1...
09:45
<Pascal_1>
;-)
09:46
<vagrantc>
i've been trying to get a new upload of ltsp to debian for the last 4 days, and other things keep getting me distracted
09:46* ogra_cmpc IS PREPARING A BETA RELEASE ATM
09:46
<ogra_cmpc>
OOPS
09:46
sorry
09:47
<daduke>
argghh. I just added SCREEN_07 = rdesktop in lts.conf, and X just loops, no ldm
09:47
yeah right, should be 8. I need some sleep. sorry
09:47
<ogra_cmpc>
use 08 and set 07 =ldm
09:47
<vagrantc>
07 should work
09:47
<ogra_cmpc>
then you can switch
09:48
<vagrantc>
nothing magic about 07
09:48
<ogra_cmpc>
right, that too
09:48
hmm
09:48
<vagrantc>
daduke: does it work without any SCREEN_* set?
09:49
daduke: i mean, does ldm start
09:49
<ogra_cmpc>
is RDP_SERVER set ?
09:49* vagrantc wants to confirm if X works at all
09:50
<daduke>
no, not yet, but adding SCREEN_08 = rdesktop breaks X. I added SCREEN_07 = ldm now... one moment...
09:50
<ogra_cmpc>
(rdesktop wont start without server address)
09:50
<daduke>
agreed, but it shouldn't break X, now should it?
09:51
<ogra_cmpc>
it will respawn endlessly
09:52mccann has joined #ltsp
09:52
<daduke>
ok, now I got ldm again. The Windoze server is not yet ready, but it was trying to start it. thanks, it's fine for now.
09:52
<vagrantc>
could someone with an ubuntu gutsy/hardy install paste a /proc/mounts to the pastebot ?
09:53chup has quit IRC
09:53
<vagrantc>
from a thin client
09:53chup has joined #ltsp
09:53
<cliebow_>
vagrantc:hang a sec..
09:54
<vagrantc>
i'm trying to improve the SERVER setting autodetection
09:54
<bjorn>
!paste
09:54
<ltspbot>
bjorn: Error: "paste" is not a valid command.
09:54
<cliebow_>
vagrantc, havnt got anything handy for a thinclient
09:55
<bjorn>
i have one, but can't remember how to use pastebot
09:55
<vagrantc>
!pastebot
09:55
<ltspbot>
vagrantc: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
09:55
<cliebow_>
bjorn, pastebot.ltsp.org
09:55
heh
09:55
<ltsppbot>
"bjorn" pasted "vagrantc: /proc/mounts on gutsy thin client" (15 lines) at http://pastebot.ltsp.org/476
09:56milobit has joined #ltsp
09:56
<vagrantc>
bjorn: thanks!
10:16makghosh has joined #ltsp
10:18
<Pascal_1>
vagrantc, i've got to leave , could you help me tomorrow about my problem ?
10:25milobit has left #ltsp
10:29DonSilver has quit IRC
10:32K_O-Gnom has joined #ltsp
10:32
<vagrantc>
Pascal_1: maybe
10:33
Pascal_1: should be available during much of the day, and hopefully will get this ltsp upload out of the way today
10:33
hmmm...
10:33
now i just need to figure out how to use cut with null characters
10:34
or awk ... or something
10:34staffencasa has joined #ltsp
10:40gentgeen__ has joined #ltsp
10:55
<vagrantc>
ah, pgrep -f -l
10:55
perfect.
11:00tux_440volt has joined #ltsp
11:08prpplague has joined #ltsp
11:08
<prpplague>
jammcq: hey bud
11:09
<Guaraldo>
hey, jammcq!!!
11:21
<cliebow_>
dont know where the little guy is...
11:34
<jammcq>
hey prpplague
11:34
and Guaraldo
11:34
and cliebow_
11:34
<prpplague>
jammcq: whats cookin?
11:34
<jammcq>
same old thing
11:34
<prpplague>
ahh
11:34
jammcq: biz good then?
11:34
<jammcq>
you in TX ?
11:35
<prpplague>
jammcq: yea for over a year now
11:35
<jammcq>
yeah, biz is good and steady, which is more than an awful lot of people can say
11:35bobby_C has joined #ltsp
11:35
<jammcq>
family with you?
11:35
<prpplague>
jammcq: yea, finally got my wife's visa in july of last year, 3 years 8 months and 24 days after we first applied
11:35
<jammcq>
holy crap
11:35
that's our govt for you
11:36
<prpplague>
jammcq: yea, the current average for a US citizen to bring their foreign born spouse to the US is right at 28 months
11:39dubinsky has joined #LTSP
11:39dubinsky has left #LTSP
11:41
<prpplague>
<jammcq> yeah, biz is good and steady, which is more than an awful lot of people can say
11:41
jammcq: job market rough in your part of the country?
11:41
<jammcq>
yeah
11:41
well, high tech is doing ok
11:42
but others not doing so well
11:42
<prpplague>
ahh
11:44
<jammcq>
lunch time
11:44
see ya'll in a bit
11:49cdealer has joined #ltsp
11:51abadger1999 has joined #ltsp
11:51
<cdealer>
Good afternoon. Im having a problem with mouse handling on my ltsp server, my thinclients are having a dual click issue, every one click becomes two clicks. I dont know how to test and fix this. Can anyone give me some help ?
12:13mccann has quit IRC
12:14makghosh has quit IRC
12:22lns has quit IRC
12:23lns has joined #ltsp
12:29
<vagrantc>
anyone have a gutsy or hardy ltsp install they can test a change for me on?
12:33
or should i just go ahead and commit :)
12:43
egrep '^/dev/nbd.* / |^/dev/nbd.* /rofs ' /proc/mounts | awk '{print $1}'
12:43
i should be able to do that without egrep ... just awk
12:46indradg has joined #ltsp
12:48
<vagrantc>
awk '/^\/foo \/ / || /^\/foo \/rofs /{print}' /proc/mounts
12:50
<bjorn>
vagrantc: your egrep line prints "/dev/nbd0" on my gutsy client
12:51
<vagrantc>
bjorn: ok ... try pgrep -f -l /dev/nbd0 | awk '{print $3}'
12:53
<bjorn>
vagrantc: 192.168.1.2
12:53
<vagrantc>
bjorn: that's your server's ip address?
12:53
<bjorn>
vagrantc: yes
12:54
<vagrantc>
bjorn: excellent! thanks for your help :)
12:54spectra has joined #ltsp
12:54
<bjorn>
np
12:55
<vagrantc>
managed to reduce it from 9 calls to binaries down to 3, all while adding support for regular nbd root :)
12:57Pascal_2 has joined #ltsp
12:57
<Pascal_2>
hello
12:57* vagrantc waves
12:57chupa has joined #ltsp
12:57
<bjorn>
ignorant question: a friend says iscsi performs much better than NFS for his not-LTSP thin client. how does iscsi compare with nbd?
12:57mccann has joined #ltsp
12:58
<vagrantc>
bjorn: no idea. some have told me that iscsi is really inappropriate as a replacement for NFS or NBD ... but i'm not really familiar enough with iscsi to know.
12:58chup has quit IRC
12:59primeministerp has quit IRC
12:59
<Pascal_2>
vagrantc: have you seen my problem?
12:59
<vagrantc>
Pascal_2: please repeat it, starting with linux distro and release :)
13:00
<Pascal_2>
in fact i'm pascal_1 it's about the pastebin i post here (debian etch, the last version of ltsp from backports as daduke told me to install)
13:01
when i disconnect from thin client there is no log in auth.log and pam_mount doesnt umount samba share, also some time when i disconnect there is some process still alive
13:01
as i have not disconnected
13:01
sorry for my english
13:02
<vagrantc>
ah, i remember you mentioning this the other day
13:02
<Pascal_2>
yes
13:02
i've still the same problem even with the last version
13:02
<vagrantc>
ok.
13:02
i haven't really used pam_mount much ...
13:02
<Pascal_2>
and i dont know how to solve it i've no log information
13:02
<vagrantc>
Pascal_2: it's working fine with a regular ssh session?
13:02
<Pascal_2>
i think the problem is not really pam_mount
13:03
yes it works fine with ssh session
13:03
i see all the processus of connection/deconnection
13:03
in auth.log
13:03
but with ldm only connection
13:04
if you prefer we can see that tomorrow (tomorrow for me ) when i will be at works
13:04
for the moment i'm at home
13:04
this problem make me crasy ;-)
13:05
<ogra_cmpc>
vagrantc, do you plan to use all possbile variants of grep in the code ? grep ... pgrep ... egrep ...
13:05
<vagrantc>
Pascal_2: i'll test and see if i get disconnect messages in my etch ltsp environment
13:05
<Pascal_2>
ok
13:05
<vagrantc>
ogra_cmpc: i'm not fond of fgrep, really.
13:05
<Pascal_2>
thanks
13:05
<vagrantc>
ogra_cmpc: i habitually use egrep, even when grep will do
13:06
though i think egrep was needed
13:06
and pgrep rocks my world.
13:06
ogra_cmpc: i think the first i saw pgrep was in ltsp_config
13:06
<ogra_cmpc>
fgrep is fine to crawl through dict lists
13:07
<vagrantc>
ogra_cmpc: i'm quite pleased with that last commit. :)
13:08tux_440volt has quit IRC
13:09
<vagrantc>
the for loop is a little ugly ... *probably* don't need it ... but if you happen to have nbd-clients both on / and /rofs is on a different server ...
13:11
well, due to our aggregious security bug in ldm, lenny will finally be able to have a working ltsp install again :)
13:11
although, with ldm from december ...
13:12abadger1999 has quit IRC
13:13
<ogra_cmpc>
did you roll back or did it simply not enter yet ?
13:15
<vagrantc>
ogra_cmpc: backported the security patch and two other patches to get it in a working state.
13:16
ogra_cmpc: and nion from the testing-security-team just uploaded it.
13:16
ogra_cmpc: still waiting on slow buildd's and now a dependency on pango*
13:16
ogra_cmpc: for the unstable -> testing migration
13:16
<ogra_cmpc>
bah
13:17
am i wrong or can you do binary uploads in debian ?
13:18
you could just skip the buildd and build it yourself, no ?
13:28
<vagrantc>
if i had mips, mipsel, hppa and alpha hardware, yes.
13:29
i've got some mips hardware, but haven't gotten it working yet. ditto for mipsel. no idea on hppa ... *might* be able to find some alpha hardware.
13:29
<stgraber>
and I guess building using qemu's cpu emulation isn't allowed ? :)
13:29
<vagrantc>
stgraber: i *do* have qemu mips and mipsel environments, yes. :)
13:30
stgraber: i'm not sure if it's not allowed, or just discouraged.
13:30
but without hppa and alpha uploads, there's not much point in doing an upload on mips*
13:31
previously, it was only mips* that was blocking, and i was tempted.
13:33indradg_ has joined #ltsp
13:33cliebow_ has quit IRC
13:46abadger1999 has joined #ltsp
13:48
<cyberorg>
anyone thought of providing prebuilt images?
13:48prpplague has left #ltsp
13:49
<vagrantc>
cyberorg: been done. hasn't been much maintenance, though.
13:50
would be pretty easy, though.
13:50
<cyberorg>
vagrantc, i am planning to build one today, a rpm package with prebuilt image
13:50
<vagrantc>
use something like bittorrent ...
13:50
oh, a package with a pre-built image ?
13:50
yuk.
13:50
<jammcq>
bittorrent is only useful if LOTS of people are downloading the same image
13:50
<cyberorg>
vagrantc, haha, i can get users to install requirements with rpm
13:51
and provide it via 1-click
13:51
<vagrantc>
jammcq: indeed. and we could set up a package that updates the NBD image ... everyone using it could leave the torrent open ...
13:51
<cyberorg>
simpler than long instructions to install various packages required ltsp
13:51
<jammcq>
I'm thinking you need thousands of people downloading the same thing, to get any benefit
13:51
<vagrantc>
cyberorg: with network access, it wouldn't really be any different than with a package.
13:52indradg has quit IRC
13:52
<cyberorg>
i am not worried about distribution, i can put it up on opensuse build service, it gets mirrored all over
13:53* ogra_cmpc finds the ubuntu and debian instrucdtions quite short actually
13:53
<ogra_cmpc>
install two packages, run one command
13:53
<vagrantc>
jammcq: i get *much* faster downloads of CD images even when only connected to a small number (5-50) peers than i do off most mirrors.
13:54
<ogra_cmpc>
AND SINCE TODAY !!!!
13:54
<laga>
.oO(.. wonder why it doesn't work.. fire up wireshark.. take broken PXE implementations to the backyard..)
13:54
<ogra_cmpc>
select "install a LTSP server" from the modes menu of the ubuntu alternate installer
13:54
\o?
13:54
<cyberorg>
ogra_cmpc, install and set up xinetd, nbd server, dhcp server everything?
13:54
<ogra_cmpc>
cyberorg, yes
13:54
<laga>
ogra_cmpc: that didn't work before?
13:55
<ogra_cmpc>
laga, there was nothing in the UI, until this week you needed to preseed ltsp-client-builder/run=true
13:55
<cyberorg>
so i plan to provide click here <-- configure a file and run one command
13:55
<vagrantc>
configure a file? eeeew.
13:55
<cyberorg>
building of image not required
13:56
<laga>
ogra_cmpc: ah, nice.
13:56
<ogra_cmpc>
now you can just select it in the menu, wait 30min and have a running ubuntu ltsp server
13:56
<laga>
ogra_cmpc: i still gotta fix that for mythbuntu..
13:56
<ogra_cmpc>
you had the menu entry before me :)
13:56
in myth.
13:56
<laga>
yes
13:56
<cyberorg>
vagrantc, because we do not know network setup of the server, like which interface is serving internal network
13:56
<laga>
it just doesn't work properly ;)
13:57
<ogra_cmpc>
you should be able to just use the LTSP_CLIENT_BUILDER_OPTS variable i think
13:57
<Pascal_2>
vagrantc: just for info (i dont know if it's a usefull info) i use ldap authentication
13:57
<ogra_cmpc>
and preseed the extra options you need for the mythbuntu client
13:57
<cyberorg>
we have an autodetection that defaults to eth0
13:57
<laga>
ogra_cmpc: you could have told me before :) no, some of my magic is different from yours.. eg i don't want people to use two different networks
13:58
<ogra_cmpc>
cyberorg, why dont you know that ?
13:58
the interface with the default route is usually the outbound one
13:58
<cyberorg>
ogra_cmpc, because there could be more than two interfaces
13:58
yes we can rule out outbound
13:59
<ogra_cmpc>
laga, well, that should all be adjustable by options to ltsp-build-client, have a look at the ltsp-client-builder.postinst
14:00
cyberorg, and you can check if an interface is totally unconfigured ...
14:00
<laga>
ogra_cmpc: i don't see how options to ltsp-build-client affect the creation of the dhcpd.conf
14:00abadger1999 has quit IRC
14:00
<ogra_cmpc>
cyberorg, so in the case where tou have an outbound interface and a unconfigured spare one you can grab the spare one
14:00abadger1999 has joined #ltsp
14:01
<cyberorg>
ogra_cmpc, one of the servers we configured has 5 configured interfaces :)
14:01
<ogra_cmpc>
laga, oh, that
14:01
cyberorg, then list all unused ones and make the user select
14:01
<vagrantc>
the testing-security buildd network is pretty fast ... builds for hppa, amd64, mipsel, i386, ia64, mips and s390 within minutes of an upload.
14:01
<laga>
ogra_cmpc: i basically hacked ltsp-client-builder.postinst to do what i want.. now i need to debug it
14:02
<cyberorg>
ogra_cmpc, we don't list them yet, but user puts the SERVER_IP variable either through a GUI or edit a configuration file directly
14:05staffencasa has quit IRC
14:06primeministerp has joined #ltsp
14:11* cyberorg adds ogra_cmpc's suggestion to offer list of ip addresses to users
14:11
<ogra_cmpc>
??
14:12staffencasa has joined #ltsp
14:12
<ogra_cmpc>
when did i talk about ip addresses ?
14:12
<cyberorg>
SERVER_IP variable we use to configure everything
14:12
based on interfaces available
14:12
<ogra_cmpc>
i didnt talk about SERVER_IP
14:13
i talked about how to find the interface you want
14:13
which is in 90^ of the cases automatic if you document the issue that users should have two NICs for an out of the box install
14:13
*90%
14:15
<cyberorg>
ogra_cmpc, it is quite easy to list out all internal network facing ip addresses and let user select if more than one is available
14:15
<ogra_cmpc>
why would you do that ?
14:16* ogra_cmpc wouldnt scare his users like that
14:16
<cyberorg>
ogra_cmpc, so what do you do for servers with more than one internal facing interfaces?
14:16
<laga>
if users have more than one NIC, they shouldn't be scared..
14:17
<ogra_cmpc>
just pick a free network and configure it, why bother the user, as long as you dont break anything a good default setup that the user can change afterwards but that works right away is way better
14:18
cyberorg, i simply dont touch configured interfaces
14:18
i tell the user he has to configure himself if there is no spare one at all
14:19
<cyberorg>
that is what i am doing, asking user to fill in whatever IP he wants to use as server IP :)
14:19
<laga>
that might work when you install the distro, but if you just install the packages chances are that the desired interface is already configured. i dont see how telling the user to configure it themselves is less scary then giving them a list of available interfaces and doing some sed magic to dhcpd.conf
14:20
of course, you can still pick free interfaces and only ask when all of them are configured
14:20
<ogra_cmpc>
right
14:21
<cyberorg>
ogra_cmpc, there could be complex scenarios like server could be other than on which boot images are
14:21
<laga>
well
14:21
<ogra_cmpc>
cyberorg, there you wont be able to prevent the admion from doing setup work anywayu
14:21
<cyberorg>
one place to configure such things are useful too
14:21
<laga>
that's one scenario where the users gets to start vim ;)
14:22
<ogra_cmpc>
i'm talking about sane defaults, not about corner cases of people herding NICs in their servers :)
14:22
<cyberorg>
ogra_cmpc, you know what happens when geeks start on their servers :)
14:22
<ogra_cmpc>
most of the time you will find that your users have dedicated ltsp servers anyway ...
14:23* ogra_cmpc gives a sh*t on geeks ... i want a windows admin to be impressed by the ease of use if he installs an ubuntu ltsp server ... thats where we win
14:23
<cyberorg>
yup, true
14:23
<ogra_cmpc>
geeks know how to help themselves
14:24
<laga>
ogra_cmpc: the amount of whining i've seen wrt "boohoo, i'll go back to windows because this is too complicated" made me rethink that ;)
14:25
<cyberorg>
this is the reason i want to provide prebuilt packages
14:25
<ogra_cmpc>
i dont care if someone goes back, thats up to everyone as he likes ... but i want to convince people willing to try by ease of use and quality
14:27
<cyberorg>
i don't get the idea behind making everyone build their own image, it is almost like making everyone compile their own packages
14:32abadger1999 has quit IRC
14:34
<vagrantc>
cyberorg: well, would your distro be willing to ship a 50-150MB package that needs frequent updating?
14:34
every time one of the packages in the image needs an update, it would basically require updating the package ...
14:34
<cyberorg>
vagrantc, it can be available from online repo?
14:34
<vagrantc>
cyberorg: sure.
14:35
cyberorg: but that's not a package ...
14:35
as something entirely *within* the distro, there's no sane way to ship a pre-built image that i've seen.
14:36
<laga>
unsquashfs and then use the normal tools for mtainance?
14:36
maintenance*
14:36
<vagrantc>
you could do that ...
14:37
<ogra_cmpc>
thats what i plan to do if ltsp-image-shell is ready
14:37
<vagrantc>
although i'm not so fond of the whole squashfs thing
14:39
still, i think distributing images is best done outside the context of the distro itself ... could put up an infrastructure to download images for your distro
14:39
and include a package that handles the downloading
14:40
<cyberorg>
vagrantc, exactly my sentiments :)
14:43
<vagrantc>
it's actually easier to do with images than with chroots :)
14:44abadger1999 has joined #ltsp
14:44
<vagrantc>
though i must say, ext2 images are quite nice :)
14:44
allows for simple editing without rebuilding the whole thing :)
14:47
<warren>
https://www.redhat.com/mailman/listinfo/k12linux-devel-list
14:49
<ogra_cmpc>
warren, ?
14:49
<warren>
Just pointing it out
14:49* ogra_cmpc wonders what he wants to tell us
14:50
<ogra_cmpc>
thats a ML page ... any context ?
14:50
:)
14:50
<vagrantc>
with an empty archive :P
14:51
<ogra_cmpc>
aah ... why k12linux and not fedora-ltsp ?
14:51chupa has quit IRC
14:51Pascal_2 has quit IRC
14:51chupa has joined #ltsp
14:52
<warren>
ogra_cmpc, because people know the "K12*" brand
14:52
ogra_cmpc, and K12LTSP was a bad marketing name
14:53
<jammcq>
hmm, we kind of liked that name :)
14:54
<ogra_cmpc>
ah
14:54Topslack has quit IRC
14:55
<cyberorg>
i heard of k12 because of ltsp
14:55cdealer has quit IRC
14:55rjent has joined #ltsp
14:56
<warren>
You didn't hear that we're changing the name?
14:56
I've been broadcasting this since December
14:56
<jammcq>
hmm, what's the new name?
14:57* vagrantc chuckles
14:58
<warren>
jammcq, K12LTSP -> K12Linux
14:58
jammcq, LTSP is just one part of K12Linux
14:58
<jammcq>
I agree
15:04
<ogra_cmpc>
jammcq, http://people.ubuntu.com/~ogra/ltsp-install-ubuntu.png :D
15:05
<cyberorg>
ogra_cmpc, nice :)
15:07jhp has joined #ltsp
15:13
<rjent>
in dhcp how can I tell if netboot before lease? I want a given range for my thin clients and regular workstations I want another range. Thanks
15:15
<cyberorg>
115M /usr/src/packages/RPMS/noarch/kiwi-ltsp-prebuilt-0.3.14-1.noarch.rpm
15:17TelnetManta has quit IRC
15:17
<jammcq>
ogra_cmpc: waaay cool
15:18
warren: it seems that for branding purposes, you guys would have slid 'fedora' or 'redhat' into that name
15:18
'k12linux' seems pretty generic
15:20
<warren>
jammcq, our fedora branding people liked this
15:20
<jammcq>
hmm, ok
15:21
I guess it's their decision
15:21
<warren>
jammcq, "K12Linux" with Fedora logos
15:27
<jhp>
rjent: You could do 2 things, one is put the thin clients in a different vlan, and second is make sure you have all the MAC addresses of the thin client and give them a specific config through your dhcp server.
15:28
There is no way to tell a dhcp server to use a range for a specific set of clients in a different way.
15:28
At least as far as I know
15:28
<Guaraldo>
jhp there is another way...
15:29
<jhp>
tell me
15:29
<Guaraldo>
rjent: But you will need some dhcp magic...
15:31
jhp: It's a very peculiar way... Just work in specific situation...
15:32
<jhp>
I can't think of a way at the moment but I'm allways in the mood to see something new.
15:32
;-)
15:33jammcq has quit IRC
15:33
<Guaraldo>
jhp: If your hardware is very similar in each network...
15:33
<vagrantc>
vendor-class-identifiers might be able to be used to distinguish between different dhcp requests
15:34
<Guaraldo>
vagrantc: Exactly!
15:34
<jhp>
Ah, ok
15:34
<vagrantc>
your dhcp server should be able to tell the difference between PXE, Etherboot and other dhcp clients ... unless your client is evil.
15:34
<jhp>
That might indeed do the trick.
15:35* vagrantc doesn't know how to distinguish ipmasq ...
15:35
<Guaraldo>
but if you have many diferent vendors and it is difused on both networks, can be very dificult...
15:35
<jhp>
It should be able to see the difference, but can I assign a different pool based on this information?
15:36
<Guaraldo>
jhp: Sure you can...
15:36
<vagrantc>
well, if you can identify all the vendor-class-id's for your thin-clients, and just give everything else a different range
15:36
<jhp>
ok
15:36
<vagrantc>
hmmm...
15:36
well, i haven't actually tried it with range declarations, though
15:36
<Guaraldo>
Here we have a network to computers and other to IP-phones...
15:37
<rjent>
jhp: I have about 200 on flat layer2 so vlan is no good they are all over wan
15:37
<jhp>
I could use this trick in one of my networks.
15:37
<Guaraldo>
jhp: Them both in the same fisical network...
15:38
<rjent>
Guaraldo: I am just going to forgo and dump all possible names in /etc/hosts and go on. thanks for the feedback
15:38
<jhp>
'/etc/hosts is evil, but ok.
15:39
<Guaraldo>
rjent: Try vendor-class-identifiers...
15:39
<jhp>
I need some help on a little thing myself as well.
15:39
<Guaraldo>
rjent: Or use an internal DNS
15:39
<jhp>
I have a ltsp server setup to provision thin clients with a X Server with rdesktop to connect to windows terminal servers.
15:40
<rjent>
Guaraldo: I have an internal DNS with ip listed to name
15:40
<jhp>
Works very well, but now one group noticed that there are floppy disks in those old PC's and they want to be able to use thm .
15:40
<Guaraldo>
jhp: Its simple...
15:41
<jhp>
I have been testing with it and I am this far that the rdesktop session shows the drive icon in the explorer.
15:41
But when the people put a floppy in the drive, nothing happens.
15:41
<rjent>
Guaraldo: So I could use if substring ( option vendor-class-identifier, 0, 9) = "PXEClient" then give iprange inside there?
15:41
<jhp>
I would suspect that the floppy gets mounted, but that does not happen.
15:41
<Guaraldo>
jhp: LTSP 4.2?
15:41
<jhp>
yes
15:42
<Guaraldo>
jhp: Look this: http://downloads.sourceforge.net/symbiont/LTSP-RDP-localdev.tgz?modtime=1156842738&big_mirror=0
15:43
jhp: this package puts ltspfs in the chroot to rdp works well...
15:44
rjent: yes...
15:44
<rjent>
Guaraldo: very interesting. Yes I can do that then. Thanks
15:46
<jhp>
Guaraldo: So I install this package in my ltsp tree and after that everything should work?
15:46
Do I also have to do some things in the config of the thin clients?
15:46
<Guaraldo>
rjent: Remember to use the shared networks too...
15:46
rjent: Or dhcp will not work...
15:47
<jhp>
I have the LOCAL_STORAGE=Y and the -r disk option of rdesktop.
15:48
<Guaraldo>
jhp: RCFILE_01 = lbussd_bg
15:48
jhp: LOCAL_STORAGE = Y
15:48
jhp: LTSPFSD_OPTIONS = "-a"
15:49
<vagrantc>
rjent: which version of LTSP ? you may also have to figure out what the dhcp client from the initramfs uses to give the same range.
15:49
<Guaraldo>
jhp: And if you have made any changes on rdesktop screen script, you will have to do it again...
15:50
<jhp>
Guaraldo: No, I did not change anything there yet.
15:50mikkel has quit IRC
15:50
<Guaraldo>
jhp: So install this package and be happy... :-D
15:50
<jhp>
thanks a lot
15:50
Will test it tomorrow
15:51chupa has quit IRC
15:51
<Guaraldo>
jhp: Thanks Gadi... this package is his...
15:51chupa has joined #ltsp
15:52
<jhp>
I don't see anyone name Gadi
15:53
Guaraldo: but just to make sure, if I install this, and configure it properly, someone just has to insert a floppy and he will be able to write to it from his thin client session?
15:53
<Guaraldo>
jhp: Sometimes hi is over here... :-D
15:54
Yep...
15:54
jhp: On \\thinclient\drives
15:54
<jhp>
Does it use mtools to write to the disk?
15:54
Or does it actually mount and unmount
15:54
??
15:54
<Guaraldo>
jhp: No... it uses ltspfs
15:55
<jhp>
ok, I will test it tomorrow and will let you know.
15:55
<Guaraldo>
jhp: Look... on server you will find an "Shared Drive" (the floppy of the thinclient)...
15:55
<jhp>
You probebly made me very happy
15:56
I allready see that but when someone writes data to it it ends up in /tmp/drives/My_Floppy
15:56
<Guaraldo>
jhp: Do it... Tell me if you get it working... :-D
15:57
<jhp>
But there is nothing mounted there so that doesn't help them.
15:57
<Guaraldo>
jhp: Becouse it is not using ltspfs... it is not mounted
15:57
<jhp>
ok
15:57
<Guaraldo>
I'll be back soon...
15:57
<jhp>
thanks a lot
15:57
seeya
15:59* vagrantc notices that upgrading an etch chroot doesn't work very well
15:59
<vagrantc>
RyanRyan52: did you ever get around to trying a clean install with ldm ?
16:01mhterres has quit IRC
16:18Topslack has joined #ltsp
16:29chup has joined #ltsp
16:31chupa has quit IRC
16:34slidesinger has quit IRC
16:42
<vagrantc>
Pascal_1: i can confirm that i get no logout messages in auth.log on etch (or sid)
16:43
Pascal_1: please file a bug report against the ldm package: http://www.debian.org/Bugs/Reporting
17:00Guaraldo has left #ltsp
17:04
<vagrantc>
warren, ogra_cmpc, cyberorg, johnny: i'm thinking the patch with $CHROOTEXEC is fixing the symptom, not really the problem.
17:05
the symptom is that there's something wrong with their PATH ...
17:05
er, the problem
17:05
<johnny>
wrong?
17:05
<vagrantc>
the symptom is that chroot isn't found
17:05
<warren>
vagrantc, our distro is just that way
17:05
vagrantc, we purposefully make the path of root different from non-root
17:05
<vagrantc>
i'd like to make a counter-proposal
17:05
<warren>
and sudo wont give you root's PATH
17:06
<vagrantc>
i guess, the reason it seems like a problem is if chroot is missing, something else may be missing too
17:06
if we have to go around setting variables with every possible binary ... the code will get ugly.
17:07
(maybe that's a bit of hyperbole, but hoppefully you get the idea)
17:07
<warren>
Yes
17:07
but what other choice do we have?
17:07
we can't depend on chroot being in the path
17:07
<vagrantc>
error out if chroot is not in path.
17:07
or add /usr/sbin (or wherever chroot is found to be) to the PATH
17:09
if [ -z "$(which chroot)" ]; then find_path_to_chroot ... PATH="$PATH:$(dirname /path/to/chroot)" ?
17:09
something like that?
17:09
<johnny>
would people want to be able to use linux32 or setarch in general with chroot tho?
17:10
<vagrantc>
johnny: i'm not familiar with those tools ... what do they do?
17:10
<johnny>
they make uname -m lie
17:10deavid has quit IRC
17:10
<johnny>
within the command you run it as
17:10
<vagrantc>
oh, we need more lies, yes.
17:11
:)
17:11
LTSP has been far too honest.
17:11
<johnny>
right now i'm building a kernel for 32bit
17:11
and i have to tell it to pretend that i'm using x86
17:11
<warren>
vagrantc, I'm thinking about redefining PATH
17:12
vagrantc, I suspect redefining path is evil because different distros have different paths
17:12
vagrantc, which chroot to find a path to add to PATH doesn't work
17:12* vagrantc wonders just how different
17:12
<warren>
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
17:12
?
17:12
<johnny>
on gobo it'd be wildly different, but they have symlinks to pretend they are normal
17:12
<warren>
gobo?
17:12
<vagrantc>
warren: no, not using which to find the path... which is just a test to find if it's *not* in the path.
17:13
<johnny>
a distro that makes the paths more similiar to mac osx
17:13
ie: not standard fhs
17:13
what about mtsp? :)
17:13
lol
17:13
<vagrantc>
warren: and if it's not in the path, figure out where chroot is (using the existing $CHROOTEXEC code as a start), and then add that dir to PATH ...
17:13
<johnny>
mac osx terminal server project.. :)
17:13
<warren>
vagrantc, sounds like adding complicated code for a simple problem
17:14
<vagrantc>
warren: it's simpler code that you've already added
17:14
<warren>
vagrantc, I also don't like programmatically finding a path to add that happens to contain chroot because of other commands that could be in there.
17:14
<vagrantc> if [ -z "$(which chroot)" ]; then find_path_to_chroot ... PATH="$PATH:$(dirname /path/to/chroot)" ?
17:14
<vagrantc>
right
17:14
<warren>
find_path_to_chroot ... requires a lot more than what I wrote thus far
17:15
<johnny>
i think being abme to do linux32 might justify keeping warren's patch
17:15
<vagrantc>
warren: well, it requires more than what you wrote thus far to support more than what you support right now :P
17:15
<johnny>
especially since i can cross compile for ppc on this box
17:15
or any other arch
17:15
so i can set whatever i want and the chroot will use it
17:15
<vagrantc>
warren: otherwise, it requires nearly the same amount of code.
17:16
johnny: using linux32 instead of chroot ?
17:16
<johnny>
linux32 chroot
17:16
CHROOTEXEC="linux32 chroot"
17:16
<vagrantc>
ah.
17:16
<johnny>
or CHROOTEXEC="setarch ppc chroot"
17:16adac2 has joined #ltsp
17:16
<vagrantc>
well, i have no intention of using $CHROOTEXEC in any of the debian plugins until i see a real reason to do so.
17:17
<warren>
vagrantc, actually, you have no need to.
17:17
<johnny>
well you're not a source based distro :)
17:17
so you don't have to :)
17:17
building a cross compiler here is really easy
17:17
<vagrantc>
johnny: also, to use CHROOTEXEC ... you have to remove the "unset CHROOTEXEC" at the top of the plugin.
17:17
<johnny>
crossdev -t i686-pc-linux-gnu
17:18
and bam.. cross compiler..
17:18
<warren>
johnny, hm... CHROOTEXEC="/usr/bin/setarch $ARCH /path/to/chroot" might not be a bad idea.
17:18captain_magnus_ is now known as captain_magnus
17:18
<adac2>
hi. wanted to know if a dhcp server on the ltsp server is required...or if it is possible to run the dhcp on the hardware router?
17:18
<johnny>
adac2, as long as it supports the proper dhcp options
17:19
adac2, in debian/ubuntu they have ltsp-server and ltsp-server-standalone
17:19
standalone includes the dhcp server and friends
17:19
but if you already have one, you just use ltsp-server
17:20
<adac2>
johnny: ah I see. but is ltsp possible with any jkind of hardware router?
17:20
<johnny>
it depends on what dhcp server software they use , and whether it can be customized to pass the options ltsp needs
17:20
like option 17
17:20
but to do this requires knowing more about dhcp and converting the ltsp dhcp configs you find on the net
17:20
to whatever it is
17:21
ok.. work time.. i'll be back online in a half hour or so
17:21
depends on if i can find parking
17:21
<adac2>
johnny: ;)
17:21
<vagrantc>
adac2: it is likely more trouble than it's worth.
17:21
<adac2>
vagrantc: you mean using hardware router as dhcp server?
17:21
<vagrantc>
adac2: yes.
17:22
adac2: if you're very familiar with dhcp configuration and you have a router that even gives you the possibility of configuring it... you might be ok.
17:23
adac2: i.e. knowing which dhcp option numbers correspond to which dhcp options that are usually used ...
17:23
<adac2>
vagrantc: yea..but the thing is I don't have running that ltsp server all the time...and if its off then no dhcp server is running...and this would make my mom unhappy
17:23
;)
17:23bobby_C has quit IRC
17:23
<vagrantc>
adac2: set up a secondd network card on your ltsp server and plug your clients into that.
17:24
<adac2>
vagrantc: yea that would solve the problem!
17:24
<vagrantc>
that's a much simpler way to go.
17:24
<adac2>
vagrantc: may the simpliest
17:25
<vagrantc>
warren: i'd almost prefer a chroot wrapper function ... maybe called ltsp_chroot to avoid namespace conflicts ... and then $CHROOTEXEC could interpret that ...
17:26
er, the function use $CHROOTEXEC
17:26
<warren>
vagrantc, one problem is the ARCH variables set by common and debian plugins do not match the standard glibc arch names.
17:27
<vagrantc>
warren: i make no use of the common plugin for ARCH handling.
17:27
<warren>
vagrantc, I like the idea of ltsp_chroot, but I don't see why is $CHROOTEXEC still needed?
17:27
vagrantc, oh right.
17:27
the common plugin for ARCH handling is not useful to anybody
17:27
not very common, is it?
17:27
<adac2>
vagrantc: i was just wondering if it wouldn't be much easier for all people if for this pxe booting wouldn't depend on that extra packets a dhcp server has to send...cause of course most, well nearly all people I know use cheap routers which are not supporting extra things for pxe
17:27
<vagrantc>
warren: $CHROOTEXEC would be needed to avoid checking for the paths every single time, as well as to be able to do tricks like johnny was talking about
17:27
<laga>
adac2: and how would that work?
17:28
<adac2>
laga: well that is the question
17:28
<vagrantc>
warren: debian uses it's own namespace for architectures... so it's not at all useful to debian derivatives ... we'd have to map between the two and i'd rather just use my own.
17:28
warren: although it *seems* like other distros actually might be able to use the common plugin.
17:28
<warren>
vagrantc, I would rather use ltsp_chroot within plugins where chrooting is desired, and $CHROOTEXEC is set once at the beginning.
17:29
I can't
17:29
<adac2>
laga: you think something like that would be impossible to implement?
17:29
<vagrantc>
warren: i mean, fix the common plugin to work for other distros.
17:29
warren: since other distros (gentoo, fedora, suse) seem to basically use the glibc arch names ...
17:30
<warren>
vagrantc, that's only possible if the common plugin uses glibc standard arch names, and distros non-common plugins need to translate it on demand.
17:30
<vagrantc>
warren: i think the common plugin should use glibc standard arch names, but i *don't know* what other distros use well enough to know if it can be done.
17:31
warren: worst case, it's a beginning example for distros to use ...
17:31
or just go ahead and delete it.
17:31
<warren>
the Fedora plugin might be a good base to replace the common
17:31
<vagrantc>
i *Really* don't care.
17:31
<warren>
uses glibc standard arch
17:31
and installs i386 on x86_64 servers by default
17:31
<vagrantc>
exactly.
17:32
<adac2>
laga: I mean it is ok if the server would send those extra packets somehow...but not acting the same time as a dhcp server
17:32
<warren>
although, the other RPM distros don't have a basearch of i386
17:32
they might have i486 or i586 because of misguidedness
17:32
<adac2>
laga: I guess this is impossible,hu?
17:33
<warren>
(turns out i386 instruction binaries with i686 optimizations are faster on i686 than i586 instructions)
17:33
<vagrantc>
well, i know debian is so weird it just doesn't make sense to use the glibc stuff.
17:33
<laga>
adac2: you can use alternate DHCP ports, you can also set up a second, non-authoritative DHCP server.. the first approach requires etherboot, the second one most likely will too
17:33
<vagrantc>
anyways ... gotta run.
17:33
warren: you were ok with an ltsp_chroot function ?
17:34
<warren>
vagrantc, depends on hte implementation
17:34
<vagrantc>
warren: well, sure :P
17:34
<warren>
I'm against redefining PATH
17:34mnemoc has quit IRC
17:34
<vagrantc>
alias chroot=false
17:35
<adac2>
larga: non-authoritative...that means the dhcp server has no function...only broadcasts its ltsp (pxe) capabilities?
17:35
<vagrantc>
warren: i'm thinking something like what you have now, but as a function, setting CHROOTEXEC if not already defined.
17:35
<warren>
vagrantc, OK, I'll work on an implementation
17:35
<vagrantc>
warren: cool.
17:36
warren: the other idea would be to implement it as an actual script
17:36
<warren>
vagrantc, this means that CHROOTEXEC needs to be first defined during 001-set-arch
17:37
vagrantc, because that's where you get the glibc arch name that would be needed within it
17:37
<vagrantc>
gotta run!
17:37
warren: thanks for the time and consideration for it :)
17:37vagrantc has quit IRC
17:38mccann_ has joined #ltsp
17:43mnemoc has joined #ltsp
17:57johnny_ has joined #ltsp
18:00stgraber_ has joined #ltsp
18:02stgraber_ has quit IRC
18:04abadger1999 has quit IRC
18:09slipttees has joined #ltsp
18:10
<slipttees>
hi all
18:10
:D
18:20staffencasa has quit IRC
18:23abadger1999 has joined #ltsp
18:25mccann has quit IRC
18:26slipttees has quit IRC
18:31
<johnny_>
did i miss anything?
18:46
<RyanRyan52>
vagrantc: It did not work...
18:51abadger1999 has quit IRC
18:52cliebow has joined #ltsp
18:52abadger1999 has joined #ltsp
19:11chupa has joined #ltsp
19:13chup has quit IRC
19:32abadger1999 has quit IRC
19:41adac2 has quit IRC
19:44cliebow has quit IRC
19:45gentgeen__ has quit IRC
20:04vagrantc has joined #ltsp
20:22jammcq has joined #ltsp
20:36
<warren>
vagrantc, grrr
20:36
vagrantc, the proposed change to create a ltsp_chroot wrapper that also does setarch
20:36
vagrantc, it wouldn't be very "common" easily
20:37
vagrantc, different distros do entering in a different way
20:37
vagrantc, (arch specific chroot entering)
20:37
vagrantc, I rather not take away absolute control of how the plugin developer wants to enter
20:44
<vagrantc>
warren: how about you just let them define it using the CHROOTEXEC variable ?
20:45
<warren>
vagrantc, this is proving to be too much of a distraction for me right now
20:45
vagrantc, I rather rip it out of common and just hardcode my own paths
20:45
<vagrantc>
warren: i'll work on it
20:46
<warren>
vagrantc, and to be honest, we have much more important things to work on
20:46
<vagrantc>
indeed.
20:46
<warren>
there's no way I'm going to get all the LTSP5 features working in Fedora 9 alone
20:46
<vagrantc>
when's fedora 9 release?
20:46
<warren>
I posted a detailed explanation of the current status a week ago, with a list of simple things people can do
20:46
not a single person stepped up from Fedora
20:46
I have maybe another 2 weeks of development
20:47
<loather-work>
april something or other
20:47slashdot1x has joined #ltsp
20:47
<vagrantc>
warren: yeah, don't get distracted in stupid things like this :)
20:48
a shame nobody's stepped up...
20:48
<warren>
yes
20:48
I now know how Eric Harrison has felt these past years
20:48
Everyone is interested in consuming but nobody wants to help
20:48
I even went out of my way to SPELL OUT how they can help in really simple terms
20:48
and nothing
20:48
<loather-work>
29 April 2008
20:48
20:48
Fedora 9 final release
20:48
<dberkholz>
warren: it was a nice description though =)
20:49
<loather-work>
the feature freeze was last week
20:49
<warren>
technically the features are in now
20:49
they're just broken
20:49
=)
20:49
<vagrantc>
that's one way to do it :)
20:49
<loather-work>
haha :) well you have until 08 april to make them work
20:50
i should be ready to beta it coming up in the next few weeks
20:50
<warren>
it is also great to see that my careful effort to upstream 100% of what I do made it way easier for suse to jump to where I am.
20:50
<vagrantc>
indeed
20:51
<warren>
while NOTHING of what they did prior went upstream
20:51
<vagrantc>
i've long been feeling like getting more distros involved would be key to getting it into decent shape
20:51
<warren>
I'm not angry. This is completely typical of FOSS, so I'm not surprised.
20:52mccann has joined #ltsp
20:52
<vagrantc>
well, i certainly had the fortune of having most of the implementation done for debian ... just had to make a few changes to get it working
20:52
though i sometimes had to fight to get those changes
20:53
but i pretty much jumped right into code cleanup and feature development
20:55slashdotfx has quit IRC
21:02
<warren>
yeah
21:20dtrask has joined #ltsp
22:12johnny_ has quit IRC
22:25abadger1999 has joined #ltsp
22:26dtrask has quit IRC
22:34DonSilver has joined #ltsp
22:35DonGnom has joined #ltsp
22:36K_O-Gnom has quit IRC
22:36DonGnom is now known as K_O-Gnom
22:52DonSilver has quit IRC
23:01mccann has quit IRC
23:11tux_440volt has joined #ltsp
23:27subir has joined #ltsp
23:32daya has joined #ltsp
23:35basanta has joined #ltsp
23:37K_O-Gnom has quit IRC
23:44tux_440volt has quit IRC
23:49
<warren>
vagrantc, ping
23:50
vagrantc, your checkin fails if chroot isn't in path
23:50
<vagrantc>
warren: hrm.
23:50
<warren>
vagrantc, 2> /dev/null ?
23:51
<vagrantc>
what fails?
23:51
<warren>
+ for c in $(which chroot) /usr/sbin/chroot /usr/bin/chroot; do
23:51
<vagrantc>
yes, but what breaks?
23:51
<warren>
If chroot isn't in path, ugly stuff to stderr?
23:51
<vagrantc>
but does it fail?
23:51
<warren>
hmm
23:51
I guess not
23:52
<vagrantc>
but sure, 2>/dev/null would probably be good.
23:52
<warren>
vagrantc, I'll redirect the error to /dev/null and pushing another chnage as well
23:52
<vagrantc>
warren: make sure you've got my recent commits ... i've made more since then
23:52
<warren>
I pulled everything as of now
23:53
<vagrantc>
cool.
23:53
i guess i broke my "i always test" rule. :)
23:54
<warren>
you didn't test it on fedora with sudo!
23:54
it wouldn't have printed an ugly error on your distro =)
23:54
<johnny>
warren , quick fedora question if you know..
23:54
<warren>
?
23:55
<johnny>
does fedora use pam's include facilities now , or still use pam_stack?
23:55
<warren>
how do I check?
23:55
<johnny>
hmm.. same question for your vagrantc
23:55
you*
23:55
grep -r pam_stack /etc/pam.d ?
23:56
gentoo used to use redhat's heavily patched pam until .99
23:57
which gets rid of pam_stack.so and uses the include functionality that was semi ported from openpam
23:57
<vagrantc>
johnny: grep returned nothing on sid
23:57
<johnny>
how about include ?
23:57
<warren>
johnny, looks like Fedora 8 has includes everywhere but a few pam_stack left, that might be there by accident
23:57
<johnny>
ok, so that means i can prolly fix the sabayon distributed pam file then :)
23:57
just need to ask a suse person
23:57
<warren>
oh
23:58
johnny, all cases with pam_stack are commented out
23:58
<johnny>
sweetz
23:58
<vagrantc>
johnny: plenty of @include lines
23:58* johnny == happy
23:58
<warren>
vagrantc, pushed up
23:59
<johnny>
so, how do you guys generate your initramfs ?
23:59
<warren>
mkinitrd
23:59
It sucks and rules at the same time.
23:59
<vagrantc>
i install the kernel and it calls initramfs-tools
23:59
<warren>
install a kernel and it runs mkinitrd here
23:59* vagrantc likes initramfs-tools a lot
23:59
<johnny>
so, how does mkinitrd compare to initramfs-tools ?
23:59
<warren>
in my chroot I installed /etc/sysconfig/mkinitrd with LTSP client specific options so it builds the correct initrd the first time.