Beyond PXE - Puppy Network booting

[gcmartin]

Your question on Edubuntu: Answer; YES. (Sorry for the delay. Day job!)

Pluses:

• Loads of documentation
• Lots of assistance across the spectrum of users; educational users and as well as products specialist.

Seems that this area gets a very very large community of people helping.

Its an out of the box implementation. All you need is some HDD space to house your filesystems (we used LVMs) that will be built.
(I think you understand why LVMs are important in areas where there is unexpected-uncontrolled growth for user needs.)

With your current expertise that I've witness from your netbook understanding, this is a no-brainer for you. I expect that more of your time will be in initial reading, than actual download, setup and use. Its a guided approach. LTSP PCs on the LAN are dumb. There are an average of about 50+ simultaneous users in a defined user base of 200+ people on a 4GB RAM dual-Xeon server and its is not close to max, currently. Edubuntu comes with a full complement of Office/Classroom tools for students and faculty. Expansions are planned this summer.

Hope this helps.
We are trying to determine if we can securely allow off-site, over the LAN access directly from the internet. Right now, we are using a Microsoft Terminal server as a helper to get internet user connections to the Edubuntu ID.

Hope this helps.
P.S. You are absolutely right about Puppy not be an attractive platform for something like this.

[Master_wrong]

@ Jamesbond

Hmmm. Must consider performance also. Which one is faster, sshfs or samba?

from
http://www.saltycrane.com/blog/2010/04/ ... fs-ubuntu/

it seem samba and nfs is faster ?

I'm no expert, but from what I've gathered, sshfs is faster than WebDAV and slower than Samba and NFS. However, Samba and NFS are typically more difficult to set up than sshfs.

so this leave which is faster... nfs or samba
from this link i assume nfs is faster
http://forums.whirlpool.net.au/archive/701909

From my experience NFS is a much faster protocol than SMB. So moving large amounts of data around is going to be better with NFS.

Using Kerberos in conjunction with NFS will make it just as secure as SMB, although kerberised NFS can be a pain to setup.

and here is the test result from other site

According his tests:
SMB : 9.6 MB/s
NFS (native QNAP) : 8.8 MB/s
UNFS (ipkg) : 16 MB/s

http://www.mpcclub.com/forum/showthread.php?t=21484

[gcmartin]

...

I'm no expert, but from what I've gathered, sshfs is faster than WebDAV and slower than Samba and NFS. However, Samba and NFS are typically more difficult to set up than sshfs.

The decision to use either of these rest with whether there is Microsoft presence in your network and its users. Every Microsoft PC is built with SMB/CIFS. None of them come out of the box with NFS. Every MS user knows Network Neighborhood. None know anything about NFS or troubleshooting or ... Because 99.44% of this earthly world is Microsoft, this is helpful knowledge especially in light that MS is coming out with a personal hand-held with a MS OS.

SAMBA is NOT very hard to set up. Biggest issues are what role do you want your SAMBA PC to share out to the network. It can be something very very simple like sharing a folder or a printer, all the way to controlling every PC on your network.

Now, lets set the FS discussion aside for a moment, and focus of a definition of what a TS system (Server and its clients) should be doing. When we are discussing, here, we should identify which of the following that we are discussing

1. Which
2. If we are trying to do a TS, then our discussion is around how we intend to get the clients setup to access and run ON THE SERVER. We might call this Real TS.
3. If we are trying to give isolated users on our LAN who have PXE boot and is running a desktop OS, a means to have protected storage, that is a completely different thing. We might call this Extended PXE.

And, there may be other implementations subsets, too.

Distributed File Systems (i.e. NFS, CIFS, DFS, etc) are a separate discussion from getting something operational and certainly separate from a TS where none of this is needed, except in helping to get a thin-client on the air.

Let's not miss the forest for the trees that we readily see.

Hope this helps.

[gcmartin]

Those interested in experiencing a Linux TS go here:
Please take a moment to help the community by leaving them a response to your experience. This helps all of us.

[jamesbond]

Final teaser: sshfs with nbd.
step6 image - just after booting, stopped at command line.
step7 image - within X desktop, showing mount points - pup.sfs is mounted readonly over nbd, pupsave is mounted over sshfs.
Bootspeed - I don't time it, but it feels faster than sshfs or cifs alone.
All servers are chroot-ed except dnsmasq - me too lazy

[jamesbond]

Here's an idea.

I have MBWE (that is, Western Digital MyBook World Edition - a simple NAS of some sorts). By default it serves cifs (well, it's a NAS for home users - and I really mean *home* users, it's painfully slow serving the cifs). BTW people say the newer version is *much* faster but I don't have that.

Good thing about MBWE is that it runs Linux, and it's rather hackable - in fact, there is a whole community whose purpose is to transform MBWE from a just a humble NAS into all sorts of things.

One only needs to add dnsmasq (available in optware) for PXE and nbd (must compile) - and then add the recipe from this thread - to get a fully functioning, puppy multi-user boot server

cheers!

[rufwoof]

NBD is there mostly for performance reasons. Problems with NBD is similar NFS - it has no security. And to make it worse, it can only export one block device per service - thus if you want to server 10 different users, you need 10 instances of NBD server. If the server is light-weight enough, this probably isn't a problem.

Old thread/post I know, stumbled across it whilst looking where to post a x-ref for http://murga-linux.com/puppy/viewtopic. ... 78#1039578
You can have multiple clients served from a single nbd server instance - provided you're content to use copy on write, where each user sees the same unchanging base set of files, but can individually edit those files and the changes are stored in separate diff files (copy on write). Like a sfs layered setup where the changes are lost at shutdown/disconnect and each user/client only sees their changes.

Yes the server would have to have a instance for each user if changes were desired to be saved back onto the server system. But if changes were stored locally then the server can be just a single instance.

Consider for example where I create a sfs of a documents folder on my server box 192.168.1.5

cd /mnt/sda1
mksquashfs docs docs.sfs -b 4096

Using a block size of 4K here as that's the minimum for mksquashfs whilst its the maximum for nbd.

I then serve that up using nbd

nbd-server 9000 /mnt/sda1/docs.sfs -c -C /dev/null

On a client I use nbd-client to link that server process to a device

nbd-client 192.168.1.5 9000 /dev/nbd0

and then mount that sfs

mkdir /tmp/sfs
mount /dev/nbd0 /tmp/sfs

and create a aufs structure for that so changes can be recorded
mkdir /root/changes
mkdir /tmp/top
mount -t aufs -o br=/root/changes:/tmp/sfs none /tmp/top

So when I open rox on /tmp/top and make changes to files there (sfs content), the changes are stored in /root/changes (which here I assume remains persistent, so prior changes remain available after reboot).

When done, I umount /tmp/top and /tmp/sfs ... and if later I re-establish that then the prior changes will still be available in /root/changes i.e. all changes are being recorded on the local system. Multiple users can use a similar arrangement on their box, all sharing the single core sfs, but each user having their own changes stored locally.

Only if I want those changes being stored back on the server would instead another nbd-server port be required, one for each user, in order to store the changes folder content on the server. But equally that could be via a sftp, scp or other transfer method.

In practice, there's not much point in actually serving up a main sfs on the server, the only benefit is that being compressed files will be quicker to read across the LAN. If a actual volume, or file filesystem is served along with copy-on-write, then that's the same as being read only anyway. And a file filesystem or actual volume is easier to update compared to having to unsquashfs, make the changes and mksquashfs a new version of sfs in order to update it. Whichever is used, the main core documents will be safe from the likes of being wiped out or modified by ransomware as they're read only and on a another box, only the changes (such as /root/changes folder content) might be destroyed/encrypted/changed, but so equally might those changes be destroyed/encrypted/changed if they were being stored in a rw folder on the server.