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.

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 ?

Initially my idea for the networked files feature came from when Barry was testing different sfs naming possibilities - at the point where we were adding distinct strings to the end of files that then had to be truncated and compared as they were recursively found, I _knew_ we needed something simpler.
REF: http://bkhome.org/blog/?viewDetailed=01807
I thought, "Why not just have the installer pass on the location to the grub entry?" I did a quick hack to the init that worked well (still needed to do minimal search for usb), but then I thought "Why does it even have to be a local file ... or even a file for that matter?"
_anything_ in the grub entry can be parsed for use via "cat /proc/cmdline"
Some of the possibilities could be:
Samba, nfs, dropbear, http, ftp,... pretty much anything you can cram in the initrd, however I am limited to a single laptop for the time being, so I never went any further with it.

btw a new version of dropbear was just released after a long wait (it may be a good candidate for both client and server on puppy ... and a lot lighter than a full LTSP setup)_________________Web Programming - Pet Packaging 100 & 101

The most difficult thing, I think, is to setup the network card. Right now all the code (hotplugging, network card drivers, firmware, rc.network etc) are all in pup.sfs. DHCP isn't an issue I think, busybox has it, ipconfig from klibc also has it - it's more on the driver issue (in my previous experiment I cheated and compiled the specific driver for my network card into kernel). Doubly complicated if one wants to boot over wireless
Once the early network is up - like you say, we can do anything - most of the network fs is small enough to go to initrd.
Another thing to consider: where to do the union (on server side or on client side). If it's done one the server side, it's transparent to the client - as far as the client PC is concerned, it's like running full install. However, not all of the network fs supports r/w --- I think httpfs only support readonly, where in this case we have to the union on the client PC.

BTW - I do all my test on a single machine too. I use VirtualBox to boot my "client" OS, with my host OS as the "server".

Aitch, eyeos is a web-based OS - I think technosaurus has done something like it, with his Puppy WebOS (see his sig). The mode of access is probably more like Point 4 in my original post, though one probably needs a more powerful box to do it.
Stunnel isn't relevant for this discussion - it provides encryption capability over internet protocols that usually don't have it._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread

2 questions for comments
1. What happens when Puppy become multi-user to an effort like this?
2. Why not force a save session onto the user via a CDRW or his own USB?
Would like to hear comments on this.

On a completely separate note, the following, below, reduces this discussion to something very very very simple (if not eliminating it, altogether).
Now here's something that most Puppyites do not think about. Multi-User Multi-desktop session system(s), you know, one server system that does both. The power of today's PC have made this viable in a PC based platform for over 15 years. If you haven't seen or ever used one, let me know, and if I can do it without violating a licencing. I will give you access to one of the 3 I have running.for your evaluation.

THIS IS NOT VIRTUAL MACHINES (a different topic). This is terminal serving. The original Terminal Server was telnet (well original to most of us), because the server served character text screen data to terminals. This was followed by Citrix serving WYSIWIG screens to PCs. Today, in its proper use, it means "serving screens" to a terminal or program/device emulating some terminal. The work is done on the server and terminal show the work requested by the user.

In a terminal server(TS) environment, the TS allows many users to login and get "their" desktop. They work as if they are the ONLY person on that machine. They use ALL desktop services individually and simultaneous with all tasks that they open. And when they logout. Their session is available for the next time they reboot.

Novell has done this in IBM OS2, Microsoft transferred that Technology when they purchased the rights, and as I remember RedHat/Ubuntu/Fedora has similar working implementation which provide administrators (us; you and I) the ability to make this happen for users on our LANs and WANs. I, personally, have been implementing the PC versions of this for 14 years. It works, It reduces costs. It reduces my having to visit each and every machine to fix any local problems. It is used in EVERY Forture 1000 in the world, today.

All we have to do is think about how we could make FATDOG or Puppy provide desktops on login to users. (I mention FATDOG ONLY because any PC that is 64bit has at least 1GB+ memory, so we wont have anyone complaining about RAM in this discussion.)

So I guess I just dropped 2 questions as well as 1 item on this table.

Hope this helps

Edited - 03/12/11 - Reason: I said Novell and I meant Citrix. Sorry for any confusion. To clarify, Citrix brought 2 significant things to the tele-commuter table.
1. ability to connect remote users to a WYSIWYG PC/Server
2. a compression transport protocol to collapse-restore WYSIWYG over low-grade connections (dial-up 9.6Kb+) called ICA._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPileLast edited by gcmartin on Sat 12 Mar 2011, 12:48; edited 2 times in total

I thought through what it would take for a minimal terminal server/client:
Server:

desktop environment
Webm encoder to stream desktop and sound over udp
xdokey daemon to listen for keyboard and mouse events

Client:

Webm player
Keylogger to send mouse and keyboard events to the server's xdokey daemon.

Ffmpeg can do the encoding. Mplayer for decoding ... even from console.
Compile with only required codecs and support for hardware acceleration.

You could optionally add sound and video the other direction too.
The encoding format is a variable that depends on hardware encoding/decoding support - Webm is a good choice if no hardware codec support, since it only does deltas it will minimize bandwidth on a typical desktop where a terminal is typically used.

one problem with X is that it doesn't control sound, so applications typically access hardware directly or via a library that does so. This makes it difficult to serve sound to multiple clients without all of them getting all of the sound, so other complex libraries have been developed with this in mind, but with a union type file system this is not necessary because each user can have symlinks for /dev/audio /dev/dsp... that redirect audio events to a user specific one

However the use case for a terminal server is different than what is desired here.
It takes a lot less server load to just host the files, and the desktop is more responsive... basically a "fat client". Since puppy's apps are already pretty light, the client load would not be drastically higher and if set up correctly even thin clients could run this way... increasing the possible number of clients drastically._________________Web Programming - Pet Packaging 100 & 101

@technosaurus.
Terminal Server discussion (this is not the place,but I just want to bring an alternative view. It probably something that you or one of the other veteran should start and the remainder of us to contribute where we can.)

But, on that subject, I see your and some good ideas. And the discussion of FAT client and Thin client is NOT what businesses running terminal server use. What they employ is a standard desktop for every user. Via the authority levels set for the users which determine access to data, files, folders browser directions and applications. In the Microsoft world I don't worry or care about the PC on the other end of my Server community The protocol coming from the client is standardized, tell me what hardware he has, why his PC ID is and everything I need to know about what hardware his client tells. At the server end, my OS "integrates" that into the system and the user session. So

if he has sound, I drive sound into his session,

if he has a BIG video, I drive that into his session,

if he has USB devices, I drive that into his session;

if he has a Printer "ANYWHERE" that he has local access, I drive that into his session.

(None of this driving is manual, its build into the RDP protocol registered international standard). This is NOT done via pieces and parts; its done via protocol and integration into the desktop session. Under Novell, it was driving 25 dial-up users simultaneously using their desktop for everything from customer communication to proposal making. with LAN desktop equivalent performance. This means that when you move the mouse on your dial-up session, it moved EXACTLY as fast as it does on the LAN. You cannot tell that you are NOT on a local machine. Instanteous over a LAN/WAN/dial-up.

Your discussion on performance and drain has been debated for over 30 years. Capacity Planning charges that I have done done support your argument because everyone is working (or not) at differing times and speeds. Today's machines are more than adequate horsepower for the things I see in discussion here. Think about this.What do desktop users do in your community. move the mouse click a web-page, read; what does the computer do mouse (yawn...that hardware), click (OK past that off to the internet..Yawn, wait, wait, yawn) Internet respond (refresh screen are paste into user screen and take a nap!) Wow, but that didn't ever take 1 sec of CPU time....whew! I take a nap until some thing else happens.

That the issue. How many people that do this do you think I can support? Why should I care if they have a FAT client, THIN client, IBM Unix termineal, etc. all the work is controlled tracked and monitored by the TS. That user is mine and I insure he gets service. User using 486s they running 8 core server as if the 486 is an 8-core. If fact the one 486 user I have rather user a TS than his local machine for the simple performance.

Anyway, to reprecate something like this in a Linux (FATDOG/Puppy) just needs some thinking about not Thin/Thick clients, but how to implement the information provided by the protocol such that you can drive WYSIWIG screens and ports into a desktop; this is something that the XRDP project has been wrestling with for 3 years now. I think we should tap their shoulder and ask some obvious questions. I have already and they just need resource coordination. That doesn't seem to be problem here.

VNC gave up years ago. X said they would but got lost. Window Managers fragmented the talent pool. So Linux needs some a good solution for this.

Think it can be done now? (Before you answer look at XRDP and if you've never seen a terminal server PM me.)

P.S. Someone open a TS in Puppy discussion. This MAY not be what JamesBond wanted us to discuss here._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

its specific debian but can boot custom kernel, i guess it can boot puppy if we setup properly.

IBS seems to be just a script to help setting up the environments for PXE/NFS booting. We already have the PXE part. The NFS part is relatively easy, and we have much better option that IBS, which says (quoted from its website)

Quote:

The ibs script installs only a single NFS root environment when it is run for the nfs boot method. If you are going to boot more than one client off an NFS root, you will either need some tool (e.g. a shell script) which prepares the single NFS root system for a particular client before booting it, or you will have to set up a separate NFS root environment for each client, for example by copying the standard NFS root system recursively. In the latter case, each addidional NFS root environment will add about 250 MB.

Adding 250MB per client is not in Puppy's tradition

gcmartin wrote:

2 questions for comments
1. What happens when Puppy become multi-user to an effort like this?
2. Why not force a save session onto the user via a CDRW or his own USB?

1. It takes serious effort to make Puppy to become a true multi-user, this has been discussed many times before, the recent one is in the link I posted at the first post.
2. That's what I pointed above (see item 1 in original post) - session can be saved into a thumbdrive. But it makes roaming more difficult - lose the thumbdrive, lose your personal information.

technosaurus wrote:

I thought through what it would take for a minimal terminal server/client:
Server:

desktop environment
Webm encoder to stream desktop and sound over udp
xdokey daemon to listen for keyboard and mouse events

Client:

Webm player
Keylogger to send mouse and keyboard events to the server's xdokey daemon.

I'm a bit lost here. We still have full X capability on the client, do we? If yes, then I'm a bit lost here - I mean, I don't see why we need this. Keylogging and (I don't know much about xdokey, so I'll assume) xdokey is what xvnc/vnc does, no? Or how about starting a new X and run it under some kind of connection - either direct X protocol or tunnelled inside ssh?

Quote:

Ffmpeg can do the encoding. Mplayer for decoding ... even from console.
Compile with only required codecs and support for hardware acceleration.

You could optionally add sound and video the other direction too.
The encoding format is a variable that depends on hardware encoding/decoding support - Webm is a good choice if no hardware codec support, since it only does deltas it will minimize bandwidth on a typical desktop where a terminal is typically used.

I presume this is to minimise bandwidth consumption, because otherwise we can probably go with PulseAudio as below. It would be interesting if we can embed ffmpeg / mplayer inside PulseAudio so that sound transferred over the network is transparently compressed

Quote:

one problem with X is that it doesn't control sound, so applications typically access hardware directly or via a library that does so. This makes it difficult to serve sound to multiple clients without all of them getting all of the sound, so other complex libraries have been developed with this in mind, but with a union type file system this is not necessary because each user can have symlinks for /dev/audio /dev/dsp... that redirect audio events to a user specific one

I think this is the problem that PulseAudio (and earlier ESD, and Arts etc) is supposed to solve. All audio applications needs to be compiled with sound server library, then during execution, all we need to do is set the SOUND environment to direct the sound where to go (just like DISPLAY variable directs where the X protocol output will go...).

Quote:

However the use case for a terminal server is different than what is desired here.
It takes a lot less server load to just host the files, and the desktop is more responsive... basically a "fat client". Since puppy's apps are already pretty light, the client load would not be drastically higher and if set up correctly even thin clients could run this way... increasing the possible number of clients drastically.

Yes, agreed, and in addition, definitely, and at this stage, "terminal server" (basically point 4 in my original post) is the most difficult to achieve in Puppy because Puppy *is not* a multi-user OS.

Quote:

Before you answer look at XRDP

I looked into it last year. It looked interesting and promising - though development activity was low. From my point of view, using xrdp is equivalent of using xvnc (not x11vnc, but the real xvnc). Or direct X session for that matter.

Quote:

This MAY not be what JamesBond wanted us to discuss here.

No, that's all right. Everything is game. Of course the point is what we can achieve by using puppy (hopefully both on the server and client end) - and it doesn't have to be invented here either - if there are working solutions from others, we should all be happy if we can adapt it to work in puppy.
We may want to draw the line on connectivity, though - I'd probably prefer to keep the context of LAN connection. When we cross into WAN (or dial-up) - a lot of the variables change, and there are a lot more to re-think._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread

Then I used BrowserLinux (puppy based), to be able to PXE boot any of my computers, with a secure (doesn't store anything back to the important directories on my server) full browser capable (Moonlight and Flashplayer added) internet session.

Now I would like to be able to do the following (similar to what I think this thread is about).

During boot, after HW detection etc..

Prompt user for a login:

This would login to the full fledged server, not changing puppy from running as root.

I looked into it last year. It looked interesting and promising - though development activity was low. From my point of view, using xrdp is equivalent of using xvnc (not x11vnc, but the real xvnc). Or direct X session for that matter. ...

Got a response from the author several weeks ago. Seems the project may have gotten new life. We could be a test-bed in FATDOG/Puppyland.

Hope this helps_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

Can we make client do 'virtual install' at first booting, then server make a special folder for that client (with special port)? I think, an 'auto-remastering'.
In the next boot, client is registered at pxe boot with machine ID, and boot a specific remastering puppy.
Of course, the server must able to give multiple nfs. Can we?
Sorry, if bothering.

P.S. Someone open a TS in Puppy discussion. This MAY not be what JamesBond wanted us to discuss here

I think you should be the one to start that thread

I understand, I think, what you are saying, and I've been thinking Puppy should have its own TS server setup that even noobies could use, and log into

I was advocating PXE boot capability ever since I witnessed a full debian install via PXE....I thought, 'Wow, a machine with no CD and only a modem, can be used for linux installs....[I didn't know it was possible]

With the 'big push' for cloud computing, I can't help but feel that 'we' would be handing over power to whomsoever holds the server....which is why I think a Puppy ibiblio TS server and/or PXE Puppy installer should be a target, within our grasp

You are "right-on" about all 3 points you indicate.
But, to do that in Puppy, I suggest we first look at Edubuntu. It has a running classroom built-in where NO PCs require anything except PXE on its motherboard. We setup all PCs with 100Watt (cant find 75Watt anymore) power supplies and a DVD drive. Every child's PC boots from the server and all personal assignments and work is saved in his home folder under his ID. Very polished, easy to maintain, no brainer to use. Most Kids believe their stuff is on their PCs. Central Backups provide all safety needed. Kids info is under their ID and is carried from school-year to school-year because their ID never changes. Next year improvements are planned in providing a "Local" cloud. Looking, again, at Ubuntu's implementation.

For observation, you could do this yourself. Beware, once you start, you'll get hooked!

Hope this helps._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

LTSP on Puppy?
I love it if someone go to puppy ncomputing discussion.

I love this on wikki
:

Quote:

Linux Terminal Server Project (LTSP) is a free and open source software for Linux that allows many people to simultaneously use the same computer. Applications run on the server with a terminal known as a thin client (also known as an X terminal) handling input and output. Generally, terminals are low-powered, lack a hard disk and are quieter than desktop computers because they do not have any moving parts.
On the LTSP server a chroot environment is set up with a minimal Linux operating system and X environment.

When a client[2] boots[3] from a local boot device (like a harddisk, CD-ROM or USB disk), it loads a small Linux kernel from that device which initializes the system and all of the peripherals that it recognizes. When configured for network booting (with mechanisms like Etherboot, Preboot Execution Environment (PXE) or NetBoot) the client first requests its own IP address and the IP address for the LTSP server via DHCP and loads the Linux kernel from a preconfigured Linux image on the LTSP server via the Trivial File Transfer Protocol (TFTP) service running on the LTSP server.

During this process the client makes a (new) DHCP request for the IP address of the LTSP server and the path to its chroot environment. When this information is retrieved, the client mounts the path on its root filesystem via either the Network File System (NFS) or Network Block Device (NBD) services running on the LTSP server.

The client loads Linux from the NFS mounted root filesystem (or NBD filesystem image) and starts the X windowing system. The client connects to the XDMCP login manager on the LTSP server. In case of the newer MueKow (LTSP 5) setup, the client first builds an SSH tunnel to the LTSP server's X environment, through which it will start the LDM login manager (on the LTSP server). From this point forward, all programs are started on the LTSP server, but displayed and operated from the client.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum