LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Any advice on building and running xrdp and xorgxrdp on Slackware? (https://www.linuxquestions.org/questions/slackware-14/any-advice-on-building-and-running-xrdp-and-xorgxrdp-on-slackware-4175617278/)

allend 11-09-2017 07:17 AM
Any advice on building and running xrdp and xorgxrdp on Slackware?
 
My work IT department (in their widely debated wisdom) have now implemented Windows Applocker functionality that has killed the Cygwin setup that I was using on my work provided computer running Windows to access and maintain my Slackware intranet server. After consultation, the suggestion is to pay the extra money to get a less locked down setup and take responsibility for on-going maintenance. I do not like this because:
1. I am pig-headed and do not want to have to pay for restoring previous functionality.
2. I have a role implementing and maintaining an application that should be usable to anybody using the standard environment, so I would prefer to develop and test in the standard environment.
3. I want to not have to deal with suggestions that a non-standard environment is the cause of any future issues.

I have found that the Google Chrome Secure Shell webapp allows SSH access, but I would like to get access to a full remote desktop.
As the Windows Terminal Services Client (mstsc.exe) is still functional, I am considering setting up my server to use xrdp and xorgxrdp. Looking at SlackBuilds.org, there is a script to build xrdp 0.6.1, but the latest version is 0.9.3.1 Also, xrdp now supports xorgxrdp, that as I understand it adds additional driver support to X11 in a less intrusive manner. However, there is no SlackBuild script for xorgxrdp.
After that long preamble, has anybody got any experience or advice they can share?

business_kid 11-09-2017 02:29 PM
Time for a memo to management.

Problem: This intranet server can no longer be maintained because Applocker had reduced the functionality of Office computers. The options are

Option A: Outline needs, time (estimated), drawbacks, security issues & Costs
Option B: Outline needs, time (estimated), drawbacks, security issues & Costs
etc.
At least one of those should be a linux VM in a windows machine. Managers are nuts about conformity and ignorance is bliss. Don't leave any reasonable option out, because the memo will be shown to 'the dark side' i.e. windows nerds, and you wouldn't want them trumping you.

Let the managers decide. If it's a windows solution, let the nerds do the spadework. Answer the question what will happen to their service if I come to a sticky end? A similar question is Can They Fire You? If they need you, it's bad management on their part, especially if you meet a sticky end.

They will choose an option. If they don't supply the needs, memo again and accuse them of not being serious because they didn't supply your needs, so they're obviously not serious about this. that usually works.

Alien Bob 11-09-2017 03:31 PM
You could try KDE's krdc (frontend to VNC and RDP) combined with freerdp for the actual RDP implementation.

allend 11-09-2017 05:07 PM
Quote:
Time for a memo to management.
:D
The managers have decided and the solution being rolled out is a separate network that will allow for less locked down environments. Just has not arrived here yet.
Quote:
You could try KDE's krdc (frontend to VNC and RDP) combined with freerdp for the actual RDP implementation.
I had not considered that particular combo.

Thanks for the support and suggestions.

glorsplitz 11-09-2017 07:49 PM
couple stupid questions

why are you accessing and maintaining your Slackware intranet server from work, shouldn't you be working? :tisk:

How far does Windows Applocker go, would it prevent say slackware vbox vm?

GazL 11-10-2017 04:28 AM
Quote:
Originally Posted by allend (Post 5778664)
My work IT department (in their widely debated wisdom) have now implemented Windows Applocker functionality
When you have so many idiot users who will happily run ransomware that someone sends them in email without even a thought, I suppose this is the sort of totalitarian stand you have to make. In retrospect there was a lot to be said for the 3270 era. :)

I'm sorry to hear that you were caught in the collateral damage.

Quote:
Originally Posted by allend (Post 5778864)
The managers have decided and the solution being rolled out is a separate network that will allow for less locked down environments. Just has not arrived here yet.
Phew! at least they didn't decide to move the intranet to IIS!
Dodged a bullet there. ;)

igadoter 11-10-2017 04:32 AM
Is this
Quote:
Originally Posted by business_kid (Post 5778816)
trumping you
somehow related to action of recent US president? I am only curious, English is funny language, or maybe rather people make it funny.

allend 11-10-2017 05:59 AM
Quote:
couple stupid questions
I am from the camp that says there are _no_ stupid questions.
Quote:
why are you accessing and maintaining your Slackware intranet server from work, shouldn't you be working?
Er - The server is at work, hiding machines that otherwise would not be allowed. They are controller PCs that run software that is not supported on current operating systems and that is not compatible with anti-virus software. Accessing the server to check backups, reset printer queues and restart samba mounts is work related on-going maintenance.
Quote:
How far does Windows Applocker go, would it prevent say slackware vbox vm?
The current standard operating system is Windows 7 Enterprise. No VM capability is available. Nor do I want it. I had a bad experience with Hyper V when a power failure on the host irrecoverably corrupted a VM that I had spent quite some time building. What Applocker does is decided by the person setting the policies.
Quote:
When you have so many idiot users who will happily run ransomware that someone sends them in email without even a thought
Explains why I get an email about once a week warning not to click on the latest circulating threat, coming from the same IT department that occasionally sends an email asking you to click on a link to register your machine for an unattended upgrade. The phrase 'go figure' springs to mind.
Quote:
Phew! at least they didn't decide to move the intranet to IIS!
Shh! They might hear you.
Quote:
trumping you
That phrase actually arises from card games where a card suit is declared as the trump suit (e.g. bridge, five hundred) that gives them special powers. A low pip trump card card can overpower a high pip or picture card, hence you have been "trumped". (I will leave the irony of the joker being the most powerful trump card to others.)
Quote:
English is funny language, or maybe rather people make it funny.
Both. On the former, "impossible" might be better while on the latter "we try".

Slax-Dude 11-10-2017 09:47 AM
Quote:
Originally Posted by Alien Bob (Post 5778837)
You could try KDE's krdc (frontend to VNC and RDP) combined with freerdp for the actual RDP implementation.
I think he wants to access Slackware from Windows, not the other way around.

I use xrdp with vnc to access my remote Slackware systems, but would like to try xorgxrdp as alternative to vnc backend.
Performance is OK, although not on the same level as nx (when it worked on Slackware).
I remember following a thread where someone was trying to get a x2go server going on Slackware 14.2 but no news there as well.

business_kid 11-10-2017 10:29 AM
Quote:
Originally Posted by igadoter (Post 5778980)
Is this

somehow related to action of recent US president? I am only curious, English is funny language, or maybe rather people make it funny.
Definitely not. The dumb blonde you mention is the embodiment of Parkin's Peter Principle: "Everyone is promoted to the level at which he is incompetent!" I was thinking of one-upmanship by windows activists.

Gerard Lally 11-10-2017 10:37 AM
Quote:
Originally Posted by Slax-Dude (Post 5779078)
I remember following a thread where someone was trying to get a x2go server going on Slackware 14.2 but no news there as well.
That might have been me. I lost interest in a Slackware terminal server when I realised the teachers refused to work with anything other than Microsoft (probably because Microsoft were giving them freebies like tablets and copies of Office).

OP - have you considered Xorg for Windows (that's if Applocker doesn't block it, of course)?

vcxsrv is an excellent implementation. SSH (with X forwarding) to your Slackware server and X clients will display on your Windows machine.

kjhambrick 11-10-2017 11:19 AM
Quote:
Originally Posted by Slax-Dude (Post 5779078)
I remember following a thread where someone was trying to get a x2go server going on Slackware 14.2 but no news there as well.
Quote:
Originally Posted by Gerard Lally (Post 5779098)
That might have been me. I lost interest in a Slackware terminal server when I realised the teachers refused to work with anything other than Microsoft (probably because Microsoft were giving them freebies like tablets and copies of Office).
And me too in a recent thread but I gave up on x2goserver myself.

I never got it to work with my 'standard' Slackware 14.2 KDE4 Desktop.

There were some recommendations to fall back to to a minimal DE but what's the point in that ? I can always use VNC.

As for allend's questions about xrdp and xorgxrdp ...

Thank you for mentioning these programs !

I've been looking at the documentation and source code for xorgxrdp v0.2.4 as well as the README and the files in the xrdp.SlackBuild ...

I've still got some reading to do but it certainly looks promising and if it works as advertised, this should provide a solution to allow a Windows Client to run X on a Linux Box via RDesktop ...

( :) Boy do I miss the 'Free Forever' NX Version 3.x :) )

Getting xorgxrdp + xrdp running on Slackware 14.2 is now on my ToDo list ... I'll report back when I get a round tuit.

Please let us know if you learn anything too !

Thanks again allend

-- kjh

kjhambrick 11-10-2017 02:23 PM
3 Attachment(s)
allend --

Edit: Fixed a bug and reattached xrdp.SlackBuild.txt

I was not able to build xrdp v0.6.1 on my Slackware64 14.2 + MultiLib system unless I fiddled with the LDFLAGS in the SlackBuild before it invoked ./configure

However, I downloaded xrdp-0.9.4.tar.gz and it built without patches ...

All I really changed in the SlackBuild was the sense of the USE_PAM Variable ( changed it to: NOPAM_OPT="--disable-pam" ) and the list of km-????????.ini files has changed.

EDIT: oops ... I also pounded out the v0.6.1-specific patch work in the SlackBuild.

Anyhow, if you're interested, the xrdp.SlackBuild.txt, xrdp.info.txt and doinst.sh.txt files are below.

Download the official xrdp SlackBuild directory someplace convenient and replace the official SBo xrdp.SlackBuild, xrdp.info and doinst.sh files with the three files below ( i.e. drop the .txt extents ).

Download xrdp 0.9.4 into the SlackBuild Directory and try the xrdp.SlackBuild.

YMMV ... I am running Slackware64 14.2 + Multilib + NVIDIA-Linux-x86_64-384.98.run + a few Alien and SBo Packages on this System ... but xrdp v0.9.4 built OK for me.

My next step is to construct an xorgxrdp.SlackBuild ... will let you know.

-- kjh

willysr 11-10-2017 05:51 PM
xrdp has been updated in my branch and will be included in this week's public update

kjhambrick 11-11-2017 07:20 AM
5 Attachment(s)
Quote:
Originally Posted by willysr (Post 5779240)
xrdp has been updated in my branch and will be included in this week's public update
Wow ! Thanks willysr.

I didn't mean to hijack Phillip Warner xrdp.SlackBuild ...

Oh well, as they say -- in for a penny, in for a pound ... So, here we go :)

After installing xrdp version 0.9.4 via the new xrdp.SlackBuild, I was able to compile the xorgxrdp XOrg modules 'by hand, the old way into a clean TOPDIR:
Code:
configure --prefix=/usr/local/test && make && make install DESTDIR=/usr/local/test
Once I saw what's what, I made an xorgxrdp.SlackBuild

Attached below are the essential pieces for an xorgxrdp.SlackBuild

I have not yet studied the xorgxrdp docs enough to actually test the system but it compiled very cleanly and all the files in the Package are new files so it looks safe enough :)

Anyhow, if you want xorgxrdp:

After installing xrdp ...

Save the attached files into a directory, say xorgxrdp/ ; remove the .txt extension from each file ; optionally chmod 755 xorgxrdp.SlackBuild

Download xorgxrdp version 0.2.4 into your xorgxrdp/ SlackBuild directory and try the xorgxrdp.SlackBuild ( ! check the gpg signature and/or the md5sum which is in the xorgxrdp.info file )

The xorgxrdp modules build fine on my Slackware64 14.2 + MultiLib + NVIDIA-Linux-x86_64-384.98.run system

I will follow up on this !

Here's to high hopes for a new way for Windows Users to connect to a Linux X Desktop !

Have Fun All'Y'All !

EDIT: Found and fixed a bug in the xorgxrdp.SlackBuild where it did not delete the old working directory when rebuilding the Package.

-- kjh

allend 11-11-2017 09:05 AM
2 Attachment(s)
I have been playing with this on a clean install of Slackware64-14.2
Rather than repackaging binaries as kjhambrick seems to be doing, I have been working on building from source. Hence my updated .info files are different.
When building xrdp, I have found it necessary to add --disable-painter and --disable-rfxcodec to ./configure for the build to succeed.
The patches supplied by mancha are no longer needed as they appear in the code.
I have updated the sesman.ini.patch as I think it is important. (No need to allow root login).
I thank kjhambrick for the catch on the new km.???????? files. They appear to be additional keymap definitions.
These are my current versions of SlackBuilds for xrdp-0.9.4 and xorgxrdp-0.2.4 that build without error.
Like kjhambrick, I still need to test.

allend 11-11-2017 09:23 AM
Quote:
OP - have you considered Xorg for Windows (that's if Applocker doesn't block it, of course)?
Consider Applocker as using a whitelist. If the application is not on the list, then it will not run.

kjhambrick 11-11-2017 03:40 PM
Quote:
Originally Posted by allend (Post 5779430)
I have been playing with this on a clean install of Slackware64-14.2
Rather than repackaging binaries as kjhambrick seems to be doing, I have been working on building from source.
allend --

The two slackbuilds I sent ARE SUPPOSED TO compile from source.

The xrdp.SlackBuild is simply a version update of the official SBo Package.

The xorgxrdp.SlackBuild is a clone of the xrdp.SlackBuild ..

No worries four eyes is better than two eyes :)

-- kjh

kjhambrick 11-11-2017 04:07 PM
2 Attachment(s)
allend --

You made me look ...

I left a Version 0.6.1 artifact in the new 0.9.4 xrdp.SlackBuild.

And because xordxrdp.SlackBuild is a clone of xrdp.SlackBuild, it is also borked.

Here are diffs ( same in both SlackBuilds ) and the fixes are attached.
Code:
# diff -Naur xrdp.SlackBuild.bad xrdp.SlackBuild
--- xrdp.SlackBuild.bad 2017-11-10 12:51:01.426283711 -0600
+++ xrdp.SlackBuild    2017-11-11 15:52:03.313098477 -0600
@@ -44,7 +44,7 @@
 rm -rf $PKG
 mkdir -p $TMP $PKG $OUTPUT
 cd $TMP
-rm -rf $PRGNAM-v$VERSION
+rm -rf $PRGNAM-$VERSION
 tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
 cd $PRGNAM-$VERSION
 chown -R root:root .
Note the 'v' in fromt of the $VERSION Variable on the .bad file.

The -v0.6.1 string is an artifact from the rdp Version 0.6.1 File Name.

This bug manifests itself in both SlackBuilds as:

They will compile the source code one time only into a clean Directory.

However if you rerun the SlackBuilds, they fail to rm -rf the build directory and`make` does nothing because the code is up to date !

And they do indeed repackage the binary files that were compiled the first time ( over and over )

Dooh !

I see that willysr caught and squashed the bug in the official Version 0.9.4 xrdp.SlackBuild.

I removed the xrdp.SlackBuild.txt and xorgxrdp.SlackBuild.txt from my previous posts and attached the fixed ones in case anyone grabs them later.

They're also attached here for handiness :)

Thanks for making me look allend !

-- kjh

kjhambrick 11-11-2017 04:23 PM
Quote:
Originally Posted by allend (Post 5779430)
... I have updated the sesman.ini.patch as I think it is important. (No need to allow root login).
Thanks allend !

When bumping a version, especially such a huge bump ( Version 0.6.1 -> 0.9.4 ) I usually try first without any patches.

Everything compiled and xorgxrdp build on my system after installing xrdp ...

I got so excited about the clean build that I forgot to loop back to see what those patches were all about before I installed xrdp :)

The sesman.ini patch definitely needs a review on my System.

Quote:
When building xrdp, I have found it necessary to add --disable-painter and --disable-rfxcodec to ./configure for the build to succeed.
I wondered if the 'extra' NVidia + SBo + Alien goodies on my Laptop might affect the outcome build.

Good catch there too !

Thanks for the TWO heads up !

-- kjh

allend 11-11-2017 09:47 PM
I have been doing some testing after installing xrdp and xorgxrdp on a Slackware64 14.2-current install.
If I start xrdp and xrdp-sesman in the foreground with 'xrdp-sesman -n', then I can connect from another machine using rdesktop. So success!
However it fails to connect if I start xrdp-sesman as a daemon. I am wondering whether this may be due to the lack of PAM.

kjhambrick 11-12-2017 07:06 AM
allend !

That is excellent news !

There is a LOG variable in /etc/rc.d/rc.xrdp which defaults to /dev/null

I wonder if you could see anything in a log file if you turned on logging in /etc/rc.d/rc.xrdp ?

-- kjh

kjhambrick 11-13-2017 04:55 AM
allend --

Yesterday afternoon, I set up an older Laptop with a virgin Slackware64 14.2 Install.

The only non-standard Packages installed on that system are the xrdp and xorgxrdp Packages.

Both of these built and installed cleanly and the system is up on my LAN

I'll be testing an RDeskTop Client from Windows and Slackware as I am able to get a round tuit but I've got some 'real work' to finish this morning so it'll be tomorrow before I can really test it.

Will let you know how it goes.

Thanks !

-- kjh

allend 11-13-2017 06:53 AM
Coming to you from Remote Desktop Client on Windows accessing a KDE session on a Slackware64-current machine. :)
The logs are generated in /var/log/xrdp.log and /var/log/xrdp-sesman.log so no need to mess with the rc.xrdp file for that.
Have fun!

kjhambrick 11-13-2017 07:33 AM
1 Attachment(s)
Woo Hoo !

I am posting this via Firefox from an xfreerdp -> KDE session on the old Laptop that I set up yesterday.

I first ran /usr/bin/xrdp-xwmconfig on the remote system as root and set up KDE as the system-default DM.

Then I connected to the RDesktop session, selected sesman-any and logged in as 'me' and here we are !

I need to figure out a few things ...

Cut-N-Paste does not work (yet).

Startup seems slow to me but now that I am in, everything works as well as any RDesktop Session I've ever used.

This could be a game-changer for us ( at work ) ... GUI Access on our headless Appliances is absolutely necessary for a few Windows Users ( the other thing is Active Directory Auth but that is another thread :) )

Will play some more and report some more.

Attached is a picture :)

-- kjh

kjhambrick 11-13-2017 07:57 AM
Quote:
Originally Posted by allend (Post 5779655)
I have been doing some testing after installing xrdp and xorgxrdp on a Slackware64 14.2-current install.
If I start xrdp and xrdp-sesman in the foreground with 'xrdp-sesman -n', then I can connect from another machine using rdesktop. So success!
However it fails to connect if I start xrdp-sesman as a daemon. I am wondering whether this may be due to the lack of PAM.
allend --

I added a little if-block stanza to /etc/rc.d/rc.local and the inverse to rc.local_shutdown and xrdp and xrdp-sesman start fine and I am able to connect via xfreerdp after a reboot.

One thing I have noticed while fooling with the different session types in the Login Dialog is that if I select an xrdp session, the connection fails and it also leaves behind an xrdp process.

These are the log entries in /var/log/xrdp-sesman.log
Code:
[20171113-07:47:38] [INFO ] A connection received from 127.0.0.1 port 43990
[20171113-07:47:39] [INFO ] ++ created session (access granted): username kjh, ip 192.168.0.6:38494 - socket: 12
[20171113-07:47:39] [INFO ] starting Xorg session...
[20171113-07:47:39] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:5911)
[20171113-07:47:39] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6011)
[20171113-07:47:39] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6211)
[20171113-07:47:39] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20171113-07:47:39] [INFO ] calling auth_start_session from pid 6400
[20171113-07:47:39] [DEBUG] Closed socket 7 (AF_INET 127.0.0.1:3350)
[20171113-07:47:39] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20171113-07:47:39] [INFO ] Xorg :11 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log 
[20171113-07:47:49] [ERROR] X server for display 11 startup timeout
[20171113-07:47:49] [CORE ] waiting for window manager (pid 6401) to exit
[20171113-07:47:49] [ERROR] X server for display 11 startup timeout
[20171113-07:47:49] [ERROR] another Xserver might already be active on display 11 - see log
[20171113-07:47:49] [DEBUG] aborting connection...
[20171113-07:47:49] [CORE ] window manager (pid 6401) did exit, cleaning up session
[20171113-07:47:49] [INFO ] calling auth_stop_session and auth_end from pid 6400
[20171113-07:47:49] [DEBUG] cleanup_sockets:
[20171113-07:47:49] [DEBUG] cleanup_sockets: deleting /tmp/.xrdp/xrdp_chansrv_socket_11
[20171113-07:47:49] [DEBUG] cleanup_sockets: deleting /tmp/.xrdp/xrdpapi_11
[20171113-07:47:49] [DEBUG] cleanup_sockets: failed to delete /tmp/.xrdp/xrdpapi_11
[20171113-07:47:49] [INFO ] ++ terminated session:  username kjh, display :11.0, session_pid 6400, ip 192.168.0.6:38494 - socket: 12
This is the 'extra' xrdp process ( note the PPID -- it is owned by the Daemon PID )
Code:
# psgrep xrdp
USER              PID  PPID %CPU %MEM    VSZ  RSZ TTY  STAT  STARTED COMMAND
root              3858    1  0.0  0.0  20600  2920 0    S    07:12:22 /usr/sbin/xrdp
root              3860    1  0.0  0.0  30960  2824 0    S    07:12:22 /usr/sbin/xrdp-sesman
root              6396  3858  0.0  0.1  39628 15036 0    S    07:47:30 /usr/sbin/xrdp
If I try to run `/etc/rc.d/rc.xrdp stop` after such a failed session then it hangs while trying to kill the 'extra' xrdp session.

The only way to kill the 'extra' session is via `kill -9 $PID`

Anyhow, I need to fix this too :)

More work to do but this approach has promise !

Thanks again for turning me onto xrdp / xorgxrdp !

-- kjh

Added to /etc/rc.d/rc.local:
Code:
#
# kjh added rc.xrdp ...
#
if [ -x /etc/rc.d/rc.xrdp ]
then
  /etc/rc.d/rc.xrdp start
fi
Added to /etc/rc.d/rc.local_shutdown
Code:
#
# kjh added rc.xrdp ...
#
if [ -x /etc/rc.d/rc.xrdp ]
then
  /etc/rc.d/rc.xrdp stop
fi

allend 11-13-2017 07:19 PM
I have been testing connecting to a Slackware64 14.2 stable install.
Perhaps check the sesman log for a line like this.
Quote:
/usr/libexec/Xorg.wrap: Only console users are allowed to run the X server
I have added a file /etc/X11/Xwrapper.config containing
Code:
allowed_users = anybody
to get things working.

kjhambrick 11-14-2017 06:03 AM
allend --

Everything seems to work fine here -- I can connect to a KDE Desktop via the sesman-any Protocol from Linux via xfreerdp / rdesktop or from Windows RDP.

I don't see that log message in either log file.

I've got to put this aside until this weekend when I can 'play'.

I'll let you know if I run into any issues.

Please let me know how it goes for you.

Thanks.

-- kjh

kjhambrick 11-21-2017 06:47 AM
allend --

Before I lose track of xrdp + xorgxrdp ...

I've been using xrdp for a week now to connect to various Slackware64 14.2 Boxen from Linux and Windows ( ! and even from my Nook ! ) with GREAT results.

In addition, I've found X11RDP-RH-Matic for our CentOS 6 Boxes at work ... No more stale nxserver version 3.5 RPMs on our Customer's Systems !!! ( :) ! woo hoo ! :) )

Anyhow ... before I lose track of what we did to get xrdp + xorgxrdp running on Slackware 14.2, I wanted to compare notes with you so I could send an updated xrdp.SlackBuild and a new xorgxrdp.SlackBuild to SBo.

Have you made any additional changes to the two SlackBuilds that you posted here on this thread ?

If not, I'll try to reconcile our two sets of SlackBuilds and post here one more time for your review ( this weekend, probably ).

Once we've blessed the scripts, I'll send them off to the SBo Team.

Last thing ... do you want to 'own' the SBo xorgxrdp.SlackBuild ?

If you do, please do !

If not, I can take it.

Thanks for all the effort, allend !

-- kjh

allend 11-21-2017 08:48 AM
Funny that you are posting now, as I have just finished a session installing a label printer driver in a Windows VM at work, and I was using xrdp to run Firefox to access http://localhost:631 to diagnose a credentials problem. Hopefully there will be labels hanging out of the printer when I get to work tomorrow.

No - I have not changed the Slackbuilds that I posted although I have been wanting to try the
Code:
--enable-fuse          Build fuse(clipboard file / drive redir)
option when building xrdp out of curiosity. I make use of the -r disk: option to rdesktop for moving files from time to time.
You are welcome to the blame and the effort to submit to SBo. The real credit belongs to the writer of the original SlackBuild script (Phillip Warner). Thanks for your enthusiasm as it did drive me along in getting the version update to work.

The scripts seem to be working without issue on Slackware 14.2, but on -current xrdp still fails to run as a daemon for me, perhaps due to different gcc or Xorg versions.

kjhambrick 11-21-2017 08:55 AM
allend --

Hmmm ... gotta look at the --enable-fuse configure option myself ...

I'll post what I come up with for one last look-see before sending it on to SBo.

Thanks again !

-- kjh

allend 11-22-2017 07:50 AM
I have built xrdp with the --enable-fuse configure option on Slackware64 14.2.
I had to do the configuration in post#27 to get a connection using rdesktop with the -r disk option.
It worked on the first connection, allowing me to copy files in and out of the $HOME/thinclient_drives directory that was created on the computer running xrdp. Yay! it works.
But after disconnecting then trying to reconnect, I hit a problem where I could not successfully connect. On investigation, I found that the $HOME/thinclient_drives directory on the xrdp server was left with weird permissions.
I have done some googling and found this, especially the last post, which seems to be directly relevant. Running
Code:
fusermount -u "$HOME/thinclient_drives"
directly on the xrdp server restores the $HOME/thinclient_drives directory permissions, so may need to add that to the startup script.
A little more configuration and testing is required.

allend 11-23-2017 10:29 AM
I have looked some more and decided that there is a good reason for the --enable-fuse configure option being disabled by default. Until upstream properly implements xfuse_deinit_xrdp_fs() with something apart from a placeholder function, then the $HOME/thinclient_drives directory issue will remain. It may be feasible to hack around this by putting a watch on /var/run/ConsoleKit/database to look for X session shutdowns, but it would be a crude hack and not worth my effort.

allend 01-23-2018 07:24 AM
i have just found that xrdp v0.9.5 has been released including a fix for a local denial of service CVE-2017-16927. Seems to build and run OK with just a couple of small adjustments to the SlackBuild posted earlier to account for the version name and the source code file name of xrdp-0.9.5.tar.gz
Code:
--- xrdp-0.9.4/xrdp/xrdp.SlackBuild        2017-11-11 22:52:58.000000000 +1100
+++ xrdp-0.9.5/xrdp/xrdp.SlackBuild        2018-01-23 12:38:41.909051396 +1100
@@ -4,7 +4,7 @@
 # Written by Phillip Warner <pc_warner@yahoo.com>
 
 PRGNAM=xrdp
-VERSION=${VERSION:-0.9.4}
+VERSION=${VERSION:-0.9.5}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}
 
@@ -45,7 +45,7 @@
 mkdir -p $TMP $PKG $OUTPUT
 cd $TMP
 rm -rf $PRGNAM-$VERSION
-tar xvf $CWD/v$VERSION.tar.gz
+tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
 cd $PRGNAM-$VERSION
 chown -R root:root .
 find -L . \


All times are GMT -5. The time now is 01:44 PM.