Author Topic: Maintaining and improving the Thin Clients module  (Read 15908 times)

Neru

  • Zen Monk
  • **
  • Posts: 58
  • Karma: +6/-0
    • View Profile
Maintaining and improving the Thin Clients module
« on: October 09, 2013, 02:44:01 pm »
Hello,

I've been working a little in the zentyal-ltsp module (Thin Clients) in order to add some new features. For the moment, I just added a name to the images, so that the images are identified using that name. This change allows the module to get rid of the limitation of having just one image for each architecture.

At the same time, I've created a ppa in launchpad where I uploaded the package:

https://launchpad.net/~neru/+archive/zentyal-ltsp

If you add this ppa to your Zentyal machine, you should be able to use the module. I tested the package in a 3.3 and it should also work in 3.2 machines.

Hope you find it useful, regards.

robb

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #1 on: October 09, 2013, 04:04:46 pm »
Good to so some un-official official support for the thin client module. I know there are quite some people using the module in 3.0.
I can fully understand why the thin client module was dropped because of the work that is involved and it is quite far off the target audience of Zentyal Small Business Server. But still, it was used quite a lot and it's good to see there is still an option to use it and it gets improved.

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #2 on: October 10, 2013, 01:38:32 pm »
Neru just been giving it a go.

Do you have to have a thin client file path in the dhcp?

I created a network object and included it in a profile but struggling to boot.

Are there any changes in the methodology of setting up the thin client?

Neru

  • Zen Monk
  • **
  • Posts: 58
  • Karma: +6/-0
    • View Profile
Re: Maintaining and improving the Thin Clients module
« Reply #3 on: October 10, 2013, 07:08:23 pm »
Hello,

you will have to configure the image path in the dhcp module since the integration with the Thin Clients module has been removed (to solve this is in my TODO list, hope to do something soon).

There have been no changes in the methodology, for the moment I just added a name to the Thin Clients.

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #4 on: October 10, 2013, 10:38:47 pm »
I have a small lab of 4 pcs and a server so if you need a bug tester.

I did quite a bit of work with LTSP but much is forgotten now.

I might be able to help and provide feedback.

There was one thing that always bugged me and that was having to enter all the mac addresses.

I did think it would be superb to use vlans as often departments and classrooms often are multiples of the same.
Making a mechanism between vlan and image is quite simple with the dhcp scopes.

Also having a scheduler to deliver certain images for certain periods would be great in a classroom environment.

There was quite a bit that I always thought would make thin client administration more palitible such as being able to clone images rather than building from scratch each time.

One thing and maybe this was a misinterpretation on my part which is I thought the client would run in the chroot of its image . When I evaluated the Zentyal module it looked very like this was untrue and it was running out of image chroots and in the process space of the server.
I chrooted into an image and added libreoffice and ran the client no libreoffice.
Installed libreoffice on the server rebooted the client and the client had libreoffice.

Thats when I stopped looking at the thin client module.

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #5 on: October 11, 2013, 01:58:27 pm »
Been having a look at the file options which are missing from dhcp.mas so its not going to work. Even with a file path.

Which is all good.

I just wondered because its not part of official zentyal should it be provided with post hooks rather than changing .mas files.


stc

  • Zen Apprentice
  • *
  • Posts: 22
  • Karma: +6/-0
    • View Profile
Re: Maintaining and improving the Thin Clients module
« Reply #6 on: October 12, 2013, 05:31:02 pm »
Thank you for the module, unfortunately the official DHCP module had LTSP integration removed, Im tinkering with reintroducing it back in.

regarding the LTSP module I would love to have a gui to assign images to specific groups. I know this can be done by editing the dhcpd.conf file but some menu gui integration would be great.


BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #7 on: October 13, 2013, 05:50:51 am »
@stc, would you explain how this could be done as with dhcp and tftp I don't understand how you can link groups into the equation.

If you had different ethernet ports then you could redirect each dhcp scope to a particular group or use vlans to emulate this.

Which would be great as from the network you could just patch into the right ports and have the correct group. Without the need to map a load of mac addresses.


stc

  • Zen Apprentice
  • *
  • Posts: 22
  • Karma: +6/-0
    • View Profile
Re: Maintaining and improving the Thin Clients module
« Reply #8 on: October 14, 2013, 03:42:50 pm »
Basically assigning an image to a clients can be achieved with changes to the dhcpd.conf as described here https://cs.uwaterloo.ca/twiki/view/CF/SettingUpLTSPserver

An example would be

Quote
group GROUPNAME
{
   use-host-decl-names on;
   host HOSTNAME1
   {
      hardware ethernet MACADDRESS;
      fixed-address IPADDRESS;
   }
   host HOSTNAME2
   {
      hardware ethernet MACADDRESS;
      fixed-address IPADDRESS;
   }

if substring( option vendor-class-identifier , 0 , 9 ) = "PXEClient"
{
   filename "/ltsp/CUSTOMIMAGE/pxelinux.0";
}
else
{
   filename "/ltsp/CUSTOMIMAGE/nbi.img";
}

option root-path "/opt/ltsp/CUSTOMIMAGE/";
}

With the recent ltsp module in github we have an option to make multiple images under different names, we also have the option to set ltsp profile which allows to create a group/object and add clients into that group by specifying mac or ip. What I am trying to say is that we have all the info required for the additional lines:

CUSTOMIMAGE = Image name
GROUPNAME = Object Name
HOSTNAMEx = Name of client with group/hostname
MAC/IPADDRESS = Required when adding client to object/group

The profile section in the ltsp module only allows for general settings but would be good to include a "Select Image" dropdown box

As far as I can see we would just require integration of the gui front end info with the dhcpd.conf file

« Last Edit: October 14, 2013, 03:44:21 pm by stc »

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #9 on: October 14, 2013, 04:00:52 pm »
Sorry my confusion as I thought you where talking at the user / group level.

I also like the idea of using seperate scopes for seperate groups.
I also like the idea of using vlans to accomplish this.

That way at the patch bay you are allocating an image to the client.

Could be great in high density / classroom or office where each classroom / office had a particular image.
Just plug and go.

Going a stage further in the classroom arena running cron jobs to run a schedule for a vlan or group against images for set periods.

I guess we will have to see how much time and effort Neru has to spare.

Looks like you already have a good knowledge of the dhcp, tftp, ltsp setup.

I am not sure what is the difference between the current profiles and what you suggest?

Its great that somebody also has an interest in the ltsp module as it would be great to have its availability as a community addon if some of its edges are smoothed.

[EDIT]

Ps my only rationale for this is the get away from having to map mac addresses.
If you are running higher density client situations its a bit of a pain for the sysadmin.
« Last Edit: October 14, 2013, 04:20:24 pm by BrettonWoods »

stc

  • Zen Apprentice
  • *
  • Posts: 22
  • Karma: +6/-0
    • View Profile
Re: Maintaining and improving the Thin Clients module
« Reply #10 on: October 14, 2013, 05:52:58 pm »
I fully understand where your coming from and it would be nice to be able to assign a switch/ports to a specific image, especially when you are dealing with many clients.

What I posted isn't particularly elegant or convenient if many clients are involved however I think it would work as a good starting point to provide some sort of control over image assignment, and that the basic things required are there. 

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #11 on: October 14, 2013, 08:36:35 pm »
I guess a lot is dependent on Neru, but if we could come to some mutual agreement.

Need to get a time scale to submit some .conf files and idea's.

I say about the vlan plug and play aspect and others now.

I used to be a developer of all things horrid & m$.

One thing hasn't changed and that is if you open all options then any design can bear that in mind.

So it might wise, I need to dust off the LTSP documentation and get back into the stride of things.

The only I remember is it seemed a relatively easy task to do. Damned if I can remember the details though.

Anything over a year is gone for me!

I will have a look and please I think your options are great as I was never sure why we just had the choice of 4 images.

Cloning images is also just a matter of copying the directory structure.

There is quite a lot that could be achieved that the last LTSP outing missed.

robb

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #12 on: October 14, 2013, 10:29:02 pm »
Let's elaborate a bit further on this and pop in a question to think about:
Do you see the thin client module as a final solution (like in: adding extra options to the LTSP module) or would it be wise to explore a true VDI solution? (like Ulteo, maybe even Ubuntu MAAS)

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #13 on: October 14, 2013, 11:06:31 pm »
I am really with you there Robb as LTSP falls short on the road warrior side. Thin clients where an alternative to expensive desktop computers.

I can now buy $10 devices that have a browser and the functionality of remote access and the thin client / fat client market is generally dying because perversely its more expensive.
I used to be big into the idea of recycling IT but the electricity saving in new cheap arm devices is there purchase cost in a year or less.

A lot doesn't make sense about thin clients any more.

Saying that with a few additions the work on the thin client module could be put to use for those of specific need.

Ulteo is definitely my favorite and I am trying to work out where (Metal As A Service) comes into this. Maybe things have moved on and I am missing something.

Well actually there is a package called theqvd which is definitely my favorite.  Ulteo is more complete and polished.

The conversation at this point will do no harm and bring in some idea's.

I have for quite a few years as a consultant been pushing and failing for the open source desktop.
I have given in to the monopoly that M$ has in this arena and its nothing to do with being any better.

Where I did have high hopes of gaining penetration was the idea of centralized services.
If you can negate desktop support your on a big money winner. If you look at the cost per user then desktop support is a financial legacy.

Personally I have been on a mission to find something that can do the job. As I say I really like ulteo and theqvd but both for some reason require clients.

Thats foobar as if you look at guacomole-vnc proxy its very possible to have zero support offerings in HTML5 browser solutions.

I would love Zentyal just to provide the back end of virtualised desktops.

Zentyal the office in a box... :) See already thinking of the sales pitch.

Its very possible and zentyal already has the perfect compliment of services to achieve it.

Zentyal virtual desktop solutions but it requires grabbing a few OS elements.
Don't redesign guacomole use it.
Don't redesign cups cloud print use it.
Don't redesign LXC virtualisation just work out a good method to rollout a desktop underneath it.

I guess I have spent too much time trying to find the killer M$ opensource system.

I have a feeling its not long off and I feel devices are the key word and not desktops.

Saying that though the killer app would be the ubuntu desktop as a service.
« Last Edit: October 15, 2013, 12:18:17 am by BrettonWoods »

BrettonWoods

  • Guest
Re: Maintaining and improving the Thin Clients module
« Reply #14 on: October 15, 2013, 10:34:31 pm »
Going back to the module we have and getting it operational I must admit I am struggling with the scripting.

If each client is going to be individually assigned then in the dhcp we need something like this.

host fix0 # blauTC
{
  hardware ethernet 00:40:f4:8a:22:ae;
  fixed-address 192.168.0.55;
  next-server 192.168.0.251;
  option root-path "/opt/ltsp/i386";
    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/i386/pxelinux.0";
    } else {
        filename "/ltsp/i386/nbi.img";
    }
}

I really like the addition of profile names as this gives the choice of which images and doesn't limit you with the default 4.

What I can't work out is how to get the profile and return its network objects.

Also it did occur to me that some check needs to be done that a network object isn't referenced several times.
Also I just wondered if this is slightly the wrong way round?
Should we have a list of network objects that you can apply a profile to, rather than a list of profiles that you can apply network objects to?
As you could declare a network object several times?

If you don't want to use mac address's then its the same thing just apply the above root-path option and filename to the scope.

I did have a go at creating several vlan interfaces  but it seems I have killed my server as it just hung for ages and then came up with a samba error.

I have never tried a multiple lan arrangement before and I just don't know if you can. I am going to do a reinstall. Set my vlans and then try to install samba. I will get back to you on that one.

It would be great to have multiple dhcp scopes with the pxe boot options. Also in the dhcp for that scope it would be really good to have a profile option. Also the next server options rather it being a global dhcp variable it would be much better to define it on each scope and the same for a profile if you are doing it by range. I guess the only thing I have to check is the host name.

That way you could provide another zentyal server yes you would have to create the profile twice but you could have several servers serving images and applications. Not elegant but it would work.

So I am stuck at the moment trying to work out how to get the profile information to write out the dhcp.conf.

I did find this about host name assignment
ddns-hostname = pick (
host-decl-name,
option host-name,
# dhcp-192-168-3-11
concat ("dhcp-", binary-to-ascii (10, 8, "-", leased-address))
);

Then I found http://sourceforge.net/apps/mediawiki/ltsp/index.php?title=DHCP

which has a whole section on it.

« Last Edit: October 15, 2013, 11:11:49 pm by BrettonWoods »