UPDATE : Version 3 now officially released: http://scarygliders.net/2013/07/25/x11rdp-o-matic-version-3-now-released/
v3.0beta of my o-matic build-and-configure tools is working pretty damn good, and is available for download from my github repository.
To grab it, use :
git clone -b v3.0beta3 https://github.com/scarygliders/X11RDP-o-Matic.git
Then run in the usual manner.
Significant changes
- Refactored the scripts; incorporated the relevant parts of TextFrontEndIncludes into the relevant main scripts. No more sourcing of that file. It has now been removed.
- It will make Debian packages – an x11rdp package, and an xrdp package. The x11rdp package includes everything that was compiled and placed in /opt/X11rdp. The xrdp package includes everything that was compiled for xrdp
- The tool will build packages whether using the FreeRDP source or the neutrinolabs source (–bleeding-edge)
- Other miscellaneous tidy-ups to o-matic too numerous to mention here – look 'em up on github if you're that fascinated ;) …
- RDPsesconfig now recognises Lubuntu B)
- For "unknown/untested" distros, RDPsesconfig now actually has a "select desktop" menu – this was omitted in earlier versions and I now have fixed this in Beta 3.
Please test this beta version and if you have suggestions/patches/etc, use the resources at the Github repository to raise issues, pull requests etc.
X11rdp-o-Matic v3.0Beta3 Available for testing,Enjoy. Happy testing! And – good luck ;)
Share the knowledge :
Worked flawlessly on Ubuntu 12.04 + Lubuntu desktop on Amazon AWS. Thanks!
Hi,
I would like to test it, but I can’t download it from git. It want user/pass. I’m newbie with git and sorry for maybe stupid question.
I have no idea why it would be asking you for a username/password. Did you copy/paste exactly the “git clone” line I give above?
I download it from website:]
I tried it, but in the end it wrote:
chown: invalid user: xrdp:xrdp
update-rc.d: /etc/init.d/xrdp: file does not exist
On another site, I found and added this:
useradd -d /var/run -r -s /bin/false xrdp
and then did chown on rsakey.ini file
Then I copied from /etc/xrdp/xrdp.sh to /etc/init.d/ and ran sudo update-rc.d xrdp defaults.
Problem is that after xrdp start, it says : xrdp is not executable. From xrdp file, it stop on “if ! test -x $SBINDIR/xrdp”.
Now I dont know what next:)
Ubuntu 12.10. kernel 3.10. x64
This help:
sudo apt-get remove xrdp
sudo apt-get install xrdp
sudo apt-get remove xrdp
and again run X11rdp-o-matic.sh
Now I have another error:
xrdp-keygen: error while loading shared libs: libcommon.so.0
But I think I have problem with path somewhere.
?
No, you should not have to do ANY of that – I think you might have downloaded the current “master” , which is version 2.5
Try this : http://github.com/scarygliders/X11RDP-o-Matic/zipball/v3.0beta3 and re-run the tools.
As I wrote, I had something wrong with xrdp, so remove, install, remove help.
Error with xrdp-keygen I already solved (copied libs from created xrdp package to libs folder and registered it)
Next error was with Log file (var/log/xrdp.log). It wasn’t there, so I created a then it worked!
So very thanks for this:) It really work! And sorry for spamming here.
No Need to apologise – every bit of feedback is useful!
Regards :)
Hi Kevin,
Thanks for a good piece of work! It works well for Ubuntu 12.04 on a Hyper-V server. The only issue I’m worried about is mouse scrolling, which is virtually unusable. I’m connecting from a Mac using Microsoft RDP Client 2.01. Have you experienced or know about any problems with scrolling, and perhaps give some advice?
Thanks a lot,
Denis
Hi dinvlad,
I haven’t noticed mouse scrolling problems when using the rdesktop or freerdp clients under Linux – I don’t use Apple stuff so I’ll never encounter those ;)
You might want to ask in the xrdp-devel mailinglist, where Jay Sorg and the other contributors to xrdp are usually quite good at answering queries hang out. Details are at https://lists.sourceforge.net/lists/listinfo/xrdp-devel .
Regards.
Hello Kevin,
Do ANY of your scripts or your work with xrdp fix the issue of disconnected sessions hanging around? The sesman.ini settings don’t do anything and I have not found a valid workaround. I have been trying to fix this for 3-4 versions of Ubuntu/Mint with no success. I run a Linux Mint virtual machine with less “lockdowns” that is outside our firewall that our users can connect to and browse the internet in a less locked down environment. There are never more than 7-10 people at any given time signed on browsing, but over the course of a days work there may be 50-100 people that have signed on at one point or another. It crashes the machine because it refuses to tear down connections when someone disconnects. So I have to have scripts that reboot the virtual machine every hour or two. This of course kills ACTIVE sessions instead of inactive ones.
My script is essentially a build tool, the actual functionality is provided by the resultant compiled binaries/system, so, no, my scripts don’t directly affect how xrdp behaves after compilation/installation – apart from RDPsesconfig which of course configures what desktop a user will get upon login.
How are your users ending their sessions? Are they actually logging out? Or are they just closing their RDP client? If it’s the latter, then of course the RDP session will hang around until that user reconnects to it.
Have you looked at /etc/xrdp/sesman.ini ?
There is an option there to kill sessions on disconnect, which sounds like what you want. Have you tried that?
Thanks for the reply. Yes, I’ve tried that setting but all the documentation online for the sesman.ini seem to indicate that killdisconnected is not fully implemented so doesn’t actually do anything yet. I can verify that behavior in my testing.
Yes, you are right my users are clicking the X to close the RDP window instead of logging out even despite training and threats against their family. There simply needs to be a technological solution because I can’t depend on users to do it properly. Like I said, there are never more than 8-10 concurrent users at most, but over the course of a day that can be 50-100 unique users with most of them having sessions hung open. Giving the virtual machine more RAM just increases the amount of time before it fails.
I suggest asking in the xrdp development mailing list, as I suggested to another chap, above.
Details of this mailinglist can be found at : https://lists.sourceforge.net/lists/listinfo/xrdp-devel .
Other than threatening your users further, I don’t know if anything can be done in an automated fashion – perhaps a cron job called script could be written to look for disconnected sessions?
Actually, whilst typing this reply, I can think of one way of doing this…
A script/utility which monitors three things;
1) The log file /var/log/xrdp.log : this file logs connections made to xrdp, including whether a connection is made successfully. FOr example, when I logged into my local machine;
[20130718-17:28:10] [INFO ] ++ created session (access granted): username kcave, ip 127.0.0.1:37106 – socket: 8
2) Similarly, the log file /var/log/xrdp-sesman.log;
[20130718-17:28:10] [INFO ] starting X11rdp session…
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: NULL:NULL – socket: 9
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: NULL:NULL – socket: 9
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: NULL:NULL – socket: 9
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: 127.0.0.1:56949 – socket: 8
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: NULL:NULL – socket: 7
[20130718-17:28:11] [INFO ] An established connection closed to endpoint: 127.0.0.1:56949 – socket: 8
[20130718-17:28:11] [INFO ] X11rdp start:X11rdp :10 -geometry 1440×900 -depth 24 -bs -ac -nolisten tcp -uds
[20130718-17:28:11] [INFO ] starting xrdp-sessvc – xpid=8043 – wmpid=8042
Now, in xrdp.log, the number 37106 is the port number used for the connection.
And in xrdp-sesman.log, the 8043 is the PID number of the X11rdp server back-end for this session.
3) You can now use netstat to monitor this connection thusly;
# netstat -n | grep 37106tcp 0 0 127.0.0.1:3389 127.0.0.1:37106 ESTABLISHED
tcp 0 0 127.0.0.1:37106 127.0.0.1:3389 ESTABLISHED
So you now have a way of keeping track of that connection. If I disconnect from that session by just closing the rdp client;
# netstat -n | grep 37106tcp 0 0 127.0.0.1:37106 127.0.0.1:3389 TIME_WAIT
Then you can tell this is so because the system now sees TIME_WAIT – which basically means “I’m going to hold this connection open for a bit to see if it’s just a temporary blip in the connection”
It’s at this point you can tell that a connection has been lost, and then you can use the
killcommand to kill off the X11rdp process (PID = 8043), hence completely ending that session.If you can make such a monitoring script or utility, then go ahead. If not, I’m willing to give it a try for a fee ;)
Regards.
Hi, I installed the beta on mint 15 and can connect to it via rdp on my win7 machine, but the session "freezes" when I try to drag a window on my desktop.
Whenever I use the vnc option instead of x11rdp everything works.
How do I fix this?
If it's freezing whilst using mstc on Win7, then I'd probably tell Jay Sorg (who writes the X11rdp back-end) about it, on the xrdp-devel mailinglist, which I've mentioned in comments above.
My utility is a build/install tool for it. :)
Regards,
Kevin.
I’ve used scarygliders in the past and had no problems on ubuntu.
Just did a git on the most recent v3 and installed it.
when I did:
sudo ./RDPsesconfig
I specific LXDE and then ALL USERS and the “Creating .xsession files displays the following which doesn’t look right as all the .xsession entry’s use an entry of “” ??
����������������������creating .xsession files…��������������������������
� Processing… �
����������������������������������������������������������������������������ij
� Creating .xsession file for libgpm: in with entry “”.. �
�chown: invalid user: ‘libgpm::libgpm:’ �
�Creating .xsession file for zero in with entry “”.. �
�chown: invalid user: ‘zero:zero’ �
�Creating .xsession file for screen in with entry “”.. �
�chown: invalid user: ‘screen:screen’ �
�Creating .xsession file for dimension, in with entry “”.. �
�chown: invalid user: ‘dimension,:dimension,’ �
�Creating .xsession file for assuming in with entry “”.. �
�chown: invalid user: ‘assuming:assuming’�����������������������������������
Creating .xsession file for 80×25. in with entry “”..
chown: invalid user: ’80×25.:80×25.’
Creating .xsession file for ALL in with entry “”..
chown: invalid user: ‘ALL:ALL’
Creating .xsession file for USERS in with entry “”..
chown: invalid user: ‘USERS:USERS’
What distribution did you run o-matic on?
Also, if you ran v3 then this v3.0beta post is the wrong one to reply in ;)
Someone else had a similar problem if you read the replies in the v3.0 proper post – basically it was because they didn’t have “normal” users and didn’t select them for configuration – try just selecting your actual users that will log in via RDP.
If you tell me what distribution you tried this on, I’ll try it in a VM and see where the RDPSesconfig user pick routine is failing to ignore system users – it shouldn’t be, or wasn’t in the past – I’m quite proud of that wee bit of code ;) It may be that the user-pick routine I wrote way back has to take additional steps to ensure system users in more recent distros don’t get added in as users to be configured.
Regards!