ltsp-developer — Discussion list for developers working on the Linux Terminal Server Project

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] 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

[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

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

[Άλκης Γ. <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

[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] 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

[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 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...>]

`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

[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] Creating an Account on the wiki fails with 500 Error

[James M. <ja...@lt...>]

Franz,
Please try it again.  I've fixed the problem that was causing the error.

Jim.

On Wed, Sep 26, 2018 at 2:47 AM Franz Dietrich <die...@te...>
wrote:

> Hello guys,
>
> I recently tried to create an account on the wiki.ltsp.org but after
> entering everything I get a blank white page. In the developers console
> of Firefox I see that the response to the post request is a 500 error
> but no additional information. Someone else on IRC mentioned to have the
> same Problems.
>
> I hope someone here can fix this issue.
>
> All the best
> Franz Dietrich
>
>
> _____________________________________________________________________
> 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] Creating an Account on the wiki fails with 500 Error

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

Hello guys,

I recently tried to create an account on the wiki.ltsp.org but after
entering everything I get a blank white page. In the developers console
of Firefox I see that the response to the post request is a 500 error
but no additional information. Someone else on IRC mentioned to have the
same Problems.

I hope someone here can fix this issue.

All the best
Franz Dietrich

[Ltsp-developer] Race condition workaround

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

Hi,

The bug reported here seems to have been fixed:
- https://github.com/NetworkBlockDevice/nbd/issues/59

Is it safe to remove this workaround:
-
https://gitlab.com/Virtual-LTSP/VirtualBox/blob/bionic/ltsp-server/scripts/lts-conf.sh#L29

Another problem that I have encountered is that the variable
HOST_TO_USERNAME on 'lts.conf' seems not to work as expected:

# Map HOSTNAMEs to LDM_USERNAMEs. E.g. for HOSTNAME=pc01,
LDM_USERNAME=guest01.
#HOST_TO_USERNAME="pc/guest"

Where is the bug/issue tracking system of ltsp, so that I can report a bug?

Thanks,
Dashamir

[Ltsp-developer] Standalone

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

Hi,

In my guide and in my scripts I install the package 'ltsp-server' and not
the package 'ltsp-server-standalone':
- http://dashohoxha.fs.al/ltsp-pnp/#sec-3-1
-
https://gitlab.com/Virtual-LTSP/VirtualBox/blob/bionic/ltsp-server/install.sh#L22
I don't know why I decided to stick with this one but it works in all the
cases
that I have tried (only the chrootless cases on Ubuntu).

On the other hand, the rest of the guides recommend installing
'ltsp-server-standalone' in all the cases, for example this one:
- http://wiki.ltsp.org/wiki/Installation/Ubuntu

I never understood properly the difference between these two packages.
What am I missing by installing 'ltsp-server' instead of
'ltsp-server-standalone'?

Initially I assumed that 'standalone' means a LTSP server that also gives
DHCP service and is also a gateway of the LAN to internet (the so called
2-NIC configuration). So, I was using in my scripts a variable named
STANDALONE in order to distinguish between this case and the other
one (1-NIC configuration). However I realized that this may be a bit
confusing, since this word is used by the packages as well, but with
a different meaning. So I changed the variable name from STANDALONE
to GATEWAY (if "yes", it means that the LTSP server is also a gateway
and DHCP server):
-
https://gitlab.com/Virtual-LTSP/VirtualBox/commit/32176251900e062545d767f0d00cb6a180cbe8ef

By the way, I think that the terminology 1-NIC / 2-NIC is a bit technical
and not quite accurate, since a computer that has 2 network cards cannot
be used as a DHCP server and gateway if there is already another DHCP
server on the LAN. Also, a laptop user may not even know what is a NIC.

Regards,
Dashamir

[Ltsp-developer] Guest accounts

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

Hi,

I have created guest accounts according to the instructions on these
postings:
- https://sourceforge.net/p/ltsp/mailman/message/27814821/
- https://sourceforge.net/p/ltsp/mailman/message/31967324/
- http://www.m-opensolutions.com/?p=667
- http://www.m-opensolutions.com/?p=537

I have also created a skeleton guest account that can be used
to customize the guest accounts. The scripts are here:
-
https://gitlab.com/Virtual-LTSP/VirtualBox/blob/bionic/ltsp-server/scripts/create-guest-accounts.sh
-
https://gitlab.com/Virtual-LTSP/VirtualBox/commit/c80a10ba3d32858807a8d8aabbcb0e6980b9543c

Hpwever, creating 255 guest accounts seems a bit clumsy to me.
If there is any simpler or smarter solution that I have missed, please
let me know. Any other suggestion is welcome as well.

Regards,
Dashamir

[Ltsp-developer] Bountysource.com LTSP campaign

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

Hi all,

in the last years, I've been doing most of the LTSP development and 
maintenance, while funded by the Greek ministry of education.
That funding has stopped in 2015 and it doesn't look like it's coming 
back any time soon.

Disklessworkstations, Canonical, Revolution Linux etc had funded LTSP 
development in the past, but currently there are no companies supporting 
its development.

So I'm thinking of creating a bountysource.com campaign page for LTSP, 
where developers can earn a monthly salary for working on LTSP 
(salt.bountysource.com), while special bounties can be opened for big 
features like LTSP 6.

Is anyone opposed to that?
If not, I'll open the project page next weekend.

Cheers,
Alkis

Re: [Ltsp-developer] LTSP BTS during debconf17?

[James M. <ja...@mc...>]

Oh how i'd love to be there in Montreal with you guys.

Unfortunately i'm going through a certification process for our software
and we'll be deep in prep work at that time.

As for Scotty, while Montreal and Winnipeg are in the same country, it's
still about 1400 miles for him so not exactly close.
But... I'll be talking to him in the next few days.  I'll mention it to him
in case he hasn't seen this email chain.

We are still planning on being in our usual spot in Maine from Oct 14th to
the 21st.
Everybody is welcome to join us for any part of that week.

Jim.


On Fri, Jun 30, 2017 at 11:10 AM, Stéphane Graber <stg...@ub...>
wrote:

> On Fri, Jun 30, 2017 at 09:21:00AM +0300, Alkis Georgopoulos wrote:
> > debconf17 will take place in Montreal from 2017-07-31 to 2017-08-13.
> > Me and Vagrant will be there, and an intern working on a new project
> > called "ltsp-manager". And we might do an LTSP sprint around that.
> >
> > Also AFAIK Scotty isn't very far... Maybe it would make sense to arrange
> > for an LTSP BTS during that time?
> >
> > Cheers,
> > Alkis
>
> I'd probably show up, since the Debconf venue is a whole 20min walking
> distance from here :)
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _____________________________________________________________________
> 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] LTSP BTS during debconf17?

[Stéphane G. <stg...@ub...>]

On Fri, Jun 30, 2017 at 09:21:00AM +0300, Alkis Georgopoulos wrote:
> debconf17 will take place in Montreal from 2017-07-31 to 2017-08-13.
> Me and Vagrant will be there, and an intern working on a new project
> called "ltsp-manager". And we might do an LTSP sprint around that.
> 
> Also AFAIK Scotty isn't very far... Maybe it would make sense to arrange
> for an LTSP BTS during that time?
> 
> Cheers,
> Alkis

I'd probably show up, since the Debconf venue is a whole 20min walking
distance from here :)

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

[Ltsp-developer] LTSP BTS during debconf17?

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

debconf17 will take place in Montreal from 2017-07-31 to 2017-08-13.
Me and Vagrant will be there, and an intern working on a new project
called "ltsp-manager". And we might do an LTSP sprint around that.

Also AFAIK Scotty isn't very far... Maybe it would make sense to arrange
for an LTSP BTS during that time?

Cheers,
Alkis

[Ltsp-developer] Moving ldm and ltspfs into separate projects

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

There was some misconfiguration in the past, and ldm/ltspfs have been
declared as "Series" of ltsp, instead of separate projects:
https://launchpad.net/ltsp

"Series" in launchpad means that we would e.g. separately maintain ltsp
5.x from ltsp 4.x. It's clearly not the correct way to configure ldm and
ltspfs in launchpad.

Instead, ldm should live as its own project at
https://launchpad.net/ldm, and possibly have its own bug tracker at
https://bugs.launchpad.net/ldm and translations at
https://translations.launchpad.net/ldm. Same for ltspfs.

I asked at #launchpad and they confirmed that it's possible to move ldm
into a separate project without losing the internal launchpad
translations memory, so the move shouldn't cause any big issues.
One issue that will be cause, is that the VCS-Browse etc fields of
packages should be updated; but since we moved to git, those should get
updated anyway, i.e. they're broken currently.

Shall I go on and move them to separate projects?

It's also possible to declare a "project group" if we want them to
appear as "subprojects of ltsp", but it's not very significant.


Cheers,
Alkis

Re: [Ltsp-developer] Switching to git

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

On 16/05/2017 10:36 μμ, Vagrant Cascadian wrote:
> Hey folks, just wanted to let you know we've switched the LTSP bzr
> repositories over to git, still hosted on launchpad:
>
>   https://code.launchpad.net/ltsp/


Since we won't be using bzr any longer, I marked about 70 branches as 
abandoned, in https://code.launchpad.net/ltsp/+branches; their 
developers should have gotten notification mails about that.

Of course they're not deleted, they just don't show up in the default list.

I only left 25 branches there, that belong to developers that have been 
active in recent years; please mark those as abandoned yourselves. :)

Merge requests in the future should be in git format, and should show up 
in https://code.launchpad.net/ltsp/+git

Cheers,
Alkis

[Ltsp-developer] Switching to git

[Vagrant C. <va...@de...>]

Hey folks, just wanted to let you know we've switched the LTSP bzr
repositories over to git, still hosted on launchpad:

  https://code.launchpad.net/ltsp/

Anyone in the ltsp-upstream launchpad group should still be able to
commit.


Browseable interface for each project:

  https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltsp
  https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ldm
  https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltspfs


I'm hoping to revisit the ltsp-pam work soonish:

  https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltsp-pam

Scotty did some great work on that late 2016 and early 2017, and I'd
like to keep pushing it forward!


live well,
  vagrant

[Ltsp-developer] Please accept my invitation to join Marbella Hardware invention/ Electronica/ Programming

[David L. <in...@me...>]

Marbella Hardware invention/ Electronica/ Programming


Join David Laurence and 6 other Members in Marbella. Be the first to hear about upcoming Meetups.

The idea is a multifaceted group in which people from the coast can join together and collaborate in a spacious Office to come up with/brainstorm new ideas using the latest in electronica (Arduino, Ra...

--------------------------------------

Accept invitation

https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXN0IjoiaHR0cHM6Ly9zZWN1cmUubWVldHVwLmNvbS9yZWdpc3Rlci8_Z2o9ZWo0cyZjPTIxNjc4MzYxJl94dGQ9Z3F0bGJXRnBiRjlqYkdsamE5b0FKR0ZpTXpZME1UTmlMVEEwTURFdE5HSXpOaTFoT0RVMUxXUXhNalEzT1RNd1pHUTNNcXBwYm5acGRHVmxYMmxrcURNNE5EWTBPREV6JnJnPWVqNHMmY3R4PWludiZ0YXJnZXRVcmk9aHR0cHMlM0ElMkYlMkZ3d3cubWVldHVwLmNvbSUyRk1hcmJlbGxhLUhhcmR3YXJlLWludmVudGlvbi1FbGVjdHJvbmljYS1Qcm9ncmFtbWluZyUyRiUzRmdqJTNEZWo0cyUyNnJnJTNEZWo0cyIsImhvb2siOiJpbnYiLCJlbWFpbF9pbnZpdGVlX2lkIjozODQ2NDgxMywiaWF0IjoxNDgyNzc3NzA2LCJqdGkiOiJiZWE4MGRkOS0xYWFiLTQ1ZjMtYTQyNy0xODY5NGYxYWY2MDAiLCJleHAiOjE0ODM5ODczMDZ9.Pd0AoDO5zLQXaVnoMjMtmRpU3eL4VEj1_bL2OkijJRk%3D

--------------------------------------

-------
This message was sent by Meetup on behalf of David Laurence (https://www.meetup.com/Marbella-Hardware-invention-Electronica-Programming/members/201190087/) from Marbella Hardware invention/ Electronica/ Programming.


Questions? You can email Meetup Support at su...@me...

Unsubscribe (https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJob29rIjoiaW52X29wdG91dCIsImRlc3QiOiJodHRwczovL3d3dy5tZWV0dXAuY29tL2FjY291bnQvb3B0b3V0Lz9zdWJtaXQ9dHJ1ZSZlbz10YzImZW1haWw9aW52aXRlJl9tc191bnN1Yj10cnVlIiwiZW1haWwiOiJsdHNwLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQiLCJpbnZpdGVyX2lkIjoyMDExOTAwODcsImlhdCI6MTQ4Mjc3NzcwNiwianRpIjoiNWEwZWFmMjEtN2Y5Yy00ZGJkLWIwZDYtMDZjMTIyYzExZjI0IiwiZXhwIjoxNDgzOTg3MzA2fQ%3D%3D.mQO4pWS16N7VIdVU5Be7sPt0xINV6qK7b7eZZPrZUMk%3D) from this type of email.

Meetup Inc. (https://www.meetup.com/), POB 4668 #37895 New York NY USA 10163

[Ltsp-developer] Ubuntu 14.04 thin client NBD problem

[John B. <joh...@so...>]

I have created an Edubuntu 14.04.4 installation with LTSP
service checked at installation. I built images for armhf,
i386 and amd64, but configuration only uses i386. The last
two days I have spent trying to figure out why thin client
freezes (PXE). I struggled for 2 days and finally got it
to work. I do think however that my struggles may contribute
a little. So let me first explain what I have done and then
make a few suggestions:

Original installation got the client to boot and read the
/ltsp/i386/pxelinux.cfg/default from tftp ("ok" displayed).
Then after a few seconds, the screen is cleared with just
a cursor in the left top corner. It stays this way.

DHCP worked as expected (according to syslog) and with -vvv 
added to tftpd-hpa, I found that all tftp files were sent
to the client. pxelinux.cfg/default, vmlinuz and initrd.img. 

After trying various things, I opted to disable isc-dhcp-server
as well as tftpd-hpa and installed dnsmasq. I used settings
I found on the web and tried again. This time round I
found much more detail in logs and tftp did log the following:

...
file /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/C not found
sent /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default to ...
sent /var/lib/tftpboot/ltsp/i386/vmlinuz-3.13.0-79-generic to ...
sent /var/lib/tftpboot/ltsp/i386/initrd.img-3.13.0-79-generic to ...

Also, in stead of a blank screen, the client dropped to a BusyBox
shell. I have seen this with Ubuntu 12.04 before but was always 
able to solve it by configuring nbd-server. I did take out the
"authfile" setting in nbd-server config (based on information I
got from the internet) and since nbd-server has basically no debug
output, I added "prerun" and "postrun" commands that would simply
log these events to a file. I tested nbd-server by using nbd-client
from a different pc, and that worked for the image that is supposed
to be mounted on thin client (/opt/ltsp/images/i386.img). I then
checked the thin client (from the busybox shell) and there were no
/dev/nbd devices. (also, my prerun debug function was not called).
I executed an nbd-client command from busybox and successfully
created /dev/nbd0 (and prerun added info to log file). The command I
used was:

nbd-client 192.168.0.1 -N /opt/ltsp/i386 /dev/nbd0

This is basically where I started writing this email, and then I
found another page on the internet which helped me to determine what
the server IP was that the client thought it should use for nbd. 
It turned out that a different DHCP server was handing out the address
to the client. I never suspected this, because every single time
the PXE client would display the correct information on startup.
However, in my hunt for solutions I did find that DHCP DISCOVER does add
flags of functionality required of the DHCP server (see allow booting
and allow bootp in dhcpd.conf). So PXE client always got the right DHCP
server. But when the newly downloaded kernel did a DHCP DISCOVER,
obviously it did not require a DHCP server that supports thin clients.
Or did it? 

So I shut down the other DHCP server on the network, and my thin client
booted without problem. Also, I was able to switch back from dnsmasq to
isc-hdcp-server and tftpd-hpa and it still worked.

Based on what I have discovered I would suggest the following changes
to the thin client kernel / LTSP server:

1) Client: Add a boot tag in the DHCP request - if a kernel was loaded
from tftp server and it got that IP from a DHCP server, then surely that
DHCP server is still around for the thin client kernel. See
https://tools.ietf.org/html/rfc4578#section-2.4

2) Server: Comment out "authfile" option in nbd-server configurations.
It adds complexity and if someone really needs it, they will have to
edit the nbd-server.allow in any case. In stead, add a default
nbd-sever.allow file with a comment stating that the authfile should be
activated.

3) Server: Add -v to TFTP_OPTIONS in /etc/default/tftpd-hpa. A little
additional debugging information can help enormously with an initial
installation. 

4) Server: Add prerun and postrun commands in nbd-server config to log
nbd activiy. If a thin client is not booting properly, you need to know
where to start looking.

5) Server: I would seriously consider moving to dnsmasq. It works pretty
well and combines not only dhcp and tftp, but also allows the LTSP host
to be a DNS server, thereby allowing a default DHCP configuration to
have it as DNS server.

6) Server: One more thing - I searched quiet a bit for a DHCP
configuration that would detect the client architecture and present it
with the correct client image (armhf, i386, amd64 etc). There does not
seem to be any information out there about such a configuration, but
according to DHCP documentation, the spec allows for architecture to be
specified by PXE client (even though ARM is not listed in the original
spec). However, it would be great to allow a different architectures to
be served by an LTSP server.

Well this is it for now - I do hope someone finds this helpful in some
way.

Kind regards
John Bester