IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 22 October 2017 (all times are UTC)
| 02:09 | GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Ping timeout: 260 seconds) | |
| 02:44 | <gehidore> nothing like a 5 year old attacking
| |
| 03:11 | <bennabiy> I understand that one
| |
| 03:27 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 03:35 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds) | |
| 04:18 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 04:19 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Client Quit) | |
| 04:35 | mmarconm has joined IRC (mmarconm!~mmarconm@200-181-97-129.dial.brasiltelecom.net.br) | |
| 04:39 | Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Quit: No Ping reply in 180 seconds.) | |
| 04:41 | Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack) | |
| 04:51 | mmarconm has left IRC (mmarconm!~mmarconm@200-181-97-129.dial.brasiltelecom.net.br, Quit: Leaving) | |
| 07:54 | Statler has joined IRC (Statler!~Georg@p579FEEDE.dip0.t-ipconnect.de) | |
| 08:41 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 13:19 | <bennabiy> alkisg: so, if I set up a "proxy" ltsp-pnp client to generate images from, how do I make sure that the resultant clients actually point to the right server?
| |
| 13:20 | ltsp-manager with a chroot.... so that would end up pointing to the right server IP, but how do I get it to have the right certificates?
| |
| 16:00 | fzimper has joined IRC (fzimper!4e2b136d@gateway/web/freenode/ip.78.43.19.109) | |
| 16:07 | Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 258 seconds) | |
| 16:08 | Freejack_ has joined IRC (Freejack_!~quassel@unaffiliated/freejack) | |
| 16:53 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 17:23 | <alkisg> bennabiy: which of those 2 methods are you asking for?
| |
| 17:24 | The chroot one is the same as the one you're using; ltsp-manager just takes care of configuring dhcp, dns, shared folders etc
| |
| 17:24 | So you just run ltsp-build-client, nothing new
| |
| 17:25 | <bennabiy> I am more thinking of how to make the same environment, but just have i386 instead
| |
| 17:25 | or similar environment
| |
| 17:27 | I was intrigued by the idea of using a version control environment to generate i386 chroots from, but still have the server be 64
| |
| 17:27 | especially since making a fat client image seems a bit cumbersome without the pnp method
| |
| 17:27 | does that make sensE?
| |
| 17:27 | alkisg: ^
| |
| 17:28 | alkisg: I was wanting more info on a template client
| |
| 17:29 | and mixed selection of thin and fat clients
| |
| 17:42 | <alkisg> bennabiy: well, the template client could work like this:
| |
| 17:43 | you install ltsp-manager on a i386 machine, and you manage/build the image using the ltsp-pnp style
| |
| 17:43 | you also install ltsp-manager/ltsp-pnp on the amd64 server
| |
| 17:43 | So basically you maintain 2 ltsp-pnp servers, one for each arch
| |
| 17:44 | Then you can of course transfer the image from the i386 template client to the amd64 server, but:
| |
| 17:44 | since the client has gigabit card, you can let it host the nbd image, which also doubles your network bandwidth
| |
| 17:45 | So the i386 clients would boot from the i386 ltsp-pnp server, the amd64 clients would boot from the amd64 ltsp-pnp server, and ALL clients would use LDM_SERVER=amd64-server, so as to have all user accounts, /home etc in one location
| |
| 17:45 | To sum up, the benefits in this is that you use a GUI to maintain the images, and that you have double bandwidth
| |
| 17:46 | <bennabiy> hmm, I am almost following you. doubles because the traffic for remoteapps on fat clients and for user directories and such would be coming from a different machine as the client image ?
| |
| 17:46 | <alkisg> Because of the traffic to the i386 nbd image would go to a separate server
| |
| 17:46 | <bennabiy> LDM_SERVER is set in lts.conf?
| |
| 17:46 | <alkisg> Yes
| |
| 17:47 | <bennabiy> so I would maintain 2 lts.conf, one for each of the tftp roots, correct?
| |
| 17:47 | <alkisg> It's possible to use a single tftp for lts.conf if you want, but it's easier to maintain 2 lts.conf, yes
| |
| 17:47 | <bennabiy> What is the best way to have each client boot the right image? menu?
| |
| 17:47 | <alkisg> Personally though I would put 2 NICs on my server and just use an i386 virtualbox VM
| |
| 17:48 | <bennabiy> defaulting to 386?
| |
| 17:48 | I use 2 nics
| |
| 17:48 | <alkisg> There's ifcpu64 which can select between amd64 and i386
| |
| 17:48 | I prefer 2 nics in bonded mode for speed
| |
| 17:48 | Not for separation of clients/internet
| |
| 17:48 | I.e. not in the classic ltsp sense, but for speed
| |
| 17:48 | <bennabiy> I have not switched to dnsmasq yet... I still do it isc style
| |
| 17:49 | <alkisg> That's one of the benefits of ltsp-pnp, that it automatically configures dnsmasq
| |
| 17:49 | It even does the NAT masquerade when needed
| |
| 17:49 | <bennabiy> but needs to be set to .67.0 network, correct?
| |
| 17:49 | <alkisg> "needs", well, that's where it's automatic
| |
| 17:49 | If you want to configure it elsewhere, it's just 1 line
| |
| 17:51 | <bennabiy> ltsp-manager is appealing to me for the sake of other labs which might not be as technical as we are here, to be able to easily roll out a lab in a location. I personally do not find it hard to get a lab up and running, and have no qualms with the old way of doing it, unless there are benefits which I am missing. I do like the thought of having a bit more speed on the network, and am working on getting fat clients over thin,
| |
| 17:51 | but I know some of my clients just need thin clients, so I need a mixed environment
| |
| 17:52 | I do have even a second server which is i386 only, which would be a fine template machine
| |
| 17:52 | <alkisg> There's just no reason to use the old setup
| |
| 17:52 | Beginners can use ltsp-manager from a gui
| |
| 17:52 | Advanced users can use ltsp-manager and do a small additional setup
| |
| 17:52 | No reason to use the old setup...
| |
| 17:52 | <bennabiy> honestly, it scares me somewhat to try it the new way ... when I know the old works
| |
| 17:53 | <alkisg> And easier to support users then, and troubleshoot issues in one set of tools, not many sets of tools
| |
| 17:53 | <bennabiy> because I have people who count on this lab, and I know how to fix it if it is broken this way, but I am not opposed to trying it out
| |
| 17:53 | <alkisg> The old way has issues that no ltsp dev troubleshoots nowadays though
| |
| 17:53 | <bennabiy> I would just need to really test it
| |
| 17:53 | <alkisg> E.g. tftpd-hpa doesn't start at boot => who cares
| |
| 17:53 | dnsmasq doesn't start at boot => ltsp-manager automatically fixes that
| |
| 17:54 | <bennabiy> I guess dnsmasq is something I need to get aquainted with
| |
| 17:54 | acquainted I mean
| |
| 17:54 | <alkisg> dnsmasq also has a .dir for configuration files, so it's easier for scripting, as opposed to isc-dhcp and tftpd-hjpa
| |
| 17:55 | And the most significant is that it supports proxydhcp, which isc-dhcp doesn't, so many users just can't use isc-dhcp
| |
| 17:55 | That's the main reason we no longer want to default to isc-dhcp
| |
| 17:55 | <bennabiy> I have been setting up LTSP labs since about 2011, so it is hard for me to think differently. I hear you though
| |
| 17:55 | <alkisg> No worries, whatever works for you
| |
| 17:55 | <bennabiy> I guess most people do not have as much control over their environment as we do here
| |
| 17:56 | <alkisg> I'm just mentioning what the ltsp devs trend is
| |
| 17:56 | Sysadmins can divert as much as they like, as long as they can troubleshoot the issues that may arise
| |
| 17:56 | <bennabiy> alkisg: I don't want you to think that I do not appreciate it... I needed a little prodding to get me to try it a different way. I am going to see if I can get it working
| |
| 17:57 | So, by default with ltsp-pnp, the clients would be fat, correct?
| |
| 17:57 | <alkisg> I understand fine, no worries, it's not like isc-dhcp is unsupported or anything
| |
| 17:57 | No
| |
| 17:57 | With ltsp-pnp, the same as with plain ltsp, the clients are fat when ram > 500 and a desktop is installed, thin otherwise
| |
| 17:58 | <bennabiy> But if you are generating from a server, then a desktop is installed, correct?
| |
| 17:58 | <alkisg> And of course it's configurable , both the FAT_RAM_THRESHOLD=500 and the LTSP_FATCLIENT=True/False
| |
| 17:58 | Correct
| |
| 17:58 | <bennabiy> I mean generating from a desktop environment
| |
| 17:58 | <alkisg> Correct, unless you have a server installation
| |
| 17:59 | <bennabiy> So if someone is using a GUI to configure LTSP, then by default, if they have more than X ram, they get a fat client
| |
| 17:59 | <alkisg> Right
| |
| 17:59 | Not GUI, just "ltsp-update-image -c /"
| |
| 17:59 | Either from gui or from the console
| |
| 17:59 | It's one of the parts that make ltsp-pnp
| |
| 17:59 | <bennabiy> Is there any support for live updating the nbd image while clients are running"
| |
| 17:59 | ?
| |
| 18:00 | I know, I am just thinking about ltsp-manager, not just pnp
| |
| 18:00 | <alkisg> It's not specific to ltsp-pnp, but to any ltsp using nbd
| |
| 18:00 | When you run ltsp-update-image, it creates a new image, and the clients will use it on next boot
| |
| 18:00 | <bennabiy> yes
| |
| 18:00 | <alkisg> Clients that are already booted will continue using the old image even if you delete it
| |
| 18:00 | So everything works ideally
| |
| 18:00 | <bennabiy> until their memory is exhausted
| |
| 18:01 | <alkisg> Why would their memory be exhausted?
| |
| 18:01 | <bennabiy> nbd-server keeps a cached image in memory of the image it serves them, even if the source is deleted, correct?
| |
| 18:01 | <alkisg> You can have a 50 GB image running on a 500 MB RAM fat client
| |
| 18:01 | No
| |
| 18:01 | <bennabiy> if someone takes a long time to reboot and does updates and such on the client
| |
| 18:01 | <alkisg> nbd-server keeps a handle to the open file
| |
| 18:02 | So when you delete it from disk, linux doesn't actually delete it
| |
| 18:02 | And nbd-server accesses it normally from disk, using its handle, without wasting RAM
| |
| 18:02 | <bennabiy> it keeps the inode until no more references, correct?
| |
| 18:02 | <alkisg> Right
| |
| 18:02 | So it's not a matter of server RAM, and not a matter of client RAM. Only of server disk space.
| |
| 18:03 | <bennabiy> I was thinking of the client using up RAM by installing updates and such on the client without reboots
| |
| 18:03 | slowly it eats up available ram
| |
| 18:03 | Statler has left IRC (Statler!~Georg@p579FEEDE.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 18:03 | <alkisg> Updates are disabled on fat clients
| |
| 18:03 | <bennabiy> ah
| |
| 18:03 | <alkisg> RM_SYSTEM_SERVICES takes care of that
| |
| 18:03 | <bennabiy> good to know
| |
| 18:03 | <alkisg> It also disables nbd-server, dnsmasq etc
| |
| 18:04 | <bennabiy> what about the case where my root filesystem on my server is ZFS?
| |
| 18:04 | <alkisg> Ah, here's another example, if you use ltsp-pnp with isc-dhcp server, you'll get isc-dhcp server running on the clients, because noone cared to exclude it
| |
| 18:04 | That's where using the defaults (dnsmasq) can help again
| |
| 18:04 | <bennabiy> heh, yes, I saw that
| |
| 18:04 | <alkisg> LTSP doesn't care about server file systems
| |
| 18:04 | If your distro supports it, all is fine
| |
| 18:05 | <bennabiy> Would the client have the zfs modules though?
| |
| 18:05 | <gvy> doesn't have to
| |
| 18:05 | <alkisg> The client will access the system using nbd/squashfs
| |
| 18:05 | /etc/fstab is regenerated on boot
| |
| 18:05 | Now if you manually load zfs, sure, it'll load on the client too, and do... nothing?
| |
| 18:06 | The nbd image is always using the squashfs format, it doesn't care about ext4/zfs/whatever
| |
| 18:06 | * alkisg needs to go afk for a while, see you guys later! :) | |
| 18:07 | <bennabiy> thank you
| |
| 18:07 | alkisg: one quick thing
| |
| 18:07 | <alkisg> yup?
| |
| 18:08 | <bennabiy> if I do two servers for generating images, would the second server need to have a /etc/hosts entry for server pointing to the 64 bit machine for the sake of epoptes?
| |
| 18:08 | and have epoptes-client installed?
| |
| 18:08 | <alkisg> It only needs epoptes-client
| |
| 18:08 | <bennabiy> so the clients grab the right server keys?
| |
| 18:08 | <alkisg> And, /etc/default/epoptes-client specifying SERVER=$LDM_SERVER
| |
| 18:08 | <bennabiy> ah, ok
| |
| 18:08 | thank you!
| |
| 18:08 | <alkisg> np :)
| |
| 18:09 | <bennabiy> would I need to run -c on the server?
| |
| 18:09 | or just having it installed is good enough?
| |
| 18:09 | ( you can answer later if needed)
| |
| 18:17 | <alkisg> Yes after installing epoptes-client anywhere, you need to run epoptes-client -c server to fetch the certificate
| |
| 18:20 | <bennabiy> after the edit to /etc/default/epoptes-client though, correct?
| |
| 18:22 | <alkisg> Either run "epoptes-client -c server" at any time, or run "epoptes-client -c" after you edit the file
| |
| 18:22 | In other words, if you edit the file first, you don't _need_ to specify the server in the epoptes-client -c command
| |
| 18:23 | <bennabiy> got it
| |
| 18:24 | Hope that didn't keep you from what you needed to do?
| |
| 18:48 | bennabiy has left IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-abaimukfugftlywn, Ping timeout: 276 seconds) | |
| 18:53 | alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-bacmadvudbmjdyvf, Ping timeout: 276 seconds) | |
| 19:39 | alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-ovjibkbaloednens) | |
| 19:55 | Guest82442 has joined IRC (Guest82442!bennabiyma@gateway/shell/matrix.org/x-otbhlwdpecwzlzti) | |
| 21:17 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:18 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: gn) | |
| 21:36 | fzimper has left IRC (fzimper!4e2b136d@gateway/web/freenode/ip.78.43.19.109, Ping timeout: 260 seconds) | |