Remote Desktop for Puppy?

[Grogster]

Oh damn.

I did not pay enough attention to your instructions. I thought the fix was for FB64.
I clearly see(now!) you stated the fix was for FB32, sorry.

My mistake.

[Grogster]

UPDATE:

FB32, made the change, can talk to the FB32 setup using BOTH the x11vnc server and TigerVNC on the W10 box, and can also access the shared ext4 hard-drive too.

Fan-diddly-tastic, as Ned Flanders would say.

I note that in FB32, if I set guest ok = no as a little experiment, the W10 box refuses to see the Puppy box at all, but with the guest ok = yes as instructed, then W10 prompts me for the username and P/W for this box - this is EXACTLY what I want and need, so this is 100% perfect for my needs at this point.

The "guest ok" thing is confusing to me though. This suggests that guests can access the server without needing a password.
I would have thought that guest ok = no, would force you to logon to the server with a P/W, but it actually seems to totally block you from any access at all.

Can someone in the know, define what a guest actually is with respect to Linux and SAMBA?
To me, a guest is someone who has full and free access to any share, so long as they can find it.
I am simply not understanding the Linux SAMBA terminology correctly, so would love clarification.

On ALL my Puppy boxes, I open a terminal and use passwd root to change the Puppy default password, and then smbpasswd -a root to change the SAMBA password. This always seems to work fine, but please do let me know if I am not really changing the passwords in the correct way.

[wizard]

@Grogster

Guest is someone that does not have a user account on the host server, but they still have to enter credentials.

You do a good job on your feedback.

Thanks
wizard

[rcrsn51]

The option "guest ok = yes" is a leftover from early versions of Samba that did not worry about security. You should delete it from your smb.conf.

Here is the correct procedure:

1. Create a LInux user named "guest" with password "guest". It would not need a home directory.

2. Create a matching Samba user with: smbpasswd -a guest.

3. When a Samba client connects to the server, they would need to login as "guest". They would only get the permissions owned by the Linux "guest" user.

[wizard]

@Grogster

The samba shares failure with Friendly-Fossa64 rc3 (based on fossapup64 9.5) is a quirk in the standard remaster script that doesn't create these two samba directories required for samba to start:
/var/log/samba
/var/run/samba

This issue may also affect remasters of Bionic64 8.0 @666philb may want to be aware of this.

Here is a fix for Friendly-Fossa64 rc3. Just download the .pet and install with Rox, it creates the directories and also puts a script in /root/Startup to start samba on boot. Also does the samba.sh mod (noted above for FB32)

samba-fix.pet

(3.63 KiB) Downloaded 44 times

Let me know if you try it.

The issue will be corrected in the next release of FF64.

Thanks
wizard

[Grogster]

@ wizard: Installed the PET, that went fine - big green tick saying install was successful. Start SSM, click APPLY, get error message - see attached image and log file.

I've noted that FB64 is considerably slower to open windows in general. It is much sexier looking then FB32, and I love the system stats thing on the desktop at the right, but FB32 is much faster. FB64 window open delay is anything up to about 15 seconds from when you open something, FB32 is pretty much instant, as you would expect, as Puppy runs entirely in RAM, so not sure what is going on there with the delays with FB64.

Anyhoo, have a look at the image and log, and if I can help further by trying something else, let me know. I have about three different USB sticks all running different configurations, so I can just swap to the FB64 one to test anything if you need me to.

EDIT: Ignore. Forgot to do a feckin' reboot. After a reboot, there are no errors reported, and I can turn the daemon off and on at will now no problems.

[wizard]

@Grogster

wizards rule #3 "Rebooting is magic"

You might also be interested in this "howto" viewtopic.php?t=2124 on password protecting file shares.

wizard

[user1111]

May have already been mentioned, but just in case ... VirtualGL ....

viewtopic.php?p=33236#p33236

for remote desktop on a local LAN system works incredibly well.

[Grogster]

@ wizard - just tried FB64 rc4, and it is very nice indeed, and everything works well. Only ONE problem I have found, is that when I setup my Puppy servers, I only set a 32MB savefile - there is no need for anything bigger, as all I need to save, is the config settings etc, so you don't NEED much space for that.

With 32MB, Puppy was moaning that I only had about 21MB free after setup, so I allowed it to resize that to 64MB.(right-click drive icon in tray, select resize personal storage file)
This completed fine.

But after you do this, THIS is when you now get prompted EVERY SHUTDOWN, if you want to save or not save the RAM to the pupsave file, when during "Normal" shutdown or reboot, the RAM is saved to the pupsave file automatically as part of the process.
This DOES NOT happen, when you choose a size for the first time you shutdown on a clean-install to a USB, and choose a savefile size, this only starts popping up IF you resize the pupsave file after the first boot on the 'Install' USB flash drive.

See attached image - I have posted it before, but just to refresh your memory as to what I see.

Again, if I set a 64MB pupsave file as part of the first shutdown after installing FB64 to a USB stick, I DON'T get this, but if I resize the pupsave file, then I do.

Hopefully, that makes some kind of sense.

I will simply do a clean-install to a reformatted USB stick, and select 64MB, which will be more then enough for me, but it might cause hiccups for others if they download and install PET's etc and need to resize their pupsave file.

[Grogster]

UPDATE:

I have been playing around tonight with various sizes of pupsave file, and it would appear to ALWAYS happen on the 'Clean-install' on the USB flash-drive, no matter what savefile size you choose.

Have been working my way up from 32MB, with a completely clean-install to the USB flash-drive each time, and am up to 256MB savefile now, and on the 2nd reboot, it always prompts with the 'DOS screen' to save.

Hopefully, that will give you additional information to work with.

[wizard]

@Grogster

First, don't understand why you want such a small save file as that is inviting problems.

The shutdown message you show is normal for a USB install. Puppy normally runs in mode 13 on a USB which means it does not save automatically, this is to prolong the life of the USB which has limited write/save/erase cycles before failure.

Thanks
wizard

[mikeslr]

@Grogster regarding operating with a 'small' SaveFile, see my post here, viewtopic.php?p=43296&sid=7918013049fdd ... 3b8#p43296. You can probably skip down to the part beginning with BUT DO NOT EXECUTE A SAVE.

You should also know about amethyst's "nicOS-Utility-Suite", https://www.forum.puppylinux.com/viewto ... 983#p12983. Using it's Save2SFS module, you can download packages, restart-x, and create either an adrv.sfs or a ydrv.sfs which will 'capture' that package and the contents of your current SaveFile/Folder (and optionally any existing adrv.sfs or ydrv.sfs). The same module can be used later to 'capture' further additions. Actually, you can employ the Save2SFS module to avoid having to use any SaveFile/Folder at all.

[Grogster]

Hi there.

@ wizard: it isn't standard for any of the other puppies I have seen and worked with INCLUDING old Slacko64, the newer Bionic64 puppies I have used, nor is it standard in the FB32 distro either. This only happens on the FB64 one. I never get prompted by the 'DOS screen' to save the session on shutdown or reboot, it does it automatically as PART of the shutdown or reboot process, so long as you have setup a pupsave file.

Note that I am talking about when you either reboot or shutdown, NOT just while running Puppy normally. I totally agree that autosaving periodically is not what you want to do while Puppy is running, as - as you point out - this will wear out the flash drive. There is the SAVE icon you can click on the desktop if you want to save any changes you've made while still on the desktop, but I'm talking about this screen showing up asking to save to the savefile as PART of the shutdown or reboot process, thus delaying the shutdown by a further 60 seconds if you don't choose one or the other option, which all the other puppies DON'T do, including FB32 - they just automatically save the session as part of the shutdown or reboot.

IE: On all the other puppies, assuming a pupsave file exists that you have setup before, when you shutdown or reboot, one of the lines of text you get on the screen after the desktop has been closed, and Puppy is doing it's shutdown procedure, is a line that says: "Saving current session to pupsave file....". Not verbatim I don't think, but a line that reads very much like that. The point being that it IS one of the steps the shutdown/reboot procedure does, and it is fully automatic - you are never asked about doing it, Puppy just does it automatically. This is not the case in FB64, it stops as part of the shutdown/reboot procedure, to flash this screen at me and ask if I want to save it or not.

Hopefully you can see what I am getting at now.

@ mikeslr: thanks for the links, I will check them out.

Oh, and on the tiny savefile size before I forget, I am partly just playing around, but partly also of the mindset that you should not NEED a big pupsave file, if you are not going to install any extra software, and all you really need it for, is to save the configuration settings for the server. Passwords, SAMBA settings, users, IP address - stuff like that. You should not need much room just to save those things. These puppies never get used on-line, and never have any new software added to them, so that was the logic behind the small savefile size, but with flash-drives being so huge now, 16GB ones are the common SMALLEST CAPACITY you can buy new now, so it's not like it's an issue for me to use a bigger size. I find the 256MB one seems to work well and I get no complaints from Puppy about pupsave filesize if I use that, so I will.

[wizard]

@Grogster

OK, I think what you're seeing is the default behavior setup by 666philb. In any case if it bothers you try this:
Menu>System>Puppy Event Manager>Save Session
-uncheck: if unticked

Thanks
wizard

[mikeslr]

It's not just the default behavior setup by 666philb. It's how Puppys work. See https://www.forum.puppylinux.com/viewto ... 827#p55827: "If the boot is considered to be from a "flash" device, the directory containing the save layer
is inserted as a read-only layer immediately below the read-write layer."
Layman's explanation: If you are booting from a hard-drive, changes are written immediately to the hard-drive. If you are booting from a flash device, changes are written to the read-write layer which is in RAM. On exit from a flash device you will be offered the opportunity to Save what is in the 'read-write' layer in RAM to the Read-only layer on your storage media. The 'Save - No Save' GUI appears. Save is highlighted so that you can immediately press the Return/Enter Key to Save. But the default routine is 'No Save'. Do nothing and the system will shut down in 60 seconds without Saving*.

You can configure a Puppy located on a hard-drive into behaving as if it were a 'flash' device --why flash was placed in quotes. Edit or add the boot parameter to read pmedia=ataflash. But AFAIK, there's no way to configure a Puppy on a 'flash' device into working as if it were on a hard-drive. [Well, maybe you can trick your computer into treating a flash device as a hard-drive by some special way of formatting the flash device].

-=-=-=-
* If you've booted from an actual flash drive -- not a hard-drive identified as a flash drive by the pmedia=ataflash argument-- you don't have to wait 60 seconds. You can immediately unplug the flash drive. Errors will be reported on your monitor. But those errors aren't being Saved as the Save media is neither being written to nor present.

[Grogster]

I hear what you are saying, but this is simply NOT happening for me - the save/no save gui on all other puppies I have used - I NEVER get prompted to do it, it ALWAYS happens automatically - when booting and running from USB flash, during shutdown or reboot.

Slacko64 did it, but I am not sure I still have any of those running - I will check.
Bionic64 definitely does, FB32 does.

I will make a couple of short videos and upload links to prove what I am saying.

[mikeslr]

Definitely odd, then.

May I suggest that you open a new thread specifically about that issue. There's a reason for the Forum's general rule of thumb "One problem, one thread". It's hard to keep track of what we know and we've tried when a thread discusses multiple issues.

Has what you've been experiencing only involved one 'flash-drive'? or does it occur with more than one?
What exactly are your computer's specs?
Exactly what did you do to create the frugal installs on the flash-drive(s)?

Scanning thru this thread I see that at some point you used rufus. Did you use the technique spelled out here? https://www.forum.puppylinux.com/viewto ... 522#p40522; i.e., have rufus create a 'persistent' partition?

[Grogster]

Good idea, I will start a new thread and detail it all there, including how I setup the flash-drives, but I just use the standard installer.

[vtpup]

Just found this thread after struggling to get XRDP working on BP64 in the Multimedia section of the forum.

At this point I've nearly given up on XRDP and am thinking about alternatives. My desire is for a high speed graphics oriented server to do video editing, but accessible from my old, less capable laptop.

I very much like the approaches user1111 has talked about here, and Wiak's solutions, too.

If I just can't get acceptable low lag and audio performance via XRDP or VNC for a remote desktop through the laptop, I was thinking about user1111's "out of the box" thinking for use of multiple independent connections for different functions.

Since wireless HDMI is possible now, I guess it would be possible to just get server video and audio through a wireless monitor anywhere in the house. And likewise a bluetooth keyboard with trackpad or mouse would provide server inputs.

Or if a laptop was providing a virtual desktop via vnc but simply lacked low- lag audio, Maybe it would be possible to add a bluetooth speaker or headphone to the server. This is all of course for an in-house setup, not for accessing the server via WAN or at long distance from the house.

Anyway, these are just alternatives I'm thinking about for my own particular needs.

[wizard]

@vtpup

As an experiment, try @mikewalsh Anydesk portable. With your lan speed and running both computers on the same subnet it should have very low latency and high frame rates. Easy to setup and use, might just work for your needs.

wizard

[vtpup]

Hi wizard, thanks. Not familiar with it, but assumed it had to be running on both computers (Bionic64s). Downloaded the .pet and ran it on both.

Temporarily dropped the firewalls.

First computer had a "This Desk" number of 0
Second computer had a "This Desk" number composed of 3 three digit numbers, like 123 456 789.

On the first computer I entered in "Remote Desk" the 9 digit number of the second computer and hit connect.

Got just an error message: "AnyDesk Not Connected. Anydesk is not connected to the server. Please check your Internet connection."

[ndujoe2]

I commend for you use Mike Walsh's portable version of Anydesk.

It works will in my system and you can setup a remote password for unattended access as well.

https://www.forum.puppylinux.com/viewtopic.php?t=1104

[wizard]

@vtpup

First computer had a "This Desk" number of 0

Something not right on that computer, should show 9 digit number. Try downloading the tar.xz version, unpack and just run the launcher (apprun).

wizard

[Clarity]

A test for ALL Remote Desktop users:

• When connected to a remote server with your client

  • Does Youtube on the remote run without video stutter on your client desktop?

  • Can you hear the sound that is played in the Youtube on your client PC?

Audio is one difference between a "Remote Display" (ie VNC) versus Remote Desktop.

So I ask:

• Who has Remote Desktop SESSIONS working on your home's LAN?

• Which distro are you running?

• Which product are you using that allow such?

Curious

[vtpup]

@vtpup

First computer had a "This Desk" number of 0

Something not right on that computer, should show 9 digit number. Try downloading the tar.xz version, unpack and just run the launcher (apprun).

wizard

Hi Wizard, I believe I was using an older .pet than current (4.x vs 6.x). When I found the later version and downloaded it, I was able to connect easily. Not only that but the speed and quality of the connection were really impressive! In fact I ran kdenlive on the host computer, and loaded a complex project. It rendered in the Kdenlive monitor, as transmitted to the client, at very close to the same quality it displayed on the host. Very little, to no, frame lag.

Because I could see both screens, I could tell that it was running perfectly on the host and the very occasional slight jitter was only on the client screen. This is with a slow set of wireless cards at 802.11n speeds (checked, it was 121 mbs actual to the router).

I'm very encouraged by this! There was no sound, though there was sound output on the host's earphone jack. A simple local workaround for that would be a set of bluetooth headphones, receiving from the host

[wizard]

@vtpup

Progress at last! Hadn't thought of the headphone idea, good show.

wizard

[vtpup]

Wizard, also, this is with the host being a 10+ year old low-end laptop (admittedly, I re-proced it with an i5-2450M and 8 gigs RAM). And client is a now old Acer C720 Chromebook, converted to run Bionic64.

BUT.....the new MSI B450 Tomahawk MAX II motherboard has arrived, and I've got it installed in my old desktop case with the new power supply and 2TB drive. The Ryzen gen 3 processor, and memory to fit, should arrive in a couple days.

The desktop is cable connected to the router, so I'm really curious to see how Kdenlive and other editors run on that rig, with anydesk sending to the laptop as client.

[wizard]

You'll see the most difference on processor intensive programs like Kdenlive, etc. that can use more cores. The most demanding things I do are Puppy remastering and video format conversion.

Many new laptops have far less power than your I5-2450. For most of the common task that people do, a dual core, 4gb computer works just fine. In the end computing power is a game of diminishing returns, i.e., If a dual core does a task in 1 second and a 8 core does it in 1/4 of a second, few people will care.

For your video processing the new machine should be a rocket

Keep us informed.

wizard

[mikewalsh]

@vtpup :-

Mm. Looks like we're making progress. Nice one.

With regard to older versions of AnyDesk, you generally find that any company that creates 'net-facing applications of any sort will tend to deprecate older versions pretty rapidly, as various security weaknesses are found & addressed. Hence, why you were having issues with a 4-series build.

I've been packaging them for a while, despite that I don't in fact have anything I can test them on; the anciente Dell lappie is SO old, and so slow, it takes it all its time to run - bless it! - never mind trying to run a remote-desktop app on top of everything else. And since it's 32-bit only, it can no longer run the current release....AnyDesk having taken the same route as everyone else, and switched to 64-bit only.

I'm not dissing our Puppy devs in any way, but since most 32-bit Puppies have issues with web-browsers now, and very few companies even provide 32-bit builds any more, I have to wonder why anyone still wants to use a purely 32-bit machine these days.......unless they intend to use it largely offline for specific use-cases.

(*shrug*)

Mike.

[vtpup]

Thanks Mike, wizard.

Wizard, the single biggest need for speed I find is in one specific aspect of video editing. That is the so-called Monitor screen. The purpose of the Monitor is to play back the video that you've laid out on the multiple tracks, with all of the transitions and effects in place. This feature is constantly called upon in the editing process in order to see what any changes will look like. It is, in effect, real time rendering. And the more tracks, the more effects, and the higher the resolution of the clips, then the more processor intensive it gets.

In playing back what you've composed, there can't be any jitters or blanks or sound anomalies, because you won't be able to tell if these are actually part of the track contents, or just a playback glitch or slowdown. The first will affect the final video, but the second won't. Since you don't know which it is, you don't know if the final video will be flawed. And rendering to final video is a very time consuming process, just to find out which it is. So you need the highest possible performance in the computer to ensure that whatever anomalies you see are part of the actual track contents, rather than just an overloaded proc.

My laptop with the i5-2450M can just barely manage to do complex editing in Kdenlive at 720p and render on the fly smoothly to the Monitor. Of course it is using no special graphics card in this old laptop. If I go higher in resolution, it will start to lose frames in the monitor and audio. So that's why the desire to move over to editing on a gamer level high power desktop, linked to the laptop.

While it's true that final video rendering speeds are not a critical need -- just a convenience, as you mention. But real-time rendering to a video editing "monitor" screen while composing is critical. Like gaming, the computer has to do everything between frames. You can't wait for it to render overnight, as you can with the final video.