Hello,

current version of winswitch have problems with case sensitive username. Currently it doesnt maintain the case of the username when parsing to other softwares (putty or any other). Looks like this was not a problem with old openssh, but now the username case is sensitive.

How to reproduce: Username: ALLUPPERCASE server machine: linux, OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 Winswitch:

setup login to $server_machine with $USERNAME in uppercase. all winswitch attempts to connect will fail. If you setup winswitch without username and password, and type the username by hand in all uppercase, it will fail too, so it's a problem of parsing the username to the program since openssh will only recognize the uppercase name.

This will not work with ssh keys either.

within a terminal (cygwin for example), the ssh ALLUPERCASE@$server_machine works like a charm, as also with plink/Tortoise provided by winswitch.

Some desktops (gnome and others) offer the option to shutdown/reboot. I also have the case where openbox will log me out of my real desktop when I logout of the virtual one! WTF!
In a virtual desktop environment this is most certainly NOT wanted.
We need a way to tell the window manager to just offer logout and nothing else.
Something a bit like ​these gconf keys maybe?
Maybe try to detect which commands get used and define dummy aliases for them? Or maybe it's dbus related?

Currently this is a manual (tedious) process, best documented here: ​http://mac101.net/content/how-to/how-to-create-dmg-art-for-fancy-application-installations/comment-page-1/ (and also here: ​http://www.wikihow.com/Make-a-DMG-File-on-a-Mac and here: ​How to create a custom dmg installer on mac)

But there must be a better way, maybe one of these can help:

• ​http://stackoverflow.com/questions/96882/how-do-i-create-a-nice-looking-dmg-for-mac-os-x-using-command-line-tools
• ​http://www.objectpark.org/buildDMG.html
• ​http://projectmouse.org/mac/osx/hdiutil+-+mac+os+x+disk+images+manipulate+tool.html

We check that the password exists before calling attach_to_session()... so this is not going to work as-is.

This is also used in some places to popup the quick_connect window. Not going to be easy!

Platform: Windows (very likely exists everywhere, but none of my Linux boxes have working rotation support)

Main display is a laptop display, 1600 x 900. Secondary display to the right is 1200 x 1920. Tertiary display to the right of that is 1280 x 720. Tertiary display appears irrelevant to problem.

When clicking on taskbar tray on left most monitor, I get the menu with totally incorrect internal dimensions, and have to scroll many lines into view to see anything: left monitor screenshot

When clicking on taskbar tray on secondary monitor, the menu appears with the correct internal dimensions, but is located complete out of the correct position (this happens on all systems with multiple monitors, not just with large resolution differences): middle monitor screenshot

When selecting the system tray menu on the tertiary monitor, it appears both extremely out of place, as well as with the wrong internal dimensions: right monitor screenshot

... I suspect, that it is trying to draw the menu in the absolute coordinates for the desktop, and using the absolute desktop dimensions, when it should be doing it based on the currently active display rather than the entire desktop space.

I've tried both the 0.12.21 and 0.12.22 builds on my Mac. The applet window never displays in the system tray. The server starts and the Ubuntu system can connect. But it is not possible from the Ubuntu system to start an app on the Mac.

Please let me know what files / logs you need for troubleshooting purposes.

At the moment, if a client can login then he can access everything.

We must change the way we store authorization keys from the current ssh style (one line per file in .winswitch/client/authorized_keys - which should be in /server/ anyway) to a first class object: ClientPermissions, saved as UUID.conf

OTOH at minimum, we should have:

• can_start_session
• can_start_desktop
• can_control_as_owner
• can_control_as_actor
• can_shadow_[local_display|vnc|nx]
• can_tunnel_[sound|print|file]
• can_grant_permissions
• can_see_others_permissions

On login, we look it up and pass the permissions back to the user as part of the add_user command. The ssh-add and local logins will grant all permissions automatically.

Some new session attributes (set on start and modifiable):

• locked (only owner/actor can release it)

etc.

Some new commands:

• set_session_attributes (and also overload start_session) to protect a session.

These sessions cannot be started, may be stopped (if we have the pid and allow it). We may not be able to detect connection server side (good thing we still have the client status update code for vnc!)

We need a way to register them (ie: when starting a qemu instance) and maybe remove them (if we want to or if we can't detect the process' ending with its pid)

The new feature in 0.11.3 to wrap regular commands via winswitch_command_wrapper is very neat (and fast too!), but for more people to use it we need to make it easier to setup: provide a tool to make it easier to convert a bunch of .desktop files to use/not-use the wrapper.

It needs to:

• be able to run as root to change system wide settings
• run as user and save to user specific shortcuts
• take the blacklists into account so we don't convert software that does not work (see #132)

The ​freedesktop menu specification seems to allow this sort of thing. ​The freedesktop menu article covers similar grounds to what we want (refers to the 'alacarte' menu editor and covers the drawbacks of duplicating menu entries)

The wrapper also needs an easy way of being toggled:

• global on/off option which can be changed from applet
• detect magic key and based on wrapper_magic_key_action, either:
  • launch via wrapper
  • do not launch via wrapper (if default is off)
  • ask
• option to start the applet if it is not running

Also maybe:

• detect if the desktop files have been modified (ie: by OS upgrades) and re-apply the changes

It may be worth looking at #34 (menu configuration app) at the same time.

r4569 makes VirtualBox sessions usable but has a number of limitations.

• password mode is broken? rdesktop/xfreerdp aren't very helpful with the error message here. (ie: "ERROR: send: Broken pipe")

(also when loading a session from disk: verify that the password we have is the right one by re-encoding it rather than always assigning a new one?)

• when the session fails to start we end up calling early_failure which sets it as UNAVAILABLE but this gets reset when the session data is parsed again. Either leave it as unavailable or...?
• we should fire call_when_done when the server log shows the port is ready rather than polling it. ie:

  VRDE server is listening on port 3389.
  VRDE server is inactive.
  

• support cloning via the UI (since we already enable multi-attach)
• allow local user to resume via SDL? Pure client-side session handling will complicate things..

etc..

We should be using callbacks and twisted_exec to avoid both blocking and the need for threading.

Threaded code is more complex, requires locking and often causes bugs.

As of r4536 (after improvements in r4635, r4631, etc), here are the remaining occurrences of threaded code that should be converted/improved:

• applet / client_base threaded_start - messy..
• controller:
  • threaded_ready
  • capture_display
  • do_shadow_session
  • reload_server_start_menu

• quick_connect.validate: slow socket check should use twisted (low priority)
• version_check: slow - safe via ask(), maybe we should use twisted for downloading the data? (low priority)
• FS_Client_Helper (currently unused - low priority)

The following occurrences have been verified or fixed already:

• controller: open_file
• server_line_connection.do_send_bytes
• server_util_base.start_read_from_log must use a thread as it may well be slow/long due to I/O and callbacks: process_log_data is now safe and process_log_line (many instances) has been verified
• local_named_pipe (must run in its own thread?)

In progress / pending:

• gstreamer_util.exec_launch_wrapper: should use twisted_exec

winswitch 0.12.15, debian package

winswitch_applet --open_server_config= has these bugs:

• the applet.log gets rotated; call it twice, and the running applet logs into a deleted file.
• it doesn't connect; the winswitch menu shows the server as connected, but the sessions are not resumed, and clicking on "resume" just makes the server-menu show up disconnected again.

Generally I'd like to say "connect to server X, session named Y" - where X can contain the "​ssh://" indicator, for example.

Perhaps a dbus interface would be better?

When hitting winswitch.org/forum response is: Error 500 Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed.

I think *I* caused this following these steps:

1 - register new user for me using email and password 2 - click on verification link in email 3 - attempt to associate OpenID account (using Gmail) 4 - accept Google's warning on linking account 5 - attempt to associate OpenID account with "existing account" created in step 1 above, providing username and password specified in step 1

At this point, the forum threw the 500 error. Sorry :(

Also, is the forum the right place to post user questions? (there is little activity there) I checked the IRC channel, but no one was there (maybe remove the link to irc.winswitch.org on ​http://winswitch.org/documentation/ or update to freenode)

Use "Windows Shell Extensions" to make it easier to action on a window (since the extension will be placed in the window's bar)

For Linux alternatives, see #111 (cant be done with metacity or other default window managers - shame that)

On linux we use xlib to know the "idle time" of the X session and compare that against the timeout value.
We could just do something more similar to what we do on win32 and get notifications when the screensaver is (de)activated:

dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver',member='SessionIdleChanged'"

More information about the dbus interface, and in particular the ActiveChanged signal in the ​gnome-screensaver doc

The FAQ contains an example of actions using dbus-monitor: ​perform_actions_when_the_screensaver...

For reference, the win32 code is ​track-session-events (from the great win32_how_do_i)

Synergy+ has a bug entry with useful links in it: ​Support for gnome-screensaver as well as xscreensaver

Some other useful pointers:

• ​gnome screensaver discussion on mailing list, dated 2006. Refers to org.gnome.ScreenSaver
• ​idle.c module for X11 used by gajim, which calls XScreenSaverQueryInfo.
• ​idle.c module for OSX (uses IOKIT via C)

This lock should be implemented client side only so the server can still make a policy decision to force the client to disconnect.

part of #92

step 1: move it to a GlobalSettings

step 2: UI to add/remove values

We should be able to re-use some of the techniques from ​x2vnc and ​x2x to detect when the window/mouse is over the edge of the screen and use this as a trigger to send the application to the machine defined as being attached to that edge.

Difficulties:

• Integration with the window manager: how do we find if there is a window being dragged easily? (in python and without libX11/win32 code if possible...) - maybe defining a compiz extension would be easier?
• UI for defining which machines are attached to which edges... and how to deal with machines coming and going in a consistent manner.

Alternatives:

• Once a plugin mechanism is added to synergy+, we could potentially use that to hook our window move, see ​this discussion

For MS Windows, see #24

VNC uses a very weak authentication mechanism: an 8 character password! ouch

So we could add an option to always tunnel VNC. (server side or client side? both?) OR use tls and certs TigerVNC 1.1 supports gnutls

Some links:

• ​http://www.freedesktop.org/wiki/Xming/Building (fails)
• ​Cross compiling for Xming.exe since Mesa merge (also fails)
• ​XMing version that uses Mesa

Ideally, also build a 64-bit version as part of #142

In all of these cases, encryption will consume extra cpu for no good reason.