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


Channel log from 10 March 2010   (all times are UTC)

00:00
<johnny>
for not enough benefit
00:05alex789 has joined #ltsp
00:07alexqwesa__ has quit IRC
00:08Wastrel_ has left #ltsp
00:31mordocai has quit IRC
01:01daya has quit IRC
01:39alkisg has quit IRC
01:59try2free has joined #ltsp
02:13try2free has quit IRC
02:13stgraber has quit IRC
02:15evilx_ has joined #ltsp
02:19stgraber has joined #ltsp
02:19evilx has quit IRC
02:24Ahmuck has quit IRC
02:34daya_ has joined #ltsp
02:44alkisg has joined #ltsp
03:01mikkel has joined #ltsp
03:13ogra_cmpc has quit IRC
03:14ogra_cmpc has joined #ltsp
03:25alex789 is now known as alexqwesa
03:27highvoltage has quit IRC
03:29highvoltage has joined #ltsp
03:49Comete has joined #ltsp
03:49
<Comete>
hi
03:51
i just update my Edubuntu 9.10 LTSP server with LTSP 5.2.1 and encounter a strange problem
03:52
it seems that when i start 2 or more thinclients at the same time, the dhcp server tries to give them the same ip address
03:54
as a result i get for example 2 thinclients with LDM connection screens showing both "ltsp171 (192.168.3.171)" at the bottom right of the screen
03:54
<alkisg>
Comete: LTSP 5.2.1? What do you mean?
03:55
5.2 is the last version, and it's not in the karmic repositories
03:55
<Comete>
alkisg: the last update from stgraber ppa
03:55
<alkisg>
Ah, let me see which version it has...
03:55
!stgraber-ppa
03:55
<ltspbot>
alkisg: "stgraber-ppa" :: https://launchpad.net/~stgraber/+archive/ppa
03:56
<Comete>
there is a backport for karmic
03:56
<alkisg>
Comete: yeah, you need this one: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1707
03:57
stgraber: that "quoted clientid bug" was kinda serious, so you might want to upload a new version to your ppa
03:57pths has quit IRC
03:58
<Comete>
alkisg: how can i update to this new version ?
03:58ogra_cmpc has quit IRC
03:58
<alkisg>
Get this file: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/annotate/head%3A/client/initramfs/scripts/init-premount/udhcp
03:58
(click on download file)
03:59
save it to: /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp
03:59
run: sudo chroot /opt/ltsp/i386 update-initramfs -u
03:59ogra_cmpc has joined #ltsp
04:00
<alkisg>
sudo ltsp-update-kernels
04:00
Then reboot the clients...
04:00otavio has quit IRC
04:00
<Comete>
oh thanks a lot !
04:04
alkisg: do i need to start a ltsp-update-image too ?
04:04
<alkisg>
No
04:06
<Comete>
alkisg: it says: Generating /boot/initrd.img-2.6.31-19-generic but i'm using 2.6.31-20-pae on my server, is it normal ?
04:06
<alkisg>
Yes - you just haven't updated your chroot recently
04:07
<Comete>
alkisg: so i should run "apt-get dist-upgrade" in my chroot ?
04:07pts has joined #ltsp
04:07
<alkisg>
If you want... it's not related to the udhcp problem
04:08
some notes for this are here: https://help.ubuntu.com/community/UbuntuLTSP/UpdatingChroot
04:12
<Comete>
alkisg: thanks
04:12
<alkisg>
np
04:14otavio has joined #ltsp
04:15
<Comete>
alkisg: another problem that was reported by the school where the LTSP server is in use, it seems that all the operations on thinclients are very slow after starting 5 or more thinclients
04:16
<alkisg>
It's usually either network speed or cpu usage
04:16
LDM_DIRECTX helps a ton for cpu usage, see the docs
04:16
!docs
04:16
<ltspbot>
alkisg: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
04:16
<Comete>
alkisg: they are using a server with 4G RAM and a Pentium 4 3Ghz on a 100mb network
04:16
alkisg: i already enable this
04:17
<alkisg>
100mbps isn't good for a lot of clients
04:17
You need to upgrade to gigabit, at least from the server to the switch
04:17
Or, you could try trunking with 3-4 NICs on the server, that would also help
04:18
<Comete>
ok i will try this
04:19
alkisg: they have 14 thinclients
04:19
<alkisg>
With 100mbps cards?
04:21
<Comete>
yes
04:21
and 512M RAM
04:21
<alkisg>
Get a switch with at least one gigabit port, and an intel gigabit nic on the server, and disable flow control. That will make your network 10 times faster... https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
04:24
With 512 ram, you could also run some stuff as localapps
04:24
E.g. firefox/flash. That would save you a lot of bandwidth as well.
04:25
<Comete>
ok i will try that too
04:26
thanks for these nice informations :)
04:44
alkisg: is it a good idea to use NETWORK_COMPRESSION=YES too ?
04:45
<alkisg>
No, any compression/encryption raises the server cpu usage too much. Good for security but not for performance...
04:45
<Comete>
ok
04:46
alkisg: the fix for udhcp works
04:46
<alkisg>
Good, i hope stgrabers updates his ppa soon.
04:46
<Comete>
alkisg: i must leave now, thanks a lot again for the help :)
04:46
<alkisg>
You're welcome, bye bye
04:48
<Comete>
bye
04:48Comete has quit IRC
04:52alkisg has quit IRC
04:53Selveste1 has joined #ltsp
04:56alkisg has joined #ltsp
05:01ogra has quit IRC
05:02ogra has joined #ltsp
05:13daya_ has quit IRC
05:25Selveste1 has quit IRC
05:29alkisg has quit IRC
05:30alkisg has joined #ltsp
05:56Selveste1 has joined #ltsp
06:16pmatulis has joined #ltsp
06:19Selveste1 has quit IRC
06:19Selveste1 has joined #ltsp
06:20alkisg has quit IRC
06:20alexqwesa has quit IRC
06:21scottmaccal has joined #ltsp
06:21alexqwesa has joined #ltsp
06:22alkisg has joined #ltsp
06:23tthorb_ has joined #ltsp
06:26tthorb has quit IRC
06:30igudym has joined #ltsp
06:30
<igudym>
hi
06:31
i try to upgrade my fedora 9 based ltsp setup to newer fedora 12
06:31
and have some troubles
06:32
does anybody using fedora 12
06:32
?
06:32
after two days of frustration i ready to migrate to ubuntu
06:34
is it have sence?
06:41ogra_cmpc has quit IRC
06:42ogra_cmpc has joined #ltsp
06:45* alkisg can only testify that there are more ubuntu users than fedora users in this room...
06:46pts is now known as pths
06:56jammcq has quit IRC
07:03
<igudym>
i have plenty of old machines - ADM K2-500 and Celeron 400
07:03
AMD K5-500
07:03
fedora's minimum kernel is i686
07:04
there is comething with tftp
07:05
some dinstance workstations not load any more (loaded with f9 just fine)
07:05
<_UsUrPeR_>
igudym: I would recommend you give Ubuntu a shot
07:07
<igudym>
two thing prevent: most of the time i use centos and fedora
07:08
i use ubuntu only on netbook
07:09
and second - i have configured and working envirenment of about 20 users
07:10
what happens to users gnome desktop and so on?
07:10
<Appiah>
um
07:11mgariepy has joined #ltsp
07:11
<Appiah>
I'm sorry I dont understand
07:11
what problems are you currently having?
07:11
<igudym>
two
07:12
1. Some clients don't start kernel - it i686 only
07:12
2. Some clients don't even load kernel and initrd
07:13
<Appiah>
so what error do you get when these clients PXE boot?
07:13
if we start with no1
07:14
<igudym>
1. Kernel say something about feature is't missing and stops
07:14
<Appiah>
please get the exact message
07:15weenus has joined #ltsp
07:15
<igudym>
minutes
07:21vvinet has quit IRC
07:23
<weenus>
I'm getting pxelinux.0 tftp file not found for some unknown reason. Anyone see anything wrong with my dhcpd.conf file? http://pastebin.com/BuVgeZix
07:25weenus has left #ltsp
07:25
<igudym>
This kernel requires the following features not present on the CPU:
07:25
cmov
07:25
Unable to boot - please use a kernel appropriate to your CPU.
07:27
weenus: filename "var/lib/tftpboot/ltsp/i386/pxelinux.0";
07:27
weenus: should be filename "/ltsp/i386/pxelinux.0";
07:28
relative to tftpboot directory
07:28
Appiah: ?
07:31
OK, what version of ubuntu start from?
07:31
last desktop or server?
07:32
<mgariepy>
morning all
07:32
<igudym>
hi
07:32
<Appiah>
igudym: are you running 64bit server?
07:33
<igudym>
no
07:33
<Appiah>
Fedora something ?
07:34cluster has joined #ltsp
07:34
<cluster>
hey
07:34
<Appiah>
"The problem is that certain CPU's, even though they are "pentium class", lack the cmov instruction. At some point a few years ago, the default 586/686 build of the booter (isolinux?) started requiring cmov"
07:34
<cluster>
im having problems booting clients
07:35
They get an IP address but the TFTP hangs with a timeout error
07:35
<igudym>
uname -s -v -r -i -m
07:35
Linux 2.6.32.9-67.fc12.i686.PAE #1 SMP Sat Feb 27 09:42:55 UTC 2010 i686 i386
07:36
<cluster>
can anyone help?
07:36
<alkisg>
cluster: they don't even load pxelinux?
07:36
<Appiah>
its your clients igudym
07:36
<igudym>
server
07:36
<Appiah>
its your clients , with the issue
07:36
<cluster>
alkisg, nope, they just hang
07:36
<alkisg>
Then it isn't a kernel problem
07:36
It's a tftp problem, or a pxelinux problem
07:37
<cluster>
its tftp
07:37
im pretty sure
07:37
basically
07:37
i had this problem yesterday
07:37
<alkisg>
Ah sorry I got mixed up with the person above
07:37
Ignore me :)
07:37
<Appiah>
cluster: all clients? or just some?
07:37* alkisg reads again...
07:37
<cluster>
all
07:37
basically it was the same problem yesterday
07:37
and i got some help in here
07:37
<alkisg>
cluster: distro/version?
07:37
<mgariepy>
cluster, does inetd started ?
07:38
<Appiah>
how did you solve it then?
07:38
<cluster>
but i was told not to use xinetd
07:38
only inetd
07:38mikkel has quit IRC
07:38
<cluster>
its ubuntu 9.10
07:38
so anyways
07:38
i came in to try out the advice i got from yday
07:38
<alkisg>
You can also use xinetd, it's just not recommented
07:38
<cluster>
but my twat mate has fiddled trying to use vnc :@ and installed xinetd
07:39
oh, well i removed xinetd
07:39
and it wanted to remove ltsp-server etc
07:39
<igudym>
Appiah: it's a kernel problem - i load it from hdd
07:39
<cluster>
so i let it, purged everything
07:39
and reinstalled it all
07:39
and now im back to square one with the tftp problem
07:39
<Appiah>
igudym: didnt you see my quoted paste?
07:39
<igudym>
"The problem is that certain CPU's, even though they are "pentium class", lack the cmov instruction. At some point a few years ago, the default 586/686 build of the booter (isolinux?) started requiring cmov"
07:40
that?
07:40
<Appiah>
your kernel wont run on those clients
07:40
<alkisg>
cluster: ok. Is tftp running? sudo netstat -nap | grep :69
07:40
<Appiah>
yes that
07:40
<cluster>
"TFTP open timeout"
07:40
<igudym>
i know it
07:40
my kernel want run
07:40jammcq has joined #ltsp
07:40
<cluster>
XD appraently not
07:40
<jammcq>
howdie all
07:40
<alkisg>
cluster: grep tftp /etc/inetd.conf
07:40
<igudym>
i want to know - what kernel will run
07:40
<cluster>
but i tried ps -efw|grep :69 and that worked so :S
07:41
that returned nothing either alkisg
07:41
i feel stupid now :$ lol
07:41
<igudym>
ok, one more issue
07:41
<alkisg>
cluster: cat /etc/default/tftpd-hpa
07:42
(to pastebin)
07:42
!pastebot
07:42
<ltspbot>
alkisg: "pastebot" :: The LTSP pastebot is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
07:42
<igudym>
when i load old (from fedora 9) kernel and mount it to old i368 chroot it loads to ldm
07:43
and command prompt sessions started as well
07:43
but when i log in to server - client hangs
07:44
<cluster>
http://pastebin.com/bxftmfQL
07:45
<alkisg>
TFTP_ADDRESS="0.0.0.0:69"
07:45
TFTP_OPTIONS="--secure"
07:45
Add also those, but mainly you need an entry in inetd
07:45
<cluster>
me?
07:46
<alkisg>
cluster: Yes, also add this line to inetd.conf:
07:46
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
07:46
Then run: sudo openbsd-inetd force-reload
07:46
Then restart your client...
07:46
*sorry
07:46
sudo service openbsd-inetd force-reload
07:47
<cluster>
so this is right now? http://pastebin.com/hEPyPKEH
07:47
<alkisg>
Yup
07:47
<cluster>
cool
07:48markit has joined #ltsp
07:48
<markit>
hi, I would like some clients "log" in a different GNU/Linux server (not the ltsp server), is it possible? what setup in lts.conf?
07:49
some of them already to rdesktop to a win2003 server
07:50
I would like to do something similare but with a X-Server and logging in a GNU/Linux server instead
07:54
<cluster>
alkisg: Thank you so much! They boot now :D
07:54
<alkisg>
You're welcome
07:55
<cluster>
Byye, Thanks Again :D
07:55cluster has quit IRC
07:55
<alkisg>
mgariepy: the new tty fix sometimes leaves the client on screen_02... I don't know if that would be considered a bug or not
07:55
As soon as I switch to vt7, X starts properly
07:56
<markit>
alkisg: hi, ltsp 5.2 ubuntu (a different installation from the one of my former question). At the ltsp login screen I enter username and password, but takes 15-20 seconds before "autenticate" and start loading desktop.. any idea? seems a timeout issue of a sort of "lookup" or reverse lookup thing...
07:56
<alkisg>
I guess that it would be nice to have just 1 chvt, to switch to the one with DISPLAY set...
07:57
<markit>
any parameter/config I can be missing?
07:57
<alkisg>
markit: regular thin clients in karmic?
07:57
(or fat? or lucid? etc)
07:57
<markit>
regular karmic
07:57
(the installation is not here but at my home, so I can't test right now)
07:58
<alkisg>
It shouldn't need any dns to function properly, but you might try to put entries in /etc/hosts to see if it improves
07:58
1.2.3.4 ltsp4, 1.2.3.5 ltsp5 etc
07:58
You could also try wireshark
07:58
<markit>
alkisg: mm at the moment is a dhcp assignment, do you suggest to use fix ip?
07:58
<alkisg>
No, just put dns entries for all the available dhcp leases
07:59
e.g. even 200 of them... you can quickly write them in calc
07:59
<markit>
but I can't tell what IP a client will get... oh, I see..their name will be formed with the IP anyway
07:59
<alkisg>
The name doesn't really matter
07:59
It might as well be different than the one actually assigned to the client
08:00
<markit>
so dns resolution will fail...
08:00* markit confused
08:00
<alkisg>
No dns resolution will be needed if you have an entry in /etc/hosts
08:01
<markit>
ok, but I will have an entry like 192.168.1.101 ltsp101
08:01
<alkisg>
Yup
08:01
<markit>
then I boot a client, that wil be ltsp101 but dhcp will assign it 192.168.1.102
08:01
<alkisg>
Then it will be ltsp102
08:01
Not 101
08:01
<markit>
ok, I've got it now :)
08:01
<alkisg>
I assume you don't actually have a dns server in your ltsp server, right?
08:02
Here's a script to help you: i=100; while [ $i -lt 110 ]; do echo 192.168.1.$i ltsp$i; i=$((i+1)); done
08:02
<markit>
well, I'm usin dnsmasq
08:02Gadi has joined #ltsp
08:02
<alkisg>
Do you have port=0 in dnsmasq.conf ?
08:02
If you don't, then you do have a dns server running
08:03
<markit>
I use it as dns server, for cache purpouse
08:03
but it know nothing about ltspxxx names
08:03
<alkisg>
OK, try putting the ltsp client declarations in /etc/hosts
08:03
dnsmasq will read them from there
08:04
<markit>
ok, thanks, sure
08:04
<alkisg>
...and won't do reverse lookups (presuming that's the problem)
08:04
<markit>
another problem ....
08:04
I've tried your gPXE
08:04
<alkisg>
Which one? the one that adds a grub2 entry?
08:04
<markit>
and gets the address and starts booting MUCH faster than nic PXE
08:05
alkisg: the .iso one
08:05
<alkisg>
OK, that's rom-o-matic's gpxe, not mine :)
08:05
<markit>
but alsot he grub entry, AFAIR, is faster than rom pxe
08:05
<alkisg>
So?
08:06
<markit>
I'm wondering if my dnsmasq setup is much more compatible with gPXE than "intel" PXE, and what to do
08:06
<alkisg>
Nah, I don't think so. I think your client nic has a "slow" pxe stack
08:07
Are you using dnsmasq normally, or in proxydhcp mode?
08:07
<markit>
when 5ltsp .2 was announced, I've read the blog about fast booting process, but if you sum the time it wastes with dhcp + login is slow
08:07
<alkisg>
I.e. does it assign leases?
08:07
<markit>
yes, is the "main and only" dhcp server around
08:07
<alkisg>
I think that blog was timing with bootchart, which starts counting *after* the kernel boots
08:07
<markit>
works also as lftp server
08:07
<alkisg>
So it doesn't count the bios / pxe / tftp / kernel loading time
08:08
<markit>
alkisg: I've read also about grub being able to pxe boot itself
08:08
<alkisg>
That's not production ready yet
08:09
<markit>
ah, I see, hope will be soon
08:09
<alkisg>
Gadi: with the new vt non-switching code, if I put SCREEN_02=shell and SCREEN_07=ldm, half of the times I get screen 2 and X only starts after I switch to vt7...
08:09
Would you consider that a bug?
08:09
<markit>
alkisg: thanks a lot for your help and tips :)
08:09
<alkisg>
You're welcome
08:11
<Gadi>
alkisg: thats the race condition for default screen that I referred to yesterday (we have always had that - tho, in the past, X would init and steal the vt, but since we now call openvt, X does not necessarily init until you switch to it)
08:11
<alkisg>
Gadi, right, so wouldn't it be nice to switch to the first screen that uses X?
08:11
<Gadi>
it would be nice to be able to define a default screen
08:12
as well as to have a sensible default when none is defined
08:12
<alkisg>
OK, but still, if none is defined, I guess it's reasonable to expect it to start with X
08:12
<Gadi>
what if you have ldm and rdesktop?
08:12
<alkisg>
The first one (as a default - I'm not saying that there shouldn't be an option to specify one)
08:13
But if the first (or last) one is the default, I guess the admin can specify the one it wants there
08:13
<Gadi>
I would do whats easiest and most reliable in the code
08:13
<alkisg>
The problem is that they run in parallel, so it's hard to keep track if a chvt was called or not
08:14
<Gadi>
we will definitely need a tmpfile to keep track of things
08:14
<alkisg>
We could write a simple code to check the available SCREENs...
08:15
Sort them, and chvt to the highest ldm/rdesktop one
08:15
<Gadi>
well, you need to chvt at the proper time
08:15
and only on boot - not logout
08:15
I think if we chvt in screen-session.d/ that is too early
08:15
and X will get screwed up again
08:16
I think for X sessions, we need to chvt post-xinit
08:16
meaning in xinitrc.d
08:16bobby_C has joined #ltsp
08:16
<alkisg>
But will that be called if we don't switch to that vt?
08:17
Will X start initializing?
08:17
<Gadi>
if you have ldm an rdesktop, *one* of them will init
08:17
and if it is the wrong one, you want it to chvt to the right one
08:17
<alkisg>
What if I have shell, ldm and rdesktop?
08:18
<Gadi>
for non-X screen scripts, we will have to handle it in the screen script itself
08:18
<alkisg>
I mean, in that case, screen_session (for shell) should chvt to the rdesktop screen
08:19
<Gadi>
its too hard to figure out in screen_session whether you are calling a graphical or non-graphical session
08:19
<alkisg>
(or better yet, the screen_session for rdp should switch to its own vt)
08:19
We can hardcode some values... how many are they?
08:19
ldm, rdesktop..
08:19
<Gadi>
you dont want anything switching to its own vt
08:20
you want everything switching to the same vt
08:20
(but only on boot)
08:20
why hardcode values?
08:20
<alkisg>
Why not? if they all have appropriate code, only the correct one will switch to itself
08:20
So only 1 chvt will take place
08:20
<Gadi>
just modify screen-x-common and the individual non-graphical screen scripts
08:21
er, not screen-x-common
08:21
thats too early, I think
08:21benGREEN has left #ltsp
08:21
<Gadi>
I think we need to add an xinitrc.d/ file
08:21
<alkisg>
Is xinit going to call the scripts in xinitrc.d if that vt is not active?
08:22
<Gadi>
alkisg: this whole thing started because by chvt'ing in screen_session, X ran on the wrong vt
08:22
<alkisg>
Yes, but there were too many chvt's there
08:22
I'm proposing "there should be only one"
08:22
(highlander :P)
08:22
<Gadi>
right, but lets say you had 02=shell and 07=ldm
08:23
<alkisg>
okay,...
08:23tthorb has joined #ltsp
08:23
<Gadi>
and you set your preferred default to be 02
08:23
because you like coming up to a shell
08:23
<alkisg>
okay,...
08:23
<Gadi>
if you chvt 2 in screen_session, wont we have the bug we just fixed where X will init on vt2?
08:24
<alkisg>
DEFAULT_VT=${DEFAULT_VT:-$(get_the_highest_vt_that_uses_X)}
08:24
(that's : - $ )
08:24
chvt $DEFAULT_VT
08:24
<Gadi>
before you go there -> is my assumption correct?
08:25
<alkisg>
Hmmm I'm not 100% sure
08:25
I think that may be a race condition
08:25
I.e. if chvt happens after xinit starts or something...
08:26
<Gadi>
thats what I am thinking, as well - which is why I would do it in xinitrc.d/
08:26
if I find some time, I will explore with some code
08:26tthorb_ has quit IRC
08:26
<alkisg>
But, if xinit doesn't start until you switch the VT manually, why would you also run chvt in the code?
08:27
<Gadi>
what I am thinking is this
08:27
let's say the default screen you want is 2
08:27
<alkisg>
and that's shell, ok,
08:28
<Gadi>
so, every screen script should call "chvt 2" - but only once on boot
08:28
and in their appropriate time
08:28
which means: X-based scripts after xinit, and non-X as part of their screen script
08:29
that way, no matter what comes up first, the thing that comes up first, does a chvt 2
08:29
and you land in the right spot
08:29
<alkisg>
But if 07=ldm, and we start on vt2, the ldm script won't get to run until we switch to vt7
08:29
manually
08:29
<Gadi>
not the prettiest, as for X-based script, X will init
08:29
not necessarily
08:29
as you said
08:29
<alkisg>
And at that point, it'll just switch us back to 02, which we don't want since we switched to 07 manually...
08:29
<Gadi>
half the time, it comes up to 07
08:30
and half the time to 02
08:30
for the half the time that 07 inits first, a chvt 2 will get it back to 02
08:30
<alkisg>
Right, but if it starts last, we don't want to switch back to 02
08:30
Because that means we switched manually to 07
08:31
<Gadi>
right, which is why when the first script does a chvt 2, it also touches a tmpfile
08:31
<alkisg>
I believe *only 1* chvt should happen
08:31
<Gadi>
so, the chvt never happens again
08:31
<alkisg>
No need for tmpfiles in this case...
08:31
<Gadi>
how will you keep it from chvt 2'ing the next time screen_script is called
08:31igudym has left #ltsp
08:31
<Gadi>
(say after a logout)
08:33
<alkisg>
That's a different problem - I could e.g. add something to ltsp_config
08:33
<Gadi>
I dont understand
08:34
screen_session is called in a loop
08:34
<alkisg>
. /usr/share/ltsp/ltsp_config
08:34
==> if I append "CHANGED_VT=True" in ltsp_config, it's about the same as touching a tmpfile
08:35
<Gadi>
ah, I see what you mean
08:36etyack has joined #ltsp
08:36
<Gadi>
well, if it works, I would be all in favor of switching to the first defined screen unless a SCREEN_DEFAULT is specified
08:36
<alkisg>
But if the code was able to calculate before xinit which vt is going to be active, only one chvt would be called. So only that screen_session call would add that CHANGED_VT variable - saving possible race conditions with tempfiles
08:37
<Gadi>
its still a race
08:37
<alkisg>
I'd go for the higher one, but ok, no problem
08:37
<Gadi>
hehe
08:37
I dont like reverse logic
08:37
<alkisg>
No it isn't, because only one script sets CHANGED_VT. The other scripts don't try chvt at all.
08:37
<Gadi>
people will get used to SCREEN_08=shell
08:37
:P
08:38
<alkisg>
SCREEN_01=login, always
08:38
SCREEN_07=ldm, usually
08:38
<Gadi>
its ridiculous that we use vt7 anyways
08:38
<alkisg>
That, by default, says "the higher is X" :D
08:38
<Gadi>
SCREEN_01 is never defined
08:38
<alkisg>
It isn't, but the login prompt is there
08:39
<Gadi>
well, the first one to working code wins
08:39
:P
08:39
<alkisg>
Heheh
08:39* alkisg gives up :P
08:39
<Gadi>
I was going to say -> which will prolly be you
08:39* Gadi switches gears....
08:39
<alkisg>
Nah, I have to fight with CK... :(
08:41japerry has quit IRC
08:48mikkel has joined #ltsp
08:50Selveste1 has quit IRC
08:56japerry has joined #ltsp
08:57japerry has joined #ltsp
09:13thunsucker has joined #ltsp
09:14
<markit>
alkisg: btw, do you know how can I have ltsp client load kernel,load X-Server and then try to login in a different GNU/Linux host? (not the ltsp server one)
09:15
?
09:15
<alkisg>
!lts.conf
09:15
<ltspbot>
alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
09:15
<alkisg>
See SERVER (or is it LDM_SERVER? not sure) there...
09:15
<markit>
thanks
09:15etyack has quit IRC
09:16
<markit>
btw2: do you know if I can run only SOME app locally?
09:16
<alkisg>
!localapps
09:16
<ltspbot>
alkisg: "localapps" :: to access a tutorial on setting up localapps on jaunty, see https://help.ubuntu.com/community/UbuntuLTSP/LTSPLocalAppsJaunty
09:16
<alkisg>
Erm, that's a little old, but it should give you some hints
09:16
<markit>
alkisg: thanks again :)
09:16
alkisg: last: is usb pen drive plugin in the client workinf with ubuntu 5.2?
09:17
I want students to be able to copy back home their work
09:17
<alkisg>
usb sticks? they've been working as long as I'm involved with ltsp..
09:18
<markit>
ehm, when I tried ltsp from debian was not working...
09:18
you can mount usb sticks and you, only you, can see/access it? and you are able to unmount also?
09:18
(I mean, every student can plug his usb stick, and is only visible on his desktop)
09:21
<klausade>
markit: did you try with gnome or kde on debian?
09:22
<ogra>
markit, with ltsp you dont unmount ... that happens automatically, you can just yank it out
09:23
<markit>
klausade: well, now I recall that was a rdesktop problem... that installation had to connect to wcrap2003
09:23
ogra: well, if is still writing to stick? brrr
09:23
I mean, in my local KDE4, often I copy a file, the stick does not blink until I "unmount" it
09:24
<ogra>
markit, ltspfs cares for it to unmount, just teach your users to wait until the light stops flashing
09:24
<markit>
maybe ltsp is set to write immediatly
09:24
<ogra>
right
09:24
<markit>
fabolous, thanks :)
09:24
<ogra>
the device is actually *only* mounted if there is active read or write going on
09:24
all the rest of the time (even if you browse it) its not mounted at all
09:24
<markit>
anyone has experience in a school deploy? only 8 clients (if we rise money/donations,we will have 16)
09:25
wondering how manage video streaming and if someone tested "italk" teacher manager software
09:25alkisg has quit IRC
09:25
<ogra>
its the default in edubuntu
09:25
<markit>
I'm using kubuntu (I'm a KDE lover :))
09:26
I'll have a look at edubuntu also... maybe I could install edubuntu and then use KDE4?
09:26
or is it a suicide?
09:27
<ogra>
edubuntu is just a set of selected apps ...
09:27
go on using kubuntu
09:27
what i meant to say with the above is that all/most edubuntu ltsp installs use italc ...
09:28
so its well tested/used
09:28
<markit>
I'm dreaming providing thin clients with decent video and resolution...italk is based upon vnc, wonderinf what performances are if clients get a, just to say, 1920x1080 resolution
09:29
I'll have a Gbit lan on the server and a Gbit switch, but...
09:29
<klausade>
markit: i have a few hundred ltsp school deployments under my belt, works like a charm every time.
09:29
<markit>
klausade: where are you from?
09:29
(me Italy)
09:29
<klausade>
norway.
09:29
<thunsucker>
markit: lets switch school's, most of the teachers i work with can't read anything bigger than 1024x768
09:30etyack has joined #ltsp
09:30
<markit>
any suggestion? what is the most problematic aspect? teacher resistence against "not windows solutions"? Proprietary applications for schools? Multimedia?
09:31
<klausade>
markit: if you have powerful enough clients, you should try to get localapps running, or try the half-thick approach that debian-edu has.
09:31scottmaccal has quit IRC
09:31
<markit>
at the moment are 1Ghz Athlon/duron with 256MB ram,I'm dreaming about atom based fanless thin clients, but are not much more powerful
09:32etyack1 has joined #ltsp
09:32
<johnny>
markit, the important thing is ram..
09:32
<markit>
johnny: server will have 8GB, 4core xeon 3220
09:32
<johnny>
i mean on yoru clients for local apps
09:32
<markit>
ah, mmm 256MB is not much
09:33
<johnny>
it's fine for running single apps locally.. just not more 2 intensive apps
09:33
<markit>
video performance will be a problem also... X protocol is not optimized for video playback, right?
09:33
<johnny>
most especially.. firefox/flash ..
09:33
<markit>
firefox is ram-hungry :(
09:34
<johnny>
flash is even worse.. :)
09:34
<markit>
and I'll have to surrender and install proprietary flash player, I suspect
09:34etyack has quit IRC
09:34
<johnny>
well. video playback is better if you use localapps
09:34
<markit>
(gnash does not play youtube at the moment, sigh)
09:34
<johnny>
yes.. you will most likely want to use local apps
09:34
markit, well.. html5 youtube will help
09:34
but you can't use firefox for that
09:34
since it uses h.264
09:35* markit confused
09:35
<johnny>
you can use chromium or epiphany (in lucid)
09:35
or chromium
09:35
<Gadi>
(or opera)
09:35
<johnny>
ah. yes.. or opera
09:35
<markit>
isn't codecs available? in italy thera are not software patents
09:35
<johnny>
markit, firefox isn't built to support it
09:35
it doesn't use gstreamer like epiphany will
09:36
<markit>
how is that?
09:36
<johnny>
because they don't bundle the codec at all
09:36
no matter where you are
09:36
<markit>
multimedia is a frontier where our freedom is push back day by day
09:36
johnny: but what about a plugin?
09:36
<johnny>
let's see how the whole.. "google buying on2" thing shakes out
09:36
it might lead to an open video solution in the near future
09:37
<markit>
I do cross my fingers
09:37
<johnny>
i don't know if there are such plugins.. you'll have to look
09:37
<markit>
I'm very depressed because people don't care about their freedom in computer things
09:37
<johnny>
aren't we all..
09:37
<markit>
they just "crack" everything, and make fun of you that use free software and donate money to developers
09:38
<johnny>
that's cuz they have never been personally affected.. or don't know how it is effecting them
09:38
when i explain mindshare to people tho.. they usually get it
09:38
<Gadi>
whoa whoa whoa whoa whoa - let's rewind to "donate money to developers...." ;)
09:38
<markit>
maybe you are much better persuasor than I am :) I usually get depressed or upset, lol
09:38
<johnny>
but there is still no replacement for final cut pro, photoshop, protools markit
09:39
in the free software world.
09:39
<markit>
Gadi: lol, I usually give some money to some projects...around 150 euros/years, not much but..
09:39
<johnny>
not yet anyways..
09:39
so.. i can understand people having to purchase those
09:39
<markit>
well, but they use photoshop because they crack it, not because worth 1500 euros
09:40
<johnny>
sure.. but even if they bought it.. doesn't matter
09:40
<markit>
so they don't even take a look at gimp, or donate to gimp to improve it
09:40
<johnny>
there's no replacement
09:40
i don't think donations are the key to improving gimp
09:40
i'm sure it would help
09:40
but there are many other factors
09:40
you need more developers in general
09:40
<markit>
if you have money, you can have full time developers
09:41
you can advertise for your program, and gain more attention
09:41
<johnny>
it's not as easy as you think
09:41
<markit>
etc.
09:41
<johnny>
if you are a project of mostly volunteers.. manyh volunteers won't work as hard if others are getting paid
09:41
there hare been bounties on free software projects before
09:41
<markit>
I know, you could have a reverse effect
09:41
<johnny>
but they discontinued many, because of how they effected the volunteers
09:41
affected*
09:42
so throwing money at the problem isn't helpful directly
09:42
something that comes out the same..
09:42
would be an organization hiring a developer to work full time on a project
09:42
with strict rules to work with the community
09:42
<markit>
exactly
09:42
<johnny>
and not running roughshod over everbody cuz they get paid or could just fork it
09:43
you'd probably have to fire them if they pissed of the community
09:43
<markit>
let's hope I'll become very rich, and I will build such an organization :)
09:43
back to work now
09:43
<johnny>
by organization.. i mean an external organization.. not the project itself..
09:43
<markit>
I have to earn money for the next donation ;)
09:44
<johnny>
that's why i hire gadi to crack joes in here
09:44
<markit>
johnny: yes, I got it
09:44
<johnny>
jokes*
09:44
lol
09:44
/me pokes Gadi
09:44
<markit>
:)
09:44
thanks a lot for your tips, see you
09:44
<johnny>
bye and good luck
09:44
<markit>
I need it, lol
09:44
teachers will be a big problem, I suppose
09:44
they are not very tech-friendly
09:45
and barely know how to "use" M$ crap
09:45
<johnny>
well.. i'm sure people on the edu lists can help you with that aspect of things
09:45
not just the technical side
09:45
but the softer side of things
09:45
<markit>
is there an edu channel also? I hate lists
09:45
<johnny>
there is an edubuntu one
09:45
i don't know about others
09:45
perhaps they would know tho
09:45
<markit>
ok, thanks again, bye :)
09:46markit has quit IRC
09:46
<johnny>
i still having found the perfect combination between archivable lists with defined subjects/mails and a chat interface where people can talk more free form
09:50alkisg has joined #ltsp
09:57rjune has quit IRC
09:58etyack has joined #ltsp
10:01etyack1 has quit IRC
10:05thunsucker has quit IRC
10:15CAN-o-SPAM has joined #ltsp
10:19
<_UsUrPeR_>
Can anybody give me a hint about installing firefox as a localapp with chinese (mandarin) support?
10:22
<alkisg>
Ubuntu? I think it just needs language-pack-XX for that...
10:22
I.e. in Ubuntu the firefox language plugins are in language-pack-XX
10:23
<_UsUrPeR_>
alkisg: great, thanks. :D
10:26thunsucker has joined #ltsp
10:27etyack has left #ltsp
10:32vandys has joined #ltsp
10:34
<vandys>
Hi... yesterday I got an eeebox B202 running as a TC using help from here; I had to rebuild my /opt/ltsp/i386 for Karmic to get the LAN driver. Thanks for that help!
10:35
But now I'm seeing that my existing TC's (NTA's w. 512M of RAM) freeze when somebody logs in with a KDE session (Karmic).
10:35
I can log in with the more basic ratpoison WM, but that's not going to keep my users happy!
10:36thunsucker has quit IRC
10:36
<vandys>
It seems to be the X server, as if as soon as I start logging in I flip to screen 1 and watch the console, all is well--I can even hear the login tune played. But as soon as I switch back to console 7 the system freezes hard and requires a power cycle.
10:37
I have NBD swap (512M) set up, and also 512M of physical RAM. Behavior's verified on two different NTA TC stations.
10:38
Workaround for now is to run different roots for the new unit and (feisty) for the old ones.
10:38
<stgraber>
mgariepy: A customer reported that TIME_SERVER doesn't work and ntp.ubuntu.com is used in all cases (well, whatever is in /etc/default/ntpdate). If you have 5min to look at it (nothing critical).
10:38
<Gadi>
!compiz
10:38
<ltspbot>
Gadi: "compiz" :: if compiz is giving you problems, one way to disable it for all users is: sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity
10:38
<Gadi>
vandys: try that ^^^^
10:39
<mgariepy>
stgraber, yeah, maybe tonight or tomorrow, this part isn't working well, i'll try to find the bug for this..
10:40etyack has joined #ltsp
10:40etyack has left #ltsp
10:40
<vandys>
Are you sure? This was a crash on a *KDE* session login?
10:41
<Gadi>
vandys: does KDE not use compiz?
10:41
<stgraber>
Gadi: nope, its window manager does the compositing. No compiz involved
10:41
<Gadi>
ah, nm then
10:44
<vandys>
Yes, it looks like /usr/bin/compiz would be around if I had it.
10:45
But my daughter on the new eee TC noticed translucent tool bars, so maybe something fancy and new is tripping up the older NTA HW?
10:45
<Gadi>
vandys: try setting XSERVER=vesa
10:46
that should tell you if its the driver
11:11thunsucker has joined #ltsp
11:12sbalneav has joined #ltsp
11:14
<sbalneav>
Whoops! When I rebooted my machine last night, forgot to sign on again
11:14
Morning all
11:15
<vandys>
Ok, after just an unbelievable amount of tediousness, I got it switched over. And the X server refuses to start. At first it was griping about somehow having decided I wanted 24 bits, but even when I overrode it to 16, it still fails to start.
11:16
<johnny>
sbalneav, ever heard of publican?
11:16
it sounds up your alley in regards to docbook
11:17
sounds like it makes it easier for others to contribute as well
11:17
http://jfearn.fedorapeople.org/Publican/
11:17slidesinger has joined #ltsp
11:17
<johnny>
they use it internally at redhat
11:21
<sbalneav>
johnny: Hmmmm, checking....
11:22
johnny: Looks cool! I'll poke into it this week.
11:22
Thanks for the link
11:25etyack1 has joined #ltsp
11:26etyack has joined #ltsp
11:29etyack1 has quit IRC
11:31etyack1 has joined #ltsp
11:32etyack has quit IRC
11:33etyack1 has left #ltsp
11:33
<vandys>
Gadi, thanks for the help. I'm going to see if I can attach a serial console so I can see more about the failure even with the display frozen.
11:33vandys has quit IRC
11:34thunsucker has quit IRC
11:39* alkisg is getting closer with CK and LTSP... it seems that the problem is that we don't run X 2>somelogfile, but we redirect it to null instead :(
12:12ogra_cmpc has quit IRC
12:14
<jammcq>
sbalneav: Scotty !!!!!!!!!!!!!!!!
12:23
<stgraber>
alkisg: and what's different between 2> /var/log/X.<VT>.err.log and 2> /dev/null ?
12:24
<alkisg>
stgraber: I'm diving into the consolekit sources, and it turns out that it looks in /proc/`pidof X`/fd/2 to get the x11-display-device
12:24
<stgraber>
that's ugly
12:24
<alkisg>
Now if only I could compile a debug version of it, without downloading 400MB of tex-related dependencies... :-/
12:25ogra_cmpc has joined #ltsp
12:26cliebow has joined #ltsp
12:37* alkisg installs 459MB of consolekit build-deps... :(
12:46MorpheusDe has joined #ltsp
12:52AsG_ has joined #ltsp
12:54
<_UsUrPeR_>
Hey guys, I am not seeing anything installed on the server, which displays chinese content correctly, that needs to be installed as a localapp in order to display chinese fonts pages correctly in localapp firefox.
12:54Selveste1 has joined #ltsp
12:54
<_UsUrPeR_>
Is there a package that I am overlooking?
12:59
<alkisg>
_UsUrPeR_: so now you're seeing chinese but with broken fonts?
12:59
Or just english?
12:59
<_UsUrPeR_>
alkisg: it's showing all broken fonts. Little squares with numbers and letters in them
13:00
<alkisg>
OK, then you're probably just missing some fonts, language support etc
13:01
Try searching in synaptic for -lc (Language Code)
13:02
<_UsUrPeR_>
alkisg: I have thus far installed language-pack-zh-hans, language-pack-zh-hans-base, language-pack-zh-hant, language-pack-zh-hant-base, language-pack-gnome-zh-hans, language-pack-gnome-zh-hans-base, language-pack-gnome-zh-hant, language-pack-gnome-zh-hant-base
13:02
Firefox even pops up stating that there have been new language support packages installed
13:02
<alkisg>
Search for -zh in your server
13:02
And see what it has installed
13:02
E.g. language-support-zh etc
13:03
dpkg -l '*-zh*'
13:03
<_UsUrPeR_>
dpkg -l |grep -i zh results in no returns
13:04
hmm
13:04hersonls has quit IRC
13:04
<AndyGraybeal>
_UsUrPeR_: dood i'm gonna purchase one of your boxen to test with
13:04
<_UsUrPeR_>
AndyGraybeal: cool :)
13:04
<AndyGraybeal>
for my biz.. i got permission to order in may
13:05Lns has joined #ltsp
13:05
<AndyGraybeal>
but i'm gonna order one now to test with then order some more in may
13:05
<_UsUrPeR_>
alkisg: ok, dpkg -l '*-zh*' results in three results. manpages-zh, openoffice.org-help-zh-cn, openoffice.org-help-zh-tw
13:05
<alkisg>
_UsUrPeR_: but can you see chinese with just those packages?
13:06
I mean, without using firefox as a localapp, are you able to see chinese?
13:06AsG_ has quit IRC
13:06
<_UsUrPeR_>
alkisg: yes. In firefox, on the server, if I go to http://vn.yahoo.com, I all the fonts appear as normal
13:06
s/vn/cn
13:07
<alkisg>
Ah, no, that's just fonts
13:08
<_UsUrPeR_>
alkisg: if I go to yahoo.cn from the client, not running as a localapp, all fonts appear correctly as well.
13:08* _UsUrPeR_ looks for chinese fonts
13:08
<alkisg>
_UsUrPeR_: copy/paste does work then, right?
13:08
I.e. copying the broken fonts to a gedit window
13:08
<_UsUrPeR_>
oooh, good question. un moment
13:09
<alkisg>
_UsUrPeR_: you can find which package installs a font by doing e.g.: dpkg -S /usr/share/fonts/truetype/thai/Garuda.ttf
13:09
<Lns>
Ok, testing ubu lucid.. never ran into this since I always had i386 server...now that i'm on AMD64, is there a good reason for an LTSP server to have the -server kernel instead of -desktop ?
13:11
<_UsUrPeR_>
alkisg: that's an affirmative. Copying from ltsp-localapps firefox's broken fonts to a notepad on the client works correctly
13:11
<alkisg>
_UsUrPeR_: ok, just compare the font directories then, on your server and on the chroot
13:11
dpkg -S /usr/share/fonts/truetype/thai/Garuda.ttf etc etc
13:21
<johnny>
hmm.. i have a similiar problem in ubuntu about the -server kernel
13:22
for some reason it keeps forcing me to use the -server kernel
13:28
<Lns>
johnny: and you think the -desktop kernel is better suited for ltsp setup?
13:28
<johnny>
if you're running a desktop on the servere machine .. yes :)
13:28
the ltsp server is also the point of sale machine
13:29
btw.. i probably wouldn't have noticed
13:29
except when choosing -server.. the keyboard stopped working
13:29
ps2 or usb
13:29
<Lns>
heh
13:30
well you're essentially running all ltsp user sessions on the server (else localapps), just wondering if the remote X session is somehow more optimized in -server..
13:30
<johnny>
doubt it
13:30
<Lns>
s/localapps/localapps or fatclient/
13:30
<johnny>
it's optimized for desktop applications in general
13:30
<Lns>
yea
13:31
<johnny>
thus.. i think a desktop kernel would be best for ltsp in general
13:31
<_UsUrPeR_>
alkisg: got it! :D ttf-wqy-zenhei and ttf-ufonts! :D
13:31
<johnny>
but i could be wrong in that..
13:31
<Lns>
only reason i used it before was because i had i386 & 8GB ram
13:31
<alkisg>
_UsUrPeR_: nice :)
13:31
<_UsUrPeR_>
thx for your help
13:36joeasaurus has joined #ltsp
13:36
<joeasaurus>
Gadi?
13:46
<mgariepy>
does anybody is able to make firefox use remote apps for mimestype present on the appserver ?
13:49MorpheusDe has quit IRC
13:51
<Lns>
Ok, since I'm new to LTSP on Lucid (or anything recent =p), did the ltsp-build-client *default* to i386 ? I supplied no arguments on my AMD64 install and it built an i386 image.
14:00
<johnny>
suprising..
14:00
<Lns>
oh nevermind
14:00
heh.. forgot about my ltsp-build-client.conf according to fatclient howto =p
14:01
<johnny>
that's what i do on gentoo
14:01
and what happens on fedora
14:01
not sure about debian
14:05vandys has joined #ltsp
14:07
<vandys>
Hi, Gadi, me again. While working on my Karmic problem, I need to run with my old Feisty bits in parallel. /opt/ltsp/images seems to be hard-coded; is there a parameter I can use to make my Karmic-needing boxes to use a Karmic-specific path for this file?
14:10
<Lns>
hmm, what's the diff between "ltsp-build-client --fat-client-desktop" and "ltsp-build-client --fat-client" ? And Gadi, no "yo mama's fat client" jokes please! =p
14:11
<alkisg>
Gadi, stgraber: sudo cat /proc/`pidof X`/stat ==> the 7th field there is the tty. In a normal ubuntu session, it's non-zero. In an ltsp session, it's zero - and that seems to be the CK problem. What sets this?
14:11
<Gadi>
well, hi everyone
14:11
:)
14:12
<alkisg>
Heh... hi! :)
14:12
<Gadi>
joeasaurus: present
14:12* Lns greets Gadi
14:12
<alkisg>
We missed you :D
14:12
<vandys>
Heh, welcome back! :-)
14:12
<joeasaurus>
hey :)
14:12
Well, with the help of alkisg (I was cluster earlier btw) I managed to get the thin clients booting
14:12
<Gadi>
vandys: you can add a line to /etc/inetd.conf to export the image on a different port, and then set a pexlinux.cfg/ file with nbdport=
14:13
<alkisg>
Lns: --fat-client ==> uses the desktop that the server has, --fat-client-desktop ==> you need to specify one, e.g. ubuntu-desktop, edubuntu-gnome-desktop etc. ***Please someone correct the ltsp-build-client --extra-help description for this*** :)
14:13
<Gadi>
Lns: yo mama's thin client's so fat that her fat-client-desktop is gigantubuntu-desktop
14:14
<joeasaurus>
the big issue was how tftp refused to start. I have more questions though :)
14:14
<Gadi>
alkisg: smells like openvt
14:14
<alkisg>
Uh... another thing to learn about :)
14:15
It's nice spending days learning about how linux components operate, but it'd be better if I had some actual results in the last days...
14:16
<Lns>
alkisg: =) ty!!
14:16
<joeasaurus>
so, atm I have the cluster set up with a head node (ub0) and two application nodes (ub1, ub2)
14:16
<Lns>
Gadi: HAHHAHA!!! sbalneav, you need to update your fortune file to include ^^^^
14:17
<joeasaurus>
when I go into the admin webpage for ltsp and search the cluster, it can only find ub1
14:17
I thought it might be a hosts file problem but its not as all the hosts files are correct
14:19
<alkisg>
What does ubuntu use nowadays, instead of openvt?
14:25joeasaurus has quit IRC
14:25mad_willsy has joined #ltsp
14:26
<Lns>
alkisg: do you mind if I alter your fatclient wiki page to 1) add in how to do it via ltsp-build-client w/fatclient parms, and 2) edit your portion to simply assume you've already got a working LTSP setup (at least that you've installed the packages, and maybe refer to that wiki page instead of re-writing it) ?
14:27
<alkisg>
Lns, no problem at all, go ahead
14:27
<Lns>
cool
14:27
<Gadi>
alkisg: once upon a time, we used to call the screen scripts directly (from screen_session) without using openvt
14:27
<alkisg>
Lns, and if you think some more bits/scripts are needed, tell me to make them
14:28
<Gadi>
alkisg: I suspect openvt may attach to a tty but what it runs attaches to it
14:28
<alkisg>
Gadi, if I create a user, login to vt1 with that user, and run startx, everything's fine...
14:28
<mad_willsy>
I wish to connect to a server-pc with ubuntu-ltsp installed from a laptop which i wish to be able to use when I am not able to access the server, without dual-boot if possible. I wish for somebody to be able to use server like a normal PC at the same time so VNC is not an option
14:28
<Lns>
alkisg: no prob
14:28
thx
14:28
<Gadi>
alkisg: right
14:28
alkisg: but ldm runs from openvt
14:28
<alkisg>
Got it - I'll try on vt2 next (shell session)
14:29
So, is there a way to completely remove openvt?
14:29* Gadi is unclear why we moved to openvt
14:29
<alkisg>
I haven't yet completely understood the whole concept...
14:29* Gadi thinks rev. linux did that
14:29
<alkisg>
uh, stgraber, any clues? :)
14:30
<Gadi>
alkisg: see what happens if you change the line in screen_session
14:30
<alkisg>
mad_willsy: freenx?
14:30
<Gadi>
to not use openvt
14:31
<alkisg>
Gadi, thanks, I'll try
14:31
<mad_willsy>
alkisg: what machine i need to install that on and does it support itunes?
14:32
<alkisg>
mad_willsy: you need to install the freenx-server to the ltsp server and the nx client to your laptop. I've no idea about itunes.
14:32* Gadi wonders why vnc is not an option unless the server is windows
14:33
<mad_willsy>
can you get freenx-server for ubuntu-ltsp and nx client for windows 7?
14:33
<alkisg>
Yes
14:33
https://help.ubuntu.com/community/FreeNX
14:34
<mad_willsy>
i only have 1 ethernet card, does that pose an issue?
14:34
also laptop uses wifi to connect to router and server-pc ethernet
14:35
<Lns>
Gadi: I <3 vnc. Unless NX got WAY easier to install, and WAY lighter on resources, I don't mind waiting a couple of seconds for some things to refresh in vnc. I use it over the net w/SSL wrapper all the time!
14:35
err, ssh
14:36
<alkisg>
mad_willsy: you should be ok
14:36
<mad_willsy>
vnc is no good because i need to be able to allow users to use the server as a workstation for when i have friends round to play poker online
14:36
<alkisg>
Lns: nx is easier to install than vnc, for separate sessions
14:36
mad_willsy: you _can_ setup vnc for separate sessions
14:37
<mad_willsy>
ok so i install unbuntu-server, install freenx-server and get nx client for windows 7 to connect in almost the same way as you do vnc i assume?
14:37
<alkisg>
Yes, it's similar
14:38
Gadi, I tried this: SCREEN_02=shell (==openvt), then adduser user, then sudo -i -u user, then startx. That's on top of openvt, so it "should" have problems - but that also worked fine.
14:38
<Gadi>
hmm
14:39
<mad_willsy>
vnc may then infact suit my needs better then as i wish to be able to connect to the TS remotely, i have ddns etc and working vnc server at the moment on windows xp.
14:43mad_willsy has left #ltsp
14:50pmatulis has quit IRC
14:52cliebow has quit IRC
14:54
<vandys>
Ok, here's why an NTA TC on a Karmic /opt/ltsp fails for KDE:
14:54
X: main/renderbuffer.c:2159: _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
14:55
I had to run X manually on a serial terminal with a manually started with getty from the TC in order to see this message...
14:55
<Lns>
Apologies for the noob q, I can't seem to find the docs online (if there are any).. how do you specify a specific chroot to use for specific clients?
14:56
<alkisg>
Lns, use different ports in pxelinux.cfg/01-mac-address
14:56
2000=first chroot, 2001=second chroot etc
14:56
You can see the ports in /etc/inetd.conf
14:58
<Lns>
alkisg: oh, ok, cool. How heavy is nbdrootd? Would it be more sane to somehow be able to specify the root directly in pxelinux.cfg/01-mac-address instead of spawning multiple nbdrootd ?
14:59
<alkisg>
Lns, I think the best start is "why do you need multiple chroots?"
14:59
<Lns>
alkisg: well unless i'm going about it wrong, one for fat clients, one for thin clients, one for localapps... ? Maybe i can put localapps/thin client together, but not sure about fat
14:59
<alkisg>
You can have all 3 of them in the same chroot
14:59
<Lns>
!! =) sweeeet
14:59
<ltspbot>
Lns: Error: "!" is not a valid command.
15:00
<Lns>
heh
15:00
<alkisg>
...as long as your clients have at least 256 ram - do they?
15:00
<Lns>
alkisg: no, a bunch have only 128
15:00
<alkisg>
Hmm you'd need another chroot for those, then. Or to disable some services manualy
15:03
<vandys>
If I want to add ServerFlags and Extensions sections to the TC's xorg.conf, how do I set that up on the server side?
15:08
<highvoltage>
hmm, besides putting the guestlogin line in lts.conf, is there anything else I need to do to make it work?
15:08
currently when I click on the login as guest button LDM just kicks me out
15:08
and I can't see anything meaningful in the ldm.log file
15:09
<Lns>
highvoltage: you need LDM_USERNAME, LDM_PASSWORD and LDM_ALLOW_GUEST vars in there (at least from 8.04, not sure if anything changed)
15:09
<johnny>
alkisg, but why
15:09
<stgraber>
highvoltage: as Lns said :) I was just going to type something like that.
15:09
<johnny>
why not --fat-client <desktop>
15:09
and default to server desktop
15:09
i'm confused
15:09
<stgraber>
highvoltage: in a ltsp-cluster setup, guest login accounts are created on the fly. That part of the code is very different from regular LTSP.
15:09
<johnny>
why does'nt it just take an argument?
15:10
<alkisg>
johnny: the way ltsp-build-client plugins work, you can register a plugin that either has a parameter or it hasn't
15:10
<johnny>
you mean there's no way to say the parameter isn't required?
15:10
<alkisg>
You can't register a plugin with an optional parameter...
15:10
Right
15:10
<johnny>
that sounds like a bug
15:10
<alkisg>
Patches welcome :)
15:10
<highvoltage>
Lns, stgraber: ok thanks
15:11
stgraber: I'm going to create a guest user on our livecd session then too
15:11
stgraber: I think it will be useful especially since we'll save some network traffic if the $HOME directory lives in client RAM
15:12weenus has joined #ltsp
15:13
<stgraber>
highvoltage: ok
15:14
highvoltage: did you set the lts.conf key to not check for ssh key validity ?
15:14
highvoltage: otherwise the ssh connection will fail when checking the server's fingerprint
15:16
<alkisg>
If I change the last line in screen.d/ldm,
15:16
xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt${TTY} -auth ${XAUTHORITY} ${X_ARGS} -br >/dev/null 2>&1
15:16
to just: xinit $xinitrc xterm
15:16
then /proc/`pidof X`/stats contains a non-zero tty, and CK works properly...
15:16
<highvoltage>
stgraber: yes
15:16
stgraber: so far I can log in just fine with my normal user
15:16
<stgraber>
highvoltage: great
15:16
<alkisg>
highvoltage: would it be possible to add e.g. 12 users along with the guest one?
15:17
<stgraber>
alkisg: as we already openvt the right vt, you may want to try dropping hte vt${TTY} part of that xinit call
15:17
<alkisg>
It would make it more usable, when written to a usb stick of course..
15:17
k, trying...
15:17
<stgraber>
alkisg: well, the user management tool will be there anyway, so I guess they can easily create some more if needed
15:18
<alkisg>
stgraber: sure, but the whole concept is to enable them to test - they can't really test with 1 user...
15:18
<stgraber>
though having one account created to have the guest login working would be great
15:18
<highvoltage>
alkisg: I guess so. why would you need them if all the live session users could use the guest user though?
15:18
<alkisg>
highvoltage: you can't login as the same user multiple times
15:18
<stgraber>
highvoltage: only one user will be able to use the guest user
15:18
<alkisg>
Firefox will only start for the first login..
15:18
<stgraber>
highvoltage: otherwise you have the risk of locking and gconf corruption if the same user is logged in multiple times
15:19
<highvoltage>
bummer.
15:19
I just want to understand this right, can I only define one guest user?
15:20
<alkisg>
No, you can define any number
15:20
But it's not easy to assign them to specific terminals
15:20
<stgraber>
alkisg: isn't the "LTSP way" of having guest users using the mac address as login or something like that ?
15:20
<alkisg>
username=ltsp123, password=ltsp123
15:20
To make that work, you'd need e.g. 255 users
15:21
I don't think that's too bad, though...
15:21
<highvoltage>
nope, adding users is quick
15:21* stgraber wished we had a ltsp-cluster setup on the DVD :)
15:21
<highvoltage>
stgraber: lucid+1? :)
15:21
<stgraber>
with the accountmanager we'd have these accounts created on the fly, tracked with CK and cleaned+reset on logout ;)
15:22
highvoltage: maybe :)
15:22
<alkisg>
stgraber: it'd be nice if some features of ltsp-cluster were intergrated to the standard ltsp...
15:22
<stgraber>
I actually hope to have the new daemon infrastructure used in LTSP itself, so only the Control Center would be ltsp-cluster specific
15:22
<alkisg>
E.g. getting lts.conf with wget ;)
15:23
Awesome
15:23
<stgraber>
basically everything would use the same code, only the configuration/logging backend would be different and offer a bit more features when it's used
15:24
<alkisg>
highvoltage: so, about the users, if you create ltsp1 to ltsp255, with the same passwords as the usersnames, and set LDM_GUESTLOGIN=True, that would work for /24 networks
15:24
I.e. 255.255.255.X (or smaller subnets)
15:25
<highvoltage>
yes that shouldl be fine for a live session
15:25
<alkisg>
For larger subnets, they'd still need to type the usersnames/passwords manually, as the clients could be named e.g. ltsp12345
15:25
<highvoltage>
people wouldn't want to run more than a ahandful of users from a livecd anyway
15:25
(or flash disk or whatever)
15:25
<alkisg>
Sure, but if their site subnet was bigger, they'd still need to type the username/password manually
15:26
So we should mention the usernames/passwords somewhere
15:26
<highvoltage>
*nod*
15:32
<alkisg>
stgraber: btw, there's this call in X95-run-x-session:
15:32
su - ${LDM_USERNAME} -c "$CLIENT_ENV $MY_LANG DISPLAY=$DISPLAY ICEAUTHORITY=$ICEAUTHORITY XAUTHORITY=$XAUTHORITY $LDM_XSESSION $LDM_SESSION"
15:32
could I change that to sudo -i, because su creates an additional CK session?
15:32
<stgraber>
are we sure absolutely all distros using recent LTSP have sudo ?
15:33
<alkisg>
Nope, but I'm sure all distros that support fat clients do :P
15:33
<stgraber>
yeah but that line is not fat client specifc ;)
15:33
or is it ?
15:33
<alkisg>
if ! boolean_is_true "$LTSP_FATCLIENT"; then ==> it's on the "else" part
15:33
<stgraber>
hmm, ok, then use sudo ;)
15:33
<alkisg>
;)
15:33
<stgraber>
we're the only one supporting fat client anyway and we have sudo for sure :)
15:34
<highvoltage>
hmm, creating 255 users takes quite some time in my virtualbox machine (around 20 seconds)
15:34
I guess that could be brought down a bit
15:34
<alkisg>
highvoltage: how are you creating them?
15:34
<stgraber>
highvoltage: adduser or useradd ?
15:34
<highvoltage>
alkisg, stgraber: useradd
15:34
<stgraber>
oh, that should be fast ...
15:35
<alkisg>
highvoltage: that's too long, I got a script that does it in under 1 sec, wait...
15:35
<highvoltage>
could be that virtualbox is just a bit slow for that
15:35
<stgraber>
highvoltage: any difference if you tell it not to look and copy /etc/skel ?
15:36
<highvoltage>
stgraber: eek, it's not even creating home directories currently
15:36grantk has joined #ltsp
15:36
<grantk>
Hello
15:36
<stgraber>
highvoltage: very odd then ...
15:37
<highvoltage>
for now I have:
15:37
<alkisg>
Uh, no, I'm also using useradd (from python)
15:37
But it's really really fast
15:37
<highvoltage>
# Create LTSP Guest Users:
15:37
for user in {1..255}; do
15:37
useradd ltsp$user
15:37
echo "ltsp$user:ltsp$user" | chpasswd &
15:37
done
15:37
<grantk>
Does anyone know if a heavy printer is penalized with ltsp? By penalized I mean their job priority changes to a lower priority? I would think it to be a cups issue but the reason I ask is this just changed for me this week when I moved a printer that uses the jetpipe script from ltsp 4.2 to ltsp5.
15:37weenus has left #ltsp
15:39
<alkisg>
highvoltage: can you time the useradd calls independed of the chpasswd calls?
15:39
<stgraber>
12s on my laptop
15:39
that's with an Intel SSD ...
15:39
<alkisg>
If the chpasswd calls are the ones that are slow, you can pass the password as a command line parameter to useradd
15:40
<stgraber>
highvoltage: btw, you probably should use: for user in $(seq 1 255); do
15:40
highvoltage: the {1..255} looks like a bashism as it failed in dash here
15:41
highvoltage: also, you may want to use the same group for all users, that should limit writes to /etc/group
15:41
<highvoltage>
stgraber: it is a bashism indeed, aparently you should only use seq if you're using bash and it's bash <3.0
15:41
stgraber: but I'll change it to sec then and change to dash and see if that speeds things up
15:41
<alkisg>
highvoltage: and, if the user creation is slow, you can use "newusers" instead
15:42
<stgraber>
alkisg: 12s for the whole thing, 9s for only the useradds
15:42
<alkisg>
OK, newusers it is then
15:42
9s is too long for 255 users
15:42
<stgraber>
removing them is a lot slower ;)
15:43
<alkisg>
Why would we? :D
15:43
<stgraber>
well, I try not to have 255 users on my laptop with obvious passwords ;)
15:43
<highvoltage>
stgraber: ubiquity wouldn't move over those users
15:44
<stgraber>
highvoltage: indeed
15:44
<alkisg>
highvoltage: man newusers, it should be much faster & better suited
15:44
<highvoltage>
I agree there should be a quiick and easy way to remove them
15:45
<stgraber>
highvoltage: well, I replaced that by a line of sed and rm -Rf /home/ltsp* :)
15:46
<highvoltage>
stgraber: :)
15:48
hmm... since the home directories will be tmpfs mounted, do they actually need to be different?
15:48
<alkisg>
Yeah, removing vt from the X command line fixes the CK problem :)
15:48
<highvoltage>
or will that also cause some funny business with gconf somehow?
15:48
<alkisg>
...but it makes X start in vt4 instead of vt7 :D
15:49
<stgraber>
alkisg: does that affect the flickerless boot in lucid ?
15:49rjune has joined #ltsp
15:49
<stgraber>
alkisg: btw, is plymouth working properly at the moment on LTSP in lucid ? (haven't had a thin client around for two weeks :))
15:49nubae has quit IRC
15:49
<alkisg>
Uh, I've no idea, I don't have an intel client to test near me
15:49
*for the flickerless boot
15:49nubae has joined #ltsp
15:49
<stgraber>
highvoltage: you'll have permission issues + potential file conflicts
15:50
<alkisg>
plymouth works in vbox and in an ati client I have around, the same as in lucid, i.e. so and so
15:50
<stgraber>
highvoltage: so go with one home directory per user
15:50
<highvoltage>
stgraber: I might have made a wrong assumption, aren't the guest users home directories tmpfs mounted so that the changes only occur in RAM on the thin clients?
15:50
<stgraber>
alkisg: what are your thin clients ? flickerless should work with ATI (open source driver), Nvidia (nouveau) and Intel (usual driver)
15:51
highvoltage: I don't think so
15:51
<highvoltage>
stgraber: ok
15:51
<alkisg>
stgraber: I'm currently testing with vbox - let me get it working first and I'll check about flickerless login tomorrow...
15:51
<stgraber>
highvoltage: that will be on tmpfs because /cow is mounted in tmpfs (as in, everything you do in the live session is on a tmpfs) but we don't automatically mount a tmpfs over the home directory
15:52
<vandys>
Gadi, if I do a partial xorg.conf just for ServerFlags, can I feed that to X_CONFIG and assume the X server will dig up the rest for itself?
15:52
<stgraber>
vandys: yes, it'll
15:52
<alkisg>
stgraber: I wonder if the opposite would work, i.e. leave the vt in the xorg call, and don't use openvt for that screen session...
15:53
<Lns>
does "ltsp-build-client --late-packages" automatically install most applications in the chroot or do you need to specify with "--late-packages" ?
15:53
<stgraber>
alkisg: well, the openvt call is potentially required for things like that menu Gadi implemented, the login script and the ssh script
15:53
<Lns>
crap, i mean "ltsp-build-client --fat-client" in the first one
15:53
<stgraber>
alkisg: so having it for everything with the logic I implemented and mgariepy fixed that detects current vt and doesn't switch if not required
15:53
<alkisg>
lns, it installs about what you can find in the live cd
15:53
<Lns>
alkisg: cool, ty :)
15:54
<stgraber>
alkisg: openvt also does "VT cleanup" which is useful if something crashed on the VT and didn't release it properly
15:54
<alkisg>
stgraber: it doesn't really work ok yet... it still needs fixing (the vt switching logic)
15:54
<stgraber>
alkisg: though everything related to VT is usually kernel black magic ;)
15:54
<alkisg>
stgraber: also, I don't see `openvt` in my normal lucid installation - so maybe there's a cleaner way to do it...
15:54
(I mean openvt processes running)
15:55
<vandys>
Is there a way to wildcard some of the MAC address matching in lts.conf?
15:55
<alkisg>
vandys: mac* should work...
15:55
<vandys>
And what is the clause to reference a bunch of common stuff from a previous lts.conf entry?
15:55
<stgraber>
alkisg: it's upstart doing it with the tty scripts + the gdm script
15:55
alkisg: though we can't really depend on upstart in LTSP yet to do everything for us
15:56
<alkisg>
Uhm so we can't use it because not all the... right
15:56
<stgraber>
alkisg: I did some test scripts using upstart instead our init scripts, it's extremely fast and generally more reliable
15:56
<vandys>
(Thanks) Finally, are hex digits in the match case sensitive?
15:56
<mgariepy>
alkisg, do you have more bugs with vt switching ?
15:56
<stgraber>
alkisg: though if you look at LP, there's currently 50 bugs about gdm starting on the wrong VT in regular lucid :)
15:56
<alkisg>
Heh!
15:57
mgariepy: kinda. If I put SCREEN_02=shell and SCREEN_07=ldm, half of the times I'm staying in SCREEN_02
15:57
<stgraber>
something to do with plymouth, keybuk is working on it and a fixed plymouth should be released in a day or two
15:57
<alkisg>
That's not really a bug, but it's not convenient
15:57
mgariepy: But, *only* if I switch quickly to vt7, X starts
15:57
<stgraber>
alkisg: are we sure of the parsing order of the environment ? is 02 actually checked before 07 ? :)
15:57
<alkisg>
If I switch after 2-3 minutes, it doesn't start at all..
15:58
<mgariepy>
hmm ik, i tested that i it didn't happen, i rebooted like 10 times and everything was working ok.
15:58
<alkisg>
mgariepy: in all my vbox test it worked fine
15:58
In an ati client, it doesn't
15:58
<stgraber>
X is a bit picky, you need to be on the vt to have it start, otherwise it hangs and wait for you to switch on it. A few months ago I could wait hours before switching and it'd kick in the second I switch to it
15:58
<alkisg>
It only works ok half (or less) of the times...
15:59
<stgraber>
mgariepy: might be interesting to test with the CSRS thin client at the office
15:59
as it's ATI and KMS works fine on it with lucid
15:59
<mgariepy>
stgraber, yes ltsp-client-core passes screen 01 to 12 or something, then it depend on what gets executed.
15:59
<alkisg>
stgraber: I think those screen scripts run in parallel, so we can't be sure of which one starts first
16:00
<stgraber>
we might have a SCREEN_DEFAULT=XX value to force a specific vt
16:00
<alkisg>
vandys: they shouldn't be case sensitive
16:00
<mgariepy>
we are sure that screen_01 starts first (it's a for) but it's not sure that it finishes first ;)
16:00
<stgraber>
that way once all screen scripts started, we can look at the current vt, if it's not the right one, do a chvt to the right one
16:01
<alkisg>
Gadi said he'd work on something like that
16:01
<stgraber>
AFAIK we also have our set of race conditions with upstart's tty scripts :) like on my laptop where gdm is loaded before plymouth shows up ;)
16:02
<alkisg>
Woah
16:02
<stgraber>
yeah, a complete boot sequence from initrd to loaded gnome session takes around 7s on that laptop :)
16:02* alkisg is seeing ldm as his desktop background for a while, with the gnome panels on top...
16:02
<stgraber>
and it's an alpha-1 upgraded, not even a clean install
16:03
alkisg: I actually like that quite a lot
16:03
<vandys>
Ugh, it's LIKE. Not documented anywhere, but found a k12ltsp example with it! :->
16:03
<mgariepy>
the screen_session script should be reviewed i think half the stuff in there is deprecated but i'm not 100% sure.
16:03
<stgraber>
alkisg: it makes the login experience a lot better
16:03
<alkisg>
I think logging in now takes longer than booting
16:03
I.e. I can boot in 20 seconds and I need 40 seconds to login...
16:03
<stgraber>
mgariepy: when I did the VT switch stuff, I did a review of all that script ... I don't "think" we have anything that's not used in some weird cases in there
16:04jammcq has quit IRC
16:05
<highvoltage>
it took 14 seconds in my VM with newusers
16:05
<mgariepy>
lines 44 through 64
16:06
stgraber, why do we need to know what is the currect tty ? as far as i'm concern i don't care as long as the ldm is in front at the end.
16:07
<highvoltage>
alkisg: I think what we'll do is, limit the dhcp range to about 40 addresses and then just create those 40 users
16:07
<stgraber>
mgariepy: because if you do a call to chvt or openvt when you already are on the right vt, that'll make plymouth to disappear, the screen will flicker to a black screen and show some output.
16:07
<alkisg>
highvoltage: if we're going to use proxydhcp (as well as normal dhcp), we don't have access to the dhcp range
16:07
<mgariepy>
plus variable are initialized with certain value that are not true when the main() makes another loop.
16:07
<alkisg>
highvoltage: did you try `newusers` ?
16:07
<stgraber>
mgariepy: if you don't do chvt/openvt in this case, you'll get the waiting cursor on top of plymouth, then fadding to a working ldm without any flicker
16:08
<highvoltage>
alkisg: yes, it took 14s in my vm
16:08
alkisg: so definitely an improvement
16:08
<alkisg>
Uh... still too much
16:08
Does it have a switch not to create home dirs?
16:08
<mgariepy>
so the -s switch the vt breaks that ?
16:09
<stgraber>
mgariepy: nope, because in the case where we are on the wrong VT, we have to switch and then it'll flicker but we don't have a choice there.
16:09
mgariepy: the extra code is to make absolutely sure that we actually need to switch VT
16:09
mgariepy: in the past we'd just openvt in all cases and that was causing the flicker
16:09* alkisg wonders why it worked fine on karmic and broke on lucid...
16:10
<highvoltage>
alkisg: hmm, I have LTSM_GUESTLOGIN=True and all the users added, but the guest login button still doesn't work. is there something obvious I'm still missing?
16:11
<stgraber>
mgariepy: I'll have to do some tests once back home, there I have the exact setup I used to develop that code + I have the bootchart + trace of a working flickerless Lucid
16:11
<alkisg>
highvoltage: LTSP, not LTSM, right?
16:11
<highvoltage>
alkisg: yes :)
16:11
<stgraber>
highvoltage: anything in /var/log/ldm.log on the thin client ?
16:11
<mgariepy>
stgraber, ok
16:11
<alkisg>
highvoltage: LDM_GUESTLOGIN
16:11rjune has quit IRC
16:11
<highvoltage>
stgraber: nope, just that the process exiced with status 0 and that it's respawening
16:12
<stgraber>
highvoltage: weird
16:12
<highvoltage>
alkisg: yes earlier was typo, I have LDM_GUESTLOGIN=True in my config file
16:12
<stgraber>
highvoltage: can you try: ssh ltsp201@192.168.0.254
16:12
<alkisg>
highvoltage: can you upload your lts.conf ?
16:12
<stgraber>
well, with the exact same parameters you pass to ssh
16:12
to make sure it doesn't prompt for anything
16:13
<highvoltage>
it prompts me to type yes for the ssh key and then asks for the password
16:13
<Lns>
alkisg: just updated the FatClient wikipage..I know there are probably errors on it, could you give it a once over? I'm OTL right now but will be back.
16:13
Anyone else is invited to do the same =)
16:13
<highvoltage>
but no other prompts
16:14
<Lns>
https://help.ubuntu.com/community/UbuntuLTSP/FatClients
16:14
<alkisg>
Lns, I'll have a look tomorrow, thanks
16:14
(it's getting late)
16:14
<stgraber>
highvoltage: it shouldn't prompt for the password with the SSH options you've set in lts.conf
16:14CAN-o-SPAM has quit IRC
16:14
<stgraber>
highvoltage: if it still does, then it'll fail to login
16:15
<alkisg>
stgraber: changed `su` to `sudo` and removed vt from the X command line, and I now have one correct CK session. But, I got ldm on vt3 instead of vt7 :-/
16:15
<highvoltage>
stgraber: does ltsp change the behavior of the ssh client on the thin client?
16:15
<alkisg>
highvoltage: can you pastebin your lts.conf?
16:16
<stgraber>
highvoltage: nope, it's just that it won't accept anything else from ssh than "password:" so if ssh asks for any user input other than the password, it'll fail
16:16
<highvoltage>
I'm sure it's small enough to just paste...
16:16
[default]
16:16
LDM_DIRECTX=True
16:16
LDM_SSHOPTIONS="-o StrictHostKeyChecking=no -o CheckHostIP=no -o LogLevel=silent"
16:16
LDM_GUESTLOGIN=True
16:16
<alkisg>
Yeah that looks fine. Can you login with ltsp1/ltsp1 ?
16:17
(manually)?
16:17
<highvoltage>
alkisg: yes
16:18
(hmm, or can I....)
16:18
seems to take a bit long
16:18
<stgraber>
highvoltage: anything of interest in /var/log/auth.log on the server side ?
16:18
<mgariepy>
hey gtg. my day is over. :)
16:19
<alkisg>
Bye mgariepy
16:19
<highvoltage>
bye mgariepy!
16:19
<stgraber>
see you mgariepy
16:20
<alkisg>
We'll also need some unmounting code for fat clients...
16:20
...because after the users log out, the mounts remain
16:20
-or at least to enable the PK policy for other users to unmount them
16:20
<stgraber>
mounts, as in the home directory ?
16:20
<highvoltage>
sounds like lyrics for some metal song
16:20
<stgraber>
or the usb keys ?
16:20
<mgariepy>
alkisg, for the fat client have you found a solution for the passwd/screensaver ?
16:20
<alkisg>
No, as in the internal hard disk or a cd rom
16:21
mgariepy: does it prompt? it shouldn't do that by default...
16:21
<stgraber>
highvoltage: ;)
16:21
<highvoltage>
ok log in as guest works now, the permissions on the home directories were incorrect
16:21mikkel has quit IRC
16:21
<stgraber>
ah, that can explain some things indeed ;)
16:21
<alkisg>
mgariepy: I think we disabled the screensaver locking by default - one would need to change the defaults to activate it
16:22
<mgariepy>
alkisg, i use fat client at the office, atom + 2G ram, when my screensaver is there i cannot unlock my screen since there is no ldap or passwd on the TC
16:22
<alkisg>
mgariepy: when did you create the chroot?
16:23
<stgraber>
mgariepy: it shouldn't prompt for a password but maybe we're running an old chroot. That's in the plugin so we need to rebuild.
16:23
<mgariepy>
well i want to have my screen is locked, stgraber works with me ;)
16:23
<alkisg>
About 2-3 weeks ago we started shipping a gconf settings file which should disable screen locking by default
16:23
<stgraber>
mgariepy: I can kill the screensaver anyway ;)
16:23
<highvoltage>
well, I'm calling it a day as well
16:23
<alkisg>
I'm also insisting on a new lts.conf setting that would allow saving the users's hash to /etc/shadow
16:23
<highvoltage>
goodnight!
16:23
<mgariepy>
a few days ago, i last updated it like friday.
16:23
<stgraber>
mgariepy: and have access to your home directory through the file server :)
16:23
highvoltage: night
16:23
<mgariepy>
lol i know ;)
16:23
<stgraber>
mgariepy: updated but didn't rebuild right ?
16:24
<alkisg>
mgariepy: it gets called on ltsp-build-client
16:24
<highvoltage>
(heh seems like I'm even beeting mgariepy out of here)
16:24
<mgariepy>
attention everyone, if i say i updated my chroot, i rebuilded it as well
16:24
<stgraber>
highvoltage: hehe, you're already at home too. He's to drive back home :) easy to beat him then.
16:24
<mgariepy>
cya highvoltage
16:25
<alkisg>
We're even allowing LDM_PASSWORD, which anyone can get with tftp, an "LDM_STORE_PWHASH_TO_SHADOW" should also be acceptable...
16:25
<mgariepy>
;)
16:25
<stgraber>
mgariepy: was ltsp-root01.dev up to date using my ppa ?
16:25
<mgariepy>
when i did it yes.
16:25
it's a few day old though almost a week. ;)
16:25
<stgraber>
mgariepy: ok, so we have 5.2.1~bzrSOMETHING
16:25
<mgariepy>
i'll rebuild it tomorrow i think
16:26
<alkisg>
mgariepy: just look at the directory and see if the file is there
16:26
/opt/ltsp/i386/usr/share/gconf/defaults or something
16:26
<mgariepy>
5.2.0
16:26
it's a bit old ;)
16:26
<alkisg>
But, I think that defaults don't work if the user has set a different setting. So in that case you'd need to unset that key to get the defaults
16:27
<stgraber>
ah, so that's from RL's PPA, not mine. I have a bzr snapshot currently in mine (karmic + lucid)
16:27
<mgariepy>
maybe it's from archive ;)
16:27
<stgraber>
hmm, right :)
16:27
<mgariepy>
ho no it's yours :P
16:28
as from last week.
16:28
<alkisg>
cat /opt/ltsp/i386/usr/share/gconf/defaults/10_ltsp_fat_client
16:28
/desktop/gnome/lockdown/disable_lock_screen true
16:29
If you have that there, and it still doesn't work, clear your key with gconf-editor
16:29
<stgraber>
cat: /opt/ltsp/fat/usr/share/gconf/defaults/10_ltsp_fat_client: No such file or directory
16:30
<alkisg>
Not recent enough, then.
16:30
<stgraber>
mgariepy: ltsp-build-client is at 5.2 on ltsp-root01.dev, the package comes from archive, not my PPA
16:30
mgariepy: the chroot is probably up to date but ltsp-root01.dev isn't
16:30
<mgariepy>
yeah i know, but i still want to be able to lock my screen anyway.
16:31
<stgraber>
mgariepy: that's why I moved it from mandatory to defaults ;)
16:31
<mgariepy>
i don't like my session to be accessible for everyone ;)
16:31
<alkisg>
mgariepy: then you need to set your password, to be able to unlock it
16:32* alkisg is looking for supporters for writing the passwd hash in /etc/shadow! :D
16:32
<alkisg>
(optionally)
16:32
<mgariepy>
that would be nice ;)
16:32* stgraber is looking forward to having sbalneav's new toys :)
16:32
<stgraber>
with PAM + NSS using ssh, that'll all be solved
16:33
<alkisg>
A tiny crypt call in ldm.c + an append to shadow... pretty simple
16:33
That's Lucid+1 or +2 or +3... but we could have the shadow trick for lucid
16:33
<stgraber>
alkisg: well, except that at this stage there's no shadow entry
16:33
alkisg: they get created a bit later on
16:34
<mgariepy>
369 update + 57 new
16:34
<alkisg>
stgraber: well I'm sure we could find a way with no security loss other than the possibility for someone which gains root access to a tc to get the hash
16:34
That's a really small security risk, as opposed to LDM_PASSWORD on tftp...
16:36
It's essentially what you're doing now manually
16:37
<mgariepy>
indeed, i wouldn't put my password in a clear text postgres database ;)
16:37
<stgraber>
bah, we're still a lot better than regular LTSP, we send it over https instead of tftp :)
16:37
<mgariepy>
would it be very hard to lock the screen from the appserver ?
16:38
yeah but it's still clear text on the apache server that everyone have access.
16:38
<stgraber>
mgariepy: ltsp-remoteapss gnmee-screensaver-command --activate ?
16:38
or something similar
16:39
<mgariepy>
i'll finish the update and test it.
16:39
<stgraber>
so much for leaving the office early today heh ? :)
16:42
<mgariepy>
i doubt it would work though i don't think gconf is running on the appserv...
16:42
yeah i know
16:42
i'll leave earlier tomorrow
16:45
<vandys>
Gadi, are you still there?
16:45
<Gadi>
barely
16:46
<vandys>
:-> So disabling AIGLX lets TC's using Via to log onto KDM/KDE. FYI!
16:46
<Gadi>
using openchrome?
16:46
or via drivers?
16:47
and it prolly depends on which via chip
16:47
<vandys>
I put ServerFlags AIGLX set to off, and Composite set to disable in a custom xorg.conf
16:47
<alkisg>
OK we need to ditch that openvt call for X sessions. If I run X -vt6 (but the vt was opened in 7) it works fine.
16:47* Gadi takes mental note tho - with whats left of his brain
16:48
<stgraber>
alkisg: ok, now to check if we now that it's a X session ;)
16:48
<mgariepy>
rebuilding the chroot now ;)
16:48
<vandys>
I agree on the Via chip, but google shows a lot of people (not just LTSP) getting hosed by this.
16:48
<alkisg>
stgraber: ok, but I'll leave that for tomorrow - too late here to go on :)
16:48
Good night all!
16:48
<vandys>
I could not get MAC address wildcarding working--should it be [01:1B:*] like that?
16:48
<Gadi>
vandys: there's no such thing
16:49
afaik
16:49
<stgraber>
alkisg: heh, it's the same time as here :) (at least I think you're CET as well)
16:49
alkisg: ah no, it's one hour worse :)
16:49
<vandys>
Ah, I thought I saw a patch go in. Oh, well. Is LIKE=<other-name> working?
16:49
<alkisg>
12:29 :)
16:49
Where are you?
16:49
<Gadi>
vandys: yeah LIKE works
16:49
<stgraber>
it's "only" 23:49 here
16:49
alkisg: switzerland until saturday
16:49
<vandys>
Cool. Thanks for your help!
16:49
<alkisg>
Ah, cool. And cold, i bet :)
16:50
<stgraber>
well, not worse than Quebec, not too much better though
16:51
<mgariepy>
hey it's quite warm here, it's 3C outside ;P
16:51
<alkisg>
k, took 3 days to change 3 characters, but it works fine now :D Bye!
16:51
<Gadi>
if openvt should only be called in non-x screen scripts, then those screen scripts should call it themselves
16:51alkisg has quit IRC
16:51
<stgraber>
mgariepy: ok, then it's probably worse than Quebec but it's 6 hours later so ...
16:51
-5C and snowing here :)
16:52
<mgariepy>
nice, at least you have snow i miss snow
16:52
<stgraber>
yeah, though I hope it'll stop soon. Tomorrow I'm going in France so if I can go there without getting stuck in traffic because of the snow it'd be great :)
16:55johnny has left #ltsp
16:57grantk has left #ltsp
17:09vandys has quit IRC
17:10mgariepy has quit IRC
17:16bobby_C has quit IRC
17:18Gadi has left #ltsp
17:21japerry has quit IRC
17:23johnny has joined #ltsp
17:40Selveste1 has quit IRC
17:42japerry has joined #ltsp
17:42
<Lns>
man it's 59 and sunny out here in cali =)
17:43
took off my jacket, rolled up my sleeves and walked to the mexican place down the street about a half hour ago =)
17:45mgariepy has joined #ltsp
18:10
<Lns>
how does the server know what arch the client is, and therefore which chroot to build (if there is i386+amd64 chroots) ?
18:10
s/build/boot
18:10
jeez my wordage is way off today
18:16
nm, gotta run! cheers all
18:16Lns has quit IRC
18:18staffencasa has quit IRC
18:25laron has joined #ltsp
18:26
<laron>
I've set up an LTSP server and using a Windows 2008 Server to transfer clients to the tftp server for the pxelinux.0 file
18:26
I just moved the tftp computer to another room, restarted it and tested a client.
18:27
and tftp connect timed out
18:27
so I check to see if por 69 was blocked "nmap -sU localhost" and it is open|filtered
18:27
so that shouldnt be the problem
18:28
note. the clients were able to get a dhcp address fine, just timed out when asking the tftp server for the files
18:28
what could be wrong?
18:30
<mgariepy>
have you tried to restart the tftp service ?
18:31
<laron>
yeah
18:31
<mgariepy>
netstat -taunp | grep 69
18:33
<laron>
udp 0 0.0.0.0:69 0.0.0.0:* 1101/inetd
18:33
is the result
18:35
<mgariepy>
does the ip of the server has changed ?
18:36
<laron>
no, set to static in /etc/network/interfaces
18:38
<mgariepy>
weird
18:38
<laron>
yeah
18:38
well, ill work on it later
18:38
<mgariepy>
does the tftp works? can you get the file with a tftp client ?
18:39
<laron>
ill try that just to make sure
18:39
thanks for the help, wanted to make sure I wansnt missing anything obvious
18:39
and it did work earlier, worked perfect
18:39
thanks for the help anyway
18:39
<mgariepy>
no problem but i wasn't of much help i guess ;)
18:40
<laron>
:) later
18:40laron has left #ltsp
18:41knipwim has joined #ltsp
18:43artista_frustrad has joined #ltsp
18:44knipwim_ has quit IRC
18:57japerry has joined #ltsp
19:09thunsucker has joined #ltsp
19:10
<thunsucker>
I am getting ready to setup my first fat client on karmic
19:10
the link off the ubuntu wiki still the best route to go?
19:10
https://help.ubuntu.com/community/UbuntuLTSP/LTSPFatClients
19:15try2free has joined #ltsp
19:20japerry has quit IRC
19:30
<johnny>
hmm..
19:30
my fat clients ain't workin
19:31
just a blinkin screen
19:31
<thunsucker>
johnny: interesting
19:36artista_frustrad has quit IRC
19:37try2free has left #ltsp
19:41waldo323 has joined #ltsp
19:49artista_frustrad has joined #ltsp
19:51artista_frustrad has quit IRC
19:53artista_frustrad has joined #ltsp
19:57artista_frustrad has quit IRC
20:00artista_frustrad has joined #ltsp
20:01japerry has joined #ltsp
20:01jammcq has joined #ltsp
20:01
<jammcq>
hellooooo friends
20:14thunsucker has quit IRC
20:18artista_frustrad has quit IRC
20:30timborn has quit IRC
20:36japerry has quit IRC
20:38alexqwesa has quit IRC
20:39alexqwesa has joined #ltsp
20:39pmatulis has joined #ltsp
20:49rjune has joined #ltsp
20:58waldo323 has quit IRC
21:57ltspbot` has joined #ltsp
21:57ltspbot has quit IRC
22:02laron has joined #ltsp
22:02knipwim_ has joined #ltsp
22:06knipwim has quit IRC
22:07mgariepy has quit IRC
22:11laron_ has joined #ltsp
22:12laron has quit IRC
22:23johnny has joined #ltsp
22:30pmatulis has quit IRC
22:31mgariepy has joined #ltsp
22:36alkisg has joined #ltsp
22:44slidesinger has quit IRC
22:58
<alkisg>
Good morning all.
23:00artista_frustrad has joined #ltsp
23:03
<johnny>
alkisg, .. those settings weren't quite good enough for my monitor
23:03
i wonder if it was too low..
23:03
stuff wasn't showing up on the bottom of the screen
23:03
<alkisg>
Meaning?
23:03
<johnny>
and it was kinda flickery..
23:03
<alkisg>
What resolution did that give you?
23:04
<johnny>
first time i'd ever seen flickering wavy line on an lcd before :)
23:04
i wonder if the default is 1280x1024 or somethin
23:04
<alkisg>
Didn't that give you 1024x768@60Hz ?
23:04
<johnny>
yes
23:04
i think that just wasn't quite big enough
23:04
<alkisg>
For higher resolutions, you'd need to increase X_HORZSYNC
23:04
For higher refresh rates, X_VERTREFRESH
23:05
<johnny>
well.. aren't most lcds 60?
23:05
<alkisg>
...just do some experiments...
23:05
No, newer ones go to 75Hz
23:05
<johnny>
ah..
23:05
i wonder..
23:05
anyways.. the fat client experiment worked
23:05
<alkisg>
Well enough?
23:05
<johnny>
yeah
23:05
i didn't test with local devices tho
23:05
<alkisg>
Good to hear
23:05
I'd like to put an NFS option there, though..\
23:05
<johnny>
i did make the mods to the devicekit.disks polkit file
23:06
<alkisg>
instead of sshfs
23:06
<johnny>
i didn't have a udisks option
23:06artista_frustrad has quit IRC
23:06
<johnny>
ah.. it'd be nice to patch tthe null cipher in
23:06
<alkisg>
No, not for speed. For application support
23:06
<johnny>
ah
23:06
<alkisg>
Some applications need to create lock, and sshfs doesn't support that
23:06
<johnny>
the follow symlinks thing for chome and the like?
23:06
ah.. locking
23:07
hmm.. i thought there was an nfs option
23:07
yeah.. nfs would be better i guess
23:07
<alkisg>
At least for people that don't care much about security...
23:07
(like all teachers here :))
23:07
<johnny>
doesn't nfsv4 support security?
23:07
encrypted stff?
23:07
fedora defaults to nfsv4 in f13
23:07rjune has quit IRC
23:08
<johnny>
uggh.. i'm upset
23:08
the new hotssh is much better looking.. but it seems to have lost cut& paste
23:08
:(
23:08
<alkisg>
I think so, but I don't really care anyway - I'd even use it unencrypted, as long as locks work :)
23:10
<johnny>
hmm.. sadly.. fedora didn't go with grub2 like lucid did
23:10
<alkisg>
Wow, they still have grub legacy?
23:10
<johnny>
hmm.. what version of upstart does ubuntu have in lucid?
23:11
well. i don't think it was fair to call it legacy
23:11
<alkisg>
0.6.5-4
23:11
That's what it's called upstream, grub legacy
23:11
<johnny>
considering grub2 is only recently just good enough
23:11
<alkisg>
It's been called thus since 5 years or more...
23:11
<johnny>
i know.. but nobody was using non legacy :)
23:11
exactly
23:11
kinda soon to call something legacy if EVERYBODY was still using it
23:12
<alkisg>
They were trying hard to make distros switch to grub2 :)
23:12
For tooooo long....
23:12
<johnny>
obvioiusly they weren't helping well enough
23:12
by not solving the problems distros had with using it
23:12
<alkisg>
Maybe. Anyway it's good enough for me, it's much easier to work with than grub legacy, EXCEPT for the installation part
23:13
I could install grub legacy from a floppy. I can't do that with grub2...
23:13
<johnny>
hmm?
23:14
install grub from a floppy?
23:14
why would you want to do that?
23:14
to fix bad mbr?
23:14
<alkisg>
One use case, yeah
23:14
<johnny>
i don't have any computers that don't have cdroms
23:14
<alkisg>
Another one would be to install grub to winXX systems
23:14
<johnny>
and also can't boot usb
23:15
you would need to satisify both conditions
23:15
for that to matter to me
23:15
<alkisg>
Also, grub2 supports ntfs
23:16
<johnny>
so does that mean no more chainloading?
23:16
or what?
23:16
<alkisg>
That's needed for ltsp-loader, which converts XP workstations to ltsp clients
23:16
(grub2 in an .exe installer)
23:16
<johnny>
is the config syntax the same?
23:16
<alkisg>
No, very different
23:16
<johnny>
or is it all different?
23:16
ah
23:16
suck
23:16
<alkisg>
You can even drop files in /etc/grub.d now
23:17
And they get picked up by update-grub...
23:17
(sourced)
23:17
<johnny>
is that a feature of grub2 or an ubuntu patch/
23:17
i wonder when fedora will switch
23:17
would be nice to have my /boot as ext4..
23:17
<alkisg>
I'm not sure, it looks like upstream work...
23:17
<johnny>
but otherwise.. i don't personally need it
23:18
<alkisg>
I haven't seen any grub2 problems since karmic - and I started using it on jaunty...
23:22
<johnny>
ah really?
23:22
yeah.. then i'm suprised fedora isn't already using it
23:24
<alkisg>
It doesn't have packages at all, or they just aren't preinstalled?
23:25
<johnny>
never looked
23:26
no other grub
23:27
i'll see when i upgrade to f13
23:37vagrantc has joined #ltsp
23:51alkisg has quit IRC