Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: Neru 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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
@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.
-
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 (https://cs.uwaterloo.ca/twiki/view/CF/SettingUpLTSPserver)
An example would be
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
-
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.
-
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.
-
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.
-
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 (http://www.ulteo.com/home/en/home), maybe even Ubuntu MAAS (http://www.ubuntu.com/cloud/tools/maas))
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/ (https://www.ltsp-cluster.org/)
-
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
-
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.
-
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.
-
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' = ''
-
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 :-)
-
STC, don't apologise and in your own time.
Its great that it is being done.
Many Thanks
-
Just wondered if you or Neru had managed to come to any solutions.
Just a bump really as its gone a bit quiet.
-
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.
-
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
-
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'...
-
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
-
Hi,
I have problem in Zentyal 3.3, everything works up to the login screen on thin client. I write login and password (user is in /etc/passwd on zentyal) and I cannot log in from thin client. After 20 seconds login screen appears again. There is nothing strange in syslog. I can make ssh user@zentyal from thin client.
Can anyone give me some advise, what to check next?
Adam
-
have you looked at this thread : https://forum.zentyal.org/index.php?topic=11612.0 ??
-
Neru, can you please re activate your repository ppa.launchpad ? I need it to restore my config (need to reinstall ltsp)
Thank you.
-
ok, went through the wiki and built the package.
thank u anyway (anyone who read this ;))
-
Hi all,
It seems this topic has gone cold. Does that mean the project to keep LTSP alive in Zentyal is dead? For the classroom situation LTSP is very useful and we need to get this back into the server. I've seen people move away from Zentyal to use something else due to the lack of thin client support. I know the product was geared towards SMBs but it has gained popularity in the educational realm. There have been implementations using thin clients and now that's all in danger. This effort was keeping it going but it looks like that too is going cold.
Any reasons? Is it a dead end?
Cheers
Osay
-
why this module is necessary? the command line does better
-
My personal opinion would be to use LTSP on a dedicated server and not combine it with other services since it is rather memory consuming. And if you go on the dedicated server path, using edubuntu as the base distro to deploy LTSP might be a good solution since it has some neat deployment scripts and all the educational goodies you could wish for in an educational environment.