IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 January 2010 (all times are UTC)
| 00:00 | pasmen has joined #ltsp | |
| 00:11 | alkisg has joined #ltsp | |
| 00:15 | <alkisg> vagrantc, ping?
| |
| 00:16 | pasmen 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:16 | artista_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:20 | ball 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:28 | alexqwesa_ has quit IRC | |
| 00:35 | Faithful has quit IRC | |
| 00:39 | alexqwesa_ has joined #ltsp | |
| 00:40 | mikkel has joined #ltsp | |
| 00:51 | Selveste1___ has quit IRC | |
| 01:21 | kmin has joined #ltsp | |
| 01:22 | <kmin> hi room
| |
| 01:22 | i need help
| |
| 01:23 | Selveste1___ 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:27 | otavio 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:42 | Barbosa 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:44 | otavio 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:52 | Selveste1___ has quit IRC | |
| 01:53 | Selveste1___ has joined #ltsp | |
| 01:55 | Barbosa_ 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:07 | gnunux 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:25 | otavio 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:28 | otavio 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:03 | vagrantc 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:09 | Selveste1___ has quit IRC | |
| 03:09 | <kmin> brb
| |
| 03:09 | kmin has left #ltsp | |
| 03:13 | <zamba> alkisg: wan, not wifi :)
| |
| 03:13 | Selveste1 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:20 | cyberorg has quit IRC | |
| 03:50 | kmin 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:09 | kmin has left #ltsp | |
| 04:10 | Pod2 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:10 | cyberorg 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:25 | hersonls has joined #ltsp | |
| 05:50 | ogra has quit IRC | |
| 05:50 | ogra has joined #ltsp | |
| 05:51 | bobby_C has joined #ltsp | |
| 05:51 | <Appiah> zamba: check out winetricks too
| |
| 06:12 | <zamba> Appiah: ok.. thanks again :)
| |
| 06:13 | pmatulis has joined #ltsp | |
| 06:14 | Selveste1 has quit IRC | |
| 06:14 | Selveste1 has joined #ltsp | |
| 06:29 | vvinet has quit IRC | |
| 06:51 | Selveste1 has quit IRC | |
| 06:51 | mikkel has quit IRC | |
| 06:52 | Selveste1 has joined #ltsp | |
| 07:00 | dro has joined #ltsp | |
| 07:05 | evilx has quit IRC | |
| 07:05 | evilx has joined #LTSP | |
| 07:08 | Selveste1_ has joined #ltsp | |
| 07:09 | Selveste1 has quit IRC | |
| 07:10 | cliebow has joined #ltsp | |
| 07:15 | alkisg has quit IRC | |
| 07:17 | cliebow has quit IRC | |
| 07:32 | vvinet has joined #ltsp | |
| 07:34 | scottmaccal has joined #ltsp | |
| 07:36 | lucascoala_ has joined #ltsp | |
| 07:43 | litlebuda has joined #ltsp | |
| 07:43 | lucascoala has quit IRC | |
| 07:43 | CAN-o-SPAM has joined #ltsp | |
| 07:57 | alexqwesa_ has quit IRC | |
| 08:00 | Gadi has joined #ltsp | |
| 08:09 | grey-monkey has left #ltsp | |
| 08:13 | alkisg has joined #ltsp | |
| 08:13 | alexqwesa_ has joined #ltsp | |
| 08:18 | mgariepy 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:24 | prpplague_afk is now known as prpplague | |
| 08:38 | bieb has joined #ltsp | |
| 08:45 | <sbalneav> Morning all
| |
| 08:46 | <alkisg> Hi Scotty!
| |
| 08:54 | cliebow 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:43 | Selveste1_ has quit IRC | |
| 09:44 | Selveste1_ has joined #ltsp | |
| 09:46 | ball has joined #ltsp | |
| 10:04 | etyack has joined #ltsp | |
| 10:11 | bobby_C has quit IRC | |
| 10:13 | gnunux has quit IRC | |
| 10:13 | etyack 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:15 | staffencasa has joined #ltsp | |
| 10:18 | lucascoala_ has quit IRC | |
| 10:19 | lucascoala has joined #ltsp | |
| 10:23 | pem725 has joined #ltsp | |
| 10:24 | alexqwesa_ 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:41 | dmarkey has quit IRC | |
| 10:41 | jbrett has quit IRC | |
| 10:41 | vlt has quit IRC | |
| 10:41 | Egyptian[Home] has quit IRC | |
| 10:41 | stgraber has quit IRC | |
| 10:41 | Ryan52 has quit IRC | |
| 10:41 | Appiah has quit IRC | |
| 10:41 | dmarkey_ has joined #ltsp | |
| 10:41 | Appiah_ has joined #ltsp | |
| 10:41 | stgraber_ has joined #ltsp | |
| 10:41 | pem725 has quit IRC | |
| 10:41 | vlt has joined #ltsp | |
| 10:41 | Ryan52 has joined #ltsp | |
| 10:42 | jbrett has joined #ltsp | |
| 10:42 | tarbo has joined #ltsp | |
| 10:42 | jhutchins has joined #ltsp | |
| 10:43 | Egyptian[Home] has joined #ltsp | |
| 10:46 | Selveste1_ has quit IRC | |
| 10:47 | pem725 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:57 | mfdutra has joined #ltsp | |
| 11:01 | staffencasa has quit IRC | |
| 11:04 | staffencasa 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:13 | Selveste1_ 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:19 | cliebow has quit IRC | |
| 11:19 | cliebow 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:37 | cliebow has quit IRC | |
| 11:37 | cliebow 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:50 | ball 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:00 | Pod2 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:07 | alexqwesa 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:18 | dro has quit IRC | |
| 12:18 | dro 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:33 | rhodan has joined #ltsp | |
| 12:37 | <mfdutra> stgraber_, hi. does ltsp-cluster also balance the nbd server or only the X server?
| |
| 12:37 | Barbosa has quit IRC | |
| 12:37 | Barbosa 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:50 | spectra 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:04 | stgraber_ 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:06 | MaRX-Mode has quit IRC | |
| 13:06 | <Gadi> it may have been introduced with w2k8
| |
| 13:06 | MaRX-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:08 | japerry 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:12 | dro has quit IRC | |
| 13:15 | * alkisg logs off and starts killing stuff | |
| 13:16 | alkisg has quit IRC | |
| 13:18 | dro has joined #ltsp | |
| 13:37 | alkisg has joined #ltsp | |
| 13:39 | mfdutra 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:42 | cliebow has quit IRC | |
| 13:42 | dro 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:42 | dro 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:44 | loathing 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:08 | vagrantc has joined #ltsp | |
| 14:11 | dro has quit IRC | |
| 14:14 | dro 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:19 | pmatulis has quit IRC | |
| 14:20 | mikkel has joined #ltsp | |
| 14:21 | vmlintu has joined #ltsp | |
| 14:23 | vmlintu_ has quit IRC | |
| 14:28 | alexqwesa 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:32 | dro 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:36 | alexqwesa 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:47 | alexqwesa 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:50 | mushroomblue 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:58 | scottmaccal 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:00 | hersonls 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:03 | Egyptian[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:06 | alexqwesa 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:15 | spectra has quit IRC | |
| 15:15 | bobby_C has joined #ltsp | |
| 15:15 | <alkisg> I'll try it again tomorrow without X running
| |
| 15:15 | alexqwesa has joined #ltsp | |
| 15:18 | nathankidd has joined #ltsp | |
| 15:19 | alexqwesa has quit IRC | |
| 15:19 | nathankidd has quit IRC | |
| 15:25 | Egyptian[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:27 | dmarkey_ 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:32 | Egyptian[Home]1 has joined #ltsp | |
| 15:37 | Egyptian[Home] has quit IRC | |
| 15:37 | Egyptian[Home]1 is now known as Egyptian[Home] | |
| 15:53 | alkisg has quit IRC | |
| 15:58 | alexqwesa has joined #ltsp | |
| 16:00 | vvinet has quit IRC | |
| 16:00 | <johnny> knipwim, sure..
| |
| 16:02 | bieb has left #ltsp | |
| 16:06 | alexqwesa has quit IRC | |
| 16:06 | Appiah_ has quit IRC | |
| 16:06 | Appiah has joined #ltsp | |
| 16:16 | alexqwesa has joined #ltsp | |
| 16:17 | hersonls has joined #ltsp | |
| 16:17 | alexqwesa has quit IRC | |
| 16:19 | hersonls has quit IRC | |
| 16:20 | <stgraber> http://www.stgraber.org/download/bootchart-ltsp-20100119.png <-- updated bootchart, details on ltsp-devel
| |
| 16:25 | alexqwesa has joined #ltsp | |
| 16:31 | <knipwim> johnny: http://bazaar.launchpad.net/~wimmuskee/ltsp/ltsp-gentoo-dev/revision/1492
| |
| 16:31 | Gadi has left #ltsp | |
| 16:32 | mikkel 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:38 | prpplague 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:10 | MaRX-Mode has quit IRC | |
| 17:10 | lucascoala has quit IRC | |
| 17:10 | cyberorg has quit IRC | |
| 17:10 | Sarten-X2 has quit IRC | |
| 17:10 | comfrey_ has quit IRC | |
| 17:10 | jhutchins_lt has quit IRC | |
| 17:10 | elias_a has quit IRC | |
| 17:10 | lupine_85 has joined #ltsp | |
| 17:10 | jhutchins_lt has joined #ltsp | |
| 17:12 | elias_a has joined #ltsp | |
| 17:12 | comfrey has joined #ltsp | |
| 17:13 | Sarten-X has joined #ltsp | |
| 17:13 | cyberorg 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:16 | MaRX-Mode has joined #ltsp | |
| 17:22 | bobby_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:32 | mgariepy has quit IRC | |
| 17:40 | rhodan_ has joined #ltsp | |
| 17:42 | rhodan has quit IRC | |
| 17:42 | vvinet has joined #ltsp | |
| 17:52 | vagrantc has quit IRC | |
| 17:56 | vagrantc 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:18 | vagrantc has quit IRC | |
| 18:20 | GGD_ has joined #ltsp | |
| 18:45 | staffencasa has quit IRC | |
| 19:00 | Faithful has joined #ltsp | |
| 19:23 | CAN-o-SPAM has quit IRC | |
| 19:51 | vlt has quit IRC | |
| 19:51 | vlt has joined #ltsp | |
| 20:08 | sene has quit IRC | |
| 20:19 | <sbalneav> Evening all
| |
| 20:20 | <GGD_> evening
| |
| 20:20 | japerry has joined #ltsp | |
| 20:53 | litlebuda has quit IRC | |
| 21:09 | GGD_ has quit IRC | |
| 21:14 | Egyptian[Home] has quit IRC | |
| 21:26 | vvinet has quit IRC | |
| 21:26 | vvinet has joined #ltsp | |
| 22:14 | tstafford_ has joined #ltsp | |
| 22:20 | ball has joined #ltsp | |
| 22:54 | vagrantc has joined #ltsp | |
| 22:55 | ball has left #ltsp | |
| 23:05 | * vagrantc wonders how well japanese is registered by ltsp-build-client | |
| 23:11 | Egyptian[Home] has joined #ltsp | |
| 23:44 | cyberorg has quit IRC | |
| 23:44 | cyberorg has joined #ltsp | |