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


Channel log from 19 January 2010   (all times are UTC)

00:00pasmen has joined #ltsp
00:11alkisg has joined #ltsp
00:15
<alkisg>
vagrantc, ping?
00:16pasmen has quit IRC
00:16
<alkisg>
vagrantc: in commit #1536, where you reverted the EARLY_PACKAGES change,
00:16
EARLY_PACKAGES="$(echo $option_early_packages_value | tr ',' ' ')"
00:16
If someone specifies EARLY_PACKAGES, he doesn't get ltsp-client installed
00:16artista_frustrad has quit IRC
00:18
<alkisg>
In ltsp-build-client/Ubuntu/000-basic-configuration: EARLY_PACKAGES="$EARLY_PACKAGES ltsp-client ldm dbus"
00:18
In ltsp-build-client/Debian/000-basic-configuration: EARLY_PACKAGES=${EARLY_PACKAGES:-"ltsp-client"}
00:19
So in both of those distros anyone that specifies --early-packages will miss important packages
00:20ball has quit IRC
00:20
<alkisg>
If you want to keep the ability to override EARLY_PACKAGES from the command line, then those ltsp-client/ldm/dbus packages should be on a seperate variable, IHMO.
00:24
(or we could move the assignment in 000-basic-configuration in the before-install) phase)
00:28alexqwesa_ has quit IRC
00:35Faithful has quit IRC
00:39alexqwesa_ has joined #ltsp
00:40mikkel has joined #ltsp
00:51Selveste1___ has quit IRC
01:21kmin has joined #ltsp
01:22
<kmin>
hi room
01:22
i need help
01:23Selveste1___ has joined #ltsp
01:23
<kmin>
hi Selveste1___
01:25
<Selveste1___>
kmin: Morning :)
01:25
<kmin>
:D well it is midnight here but thanks
01:25
i need help
01:26
is this the right room for that kind of questions ?
01:27otavio has quit IRC
01:31
<kmin>
anyone?
01:32
it is strange that a room with this many people in it is so quiet :)
01:39
<alkisg>
!ask
01:39
<ltspbot>
alkisg: "ask" :: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least 15 minutes after asking a question, as not everybody constantly monitors the channel.
01:39
<alkisg>
kmin: ^
01:40
<kmin>
ok here is the problem
01:40
i installed ubuntu ltsp server and i fixed the dhcp.conf in the /etc/ltsp
01:41
now when i try to boot from the network
01:41
i see the pxe loader get the image then i see the ubuntu logo
01:41
and after afew second i keep seeing something like this:
01:42
udhcpc[ ]: started
01:42
udhcpc[ ]: send requiest
01:42
udhcpc[] : no lease failing
01:42Barbosa has joined #ltsp
01:43
<kmin>
and it keeps repeating it self for ever
01:43
i know the dhcp server is up and running
01:44
any idea?
01:44
<alkisg>
See the syslogs
01:44otavio has joined #ltsp
01:44
<kmin>
what should i look for in it?
01:46
<alkisg>
Messages from dhcp3-server, seeing if it gets the request, and why it's unable to give a lease
01:47
<kmin>
this is the only thing in syslog
01:47
Jan 18 22:38:53 ubuntu dhcpd: DHCPDISCOVER from 00:02:55:57:71:6f via eth0
01:47
Jan 18 22:38:53 ubuntu dhcpd: DHCPOFFER on 192.168.7.222 to 00:02:55:57:71:6f via eth0
01:47
Jan 18 22:38:58 ubuntu dhcpd: No hostname for 192.168.7.222
01:48
and it keeps repeating
01:48
<alkisg>
Hmmm strange is that vanilla Karmic?
01:49
(with no PPAs in the sources etc?)
01:49
<kmin>
no the 9.10 release
01:49
i forgot the name
01:50
do u know if there is anything else that i need to manually enable ? nbd? some sort of swap? nfs?
01:51
the only thing that i turned on after i installed the server was dhcp
01:51
by the way after i restart the client pxe fails to boot
01:52
it seems that some how i manage to kill the dhcp after the first request
01:52Selveste1___ has quit IRC
01:53Selveste1___ has joined #ltsp
01:55Barbosa_ has quit IRC
02:01
<kmin>
let me ask u this do both of dhcp.conf files (the one in the tlsp dir and the other one) get executed or only the one in /etc/tlsp/?
02:01
cause i don't have a leae time in that one
02:05
<alkisg>
kmin: Can you upload your /etc/ltsp/dhcpd.conf to http://ltsp.pastebin.com ?
02:07
<kmin>
1 min
02:07gnunux has joined #ltsp
02:08
<alkisg>
(Karmic is the name for 9.10, btw...)
02:09
<gnunux>
hi
02:11
<alkisg>
Hello
02:16
<kmin>
http://ltsp.pastebin.com/m21243ba0
02:23
<alkisg>
option broadcast-address 192.168.0.255;
02:23
kmin ^^ fix that and retry
02:24
<kmin>
oops
02:25otavio has quit IRC
02:28
<vagrantc>
alkisg: yes, but if you *only* want ltsp-client-core installed, there's no way to do it the way you had it
02:28otavio has joined #ltsp
02:28
<vagrantc>
alkisg: i often do that for testing
02:28* vagrantc waves to otavio
02:28
<alkisg>
vagrantc: well, isn't the current one a broken behaviour?
02:29
<vagrantc>
alkisg: i don't see how
02:29
alkisg: it's the responsibility of the person using --early-packages and --late-packages to not do stupid things.
02:29
<alkisg>
The --early-packages parameter says that it enables me to specify some packages
02:29
It doesn't say that it prevents the necessary packages to be installed...
02:29
<vagrantc>
alkisg: so we should be more explicit, or do some error checking.
02:30
alkisg: but the point of it was to override the defaults.
02:30
<alkisg>
vagrantc: or we can do the other thing I said, ...
02:30
(08:23:47 πμ) alkisg: (or we could move the assignment in 000-basic-configuration in the before-install) phase)
02:30
^^^ that one
02:30
I think that covers all of the cases.
02:31
<vagrantc>
alkisg: i suppose... ideally, we wanted all the configuring to happen in the "configuration" phase of things...
02:31
alkisg: no, the way you suggest is no different, actually
02:31
<alkisg>
There are 4 sources of configuration:
02:31
1) ltsp-build-client.conf
02:31
2) defaults
02:32
3) command line parameters
02:32
Hmmm maybe 3 :)
02:33
The correct order to evaluate them probably is:
02:33
<vagrantc>
defaults are overridden by conf, which are overridden by commandline
02:33
<alkisg>
lower=defaults, a little above that = ltsp-build-client.conf, higher priority = commandline
02:33
Right
02:33
<vagrantc>
so i think the correct behavior is the way it was, which is why i reverted it.
02:34
i routinely use the option in a particular way, and i don't think it's broken, just not adequately documented.
02:34
alkisg: more approriate would be to specify an --extra-packages option or some such, so it doesn't override the defaults...
02:34
<alkisg>
vagrantc: OK so the early_packages isn't clear in the docs
02:35
It should state that it REPLACES the defaults
02:35
<vagrantc>
sure.
02:35
and late-packages as well.
02:35
<alkisg>
And if you don't specify ltsp-client-core or such there, it results in a broken chroot
02:35
<vagrantc>
sure.
02:35
<alkisg>
So, in WHICH parameter may a user just install ADDITIONAL stuff?
02:36
<vagrantc>
late-packages
02:36
as far as i recall, that shouldn't have a default, at least the way debian implements it... i think ubuntu might be a little different.
02:37
KERNEL_PACKAGES get added to LATE_PACKAGES
02:38
<alkisg>
So it's possible that an Ubuntu user doesn't want to install ltsp-client, ldm and dbus, and replace them with something else?
02:38
OK
02:38
<vagrantc>
there is one significant difference: late-packages happens after the init script rearranging, so you will get init scripts kicking it
02:39
alkisg: yes, it is possible that any user may not want to install ltsp-client ldm and dbus.
02:39
<alkisg>
OK, sorry for me misunderstanding the meaning of that option
02:39
<vagrantc>
alkisg: say they want a console-only application...
02:39
alkisg: sorry it wasn't clearer.
02:39
<alkisg>
I'll revert them to Ubuntu as well
02:39
<vagrantc>
there's a reason the --extra-help option is there ...
02:40
there's so many possible options, but i wouldn't recommend people see most of them by default.
02:40
<alkisg>
I was just trying to gather the most significant options in the ltsp-build-client.conf configuration file,
02:40
<vagrantc>
ah, ubuntu and debian have diverged on the 020-kernel-selection plugin...
02:40
<alkisg>
so that I can e.g. initialize them with sane values (arch=i386 etc)
02:41
vagrantc: unreleated: wouldn't it be better to use debconf seeding for popcon?
02:41
Instead of trying to change the value after the installation?
02:41
<vagrantc>
alkisg: also look at the difference between Debian/Ubuntu/000-basic-configuration
02:41
<alkisg>
Yes, I need to revert that change for Ubuntu as well
02:42
<vagrantc>
alkisg: the way ubuntu has 000-basic-configuration, it overrides values set in ltsp-build-client.conf, whereas in debian it only sets the defaults if not already specified.
02:43
<alkisg>
Thanks, I'll fix that.
02:44
<vagrantc>
alkisg: so fixing that might avoid the need for some of your changes
02:45
i noticed that a *long* time ago and guess it never got fixed
02:45
<alkisg>
I was careful about the changes, I just thought that EARLY_PACKAGES and LATE_PACKAGES were exceptions, in which the user would only *add* more packages, and not replace the defaults
02:46
<vagrantc>
yeah, no problem, it's not obvious
02:47
<kmin>
well i fixed that but that was not the problem
02:47
i still get the same thing
02:47
<alkisg>
Did you restart dhcp3-server ?
02:48
<kmin>
couple of times :)
02:48
<alkisg>
You don't have any other dhcp servers around that would mess your configuration, right?
02:49
<kmin>
no
02:49
<vagrantc>
alkisg: good to see your commits... i'd best get some sleep. :)
02:49
<alkisg>
vagrantc: again, thanks for correcting me :)
02:49
<kmin>
base on the ip address that the pxe gets, it gets it from the dhcp server that i have
02:50
<alkisg>
pxe is another matter
02:50
<kmin>
(i turned off the one on the router)
02:50
<alkisg>
kmin: Do you have a standalone (non-thin-client) pc around that you could use to test things?
02:50
<kmin>
yup
02:50
<alkisg>
ok, boot it with Ubuntu or something
02:50
<kmin>
this whole thing is inside vm
02:51
<alkisg>
And first try to see if dhclient succeeds,
02:51
and if it does, then install udhcpc and see if that one succeeds as well
02:53
<kmin>
dhclient works i tested it before
02:53
but i have no idea what udhcpc is :D
02:53
<alkisg>
sudo apt-get install udhcpc
02:54
<elias_a>
Has someone tested using Novell client on LTSP?
02:55
I have a need for this. There are no .deb packages for the novell client and there have been some problems when trying to install it with alien from rpm files.
02:55
<kmin>
btw I did rm /var/log/syslog
02:55
and did touch /var/log/syslog
02:56
<elias_a>
Do you think this is doable or am I trying to commit a painful suicide?
02:56
<kmin>
but since then the syslog file has remained empty why?
02:59
<zamba>
you can run ltsp over a WAN?
03:00
you basically just need a local dhcp that points to the tftp server, right?
03:00
(it's a 100 Mbit/s wan)
03:00
before you ask
03:03
<alkisg>
kmin: sudo chown syslog:adm /var/log/syslog
03:03vagrantc has quit IRC
03:03
<alkisg>
zamba: you'd need the wireless drivers and wpa keys etc in the initramfs
03:04
You'd also need to boot from lan first, as only a very few wireless cards support network booting
03:04
(or have the kernel in a local media)
03:04
zamba: so it's doable, but hard to do it
03:09Selveste1___ has quit IRC
03:09
<kmin>
brb
03:09kmin has left #ltsp
03:13
<zamba>
alkisg: wan, not wifi :)
03:13Selveste1 has joined #ltsp
03:13
<zamba>
alkisg: this is going to be wired networking
03:13
<alkisg>
zamba: heh sorry :)
03:14
zamba: you'll need some ports open, and you can either boot with a local gpxe or with a local dhcp server
03:14
<zamba>
local gpxe means a boot media? like flash or cd?
03:14
<alkisg>
Yes
03:14
Either that, or a dhcp server around
03:14
<zamba>
alkisg: yeah
03:14
alkisg: i'd go for the dhcp
03:14
alkisg: but it's "doable"?
03:15
<alkisg>
Yeah sure it is
03:15
<zamba>
alkisg: should be any problems with tftp?
03:15
<alkisg>
Just be careful about security
03:15
No, it's common to have a different tftp server than the application server
03:18
<zamba>
ok
03:18
what methods of load balancing exist? if any?
03:20cyberorg has quit IRC
03:50kmin has joined #ltsp
03:54
<kmin>
ok when i try to run udhcpc i get this
03:54
SIOCGIFINDEX failed!: No such device
03:54
but the dhcp server is working just fine
03:59
so just to give some back ground
04:00
i installed a ltsp server (ubuntu) and now when i am trying to boot a client
04:00
after the pxe get the image and after the ubuntu logo comes up
04:00
i keep getting this message :
04:03
:D nm
04:04
some new stuff is happening
04:09
it is working thanks everyone
04:09kmin has left #ltsp
04:10Pod2 has joined #ltsp
04:23
<zamba>
hehe
04:27
solutions for running windows applications in a ltsp session?
04:27
preferably terminal services.. if the licensing allows it
04:29
<Appiah>
wine ?
04:29
or rdesktop to a windows server
04:50
what did you have in mind zamba ?
04:51
<zamba>
Appiah: something like that, yeah
04:52
<Appiah>
something like what? :)
04:52
<zamba>
Appiah: but isn't the licensing for terminal services stupid?
04:52
Appiah: i mean.. i have a program that's freeware, but i still need to pay licenses to use it over rdesktop because several users are using it at the same time..?
04:52
Appiah: rdesktop :)
04:53
<Appiah>
I thing licensing is stupid yes
04:53
think*
04:53
I would switch over to a software that can run nativly on Linux
04:53
<zamba>
unfortunately that's not available
04:54
it's a software used in schools and developed in norway
04:54
<Appiah>
If that thats not a option I would try to run it in wine
04:54
<alkisg>
zamba: I've also had some success in packaging windows applications to run under wine
04:54
I.e. also do file associations etc
04:54
<zamba>
alkisg: so you know the "procedures" for getting windows applications working in wine?
04:55
the problem is often resolving the library dependencies, right?
04:55
<alkisg>
There are lots of related problems, but I've been a windows programmer for 17 years so I was able to solve many of the problems we had in edu apps here
04:56
<Appiah>
check the application database zamba
04:56
http://appdb.winehq.org/
04:57
<zamba>
Appiah: it's definitely not there :)
04:57
but sure, i'll take a look
04:57
<alkisg>
E.g. provide some DLLs, run under "nice" so that they don't hog the CPU etc
04:57
<Appiah>
then check the debug manual
04:57
<zamba>
alkisg: i have a program here i'd like to get running under wine.. mind helping me out?
04:57
<Appiah>
see how íf you can get it to work
04:57
and maybe contact the developrs to get help on the way
04:58
if it's a .net application I'd say there a smaller chance of getting it to work
04:58
have you even tried zamba ? Maybe it runs and works perfectly
04:58
<alkisg>
zamba: Appiah is right, give some more information about the program
05:00
<zamba>
Appiah: i have no idea who's made it
05:00
Appiah: it's probably nearly 20 years old
05:01
<alkisg>
zamba: ? is it a dos app?
05:01
<zamba>
when i try to run it i get two (windows specific) errors.. first in norwegian: "FEILHÅNDTERING" which basically means "error handling"
05:01
and then "Illegal function call"
05:01
no, it's a windows app
05:01
probably more like 15 years old.. but it's very old :)
05:01
<Appiah>
was it written for win95?
05:01
did you switch wine to a win95 profile?
05:02
<zamba>
how do i do that?
05:02
<Appiah>
winecfg
05:02
well what was it written for?
05:02
<zamba>
same error
05:02
<alkisg>
zamba: also, run "wine myapp" from the console, and paste the output to pastebin
05:03
<zamba>
alkisg: no output
05:03
<Appiah>
hello what windows version was it written for?
05:03
<alkisg>
No wine output?!
05:03
<zamba>
Appiah: have no idea, man
05:03
<Appiah>
then enable console debug
05:03
zamba: check the readme?
05:03
manuals
05:03
<zamba>
Appiah: but it runs in winxp
05:03
<Appiah>
etc
05:03
<zamba>
Appiah: did you get the point about this being an obscure program with no manuals, no readme, no nothing? :)
05:04
Appiah: and it's written by a company long gone
05:04
<Appiah>
ok
05:04
<alkisg>
zamba: there are debug options in wine, you can tell it to output all winapi function calls
05:04
<Appiah>
then enable the debug
05:04
<alkisg>
You'll see on which one it fails..
05:07
<zamba>
looks like it lacks a dll, yeah
05:07
<alkisg>
Putting it either in the program's dir or in the wine dll overrides could solve your problem
05:07
<zamba>
thanks.. i'll try that..
05:07
have to get hold of it first, though :)
05:08
<alkisg>
:)
05:10cyberorg has joined #ltsp
05:24* alkisg wonders why ltsp-update-image uses "/etc/default/ltsp-update-image" while all others use "/etc/ltsp/*.conf"...
05:25hersonls has joined #ltsp
05:50ogra has quit IRC
05:50ogra has joined #ltsp
05:51bobby_C has joined #ltsp
05:51
<Appiah>
zamba: check out winetricks too
06:12
<zamba>
Appiah: ok.. thanks again :)
06:13pmatulis has joined #ltsp
06:14Selveste1 has quit IRC
06:14Selveste1 has joined #ltsp
06:29vvinet has quit IRC
06:51Selveste1 has quit IRC
06:51mikkel has quit IRC
06:52Selveste1 has joined #ltsp
07:00dro has joined #ltsp
07:05evilx has quit IRC
07:05evilx has joined #LTSP
07:08Selveste1_ has joined #ltsp
07:09Selveste1 has quit IRC
07:10cliebow has joined #ltsp
07:15alkisg has quit IRC
07:17cliebow has quit IRC
07:32vvinet has joined #ltsp
07:34scottmaccal has joined #ltsp
07:36lucascoala_ has joined #ltsp
07:43litlebuda has joined #ltsp
07:43lucascoala has quit IRC
07:43CAN-o-SPAM has joined #ltsp
07:57alexqwesa_ has quit IRC
08:00Gadi has joined #ltsp
08:09grey-monkey has left #ltsp
08:13alkisg has joined #ltsp
08:13alexqwesa_ has joined #ltsp
08:18mgariepy has joined #ltsp
08:18
<mgariepy>
good morning everyone
08:19
<alkisg>
Hello mgariepy.
08:19
stgraber: hi, here's a try for killing processes in ltsp-update-image: http://paste.ubuntu.com/359032/
08:19
Any tips to easily trigger it for testing?
08:21
<moldy>
alkisg: hm, why do you have to do this?
08:21
<alkisg>
moldy: as a safeguard for any daemons that started in the chroot and weren't stopped
08:21
Of course we'll also try to stop any daemons from starting :)
08:22
<moldy>
alkisg: hm, ok...
08:24prpplague_afk is now known as prpplague
08:38bieb has joined #ltsp
08:45
<sbalneav>
Morning all
08:46
<alkisg>
Hi Scotty!
08:54cliebow has joined #ltsp
08:56
<dro>
good morning
08:57
<CAN-o-SPAM>
hey dro
08:57
hi sbalneav!
08:58
<dro>
Hiya
08:58
<cliebow>
Scotto!
09:01
<stgraber>
alkisg: why are you making that so long ? the one-liner did the same didn't it ?
09:03
<alkisg>
stgraber: well `find` seemed safer & faster than ls/grep/awk/cut... and I also wanted to show the processes, so that we can then try to disable those daemons from starting
09:04* alkisg is building a fat chroot to reproduce the problem right now...
09:05
<stgraber>
alkisg: ok
09:10
<alkisg>
Wouldn't it be better if ltsp-update-image sourced /etc/ltsp/ltsp-update-image.conf, similar to what ltsp-update-kernels does, instead of sourcing /etc/default/ltsp-update-image?
09:12
<stgraber>
just use whatever is the most consistent
09:12
neither are used in Ubuntu currently (as in, shipped in the package) so I don't have to think too much about transition (other than mentioning it in the changelog)
09:43Selveste1_ has quit IRC
09:44Selveste1_ has joined #ltsp
09:46ball has joined #ltsp
10:04etyack has joined #ltsp
10:11bobby_C has quit IRC
10:13gnunux has quit IRC
10:13etyack has quit IRC
10:14
<alkisg>
Darn building an ubuntu fat client didn't trigger the problem :(
10:14
Building an edubuntu fat client now....
10:15staffencasa has joined #ltsp
10:18lucascoala_ has quit IRC
10:19lucascoala has joined #ltsp
10:23pem725 has joined #ltsp
10:24alexqwesa_ is now known as alexqwesa
10:25
<pem725>
I have an Ubuntu 9.04 LTSP server that was working fine for months and now it appears that inetd no longer functions properly. Anyone other there have any clues on fixing inetd without upgrading?
10:29
is it possible to run tftp without inetd?
10:29
<dro>
pem725: more of a ubuntu issue than ltsp
10:29
pem725: whats it doing?
10:29
<pem725>
yeah, I know...sorry.
10:30
inetd does not seem to start correctly.
10:30
<ogra>
how did you get to that state ? :)
10:30
server apps dont "just stop working"
10:30
<pem725>
when I check netstat after a reboot, tftp is not active.
10:30
<ogra>
it shouldnt be
10:30
inetd starts it dynamically
10:30
<pem725>
ah
10:30
but my thin clients hang on the TFTP timeout.
10:31
so my guess is that inetd is the culprit.
10:31
<ogra>
did someone add a pc with dhcp server enabled ? ;)
10:31
<pem725>
perhaps I am wrong.
10:31
I doubt it.
10:31
<ogra>
or a new router that has a dhcp server on it
10:31
<pem725>
hmmmm
10:31
<dro>
and what currently is your dhcp server? the ltsp server, windows dhcp, firewall/router?
10:32
<pem725>
well I have a router with a dhcp server on it but it sits outside my network range.
10:32
<ogra>
ususally tftp timeouts are rather caused by dhhp issues ... if you run more than one dhcpd in one network segment you can have races between the two servers
10:32
<pem725>
ah
10:32
so it might not be inetd afterall.
10:32
<ogra>
#well, define "network range" :)
10:32
<pem725>
OK
10:32
<Gadi>
pem725: uncomment the "next-server" line in dhcpd.conf and put the IP address of the tftp server. Restart dhcp3-server and reboot the client
10:32
<ogra>
if its physically on the same ethernet the router could answer faster than the actual dhcpd
10:32
<pem725>
Gadi, I did that already.
10:33
<Gadi>
ah
10:33
<pem725>
and it worked just fine.
10:33
<Gadi>
that was u
10:33
:)
10:33
<pem725>
yes.
10:33
thanks again.
10:33
I am back to square one again though.
10:33
seems I might be barking up the wrong tree though.
10:33
dhcp issues might be the problem.
10:33
<ogra>
well, for a test, shut down the router and see if the clients boot ;)
10:33
<pem725>
will do.
10:36
<Gadi>
pem725: just an FYI, the PXE dhcp request is broadcast, so it doesn't matter if your dhcp servers are different ranges, whichever one answers the request first wins
10:36
<ogra>
right, physical ethernet is all that counts :)
10:36
<Gadi>
if you can't separate the network by physical switch or VLAN
10:37
there are other workarounds like this: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
10:37
<ogra>
or just use a single dhcpd :)
10:37
<Gadi>
or you can listen to ogra - but thats never as much fun
10:37
<pem725>
ah, got it Gadi.
10:37
<ogra>
pfft
10:38
<pem725>
OK, I killed all the other potential dhcp conflicts.
10:38* ogra likes single points of failure ... way easier to debug :)
10:38
<pem725>
whoa!
10:38
except one...
10:38
seems win4lin has a dhcpd
10:39* ogra really thinks these guys should use ltsp http://blog.dustinkirkland.com/2010/01/39000-core-ubuntu-cluster-renders.html
10:41
<pem725>
I'm not sure what is running anymore. I'm going to reboot the server to see what happens from startup.
10:41dmarkey has quit IRC
10:41jbrett has quit IRC
10:41vlt has quit IRC
10:41Egyptian[Home] has quit IRC
10:41stgraber has quit IRC
10:41Ryan52 has quit IRC
10:41Appiah has quit IRC
10:41dmarkey_ has joined #ltsp
10:41Appiah_ has joined #ltsp
10:41stgraber_ has joined #ltsp
10:41pem725 has quit IRC
10:41vlt has joined #ltsp
10:41Ryan52 has joined #ltsp
10:42jbrett has joined #ltsp
10:42tarbo has joined #ltsp
10:42jhutchins has joined #ltsp
10:43Egyptian[Home] has joined #ltsp
10:46Selveste1_ has quit IRC
10:47pem725 has joined #ltsp
10:48
<pem725>
OK, I'm back and figured out the problem - ogri was right. My new router has a dhcp that is outside my network but still interfering with my dhcp server.
10:48
very strange.
10:48
I guess I need to kill that thing when I reboot.
10:48
thanks for the help.
10:51
<alkisg>
pem725: there are ways around that
10:52
E.g. the proposed topology is with 2 NICs on the server, so that the second nic faces the ltsp clients, and no dhcp server interferes there
10:52
Or, you could even turn off the ltsp dhcp server and only keep the router's dhcp server
10:52
<ball>
alkisg: that's how I was planning to roll it out, with a separate LAN for the terminals.
10:53
<alkisg>
pem725: but if you want to do that on every client reboot, sure, you could turn off the dhcp server or unplug the cables temporarily :D
10:57mfdutra has joined #ltsp
11:01staffencasa has quit IRC
11:04staffencasa has joined #ltsp
11:04
<Pod2>
has anyone managed to get rdesktop v1.6 into ltsp 4.2?
11:04
<ball>
Pod2: what are you trying to do?
11:05
Pod2: connect to MS Windows servers?
11:05
<Pod2>
yes
11:06
I have ltsp 4.2 connecting via rdesktop to Win2003 fine. The v1.4 of rdesktop doesn't want to connect to Win2008R2 though
11:06
<dro>
Pod2: what seems to be the issues?
11:06
Pod2: probably because of the increased security of win20008r2
11:06
<ball>
I wouldn't be surprised if Microsoft deliberately broke it.
11:06
<dro>
Pod2: 2 options, upgrade the client or descrease the TS connectivity security
11:06
<Pod2>
I have a ltsp 5 install, but that's on debian squeeze. rdesktop connects, but mouse and keyboard don't work
11:07
<ogra>
squeeze is in flux
11:07
<Pod2>
dro: failing to upgrade the client is why I'm here :)
11:07
<dro>
Pod2: lower the security settings in 2008r2 then
11:07
<Pod2>
yeah, choosing squeeze may not have been the best option.
11:07
<dro>
Pod2: should be fine
11:07
<Pod2>
dro: any idea how?
11:07
<ogra>
xorg switched to hal input handling and away from it again, squaeeze is in the middle of that transition afaik
11:08
<dro>
Pod2: are you running a domain?
11:08
<Pod2>
yes
11:08
<dro>
Pod2: sec let me check google
11:08
<Pod2>
ogra: thanks. I'll probably just wait it out till moving to ltsp 5 then
11:08
<dro>
for the specific group policy
11:09
<ogra>
Pod2, i know that vagrantc provides backport packages of LTSP for lenny though (not sure where though)
11:09
<dro>
Pod2: I know one way is to disable the TS role
11:09
Pod2: go back to add that role back in, and there is an option that talks about the client connectivity
11:09
where you can choose secure only, and a few other options
11:09
you change it to the lower setting
11:10
<Pod2>
I *thought* I had done that. Quite possibly not though - I'll check that.
11:10
thanks
11:10
<dro>
Pod2: np i'm not finding anything on google
11:11
<Pod2>
me neither. irc was the last resort :)
11:11
<dro>
Pod2: sec i might have found something
11:12
ok on the TS
11:12
go to system properties
11:12
easiest way is to r-click computer-->properties-->system properties should be on the left
11:13
<Pod2>
ok
11:13
<dro>
go to the remote tab
11:13
which option is checked
11:13
top, middle, or bottom?
11:13
<Pod2>
I've already got the 'less secure' option checked
11:13Selveste1_ has joined #ltsp
11:13
<Pod2>
middle
11:14
<dro>
k
11:14
then it's a group policy issue
11:14
probably in the default domain policy
11:14
and unfortenly i do'nt have access to a 2008r2 pdc right now
11:14
not at this customer's site
11:15
<Gadi>
Pod2: you cannot connect to w2k8r2 with rdesktop1.4
11:15
<Pod2>
I know :)
11:15
<dro>
Gadi: is it do to the heightened security?
11:15
<Gadi>
they haven't even worked out all the bugs with 1.6 :P
11:15
no
11:15
much has changed in rdp
11:16
<dro>
ahhhh
11:16
<Gadi>
true that rdesktop does not support many of the new security extensions that MS has added
11:16
so, those need to be turned off
11:17
<Pod2>
with ltsp 5, I can log into the linux desktop, run rdesktop from there and it's all peachy. Running rdesktop direct causes the mouse and keyboard to fail (which seems to be a known problem with squeeze)
11:17
<Gadi>
but, older versions of rdesktop cannot even make the connection to newer rdp servers
11:18
I thought the mouse/keyboard issues in debian were in ldm as well
11:18
I thought it was an X/dbus/hal thing
11:19cliebow has quit IRC
11:19cliebow has joined #ltsp
11:20
<Pod2>
I have LDM_DIRECTX = True and SCREEN_07 = startx - this gets me a linux login screen and then the desktop
11:21
<alkisg>
stgraber_: nope, ls /proc/*/exe doesn't work :(
11:21
I have /opt/ltsp/i386/proc in use right now, and no way to see the process that's using it.
11:21
<Gadi>
Pod2: you dont need LDM_DIRECTX if you are using startx
11:22
are you using startx because mouse/keybd dont work with ldm?
11:23
<Pod2>
I was using LDM_DIRECTX because my clients are slow - wasn't sure if it was relevant, so I pointed it out anyway
11:24
<Gadi>
right bu *LDM*_DIRECTX only works if you use LDM
11:24
:)
11:26
<Pod2>
aha, I've just tried with screen7 = ldm. Got a (different) login screen and no mouse or keyboard
11:26
I'll test it again with startx
11:28
hmm, no mouse or keyboard with that either
11:28
must have got confused
11:28
<alkisg>
stgraber_: lsof /opt/ltsp/i386/proc output: http://paste.ubuntu.com/359113/
11:29
<Pod2>
ok, so that's not likely to work until squeeze gets sorted out.
11:30
I have tried shoehorning rdesktop v1.6 into my (working!) ltsp 4.2 but only get illegal instruction errors
11:31
booting a client to the shell and running ldd rdesktop gives a different list of libs compared to the same command on the server
11:31
before, it complained about missing libs and just copied bits around till it worked, but that doesn't seem to do it this time
11:31
<johnny>
that's cuz they are different..
11:35
<Pod2>
looks like my best option is to find another box and install debian stable and try that
11:37cliebow has quit IRC
11:37cliebow has joined #ltsp
11:42
<Gadi>
Pod2: I *belieeve* you can build a chroot from a different repo than the server one
11:42
look at: ltsp-build-client --extra-help
11:43
<Pod2>
ah, now that would be perfect. Thanks very much - I'll have a good read of that
11:43
<Gadi>
look at --dist
11:50ball has quit IRC
11:58
<stgraber_>
yeah, I have a rock solid nbd-proxy now !
11:58
Just need to have the forking part done a bit better than it currently is and it'll be ready
12:00Pod2 has left #ltsp
12:02
<alkisg>
stgraber_: if you want to give me commands to try out to see what uses /proc, now's the time... unfortunately, reproducing it takes a LOT of time :)
12:07alexqwesa has quit IRC
12:08
<stgraber_>
alkisg: looking at that now, hang on a sec
12:08
<alkisg>
Sure, np, thanks :)
12:17
<stgraber_>
alkisg: you need -lh if you want to see the symlink target
12:17
<alkisg>
alkisg@alkis:~$ sudo ls -lh /proc/*/exe 2>/dev/null | grep /opt/ltsp
12:17
alkisg@alkis:~$ sudo umount /opt/ltsp/i386/proc/
12:17
umount: /opt/ltsp/i386/proc: device is busy.
12:17
stgraber_: ^
12:18dro has quit IRC
12:18dro has joined #ltsp
12:20
<alkisg>
I wonder if hal is related, as the problem doesn't happen in Ubuntu fat clients, only when installing Edubuntu ones.
12:21
<stgraber_>
alkisg: could be hal, though I don't see why exe doesn't point to it correctly ...
12:21
<alkisg>
Maybe it's reusing an already running instance?
12:21
I have both edubuntu server and chroot
12:26
stgraber_: fuser output: http://ltsp.pastebin.com/m7e05070d
12:33rhodan has joined #ltsp
12:37
<mfdutra>
stgraber_, hi. does ltsp-cluster also balance the nbd server or only the X server?
12:37Barbosa has quit IRC
12:37Barbosa has joined #ltsp
12:40
<Gadi>
mfdutra: only the application servers
12:40
linux or windows
12:41
<mfdutra>
right. it works by generating a different lts.conf on the fly, right?
12:41* Gadi is actually doing his first ltsp-cluster implementation right now
12:41
<Gadi>
mfdutra: sorta - it makes http queries to the "Control Center"
12:41
that responds with lts.conf-parameters
12:42
<mfdutra>
yes, but that http query seems to create an lts.conf file
12:42
or something like that
12:42
<Gadi>
right
12:42
on the client side
12:42
<mfdutra>
I have a setup with about 2000 users in ltsp 4.2 now. I'm planning to upgrade it to 5
12:43
I'm afraid of having all those clients nbd'ing to the same server
12:43
<Gadi>
which has the added benefit of changing runtime session params
12:44
well, the nbd server and the control center need not be one and the sasme
12:44
*same
12:45
<mfdutra>
today I have all those clients using the same NFS server. I don't think the performance would change because of NBD
12:45
actually I don't know if NBD is faster than NFS...
12:46
<johnny>
it is
12:46
otherwise ubuntu wouldn't be using it
12:46
at least for most people
12:46
<mfdutra>
well, speed isn't the only concern
12:46
<Gadi>
right - the only thing to keep an eye on is whether there is a limit to the number of nbd-server processes that can be spawned
12:46
<mfdutra>
NFS is a pain in the ass
12:46
<Gadi>
which I am not sure there is
12:46
(short of Linux's own max proc limit)
12:46* alkisg served an 11Gb nbd chroot with no problems, so size isn't an issue either
12:47
<Gadi>
I am actually currently trying to choose a good high-availability approach to my nbd-server/control-center VM
12:48
lots of ways to go
12:48
<mfdutra>
my i386 image won't be bigger than 500 mb. my concern is to have almost 2k users accessing it
12:49
<Gadi>
mfdutra: I wouldn't worry too much - unless they all boot at the same time
12:49
:)
12:49
<mfdutra>
they do
12:49
<Gadi>
ah
12:49
<mfdutra>
it's a university
12:49
<Gadi>
and all 2000 machine come on at once?
12:49
<mfdutra>
all the students begin their classes almost at the same time
12:49
<Gadi>
I see
12:49
<mfdutra>
well, they already do it today with NFS
12:50
<Gadi>
and you have no problems with that with NFS?
12:50
<mfdutra>
it gets a bit slow, but... it works
12:50
after a lot of tweaks, it's been working well
12:50
1 NFS and 18 app servers
12:50
<Gadi>
ok, then Im sure you can make nbd behave well, too
12:50
<mfdutra>
cool
12:50spectra has joined #ltsp
12:51
<Gadi>
the only diff is that nbd is spawned out of inetd
12:51
an individual nbd-server proc for each connection
12:51
<mfdutra>
is inetd stable enough?
12:51
<Gadi>
whereas nfs will have fewer procs per connections
12:51
havent had any stability issues with inetd
12:52
<mfdutra>
yes, the dirty NFS work is all done by the kernel
12:52
<Gadi>
now, all that said, you can still run ltsp over nfs
12:52
<mfdutra>
although I have almost no control over it, what's bad (in NFS)
12:52
<Gadi>
as opposed to nbd
12:52
<mfdutra>
sure, right
12:52
I'll try it with nbd. it looks to me a good idea
12:53
<Gadi>
and you can always distribute the load over several nbd servers as needed
12:53
<mfdutra>
can I configure the nbd server in lts.conf?
12:53
<Gadi>
in dhcpd.conf
12:53
your dhcp server tells it what nbd server to use
12:54
(well, if nbd is same as tftp server)
12:54
<mfdutra>
hmm it's tcp. I could have something like a LVS to balance it
12:54
<Gadi>
right
12:54
<mfdutra>
my question actually was whether I can have a different tftp and nbd server
12:55
<Gadi>
sure
12:55
you can set nbd server as a kernel argument
12:55
<mfdutra>
hmmmm
12:55
which one?
12:55
<Gadi>
nbdroot=<ip:port>
12:55
<mfdutra>
excellent
12:56
would that support a hostname (DNS)?
12:56
<Gadi>
I believe so
12:56* mfdutra thinkinf of a DNS round robin
12:57
<mfdutra>
interesting
12:57
I'll proceed with some tests here :)
12:57
thanks for all the preciousinfo
12:57
.. info
12:57
<Gadi>
whats ur plan?
12:57
<mfdutra>
I don't know actually
12:57
<Gadi>
hehe
12:57
<mfdutra>
I'm just researching by now
12:58
I wrote a lot of cluster stuff for ltsp-4.2
12:58
it's working perfectly
12:58
<Gadi>
same type of design?
12:58
<mfdutra>
my point now is either using what I have written or moving to ltsp-cluster
12:58
yes
12:58
well, almost
12:58
I use DNS SRV
12:59
_ltsp._udp.domain
12:59
it returns all the servers with their weights
12:59
all the rest is SNMP
12:59
<Gadi>
interesting
13:00
<mfdutra>
so the script queries all the servers and calculates a score for each one
13:00
sort that list and choose the best server to X -query
13:01
when I boot my clients, they stop at a dialog screen asking the user for linux or windows session. we have some windows terminal servers too
13:01
the balancer takes place after the dialog
13:02
for windows it's the same theory, with SNMP
13:02* alkisg tries killing processes at random until /opt/ltsp/i386/proc is no longer in use... :D
13:02
<stgraber_>
alkisg: alkisg ls -lh /proc/*/root | grep "/opt/ltsp/i386"
13:02
<mfdutra>
although I don't consider as many variables as I do for linux, because the windows snmp agent is crappy
13:03
<alkisg>
alkisg@alkis:~$ sudo ls -lh /proc/*/root | grep "/opt/ltsp/i386"
13:03
alkisg@alkis:~$ sudo umount /opt/ltsp/i386/proc/
13:03
umount: /opt/ltsp/i386/proc: device is busy.
13:03
stgraber_: ^ :(
13:03
It wasn't hal, I killed it, no sugar
13:03
<Gadi>
mfdutra: windows these days has NLB
13:03
<stgraber_>
alkisg: you don't happen to have any shell currently somewhere in /proc ?
13:03
<alkisg>
Nope
13:04
<Gadi>
mfdutra: which you can use with WTS
13:04stgraber_ is now known as stgraber
13:04
<mfdutra>
what's NLB and WTS?
13:05
<stgraber>
alkisg: can you paste the output of "lsof -n | grep proc" again ?
13:05
<Gadi>
mfdutra: NLB=Netowrk Load Balancing WTS=Windows Terminal Services
13:06
<alkisg>
stgraber: http://paste.ubuntu.com/359162/
13:06
<mfdutra>
is NLB that .net thing used by ltsp-cluster?
13:06
<Gadi>
no
13:06
it is a MS thing
13:06
<mfdutra>
hmmm
13:06
<Gadi>
a service you enable to create a load balanced cluster
13:06
<mfdutra>
does that exist for w2k3?
13:06
<Gadi>
you basically have a floating cluster IP
13:06
not sure
13:06MaRX-Mode has quit IRC
13:06
<Gadi>
it may have been introduced with w2k8
13:06MaRX-Mode has joined #ltsp
13:07
<mfdutra>
when I tried to create a cluster in windows, it demanded AD
13:07
I have no AD
13:07
<Gadi>
ah
13:07
<mfdutra>
samba+openldap
13:07
<stgraber>
alkisg: 1759 looks like a good candidate
13:07
<Gadi>
that may still be the case
13:07
<mfdutra>
probably
13:07
that's why I gave it up and wrote our scripts
13:08japerry has quit IRC
13:08
<mfdutra>
is rdesktop on karmic working ok in w2k8?
13:08
<alkisg>
stgraber: should I try killing it? or should I search for something "recognisable" in /proc/1759/* ?
13:09
<Gadi>
mfdutra: it does, but rdesktop needs more loving in general
13:09
it is falling behind the pace of rdp
13:09
<stgraber>
alkisg: ls -lh /proc/1759/ might help
13:09
<mfdutra>
hmm
13:09
is there any alternative to rdesktop these days?
13:10
<Gadi>
last year, there was a fork that started
13:10
freerdp
13:10
it looks promising but is a very new fork
13:10
<mfdutra>
hmm I'll check it
13:10
right
13:10
<stgraber>
alkisg: I'm building a new chroot here with edubuntu fat client but in a container, so I'll have only the process that gets spawned from within the chroot
13:11
alkisg: I'm suspecting that something in your gnome desktop is opening that /proc and that it has nothing to do with the chroot itself
13:11
<alkisg>
Oooh that's a fine way to isolate it (if it actually happens to you too :D)
13:11
OK, so I'll try killing things to see what it was
13:11
<stgraber>
alkisg: in that can case, the solution would be to go with: the kill + umount -l
13:11
as nothing will actually be started from the chroot, it's safe to do a umount -l
13:11
<alkisg>
I can't find anything in /proc/1759/*, other than mounts and mountinfo
13:11
<stgraber>
but I need to make sure of that before we do it
13:12dro has quit IRC
13:15* alkisg logs off and starts killing stuff
13:16alkisg has quit IRC
13:18dro has joined #ltsp
13:37alkisg has joined #ltsp
13:39mfdutra has quit IRC
13:40
<alkisg>
stgraber: I've finished my "killall attempts", and I can tell you with great certainty that "killing will get us nowhere" :(
13:40
I've stopped any service and killed any process I saw, to no avail
13:41
<stgraber>
alkisg: ok
13:41
alkisg: I'm finishing to built my chroot
13:41
<ogra>
alkisg, checked with lsof or fuser ?
13:42cliebow has quit IRC
13:42dro has quit IRC
13:42
<alkisg>
ogra: yes, hours ago. Since then, I've stopped X, gdm, avahi, `killall -u user`, kill everything that's not on [brackets], stopped all services... still umount complains "in use"
13:42
<ogra>
umount -l ;)
13:42dro has joined #ltsp
13:43
<alkisg>
Right, I totally agree ;)
13:43
<ogra>
what has ps to say about proc 1759 ?
13:43
<alkisg>
Killed that as well
13:43
<ogra>
what was it ?
13:44
<alkisg>
Let me see my logs..
13:44
root 1759 1 0 08:09 ? 00:00:00 /usr/lib/devicekit-disks/devkit-disks-daemon
13:44loathing has joined #ltsp
13:44
<ogra>
aha
13:44
thats spawned by udev
13:45
<alkisg>
I've killed udev too :P
13:45
<ogra>
ugh
13:45
well, i'D talk to pitti about that, he's the devkit god
13:45
(at least in ubuntu)
13:46
<alkisg>
I was left with those at the end: http://paste.ubuntu.com/359181/
13:46
<ogra>
killing udev is never a good idea
13:46
<alkisg>
I didn't know what else to kill, so I just rebooted
13:46
<ogra>
i would consider not running rsyslog on clients btw
13:46
at least the kernel part
13:47
<alkisg>
(I killed rsyslog and it respawned)
13:47
<ogra>
thats something you can enable on demand if you actually see probs
13:47
how did you kill it ?
13:47
<alkisg>
I did a "kill <some process number that started with dd>",
13:47
<ogra>
daemons are usually respawned by upstart if you didnt use upstart to stop them
13:48
sudo service rsyslog stop
13:48
;)
13:48
<alkisg>
and immediately after that, I saw a message about "syslog killed respawning"
13:48
<ogra>
right
13:48
<alkisg>
I didn't know it was syslog at that time
13:48
<ogra>
upstart is clever :)
13:49
as long as all events are fulfilled it will keep the daemion running unless the admin sends the stop event
13:49
anyway, i need to go ...
13:49
<alkisg>
Bye ogra, good night
13:49
<ogra>
ciao
13:55
<stgraber>
alkisg: do you have the bug number for that seed change (depends to recommends) ?
13:55
<alkisg>
Moment...
13:55
https://bugs.launchpad.net/ubuntu/+source/edubuntu-meta/+bug/508923
13:55
<stgraber>
thanks
13:55* alkisg thanks
14:08vagrantc has joined #ltsp
14:11dro has quit IRC
14:14dro has joined #ltsp
14:18
<stgraber>
Gadi: btw, you broke PATH in ltsp_config ;) I had a few scripts sourcing ltsp_config getting empty $PATH ;) I fixed it with 1543.
14:19pmatulis has quit IRC
14:20mikkel has joined #ltsp
14:21vmlintu has joined #ltsp
14:23vmlintu_ has quit IRC
14:28alexqwesa has joined #ltsp
14:29
<alkisg>
Well we could just put ". /usr/share/ltsp/ltsp-common-functions" AFTER "if [ "$LTSP_CONFIG" = "True" ]; then return 0; fi"
14:30
Then there wouldn't be any need to check if ltsp-common-functions is already included or not
14:32dro has quit IRC
14:32
<vagrantc>
we should also not put that as a one-liner.
14:32
or use the one-liner syntax: [ "$foo" = "True" ] && return 0
14:34
<alkisg>
Is there any case where ltsp-common-functions will need to be sourced from ltsp_config, while LTSP_CONFIG is True?
14:34
(btw vagrantc, we were wandering with Gadi about the last line, "export LTSP_CONFIG=${LTSP_CONFIG:-"True"}" ==> how exactly do you use that? from lts.conf?)
14:34
*wondering
14:36
<knipwim>
what's the proper way to request an edit for the wiki
14:36alexqwesa has quit IRC
14:37
<johnny>
knipwim, i'm pretty tired of gentoo... roy marples is a dummy :(
14:37
i don't know if i can go back now
14:38
of course.. i guess it's not his fault.. he did spend all his time developing openrc
14:38
<Gadi>
pheh - PATH - who needs that in the real world? ;)
14:39
<knipwim>
johnny: they indeed have a slow development cycle
14:39
that doesn't keep me from using it
14:40
<johnny>
i'd really appreciate it if they would just adopt upstart..
14:40
it would make the world a better place
14:41
<knipwim>
can't you lobby for it?
14:41
<johnny>
there are already tickets for it
14:41
i think people have already put enough time caring about openrc
14:41
and it probably is faster than upstart..
14:42
but not fast enough to make up for the loss of the possibliyt for a common init system for multiple distros..
14:42
<Gadi>
stgraber: how we doing on bootchart?
14:42
<vagrantc>
alkisg: i would use it for use cases where the lts.conf might change regularly, and set it to False in lts.conf
14:42
alkisg: i.e. LTSP_CONFIG=false
14:43
alkisg: for the most part, like all things, the defaults are probably going to be used.
14:43
<stgraber>
Gadi: network is really slow here so actual boot time isn't interesting but I'll make one just to check if we have some odd process getting started.
14:43
<alkisg>
vagrantc: thanks, that's what we thought too.
14:44
So ". /usr/share/ltsp/ltsp-common-functions" should probably be BELOW "if [ "$LTSP_CONFIG" = "True" ];" ...
14:45
<vagrantc>
sounds good to me.
14:45
unless we want to use the boolean_is_true function.
14:45
<Gadi>
right - thats why I put it first
14:45
<alkisg>
Erm what?
14:45
<Gadi>
but, as long as we don't we're good
14:45
<alkisg>
I don't get it
14:45
<vagrantc>
if [ "$LTSP_CONFIG" = "True" ] is not consistant with our usal boolean values
14:46
<Gadi>
alkisg: ie, if we said: if boolean_is_true $LTSP_CONFIG....
14:46
we would need to source it first
14:46
<vagrantc>
true, y, True, Y should all be valid.
14:46
<alkisg>
Ah... is that worth all the hassle? "PATH="" boolean_is_true True 2>/dev/null || . /usr/share/ltsp/ltsp-common-functions || true"
14:46
<vagrantc>
but i'm willing to make an exception for the performance gain with this one...
14:46
<Gadi>
but, vagrantc doesn't use boolean_is_true anywhere else for LTSP_CONFIG
14:46
<alkisg>
instead of just ". /usr/share/ltsp/ltsp-common-functions" ?
14:46
<vagrantc>
what's with the PATH stuff?
14:47
<Gadi>
vagrantc: to check for the existence of a function
14:47alexqwesa has joined #ltsp
14:47
<Gadi>
shell will look for function and then look for an executable in PATH
14:47
<vagrantc>
ah.
14:47
<Gadi>
which takes some time
14:47
<vagrantc>
sure.
14:48
<Gadi>
by setting PATH="", it returns an error right away
14:48
<vagrantc>
clever. might be good to document in the comments
14:48
<Gadi>
probably
14:48
<alkisg>
OK, here it is visually: http://ltsp.pastebin.com/m5bc612df
14:48
<Gadi>
but, then we would never forget it
14:48
<knipwim>
johnny: i have been looking at an ltsp profile
14:49
<Gadi>
and it would lose the mystery
14:49
:)
14:49
<johnny>
knipwim, cool
14:49
<knipwim>
and i can symlink it
14:49
<johnny>
does it work from eselect-profile? even from the overlay?
14:49
<knipwim>
nope, not with an eselect
14:49
<johnny>
knipwim, it would be nice if we could get an rsync overlay
14:49
instead of git
14:49
<knipwim>
all eselect can do, is select from /usr/portage/profiles
14:49
<johnny>
or find a way to replicate from rsync
14:49
<vagrantc>
Gadi: you can have your mysterious fork of LTSP :)
14:49
<Gadi>
alkisg: I would keep the PATH="" ... stuff in the second version
14:50
<vagrantc>
"purged all comments to improve performance!"
14:50
<johnny>
rsync would mean no git..
14:50mushroomblue has quit IRC
14:50
<Gadi>
in case someone sources l-c-f in their script
14:50
<alkisg>
Gadi, why? Just for the mystery, or some deeper reason?
14:50
<Gadi>
before ltsp_config
14:50
<johnny>
knipwim, perhaps you can publish the profile as to the profile maintainers
14:50
<alkisg>
OK, then another safeguard variable there :D
14:50
<Gadi>
:)
14:51
<knipwim>
johnny: you think that would work, for a development overlay?
14:51
<Gadi>
its handy when we have lots of hands in the same pot to have some 0-delay safeguards
14:51
:)
14:51
<knipwim>
when it's easy to solve in our situation
14:51
<johnny>
guess we can wait..
14:51
<knipwim>
removing the stage symlink
14:51
<johnny>
can we just copy it from the overlay..?
14:51
<knipwim>
and symlinking our own from the overlay
14:51* Gadi figures anything shell does in shell is worth the code
14:51
<vagrantc>
ah, at first i was wondering if setting PATH would break boolean_is_true ... but then i noticed i switched it to pure shell at some point.
14:51
<knipwim>
johnny: same difference i think
14:52
also two commands nesessary
14:52
<johnny>
i dont think it should be in ltsp trunk
14:52
<knipwim>
no, don't get me wrong
14:52
i symlink it from the overlay
14:52
<johnny>
symlinking to the overlay is fine
14:52
until we get it upstreamed
14:52
<knipwim>
i put the ltsp packages in packages
14:52
<Gadi>
do u guys want me to make those changes now?
14:53
<knipwim>
so they're in system
14:53
<Gadi>
or is someone else doing it?
14:53
<johnny>
knipwim, ah.. neat
14:53
we can also drop some of the stuff we do in quickstart
14:53
and the plugin
14:54
yay!
14:54
<knipwim>
which plugin?
14:54
<johnny>
can you unmask stuff in the profile?
14:54
ltsp trunk plugin
14:55
<knipwim>
unfortunately, you can't unmask stuff
14:55
<johnny>
knipwim, we really do need a place to store the trunk ...
14:55
err store the ltsp packages that are tagged
14:55
<knipwim>
why?
14:55
<johnny>
i wish ltsp.org would store tars for us :(
14:55
we wouldn't have to require bzr..
14:55
<alkisg>
Gadi, I don't think anyone's doing them, so feel free to do so...
14:55
<Gadi>
roger that
14:55
<knipwim>
it would save some build time
14:56
<johnny>
please ltsp peeps.. why can't you generate tars for us..
14:56
:(
14:56
<vagrantc>
Gadi: i'm not touching it today
14:56
<johnny>
knipwim, is there any way we can use debs :(
14:56
<knipwim>
sounds bad
14:56
can't the sourceforge page be used to store tars?
14:58
<johnny>
nobody uses tars knipwim
14:58
they all pull from bzr
14:58
and make packages from that based on the tags
14:58* vagrantc wishes tarballs were used
14:58
<johnny>
just like we do
14:58scottmaccal has quit IRC
14:58
<vagrantc>
but i gave up that fight long ago
14:58
<johnny>
vagrantc, then help me get them published somewhere :)
14:58
vagrantc, there are 3 of us who want it
14:58
isn't that enough?
14:59
<vagrantc>
johnny: well, if we have a spotty tarball repository, what's the point?
14:59
<johnny>
spotty?
14:59
it should be cronned
14:59
<vagrantc>
johnny: and if all distros aren't using them, what's the point?
14:59
<johnny>
2 would be
14:59
debian and gentoo
14:59
isn't 2 enough?
14:59
<vagrantc>
don't know...
14:59
<johnny>
why can't freakin launchpad generate tars for us
15:00
:(
15:00hersonls has quit IRC
15:00
<johnny>
based on tags
15:00
that'd be cool enough
15:00
<vagrantc>
johnny: if one distro generates a tarball with the same version, but actually different automake cruft... then we have an inconsistancy...
15:01
which we get from bzr anyways ...
15:01
but i'd want to at least have commitment from the ubuntu folks to use it, as lately i've just been pulling the tarballs from ubuntu.
15:01
so there's at least consistancy across those two distros.
15:02
<johnny>
src tarballs
15:02
not compiled..
15:02
<vagrantc>
johnny: the other thing we could do is have a script that checks the various distro pages and consolidates the tarballs
15:02
yes.
15:02
<johnny>
src pre autogen
15:02
so nothing would be different
15:02
<vagrantc>
ah.
15:02
<johnny>
not sure what you're talking about
15:02
<vagrantc>
mildly interesting.
15:02
<johnny>
isn't that what you use for src debs? pre autogened tarballs from upstream?
15:03
<vagrantc>
mostly not interested, i guess.
15:03
<johnny>
or pre anything right..
15:03
<vagrantc>
johnny: no, the tarballs include the ./autogen.sh stuff
15:03
johnny: we use mkdst to release a tarball.
15:03Egyptian[Home] has quit IRC
15:03
<johnny>
oh.. well we can rely on an tarball with just configure most of the time..
15:04
<vagrantc>
well, the autogen stuff is what creates the configure script.
15:06alexqwesa has quit IRC
15:09
<stgraber>
root@ltsp-root01:~# ls /opt/ltsp/edubuntu/proc/
15:09
root@ltsp-root01:~#
15:09
alkisg: ^
15:09
that's after a: ltsp-build-client --fat-client --arch i386 --dist lucid --fat-client-desktop edubuntu-desktop --skipimage --prompt-rootpass --chroot edubuntu
15:09
so the thing that keeps /proc mounted in your case must be because you are using a full gnome desktop
15:10
<alkisg>
Probably
15:10
It must be reusing some existing daemon
15:10
<stgraber>
so it should be safe to umount -l then
15:10
<alkisg>
I'd better keep it as it is, in the 030-fat-client code then
15:11
And just put more documentation on top of the umount -l :D
15:11
Or should we move it to ltsp-update-image?
15:12
stgraber: erm... did you *remove* the umount -l from the 030-fat-client code before testing? :D
15:14* alkisg forgot to remind you about that, sorry...
15:14
<stgraber>
alkisg: I did
15:14
<alkisg>
Nice
15:15spectra has quit IRC
15:15bobby_C has joined #ltsp
15:15
<alkisg>
I'll try it again tomorrow without X running
15:15alexqwesa has joined #ltsp
15:18nathankidd has joined #ltsp
15:19alexqwesa has quit IRC
15:19nathankidd has quit IRC
15:25Egyptian[Home] has joined #ltsp
15:26
<knipwim>
johnny: i also had the idea to put the timezone script in quickstart into the proper pre_set_timezone() function
15:27
and remove the TODO on "much of this shell code can go into a pre install or post install script"
15:27dmarkey_ is now known as dmarkey
15:27
<johnny>
knipwim, that includes the way i was setting package.keywords
15:27
that's the part i was talking about
15:28
mostly
15:28
so until you fix that
15:28
<knipwim>
ah :)
15:28
<johnny>
don't remove the TODO
15:28
i meant all shell code in there
15:28
including the cat >
15:28
<knipwim>
i'll get back to you on the TODO when it's all removed
15:28
in a couple of years hopefully
15:29
but using the pre_set_timezone() function?
15:32Egyptian[Home]1 has joined #ltsp
15:37Egyptian[Home] has quit IRC
15:37Egyptian[Home]1 is now known as Egyptian[Home]
15:53alkisg has quit IRC
15:58alexqwesa has joined #ltsp
16:00vvinet has quit IRC
16:00
<johnny>
knipwim, sure..
16:02bieb has left #ltsp
16:06alexqwesa has quit IRC
16:06Appiah_ has quit IRC
16:06Appiah has joined #ltsp
16:16alexqwesa has joined #ltsp
16:17hersonls has joined #ltsp
16:17alexqwesa has quit IRC
16:19hersonls has quit IRC
16:20
<stgraber>
http://www.stgraber.org/download/bootchart-ltsp-20100119.png <-- updated bootchart, details on ltsp-devel
16:25alexqwesa has joined #ltsp
16:31
<knipwim>
johnny: http://bazaar.launchpad.net/~wimmuskee/ltsp/ltsp-gentoo-dev/revision/1492
16:31Gadi has left #ltsp
16:32mikkel has quit IRC
16:32
<johnny>
hmm.. why are you timezone in pre_set_timezone?
16:32
i think that's why didn't use it..
16:33
<knipwim>
because the actual timezone is set in set_timzone(), which runs after pre_Set_timezone
16:34
ah, you mean the timezone command
16:36
i believe it works from the pre_set function
16:38prpplague is now known as prpplague_afk
16:43
<johnny>
sure
16:43
but that seems weird..
16:44
<knipwim>
howcome? we put a timezone script in the intended place?
16:56
<johnny>
no..
16:56
that you put the timezone command in the wrong place
16:56
it looks like it could cause a recursion error
16:56
that is..
16:56
even if it doesn't
16:57
it sure looks like it should
16:57
as in.. it looks like an infinite loop
16:57
timezone calls pre_set_timezone, which calls timezone which calls pre_set_timezone, etc...
16:58
i guess quickstart doesn't load the file like that..
16:58
but still..
17:10MaRX-Mode has quit IRC
17:10lucascoala has quit IRC
17:10cyberorg has quit IRC
17:10Sarten-X2 has quit IRC
17:10comfrey_ has quit IRC
17:10jhutchins_lt has quit IRC
17:10elias_a has quit IRC
17:10lupine_85 has joined #ltsp
17:10jhutchins_lt has joined #ltsp
17:12elias_a has joined #ltsp
17:12comfrey has joined #ltsp
17:13Sarten-X has joined #ltsp
17:13cyberorg has joined #ltsp
17:15
<vagrantc>
sbalneav: do you know if your commit ito ltspfs: 120: "Files are now user-owned only" actually requires setting AM_PROG_CC_C_O in configure.ac ?
17:16MaRX-Mode has joined #ltsp
17:22bobby_C has quit IRC
17:30
<knipwim>
johnny: you're right
17:30
probable have to do the timezone function after the pre_set
17:32mgariepy has quit IRC
17:40rhodan_ has joined #ltsp
17:42rhodan has quit IRC
17:42vvinet has joined #ltsp
17:52vagrantc has quit IRC
17:56vagrantc has joined #ltsp
18:07
<stgraber>
I'm not really happy with the commit I just did but it seems like I don't get run_parts working properly by just having ltsp_config sourced (or not sourcing it because it's already in the environment)
18:08
a quick guess would be that we export variables which works fine but the same doesn't apply to functions so they don't get available and we get some errors.
18:18vagrantc has quit IRC
18:20GGD_ has joined #ltsp
18:45staffencasa has quit IRC
19:00Faithful has joined #ltsp
19:23CAN-o-SPAM has quit IRC
19:51vlt has quit IRC
19:51vlt has joined #ltsp
20:08sene has quit IRC
20:19
<sbalneav>
Evening all
20:20
<GGD_>
evening
20:20japerry has joined #ltsp
20:53litlebuda has quit IRC
21:09GGD_ has quit IRC
21:14Egyptian[Home] has quit IRC
21:26vvinet has quit IRC
21:26vvinet has joined #ltsp
22:14tstafford_ has joined #ltsp
22:20ball has joined #ltsp
22:54vagrantc has joined #ltsp
22:55ball has left #ltsp
23:05* vagrantc wonders how well japanese is registered by ltsp-build-client
23:11Egyptian[Home] has joined #ltsp
23:44cyberorg has quit IRC
23:44cyberorg has joined #ltsp