Beyond PXE - Puppy Network booting
Posted: Fri 25 Feb 2011, 08:28
This is my first ever "Cutting Edge" post - so please be gentle
Ok - everyone knows puppy can booted via PXE. The necessary infrastructure (=the hard part) was put in place by Barry in early 4.x series, a couple of years ago. I was in one way or another to automate the server-side portion of this PXE booting - though I'm only sitting on the shoulder of the giant, doing only incremental work on top of those who came before me.
But then what? mhanif and master_wrong here http://murga-linux.com/puppy/templates/ ... _reply.gif asked whether it is possible to netboot puppy via nfs. It is possible, although it's not as wasy as PXE booting.
Technosaurus here http://murga-linux.com/puppy/viewtopic. ... 661#498661 has another ideas - secure booting over nfs with persistent personal user storage.
All these have the same theme - turning puppy, a single PC operating system, into a network-centric OS. And seeing what's possible and what's not possible (=because it would be too difficult).
So I thought I'd just put together a thread to discuss this - if this hasn't been discussed before. I don't have any stake at all on this at the moment, so I'd probably just contribute some random ideas and not code. All are welcome though, if they want to elaborate on the ideas and turn it into a working implementation.
Some ideas:
1. PXE booting - done and dusted WIth / without persistency. Useful for lab environment, where every boot will be refresh configuration no matter how screwed up the previous booting was (with the exception of the student re-flashing the PXE boot ROM, of course). Persistency - if wanted - can be done by storing the session on thumbdrive just before reboot.
2. NFS booting without persistency. Useful for internet cafe scenario. During boot, puppy will mount its pup.sfs or its rootfs from a nfs server. Not much difference (in benefits) from straightforward PXE booting, except perhaps less RAM is used (straightforward booting with PXE implies pfix=copy to more or less, with NFS it's possible to achieve the equivalent of "frugal" operation or even "full install" operation - thus more memory for applications). It also has the benefits of ability to selectively kill the client PC from the server - just drop the connection to that particular client PC and be done with it
3. Network booting with persistency (with NFS or other network filesystem). We want to store the persistency on the server itself, not on the client PC - so that we can go to any PC, login with our credentials, and get our desktop back (virtual desktop / roaming desktop) - similar to VNC and its friends.
Theoritically it isn't much different from above, but instead we enable r/w access on the shared directory on network server. The problem is how to make it secure and ensure that one puppy user won't be able to look and *delete* other puppy user's session persistence, which is what will happen if we use straight NFS sharing for pupsaves.
There are a few ways to workaround this, but in the end I think NFS is probably not the best network fs to be used. I'm thinking along that "just because puppy client run as root, it doesn't have to be the same on the server end". This requires a network fs on which the user must be independently authenticated regardless of its UID on the client PC (which is always root in puppy).
I'm thinking along sshfs or cifs. Both allows independent logins to the network server, and from the server end we can map it in such a way that every network user will have their own directory for pupsave files or for direct sharing (combined with aufs on the client end). From end-user perspective, puppy can be augmented with DirectFB + qingy graphical login (this login is to the network server) - and there you go, persistence on server, root user on client, every user can't meddle with other user's pupsave.
I think it's still possible to do the server component using puppy as well, because it's not too difficult to establish user identities at the cifs / sshfs level. I don't know enough of NFS to say whether the gss/krb5 security can be used for this, but it sounds "complicated" to me, while cifs (=SAMBA server) and sshfs (=ssh daemon) is practically avalable for all puppies and relatively easier to configure.
4. Thin-client remote desktop. This can be done with PXE or NFS booting on its base. The idea is to embed a small remote desktop client on initrd or pupsave (vnc, xvesa, rdesktop, or some other directfb-derived RFB client). Upon booting, the client will be presented with login screen and a choice of servers to login to. Again, client PC's puppy runs as root, but the applications on server doesn't.
Persistence is automatic as the applications are actually run on server, not on the client. As far as the application is concern, the client PC is just a "screen".
This is probably better than 3) above for smaller, lighter client memory/cpu-challenged machines which can't handle application load - e.g. a set-top box type of client.
Now, for this, while the client component can definitely be puppy, I'm not sure whether we can use puppy for the server - I think because the server will require full multi-user capability.
None of the above a new - people have been doing this for many years (I think LTSP may employ some or all of the above, or even scenarios I haven't though of) - but the idea here is how to apply that to puppy. Of course, it may be easier instead just to go to LTSP and use it - but hey, what's the challenge ?
Anyone?
Ok - everyone knows puppy can booted via PXE. The necessary infrastructure (=the hard part) was put in place by Barry in early 4.x series, a couple of years ago. I was in one way or another to automate the server-side portion of this PXE booting - though I'm only sitting on the shoulder of the giant, doing only incremental work on top of those who came before me.
But then what? mhanif and master_wrong here http://murga-linux.com/puppy/templates/ ... _reply.gif asked whether it is possible to netboot puppy via nfs. It is possible, although it's not as wasy as PXE booting.
Technosaurus here http://murga-linux.com/puppy/viewtopic. ... 661#498661 has another ideas - secure booting over nfs with persistent personal user storage.
All these have the same theme - turning puppy, a single PC operating system, into a network-centric OS. And seeing what's possible and what's not possible (=because it would be too difficult).
So I thought I'd just put together a thread to discuss this - if this hasn't been discussed before. I don't have any stake at all on this at the moment, so I'd probably just contribute some random ideas and not code. All are welcome though, if they want to elaborate on the ideas and turn it into a working implementation.
Some ideas:
1. PXE booting - done and dusted WIth / without persistency. Useful for lab environment, where every boot will be refresh configuration no matter how screwed up the previous booting was (with the exception of the student re-flashing the PXE boot ROM, of course). Persistency - if wanted - can be done by storing the session on thumbdrive just before reboot.
2. NFS booting without persistency. Useful for internet cafe scenario. During boot, puppy will mount its pup.sfs or its rootfs from a nfs server. Not much difference (in benefits) from straightforward PXE booting, except perhaps less RAM is used (straightforward booting with PXE implies pfix=copy to more or less, with NFS it's possible to achieve the equivalent of "frugal" operation or even "full install" operation - thus more memory for applications). It also has the benefits of ability to selectively kill the client PC from the server - just drop the connection to that particular client PC and be done with it
3. Network booting with persistency (with NFS or other network filesystem). We want to store the persistency on the server itself, not on the client PC - so that we can go to any PC, login with our credentials, and get our desktop back (virtual desktop / roaming desktop) - similar to VNC and its friends.
Theoritically it isn't much different from above, but instead we enable r/w access on the shared directory on network server. The problem is how to make it secure and ensure that one puppy user won't be able to look and *delete* other puppy user's session persistence, which is what will happen if we use straight NFS sharing for pupsaves.
There are a few ways to workaround this, but in the end I think NFS is probably not the best network fs to be used. I'm thinking along that "just because puppy client run as root, it doesn't have to be the same on the server end". This requires a network fs on which the user must be independently authenticated regardless of its UID on the client PC (which is always root in puppy).
I'm thinking along sshfs or cifs. Both allows independent logins to the network server, and from the server end we can map it in such a way that every network user will have their own directory for pupsave files or for direct sharing (combined with aufs on the client end). From end-user perspective, puppy can be augmented with DirectFB + qingy graphical login (this login is to the network server) - and there you go, persistence on server, root user on client, every user can't meddle with other user's pupsave.
I think it's still possible to do the server component using puppy as well, because it's not too difficult to establish user identities at the cifs / sshfs level. I don't know enough of NFS to say whether the gss/krb5 security can be used for this, but it sounds "complicated" to me, while cifs (=SAMBA server) and sshfs (=ssh daemon) is practically avalable for all puppies and relatively easier to configure.
4. Thin-client remote desktop. This can be done with PXE or NFS booting on its base. The idea is to embed a small remote desktop client on initrd or pupsave (vnc, xvesa, rdesktop, or some other directfb-derived RFB client). Upon booting, the client will be presented with login screen and a choice of servers to login to. Again, client PC's puppy runs as root, but the applications on server doesn't.
Persistence is automatic as the applications are actually run on server, not on the client. As far as the application is concern, the client PC is just a "screen".
This is probably better than 3) above for smaller, lighter client memory/cpu-challenged machines which can't handle application load - e.g. a set-top box type of client.
Now, for this, while the client component can definitely be puppy, I'm not sure whether we can use puppy for the server - I think because the server will require full multi-user capability.
None of the above a new - people have been doing this for many years (I think LTSP may employ some or all of the above, or even scenarios I haven't though of) - but the idea here is how to apply that to puppy. Of course, it may be easier instead just to go to LTSP and use it - but hey, what's the challenge ?
Anyone?