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


Channel log from 24 August 2016   (all times are UTC)

00:21vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
00:34GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
02:47GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds)
03:03Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 250 seconds)
03:08Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
03:20
<alkisg>
!local-boot
03:20
<ltsp>
local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
03:20
<alkisg>
bennabiy: you can either use that ^
03:20
...or uefi booting, which isn't yet very much supported by ltsp and it needs manual setup
03:20
*uefi network booting
03:21
Erm, no, local-boot isn't what I meant; I meant putting the kernel+initrd in the local storage
03:22
I've implemented local kernel+initrd automatic updates
03:22GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
03:23
<alkisg>
!local
03:23
<ltsp>
I do not know about 'local', but I do know about these similar topics: 'install-localapp', 'localdev', 'localapps-print', 'RDP-localdev', 'localapps', 'LocaldevCommonGroupWorkaround', 'localxterm', 'local-disks', 'local-boot'
03:24
<alkisg>
!kernel
03:24
<ltsp>
I do not know about 'kernel', but I do know about these similar topics: 'ltsp-update-kernels'
03:30
<alkisg>
This one is a bit slower (900 passmark), but it also has a VGA port... http://www.gearbest.com/tv-box-mini-pc/pp_365007.html
03:36
This one seems very similar to the one you got, maybe it has a better firmware: http://www.gearbest.com/tv-box-mini-pc/pp_324845.html
03:42GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds)
03:46
<alkisg>
This one has gigabit ethernet: http://www.gearbest.com/tv-box-mini-pc/pp_343636.html
04:55ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:27forum has joined IRC (forum!~Icedove@194-96-56-215.adsl.highway.telekom.at)
06:39mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:40forum has left IRC (forum!~Icedove@194-96-56-215.adsl.highway.telekom.at, Quit: forum)
07:01forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
07:26forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum)
07:26forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
07:32forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Remote host closed the connection)
07:32forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
07:45forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum)
07:55kjackal has joined IRC (kjackal!~quassel@91.138.174.161)
08:02Statler has joined IRC (Statler!~Georg@p5DD6F595.dip0.t-ipconnect.de)
08:13kjackal has left IRC (kjackal!~quassel@91.138.174.161, Remote host closed the connection)
08:21kjackal has joined IRC (kjackal!~quassel@91.138.174.161)
08:22gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
08:39neprox has joined IRC (neprox!1f1e3e23@gateway/web/freenode/ip.31.30.62.35)
08:41
<neprox>
Hello, our diskless stations are connected to display via minidisplayport, but after boot process, when login screen should show, display poweroff. Is there some option to allow displayport on ltsp?
08:42forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
09:03forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Remote host closed the connection)
09:26
<alkisg>
neprox: does the same distro/version work with a live usb stick?
09:28
If yes, it's an ltsp issue. If not, it's not an ltsp issue so you should ask in your distro channel
09:33
<neprox>
ok, i tried it with ubuntu live distro and problem is the same (debian on ltsp). So it could by hardware problem, thanks
11:02forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
11:14GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
11:38
<alkisg>
!epoptes
11:38
<ltsp>
epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
11:38
<alkisg>
neprox: you can use that ^ to monitor the clients while they're at ldm
11:38
E.g. you can run xrandr, try different resolutions etc
11:39
So if it's a matter of wrong resolution, you can then just set XRANDR_MODE_0=xxx
13:07
<bennabiy>
alkisg: do you have an example of your script?
13:07
<alkisg>
bennabiy: which script?
13:08
<bennabiy>
for the nbd to work until it syncs, and then to pull from local instead
13:09
<alkisg>
No, I haven't written it yet
13:09
<bennabiy>
I wonder if there is a way to have a fat client where you can install packages, and then with a flag, you can sync the changes to the RO image
13:09
<alkisg>
Instead of using ltsp-pnp?
13:09
<bennabiy>
no
13:09
after the fat client is generated
13:10
<alkisg>
I mean, ltsp-pnp is about doing what you said on the server
13:10
But you want to do it on the client
13:10
<bennabiy>
similar
13:10
<alkisg>
You could use nbd-server in a writeable mode instead of read-only,
13:10
<bennabiy>
on a selective basic?
13:10
basis*
13:10
<alkisg>
but you would need to "emulate" ltsp-update-image --cleanup in order to remove the settings that you don't want
13:10
Yes, nbd-server supports per-ip etc exports
13:11
<bennabiy>
I will have to look up the docs on that
13:12
especially with some type of local storage to sync to and from
13:12
<alkisg>
For example, the fat client would have an /etc/passwd entry that you wouldn't want, and an /etc/program/setting entry that you would want
13:12
<bennabiy>
yes
13:12
<alkisg>
So you would need to duplicate what ltsp-update-image --cleanup does
13:12
It's not just "a flag to sync"
13:12
<bennabiy>
well, to initially call the sync could be a flag on a command
13:13
it would obviously have to have more on the backend to make it work
13:13
I am just talking about the possibility
13:13
<alkisg>
It's what ltsp-update-image --cleanup does, so yup it's possible
13:13
I just don't think it's worth it to support doing it from 2 different places, server/client
13:14
You can just run ltsp-pnp on the client itself
13:14kjackal has left IRC (kjackal!~quassel@91.138.174.161, Ping timeout: 244 seconds)
13:14neprox has left IRC (neprox!1f1e3e23@gateway/web/freenode/ip.31.30.62.35, Quit: Page closed)
13:15
<bennabiy>
The idea being that you could generate the initial fat client image through either --cleanup or build-client, and then while running from the fat client, you could install software to the client ram, but then if you decide that you want it to remain in the image, you wouldn't have to go back to the server, and try to recreate your package choice etc, especially if you only want it for a select image (client basis)
13:15
is the script already in the client?
13:15
<alkisg>
I don't think maintaining images is a spontaneous idea
13:15
<bennabiy>
if you did the initial build by doing ltsp-build-image
13:16
<alkisg>
If you want to install a program to the image, you can use ltsp-pnp on the client
13:16
And you can duplicate as many images as you want
13:16
<bennabiy>
The thing I do not like about ltsp-pnp is that there is no chroot apart from the server for custom images to be spun from
13:16
<alkisg>
/opt/ltsp/images/i386.img is the chroot
13:16
You can have 100 of them
13:16
<bennabiy>
yes
13:17
but the squashfs is not very friendly to open, update, etc
13:17
I have done it in the past, but it was a hack
13:17
<alkisg>
That's a completely different conversation
13:17
One was how to generate the image
13:17
Now it's about the image format
13:17
<bennabiy>
no, I would say they are related
13:18
<alkisg>
What would you purpose about the image format?
13:20
<bennabiy>
So, if I generated an image say customi386.img and I wanted to make 100 copies of it, with a couple customizations, either programs or settings etc, I would have to set up a machine, and make the changes, and then rewrite the image, so to change one setting takes setting up the machine again,...
13:21
I am fine with ltsp-pnp if I can run it on the client, and have it write the image back to the server
13:21
or if nbd can mount RW
13:21
<alkisg>
I think that what you're trying to say is that you'd like ltsp to support .diff files for images
13:21
That can be done with ltsp-pnp or without it, it's a conversation about the image format
13:22
It's very difficult to implement it properly though, no matter how you maintain the image (chroots, ltsp-pnp, clients, server...)
13:22
<bennabiy>
true
13:22
perhaps I am unable to communicate my desire clearly because of frustration in the past at trying to get it working
13:23
please do not take it personally against you or anything of the like
13:23
<alkisg>
of course not
13:23
Don't think that we haven't thought about that idea...
13:23
squashfs doesn't have the appropriate tools to do that
13:23
<bennabiy>
yes
13:23
that is why I have been frustrated in the past
13:23zerkalo has left IRC (zerkalo!myricae@ny1.hashbang.sh, Ping timeout: 244 seconds)
13:23
<alkisg>
It could be done with e.g. a plain ext4, or a compressed btrfs, or an nfs-based overlayed chroot
13:24
All those have their down-sides
13:24
<bennabiy>
hrm,... zfs could have some benefits in this
13:25
<||cw>
bennabiy: this sounds a lot like how ubuntu does their persistent livecd
13:25
<alkisg>
So up to now, what we implemented was that for "per client" things, we would either maintain different images normally (ltsp-pnp or chroots), or implement init-ltsp.d boot scripts to differentiate between them
13:25zerkalo has joined IRC (zerkalo!myricae@ny1.hashbang.sh)
13:25
<alkisg>
casper is just using overlayfs, like ltsp does
13:25
(the ubuntu livecd mechanism)
13:26
<||cw>
right, but with the RW part being saved to USB
13:26
which ltsp doens't do, at least by default
13:26
<alkisg>
The key there is that they never allow the bottom image to be updated
13:26
Which would make what bennabiy asks, worthless
13:26
<||cw>
yes, which is easy with squashfs
13:27
<bennabiy>
alkisg: I do not mind the bottom image being RO as long as persistent updates can be done on the clients
13:27
for example, make the base image, but then have customizations on a per client bases based on the base image
13:27
<||cw>
maybe the RW image could be on nfs or something
13:27
<alkisg>
bennabiy: that means that when you update the bottom image, you would have to delete all the client .diffs and start over from zero
13:28
If that's OK for you, then that's very easy, just 2 layered nbd images
13:28
<bennabiy>
alkisg: true, I am not saying I have the answers, just projecting what my goal is
13:28
<alkisg>
One ro squashfs, the other rw per client
13:28
I'm asking about your specifications, not the solutions to them
13:28
<||cw>
you're also getting into how virtual desktops work
13:29
<alkisg>
If that satisfies you (deleting all .diffs on master image updates), then it's very easy to implement
13:31
I've implemented that for providing windows VMs, one for each LTSP user, upon a master template maintained by the teacher
13:31
The bottom image is the .vdi, and the .diff is the vbox snapshot over the RO .vdi
13:32
<bennabiy>
I might be able to work with that
13:32
<alkisg>
And of course the fact that they have to delete all the snapshots when they update the .vdi image, bothers them... but that's the best I can give them for windows
13:33GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds)
13:34
<bennabiy>
so if I had to do a system update on the .vdi for example, I would have to then reimage each machine with customizations again?
13:35
<alkisg>
Yes
13:35
<bennabiy>
or I could keep the updates as part of the diff, making the need to update the base image less?
13:35
<alkisg>
You could update all the e.g. 10 clients images instead of updating the master one
13:35
<bennabiy>
I could see the images all getting quite large then
13:35
<alkisg>
Yup
13:36
<bennabiy>
bah
13:36
<alkisg>
And having to do that 10 times is annoying
13:36
<bennabiy>
yes
13:36
which is more annoying, recustomizing or updating 10 times?
13:36
<alkisg>
That's why we focus on solving things from init-ltsp.d, on boot
13:36
<bennabiy>
but I guess either way I would have to do both with that method
13:36
eventually
13:36
<alkisg>
Give me one customization example
13:38
What would you need to customize on a per-client basis?
13:38
E.g. a program? Just install it everywhere, and hide/delete the desktop entry or service from init-ltsp.d
13:38
A driver? Activate it/deactivate it from init-ltsp.d
13:39
The good part there is that you only write the init-ltsp.d script once, for all future installations
13:39
<bennabiy>
ok, I used a lot of IDE type things, as well as being set up to build apps etc. I also have a lot of administrative apps installed which the normal users do not need, and then I have another user who does mostly transcribing, another who does layout etc
13:39
I could have the apps all installed for everyone in the same image, there are certain things which only 1 person uses
13:39
and the rest do not need
13:39
<alkisg>
So? it won't take more disk space or bandwidth
13:40
Having multiple images, will
13:40
Having all programs in one image, won't.
13:40
<bennabiy>
alkisg: true, but I also do customizations to debug / test
13:40kjackal has joined IRC (kjackal!~quassel@ppp-94-65-249-7.home.otenet.gr)
13:40
<bennabiy>
so even maintaining two images would probably be what I need
13:40
<alkisg>
It's normal to maintain a second image for testing etc
13:40
<bennabiy>
which I guess I could just generate two
13:40
and control the access through tftp
13:40
<alkisg>
You can very easily clone i386.img and append on that
13:41
<bennabiy>
so back to my frustration
13:41
<alkisg>
The debug image doesn't need to be squashfs
13:41
You can clone it to ext4, btrfs, wherever
13:41
You can also boot it with a vm and modify it
13:41
(e.g. vbox)
13:41
(or directly from a client)
13:42
You can also use the .diff thing for a single client, for debug purposes
13:43
The debug .diff is usually discardable, while the "maintaining one image per client" isn't
13:43
<bennabiy>
true
13:43
<alkisg>
Finally, many times you can debug on the fly, from a fat client, without reboot
13:43
<bennabiy>
I do not necessarily want to maintain an image per client but to have classes of images
13:44
<alkisg>
What i'm proposing is that you minimize those classes
13:44
E.g. install all the programs and hide them, instead of maintaining multiple images for each class
13:44
If you seriously need 2 different images for something, sure, do it
13:44
<bennabiy>
but if I like the changes, I would like an effective way to write those changes back to the main image
13:44
I agree
13:45
<alkisg>
So far I only needed 2 images when I'm having mostly 64bit clients, and I also want a thin chroot for really old i386 clients
13:46
<bennabiy>
that is the other thing is I have all 32 bit thin clients and the fat clients will be 64
13:47
<alkisg>
For mixed i386 and amd64 clients with <=3 gb ram, we still use a single i386 image
13:58ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:59mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:03gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
15:26ARK40BR has joined IRC (ARK40BR!b3d825af@gateway/web/freenode/ip.179.216.37.175)
15:26
<ARK40BR>
good morning for all
15:27
a recent install Ubuntu 16.04 lts but on the thin client is a extremely slowing.!
15:27
any help me
15:37ARK40BR has left IRC (ARK40BR!b3d825af@gateway/web/freenode/ip.179.216.37.175, Ping timeout: 264 seconds)
15:39Statler has left IRC (Statler!~Georg@p5DD6F595.dip0.t-ipconnect.de, Quit: Leaving)
15:49vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:51pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds)
17:04pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
17:07robb_nl has joined IRC (robb_nl!~robb_nl@ip-62-235-224-54.dsl.scarlet.be)
18:11vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
18:14robb_nl has left IRC (robb_nl!~robb_nl@ip-62-235-224-54.dsl.scarlet.be, Quit: I'm gone, bye bye)
18:21yanu has left IRC (yanu!~yanu@178-116-57-70.access.telenet.be, Ping timeout: 244 seconds)
18:23yanu has joined IRC (yanu!~yanu@178-116-57-70.access.telenet.be)
18:41forum1 has joined IRC (forum1!~Icedove@193-80-182-32.adsl.highway.telekom.at)
18:41forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Read error: Connection reset by peer)
18:41forum1 is now known as forum
18:57forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Remote host closed the connection)
18:57forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at)
19:16forum1 has joined IRC (forum1!~Icedove@193-80-182-32.adsl.highway.telekom.at)
19:16forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Read error: Connection reset by peer)
19:16forum1 is now known as forum
20:19ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:30forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum)
22:44adrianorg has left IRC (adrianorg!~adrianorg@177.204.158.221.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds)
22:45adrianorg has joined IRC (adrianorg!~adrianorg@189.114.73.56)
22:54kjackal has left IRC (kjackal!~quassel@ppp-94-65-249-7.home.otenet.gr, Ping timeout: 264 seconds)
23:15url has left IRC (url!~fnurl@36-229-142-205.dynamic-ip.hinet.net, Read error: Connection reset by peer)
23:28ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
23:54GodFather has joined IRC (GodFather!~rcc@68-188-241-8.dhcp.trcy.mi.charter.com)