How I tried RDP in FatDog

[fatdoguser]

Received a pm in part about xrdp. Hadn't tried that so in a disposable session (no changes saved) I ran ...

Fatdog gslapt and selected/installed ...

Code: Select all

xorg-xrdp
xrdp

(I got some warnings, but just ignored those)

In terminal run

Code: Select all

vncserver :10

and enter a password 111111
(six or more characters)
once started, kill that

Code: Select all

vncserver -kill :10

in ~/.vnc edit xstartup file to contain just

Code: Select all

jwm

I did the same also for ~/.xsession

restart that vncserver again

Code: Select all

vncserver :10

In a terminal start xrdp ...

Code: Select all

xrdp

Fatdog .. Menu, Network, Terminal Server Client, and enter ...

Computer : localhost
Protocol : RDPv5
username : root
... leave the rest empty and click connect

At the login screen select ...
Session : vnc-any
IP: localhost
port: 5910 (i.e. 5900 vnc base port plus the :10 display we used above)
password 111111 (or as above for whatever you set the vncserver password to)

... and I see a desktop with a window with a jwm tray

Worked, but I think it messes up Fatdog doing it that way, so make sure you backup your main system or use a disposable session.

I've heard that rdp can also convey sound, didn't venture into that as Fatdog now has tx/rx (in control panel sound configuration set up a loop and use the control panel to direct sound Computer -> Network or other preferred choice).

A crude basic quick test. How do others setup/use their XRDP? Of particular interest for me would be setups where both audio/video were conveyed in sync/together?

PS for Xorg method just additionally start

Code: Select all

xrdp-sesman

as well as xrdp. When you run the terminal server select Xorg and enter root for the userid and woofwoof (whatever) for the password, and you drop straight into a full Fatdog session. Nicer (higher resolution) than tigervnc viewer/server, but more blocky for larger window size youtubes. I know little about rdp but tigervnc dynamically scales up/down the image quality in reflection of the data throughput rate so you end up with a smoother video, but lower resolution quality on slower links.

[fatdoguser]

Straight vnc is the easier/better choice IMO

On your desktop system run

Code: Select all

vncserver :20 -localhost=no -SecurityTypes none &

As its the first time vncserver is run, that sets up ~/.vnc folder contents, immediately kill that

Code: Select all

vncserver -kill :20

and edit the contents of ~/.vnc/xstartup to something more useful

Code: Select all

cd .vnc
cp /etc/X11/xinitrc xstartup

and then restart it again

Code: Select all

vncserver :20 -localhost=no -SecurityTypes none &

Identify your desktops IP, from ifconfig for instance, maybe 192.168.1.5

and connect to that from your laptop

Code: Select all

vncviewer 192.168.1.5:5920

(vnc ports start at 5900, so as we started a server on :20 that binds to port 5920)

Most OS's/devices have a means to install/use a vnc viewer.

The above will run a separate session to the main desktop boxes session, but the desktop sound will pick up on any sound played in the vnc session, so if you're using that to view a youtube for instance then anyone using the desktop system at the time will hear the sound from that youtube. You have to forward sound separately.

The above assumes firewalls are turned off/disabled, and isn't secure at all, so only run that on a secure local LAN.

If you set up another vncserver session, on :21 for instance, and you also vncviewer into that, then you can 'communicate' between the two. The connection on 5921 (display :21) can for example start a galculator on display :20

DISPLAY=:20 galculator

or trigger a xmessage

DISPLAY=:20 xmessage hi

As can :20 do the same

DISPLAY=:21 xmessage "go away I'm busy"

Or even run things like Menu, Network, Back Seat Driver

A benefit is that multiple lower powered devices only need to be able to net connect and run vncserver in order to have interactions/web-browsing experience at the desktops (likely ethernet hard wired) speed. And are in themselves secure, just a vnc session as possible hacker attack surface. Your devices files are very secure, even if the connecting device is running a old insecure OS/Puppy/Fatdog. And that simplifies updates such as to Chrome as you only have to update the one version (desktop). I tend to download the latest chrome .deb file, extract that, and replace the existing /opt/google/chrome folder with the chrome folder in the extracted latest version, typically a few minutes task,

[fatdoguser]

Edit /etc/ssh/sshd_config to contain

Code: Select all

PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys
PasswordAuthentication yes
KbdInteractiveAuthentication yes
AllowTcpForwarding yes
X11Forwarding yes
Compression no
Subsystem	sftp	/usr/libexec/sftp-server

Then in Fatdog Control Panel, System, Manage Server and Services scroll down to the sshd item and both enable and start that

You're now all set to use ssh

You can ssh into that boxes IP

ssh 192.168.1.5

accept it as approved connection by typing Yes, and then enter the password (woofwoof unless you've changed it).

If you add support for X (-Y switch i.e. ssh -Y 192.168.1.5) then once logged in you can run X programs such as 'galculator'. X forwarding however does use a lot of lan bandwidth, vnc is much better.

You can copy files using scp, similar to cp but transfers files via ssh

scp some.file 192.168.1.5:/root/some.file # to copy to the remote system

or

scp 192.168.1.5:/root/some.file my.file # to copy from the remote system

Basically the same format as cp but where you prefix the filename with the IP: of the remote system being copied from/to

You can even use sshfs to mount a remote system folder as a local folder, so you can for instance drag/drop files using rox.

mkdir /root/server-downloads
sshfs 192.168.1.5:/root/Downloads /root/server-downloads

At some point you'll tire of having to enter the password, so you can set up ssh keys for that. On your laptop (if you haven't already done so) run

ssh-keygen

to create a ~/.ssh folder and contents, and append the ~/.ssh/id_rsa.pub file contents to the servers ~/.ssh/authorized_keys file. Thereafter you should be able to just ssh in without having to enter a password, or even run commands directly

ssh -Y 192.168.1.5 galculator

[fatdoguser]

From gslapt install the latest qemu, then with a Fatdog iso to hand you can boot that using

Code: Select all

qemu-system-x86_64 -enable-kvm -m 4096 -cdrom Fatdog64-901.iso

that allocates 4GB ram to that (-m 4096).

Not all systems support kvm (a virtual machine within the kernel), so YMMV. Machines less than 10 years old should be OK. Be patient, booting the iso can take a while, Fatdog used to show a series of dots as it was loading, but more recent versions don't. Also your system may not support 4096GB of ram, you may have to reduce that to 2GB (-m 2048).

Note that the ctrl-alt-g keys toggles locking/releasing the mouse to/from the virtual machine, ctrl-alt-f toggles fullscreen/restored. The default screen size for me makes it awkward to fully see the vm, so adding a 800x600 screen device helps

Code: Select all

qemu-system-x86_64 -enable-kvm -m 4096 -cdrom Fatdog64-901.iso -display gtk -device virtio-vga,xres=800,yres=600

If you create a virtual hard disk of 10GB size

Code: Select all

qemu-img create -f raw myvm.raw 10GB 

then you can further add that device to the boot command ... -drive if=virtio,file=myvm.raw,format=raw

Adding the boot d command will boot from the iso, boot c will boot that virtual hard disk (once you've booted the fatdog iso and run through installing fatdog to the hard disk). Or once Fatdog is installed into the virtual hard disk you might ignore/drop the iso and just boot the disk

Code: Select all

qemu-system-x86_64 -enable-kvm \
-m 4096 \
-display gtk -device virtio-vga,xres=800,yres=600 \
-drive if=virtio,file=myvm.raw,format=raw

Raw type disk take up all of the space (10GB in the above) assigned, there is a qcow2 format alternative that has additional features such as being able to take snapshots, and that is a sparce file (in effect compressed). BUT raw is easier to manage such as copying between machines, making backup copies etc. Easier in early days.

Image shows Fatdog main system with a qemu booted fatdog iso within which I've vnc'd into a server and run chrome and used a internet speed test web site (my ISP limits upload speeds), and that's from a laptop that's wifi net connected.

[step]

@fatdoguser, thank you for this wealth of information. This thread makes a great resource for Fatdog64 users and experimenters. If you are interested and have the time, I would be curious to see similar information about x11vnc. Fatdog64 includes Xvnc and x11vnc and runs the latter when "Control Panel > Network > Share your desktop" is clicked.

How do you forward sound to direct vnc viewers? I think you mentioned it already, but I kind of lost sight of it at the moment. Thank you again.

[fatdoguser]

@fatdoguser, thank you for this wealth of information. This thread makes a great resource for Fatdog64 users and experimenters. If you are interested and have the time, I would be curious to see similar information about x11vnc. Fatdog64 includes Xvnc and x11vnc and runs the latter when "Control Panel > Network > Share your desktop" is clicked.

How do you forward sound to direct vnc viewers? I think you mentioned it already, but I kind of lost sight of it at the moment. Thank you again.

Hi @step

x11vnc publishes a existing X display via vnc. Xvnc is both a X and vnc combined. tigervnc vncserver fronts a Xvnc, whereas you indicated that Fatdog's share desktop fronts a x11vnc. There's considerable overlap/similarity.

Neither manage sound, that has to be handled separately. Your latest version of Fatdog's sound forwarding is great, and is I believe based on rx/tx. Another choice is sndio, the installation and setup of which I outlined here -> https://www.forum.puppylinux.com/viewto ... 60#p102260

For my own usage case I prefer to be able to have one person using the 'server' system, such as a more powerful desktop that's hard wired to ethernet, and another using that system totally separately via vnc i.e. low spec laptop/wifi. For that I built a virtual machine (kvm/emu) of Fatdog that runs on the server, within which I set that Fatdog to use sndiod that forwards sound to the laptop. Which totally separates the main servers 'host' display and sound from the virtual machines display/sound.

A factor with separate display (vnc) and sound is that the two rarely (if ever) perfectly align, so there are lip-sync issues. Mostly only noticeable when you're viewing something where a person is talking towards the camera. The cost of having a low spec laptop display that runs at server speeds.

I'm far from a expert such as yourself, but imagine that there are methods to potentially adjust that lip sync issue dynamically, piping both the separate video and audio streams through some kind of virtual 'device' that enabled you to introduce a delay in either of those. Press a button and phase shift the video (or audio) by introducing a 1ms (or whatever) lag each time that button was clicked, until the viewer perceived that the sound and audio were more aligned with each other. I'd guess that there's a 'app for that' already somewhere, or even one where that was automatically handled, but I personally don't know of such, the commercial products of remote sound/video would be the place to look but again I'm not familiar with those.

Fatdog also includes Back Seat Driver, that is yet another means to perform remote control along with sound, but that's for more for two separate parties sharing the same desktop at the same time and being able to talk to each other. That also uses a intermediary system so that both parties can be behind firewalls that might otherwise block direct connections between each other.

[Clarity]

Hi @fatdoguser. I saw this comment:

...Not all systems support kvm (a virtual machine within the kernel)...

I offer this to help user usage as in most PC to enable it on the running system, as, it is NOT turned on in FATDOG with the installation of QEMU.

Here is a forum utility that 'should' be included in every installation of QEMU, but is not.

Since QEMU is reasonably widespread in forum use, @fatdog might consider this utility's addition to its repo allowing easy member access.

Its a tiny simple utility which will both check for and setup for use of the KVM BIOS/UEFI feature of the CPU in almost all 64bit PCs since 2010. It was donated to the community by @norgo and is found on the forum here.

Hope this is helpful

[Clarity]

Over the last few years, I have found @jamesbond to be one of the "architects of understanding" for a multimedia experience in a remote access to @fatdog .

In my personal past, I have made use of this ability in many varied past work-related environments.

Several manufacturers in the past 3 decades have answered this with several using a standard protocol that has some meaningful properties to insure a consistent remote experience to rival a local experience. This picture depict one of them:

XRDP.jpg (17.03 KiB) Viewed 615 times

.

Today, I am not sure if this is an accurate picture of server-side products.

[fatdoguser]

@Clarity

As I stated in the OP I'm totally unfamiliar with RDP (and Windows). I note from https://learn.microsoft.com/en-us/troub ... p-protocol

RDP is based on, and is an extension of, the T-120 family of protocol standards. A multichannel capable protocol allows for separate virtual channels

further

channel assignment by multiplexing data onto predefined virtual channels within the protocol

In my layman terms RDP can combine multiplex multiple channels, such as separate video and audio streams, into individual actual packets such that they are conveyed together and hence in (lip) sync, using its own proprietary (extended T-120) protocol (strips tcp/whatever packets of headers etc. and wraps the multiplexed content into its own RDP packets). For that it requires a Terminal-Server server that feeds that flow i.e. Windows Box running Terminal Server. The Linux equivalent to that is xrdb which I never tried in my OP, so I've revised the title from xrdb to just rdp.

[fatdoguser]

Fatdog laptop, 1366x768 resolution
Fatdog server, i5 running kvm/qemu VM of another Fatdog session (all 901 series)
Within the VM I've swapped out using vncserver for x0vncserver. In /root/Startup I have a vnc file to start that

Code: Select all

#!/bin/sh

sleep 4
DISPLAY=:0 Xephyr :1 -dpi 96 -screen 1360x768 &
P=$!
sleep 3
DISPLAY=:1 jwm &
DISPLAY=:1 xrandr --output default --mode 1360x768
sleep 2
DISPLAY=:1 x0vncserver -ImprovedHextile -rfbport 5903 -geometry 1360x768 \
    -rfbauth /root/.vnc/passwd -SecurityTypes none -FrameRate 10
kill $P

The point of note is the -FrameRate 10
Sounds too low? ... But it still works well! Well enough to look-n-feel just like a regular sitting at the box desktop. Whilst capping the frames at 10 per second considerably reduces the amount of data that has to be conveyed/processes.

Testing that, using the laptop to vnc into the server session and play the nvidia test video, set to 720 resolution, whilst having bmon (and htop) running on the (vm) server, and the Tx data indicates how much vnc traffic is being sent out (over wifi) to my laptop. I snapped the attached image around halfway through that video run, started the video, used the Fatdog menu to initiate a (delayed) mtpaint snapshot, and as indicated the Y axis peaked at around 3MB/sec (so around 24Mbs). That also includes sound that I forward to the laptop. vnc being fed to the laptop through a ssh tunnel, that has no Compression turned on. It does route out to the host first, a net switch when the kvm/qemu is started, but that's more of just a matter of pointers. I run that in a VM solely as that separates it from the main host system, so someone else can be using that i5 box at the same time also running chrome/watching youtubes ... without interference.

The video was played in chrome, with a pull-out plug used to position/size the video as seen in the attached image. Reducing the size, to the more regular sized youtube frame size, along with reducing the resolution to 480 would obviously be inclined to further reduce the bandwidth. Within the realm of being comfortable to use when out-n-about wherever a modest wifi or data connection speed is available. Without high intensity things running such as a video, preparing and posting this for example and the throughput is less than 1MB/sec peak, down to low KB's if the screen is relatively static/idle.

IIRC I don't think x0vncserver or vncserver are included as part of the default Fatdog, you (may) have to install tigervnc from gslapt.

Oh and attached image quality is low as the initial .png I tried to upload was too big 670K or thereabouts, so I re-saved it as a more lossy .jpg (160KB). And its been scaled down from the original 1366x768 to 1200x678