UPDATE : Version 3 now officially released: http://scarygliders.net/2013/07/25/x11rdp-o-matic-version-3-now-released/

It's here! It's improved! It works even better!

I call this the "ssta release", in honour of a pal of mine who made a request which I've now implemented. ( --justdoit option, see below).

I have sweated and toiled, lost sleep, learned a lot, re-learned a lot, tested, tested again, and ended up with something which should work for just about everyone – everyone that is, who's users are local to the system – anyone using Active Directory to login still won't be handled by the RDPsesconfig utility yet – if you really want this, please donate to encourage it! I am unemployed, living in Japan, waiting until my house/land are sold before I can move back to my native Scotland – in the meantime, I'm using this time to do useful and unpaid stuff, so what I'm asking is, if you like what I'm doing and want to show your appreciation, hit the donate button! You don't need to be a Paypal member to do so :)

Did I mention the Donate button? Hit that thing Like A Boss, or The Fist Of An Angry God, or something, but just do it. Please B)

And I'd like to thank those who have sent a donation so far. I have received 2 "General" donations (from the button on the left hand sidebar) , and 1 specific donation from the donate button on the X11rdp-o-matic/RDPsesman V1 post. THANK YOU! You guys are awesome!

Anyway onto Version 2…

v2.5 Changelog

dpkg-status response has changed in Debian Wheezy! Changed the package status test to reflect this, which will also work with older distros.

v2.4 Changelog

set LANG so that dpkg etc. return the expected responses so the script is guaranteed to work under different locales – many thanks to reader Pedro Alves

v2.3 Changelog

Now works and tested with Ubuntu 10.04 LTS

v2.2 Changelog

RDPsesconfig

fixed naïve grepping for username in /etc/passwd. (thanks to reader Jeroen!) Utility should now not confuse username "tim" with the entry "rtkit:x:110:119:RealtimeKit,,,:/proc:/bin/false" in /etc/passwd , for example, and should now place the correct .xsession in the correct place.

V2.1 Changelog….

X11rdp-o-Matic

corrected error in package status test condition on line 166 – thanks to Daniel for pointing it out ;)

V2 Changelog…

X11rdp-o-Matic

Added package repository update before checking for required packages
Modularized for future multiple dialog front-ends
Added a text dialog front-end
Added a check for running on a non-X display terminal (will revert to text-only if so)
Uses the text mode front-end by default – Zenity is limited and rubbish!
Added command line parameters: --justdoit , --nocpuoptimize , --zenityfrontend , --keepsource , --nocleanup
Now runs in a text only environment – suitable for "Server" distro variants with no Xorg installed as yet, or basically for anyone who prefers the text interface over the Zenity one.
Added a non-interactive, "just do it" mode so script will run from start to end, with "sane" defaults
Really tidied up the script, should make it easier to read and edit later
Source code is downloaded to inside wherever the ScaryMatic directory is located
Added alteration of xrdp source code Makefile.am so the PID file is now in /var/run/xrdp/
Changed "PIDDIR=/var/run/" to "PIDDIR=/var/run/xrdp/" in the xrdp init script

RDPsesconfig

Added package repository update before checking for required packages
Modularized for multiple dialog front-ends
Added a text dialog front-end
Added a check for running on a non-X display terminal (will revert to text-only if so)
Uses the text mode front-end by default – Zenity is limited and rubbish!
Added command line parameter: –zenityfrontend – seriously? use the text front-end, it's better.
Really tidied up the script, should make it easier to read and edit later
Source code is downloaded to inside wherever the ScaryMatic directory is located
Removed the experimental PolicyKit rules generator. System admins should consider implementing their policies carefully.

What's New

The Text Interface

I implemented a pure text interface for both utilities, using dialog as the front-end. It is now the default interface, and I advise you keep using it.

This has a number of advantages over the original Zenity interface;

1) Now means that "server" editions of distros without GUI's can use X11rdp-o-matic utility to install X11rdp and xrdp

2) The text interface has more features than the Zenity interface (able to select all the users in the list in RDPsesconfig for example)

3) The Zenity interface will be dropped completely in the next release of the utilities – Zenity is not as useful as Xdialog was, and seems to be very buggy.

If you're running the dialog interface in a terminal window on a desktop, you can click the buttons with the mouse, anyway.

Just Do It mode...

Starting X11rdp-o-matic.sh with the --justdoit switch will download, compile, install, and configure X11rdp and xrdp from start to finish, with no user interaction required. This fire-and-forget mode is suitable for busy admins like my friend "ssta" who don't have the time for fancy schmancy front-ends or GUI's ;) You're welcome.

--justdoit will trigger non-interactive mode, will display plain text with no dialogs, by default will use additional cpu's in the compilation of X11rdp (make -j N+1 , where N is the number of cpu cores available), unless requested not to by use of the --nocpuoptimize switch.

Example of use;

sudo ./X11rdp-o-matic.sh --justdoit : will download, utilize all cpu cores for compilation, compile, install, and configure X11rdp and xrdp automatically from start to finish.

sudo ./X11rdp-o-matic.sh --justdoit --nocpuoptimize : same as above but without the cpu utilization.

Cleanup of source code after installation…

By default, all downloaded source trees will be completely removed from the system, after compilation and installation – this was a feature request.

You can use the --nocleanup switch to keep the source trees after installation.

Example of use;

sudo ./X11rdp-o-matic.sh --nocleanup : Starts the utility in interactive text mode and will not delete the source trees after use.

sudo ./X11rdp-o-matic.sh --justdoit --nocleanup : Starts the utility in non-interactive mode and will not delete the source after completion.

Re-use source code

Related to the above, if you chose to keep the source, then on next use of the utility you should issue the --reuse switch , which will re-use the source trees – use this for non-interactive mode if you still have the source trees from last use.

Example of use ;

sudo ./X11rdp-o-matic.sh --justdoit --reuse : will re-use the source trees BUT WILL delete the source trees after completion!

sudo ./X11rdp-o-matic.sh --justdoit --reuse --nocleanup : same as above but will KEEP the source after completion.

Source code download location…

Speaking of source code – it is now downloaded to within the Scarymatic directory, instead of using /root, which was a bad idea from the start and I have no idea why I did that in version 1 :)

xrdp source code automatically altered after download

The upstream source has the .pid files generated by xrdp and sesman, located within /var/run. Since nowadays /var/run is a symbolic link to /run , /run seems to become owned by xrdp. I have now implemeted an automatic alteration of the source code so that the .pid files are now created within /var/run/xrdp – similarly, the xrdp init script has been altered to match this change.

Default system PolicyKit rules prevent users logged in via RDP from doing stuff locally logged in users can do

Like the title says, the default system rules prevent RDP users from, say for example, ejecting a CD/DVD from the drive. I placed an experimental rules generator which didn't work very well, and when it did work, it gave RDP users full access to do exciting things like reboot or halt the system without needing the admin password – that's a really bad idea, and now that I have learned a lot about how PolicyKit works, I have completely removed the policykit stuff from the utilities.

Instead, it is up to you – the administrator of the system – to decide who gets to do what on your system – I tell you how to do this in another article I have written in parallel with this post. It's not difficult but does entail editing XML files. I was considering making the RDPsesconfig utility parse the XML files and then being able to edit them, but seriously, parsing XML files in Bash script would be very difficult and fidgety to get right, and due to the nature of what PolicyKit does, I'm probably going to write a program to parse the PolicyKit action XML files, edit them and re-save them, in Python as a separate and new utility.