Bug 7729 - localdrives requires Python 2
Summary: localdrives requires Python 2
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Local drive redirection (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Bugzilla mail exporter
URL:
Keywords: linma_tester, prosaic
Depends on:
Blocks: 4586
  Show dependency treegraph
 
Reported: 2021-06-21 15:34 CEST by William Sjöblom
Modified: 2021-08-30 13:30 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description William Sjöblom cendio 2021-06-21 15:34:44 CEST
localdrives still use Python 2. Since Python 2 is getting old, dusty, and unsupported, we should port localdrives to Python 3.
Comment 19 William Sjöblom cendio 2021-07-05 12:49:38 CEST
I have contacted J. Bruce Fields <bfields@redhat.com> regarding the changes made to pynfs in r37154. Hopefully, these changes can be upstreamed.
Comment 20 William Sjöblom cendio 2021-07-05 13:00:01 CEST
I have tested the converted `tl-mount-localdrives` (r37154) on both Fedora 33 and SLES12 without noticing any issues.

The following tests were performed:
 - Mounting a directory
   - Reading files from said directory
   - Writing files to said directory
 - Mounting multiple directories
 - Mounting a directory containing non-ASCII characters
   - Reading files from said directory (non-ASCII file name)
   - Writing files to said directory (non-ASCII file name)
Comment 32 William Sjöblom cendio 2021-07-07 15:40:23 CEST
Tested the following `tl-umount-localdrives` cases on SLES12 using Jenkins server build #2200:

    - [X] Mount names containing non-ascii characters and spaces
      - [X] On UTF-8
      - [X] On Latin9
    - [X] Unmounts current session
      - [X] Mounts removed from /proc/mounts
      - [X] /opt/thinlinc/sessions/<user>/<sessnum>/drives/ empty
      - [X] ~/thindrives/ symlink points to the previous session *with mounted
        drives*, or is removed if there are no previous sessions with mounted
        drives.
    - [X] Unmounts all sessions for user
      - [X] Mounts removed from /proc/mounts
      - [X] /opt/thinlinc/sessions/<user>/*/*/drives/ empty
      - [X] ~/thindrives/ symlink removed
    - [X] Unmounts all sessions for all users
      - [X] Mounts removed from /proc/mounts
      - [X] /opt/thinlinc/sessions/*/*/*/drives/ empty
    - [X] Verbose logging

For testing multiple concurrent sessions with the same user the "Terminal" profile was used. Marking as resolved.
Comment 34 Linn cendio 2021-07-09 13:07:15 CEST
Found a corner case that is not currently covered. Tested with server build 2210.

Scenario:

1. Client with locale UTF-8, server with locale Latin-1. 

2. Name one of the exported folders with a character unavailable in the servers locale, e.g. 'fold€r'. 

3. Log in with the client, and run ls ~/thindrives. Only folders with valid characters that are *before* the invalid foldername are shown (the order from TL client's Options->Local Devices).


In 4.12.1, we were able to fetch folders with names that had unavailable characters, but the names were shown in the wrong encoding.
Comment 35 Linn cendio 2021-07-12 08:31:47 CEST
I tested server build 2210 on RHEL 8 and Ubuntu 20.04 with client version 4.12.1, and everything is working fine except for the corner case in comment 34. 

    - [ ] Mount names containing non-ascii characters and spaces
      - [X] On UTF-8
      - [ ] On Latin1
    - [X] Mount multiple directories
    - [X] Read file from mounted directories
    - [X] Write file from mounted directories
    - [X] Can't write file to read-only mounted directories
    
    - [X] Unmounts current session
      - [X] Mounts removed from /proc/mounts
      - [X] /var/opt/thinlinc/sessions/<user>/<sessnum>/drives/ empty
      - [X] ~/thindrives/ symlink points to the previous session *with mounted
        drives*, or is removed if there are no previous sessions with mounted
        drives.
    - [X] Unmounts all sessions for user
      - [X] Mounts removed from /proc/mounts
      - [X] /var/opt/thinlinc/sessions/<user>/*/drives/ empty
      - [X] ~/thindrives/ symlink removed
    - [X] Unmounts all sessions for all users
      - [X] Mounts removed from /proc/mounts
      - [X] /var/opt/thinlinc/sessions/*/*/drives/ empty
    - [X] Verbose logging
Comment 37 William Sjöblom cendio 2021-07-12 11:15:29 CEST
The above mentioned issue has now been fixed. Marking as resolved.
Comment 40 William Sjöblom cendio 2021-07-12 14:02:55 CEST
With the move to python 3 there has been subtle changes to how the server-side
mountpoints are named. This has to do with the fact that we do not know the
client-side character encoding. Previously, we did not consider encodings and
just considered the names as raw byte sequences.

Let's consider the two incompatible character encodings UTF-8 and Latin-1. With
this incompatible encoding pair we have four possible outcomes:

1. The client use UTF-8 (Windows and most Linux machines) and the server uses
   Latin-1.
   - All characters in the mountpoint name representable in Latin-1 gets
     correctly translated to the new encoding. Others get replaced by a '?'.
2. The client use Latin-1 and the server UTF-8.
   - All characters within the ASCII range in the mountpoint name are correctly
     translated to the new encoding. Others get replaced by the UTF-8
     replacement character.
3. Both use UTF-8 (the most common scenario).
   - All characters are correctly translated.
4. Both use Latin-1.
   - All characters within the ASCII range are correctly translated. Others get
     replaced by '?'.
Comment 41 William Sjöblom cendio 2021-07-12 14:30:31 CEST
To clarify comment 40:
 
Previously we did not consider encodings. Thus, we just assumed that the client and server both used the same encoding. For example, if we have a client running on a UTF-8 system and a server running on a Latin-1 system, the raw UTF-8 bytes from the client will be interpreted as raw Latin-1 bytes by the server, and thus any multibyte UTF-8 characters sent from the client will be interpreted as multiple Latin-1 characters by the server. In this case, a mounted directory called "ödeshög" on the client would get the name "thindrives/ödeshög", even though "ödeshög" is within the Latin-1 range.
Comment 42 Linn cendio 2021-07-12 16:03:15 CEST
Tested the following two scenarios with server build 2219, which both works well. 

> 1. The client use UTF-8 (Windows and most Linux machines) and the server uses
>    Latin-1.
>    - All characters in the mountpoint name representable in Latin-1 gets
>      correctly translated to the new encoding. Others get replaced by a '?'.
Works as expected.


> 2. The client use Latin-1 and the server UTF-8.
>    - All characters within the ASCII range in the mountpoint name are
> correctly
>      translated to the new encoding. Others get replaced by the UTF-8
>      replacement character.
Works as expected.
Comment 43 Frida Flodin cendio 2021-07-12 16:11:35 CEST
I have tested the following scenarios and it works as expected:


> 3. Both use UTF-8 (the most common scenario).
>    - All characters are correctly translated.
Works as expected.

> 4. Both use Latin-1.
>    - All characters within the ASCII range are correctly translated. Others
> get
>      replaced by '?'.
Works as expected.

Now everything should be tested, so I will close this!
Comment 44 William Sjöblom cendio 2021-08-30 13:30:02 CEST
The changes applied to pynfs have now been upstreamed:
http://git.linux-nfs.org/?p=bfields/pynfs.git;a=commit;h=e96aa245978208e9b0d8bdfe51bef3a879eb03cb

Note You need to log in before you can comment on or make changes to this bug.