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

Request log from specific day:

Channel log from 28 December 2017 (all times are UTC)

00:35	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds)
00:41	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
02:43	alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 264 seconds)
02:48	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:26	lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
05:56	Statler has joined IRC (Statler!~Georg@91.48.234.67)
08:13	Statler_ has joined IRC (Statler_!~Georg@gwrz3.lohn24.de)
08:15	Statler_ has left IRC (Statler_!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
08:15	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:18	Statler_ has joined IRC (Statler_!~Georg@gwrz3.lohn24.de)
08:20	Statler has left IRC (Statler!~Georg@91.48.234.67, Quit: Leaving)
08:21	Statler_ has left IRC (Statler_!~Georg@gwrz3.lohn24.de, Client Quit)
08:21	Statler has joined IRC (Statler!~Georg@gwrz3.lohn24.de)
08:22	Statler_ has joined IRC (Statler_!~Georg@p5B30EA43.dip0.t-ipconnect.de)
08:48	Statler_ has left IRC (Statler_!~Georg@p5B30EA43.dip0.t-ipconnect.de, Remote host closed the connection)
09:32	JerryT has joined IRC (JerryT!~jerry@70.165.106.163)
09:43	JerryT has left IRC (JerryT!~jerry@70.165.106.163, Ping timeout: 260 seconds)
11:12	lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
11:51	traa has joined IRC (traa!293c7574@gateway/web/freenode/ip.41.60.117.116)
11:54	<traa> hie need to install ltsp on linux centos.
11:57	is it possible and can you please help on the procedure need to install ona small lab for a pre-school
12:08	<alkisg> traa: it's best to use ubuntu where it works best and out of the box
12:08	!ltsp-manager
12:08	<ltsp> ltsp-manager: LTSP Manager is a GUI tool that makes LTSP maintenance easy. It's the recommended way to install LTSP in common setups. More info: http://wiki.ltsp.org/wiki/Ltsp-manager
12:08	<alkisg> If you insist on centos, you might be able to get it to work after a few weeks of work...
12:09	The last packages for centos were published many years ago and they won't work anymore, but I think bcg has some new ones, maybe he will publish them somewhere..
12:15	<traa> Thanks @alkisg so l will go for ubuntu for now, and whats the best version of ubuntu to run also of the ltsp.
12:33	gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
12:44	lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Ping timeout: 264 seconds)
12:45	<alkisg> traa: follow the wiki page, it even has a download link for the cd
12:47	<traa> thanks @alkisg. any issues which are prone to be faced on ubuntu installation?
12:48	<alkisg> traa: not really, it's working great
13:05	<traa> thats great thanks @alkisg
13:08	lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
16:00	JerryT has joined IRC (JerryT!~jerry@wsip-70-165-106-163.om.om.cox.net)
16:25	lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
16:33	lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
16:50	lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
16:58	gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
17:33	lucascastro has joined IRC (lucascastro!~lucas@189.89.0.218)
18:56	adrianorg has joined IRC (adrianorg!~adrianorg@201.22.231.132)
18:59	adrianor1 has left IRC (adrianor1!~adrianorg@177.18.102.74, Ping timeout: 252 seconds)
19:13	Tim has joined IRC (Tim!2fb45848@gateway/web/freenode/ip.47.180.88.72)
19:14	<Tim> Hello everyone. I'm curious about the state of the LTSP project. My organization is interested in using it, but don't want to hitch ourselves up to something that isn't active. How's the health of the LTSP project?
19:15	<alkisg> !ltsp-source
19:15	<ltsp> ltsp-source: at https://git.launchpad.net/ltsp/
19:15	<alkisg> See the recent commits there
19:15	'somewhat active' could describe it :)
19:15	lucascastro has left IRC (lucascastro!~lucas@189.89.0.218, Remote host closed the connection)
19:15	<alkisg> One could also use 'mature' :)
19:16	<Tim> Oh good. So the launchpad is the current repo. I was worried because https://www.openhub.net/p/ltsp painted a different picture
19:16	<quinox1> I like the term "mature"
19:16	it's really solid
19:19	<Tim> Now that I know it's mature and active project, how about functionality? One of our needs it to run three monitor thin clients. I see chatter on forums from 13 years ago about dual monitors. Has anyone gotten three monitors to work?
19:19	<quinox1> yes
19:20	I used to run it with 3 monitors just fine
19:20	before the videocard died
19:20	it depends on the hardware, not on LTSP
19:20	<Tim> hardware of the thin client?
19:21	<quinox1> sorry, I did not see you mention thin clients
19:21	It works just fine with fat clients, I have no experience with thin ones
19:22	in general hardware is cheap enough to make everything fat, which usually gives better performance
19:22	you might have good reasons for thin clients, I don't know
19:23	<Tim> We really have no specific requirements. We just figured thin clients would take up less space and since the server will handle the application processing, what need is there for a fat cleint
19:23	So three monitors will work assuming the client (fat or thin) physically supports the three monitors itself?
19:25	<quinox1> it's Linux, so it depends on drivers as well... I ran a triple monitor setup on a card that only supports 2 officially, but the Linux driver was flexible enough to allow me to use the third output as well as long as it ran the same resolution as one of the other 2 outputs
19:26	but yes, a fat client behaves just like any other linux client
19:26	with the advantage that I can manage the installation on 1 spot only
19:27	if I get more developers I buy some hardware, make the machine do PXE boot and it's up and running
19:30	fat clients run as smooth as a locally installed Linux would, thin clients not so much
19:30	it's fine for static output
19:31	but watching youtube on a thin client is not much fun
19:32	you can buy tiny PCs that fit behind a monitor and which are powerful enough for fat clients
19:32	it just needs a motherboard, CPU, RAM and a network card
19:33	(on board NIC, even easier)
19:34	!ltsp-manager
19:34	<ltsp> ltsp-manager: LTSP Manager is a GUI tool that makes LTSP maintenance easy. It's the recommended way to install LTSP in common setups. More info: http://wiki.ltsp.org/wiki/Ltsp-manager
19:34	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
19:35	<quinox1> I suggest just giving it a spin, see if it works for you - the price is right ;)
19:39	<alkisg> Tim: I also added support for multiseat ltsp clients a while back
19:39	So e.g. 2 graphics card can drive 2 different seats with the same client
19:40	In general, whatever you can do with linux, you can do with ltsp as well, give or take some effort
19:46	<Tim> good to hear! Thanks for all the great info. It sounds like a small form factor fat client is the right thing for us. I dont want performance to be an issue anywhere. We watch videos an do a lot of IT related work so I don't want there to be a bottleneck anywhere
19:47	<vagrantc> ltsp fat clients have very little difference in performance that running on a disk locally ... in some cases even faster
19:47	main difference is availability of swap space
19:47	although you can technically set up swap on local media as well
19:52	<Tim> what do you mean running on a disk locally?
19:53	doesnt the ltsp client run on the local disk of the client machine always?
19:53	<vagrantc> instead of using LTSP, installing the OS on a disk on the machine
19:53	typicall, with LTSP, the only disk is on the server
19:54	LTSP is primarily about network booted computers
19:54	<Tim> oh, i thought the latter was how you always did it. so there's a way to boot to LTSP on the client?
19:55	<vagrantc> most modern hardware can boot from the network
19:55	no disk on the client
19:55	<Tim> oh wow cool!
19:56	<vagrantc> indeed! one less part to fail, no local state on the client, trivial to replace a failed client, etc.
19:56	<Tim> Hmm that raises some questions in my intended setup though
19:56	<vagrantc> though clever people like alkisg have innovated and installed LTSP to disk in some circumstances :)
19:57	<Tim> So we have multiple teams that work on different projects. We intended to setup an environment for each project that a team can remote into (or boot to).
19:57	The reason being is that each project will have it's own software needs and setup. so we want to keep projects clean and separated.
19:58	and multiple teams should be able to remote into that project's environment to utilize the software and setup of that environment
19:58	<vagrantc> you can have a boot menu, and select at boot time, or if particular clients need to boot in a particular way, you can configure the default for each client differently
19:58	<Tim> oh excellent, so at boot, they can select which environment to boot into?
19:58	<vagrantc> but "remote into" is a bit complicated
19:59	its possible to set up, sure
19:59	you get into some issues with managing multiple images, then
19:59	<Tim> ya sorry, my terminology may be messing us up here. boot it probbaly the best route
19:59	ya im fine managing multiple images. That's my Ops team's problem haha
20:00	<vagrantc> depending on what the different environments are, you might be able to use virtual machines or chroots or something
20:00	or containers, etc.
20:01	<Tim> The requirements for different environments arent that much different. They'll have the same base software like email client, Eclipse, etc. but some may need to install Python, while others need Java for code development.
20:01	Would you recommend virtual machines for that? or is there a simpler and cleaner route?
20:01	<vagrantc> the simplest route is to just build your server to be the way you want your development environment, and then build an LTSP image out of that
20:02	Tim: chroots might work; it really depends
20:02	<Tim> hmm building it after we setup the environment is a problem though. If they need to install new software, we want that new software to be available to any other team on that same project.
20:02	<vagrantc> Tim: there are a lot of variables ...
20:03	Tim: with LTSP, when you rebuild the image, everyone who needs the updated image just reboots
20:04	Tim: i missed some of the earlier context, not sure what exactly you're trying to do :)
20:04	<Tim> but it would require rebuilding the image? is that an automatic thing? or does an Ops person have to trigger a rebuild after they installed the software?
20:04	yanu has left IRC (yanu!~yanu@178-116-60-189.access.telenet.be, Ping timeout: 248 seconds)
20:05	<vagrantc> whatever process you have to install software would also need to rebuild the image, yes
20:05	<Tim> vagrantc: To summarize, we have multiple projects and multiple teams that can be on any of those projects. I want to support one environment per project that multiple teams can boot into to utilize the software for that project.
20:05	<vagrantc> Tim: is it so wrong to have both javaj and python in both environments? or are some things mutually incompatible?
20:05	<Tim> well we dont really have a process. It would be up to the teams to install what they need
20:06	It's not a compatability thing. It's about not knowing what we will need. We have many projects and can't predict what software they will need on a day to day basis.
20:06	<vagrantc> if you really want clean environments, your processes should use chroots, containers, or VMs for each program build ...
20:07	it shouldn't rely on the development environment's set of installed software, you should build the environment as part of the development process
20:09	but that's well outside the scope of LTSP :)
20:10	Statler has left IRC (Statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
20:13	<Tim> Right, I'm just trying to figure out how this all plays together
20:13	I'll look into chroots
20:13	<alkisg> Tim: how many clients (computers) per different image?
20:13	<Tim> thanks for the help!
20:13	1 most of the time. some projects have 2-3
20:13	<alkisg> Then ltsp isn't appropriate
20:13	You want normal installations
20:14	ltsp is about maintaining one installation that serves many clients
20:14	To ease administration
20:14	there's not really a point in configuring an image for a single client
20:14	* vagrantc notes, as usual, alkisg cuts to the heat of the matter :)
20:14	<Tim> We want to have the ability to spin up multiple clients on a single project though
20:15	<vagrantc> er, heart
20:15	<Tim> We wont always have 1 team per project
20:15	If one of our projects has a burst of resource need, we want to be able to shift teams to that project easily and tackle the workload
20:16	yanu has joined IRC (yanu!~yanu@178-116-60-189.access.telenet.be)
20:16	<vagrantc> ltsp might work for that, although just using some sort of configuration management tool on disked installs might make about as much sense
20:16	<alkisg> How many computers in total?
20:16	(clients)
20:17	<Tim> 12
20:17	and about 5-6 different projects
20:17	<alkisg> Maintaining 10 images for 12 clients sounds harder than just cloning an installation whenever you need it
20:17	<vagrantc> or having a virtual machine that you can log into remotely
20:18	(for each project)
20:19	traa has left IRC (traa!293c7574@gateway/web/freenode/ip.41.60.117.116, Ping timeout: 260 seconds)
20:19	<Tim> So you would recommend just running containers for each project and setup a VNC server for client access to that environment?
20:20	* vagrantc shrugs
20:21	<Tim> Maybe that's not the final solution, but that would be a better solution that using LTSP?
20:21	<vagrantc> using LTSP for this purpose sounds like it could be more complicated than it's worth, yes
20:22	<Tim> ok
20:22	<vagrantc> if it were maybe 2 different environments for 12 computers, that would be one thing...
20:22	althoug i still wonder if you couldn't use the same environment for all of them
20:23	if you were using one development environment for all the projects, then LTSP would make a lot of sense
20:24	<Tim> hmm ok let me talk with my team.
20:41	<\|\|cw> or use user based env switching, like nvm does for node
20:42	<alkisg> Tim: if you'll go into the additional overhead of VMs, then you can use ltsp to netboot them
20:42	LTSP can easily give you "roaming" VMs
20:42	The easiest setup would be normal installations with the occasional installation of one more program or a cloning
20:43	If you want VMs and roaming stuff etc, then sure ltsp can help
20:47	(note that when people temporarily join another team, it may be easier to install those new programs rather than migrate the user profile with all his settings etc)
21:24	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
21:35	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
22:04	<quinox1> it's not related to LTSP at all, but I have a repo for our company called company-tooling; it has 1 file called `empower.sh` which sets a bunch of envvars with paths inside the repo (e.g., PATH="${repo}/bin:$PATH" PYTHONPATH="${repo}/python/libs:$PYTHONPATH")
22:04	which sets up most of the dependencies any dev requires
22:05	then there's 1 script called `is-my-machine-suitable-for-development.py` which checks the status of MySQL / postgres / anything you'd want the package manager to use for (is it installed, is it running, does the config contain option X)
22:06	if it sees postgres isn't installed it will show `please run "sudo apt-get install postgresql"` etc, commands a user can copy/paste to fix it
22:07	using this new devs can setup their laptop for work within a few minutes
22:08	works like a charm
22:10	if you run `source ~/projects/company-tooling/empower.sh` (which everybody has aliased as `e` it will run `git pull` automatically if it sees it hasn't been run in the last 24 hours
22:10	so all the devs are always up to date without any manual steps
22:13	I even use it from our CI (Jenkins); I don't have to do any manual dependency installation on that host this way
22:17	using Docker or VMs (Vagrant?) might also be a way to go
22:20	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:21	<quinox1> getting people to use these tools might require some ... attention ... if there's only 1 dev on a specific project
22:21	it's all too tempting to "just do it by hand for once"
22:22	I've found setting up CI is useful to get rid of manual steps
22:23	I give devs full power over the CI setup, but they get no access on the CI host itself; if they want their project to build successfully they cannot get away with manual steps :-)
22:26	<vagrantc> smart
23:19	<Tim> Is there anyway for software to be persisted to an environment without having to rebuild it?
23:20	We're doing a POC of LTSP and we're concerned about building the image which seems to come after the environment setup stage where we would install any necessary software
23:20	We want to give the ability to our team members to install an application and its available to anyone that boots to that environment without having to rebuild the whole thing. Or is that just not how LTSP works?
23:45	<vagrantc> there are tons of ways you could do that, none of them have anything to do with LTSP
23:46	i can think of some ways you could do that sort of thing with LTSP, but it would require a bit of development, and it sounds like your use-case wouldn't be worth it
23:46	<Tim> Ok that's what I was wondering. LTSP isn't the solution for us then. Bummer, it's a really cool project!
23:46	and its the closest thing we've found to a right-fit solution
23:47	VNC is a no-go because of the incrementing port and use management.
23:47	<vagrantc> i guess i still really don't understand your use-case
23:50	<Tim> Let's see if I can explain it better. We have teams of people that come in each day and work against a specific client. They use web browsers, API testing tools, IDEs, programming languages, etc. to perform their tasks. Each of our clients is different thus requiring different applications to work on that client.
23:51	Instead of having a bunch of laptops for each team member out with varying sets of software, we wanted to setup a single server that has all the software needed to work for a particular client. Any team member working for that client would boot to that environment and have access to all the software needed to work on that client
23:52	<vagrantc> and you can't mix environments?
23:53	<Tim> The main problem I see with LTSP is the fact that if one team member needs to install a new application like Eclipse IDE that isnt already a part of the installed set of applications, they would lose it once they log out and boot back in.
23:53	We'd like not to, across all of our clients, it's a lot of software
23:53	We could if we had to, but that's not the problem.
23:53	it's the installation of new software
23:54	<vagrantc> well, if you could just install all the stuff you want in all the images, LTSP would work fine
23:54	<Tim> Right, but the part about not know what is needed is what gets us
23:55	<vagrantc> so you need your developers able to install software, potentially any software
23:55	<Tim> right. How do updates work in LTSP when new software needs to be installed?
23:56	and not just install it, but that installed software sticks from then on, and is available to everyone
23:56	<vagrantc> you install it on the server and or chroot on the server, regenerate the image, and reboot the needed clients
23:57	<Tim> That's ok from an operations perspective but would you expect our team members to do that?
23:57	<vagrantc> with NFS, you wouldn't need to reboot the clients... but that hasn't been very reliable recently
23:57	i don't know how you expect your team members to install software at all
23:57	so i don't know what you "can't" do
23:58	<Tim> well with a regular ubuntu environment, they would just do an apt-get install of whatever they need, but that's on the running instance they've booted to
23:59	you make it sound like they would have to remote into the main server, install software, and build the image. Sounds complicated for an end-user outside of the operations team
23:59	is my understanding correct?
23:59	<vagrantc> ssh $server apt-get install foo && ssh $server ltsp-update-image