I'm calling xfreerdp from TCE to connect directly to the RDP server. I've been trying to find the right cli options for xfreerdp to use for this, but documentation is pretty light on this and I have yet to find something that works.

If I run dmesg on the thin client device from within the TCE desktop, I can see that my flash drive is recognized, but it's not getting mounted. That sounds like a udev issue within debian, but I was hoping somebody on the list had already solved this problem.

Thanks. Seth

On 11/07/2017 12:37 PM, Stefan Baur wrote:

Am 07.11.2017 um 18:59 schrieb Seth Galitzer:

...

I know this is a FAQ, but I've been unable to find an answer on my own.

I'd like to be able to redirect a local USB flash drive to a remote Windows host. I'm using TCE from a debian image deployed to my thin client devices.

If this is possible, what's the magic recipe to make this work?

X2Go doesn't do generic USB device forwarding - at all. What it can forward are local file shares - that's also how printing is currently handled. A USB mass storage device or optical drive is exposed as a file share, then forwarded - as long as we're talking about native X2Go sessions, that magic recipe is the package x2gousbmount (on the client) and the patch for it that's part of the TCE-Live build scripts.

However, for RDP, we currently don't have anything like that built in. Are you using RDP in direct mode or with an X2Go Server inbetween?

With direct mode, you might be able to pass /usb or /drive as a parameter to xfreerdp in the session config. Untested, but might already do the trick. For RDP + X2Go Server mode, things will probably be a bit more hairy.

Kind Regards, Stefan Baur

---

x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user

-- Seth Galitzer Systems Coordinator Computer Science Department Kansas State University http://www.cs.ksu.edu/~sgsax sgsax@ksu.edu 785-532-7790

On 11/07/2017 03:49 PM, Stefan Baur wrote:

Am 07.11.2017 um 21:41 schrieb Seth Galitzer:

...

I'm calling xfreerdp from TCE to connect directly to the RDP server. I've been trying to find the right cli options for xfreerdp to use for this, but documentation is pretty light on this and I have yet to find something that works.

If I run dmesg on the thin client device from within the TCE desktop, I can see that my flash drive is recognized, but it's not getting mounted. That sounds like a udev issue within debian, but I was hoping somebody on the list had already solved this problem.

So your actually have two problems:

1. getting the automounter to mount your flash drive.

I've found two ways to do this so far: A) Install usbmount package (https://usbmount.alioth.debian.org/). I've tested this and it works, but needs some tweaking to produce a reliable/duplicatable mount point. This claims to work for vfat, ext* and hfs.

B) Configure udev to use pmount when a USB storage device is detected (https://unix.stackexchange.com/a/124060). I haven't tested this yet, but if the above option works, I'm guessing this is the manual implementation of it, so it should work.

2. getting xfreerdp to forward that mountpoint to the RDP server.

This is proving difficult if not impossible. Supposedly, some invocation of the /drive option should work, but I have not found good documentation on syntax, nor have suggestions I found so far worked. Use of the /usb option is not recommended as supposedly this is for redirecting devices, such as printers or HID. There is even much discussion among freerdp devs and users on how to properly implement this functionality.

For now, I'm telling my users it's not doable, but I'm still looking for a way to do it. Suggestions are welcome.

You could try to research them independently. Let's start with 2): How about running xfreerdp on a Linux "fat client", and tinkering with its cli options until you get it to forward a local directory?

Regarding 1): Funny coincidence, I was trying out the usb mass storage automounter today and realized that in its current incarnation, it can only handle VFAT - not ext*-formatted media. I'm planning to improve the code in question $SOON, but at the moment, I would suggest double-checking that your flash drive is in VFAT format.

Kind Regards, Stefan Baur

Thanks. Seth

-- Seth Galitzer Systems Coordinator Computer Science Department Kansas State University http://www.cs.ksu.edu/~sgsax sgsax@ksu.edu 785-532-7790

Am 08.11.2017 um 00:39 schrieb Stefan Baur:

...

...

2. getting xfreerdp to forward that mountpoint to the RDP server. This is proving difficult if not impossible. Supposedly, some invocation of the /drive option should work, but I have not found good documentation on syntax, nor have suggestions I found so far worked. Use of the /usb option is not recommended as supposedly this is for redirecting devices, such as printers or HID. There is even much discussion among freerdp devs and users on how to properly implement this functionality. My understanding is that you need to specify a share name along with the local path, so something like

/drive:flashmedia,/media/Generic_Flash_Disk/sda1 /drive:home,/home/user

should result in \\TSCLIENT\flashmedia and \\TSCLIENT\home becoming available inside the RDP session.

I just had a chance to try this out myself. Problem is, while it works on a regular Linux box that has X2GoClient installed, it failed on current X2Go-TCE-Live images. This is because we were missing a package - libfreerdp-plugins-standard - and its dependencies in the images.

Please use

export LBX2GO_CONFIG='https://github.com/LinuxHaus/live-build-x2go::feature/openbox'

or

export LBX2GO_CONFIG='https://github.com/LinuxHaus/live-build-x2go::feature/openbox-magic-pixel-wo...'

for your build, that should fix it. I will poke Juri to add these changes to the official X2Go repo once I've properly tested them.

I was able to mount the thinclient's /media directory using /drive:media,/media with xfreerdp in direct RDP mode after adding these additional packages to the image. \\TSCLIENT\media showed the content of the TC's local /media folder (as this is where the automounter mounts all removable media, you should be good to go by forwarding just that path).

Kind Regards, Stefan Baur

-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

Am 11.11.2017 um 16:10 schrieb Ulrich Sibiller:

I mentioned some possible solutions for the generic approach some time ago, namely http://www.incentivespro.com/usb-server.html and http://usbip.sourceforge.net/. So, Seth, maybe you could try those and report the results. Maybe integration proves not to be so difficult.

Yeah, these are mentioned over and over again, yet people always spontaneously decide it's not that important to them when they see the price tag that an integration into X2Go would have.

-Stefan

-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

I've been trying for a couple of weeks now to build a TCE image that this actually works on. I applied your new script to my latest attempt today and finally discovered that the libfreerdp-plugins-standard package is not actually getting installed in the chroot image. As a result, while the USB flash drive is getting correctly mounted in the expected location, when I run my RDP connection, I do not see the share presented by the tsclient host.

I traced the log during the build process and it looks like the package is getting properly added, but when I boot the image and look at the installed packages, it is not actually there. I'm not seeing any errors or where it is getting removed before the squashfs image is rolled. Here's an excerpt:

$ grep freerdp-plugins build.log libfreerdp-plugins-standard libfreerdp-primitives1.1 libfreerdp-rail1.1 Get:411 http://security.debian.org/ jessie/updates/main libfreerdp-plugins-standard i386 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1 [236 kB] Selecting previously unselected package libfreerdp-plugins-standard:i386. Preparing to unpack .../libfreerdp-plugins-standard_1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1_i386.deb ... Unpacking libfreerdp-plugins-standard:i386 (1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) ... Setting up libfreerdp-plugins-standard:i386 (1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) ... libfreerdp-plugins-standard is already the newest version.

If I try "dpkg -l|grep freerdp-plugins" on the booted client, I don't get any results. Not even a package in "rc" state". If I grep for freerdp, I get the rest of the packages requested in the overlay list.

I should note that I'm using a very lightly-patched x2goclient v4.1.1.1 in this build and a slightly modified version of 2900-x2go-thinclientconfig from the chroot overlay, but I don't think these are related to this build issue. I will double-check the latter to make sure.

Any thoughts as to what might be causing this or possible work-arounds this?

Thanks. Seth

On 11/20/2017 08:24 AM, Stefan Baur wrote:

Am 07.11.2017 um 23:56 schrieb Seth Galitzer:

...

On 11/07/2017 03:49 PM, Stefan Baur wrote:

...

Am 07.11.2017 um 21:41 schrieb Seth Galitzer:

...

I'm calling xfreerdp from TCE to connect directly to the RDP server. I've been trying to find the right cli options for xfreerdp to use for this, but documentation is pretty light on this and I have yet to find something that works.

If I run dmesg on the thin client device from within the TCE desktop, I can see that my flash drive is recognized, but it's not getting mounted. That sounds like a udev issue within debian, but I was hoping somebody on the list had already solved this problem.

So your actually have two problems:

1. getting the automounter to mount your flash drive.

I've found two ways to do this so far: A) Install usbmount package (https://usbmount.alioth.debian.org/). I've tested this and it works, but needs some tweaking to produce a reliable/duplicatable mount point. This claims to work for vfat, ext* and hfs.

B) Configure udev to use pmount when a USB storage device is detected (https://unix.stackexchange.com/a/124060). I haven't tested this yet, but if the above option works, I'm guessing this is the manual implementation of it, so it should work. I have updated the X2Go-automounter script. Assuming you are using the build instructions at <https://wiki.x2go.org/doku.php/doc:howto:tce>, especially <https://wiki.x2go.org/doku.php/doc:howto:tce#live-patching_the_build>, you should now be able to automatically mount VFAT, NTFS, HFS, HPFS out of the box (as previously mentioned, under /media/vendor_model/partitiondevice). Once my further changes (currently only stored locally on my computer) make it to the git repos, you will also be able to access ext* filesystems, albeit in read-only mode only.

So neither usbmount nor udev/pmount should be necessary. If automounting still fails for you without them, please provide more info about your setup.

Kind Regards, Stefan Baur

-- Seth Galitzer Systems Coordinator Computer Science Department Kansas State University http://www.cs.ksu.edu/~sgsax sgsax@ksu.edu 785-532-7790

On 11/20/2017 07:09 PM, Stefan Baur wrote:

Am 20.11.2017 um 23:42 schrieb Seth Galitzer:

...

I've been trying for a couple of weeks now to build a TCE image that this actually works on. I applied your new script to my latest attempt today and finally discovered that the libfreerdp-plugins-standard package is not actually getting installed in the chroot image. As a result, while the USB flash drive is getting correctly mounted in the expected location, when I run my RDP connection, I do not see the share presented by the tsclient host.

Ah-ha!

[libfreerdp-plugins-standard package missing]

...

If I try "dpkg -l|grep freerdp-plugins" on the booted client, I don't get any results. Not even a package in "rc" state". If I grep for freerdp, I get the rest of the packages requested in the overlay list.

I should note that I'm using a very lightly-patched x2goclient v4.1.1.1 in this build and a slightly modified version of 2900-x2go-thinclientconfig from the chroot overlay, but I don't think these are related to this build issue. I will double-check the latter to make sure.

Any thoughts as to what might be causing this or possible work-arounds this?

Are you using the timestamp feature I added? If so, I would first compare timestamps of your running system and of the image you built. cat x2go-tce-timestamp in the builddir vs. the build number you see at the local or ssh login prompt (cat /etc/issue, bottom line), or, lacking the timestamping code in your build, comparing the output of

# in the builddir TIMESTAMP=$(stat -c %Y ./config/includes.chroot/lib) HUMANTIMESTAMP=$(date --date="$TIMESTAMP") echo "Build Version: $TIMESTAMP ($HUMANTIMESTAMP)"

# in the booted TCE for TIMESTAMPFILE in /lib/live/mount/rootfs/*/lib; do TIMESTAMP=$(stat -c %Y $TIMESTAMPFILE) HUMANTIMESTAMP=$(date --date="@$TIMESTAMP") done echo "Build Version: $TIMESTAMP ($HUMANTIMESTAMP)"

Because to me, it sounds like you're not booting the image you're expecting to boot. Maybe you're storing it to the wrong directory, maybe the client you're testing with has a custom PXE boot entry that causes it to boot the image from a different location, maybe your USB media is actually a bootable X2GoThinClient because you were experimenting with that, and you're booting off of USB rather than PXE, ...

OK, this is the exact problem. I've been forgetting that I actually have a separate PXE boot server for my thin client lab and was uploading my images to my "general purpose" PXE server for the rest of my public machines. Now that I'm properly remembering, I'll do more testing and see what I can find.

Did you try using the entire build script from the wiki page, or only patch the automount script? What happens when you try to build a stock image using our scripts, our git repo, and no custom changes?

I went back through the wiki page and updated my build scripts to match the new info, and got the newer version of the x2gousbmount script. I can try a vanilla build and see what happens.

I just checked it myself on a stretch amd64 build, a stretch i386 (686-pae), and a jessie i386 (686-pae), the package is always there, just like it should be.

Of course, if all else fails, you could run unsquashfs, chroot into the resulting directory, install the package manually, then run mksquashfs again. I would suggest adding options -comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K to mksquashfs (based on a suggestion by intrigeri from the TAILS team), and reading the man page for mksquashfs first.

I was wondering how I might accomplish this, thanks for the tips.

Kind Regards, Stefan Baur

Chalk this one up to my own error. :) Thanks for the help.

Seth

-- Seth Galitzer Systems Coordinator Computer Science Department Kansas State University http://www.cs.ksu.edu/~sgsax sgsax@ksu.edu 785-532-7790