Puppy Linux Discussion Forum

[Aitch]

gcmartin

I got impatient...ha ha

http://murga-linux.com/puppy/viewtopic.php?p=499955#499955

More PR isn't it?

Aitch

[jamesbond]

Dutchman again, yes, that's one of the ideas.

mhanif - "virtual remastering" is functionally equivalent of "standard puppy + savefile". It's better to use the "puppy + savefile" because you save space - only the changed / modified files needs to be kept, instead of the entire pup.sfs

NFS can export multiple directories, no problem. The problem with NFS is security - in the past, NFS security is based on IP address - not something you want to live with in this age. There are ways to tie NFS security with Kerberos apparently, but honestly I have no idea how to do this - both at the server level and at the client level.

Does anyone thinks that standard puppy setup is secure enough to run sshd? It's very easy to setup a "regular" user on puppy for ssh purpose, but I'm not sure whether puppy is secure enough to run as that user (ie can't wipe important directories, for example)? Running chroot-ed sshd sounds better - I need to explore this dropbear.

Terminal Server (TS) concept looks interesting, but as I said above, it's difficult to do using puppy as the server. As a client - no problem, we have loads of TS client - we have vnc, rdesktop, and others. As a server - well, you need a multi-user puppy, and we are nowhere near that.

gcmartin - thanks for the info on Edubuntu. Does the setup you mention runs out of the box? If I download Edubuntu LiveCD, will all that you mention works straight away - no special installation process is necessary (e.g. goto synaptic, download this packages, install this script, edit this config file, change that settings ...)? If yes, that would be very great!

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. Using a combination of ssh and nbd, we can explore the possibility of starting an NBD server when the remote user logs in from their ssh client. Boot process continues with the client PC mounting the save-file over NBD.

Good ideas everyone, thanks for sharing. Anyone else?

[jamesbond]

Following up with the concept outlined earlier, I've got chroot-ed dropbear to work. Combined with sftp-server from openssh, it serves sshfs smoothly with a non-root user id. I was thinking of using NBD - but why bother, just put a symlink to the pup.sfs to users' home directories and let dropbear serves both the pup.sfs and pupsave.sfs.

All that is needed is plumbing scripts - the server side is about 1.6M (1.1M of those is full busybox, which we can definitely cut down). The sshfs client side (not including busybox and network drivers) is 2.5M, and that is because I'm too lazy to convert those glib dependencies to uclibc instead (glib+libc=2M).

I think we can do the same with cifs. Client-side requirement for cifs will be very minimal (cifs is a kernel module, and static mount.cifs is only 70k), as compared to sshfs. The samba server component on the other hand ... and I don't think it's that easy to make samba runs under chroot (simply because there are too many libs?).

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

[jamesbond]

Some teasers
I did this with Samba for reasons I already said above.

Step1 - After PXE booting - stopping to wait for entering network credentials to connect to samba server (not puppy's credential, which is always root).
Step 2 - After entering credentials (spot) and setup all unionfs layers, just before switch root.
Step 3 - After switch_root and executing /etc/rc.d/rc.sysinit, stopping in terminal before going to X desktop.
Step 4 - Within the X desktop. Mount shows all the mountpoints. I'm using 128MB of pupsave for this experiment.

This is implementation of method 3 (please refer to first post). Summary: PXE booting, with pup.sfs and pupsave.sfs over cifs. Persistence is over the network - users can login to any PC and will see his/her own desktop just the way they left it before. Puppy runs as root as usual, but access to cifs is governed by network username/password separate from puppy's root account. Everybody will see his/her own pupsave file only and cannot access/mess with others. If more security is required, encrypted pupsave can be used (didn't do this in the experiment).

[jamesbond]

Same as above, but running under sshfs (under chroot-ed dropbear). Feels a tad slower - may be because of the encryption overhead.

[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

[gcmartin]

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