Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Nick Couchman]

On Sat, Mar 3, 2018 at 9:23 AM, Amarjeet Singh  wrote:

> I have tested with xrdp version 0.9.5 and got the following :-
>
> Display name is *"GUAC*" as you have mentioned above.
>
> View the screenshot : https://www.dropbox.com/s/
> bpsz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0
>
>
I suspect the 0.5.0 version you were using from Ubuntu was patched to
include the filesystem name/label functionality rather than just using the
PreferredDosName.

-Nick

Re: Authentication mechanism.. Was: New user questions...

[Nick Couchman]

On Sat, Mar 3, 2018 at 6:46 PM, Mike Jumper 
wrote:

> On Sat, Mar 3, 2018 at 1:51 PM, Joachim Lindenberg  > wrote:
>>
>> (3)It is still unclear to me what configuration changes I can/should
>> support, and how to best trigger restore of VMs. One approach I am
>> experimenting with is to subclass GuacamoleConfiguration and “monitor”
>> whether parameters are accessed and then as a side effect trigger restore.
>> However the unpleasant aspect is that I´d also have to cache credentials of
>> the user then. Any better approach?
>>
>
> Can you clarify what you mean here? What do you mean by "restore" in the
> context of VMs, and why are you trying to trigger this as a side effect?
> Can you describe what you're trying to achieve at a high level - based on
> the overall goal, rather than the specifics of your current implementation?
>
> - Mike
>

IIRC from earlier conversations, "restore" in this context means to bring
them out of a suspended/sleep mode.  So, Joachim is trying to implement an
extension that will resume a VM from a suspended state when the user tries
to (or is about to) connect.  This was discussed recently in the
Wake-on-LAN conversation, where you mentioned the challenge of somehow
delaying the connection until the machine is in an operational state.

In my mind, this would involve code to do the following things:
- Determining when the VM needs to be resumed (when a user logs in, when a
connection is initiated).
- Storing/retrieving some information about each connection that determines
how/where to resume the VM, if that isn't readily obvious.  This can be
done with the newly-added code for allowing extensions to store arbitrary
code.
- Code to actually trigger the VM resume/restore.  This could involving
calling a REST API for the hypervisor manager, executing a string of
command line commands, or connecting to a TCP socket, etc.
- Somehow checking the state of the VM to see if it is up and running
before actually connecting.

-Nick

Re: Authentication mechanism.. Was: New user questions...

[Mike Jumper]

On Sat, Mar 3, 2018 at 1:51 PM, Joachim Lindenberg 
wrote:

> Hi all,
>
> I made a proof of concept and implemented my own authentication extension.
> I am however struggling with
>
> (1)Changes of guacamole.properties (where I put some settings using a
> prefix hyperv.*) are not picked up until I restart tomcat. I´d appreciate
> if changes would be monitored or picked up at login like is for
> user-mapping.xml. Or am I mislead?
>

guacamole.properties is cached after the first time it is read.
Extension-specific files, like user-mapping.xml (which is used by a
built-in extension), are governed only by how the extension was written.
The reason that user-mapping.xml is automatically reread upon modification
is because the underlying built-in extension is written to do so. You can
do this for your extension, too, of course - define your own configuration
file which is read from within GUACAMOLE_HOME, and re-read if changed.

(2)I need a json parser. Looks like there is none exposed by tomcat8 or
> guacamole. I had to copy a json implemention into my jar, which does not
> look like a good solution to me. Is there a way to refer to a standard json
> implementation?
>

I believe Guacamole bundles Jackson, so you might be able to use that,
however you are indeed expected to bundle your own dependencies. Extensions
are loaded within their own child classloaders with this in mind.

(3)It is still unclear to me what configuration changes I can/should
> support, and how to best trigger restore of VMs. One approach I am
> experimenting with is to subclass GuacamoleConfiguration and “monitor”
> whether parameters are accessed and then as a side effect trigger restore.
> However the unpleasant aspect is that I´d also have to cache credentials of
> the user then. Any better approach?
>

Can you clarify what you mean here? What do you mean by "restore" in the
context of VMs, and why are you trying to trigger this as a side effect?
Can you describe what you're trying to achieve at a high level - based on
the overall goal, rather than the specifics of your current implementation?

- Mike

AW: Authentication mechanism.. Was: New user questions...

[Joachim Lindenberg]

Hi all, 

I made a proof of concept and implemented my own authentication extension. I am 
however struggling with 

(1)Changes of guacamole.properties (where I put some settings using a 
prefix hyperv.*) are not picked up until I restart tomcat. I´d appreciate if 
changes would be monitored or picked up at login like is for user-mapping.xml. 
Or am I mislead?

(2)I need a json parser. Looks like there is none exposed by tomcat8 or 
guacamole. I had to copy a json implemention into my jar, which does not look 
like a good solution to me. Is there a way to refer to a standard json 
implementation?

(3)It is still unclear to me what configuration changes I can/should 
support, and how to best trigger restore of VMs. One approach I am 
experimenting with is to subclass GuacamoleConfiguration and “monitor” whether 
parameters are accessed and then as a side effect trigger restore. However the 
unpleasant aspect is that I´d also have to cache credentials of the user then. 
Any better approach?

Thanks,

Joachim

 

Von: Joachim Lindenberg [mailto:joac...@lindenberg.one] 
Gesendet: Mittwoch, 28. Februar 2018 15:34
An: user@guacamole.apache.org
Betreff: Authentication mechanism.. Was: New user questions...

 

Hi Mike, all,

let me first understand exactly what you wrote, in particular as I did not 
install the LDAP and database part so far. You write “It is the only 
authentication extension which implements both reading and writing,..”

what exactly is it writing? Configuration data – then I´d prefer to generate 
it. Personalization? Then that sounds more interesting. What types of 
personalization? Maybe including settings like enable-font-smoothing Christian 
mentioned, which might really be users preference or depend on bandwidth.

Then second I´d like to understand my options. I think I have a pretty standard 
Hyper-V setup except for two things: some of the VMs are created by an 
application of mine which also assigns VMConnectAccess authorizations to 
specific user/VM combinations (which also prevents access using VMconnect 
unless the users are also Hyper-V-Administrators, haven´t tested exactly what 
guacamole requires, but I verified I can actually connect using a different 
user). And then I have a mechanism in place that saves/suspends VMs 
aggressively in order to conserve memory on the host.

What I´d do in an authentication mechanism is to call a service on the hyper-V 
server doing two things: first check user against the local 
authentication systems (which includes support for local, domain, and microsoft 
users). If that succeeds, enumerate the VMs the user is authorized to and 
generate the relevant configuration connection.

Does that make sense? 

Obviously the server running on hyper-V is Hyper-V specific, whereas the client 
part could be very generic and don´t really care about whether it is Hyper-V or 
some other backend.

Now an interesting question is how to deal with the aggressive save: ideally 
one would include suspended VMs in the connections and then trigger the resume 
operation when a user picks that. Is that possible? How?

Thanks & Best Regards,

Joachim

 

 

Von: Mike Jumper [mailto:mike.jumper@guac-d  
ev.org] 
Gesendet: Dienstag, 27. Februar 2018 08:04
An: user@guacamole.apache.org  
Betreff: Re: New user questions...

 

On Mon, Feb 26, 2018 at 10:45 PM, Joachim Lindenberg  > wrote:

...

*   w.r.t. ldap & database – my installation is very small w.r.t. the 
number of users (2-3) and virtual systems (5-10).  A database sounds 
overengineered to me especially considering operations (backup).

 

Small or large, the database authentication backend is really the best way to 
go. It is the only authentication extension which implements both reading and 
writing, thus providing a web-based management interface for connections and 
users, and the only extension which implements full screen sharing, logging of 
connection access, etc.

 

Generating user-mapping.xml on the Hyper-V host sounds like one approach I 
might try

 

I strongly recommend against auto-generating XML as a means of throwing 
together integration quickly:

 

http://guacamole.apache.org/faq/#integrate-auth

 

(but I dislike the passwords in that and would prefer to get them from LDAP), 
or I am considering to plug in my own authentication – but that will take some 
programming time.

 

Nevertheless, if you wish to tightly integrate Guacamole with your own 
authentication, this is exactly the way it should be done.

 

Actually I think Guacamole could standardize a rest based client

 

Guacamole's interface is already driven by a REST sevice.

 

using basic authentication (forwarding the credentials received)

 

Guacamole also already pulls credentials from HTTP basic auth if they are not 
otherwise 

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Amarjeet Singh]

I have tested with xrdp version 0.9.5 and got the following :-

Display name is *"GUAC*" as you have mentioned above.

View the screenshot :
https://www.dropbox.com/s/bpsz633zt5tpfv3/xrdp_version_0.9.5.PNG?dl=0

Regards,
Amarjeet Singh

On Sat, Mar 3, 2018 at 7:35 PM, Amarjeet Singh  wrote:

> @Nick, Below is the *INFO :-*
>
>
>> What version of XRDP are you using, on what Linux distribution?
>
>
> Linux distribution  : Ubuntu 16.04.3 x64
> XRDP version : xrdp 0.5
>
>
>
>> Also, could you test with an un-modified version of Guacamole and see if
>> the behavior is consistent?
>
> Maybe you could try with a more modern version of XRDP?
>
>
> I will test and update you the same.
>
>
>
> On Sat, Mar 3, 2018 at 7:21 PM, Nick Couchman  wrote:
>
>> On Sat, Mar 3, 2018 at 8:47 AM, Amarjeet Singh 
>> wrote:
>>
>>> @Nick xrdp Version is 0.5.0
>>>
>>>
>> Oh, my.  That is quite old.  Current version of XRDP is 0.9.5, and that
>> is available at least in the EPEL repository for RH/CentOS 7 (EL7), and I
>> would be surprised if it isn't available for other distributions.  Maybe
>> you could try with a more modern version of XRDP?
>>
>> -Nick
>>
>
>

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Amarjeet Singh]

@Nick xrdp Version is 0.5.0

On Sat, Mar 3, 2018 at 7:08 PM, Nick Couchman  wrote:

>
>>>
>>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>>> either the client name, nor the the filesystem name for presenting this
>>> share.
>>
>>
>> I am seeing the same . Please view the screenshots.
>>
>
> Interesting.  Perhaps the version of XRDP you are using has been patched
> to support it.  The Github source code I looked at and the version I used
> (EPEL 7 repo) did not behave this way.  In any case, this is dependent on
> XRDP and how it behaves, and not Guacamole.  Whatever version you are using
> is clearly okay with the lack of UTF-16 encoding, so it looks like they
> have implemented it in a way consistent with other RDP clients and servers.
>
> -Nick
>

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Nick Couchman]

>
>
>>
>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>> either the client name, nor the the filesystem name for presenting this
>> share.
>
>
> I am seeing the same . Please view the screenshots.
>

Interesting.  Perhaps the version of XRDP you are using has been patched to
support it.  The Github source code I looked at and the version I used
(EPEL 7 repo) did not behave this way.  In any case, this is dependent on
XRDP and how it behaves, and not Guacamole.  Whatever version you are using
is clearly okay with the lack of UTF-16 encoding, so it looks like they
have implemented it in a way consistent with other RDP clients and servers.

-Nick

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Amarjeet Singh]

One more INFO I would like to share which is as follows :-

*Link target of that folder* : home/gk/.rdp_drive/CLOUD  { gk  is username
}

On Sat, Mar 3, 2018 at 6:52 PM, Amarjeet Singh  wrote:

> I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
> which is not accessible.
>
> Link to view the screenshot :-  https://www.dropbox.com/s/
>> t2emg56wxg0nito/linux_folders.PNG?dl=0
>
>
>
> Below is the error I got while opening the folder :- Refer the screenshot
>
>>
>> Link to view the  screenshot :   https://www.dropbox.com/s/
>> w11d1hj81gwazvs/error_linux.png?dl=0
>
>
>
> I have no idea about it.
>
> Regards,
> Amarjeet Singh
>
>
>
>
>
> On Sat, Mar 3, 2018 at 6:42 PM, Amarjeet Singh 
> wrote:
>
>> Thanks Nick,
>>
>>
>> Below is the link to view the screenshot :-
>>
>> Windows  :   https://www.dropbox.com/s/97m3x94vewi4q2j/windows_device_
>> redirection.PNG?dl=0
>>
>> Linux : https://www.dropbox.com/s/x7mego94nduosbz/liux_device_redi
>> rection.PNG?dl=0
>>
>>>
>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>
>>
>>
>> I will fix it.
>>
>>
>>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>>> either the client name, nor the the filesystem name for presenting this
>>> share.
>>
>>
>> I am seeing the same . Please view the screenshots.
>>
>>
>> Regards,
>> Amarjeet Singh
>>
>>
>> On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman  wrote:
>>
>>> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh 
>>> wrote:
>>>
 Hi Team,

 I have done the following changes to fix the above issue which works
 both in *Windows  *as well as *Linux RDP.*


>
> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   12*



 *Instead of using above configurations I have used the following  (
 No   UTF-16 encoding  is required  ) :-   *


> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   5*




>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>>
>>>
 *and I have used   UTF-16 encoding in the following :-*


 * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*

 *to *

 #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
 \0S\0t\0o\0r\0a\0g\0e\0\0\0"
 #define GUAC_DRIVE_NAME_LENGTH   28

 and used the above in the  *guac_rdpdr_send_client_name_request
 function .*

>>>
>>> Note that the drive name and client name are *not* the same thing.  The
>>> client name is used for redirection, but is used in a broader sense to
>>> identify the client connecting to the server.  I don't know off the top of
>>> my head what the encoding should be for that, but probably UTF-16.
>>>
>>> Your screenshots did not come through, but the storage should show up as
>>>  on , so, in your case, you should see
>>> "Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
>>> this, as XRDP does not look at either the client name, nor the the
>>> filesystem name for presenting this share.  Instead, there's a value
>>> determine on the XRDP side, either in the code or in a configuration file,
>>> for the name of the share, and then it uses the PreferredDosName setting
>>> for the folder name.  None of the changes you have done (nor the ones I
>>> have done in the pull request for the JIRA issue) will impact the way XRDP
>>> sees it, and this is not because of Guacamole, this is because of how the
>>> XRDP code handles it.
>>>
>>> -Nick
>>>
>>
>>
>

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Amarjeet Singh]

I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
which is not accessible.

Link to view the screenshot :-
> https://www.dropbox.com/s/t2emg56wxg0nito/linux_folders.PNG?dl=0



Below is the error I got while opening the folder :- Refer the screenshot

>
> Link to view the  screenshot :
> https://www.dropbox.com/s/w11d1hj81gwazvs/error_linux.png?dl=0



I have no idea about it.

Regards,
Amarjeet Singh





On Sat, Mar 3, 2018 at 6:42 PM, Amarjeet Singh  wrote:

> Thanks Nick,
>
>
> Below is the link to view the screenshot :-
>
> Windows  :   https://www.dropbox.com/s/97m3x94vewi4q2j/windows_
> device_redirection.PNG?dl=0
>
> Linux : https://www.dropbox.com/s/x7mego94nduosbz/liux_device_
> redirection.PNG?dl=0
>
>>
>> While the string apparently does not need to be UTF-16 encoded, it does
>> need to be null-terminated, which you're missing, here.
>
>
>
> I will fix it.
>
>
>>   On XRDP on Linux, you will not see this, as XRDP does not look at
>> either the client name, nor the the filesystem name for presenting this
>> share.
>
>
> I am seeing the same . Please view the screenshots.
>
>
> Regards,
> Amarjeet Singh
>
>
> On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman  wrote:
>
>> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh 
>> wrote:
>>
>>> Hi Team,
>>>
>>> I have done the following changes to fix the above issue which works
>>> both in *Windows  *as well as *Linux RDP.*
>>>
>>>

 *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
 GUAC_FILESYSTEM_NAME_LENGTH   12*
>>>
>>>
>>>
>>> *Instead of using above configurations I have used the following  (  No
>>>  UTF-16 encoding  is required  ) :-   *
>>>
>>>
 *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
 GUAC_FILESYSTEM_NAME_LENGTH   5*
>>>
>>>
>>>
>>>
>> While the string apparently does not need to be UTF-16 encoded, it does
>> need to be null-terminated, which you're missing, here.
>>
>>
>>> *and I have used   UTF-16 encoding in the following :-*
>>>
>>>
>>> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*
>>>
>>> *to *
>>>
>>> #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
>>> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
>>> #define GUAC_DRIVE_NAME_LENGTH   28
>>>
>>> and used the above in the  *guac_rdpdr_send_client_name_request
>>> function .*
>>>
>>
>> Note that the drive name and client name are *not* the same thing.  The
>> client name is used for redirection, but is used in a broader sense to
>> identify the client connecting to the server.  I don't know off the top of
>> my head what the encoding should be for that, but probably UTF-16.
>>
>> Your screenshots did not come through, but the storage should show up as
>>  on , so, in your case, you should see
>> "Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
>> this, as XRDP does not look at either the client name, nor the the
>> filesystem name for presenting this share.  Instead, there's a value
>> determine on the XRDP side, either in the code or in a configuration file,
>> for the name of the share, and then it uses the PreferredDosName setting
>> for the folder name.  None of the changes you have done (nor the ones I
>> have done in the pull request for the JIRA issue) will impact the way XRDP
>> sees it, and this is not because of Guacamole, this is because of how the
>> XRDP code handles it.
>>
>> -Nick
>>
>
>

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Nick Couchman]

On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh  wrote:

> Hi Team,
>
> I have done the following changes to fix the above issue which works both
> in *Windows  *as well as *Linux RDP.*
>
>
>>
>> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
>> GUAC_FILESYSTEM_NAME_LENGTH   12*
>
>
>
> *Instead of using above configurations I have used the following  (  No
>  UTF-16 encoding  is required  ) :-   *
>
>
>> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
>> GUAC_FILESYSTEM_NAME_LENGTH   5*
>
>
>
>
While the string apparently does not need to be UTF-16 encoded, it does
need to be null-terminated, which you're missing, here.


> *and I have used   UTF-16 encoding in the following :-*
>
>
> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*
>
> *to *
>
> #define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
> #define GUAC_DRIVE_NAME_LENGTH   28
>
> and used the above in the  *guac_rdpdr_send_client_name_request function
> .*
>

Note that the drive name and client name are *not* the same thing.  The
client name is used for redirection, but is used in a broader sense to
identify the client connecting to the server.  I don't know off the top of
my head what the encoding should be for that, but probably UTF-16.

Your screenshots did not come through, but the storage should show up as
 on , so, in your case, you should see
"Cloud" on "Cloud Storage" on Windows.  On XRDP on Linux, you will not see
this, as XRDP does not look at either the client name, nor the the
filesystem name for presenting this share.  Instead, there's a value
determine on the XRDP side, either in the code or in a configuration file,
for the name of the share, and then it uses the PreferredDosName setting
for the folder name.  None of the changes you have done (nor the ones I
have done in the pull request for the JIRA issue) will impact the way XRDP
sees it, and this is not because of Guacamole, this is because of how the
XRDP code handles it.

-Nick

Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]

[Amarjeet Singh]

Hi Team,

I have done the following changes to fix the above issue which works both
in *Windows  *as well as *Linux RDP.*


>
> *#define GUAC_FILESYSTEM_NAME  "C\0L\0O\0U\0D\0\0\0"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   12*



*Instead of using above configurations I have used the following  (  No
 UTF-16 encoding  is required  ) :-   *


> *#define GUAC_FILESYSTEM_NAME  "CLOUD"**#define
> GUAC_FILESYSTEM_NAME_LENGTH   5*



*and I have used   UTF-16 encoding in the following :-*


* guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage");*

*to *

#define GUAC_DRIVE_NAME  "C\0l\0o\0u\0d\0
\0S\0t\0o\0r\0a\0g\0e\0\0\0"
#define GUAC_DRIVE_NAME_LENGTH   28

and used the above in the  *guac_rdpdr_send_client_name_request function .*


*Following is the output in the Windows and Linux RDP :- Please refer the
screenshots*









Thanks Nick for the helping me out .

Please look into it and suggest if there is any change required.


Thanks and regards,
Amarjeet Singh

On Mon, Feb 26, 2018 at 8:27 PM, Nick Couchman  wrote:

>
>>
>>> It's interesting that XRDP is still clearly attempting to read things as
>>> UTF-16 here, but if that's failing for unmodified Guacamole, too, then it
>>> must be reading a field which we are not encoding as UTF-16 already (since
>>> the name of Guacamole's filesystem is definitely pre-encoded as UTF-16 at
>>> the moment). Perhaps we're wrong in the handling of whichever value is
>>> being used by XRDP, too?
>>>
>>>
>> I'm going to try to stand up a XRDP test server tomorrow and see if I can
>> test a few things and get some findings consistent with Amarjeet's
>> results.  This point actually puzzles me a little bit, particularly since
>> XRDP apparently works fine with xfreerdp, which does not UTF-16 encode its
>> filesystem name parameter.  Maybe with a few more test cases we can find
>> the illusive pattern.
>>
>> Or we'll just further confuse ourselves ;-).
>>
>> -Nick
>>
>
> It looks to me like xrdp just reads the "PreferredDosName" setting and
> doesn't even bother to try to enumerate the DeviceData:
>
> https://github.com/neutrinolabs/xrdp/blob/5daa09171e1e6e65a1
> a3ab969775fdf8ac37/sesman/chansrv/devredir.c#L691
>
> In my testing, with my changes for GUACAMOLE-446, it doesn't matter what I
> set the name of the drive to in Guacamole, it always shows up as "GUAC" in
> the XRDP redirected filesystem directory.  I can't find the exact place in
> the guacd code where the PreferredDOSName field gets set, but it looks like
> maybe it just uses the GUAC_OS_TYPE define from rdpdr_messages.h:
>
> https://github.com/apache/guacamole-server/blob/bc5b01d4d8ab
> 0c3c89a08007316d33012261f6b3/src/protocols/rdp/guac_rdpdr/
> rdpdr_messages.h#L71
>
> ??  The PreferredDOSName field is supposed to be ASCII, 8 characters, at
> most, and *not* null-terminated...
>
> So, whatever changes get made in -446 should *not* adversely impact XRDP,
> as far as I can tell.  Also, I tested xfreerdp with xrdp, and, when you
> specify a filesytem name longer than 8 characters, it just truncates it at
> 8 ("temporary_files" turned into "temporar").  My guess is that xfreerdp is
> just taking the command line argument for the filesystem name and
> truncating it to 8 characters for the preferred DOS name.
>
> -Nick
>