Separate headless server for video editing?

[wizard]

Man, this is like pulling teeth!

More like "whack a mole"

wizard

[vtpup]

Thanks Rockedge, wizard.

Suddenly all moot. Proc died.

[rockedge]

@vtpup Oh no! sorry to hear of the CPU's demise.

[vtpup]

Thanks Rockedge, I think the CPU temp monitoring program wasn't working for this old a proc and when I opened it up, the heatsink compound was all dried up. So...... well, I didn't really expect much starting out -- in fact it was a surprise that it started up at all. Just wish it had lasted long enough to test out an rdp connection. At least I learned what was involved, which was the main point.

Well..........I hope I'm not going to regret this but I just sent for the MSI AMD motherboard, proc, and memory as a combo, listed here:
https://www.amazon.com/MSI-Crossfire-Mo ... B07WF6ZQST . Impulse decision!

[wizard]

@vtpup

You're going to need a power supply or an adapter for the atx. Also, the old atx may not have enough watts for the new equip.

wizard

[vtpup]

Thanks wizard, yup I realized that and ordered a 700w supply. Also a 2 TB HD.

[Clarity]

Just got to see this. Yes, you are on the right track. Since this is SO NEW to members in "how to have a connections that is truly multimedia in Puppy Linux", the topic is practically alien.

I will try, over this weekend to get @fatdog to work with having an XRDP server running and using either Remmina or the current client(s) in Puppy linux to yield a multimedia session.

This way, all other members who have multiple PCs on their LAN can take advantage of never needing to get up and walk to another home PC to use it. This has so many home use possibilities. I thinks others will find benefit as this is NOT new technology, but rather old, open-source, and free.

I have had it running on a Ubuntu server 3-years ago, but that PC's power-supply died earlier this year and it was never resurrected.

There are a few videos on XRDP and Remmina and clients but, NONE for 'any' PUPPY Linux although there is the @goingnuts implementation in a PUP found on the old Puppy Linux forum.
Ubuntu
Kali
Debian

[vtpup]

From my point of view the problem of communicating a remote desktop isn't the difficulty of the concept, or the availability of applications, It's the arcane nature and individual jargon of configuration options and protocols in constantly changing versions of applications, as implemented in a hundred similar but different operating systems, which are themselves obsoleted on a yearly basis.

I wouldn't be surprised if I changed my mind and set up the server with a non-Puppy OS proven to work with kdenlive and xrdp, with lots of user experience to back it up with proven configs. Then I could just run a puppy client on the laptop.

[vtpup]

btw, @mikewalsh your Avidemux pet ran beautifully on Bionic32 before the CPU died.
R.I.P P4

[Clarity]

Looking for directions to make it as simple; same as it is for Windows/MACs/UBUNTUs

We'll need to create information to show

• The PUP server steps"

  1. Install XRDP with dependencies.

  2. Once successful, check to insure that the XRDP server has port 3389 open for LAN service

• The PUP client steps

  1. Fire up a PUP client

  2. insure its firewall wont stop return traffic

We want PUPs to be simple too; as in the mentioned OSes.

[vtpup]

Those steps were all accomplished. Fairly straightforward application troubleshooting. The problem was in getting them to work together.

In other words, communication protocols, encryption type, encryption version, encryption keys, X session type, X session initiation parameters, group and user permission requirements, login window contents, screen resolutions and bit depths, audio server type and requirements, etc, etc.

In other words configuration is the blivet. And documentation skeletal.

btw, encryption is NOT absolutely required by xrdp.

[vtpup]

I'm trying again to just get XRDP and Remmina working. This time I've set up the main laptop (Acer 5349) as the XRDP server, and my Acer C720 Chromebook as the Remmina RDP client.

The C720 is a dedicated BionicPup64 box (Chrome OS removed) so, technically it's a C720 Pupbook.

Both RDP server and client programs were successfully installed on the respective machines after all updates to PPM and Bionic64 were applied. The laptop server is running on a fresh Pupsave.

I'm back at the same stage I was before: The login screen from the server appears on the client -- so both are communicating. However, entering the credentials does nothing.

There are two main possibilities. One is a reported Ubuntu XRDP bug requiring reinstalling xorg for missing dependencies and then reinstalling a required module.

The other is that the configurations for server and client are not set up to be compatible yet. Most likely the problem is with the XRDP config file:

Code: Select all

[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=3389
; 'port' above should be connected to with vsock instead of tcp
use_vsock=false
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection will be closed
tcp_keepalive=true
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=rdp
; minimum security level allowed for client
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=none
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
certificate=
key_file=
; set SSL protocols
; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2'
ssl_protocols=TLSv1, TLSv1.1, TLSv1.2
; set TLS cipher suites
#tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=

allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
#hidelogwindow=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
#require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
#pamerrortxt=change your password according to policy at http://url

;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
#black=000000
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

;
; configure login screen
;

; Login Screen Window Title
#ls_title=My Login Title

; top level window background color in RGB format
ls_top_window_bg_color=009cb5

; width and height of login screen
ls_width=350
ls_height=430

; login screen background color in RGB format
ls_bg_color=dedede

; optional background image filename (bmp format).
#ls_background_image=

; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50

; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=60

; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210

; y pos for first label and combo box
ls_input_y_pos=220

; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30

; Cancel button
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30

[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:
#port=/tmp/.xrdp/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1
#chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210


;
; Session types
;

; Some session types such as Xorg, X11rdp and Xvnc start a display server.
; Startup command-line parameters for the display server are configured
; in sesman.ini. See and configure also sesman.ini.
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

[X11rdp]
name=X11rdp
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
xserverbpp=24
code=10

[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
#xserverbpp=24
#delay_ms=2000

[console]
name=console
lib=libvnc.so
ip=127.0.0.1
port=5900
username=na
password=ask
#delay_ms=2000

[vnc-any]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask
#pamusername=asksame
#pampassword=asksame
#pamsessionmng=127.0.0.1
#delay_ms=2000

[sesman-any]
name=sesman-any
lib=libvnc.so
ip=ask
port=-1
username=ask
password=ask
#delay_ms=2000

[neutrinordp-any]
name=neutrinordp-any
lib=libxrdpneutrinordp.so
ip=ask
port=ask3389
username=ask
password=ask

; You can override the common channel settings for each session type
#channel.rdpdr=true
#channel.rdpsnd=true
#channel.drdynvc=true
#channel.cliprdr=true
#channel.rail=true
#channel.xrdpvr=true

[mikewalsh]

↑↑↑ - Removed additional "double-post"...

btw, @mikewalsh your Avidemux pet ran beautifully on Bionic32 before the CPU died.
R.I.P P4

Cool. I thought it should. That thing will run absolutely anywhere; I know it's an old version, bu for testing purposes you just want summat reliable, not "fancy"....

Glad to be able to help.......however little.

Mike.

[vtpup]

Well the Avidemux pet may help someone else reading this on Bionic32. As well as this entire thread, since the behavior of XRDP is the same as on BP64.

Now for today's (lack of) progress report, I decided to try the actual Windows 7 version of the Remote Desktop client (on Windows 7, not Wine) against the XRDP server running on Bionicpup64 . And I got exactly the same result I got running the Remmina client on BP64.

I get the XRDP splash/login screen, meaning they are connected. But logging in does nothing.

This to me proves the problem is with XRDP, not Remmina (or Win's RDP client)

So I guess that's progress of a sort.

[vtpup]

Okay, I've had it with XRDP on Puppy. It doesn't work. I've tried everything I've found on the net by way of suggestions (invariably for Ubuntu, not Puppy)

Clarity, since you've been such a booster for RDP here, let me know if you have XRDP working on ANY version of Puppy and what your config file looks like.

[rockedge]

@vtpup So I am 100% on the same page, the XRDP server is on the Puppy Linux machine and the desktop client to communicate with the RDP server is on a machine running Windows.

So far the XRDP package seems to be running but you can not connect with Windows or with a client running on WINE?

[vtpup]

Yup Rockedge, XRDP runs. And actually it does connect in a sense. It sends its own login screen to the client machine. But nothing you enter into the login screen from the client works to get it to move further with a remote desktop presentation.

I cannot get it to log in via the standard RDP client on Windows 7 machine, or via a Puppy Bionic64 machine running the Remmina client natively. I have not tried anything on Wine.

Both clients show exacly the same thing: the teal colored XRDP login screen with XRDP logo, but which doesn't actually work to log you into XRDP.

The problem is either with the XRDP configuration, or the XRDP implementation.

[vtpup]

Well, I've got the re-made desktop computer together. It used an old previously modified Compaq tower. The mainboard is an MSI B450 Tomahawk MaxII gamer board. CPU is an AMD Ryzen 5 3600 6 core. The GPU is an old one that is NIB that I bought for a project 7 years ago and used twice -- also coincidentally MSI, an N460GTX Hawk two fan heat-piped gamer card. Here's a pic, GPU on left:

MSI MotherboardandGPU.jpg (159.52 KiB) Viewed 743 times

Other purchased items were a 2TB hard drive, 16GB Corsair memory, and a power supply. Total cost was a little over $400 -- considerably less than any gamer quality laptop, which, quite frankly was out of the question for me. I could have spent less; I didn't realize the older power supply could have been adapted to fit the 24 pin header. And I could have used the older 500 gb hard drive in the Compaq, but video production gobbles up storage as fast as you add it, and the drive was about $50.

The graphics card was probably uneccessary, and overkill, since the main use for this computer was imagined to be as a headless video editing server. But if the remote desktop idea doesn't pan out, at least it will be usable with a monitor as a decently powerful standalone editing machine.

The only two construction problems I had were mounting the CPU fan, and a Babel of new connector types. I'm definitely behind the times on those! For instance, new to me DVI connectors on the GPU required a new DVI cable -- luckily my older monitor could accept it, as well as the former VGA cable. New smaller HDMI jacks than the cable I have are unused. The motherboard had more types of USB than I knew existed. But all seemed to work with what I plugged in.

CPU issue: The cpu fan has very short spring loaded screws and is supposed to normally screw into an extra bracket on top of the CPU's mount. At least that what it shows on the instruction cartoons. Words are no longer used in manuals. Unfortunately all included cartoons were irrelevant. MSI did an undocumented alternate mount with a backing plate underneath and standoffs which penetrate the board. The fan mount screws are supposed to go into this standoff/backing plate combo.

Unfortunately this backing plate comes loose when the board is mounted and temporary retainers are removed. It drops down a short distance to sit on the computer case. The spring mounted fan screws then can't reach the standoffs, but that's not obvious because all are hidden under the fan cooling fins. Ideally you'd mount the CPU and fan assembly before mounting the motherboard to the case so you could hold the plate tight to the board. --- IF you were aware of the whole problem in advance. But who is? Seems everybody mounts the board before the CPU, and then puzzles why the screws won't engage in the invisible space under. There are whole videos showing mounting OUT of the computer. Saying, it's easy, but not mentioning it is absolutely necessary out of the computer, and hundreds of comments from people saying "but my fan doesn't fit, HELP!"

The problem is complicated by the fact that the fan has thermal compound applied already by the mfr (their brand tied to the warranty) and once you've started to mount it, the cpu is covered with the goo, and suction won't let you remove the fan without fear of damage, etc, etc. If I took the board out, the compound would probably end up everywhere and contaminated. What to do? I finally managed to catch one of the screws by applying enough pressure to the fan bend the motherboard down a little (not recommended!). By screwing that one in a little I could catch another screw and then eventually all four. Ugh.....had I stupidly ruined it? Only the smoke test would tell.

[vtpup]

All the cover panels were off of the computer chassis. I wanted to see the fans, troubleshooting LEDs etc. I connected monitor, keyboard, and mouse, and finally the power cord. With a giant cartload of trepidation I switched on the power supply and..... NOTHING! Nope. No lights, no sounds, no nothing. I looked over the wiring. I looked at the power cord, was it fully plugged in? I looked at the manual.......all connectors in place?

Then I remembered, uh.......you have to hold in the momentary power switch in the front of the chassis, not just the power supply. Duh!!

And when I did, expecting no change, all of a sudden all kinds of things started happening: green lights red lights, lots of red lights, fans turning, but silently. Are they turning fast enough? What do so many red lights mean?

Then the monitor came to life, and this is what I saw:

MSI_BiosScreen.png (282.66 KiB) Viewed 743 times

[vtpup]

It worked!
After trying to read all of the BIOS screen (I'm used to a console style black and whit American Megatrends type) and figure out if everything was okay, I was surprised to see that CSM was already enabled (vs UEFI). Did this thing read minds?

Or maybe it just automatically recognized the GPU as older and decided the user would never even get to see a BIOS screen unless it relented. The huge number of possible bootable devices was daunting to try to set up, but eventually I found USB key (non EFI) and the non EFI hard drive, and promoted them to the top of the list. Weird using a mouse to set up a BIOS!

Then I shut down the computer and inserted an USB wireless dongle (from an old Raspberry PI) and a Fossa64-installed thumb drive, re-booted and IT JUST WORKED! Fossa came up just like it should, and I loaded Frisbee and configs, updated Fossa with Petget, and also updated the PPM repositories. No problem, and all familiar. Went to GParted and added a partition table and a 100 GB FAT32 sda1 boot partition and a 200 GB ext3 partition after, just for testing.

Tried a couple appimages of Kdenlive (different versions) and both had dependency problems. So I loaded the sfs from Petget, and that opened. I tried out a simple little video project using some random clips and music, and with headphones marveled at the really crisp video and sound playback in the kdenlive monitor screen. Woohoo!

[wizard]

Unfortunately this backing plate comes loose when the board is mounted and temporary retainers are removed. It drops down a short distance to sit on the computer case

"The handyman's secret weapon...duct tape" Thanks Red Green.

@vtpup

VROOOM VROOOM!

wizard

[vtpup]

Thanks Rock and Wizard.
re. duct tape: If one only knew about the backing plate in advance. Y'see it's mounted firmly to start with with 4 screws through yet another set of fan mount plastic thingamabobs on the top side. These you are supposed to remove cause they're for a different fan, to reveal the 4 screw holes you need. That's when the bottom falls out.

You don't know you need to remove the plastic thingamabobs until you open the pretty cardboard proc box and survey its included cartoons. That' was after I'd built everything else -- thinking the proc is the most delicate static sensitive whatzit -- be smart Stevie, wait til the very end of all the screwdriver-dom and plug-icity and wire-tie-ishness to add it. Should be simple, after all it's just a zero insertion force socket, right?

And since the backing plate is on the bottom of the circuit board, you don't even know it exists. Backing plate? What backing plate? Instead, you think the standoffs are just too short, since they barely protrude through the circuit board. Ah well, ignorance is blistering.

My only positive feeling came when I saw that thousands of others had probably the same dumbfounded frustration when the screws didn't reach. I wasn't alone.

btw, duct tape? ya wanna see duct tape? Click on my video link in my sig. I'll show ya duct tape.......

[vtpup]

Okay so now I'm wondering what I should actually run on this computer. I'm sorry to say, thinking outside of the puppy realm, now. Two reasons -- a failure to get XRDP server running in Fossa, and the possibility that it could end up being a multi-user server in this household. I'm not sure I want my teenage daughter running a remote desktop on it as root. Not necessarily her fault, but the relative vulnerability of a remote root desktop that I'm not sole user controlling.

So I'm thinking Ubuntu Server edition, since there are proven XRDP instances on Ubuntu, Kdenlive installation straightforward, and finally, it's a multiuser system. The clients can all still be Puppies running remmina, just thinking it might make sense to make the server the odd OS in the house.

What do you think?

[wizard]

@vtpup

My searches didn't find anyone with a working Puppy XRDP since 2015. You might consider one of the popular lightweight Ubuntus like Xubuntu, simpler and I like better than the big parent. Also, take a look at X2Go or Nomachine as alternates for XRDP.

wizard

[vtpup]

Hi Wizard, thanks. I just checked and Ubuntu Server edition requires 2.5 GB disk storage, minimum, while Xubuntu requires 8.6 GB minimum. Ubuntu server doesn't have a lot of apps, or even a desktop. XFCE can be downloaded onto the server to keep it light weight. I would only need to add (in the way of big apps), Kdenlive and dependencies, plus XRDP to have a video editing server, with remote desktop capabilities, I believe.

[vtpup]

A lot of water over the dam on this multimedia project, mostly documented in other threads devoted to specific problems like the remote desktop implementation. To catch up on the overall project, remote desktop IS working using Xubuntu 18.04 on the desktop server, running XRDP, and so far, Bionic64, or Fossa64 running Remmina on the laptop. Sounds is working. The video editor of choice is Kdenlive

The main problem left to resolve for completion is getting a high enough speed wireless network connection between the two boxes. I've achieved 100 mbps on a wired ethernet connection through an older DSL modem/router. This is not quite fast enough to provide jitter free sound and video, but it's close.

I just received two new wireless cards, one for the desktop and one for the laptop. These are rated at Wifi 6 rates, and use either 2.4 gHz or 5 gHz bands. I had hoped to connect through the 5gHz band for possibly triple the previous wired speed. But unfortunately it looks like Puppy's wireless managers may not be able to utilize this band. Xubuntu's wifi manager has no problem with it -- and offers settings for 2.4, 5 or automatic.

In an adhoc wifi test between the two boxes directly (sidestepping the DSL modem/router) on 2.4 gHz I achieved 108 mbps (that's megabits, not Bytes) , just slightly higher than a wired connection through the present router.

I would be grateful for any help in getting 5 gHz wifi going in Bionic or Fossa puppies, as it has the potential to greatly increase the speed of connection, and make this a viable system.