It needs to be converted to work with Python 3.
VSM Server and VSM Agent need to support Python 3 before this bug can be closed, see bug 7629 and 7630. Here is a list of shared dependencies: * vsm.xmlrpc * ctcommon * vsm.vsmcommon * vsm.extproc * vsm.async * which * vsm.authoritychecker * vsm.check_environment
Here are modules and scripts that need to be tested with this bug due to changes in the modules in parentheses: * tlwebadm (daemon, handler_getloadstatus, loadinfokeeper, handler_killsession) * tlwebaccess (daemon, authutil, sessionstart and more) * tl-ldap-certalias (crypto, pyaes, selinux) * tl-setup (authutil, selinux) * tl-collect-licensestats (licensehandler, sessionstore, call_verifysessions, call_sessionchange) * tl-gen-auth (authutil)
Tested using build 1984 on Ubuntu 20.04: ✓ tlwebadm ✓ tlwebaccess ✓ tl-setup (except SELinux) ✓ tl-collect-licensestats ✓ tl-gen-auth
Tested using build 1984 on SUSE 12: ✓ tlwebadm ✓ health ✓ The services are correctly shown to be running or stopped. ✓ status ✓ Licensegraphs show correct number of used and available licenses. ✓ Load is correctly displayed and updated. ✓ All sessions is displayed. ✓ I can terminate sessions. ✗ I can not shadow session due to Bug 5813. ✓ All information about the session looks correct. ✓ vsm ✓ Stopping and starting VSM master and agent. ✓ tlwebaccess ✓ Create new session and reconnect. ✓ Logging in with non-ASCII password. ✓ tl-ldap-certalias (Except SELinux) ✓ tl-setup (Except SELinux) ✓ Creating ASCII and non-ASCII password and use in tlwebadm. ✓ tl-collect-licensestats ✓ tl-gen-auth ✓ ASCII ✓ non-ASCII
I have now tested Licensehandling on SUSE 12 with build 1986: ✓ Blocking new session when license max user is hit. ✓ Adding a new licenses with more users and then created another session works. ✓ Sending warning mail, with non-ASCII characters. ✓ Not allowing license with to old version. ✓ License with bad signature is not allowed. ✓ Non-zero returncode from sendmail (by creating a fake sendmail and returning 1) ✓ Log warning when no sendmail is available. ✓ User with a session is always allowed to create more sessions when connecting from the same terminal.
So, I tested our SELinux's Python 2 compatability on Fedora 33 and CentOS 7 with build 1989: ✓ tl-setup ✓ tl-ldap-certalias (only tested on CentOS 7) I used the docker image from "test_5880" to test tl-ldap-certalias, and it's worth noting that it doesn't run properly on Fedora 33. The docker image is based on CentOS 7 which is one of the newest distros which still has Python 2's python-ldap. However, CentOS 7 has an older version of systemd which isn't compatible with the cgroups v2 engine on Fedora 33. For now I ran the test_5880 image from a Fedora 32 machine instead.
I have tested shadowing on Fedora 33 (Python 3.9): ✓ Silent mode ✓ Notify mode ✓ Accepted shadowing request ✓ Rejected shadowing request ✓ Attempt to shadow yourself ✓ Attempt to shadow without shadowing privileges ✓ Attempt to shadow non-ThinLinc user ✓ Attempt to shadow user that isn't logged in ✓ Attempt to shadow when vnc-shadow-notify isn't running
Tested session killing on Ubuntu 20.04 (Python 3.8): ✓ Killing from tlclient (as user) ✓ Killing from tlwebadm (as root) ✓ Killing after vsmagent restart (tl-session no longer child of vsmagent) ✓ Failure killing (blocked SIGTERM using gdb)
Tested HA on Ubuntu 20.04 (Python 3.8): ✓ Started a session on one master and reconnected via the other ✓ Logged out and both masters noticed the session was dead ✓ Resync after one vsmserver was down during new session ✓ Resync after one vsmserver was down and other restarted (sync info written to disk)
Tested creating new session with loadbalancing and subclusters. (Note however that I have worked a lot with these modules, some new verifying eyes might want to check this before closing.) Tested on SUSE 12 with build 1989. NewSessionHandler ------------------ ✓ Getting users groups ✓ Not allowing user not in allowed_groups ✓ Allowing user if in allowed_groups ✓ Empty allowed_groups -> everyone is allowed. ✓ Number of session limit ✓ max_sessions_per_user=0 gives no limit. ✓ max_sessions_per_user=1 automatic reconnect from client. ✓ max_sessions_per_user=2 can not choose the create new session from client. ✓ Subcluster configuration is respected. ✓ Successful creation of session on best agent. ✓ Trying to get load from agent that is down, try next. ✓ Trying to get load from agent but hit timeout, try next. ✓ Fail to create session on the best agent, try next. ✓ After trying two agents the server gives up and reports back to client that no agents was available. ✓ Running all session scripts ✓ No session scripts in sessionstartup.d ✓ Getting OSError when running session script ✓ Output from session script is printed in log ✓ Getting client IP Loadbalancing ------------- ✓ New session is created on the agent with highest rating. ✓ With multiple sessions user gets new sessions on the same agent, regardless of rating. ✓ With multiple sessions user gets new session on *another* agent if the user's agent is down. But first the agent that is marked as down is tested to see if it is really down. ✓ User with two sessions on two different agents, wanting to created a third, the one of the user's agents with the highest rating is chosen. ✓ User with multiple sessions spread out on two agents and want to create a new session. The agent with the most user sessions is chosen, regardless of rating. ✓ User has session on agent that has been removed from the configuration. If the user wants new session it is created on *another* agent and there is a warning in the vsmserver log about this. ✓ Agents are marked as down if they don't respond on getload. ✓ No subcluster associated with user, no session started. ✓ Loadinfo updates ✓ Periodic updates works. ✓ If a session is started between two updates, the next scheduled updated is done later. ✓ If there are dead children reported from vsmagent, they get deleted in sessionstore when the load information is updated. ✓ Penalty ✓ Giving 5 penalties to bad agent when session could not be started. ✓ Decreasing after successful periodic update. ✓ Decreasing after successful new session.
Tested getting sessions on Ubuntu 20.04 (Python 3.8): ✓ List all sessions in tlwebadm ✓ List sessions for one user in tlwebadm ✓ User sessions are verified when tlwebadm lists them (notices dead sessions right away)
Tested on RHEL 8, running Python 3.6, with build 1989. Loadbalancing ------------- ✓ Reasonable values in loadstatus on tlwebadm ✓ Mem total ✓ Mem free ✓ Swap total ✓ Swap free ✓ Number of users ✓ Reasonable rating for a server. (Manual counting) ✓ Use the agent with best rating for new session ✓ If best rating fails, use next best ✓ Periodic updates of loadinfo works ✓ Mark agent as down if periodic update fails ✓ Periodic update re-tries agent marked as down (To mark them as alive again) ✓ Failure to start a session increases penalty for an agent by 5 ✓ Successful session start on agent reduces penalty point by one ✓ Successful periodic update reduces penalty point by one
Tested unbinding ports on SUSE 12 with build 1989. ✓ Nothing to kill -> do nothing. ✓ Killing process that occupies port. ✓ Killing process with Unicode name (on UTF-8 system). The correct name is displayed in log.
It turns out there are two different paths the shadowing code can take when mode is set to 'reject': * The regular scenario is that the handler on the Master notices that the configuration file mode is set to 'reject', this requires that 'vsmserver' is restarted after making the change. * The second scenario requries that the vsmserver service isn't restarted after changing the shadowing mode. In this case we get further all the way to the Agent where the vnc-shadow-notify will reject you. Both these work fine on Python 3.9 (Fedora 33 ) with build 1989.
Tested authority checker on Ubuntu 20.04 (Python 3.8): vsmserver: ✓ Getting sessions is allowed by root ✓ Getting sessions is denied by anyone else ✓ Getting sessions is denied by unknown hosts ✓ Getting sessions is denied by high port ✓ Getting load status is allowed by root ✓ Getting load status is denied by anyone else ✓ Getting load status is denied by unknown hosts ✓ Getting load status is denied by high port ✓ HA updates are allowed by other hostname ✓ HA updates are allowed by other IP ✓ HA updates are denied by anyone else (including hosts allowed for other things) vsmagent: ✓ Getting load is allowed by approved hostnames ✓ Getting load is allowed by approved IP ✓ Getting load is denied by unknown hosts ✓ Verifying sessions is allowed by approved hostnames ✓ Verifying sessions is allowed by approved IP ✓ Verifying sessions is denied by unknown hosts ✓ Unbinding ports is allowed by approved hostnames ✓ Unbinding ports is allowed by approved IP ✓ Unbinding ports is denied by unknown hosts ✓ Unbinding ports is denied by high port ✓ Creating sessions is allowed by approved hostnames ✓ Creating sessions is allowed by approved IP ✓ Creating sessions is denied by unknown hosts ✓ Creating sessions is denied by high port ✓ Terminating sessions is allowed by approved hostnames ✓ Terminating sessions is allowed by approved IP ✓ Terminating sessions is denied by unknown hosts ✓ Terminating sessions is denied by high port (test this using non-ASCII username and password, with UTF-8 locale)
Tested multiple sessions on Fedora 33 (Python 3.9): Ask: ✓ New session (first session) ✓ New session (second session) ✓ New session another agents * ✓ End session ✓ End session on multiple agents ✓ Reconnect to disconnected ✓ "Steal" connected session ✓ Sync "session list" with other client ** ✓ Hit session limit (no "New session"-button is shown) Auto: ✓ New session (first session) ✓ New session (second session) ✓ Reconnect to disconnected ✓ Hit session limit (no "New session"-button is shown) * An agent with 2 active sessions for the same user was removed from the subcluster, the 3rd session for that user was then successfully created on another agent. ** When trying to connect to a session that has been ended from the session list of another ThinLinc client, you don't get an error - you get a new list to choose from.
Tested subclusters with build 1989 using the following setup: Server on RHEL8. Cluster A: - One agent on RHEL8 Cluster B: - Two agents, one on RHEL8 and the other on Fedora 33 Subclusters ----------- ✓ Association ✓ User will create new sessions on cluster associated with it ✓ User will create new session on cluster assosiated with it's 'groups' ✓ If neither 'users' or 'groups' are given, the session is created on the default cluster ✓ Given no default cluster is configured. An user without any cluster associated with it's 'groups' or 'users' will not be able to create session. ✓ Log warning if the same 'agent' is specified in multiple subclusters ✓ Log warning if the same 'users' is specified in multiple subclusters ✓ Log warning if the same 'groups' is specified in multiple subclusters ✓ If session is already created before changing association, we should be able to reconnect to the existing session ✓ Priority ✓ 'users' have precedence over 'groups' ✓ 'groups' have precedence over 'default' ✓ Load balancing in a subcluster ✓ Given a cluster with good rating, A. Given a cluster with less rating on all agents, B. User with association to cluster B will not create session on cluster A ✓ User associated with cluster B will not be able to create sessions if all of cluster B agents are down and cluster A is healthy. ✓ User associated with cluster B will create session on the agent with the best rating
Tested session request on agent. Tested on SUSE 12 with build 1986. ✓ Reject session when user does not exist on system. ✓ Finding free display ✓ The first free display is used ✓ No free display left ✓ Setting session key, looks random. ✓ Generating vnc password ✓ Generating cookies ✓ Create and set correct access rights to system sockets. ✓ Creating home dir* ✓ Default mode ✓ Different mode 0755 ✓ Mode written as 0o755 -> use default 0700 ✓ Non-ascii username ✓ Trying to create homedir when homedir already exists ✓ SessionStart ✓ Non-ascii username ✓ Non-ascii homedir ✓ Single sign on ✓ Basic functions in session: graphics, mouse, keyboard, sound. ✓ Wait on vnc port ✓ xvnc startup failed due to timeout * Did not tests with SELinux
Tested user sockets on Ubuntu 20.04 (Python 3.8): ✓ User sockets are created for the correct user and with the proper rights ✓ User sockets for unknown users are denied ✓ User sockets are removed after a couple of minutes
Tested get_public_session_info on Ubuntu 20.04 (Python 3.8): ✓ Get info via tl-session-param
Tested reconnect session on Fedora 33 (Python 3.9) using build 1995: ✓ Reconnect regular session ✓ Auto mode ✓ Reconnect using start command ✓ Reconnect to start command session without start command - reconnects ✓ Reconnect to regular session with start command - reconnects ✓ Ask mode ✓ Reconnect using start command ✓ Reconnect to start command session without start command - fails * ✓ Reconnect to regular session with start command - fails * ✓ Reconnect to session upgraded from 4.12.1 to build 1995 ✓ tl-session-param -a / ** ✓ tladm session info * This is expected ** The parameters are ordered differently but the values are the same Tested shadowing: ✓ Shadowing enabled for group ✓ Shadowing enabled for user
Tested what was left of sessionstore. Tested on SUSE 12 with build 1997. ✓ Writing sessions and HA updates to disk. ✓ Load HA changes ✓ Load changes ✓ Load changes dumped with 4.12.1 server (With Unicode username on UTF-8 system) ✓ Load sessions ✓ Loading sessions. ✓ Corrupt file -> no sessions loaded. ✓ Loaded sessions file created with server 4.12.1. ✓ Load session for Unicode username from 4.12.1 server (On UTF-8 system). ✓ The number of sessions and users are correctly displayed in log. ✓ Upgrade sessionstore ✓ 4.7.0 -> current build* ✓ Periodic write to disk ✓ Periodic sessions update ✓ Two agents, one session each, restart both agents, wait 10 minutes. Both agents are verified. ✓ The agent is down when trying to do periodic update. ✓ An agent has been restarted and a session was removed after this. ✓ A session was unreachable but is now reachable again. ✓ Writing session changes to license log. * Did not manage to install any older server than 4.7.0, so only that special handling was tested.
Tested handler_verifysessions with server build 1997 on RHEL 8. ✓ Session status ✓ Connected sessions ✓ Disconnected sessions ✓ Unreachable sessions - If we try to reconnect to an unreachable session, the client gives this warning: 'The ThinLinc session is currently unreachable. Try again later or press "Abandon session" to abandon the session, in which case it will never be possible to connect to the session. The session will not be terminated, which means that the desktop environment and applications may continue to run.' ✓ Periodic session updates ✓ Unreachable sessions. - Note that the session status is only logged in vsmserver.log as unreachable once. Once the session is reachable again, this will be logged.
Tested check environment with build 1995 on SUSE 12 ✓ Trying to start services as non-root. ✓ Corrupt pidfile -> overwrite with pid. ✓ Trying to start vsmserver/vsmagent when another instance is already running. ✓ Trying to start vsmserver/vsmagent without finished tl-setup. ✓ Starting vsmagent from inside ThinLinc session. ✓ Vsmagent won't start when things like xvnc, pgrep, ss, xprop and xauth is missing on the system. ✓ Vsmagent won't start if configuration is misconfigured with overlap in allowed session and user ports. (max_session_port > lowest_user_port)
Tested session requests on Fedora 33 (Python 3.9) with build 1997: ✓ Reject session when user exists on master but not on agent ✓ Create session on different agent if it doesn't exist on first choice ✓ Finding free display ✓ min_display and max_display config works ✓ The first free display is used ✓ No free display left rejects session ✓ Setting session key, looks random ✓ Generating vnc password ✓ Generating cookies (pcsctun-cookie & pulse-cookie are identical however) ✓ Create and set correct access rights to system sockets. ✓ Creating home dir ✓ Default mode ✓ Different mode 0777 ✓ Invalid mod (0o0777) -> use default 0700 ✓ Non-ascii username ✓ Trying to create homedir when homedir already exists ✓ SELinux ✓ SessionStart ✓ Non-ascii username ✓ Non-ascii homedir ✓ Single sign on ✓ Basic functions in session: graphics, mouse, keyboard, sound ✓ Wait on vnc port ✓ xvnc startup failed due to timeout (my own Xvnc binary with a sleep)
I've done some unstructured testing on Ubuntu 20.04 with sv_SE.ISO-8859-15 as the locale and "böss€"/"linux99€" as the username/password. Except for bug 7613 everything seems to work just fine.
Checked call_verifysessions on RHEL 8 with build 1997, and tested what was leftover from testing handler_verifysessions. ✓ Timeout
Tested thinlinc-login on Ubuntu 20.04 (Python 3.8): ✓ Normal login ("master" and "dummy" modes) ✓ thinlinc-login as the user's shell
Tested tl-show-licenses on Ubuntu 20.04 (Python 3.8): ✓ No licenses (only free ones) ✓ License file installed
Tested some special cases of the services on SUSE 12 and build 2001 ✓ vsmagent ✓ Running as foreground ✓ Terminating ✓ vsmserver ✓ Running as foreground ✓ Terminating ✓ Any open user sockets are closed when terminating vsmserver.
