IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 24 August 2016 (all times are UTC)
| 00:21 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 00:34 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 02:47 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds) | |
| 03:03 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 250 seconds) | |
| 03:08 | Freejack 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:22 | GodFather 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:42 | GodFather 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:55 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:27 | forum has joined IRC (forum!~Icedove@194-96-56-215.adsl.highway.telekom.at) | |
| 06:39 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 06:40 | forum has left IRC (forum!~Icedove@194-96-56-215.adsl.highway.telekom.at, Quit: forum) | |
| 07:01 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 07:26 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum) | |
| 07:26 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 07:32 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Remote host closed the connection) | |
| 07:32 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 07:45 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum) | |
| 07:55 | kjackal has joined IRC (kjackal!~quassel@91.138.174.161) | |
| 08:02 | Statler has joined IRC (Statler!~Georg@p5DD6F595.dip0.t-ipconnect.de) | |
| 08:13 | kjackal has left IRC (kjackal!~quassel@91.138.174.161, Remote host closed the connection) | |
| 08:21 | kjackal has joined IRC (kjackal!~quassel@91.138.174.161) | |
| 08:22 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 08:39 | neprox 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:42 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 09:03 | forum 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:02 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 11:14 | GodFather 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:14 | kjackal has left IRC (kjackal!~quassel@91.138.174.161, Ping timeout: 244 seconds) | |
| 13:14 | neprox 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:23 | zerkalo 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:25 | zerkalo 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:33 | GodFather 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:40 | kjackal 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:58 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:59 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 15:03 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving) | |
| 15:26 | ARK40BR 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:37 | ARK40BR has left IRC (ARK40BR!b3d825af@gateway/web/freenode/ip.179.216.37.175, Ping timeout: 264 seconds) | |
| 15:39 | Statler has left IRC (Statler!~Georg@p5DD6F595.dip0.t-ipconnect.de, Quit: Leaving) | |
| 15:49 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:51 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds) | |
| 17:04 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 17:07 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-62-235-224-54.dsl.scarlet.be) | |
| 18:11 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 18:14 | robb_nl has left IRC (robb_nl!~robb_nl@ip-62-235-224-54.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 18:21 | yanu has left IRC (yanu!~yanu@178-116-57-70.access.telenet.be, Ping timeout: 244 seconds) | |
| 18:23 | yanu has joined IRC (yanu!~yanu@178-116-57-70.access.telenet.be) | |
| 18:41 | forum1 has joined IRC (forum1!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 18:41 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Read error: Connection reset by peer) | |
| 18:41 | forum1 is now known as forum | |
| 18:57 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Remote host closed the connection) | |
| 18:57 | forum has joined IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 19:16 | forum1 has joined IRC (forum1!~Icedove@193-80-182-32.adsl.highway.telekom.at) | |
| 19:16 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Read error: Connection reset by peer) | |
| 19:16 | forum1 is now known as forum | |
| 20:19 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:30 | forum has left IRC (forum!~Icedove@193-80-182-32.adsl.highway.telekom.at, Quit: forum) | |
| 22:44 | adrianorg has left IRC (adrianorg!~adrianorg@177.204.158.221.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds) | |
| 22:45 | adrianorg has joined IRC (adrianorg!~adrianorg@189.114.73.56) | |
| 22:54 | kjackal has left IRC (kjackal!~quassel@ppp-94-65-249-7.home.otenet.gr, Ping timeout: 264 seconds) | |
| 23:15 | url has left IRC (url!~fnurl@36-229-142-205.dynamic-ip.hinet.net, Read error: Connection reset by peer) | |
| 23:28 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 23:54 | GodFather has joined IRC (GodFather!~rcc@68-188-241-8.dhcp.trcy.mi.charter.com) | |