alkisg, only the fact that home folder is on the server, am I correct?

06:53

<alkisg>

No

06:53

When you want to load openoffice, you need about 120 MB of data

06:54

I.e. the program and its libraries

06:54

<bakytn>

alkisg, and it loads over the network?

06:54

<alkisg>

That is read from the server

06:54

Yes

06:54

<bakytn>

alkisg, ok

06:54

<alkisg>

A fat client is similar to a client booted from a usb disk

06:54

Except that instead of usb, it's a network disk

06:54

And the server caches the reads, so it's a bit like a slow SSD disk

06:55

Very low seek times but a bit low bandwidth as well

06:55

All in all, fat clients performance should be quite similar to local installations

06:56

So if you don't have configuration/network etc problems, and you think it's slow, it's just linux that is slow on your clients (or your clients not good enough for it)

06:56

<bakytn>

alkisg, my problem strange... it all work fine, apps, browsing, video playbacks etc. The problem is only about UX. I thought it's a xsession related but I tried everyting GNOME, KDE, LXDE, Cinnamon. etc

06:56

alkisg, but what I must do right now, is to install some desktop directly on the device to compare

06:57

<alkisg>

Right. Or on an external usb disk.

06:59

<bakytn>

alkisg, what am I thinking about right now is to use a thin client setup but install all other apps as a local apps. This might work too I guess

07:04

alkisg, sorry one more question. Can I just copy NBD images and chroot (i.e: i386 and images) folders to another completely independent server or they must be on an LTSP server?

07:08

<vnc786>

i tried xfce on amd dual core4gb http://picpaste.com/sc-WyBV9J2B.png

07:10

<bakytn>

vnc786, how is it? working good?

07:10

<alkisg>

bakytn: local apps vs fat clients is the same thing

07:10

Don't expect them to go faster

07:11

You can transfer the nbd image and tftp dir to another server, yeah

07:11

<bakytn>

alkisg, apps working great, UX is not as fat clients, so having UX running on Server (xsession etc.).. I will test anyway :D thaks

07:12

<alkisg>

bakytn: what is UX?

07:12

<bakytn>

alkisg, user experience

07:12

alkisg, in my situatino is user desktop experience

07:12

<alkisg>

...it doesn't make sense though :)

07:12

UX == desktop, firefox, flash, whatever

07:12

But you say apps run fine

07:13

<bakytn>

alkisg, if I transfer those dirs to another Linux, what I need is just a tftp server and no ltsp related software, correct?

07:13

<alkisg>

Maybe you're only talking about the Desktop Environment, DE ?

07:13

<bakytn>

alkisg, yes in my sitaution UX is only about Desktop :D

07:13

<alkisg>

tftp and nbd server

07:13

<bakytn>

alkisg, ok!

07:13

<alkisg>

If e.g. firefox is going fast and the desktop is slow, troubleshoot or change the desktop

07:13

* alkisg prefers gnome-fallback session

07:14

<vnc786>

alkisg: can u see the image which i uploaded ...!! u guided me to use different DE..and i did ...

07:14

<bakytn>

alkisg, yeah need to test test and test. But I am happy that browsing is pretty much smooth (local app)

how this works ? fat clients get booted(amd64.img) at (let say) 10.00 am and if add/remove some application at 11.00am and rebuild image then fat clients which get booted after 11.00 am will get new image but still the fat clients which got image at 10.00 am are working fine....

jammcq has joined IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net)

13:50

<jammcq>

good morning friends

13:50

<sbalneav>

jammcq: Morning!

13:50

<jammcq>

Scotty !!!!!!!!!!!!!!!!!!!!!!!

13:51

Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)

13:53

<sbalneav>

alkisg: ping, you about?

14:00

<cpm__bis>

Hi everybody. LTSP installed on Debian squeeze. There is only one issue. LDM login failed. On the local thin client SCREEN_08=shell, if I do ssh myuser@server, then the LDM login succeed. Any idea? Heeeeelp! :o)

cpm__bis: i dont know about thin client but i faced same issue on fat clients i was able to ssh username@server but thru GUI i was not able the solution was that /tmp directory in chroot should have drwxrwxrwt perm..u might facing some issue related to permission ..

14:08

<sbalneav>

cpm__bis: You might need to do the ltsp-update-sshkeys

14:16

Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)

14:20

<cpm__bis>

vnc786, thx, permission on the local /tmp are right.

14:20

sbalneav, already done, without result.

14:21

The issue is when the thin client done ssh ... echo LTSPROCKS, it failed there.

14:21

<sbalneav>

Do you locally customize .profile, .bashrc, etc?

14:22

<cpm__bis>

If I do it manually and answer 'yes' to "Are you sure you want to continue connecting(yes/no)?", then it's running well.

If it's asking if you want to continue connecting to an ssh, is it first complaining about unknown host?

14:23

<cpm__bis>

yes

14:23

<sbalneav>

Because if it is, it's your ssh keys.

14:24

MadX_ZA has joined IRC (MadX_ZA!~adrians@152.106.1.5)

14:24

<sbalneav>

ok, so you need to debug why ltsp-update-sshkeys isn't working for you/

14:25

Are you running an nbd chroot, or an nfs chroot?

14:25

<cpm__bis>

nfs chroot

14:25

localy, I see /etc/ssh/ssh_known_hosts

14:26

<sbalneav>

so you run ltsp-update-sshkeys, and reboot the thin client, and it still doesn't know about the server?

14:26

<cpm__bis>

it contains entry for "server"

14:27

but in ldm.log, the ssh try to reach the ip 172.16.0.3, not "server" (even if the ip of "server" is 172.16.0.3)

14:27

sbalneav, it is exactly that.

14:29

<sbalneav>

what does your lts.conf file look like?

14:30

Can you pastebin it?

14:30

!paste

14:30

<ltsp>

paste: try !pastebot

14:30

<sbalneav>

!pastebot

14:30

<ltsp>

pastebot: try !pastebin

14:30

<sbalneav>

!pastebin

14:30

<ltsp>

pastebin: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.

14:34

<cpm__bis>

http://pastebin.com/bCDvSQ0v

14:35

This is the default one. I added the SCREEN entries to debug

14:36

14:37

in the ldm.log, I see ssh ... test@172.16.0.3

14:37

but this IP is not in the ssh_known_hosts

14:37

so when I do ssh test@172.16.0.3, it asks me confirm.

14:38

If I do ssh test@server, it not asks me to confirm.

14:38

<sbalneav>

So, I'd add 172.16.0.3 into the ssh_known_hosts.

14:39

<cpm__bis>

Hahahahahaah, so simple!

14:39

Yes, it is a simple and good solution.

14:39

I don't know I was focus on the normal way...

14:39

tsss

14:40

So, just for the fun. Did you know how config correctly to generate ssh ... test@server in replacement of ssh ...test@172.16.0.3... ?

14:44

<alkisg>

sbalneav: hello!

14:46

cpm__bis: in recent LTSP versions, it tries to connect to @server. I don't know what version squeeze has. Try LDM_SERVER=server.

14:49

<cpm__bis>

alkisg, hoooo, I check immediatly

14:49

<sbalneav>

alkisg: ok, so I've done some thinking/playing the last day or so.

14:51

I think sshfs will work, but we're going to need something to do the automounting. I'm not sure udisks will work, since we need 2 bits of custom behaviour:

1) We need an automounter that understands some LTSP variables, and calls a shell script when it mounts. That's so when the mount happens, we can inform the server.

14:52

<cpm__bis>

Now I can move the server to the classroom. Teachers and students will be glad. :-)

14:52

<sbalneav>

2) We need an automounter that will mount with /media/userid/DEVICE, as opposed to /media/DEVICE, to maintain consistency between tc and fc.

14:53

So, I will do some work opposite that.

14:53

<alkisg>

cpm__bis: note though that you shouldn't have to do that manually, ltsp-update-sshkeys should have made the IP connection work without you defining LDM_SERVER

14:53

sbalneav: about (1), I'm guessing that udisks and other tools will have a place where we can put hook scripts...

14:54

<sbalneav>

They don't. I checked.

14:54

<cpm__bis>

alkisg, hooo, I will chek the script.

14:54

<alkisg>

Meh. So much for dbus and all the exciting technologies :D

14:55

sbalneav: so, we're sticking with our own udev rules?

14:56

<sbalneav>

No.

14:57

We'll have our own automounter that uses udev/dbus.

14:58

https://github.com/LemonBoy/ldm

14:58

markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)

14:58

<sbalneav>

This can probably be forked/adapted.

15:00

If we modify/adapt that lightweight device mounter, and couple it with sshfs, we should be able to do what we want. It already supports scripted callouts.

15:00

<markit>

alkisg , Phantomas : hi, currently I use greek ppa for ltsp, but regarding epoptes, do you suggest me to use the specific epoptes ppa to have "the latest the greatest" or is too "experimetnal"? I would love to follow epoptes improvements more closely and have new features like miniature size modificable, multithread broadcast etc..

15:01

<alkisg>

markit: we upload new stable epoptes versions to that ppa

15:01

So you don't need to add the other ppa as well

15:02

(as long as you're using lts releases...)

15:02

<markit>

alkisg: I'm on 12.04

15:02

<alkisg>

OK

15:02

<markit>

so is "stable enough", ok, I'll add that ppa

15:03

alkisg: btw, I've seen discussion here about LightLDM, I've no clue of what I'm saying, just pointing you to SDDM just in case is of any interest for you: http://qt-apps.org/content/show.php/SDDM%3A+Simple+QML+Based+Display+Manager?content=156539

alkisg: ah, sorry, "as long as..." ok, I thought the contrary (lts more conservative, other more updated)

15:04

<alkisg>

QML is the new trend, let's see how that works out

15:05

* alkisg is also curious about how MIR will affect LTSP

15:05

<markit>

alkisg: btw, do you have any experience of pfsense or zeroshell? what would you suggest? I need (a friend of mine needs) dansguardian, access control, etc. and I would love put that stuff out of ltsp server, with a firewall between ltsp and the router

15:05

<alkisg>

But I prefer Qt to GTK, it seems more mature

15:05

No experience

15:06

<sbalneav>

None of the new "X Replacements" (Mir or Wayland) support protocol-over-ip, to my knowledge, so certainly I won't be adopting them, as they don't allow for true thin-client like what I run around here.

15:07

<markit>

ok, last request for epoptes, but probably have already be filed, is have a visual clue on the miniature to know which one have the teacher screen broadcast active, i.e. if you do in "window mode" and a child closes that window by mistake, would love to be able to know what to activate again

15:07

<alkisg>

sbalneav: I see org.freedesktop.UDisks on dbus, providing signals like "DeviceAdded()"

15:07

sbalneav: so a dbus listener would be all that's needed?

15:08

<markit>

I've seen that with big screens the window mode broadcast is useful... in that window, half the 24" screen, the student sees what the teacher is doing, in the other half he tries to mimic

15:08

<sbalneav>

Correct, that's what that url I pointed to does.

15:08

The code's not that big, plus it's doing things we may not need.

15:09

<alkisg>

sbalneav: is udisks cross-distro enough? Or rhel-based distros are using something systemd-based there?

15:10

<sbalneav>

systemd will be an issue we'll have to deal with, but one assumes that we can come up with at "systemd" listener.

15:10

I don't know, since none of the systems I'm interested in currently need systemd. I trust that interested parties will provide solutions.

15:12

<muppis>

This is not really LTSP related, but nfs-booting anyway. In middle of booting, nic were it was booting is switched to totally different and can't find nfs root from there and, of course, causes kernel panic. :/

15:13

<markit>

Phantomas: https://bugs.launchpad.net/epoptes/+bug/1157241 (better later than never ;P)

15:17

<alkisg>

muppis: did you list the nic in /etc/network/interfaces as "manual"ly configured?

15:18

<muppis>

alkisg, sure. Other host boots fine and never had this problem.

15:18

host/client/machine

15:19

<alkisg>

And "totally different" means? Different ip?

15:19

<muppis>

Different nic. There is no cable plugged in nic which it switches.

15:20

lee___ has joined IRC (lee___!~lee@loathe.ms)

15:20

<alkisg>

sbalneav: can you take a look at this ubuntu package? udisks-glue - simple automount daemon with support for user-defined actions

15:21

muppis: try IPAPPEND 2 in the kernel command line

15:21

*pxelinux.cfg, I meant

15:21

<sbalneav>

alkisg: Even better; looks like there's one available. Yeah, if we can write stuff for that, perfect. I'll look.

15:21

lee has left IRC (lee!~lee@loathe.ms, *.net *.split)

15:21

lotharn has left IRC (lotharn!~taco@24.154.55.32, *.net *.split)

15:25

<muppis>

alkisg, does that work in non-ltsp systems?

15:25

<alkisg>

yes, it's pxelinux, one of the tools that ltsp uses but not ltsp-specific

15:25

biomorph has joined IRC (biomorph!~biomorph@91.85.204.16)

15:25

<muppis>

Ok.

15:27

Machine is HP DL360p gen8. Takes about 2 min per POST. :(

15:32

No effect. It's still finds wrong nic as that where it was booting on.

15:33

<alkisg>

muppis: that's on the initramfs, right? Do you get a busybox shell after that?

15:34

If so, cat /proc/cmdline and verify that the MAC address of the boot nic is listed there

15:34

<muppis>

Yes, it's on initramfs. I don't get a shell after that. I get kernel panic.

15:34

<alkisg>

muppis: try break=mount in pxelinux.cfg/default

15:34

You should get a shell before the mounting

15:35

<muppis>

I've set --verbose debug=100 so I see the MAC and it's different.

15:35

<alkisg>

Btw, ipappend 2 gets on a separate line, right?

15:35

Pastebin your pxelinux.cfg/default if unsure

15:36

<muppis>

http://pastebin.com/g5S7VkX7

15:39

Hmm...

15:40

garymc has joined IRC (garymc!~chatzilla@host81-139-87-129.in-addr.btopenworld.com)

15:42

<muppis>

http://pastebin.com/9hapMSJK -- It boots from eth1, where in this paste is presented as eth2. eth1 in paste is the wrong one.

15:45

<alkisg>

muppis: remove the =

15:45

<sbalneav>

I'm not exactly sure what consolekit requires in order to mark a session as "Active".

15:45

<alkisg>

It's "ipappend 2", not "ipappend=2"

15:46

<muppis>

yes.

15:46

http://pastebin.com/hj5mPHte -- This happens.

15:48

<alkisg>

muppis: so, do you see BOOTIF in the `cat /proc/cmdline` output?

15:49

Finally, you can also try with "ipappend 3" instead of 2

15:52

<muppis>

With ipappend 2 it works, but still nics are in wrong order.

15:52

Parker955_Away is now known as Parker955

15:53

<alkisg>

The nic names are determined by udev rules

15:55

<muppis>

It interlaces them. Two cards with 4 nics per each. They should be ordered by mac like eth0-3 from first card and eth4-7 from second, but now they are interlaced like eth0 from first and eth1 from second and so on.

15:55

<alkisg>

sbalneav: I think if we use "su - user", then ck-list-sessions will list the session as active, as long as it's on the fgconsole

15:56

sbalneav: previously we didn't use `su`, so I had to resort to setting the CKCON* environment variables in X95-run-X-session

15:58

Btw, I think consolekit will go away in favor of logind...

15:58

So we might want to concentrate on that one

15:59

<sbalneav>

What will we do for wheezy? It's what I'll be running here, hopefully, in a few months?

I put my /opt/ltsp/i386/etc/ssh/ssh_known_hosts there: http://pastebin.com/Hfn5cUHb This file was generated by ltsp-update-sshkeys. Do you confirm that "server" have to be replace by * when I run ltsp-update-sshkeys ?

16:24

I am using the package ltsp-server 5.4.2-2~bpo60+1 from Debian

16:32

vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)

15:59<sbalneav> What will we do for wheezy? It's what I'll be running here, hopefully, in a few months?

18:03

==> no idea, only vagrantc can answer that one :)

18:04

<ogra_>

backports galore

18:04

<alkisg>

sbalneav: so you no longer use ubuntu in any of your installations/home pcs?

18:05

<ogra_>

i just read that backports in debian are officially supported now

18:06

<alkisg>

ogra_: did I understand correctly that Unity is now to be written in QML? So, for e.g. 13.10 that MIR won't be there yet, we'll be able to run Unity on thin clients (2d accelleration only) again?

18:06

<ogra_>

no

18:06

ubuntu touch is written in OML

18:06

*QML

18:07

ubuntu desktp wont change (yet ?!?)

18:07

<vagrantc>

i'll make efforts to support backports

18:07

for wheezy

18:07

i usually do.

18:07

<alkisg>

ogra_: ah, so MIR isn't a target for 14.04 for the desktop too?

18:07

<ogra_>

alkisg, and you will always be able to use X it wont go away ... you will even be able to use X on top of Mir without issues

18:08

Mir just replaces the drivers and the compositor

18:08

<alkisg>

X on top of MIR ==> too bloated for thin clients with 64 or 128 ram, we'll have to go fat on those

18:08

<ogra_>

it wont be different to what you have today

18:08

most likely even faster and smaller

18:08

<alkisg>

I just hope some good remote desktop solution will emerge for the composition era of linux...

18:09

<ogra_>

X on top of Mir means the X protocol ... not the whole of X

18:09

you wont have to carry all the low level bloat

18:09

<sbalneav>

alkisg: We have ubuntu here still, but I'm going to be phasing it out in favour of Debian.

18:09

<alkisg>

ogra_: ah, so something like Xephyr now? Just a thin layer?

18:09

<ogra_>

(and instead get the Mir C++ low level bloat i guess ;) )

18:10

yeah

18:10

the good stuff will be that you wont have to care for drivers at all anymore

18:10

no matter how good or bad wayland and mir are ... thats a massive advantage

18:11

<alkisg>

Sure, reusing android drivers is a good thing... but I thought wayland also had plans for that

18:11

<ogra_>

both talk directly to the kernel display drivers (and to lib GLES/EGL)

18:11

wayland dropped all android support they previously had

18:12

<alkisg>

ogra_: also, is python now getting a bit deprecated for the ubuntu desktop in favor of javascript?

18:12

<ogra_>

dunno i guess we'll still have tons of python ... that wont go away

18:12

<alkisg>

But for new desktop apps, javascript/qml is suggested, right?

18:13

And c++/qml for the more advanced ones...

18:13

<ogra_>

not atm, no

18:13

for ubuntu touch it is

18:13

they are completely distict things atm

18:13

*distinct

18:13

<alkisg>

Ah, so the ubuntu sdk isn't for all devices, it's just for ubuntu touch...

18:13

<ogra_>

right

18:13

<alkisg>

Gotcha

18:13

<ogra_>

eventually i suspect unity will become QML ...

18:14

but that wont stop you from running and developing Gtk apps for it

18:14

* alkisg prefers Qt as long as it's a "first class citizen"...

18:14

<ogra_>

like you dont need to be able to write compiz to have a desktop app today

18:15

its the layer that nobody but the unity team touches anyway that gets changed

18:15

everything around it will go on to work as before

18:17

there was so much FUD spread around Mir ...

18:17

* ogra_ had quite some sad days the last weeks

18:17

<alkisg>

Well, canonical didn't handle it good though

18:18

Telling people to focus on one thing, then secretly focusing on another for months

18:18

It's the worse thing about ubuntu; it's a moving target, changing course every few months

18:20

I really like the idea of using qt for the desktop and a layer that can reuse the android drivers for the graphics

18:20

I hope this one sticks and doesn't get dropped after a couple of years...

18:21

<ogra_>

agreed, we didnt handle it well, but we also had issues in the past where we started something that had no code yet and were bvlamed for that

18:22

so the idea was to first have some code to present before revealing it to exactly not run into that trap again

18:22

PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.141.131)

18:22

<alkisg>

I imagine there are political reasons for not using wayland for that too

18:22

<ogra_>

which turned out to be a lot worse and even more full of lies and FUD

18:22

<alkisg>

Not technical reasons

18:22

But anyways, I just hope it turns out for the best

18:22

<ogra_>

well indeed

18:22

canonical now has its own systemd

18:23

* ogra_ is really curious how debian will havndle gnome installs in a year from now btw :)

18:24

<alkisg>

Why? Wrt systemd integration?

18:24

<ogra_>

it will mean requiring systemd and wayland on the system level

18:24

gnome decided they will drop X support in favour of wayland with their next iteration ... and redhat/fedora is forcign userland gnome into systemd

18:24

<vagrantc>

it's a newish kind of vendor lock-in.

18:24

<ogra_>

yep

18:25

<vagrantc>

after decades of compatibility, it seems like a lot of players have just decided to give up.

18:25

<ogra_>

thats one reason for the move to Mir (teh political one you mentioned above)

18:25

<vagrantc>

and implement what *they* believe to be the next incompatible way forward...

18:26

<ogra_>

there are some massive design differences too between wayland and mir though ...

18:26

<alkisg>

Wayland isn't controlled by redhat though, is it? I thought even intel contributes to it...

18:26

<ogra_>

the majority of devs is fedora ...

18:26

like systemd (which today is also consolekit policykit and udev btw)

18:26

<alkisg>

Ah, so they'd try to enforce their stuff like they do for systemd, got it

18:27

<ogra_>

systemd will bite everyone long term

18:27

you wont have a standalone udev anymore

18:28

<cpm__bis>

I put my /opt/ltsp/i386/etc/ssh/ssh_known_hosts there: http://pastebin.com/Hfn5cUHb This file was generated by ltsp-update-sshkeys. Do you confirm that "server" have to be replace by * when I run ltsp-update-sshkeys ?

18:28

<alkisg>

cpm__bis: in newer ltsp versions, the client tries to connect to "server", not to "ip"

18:28

Maybe you don't have a recent enough ldm version?

18:28

And you only have a very recent ltsp backport?

18:29

cpm__bis: run `ltsp-info` and put the result to pastebin

18:29

<cpm__bis>

alkisg, surely, Debian squeeze with only backports...

18:29

<alkisg>

vagrantc knows about the squeeze backports versions, /me is very fond of debian but doesn't have any deployments with it yet...

cpm__bis: but anyways if LDM_SERVER=server in lts.conf makes it work for you, I don't think you need to bother with that anymore...

18:30

<cpm__bis>

http://pastebin.com/kJkG8H08

18:31

<vagrantc>

cpm__bis: do you have backports both on server and in the chroot?

18:31

cpm__bis: ltsp-info

18:31

!pastebin | echo cpm__bis

18:31

<ltsp>

cpm__bis pastebin: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.

18:31

<alkisg>

cpm__bis: I think your ldm is too old, you should have 2:2.2.11-2~bpo60+1

18:31

And you have ldm 2:2.1.2-2

18:31

<cpm__bis>

alkisg, allright, I wanted to know the normal procedure in anticipation a future installation.

18:32

<alkisg>

(08:31:25 μμ) vagrantc: cpm__bis: do you have backports both on server and in the chroot? ==> I think that nailed it

18:32

You probably need to enable backports in your chroot too

18:33

<cpm__bis>

alkisg, hooooo, yes, the chroot!

18:39

Gremble has left IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com, Quit: I Leave)

18:41

<cpm__bis>

vagrantc, I note the good link.

18:42

<vagrantc>

you need to specify --backports-mirror when building the chroot.

18:42

maybe some other things ... haven't tested it in a few months

18:43

* vagrantc should update the backports, too

18:59

komunista has joined IRC (komunista!~slavko@87.244.209.121)

19:00

<cpm__bis>

alkisg, you were so right. backport parameter in ltsp-build-client solve my issue. Wonderful, now I am using a good version of ldm and I have no more error in ldm login.