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


Channel log from 22 October 2017   (all times are UTC)

02:09GodFather 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:27vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
03:35vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
04:18vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:19vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Client Quit)
04:35mmarconm has joined IRC (mmarconm!~mmarconm@200-181-97-129.dial.brasiltelecom.net.br)
04:39Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Quit: No Ping reply in 180 seconds.)
04:41Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack)
04:51mmarconm has left IRC (mmarconm!~mmarconm@200-181-97-129.dial.brasiltelecom.net.br, Quit: Leaving)
07:54Statler has joined IRC (Statler!~Georg@p579FEEDE.dip0.t-ipconnect.de)
08:41ricotz 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:00fzimper has joined IRC (fzimper!4e2b136d@gateway/web/freenode/ip.78.43.19.109)
16:07Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 258 seconds)
16:08Freejack_ has joined IRC (Freejack_!~quassel@unaffiliated/freejack)
16:53gvy 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:03Statler 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:48bennabiy has left IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-abaimukfugftlywn, Ping timeout: 276 seconds)
18:53alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-bacmadvudbmjdyvf, Ping timeout: 276 seconds)
19:39alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-ovjibkbaloednens)
19:55Guest82442 has joined IRC (Guest82442!bennabiyma@gateway/shell/matrix.org/x-otbhlwdpecwzlzti)
21:17ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:18gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: gn)
21:36fzimper has left IRC (fzimper!4e2b136d@gateway/web/freenode/ip.78.43.19.109, Ping timeout: 260 seconds)