Is krfb abandonware?

Help
1

All I want to do with krfb is have it run so when my remote system using it boots up, I can access it remotely - and yet, there’s almost no documentation on how to do this and krfb is acting like it is designed to disallow unattended remote access.

Is krfb abandon at this point? I’ve made two posts asking for help and one was up for a while before I found the answer myself, so I’m finding that on the official KDE forum, help for krfb seems scarce. I am not trying to be combative or argumentative or blaming at this point, but I just want to do ONE SIMPLE THING and I can’t find documentation for help, can’t get help here, and the program is not behaving as it should.

I’ve also found NO official documentation on the command line arguments or the config file (.config/krfbrc).

And I’m finding behaviors that make me ask, “Did the developers actually USE this in real life after they finished?”

I know building and maintaining KDE is not easy and even one program, like krfb, requires a lot of work, but this is frustrating. But when it’s not possible to use a program for remote access to a system without a lot of work and a fight, then something is wrong.

First, I wanted krfb to start without opening a window. I put it in Autostart, but it had to open the window. I found I could add “–nodialog” (I used 2 en-dashes, not one em-dash as autocorrect did) to autostart. Did that. It STILL opens the window.

Once it opens the window, it means it’s attended access, so I have to use the attended access password, which is random and, even when I save it, it’s changed each time KDE starts up.

This makes it IMPOSSIBLE to use krfb for remote access UNLESS there is someone at the computer. It won’t start without a dialog, even with the argument for no dialog, so it ONLY starts with a dialog, forcing attended access and the random password changes.

I want help on this, but previous posts about krfb issues aren’t getting responses, there is no man page, no page on the KDE website documenting options, or what I can do in the krfbrc file.

This makes me wonder if the project is abandon or if the devs intentionally want to make it hard to use for unattended access. (Clearly starting with a dialog even when the argument to not do that is used is a bug - but, at this point, I don’t know if it’s even worth reporting it.)

2

all i have in my notes about this app is this

Krfb Desktop Sharing is a server application that allows you to share your current session with a user on another machine, who can use a VNC client to view or even control the desktop.

KRDC is a client application that allows you to view or even control the desktop session on another machine that is running a compatible server. VNC and RDP is supported.
3

Thanks for a reply!

This backs up what I’m saying - no documentation on it.

I’m really not trying to start a fight, but to put out a program for remote access that, in reality, only works if the system is attended, makes it almost useless and I think the devs need to be aware of the issues (the apparent bug and lack of documentation).

4

Hi,

There is a new “Remote Desktop” in system settings (krdp package), would that possibly suit your needs?

5

Cool! So would that explain why there seems to be little or no attention to krfb? Because it’s been superseded by krdp? I will check that out as soon as I get back to the system I’m working on.

6

KRFB is for sharing over VNC, krdp shares over RDP. Different protocols, and wildly different capabilities. I can’t comment on the amount of attention each receives, but from a technical standpoint, I’d chose focusing on RDP too.

7

Okay, just saw that when I got home and looked it up. (The “RDP” in the name should have been a hint to me!)

The problem is I deal with Linux and Mac systems on my LAN and don’t want to start splitting them up into different protocols. Right now I can use ONE viewer, from any desktop system on my LAN, to access any other system. I have several Pi systems (odd - forum won’t allow the use of the word Pi with an ‘s’ on the end!) that use touch screens, Macs for desktop use, and some Linux systems for desktop use. Until I can easily switch all to RDP servers (not so easy for Mac - and I’m not sure if other DEs on Linux use it), I really don’t want to start using different protocols on different systems.

But, again, if KDE is focusing on krdp, that might explain why krfb is treated like an unwanted step child.

8

Hi ImaginaryTango

I found this info that solved my issue:

It has been quite a while but I remember following parts of this to save some settings.

Good luck,

Vektor

9

Just a note to say that krdc supports both VNC and RDP. So one viewer is still possible.

10

Interesting. Yes, it’s over 10 years old, but the parts that talk about bypassing the bug might be helpful. The first issue is not the krfb settings, but the Autostart settings. For some reason, even with “–nodialog,” it opens the dialog. I have tested it from the terminal and the option works. I went ahead and added a 2nd option, so now, in Autostart, I have “–nodialog –nodialog” for the command line options and it’s working. (Just tested that late last night!) As long as it’s saving the unattended access password, then that’s the main setting I need krfb to save.

I looked at that. Since krdc is a client, though, it doesn’t help me set up a VNC server on this system with KDE. While there are some clients on different OSes that use RDP, one reason I’m not going with RDC is because I’d need a good open source RDC server to run on macOS. Until I can get that working, I’m sticking with VNC servers so I don’t have to stop and remember which computer uses which protocol and have to pick which client I use for which computer. (I really have problems keeping up with things like that.)

11

on which OS are you having difficulty setting up the VNC server?

i think the point about krdc is that it’s a client that can handle either server type depending on which machine you are connecting to.

12

Let me step back a bit, because I may have rushed and tried not to go into too much info!

macOS uses Screen Sharing, which uses VNC. So Macs us that as a VNC server AND client. And on other OSes (for me, that’s Linux or similar, since I rarely use the one Windows laptop around here), I can easily use TightVNC as a client to connect to any Mac. I can’t remember what I use as a server for Windows, since it’s so rare I use Windows at all.

On Linux, in the past, I’ve used TightVNC server, but now they charge and license it and it’s a pain. I have some Raspberry Pi systems that run their version of Debian. Most of the time I use those for touchscreen controllers, and I’ve never had a problem setting up a VNC server on one of them. (I can’t think, right off, what desktop I use for those, but it’s been a while since I set one up, so it might be KDE and it might be krfb didn’t have the issues I’ve had back then.)

The problem is if I want to move to RDP. At this point, there’s only one program I can use on a Mac as an RDP server and it’s a per-system license. (And I prefer open source - I’d rather pay for a good open source program to support the devs than get a crappy closed source one for free or cheap.)

That makes it quite useful and if it were easily installed on a Mac, I’d start using it instead of TightVNC as a client. My concern is that to install it on a Mac, I have to use MacPorts and install the whole base KDE system. That’s a fair amount of files to have to deal with updates on. (Also, I’ve used brew and macports - they’re pretty good for many uses, but I’ve run into issues with them. One, maybe both, have usurped my Python path in the past, forcing me to pick between using my preferred Python Mac setup or the ports/brew Python setup.)

13

Since my immediate issues seem to be resolved at this point, I do want to add a point for summary, especially since I think it would be appropriate for a KDE dev to respond at some point here.

I think we can draw a conclusion that krfb is, at this point, abandonware. There are no useable docs, even from the command line, “–help” does not provide any clear documentation on important options (“–nodialog” isn’t mentioned, for example). Also, while I know devs are busy, I think the fact that this hasn’t caught their attention (either by someone referring one to this thread or anything else) is an indicator KDE has minimal interest in krfb. They’re probably moving to RDP only. I think that would be a mistake. This isn’t Apple, where they quickly drop support for anything other than the latest hardware or software. One reason a lot of people use Linux is because it can easily be run on older systems, or can be modified for special uses, or can be used to work with older systems.

14

Hmm. Couple of suggestions:

The app is available by command line, but, since this is a KDE app, another place to start might be KDE’s Application Dashboard/Launcher/Menu. At least in Arch and Debian, a GUI interface to Krfb shows up there, under Internet.

As you point out, it looks like there’s a problem with —help from the CL. I see what look like errors about QThreadStorage when I try it. It’s my impression that the KDE Discuss forum is not routinely monitored by KDE developers. Maybe a bug report would be appropriate? https://bugs.kde.org/

For documentation on the GUI interface, you might check the KDE Documentation website: https://docs.kde.org/

If you use the Application Name: search box (upper left) to look for krfb, you’ll see both Stable and Development versions listed. Even though the documentation is old, the app is listed as Frameworks 6, so seems to be fairly current. (Docs are also listed in the files list for the application in usr/share/doc/HTML/[lang]/kfrb, but in docbook format, so I prefer just reading them on-line.)

Those docs show details for setting up the server for Unattended Access, for example. One thing I haven’t figure out is whether it can be started before a user logs in.

Also, a gotcha I came across recently: the krfb app starts automatically when the GUI is opened (Enable Desktop Sharing is checked by default). To shut it down, the GUI needs to be closed via File, Quit, not by simply closing the window. Otherwise it seems to ignore clearing the Enable box. This is documented, but I find it odd. This behaviour makes it easy to inadvertently share the desktop.

For the client, I’ve been using TigerVNC lately, but up to you of course. I’ve been connecting from Windows, so don’t have the option of using KRDC, the KDE app.

RDP, AFAIK, is a proprietary Microsoft protocol. There are open-source apps to use it I understand, but I’m reluctant to do so myself as I prefer open source. As old as it is, the frame buffer approach still works for X11 at least.

X2go is an alternative, but I haven’t been able to get the server working on Arch, so am not using at this point.

Hope this has been of some help.

15

The problem with both of this is if the computer is in a remote location. Even though my workshop is only a 500’ walk from my study/office, there are times I can’t just walk down there. I tried and krfb won’t start from the command line unless it’s run from the terminal within KDE. If you run it from a shell in ssh, it’ll give you a bunch of errors because it depends on the KDE environment.

I haven’t tried running it without a user logged in. But that would be an important factor - you can’t count on someone being logged in at all if you need remote access! in my case, we’re in a rural area. Our house and barn are in the woods. Yes, someone can always break in and do bad things, but the chance of such a person knowing what to do on Linux to make a mess… Because of our situation, this system is set to go into KDE without asking for a username or pw.

If krfb would just load without bringing up the GUI, it would be just fine for remote access. (Again, if the window comes up, so it’s attended access, then I have to use a pw that is randomized and auto-generated each time the program starts - it won’t save my specified pw.

And, of course, for remote access, starting it within KDE doesn’t help - since the whole reason I want to use it is to access the GUI/DE in KDE.

I know you’re probably aware of this, but I’m stating it to document the issue.

I’ll check those out. (Still, not having a man page or a working help function from the command line is a serious problem.) As I see it, there are multiple bugs:

- It regenerates the Attended Access pw every time it’s run

  • It won’t autostart in KDE without opening the window, always forcing Attended Access
  • Help function won’t work
  • No way to effectively autostart it on a remote system due to these issues

I did use “–nodialog” in Autostart, and it still started - sometimes. I added a 2nd “–nodialog” just in case, and it didn’t open a window the next time I tested it, but it did from then on. This may be part of the gotcha you found.

Are you saying it always starts with KDE? If that happened on my system, it’d solve my problem. Where are you checking “Enable Desktop Sharing?” I have it checked in krfb, of course, but want to know if you’re talking about somewhere else.

I’m not sure if I follow what you mean. So if I click the X to close the window, it closes the window, but doesn’t stop krfb, so it’s still waiting for connections?

My issue is that even when I close the window and the window icon is gone from the menu bar, when I restart the system and KDE comes up, the dialog for krfb comes up again.

I think you’re right that RDP is a Microsoft protocol. There is a RDP server for Mac, but it’s got a per-computer license at, I think, $50/computer. So that’s $100 for my 2 Macs and that’s kind of pricey.

16

I don’t understand this remark:

Meaning the GUI interface? Doesn’t that mean it’s working? Is the Enable Desktop Access box checked? What about the Enable Unattended Access box?

Have you checked to see if the process is listed in the System Monitor, or through

ps aux | grep ‘krfb’

in a terminal?

17

Here are steps I’ve used to get it working here, in case this helps:

Login (through sddm) as normal, starting a KDE session on the target (i.e. host) machine.

Confirm krfb process is not running. Open a terminal and enter
ps aux | grep ‘krfb’
/usr/bin/krfb is not listed.
(could do this through System Monitor too I guess).

Start the Krfb GUI from the menu. Confirm that the Enable Desktop Sharing box is checked (it is and the application automatically starts when the GUI is opened it seems).

Check the Enable Unattended Access box, then click the Change Unattended Password button. Enter and confirm a password.

Go to another machine (the client). Connect using some version of VNC (Tiger in my case, from Windows). Password challenge works as expected, with the Unattended Access pw, not the regular one.

Optionally while connected to the target, close the GUI interface on the target by clicking on the window’s X. The process still appears in process list, and the connection continues to function. (Clicking File, Quit terminates the process and the connection.)

Reboot the target. The connection terminates as the machine shuts down. No connection is available after restart.

Go to the target machine and login. Again, krfb does not appear in the process list. (I believe this behaviour changed a few months ago. In any case, it’s clearly the state of things today.)

To provide Krfb on startup, go to System Settings, Autostart. Add the Krfb GUI application. Then go to System Settings, Login Screen, Behaviour and set up Auto Login.

Start the GUI on the target as above – make no changes (i.e. both Enabled boxes are checked).

Connect from client. Password challenge works as above with same password.

Restart the target. Wait, then use VNC app to reconnect from client. Password challenge works as expected.

Could your password problem have something to do with KDE Wallet? I don’t use it.

Anyway, that’s about all I can thnk to add at this point.

18

My goal is to be able to use VNC to access this computer remotely. I can get to it with ssh, but sometimes it’s easier to do some activities with a GUI. And the big problem (which is caused by a combination of several bugs) is that I can’t access it through krfb on boot. So if the machine goes down because of a power flicker or someone else messes with it, at this point, I can’t access it with VNC until I go there, physically, and make sure krfb is running properly.

I have done a lot of what you suggest to set it up, and I’ve brought up the problems with those actions, which seem to involve bugs. I have krfb on Autostart. Note I’ve brought that up and when I set it up in Autostart, it always opens the dialog. I added “–nodialog” (2 en dashes, but it’s autocorrected, here, to one m-dash) to the config in Autostart. It still always opens the dialog.

So that’s bug #1 (which I’ve reported): Even with “–nodialog” set, it brings up the dialog. Tried this in many configurations.

Bug #2 is that there is almost no documentation on krfb anywhere. While the help function does list “–nodialog” as a command line option, not much more is give. There are other options, not given, there’s no man page, and even on the KDE site, it’s not documented. As for the “–nodialog,” there’s so little on it that I can’t tell if there’s a reason it doesn’t work or if it’s a bug. (I do notice if I start it from the terminal in KDE, it works, but with Autostart, it does not.)

So no matter what I do, it always starts in attended mode.

I don’t use KDEWallet. (Which was a pain to undo - since it comes up by default and the “off” setting is not as obvious as I had hoped. It’s there - forgot just why it was a pain to get to.)

When I set the attended access password, it’s stored in the config file, ~/.config/krfbrc. The passwords are encrypted and stored in that file. And that’s bug #3: Every time I restarted krfb, by hand, or restarting KDE, or rebooting, as I pointed out, it changed the attended password to random characters. At one point I hand edited that file and it FINALLY stopped changing it every time - but it still changed it at least once after that. So I don’t know what the conditions are that make that password change.

Because of these bugs, here’s what happens:

  1. I set up krfb in Autostart to use “–nodialog”
  2. I close the window, leaving the program running.
  3. I restart.
  4. KDE comes up with krfb starting, with the dialog open (no matter what)
  5. Sometimes krfb has changed the attended access password to a random string.

So I can’t use the unattended access mode, since the dialog comes up. I can sometimes use the unattended password, but not always, since that gets clobbered and replaced.

There is no way, remotely, with ssh, to kill the dialog box within KDE, and no way to restart krfb, since it must be run within the KDE environment to work. Starting it from the command line, outside of KDE, results in multiple errors because it can’t access the libraries needed.

19

Hi ImaginaryTango

I feel your pain.

A few years ago I set up MX Linux on all the machines that needed to be remotely controlled. After giving up on KRFB. I decided to use DWService. It installs wherever you want and can autostart. Works great.

Point Firefox to the DWService website and I am in. After that I can engage any local remote program I want, which is krfb. So I am able to accept KRFB remotely from my living room chair to my guy-cave computers (4) and then kill Firefox to stop internet activity. Remmina works great.

DWService has nearly always been flawless and also offers other capabilities that might interest you. Very shallow learning curve and FREE !!!

Vektor

20

Does it require any kind of port forwarding? My ISP uses CGNAT, so I can’t do port forwarding. (That also can create bandwidth issues at times, and I lose connection during heavy storms.)