ltsp-developer

[Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Dashamir H. <das...@gm...>]

Hi,

I noticed recently that whatever I install on the ltsp-server
ends up running on the ltsp-clients as well (with chrootless mode).
Actually this is a well-known fact, but I didn't think there was
anything wrong with it, until I realized that apache2, and tomcat,
and mysql were running on the client too, eating up a lot of ram!

As a workaround I changed the order of scripts so that the image
of the ltsp-client is generated as soon as possible, and then we
proceed with the other installations and configurations, with
guacamole, etc.

However this solution has the drawback that afterwards you cannot
install any more packages on the client image (if you need to).
The only way is to rebuild the ltsp-server from scratch, and this takes
a lot of time (about one hour), since lots of things have to be
downloaded and installed (sometimes even compiled from source).

Is it possible to unpack the image of a chrootless client to a directory,
to chroot to this directory and install any additional packages, and
then to pack it back again? This could be much faster than rebuilding
the whole server from scratch (and also more elegant).

Thanks,
Dashamir

Re: [Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Alkis G. <al...@gm...>]

`man lts.conf` and read about RM_SYSTEM_SERVICES there.
The services that are disabled by default on fat clients are listed in:
/usr/share/ltsp/init-ltsp.d/50-rm-system-services

I.e. you just need a line in your lts.conf to prevent all the additional 
services that you installed from running on thin/fat clients.

Alkis

Στις 05/10/2018 11:42 μμ, ο Dashamir Hoxha έγραψε:
> Hi,
> 
> I noticed recently that whatever I install on the ltsp-server
> ends up running on the ltsp-clients as well (with chrootless mode).
> Actually this is a well-known fact, but I didn't think there was
> anything wrong with it, until I realized that apache2, and tomcat,
> and mysql were running on the client too, eating up a lot of ram!
> 
> As a workaround I changed the order of scripts so that the image
> of the ltsp-client is generated as soon as possible, and then we
> proceed with the other installations and configurations, with
> guacamole, etc.
> 
> However this solution has the drawback that afterwards you cannot
> install any more packages on the client image (if you need to).
> The only way is to rebuild the ltsp-server from scratch, and this takes
> a lot of time (about one hour), since lots of things have to be
> downloaded and installed (sometimes even compiled from source).
> 
> Is it possible to unpack the image of a chrootless client to a directory,
> to chroot to this directory and install any additional packages, and
> then to pack it back again? This could be much faster than rebuilding
> the whole server from scratch (and also more elegant).
> 
> Thanks,
> Dashamir

Re: [Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 8:09 AM Alkis Georgopoulos <al...@gm...> wrote:

> `man lts.conf` and read about RM_SYSTEM_SERVICES there.
> The services that are disabled by default on fat clients are listed in:
> /usr/share/ltsp/init-ltsp.d/50-rm-system-services
>
> I.e. you just need a line in your lts.conf to prevent all the additional
> services that you installed from running on thin/fat clients.
>

Thanks Alkis, this should solve the problem.

By the way, `man lts.conf` gives a "No manual entry for lts.conf" error.
I am referring to this page, which may be a bit outdated but should still
be ok:
http://manpages.ubuntu.com/manpages/xenial/man5/lts.conf.5.html

However, I think that this is not a very "clean" solution, since all the
extra
files installed by the extra packages will still go to the client image.
If there was some option like RM_PACKAGES which automatically
removes all the files of the listed packages, this could be better.

But it still does not solve the problem of the software that is compiled
and installed manually. By looking at the code of
`/usr/share/ltsp/ltsp-cleanup`
I get the impression that any scripts listed on `/etc/ltsp/cleanup.d` will
be
called automatically, besides the scripts on `/usr/share/ltsp/cleanup.d`,
if the option `--cleanup` is used. If this is true, then I can create for
example
a script like `/etc/ltsp/cleanup.d/50-guacamole` which removes from the
client everything installed by `guacamole.sh` (including apache, tomcat,
mysql, etc.)

If this works, it would be a cleaner solution. I have to try it.
By the way, I haven't seen this documented somewhere (or maybe I have
missed it, since I don't know all the documentation details).

Another possible solution, which would be "clean" in my opinion, is
to create a chroot directory by taking a snapshot/copy of the root ("/")
directory. Then it can be managed as a chroot client image (chroot to it,
install new packages and software, etc.) Then whatever is installed on
the server after the creation of the chroot directory does affect the
content
of the client image.
Do you think this is a good solution? Can it be achieved with the tools
that are already available, or it needs some improvements?

Regards,
Dashamir

Re: [Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Alkis G. <al...@gm...>]

Στις 06/10/2018 11:40 πμ, ο Dashamir Hoxha έγραψε:
> By the way, `man lts.conf` gives a "No manual entry for lts.conf" error.

apt install ltsp-docs

 > However, I think that this is not a very "clean" solution, since all
 > the extra files installed by the extra packages will still go to the
 > client image.

In chrootless ltsp, the server is a template of the clients.
It's not "your generic apache/php/mysql server that also happens to be a 
template for clients". Because then it's not a template.

> I get the impression that any scripts listed on `/etc/ltsp/cleanup.d` 
> will be called automatically, besides the scripts on `/usr/share/ltsp/cleanup.d`,

Yes you can uninstall packages from there.
/etc is for administrators, /usr is for packages.
I'm not sure what "virtual-ltsp" aims to be.

> Another possible solution, which would be "clean" in my opinion, is
> to create a chroot directory by taking a snapshot/copy of the root ("/")
> directory. Then it can be managed as a chroot client image (chroot to it,
> install new packages and software, etc.) Then whatever is installed on
> the server after the creation of the chroot directory does affect the 
> content

That's just like `cp -a / /opt/ltsp/i386`. There's no need to get a 
specific tool for it. And then it still involves chroots for 
maintenance, which is what chrooted ltsp wants to avoid, as not all 
people like to use console to maintain installations.

Re: [Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 10:56 AM Alkis Georgopoulos <al...@gm...> wrote:

> Στις 06/10/2018 11:40 πμ, ο Dashamir Hoxha έγραψε:
> > By the way, `man lts.conf` gives a "No manual entry for lts.conf" error.
>
> apt install ltsp-docs
>

Sorry, I have missed this.

I am going to test the other proposed solutions and I will let you know.

Thanks,
Dashamir


>
>  > However, I think that this is not a very "clean" solution, since all
>  > the extra files installed by the extra packages will still go to the
>  > client image.
>
> In chrootless ltsp, the server is a template of the clients.
> It's not "your generic apache/php/mysql server that also happens to be a
> template for clients". Because then it's not a template.
>
> > I get the impression that any scripts listed on `/etc/ltsp/cleanup.d`
> > will be called automatically, besides the scripts on
> `/usr/share/ltsp/cleanup.d`,
>
> Yes you can uninstall packages from there.
> /etc is for administrators, /usr is for packages.
> I'm not sure what "virtual-ltsp" aims to be.
>
> > Another possible solution, which would be "clean" in my opinion, is
> > to create a chroot directory by taking a snapshot/copy of the root ("/")
> > directory. Then it can be managed as a chroot client image (chroot to it,
> > install new packages and software, etc.) Then whatever is installed on
> > the server after the creation of the chroot directory does affect the
> > content
>
> That's just like `cp -a / /opt/ltsp/i386`. There's no need to get a
> specific tool for it. And then it still involves chroots for
> maintenance, which is what chrooted ltsp wants to avoid, as not all
> people like to use console to maintain installations.
>
>
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>

Re: [Ltsp-developer] Serious flaw in virtual-ltsp scripts

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 10:56 AM Alkis Georgopoulos <al...@gm...> wrote:

>
> > I get the impression that any scripts listed on `/etc/ltsp/cleanup.d`
> > will be called automatically, besides the scripts on
> `/usr/share/ltsp/cleanup.d`,
>

This works, but at least in my case it is not so clean. I also install
software
by compiling the code, and so it is not easy to clean up everything (just
by removing
packages).

> Another possible solution, which would be "clean" in my opinion, is
> > to create a chroot directory by taking a snapshot/copy of the root ("/")
> > directory. Then it can be managed as a chroot client image (chroot to it,
> > install new packages and software, etc.) Then whatever is installed on
> > the server after the creation of the chroot directory does affect the
> > content
>
> That's just like `cp -a / /opt/ltsp/i386`. There's no need to get a
> specific tool for it. And then it still involves chroots for
> maintenance, which is what chrooted ltsp wants to avoid, as not all
> people like to use console to maintain installations.
>

This command (`cp -a / /opt/ltsp/i386`) somehow did not work for me.
I searched on internet and found this one that works better:
`rsync -a
--exclude={/proc,/dev,/sys,/opt/ltsp,/tmp,/run,/mnt,/media,/lost+found} /
/opt/ltsp/i386`
However when I run `ltsp-update-image --cleanup /opt/ltsp/i386` it fails.
Maybe I am missing something.

So, for the time being I am still keeping the clumsy solution (when
something new
needs to be installed on the client, just rebuild the whole ltsp server).

Regards,
Dashamir

Re: [Ltsp-developer] Suggestion on how to improve the client-building proocess

[Franz D. <die...@te...>]

Hey all,

I truely dislike the idea of having a "forced" same setup for server and
clients - which is why I'm having a chroot setup...
however I do understand, that many teachers would like to install and
maintain graphically.

An alternative approach to the current would be to maintain a qemu-vm of
the client image and package this quemu as bootimage.
So the workflow for the server woud be:
  
    1. install packages (graphically),
    2. launch "manage-client"
    3. get a window with a virtual machine that will then be installed
    4. do all the setup etc.
    5. on shutdown of the vm the image is built/updated

Any thoughts on the feasability, time needed to implement this?

My guess is that this approach would be much cleaner and would require
not too much additional code - though a lot would be needed to change.
I also think it would be less confusing for those who only maintain the
image without deeper linux knowledge.

All the best
Franz (enaut in irc)

Am 05.10.2018 um 22:42 schrieb Dashamir Hoxha:
> Hi,
>
> I noticed recently that whatever I install on the ltsp-server
> ends up running on the ltsp-clients as well (with chrootless mode).
> Actually this is a well-known fact, but I didn't think there was
> anything wrong with it, until I realized that apache2, and tomcat,
> and mysql were running on the client too, eating up a lot of ram!
>
> As a workaround I changed the order of scripts so that the image
> of the ltsp-client is generated as soon as possible, and then we
> proceed with the other installations and configurations, with
> guacamole, etc.
>
> However this solution has the drawback that afterwards you cannot
> install any more packages on the client image (if you need to).
> The only way is to rebuild the ltsp-server from scratch, and this takes
> a lot of time (about one hour), since lots of things have to be
> downloaded and installed (sometimes even compiled from source).
>
> Is it possible to unpack the image of a chrootless client to a directory,
> to chroot to this directory and install any additional packages, and
> then to pack it back again? This could be much faster than rebuilding
> the whole server from scratch (and also more elegant).
>
> Thanks,
> Dashamir
>
>
>
>
>
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net

Re: [Ltsp-developer] Suggestion on how to improve the client-building proocess

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 4:20 PM Franz Dietrich <die...@te...>
wrote:

>
> I truely dislike the idea of having a "forced" same setup for server and
> clients - which is why I'm having a chroot setup...
>

It is not necessarily a "forced" setup. Sometimes all you have is 20 or 30
identical computers and no server. In this case this is the best setup.
I really like the idea of using one of the computers as a "template" for
the others.


> however I do understand, that many teachers would like to install and
> maintain graphically.
>

It is not only this. Sometimes building a chrooted system may be
significantly
more difficult than installing it from a DVD. This is the case for example
with
LinuxMint. I agree that it is not good that you cannot install easily a
chrooted
LinuxMint system, but this is how it is (until LinuxMint improves it).

An alternative approach to the current would be to maintain a qemu-vm of
> the client image and package this quemu as bootimage.
> So the workflow for the server woud be:
>
>     1. install packages (graphically),
>     2. launch "manage-client"
>     3. get a window with a virtual machine that will then be installed
>     4. do all the setup etc.
>     5. on shutdown of the vm the image is built/updated
>

You can do this with VirtualBox as well, but the drawback is that VirtualBox
supports only Intel architectures (i386/amd64). Qemu/KVM maybe is better
since it supports more architectures.

Any thoughts on the feasability, time needed to implement this?
>

I think that it is possible. The time depends on who implements it and how
familiar is with the existing code of ltsp.
One option can be to try it as a GSoC project (or some other kind of
sponsored
project). However, unless you can find a good student, the success of the
project
is not guaranteed.

By the way, what would be a good way for keeping and discussing project
ideas?
I am afraid that we are going to forget about them, if we don't keep them
in a central
place where we can come back and review


> My guess is that this approach would be much cleaner and would require
> not too much additional code - though a lot would be needed to change.
> I also think it would be less confusing for those who only maintain the
> image without deeper linux knowledge.
>
> All the best
> Franz (enaut in irc)
>
> Am 05.10.2018 um 22:42 schrieb Dashamir Hoxha:
> > Hi,
> >
> > I noticed recently that whatever I install on the ltsp-server
> > ends up running on the ltsp-clients as well (with chrootless mode).
> > Actually this is a well-known fact, but I didn't think there was
> > anything wrong with it, until I realized that apache2, and tomcat,
> > and mysql were running on the client too, eating up a lot of ram!
> >
> > As a workaround I changed the order of scripts so that the image
> > of the ltsp-client is generated as soon as possible, and then we
> > proceed with the other installations and configurations, with
> > guacamole, etc.
> >
> > However this solution has the drawback that afterwards you cannot
> > install any more packages on the client image (if you need to).
> > The only way is to rebuild the ltsp-server from scratch, and this takes
> > a lot of time (about one hour), since lots of things have to be
> > downloaded and installed (sometimes even compiled from source).
> >
> > Is it possible to unpack the image of a chrootless client to a directory,
> > to chroot to this directory and install any additional packages, and
> > then to pack it back again? This could be much faster than rebuilding
> > the whole server from scratch (and also more elegant).
> >
> > Thanks,
> > Dashamir
> >
> >
> >
> >
> >
> > _____________________________________________________________________
> > Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
> >       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> > For additional LTSP help,   try #ltsp channel on irc.freenode.net
>
>
>
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>

Re: [Ltsp-developer] Suggestion on how to improve the client-building proocess

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 4:20 PM Franz Dietrich <die...@te...>
wrote:

>
> I also think it would be less confusing for those who only maintain the
> image without deeper linux knowledge.
>

I have another idea:
What if you login on the client as an admin user and then customize it?
This would be very easy and clear for an average Linux user.

I have tried it and `apt update`, `apt install` etc. do work. However these
changes
somehow are not saved on the client image. As soon as you reboot the client
they are lost.

Would it be possible to update the client image from inside a running
client,
so that the customizations that are made to this client are saved on the
image?
Of course this should be allowed only for an admin user (that can use sudo).

Regards,
Dashamir

Re: [Ltsp-developer] Suggestion on how to improve the client-building proocess

[Άλκης Γ. <al...@gm...>]

You can just install a distro in a vm in bridged mode, and use that for the
ltsp server.
I don't see any reason to make things more complicated than that.

Στις Σάβ, 6 Οκτ 2018 - 17:20 ο χρήστης Franz Dietrich <
die...@te...> έγραψε:

> Hey all,
>
> I truely dislike the idea of having a "forced" same setup for server and
> clients - which is why I'm having a chroot setup...
> however I do understand, that many teachers would like to install and
> maintain graphically.
>
> An alternative approach to the current would be to maintain a qemu-vm of
> the client image and package this quemu as bootimage.
> So the workflow for the server woud be:
>
>     1. install packages (graphically),
>     2. launch "manage-client"
>     3. get a window with a virtual machine that will then be installed
>     4. do all the setup etc.
>     5. on shutdown of the vm the image is built/updated
>
> Any thoughts on the feasability, time needed to implement this?
>
> My guess is that this approach would be much cleaner and would require
> not too much additional code - though a lot would be needed to change.
> I also think it would be less confusing for those who only maintain the
> image without deeper linux knowledge.
>
> All the best
> Franz (enaut in irc)
>
> Am 05.10.2018 um 22:42 schrieb Dashamir Hoxha:
> > Hi,
> >
> > I noticed recently that whatever I install on the ltsp-server
> > ends up running on the ltsp-clients as well (with chrootless mode).
> > Actually this is a well-known fact, but I didn't think there was
> > anything wrong with it, until I realized that apache2, and tomcat,
> > and mysql were running on the client too, eating up a lot of ram!
> >
> > As a workaround I changed the order of scripts so that the image
> > of the ltsp-client is generated as soon as possible, and then we
> > proceed with the other installations and configurations, with
> > guacamole, etc.
> >
> > However this solution has the drawback that afterwards you cannot
> > install any more packages on the client image (if you need to).
> > The only way is to rebuild the ltsp-server from scratch, and this takes
> > a lot of time (about one hour), since lots of things have to be
> > downloaded and installed (sometimes even compiled from source).
> >
> > Is it possible to unpack the image of a chrootless client to a directory,
> > to chroot to this directory and install any additional packages, and
> > then to pack it back again? This could be much faster than rebuilding
> > the whole server from scratch (and also more elegant).
> >
> > Thanks,
> > Dashamir
> >
> >
> >
> >
> >
> > _____________________________________________________________________
> > Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
> >       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> > For additional LTSP help,   try #ltsp channel on irc.freenode.net
>
>
>
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>

Re: [Ltsp-developer] Suggestion on how to improve the client-building proocess

[Dashamir H. <das...@gm...>]

On Sat, Oct 6, 2018 at 5:35 PM Άλκης Γεωργόπουλος <al...@gm...> wrote:

> You can just install a distro in a vm in bridged mode, and use that for
> the ltsp server.
> I don't see any reason to make things more complicated than that.
>

Yes, they don't need to be more complicated.
But a few steps are routine and maybe they can be automated, especially for
the people
who are not so familiar with virtual machines. Otherwise, besides the LTSP
concepts
and skills that they have to master, we are also telling them to learn and
master vm
management skills.

Regards,
Dashamir