Maintaining and improving the Thin Clients module

[stc]

Hi BW

It great to see your still looking at the module and ways to improve it. I would like to say in advance that a combination of my work and limited knowledge of zentyal and module development I am probably not as much use as I would like to be but trying to learn as I go along, but hopefully I could help bounce ideas.

I'll start off with the next server and the small issue of recreating the profile. Would restoring a backup of the original server populate the profiles, especially when we have many different clients? Going further and possibly a realistic option may be having advanced backup options allowing you to individually select what modules you want to backup/restore. Going even further would be to have an option to specify secondary server to sync across objects/profiles

Regarding the duplicate object/client would a lookup command like in some other modules be included into the objects module to check if already exists. From what I culd see briefly the variables correspond to the group and members/clients and stord in the likes of objects/conf/ObjectTable/keys/objc$/members/keys/mmb$

As mentioned my knowladge is limited in this area however from other things in the past I would think a lookup that checks all object tables could prevent duplicates.

The downside to doing this would be that the original Object module would be compromised and no longer work as it originally did so one would loose functionality forcing one to use it in one mode or the other. Actually just a thought, one could add an option to enable "LTSP Mode" which could essentially unhash an "if exists" option or equivalent, allowing to choose without the need of resintalling the original module.

Sorry for waffling a bit hopefully you can understand what I was thinking lol.

Finally about the dhcpd.conf file I believe the template that includes the LTSP section is in the usr/share/zentyal/stubs/shared-network.mas. I suppose to identifying the keys/tables required to get the information we need.

[BrettonWoods]

Don't worry about waffling or skill levels.

I will have a think about your ideas and post something and see if you agree. you can never get to much opinion and thought at the start of project as each item might have a bearing on direction.

I also struggle with scripting my M$ skills are completely redundent. For a couple of years I have been dodging taking the plunge.

I don't care about proficiency and have enough experience in IT to know that there isn't a right way.

Going back to the scripting and having a look at things in 3.2 is that parts of it are missing.
I have never done any zentyal dev before but each module would seem to be quite distinct.

My thoughts are to go back to 3.0 and have a look at what I am missing.

Also my thoughts with being a community mod is maybe rather than create a full blown addon. We should just use what we have and try and create the rest with hooks so it is purely a community hack.

Personally I am thinking we should just keep our eyes on ltsp and what functionality we want there.

Neru added the name field to the profile list which is a great improvement to have more than just 4 profiles based on fat/thin architecture.

I sort of think in my Lancashire dialect that network objects should be the higher level object rather than the profile. But I don't think its critical so maybe just keep what we have got. but currently its a bit arseface (wrong way round).

I do think the ability to clone an image would be great as you could create base templates to work from and then just add or remove to make the difference required for the cloned profile. Cloning for me is a really useful tool and it would require more than just hook scripting. So maybe that can be completed as a last option to be added. Its only a matter of copying a particular chroot renaming and then runing an image update with the right parameters. I think one item I need to have a look at in more detail.

I think I can get ranges working with a hack of using the filename in the dhcp to use a profile name.

As I said I am going to install 3.0 and grab the scripts and stuff. I don't know if Neru is available just to give us a hand to get us started.


   

[BrettonWoods]

It would be great just to get opinions on ltsp without even going near scripting and development.

Replied to myself apols, but thought just a general consensus on features separate to the above post might be useful.

Backups is important and this isn't just the files as much is stored in the ltsp config.

Never been a big fan of using redis over the old /etc/ method but hey. Could of just copied /etc/zentyal/ltsp

I really like the idea of being able to use vlans to create ranges which are assigned a profile.
I suggested stealing the file path option but if done correctly all that is needed is a drop down of profiles in the dhcp scope.

I say as a lazy sysadmin it negates the need to assign mac addresses to Ip's and also allows a group change by just selecting a different profile. I would just like some input if this would be of any interest.

Being able to set the next server is really great and simplistically as long as you have the same profile name and directory name you can then use a small cluster of servers that are manually load balanced.

Then you can talk about automatic synchronisation and push / pull operations but maybe just starting off simple is the best idea. Currently by specifiing a different next server and manually making sure it has the same profile name you can cluster.
I did have some reservations about running LTSP on my PDC and this ticks that box and provides ways to load balance. The DHCP in zentyal and LTSP config would just redirect to other simple zentyal servers and negate any security and load concerns. Again I think its just a matter of the next-server being declared at scope level rather than global.

There was much talk of various lock down and control tools. I had the opinion of just keep it native and chroot into a image create that particular desktop. That is why I like the ability to clone. It means you can do the hard work of creating a base image then clone and make small modifications. Cloning is it needed?

In terms of operation and general LTSP without any thoughts on dev is that if I am given the option to run on another server, be able to use ranges without the need of mac declarations and add cloning support. The rest I can do relatively simply manually.

[stc]

Just got back in and read your posts and some good thoughts. Sorry to make this post a bit short but two things possibly of interest.

1. I sorted the DHCP module for 3.2 with LTSP integration so along which along with Neru's updated module works fine giving back the original Think client setup that was removed. I have attached the .deb for now (sorry it was a quick mock up so version still set as 3.2)

2. Stumbled across this yesterday it might be of some help https://www.ltsp-cluster.org/

[BrettonWoods]

Wow that was quick, lol haven't finished trawling through various LTSP sites.

I know about LTSP clusters, well I have read about them. It was just a thought of just a few minor mods could provide similar with very little work without going that far. Doesn't have to be vlans, could be separate nics. Just adds a lot to the whole LTSP scenario where a couple of workstations can be added. I really don't like the security and load concerns on a PDC. With Samba a couple of synchronized zentyal ltsp servers could roll out to quite a scale with not much more than those simple mods.

I will wait and see what you think.

Just staying with Zentyal being able to declare the next server and boot path at the dhcp scope would be really cool.
It mirrors how the config of dhcpd is layed out root-path and filepath are scope variables really.

Its great you have done so much, so I will shut up and have a go with that .deb.

Many thanks and much karma. +20

[stc]

Hi

Regarding the DHCP module to avoid any confusion I just updated it to restore what was removed for 3.2 so along with Neru's updated module it just bring the standard LTSP functionality that was in 3.0. It allows us to work with 3.2 rather than having to go between 3.2 and 3.0.

I will try to get some real moding done over the weekend if I get some time and try things out.

For a small school environment I am testing it on LTSP Cluster is overkill however posted it as it might have some bits that might be useful of be able to help.

[BrettonWoods]

Its the bits from the dhcp that where missing from what I can gather.

Apols as I need to remove the vlan setup and just go with a single nic to keep other errors at bay.

I will be doing that today.

So will do a run down. It all looks good the scopes look good. Just wasn't able to test the pxe boot.

[BrettonWoods]

Attached is the desktop image of the dhcp module.

Also attached is dhcpd.conf

From the dhcp.conf I am pointing the client to /opt/ltsp/i386 and there doesn't seem to be anywhere to include the correct profile.

The client is having a go but its creating a pxe error because it is looking for directories that are not there.

The advanced options for the DHCP provide the default architecture i386/32 or 686/64 with a tick box of fat or thin.

There doesn't seem to be any mechanism in the dhcp to select a particular profile.

Personally I would like to be able to select a LTSP profile name in the scope section of the DHCP module.

Also when it comes to Static Address I have never understood why you have to create individual network objects.
Its not needed for DHCP and for me isn't logical. If I need to start declaring network objects then in the network object module I will declare them.
Just a small gripe but static address are just IP, Mac and description. Its that easy.

As I say I would prefer a drop down of LTSP profiles in the DHCP scope as for me this is more logical and how the conf files works anyway.
This would also mean being able to select the profile in a static address which should really be called "assigned addresses" as they are handled by DHCP and are also just single IP scopes.

Currently LTSP has its settings in the advanced options of the DHCP server.

The next-server option allows Zentyal, The current server : Host, Point to another server, None LTSP is not used.
The Host box stays open when you select Zentyal and should only be visible when Next-Server is set to Host.

The next to items Architecture and Fat-Client shouldn't be here there should be a list of LTSP profiles.
Thats the linkage that seems to be missing.

Maybe Neru could provide more details.

I like the ability to be able to point at another host.

As long as the sysadmin remembers to setup and duplicate the profiles its a simple way to cluster servers together and load balance.
Its again my own personal preference of not running applications and load on a PDC.

If I create a profile so it matches the dhcp LTSP settings then the client does boot.

I can't seem to logon on the client though.

Oct 20 20:55:37 zent1 dhcpd: DHCPREQUEST for 192.168.3.33 from 00:19:d1:57:3a:53 via eth1
Oct 20 20:55:37 zent1 dhcpd: DHCPACK on 192.168.3.33 to 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:09 zent1 dhcpd: DHCPDISCOVER from 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:10 zent1 dhcpd: DHCPOFFER on 192.168.3.33 to 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:11 zent1 dhcpd: DHCPREQUEST for 192.168.3.33 (192.168.3.1) from 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:11 zent1 dhcpd: DHCPACK on 192.168.3.33 to 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:11 zent1 in.tftpd[3459]: tftp: client does not accept options
Oct 20 20:58:33 zent1 dhcpd: DHCPDISCOVER from 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:33 zent1 dhcpd: DHCPOFFER on 192.168.3.33 to 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:33 zent1 dhcpd: DHCPREQUEST for 192.168.3.33 (192.168.3.1) from 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:33 zent1 dhcpd: DHCPACK on 192.168.3.33 to 00:19:d1:57:3a:53 via eth1
Oct 20 20:58:34 zent1 nbd_server[1871]: connect from 192.168.3.33, assigned file is /opt/ltsp/images/i386.img
Oct 20 20:58:34 zent1 nbd_server[1871]: Can't open authorization file (null) (Bad address).
Oct 20 20:58:34 zent1 nbd_server[1871]: Authorized client
Oct 20 20:58:34 zent1 nbd_server[3539]: Starting to serve
Oct 20 20:58:34 zent1 nbd_server[3539]: Size of exported file/device is 269414400
Oct 20 20:58:45 zent1 nbd_server[1871]: connect from 192.168.3.33, assigned file is /opt/ltsp/images/i386.img
Oct 20 20:58:45 zent1 nbd_server[1871]: Can't open authorization file (null) (Bad address).
Oct 20 20:58:45 zent1 nbd_server[1871]: Authorized client
Oct 20 20:58:45 zent1 nbd_server[3541]: Starting to serve
Oct 20 20:58:45 zent1 nbd_server[3541]: Size of exported file/device is 269414400
Oct 20 20:58:45 zent1 nbd_server[3541]: Disconnect request received.
Oct 20 20:58:45 zent1 nbd_server[1871]: Child exited with 0
Oct 20 20:59:13 zent1 nbd_server[1871]: connect from 192.168.3.33, assigned file is /opt/ltsp/images/i386.img
Oct 20 20:59:13 zent1 nbd_server[1871]: Can't open authorization file (null) (Bad address).
Oct 20 20:59:13 zent1 nbd_server[1871]: Authorized client
Oct 20 20:59:13 zent1 nbd_server[3690]: Starting to serve
Oct 20 20:59:13 zent1 nbd_server[3690]: Size of exported file/device is 269414400
Oct 20 20:59:13 zent1 nbd_server[3690]: Disconnect request received.
Oct 20 20:59:13 zent1 nbd_server[1871]: Child exited with 0
Oct 20 20:59:37 zent1 ddclient[8852]: WARNING:  file /etc/ddclient.conf, line 8: Invalid Value for keyword 'login' = ''

[stc]

Oh crap it didnt twig about the changes in Neru's ltsp module, what a brain fart moment. I will try to have a look at it tomorrow. Looking at it I forgot that $fat and $arch values in the image option where replaced with just $name

I didnt do those changes to the dhcp module so when looking for the images it was looking at

"/ltsp/<% ($options{fat}?'fat-':'') %><% $options{architecture} %>"

instead of the new format. Thins needs changing as well as adding a "default image" option as you mention in the form of a drop down to select an image.

Didn't have any time today as I hoped but will try to have a look at it when I can

sorry about that :-)

[BrettonWoods]

STC, don't apologise and in your own time.

Its great that it is being done.

Many Thanks

[BrettonWoods]

Just wondered if you or Neru had managed to come to any solutions.

Just a bump really as its gone a bit quiet.

[stc]

Hi BW

I'll be honest I havn't even had a chance to look into this since last time as just been manic at work with other bits I havn't had a chance to play with our server. This should hopefully change over the next week or so, so I should be able to look at it again soon.

[BrettonWoods]

There was a recent fix with the DHCP so that the next server should show up.

I haven't had a look yet. Also haven't heard from neru.

When you have time post what you have and maybe we can share the workload a bit

https://github.com/Zentyal/zentyal/commit/c44bbeec26ef1d3eb1d6087381298049f8443414

[yura.syrov]

i am install this module, enabled module and save settings. i am set name and select arch. i am click to button "create image". no effects. why?


upd. after manually execute /usr/share/zentyal-ltsp i have record in the 'Available Images'...

[tasraison]

Thank you for this module, working fine with Zentyal 3-3, but I keep getting "building image failed" with 3.4, any idea what might be wrong?

TQ