Details

      Description

      The web application currently assumes that one guacd will be used to provide access to all connections. This assumption fails if:

      • Multiple guacd instances are spread out across different networks
      • Another component implementing the Guacamole protocol is being used instead of guacd on a per-connection basis (like the X.Org driver of GUACAMOLE-168)

      Though no change is needed to the core APIs, as no such assumption is made at that level, the web application and extension API should be modified such that the guacd (or other Guacamole proxy) applicable to a connection can be specified explicitly for that connection.

        Issue Links

          Activity

          Hide
          mike.jumper Michael Jumper added a comment -

          I forgot to add documentation for the new columns, and to update the main schema creation script.

          Show
          mike.jumper Michael Jumper added a comment - I forgot to add documentation for the new columns, and to update the main schema creation script.
          Hide
          TdSN Thiago dos Santos Nunes added a comment - - edited

          Hi Nick,

          Thanks for your explanation. I followed your advice.

          I opened a ticket (one by now):

          https://issues.apache.org/jira/browse/GUACAMOLE-283

          Thanks a lot!

          Show
          TdSN Thiago dos Santos Nunes added a comment - - edited Hi Nick, Thanks for your explanation. I followed your advice. I opened a ticket (one by now): https://issues.apache.org/jira/browse/GUACAMOLE-283 Thanks a lot!
          Hide
          nick.couchman@yahoo.com Nick Couchman added a comment -

          This particular ticket doesn't necessarily deal with high availability or failing from one guacd server to another, just being able to assign a connection to a particular guacd instance, as might be necessary to overcome firewall issues and deal with distributed networks, and as is necessary for implementing the X.org driver.

          You're asking about two other things, which are probably good things to implement, but separate from this particular ticket and probably separate from each other:

          • Ability to load-balance or at least fail over from one guacd instance to another. guacd doesn't really care about where the client is getting its connection information (MySQL, PostgreSQL, LDAP, etc.), it just receives the Guacamole protocol information from the client and processes the translation of the Guacamole protocol to whatever back-end you're connecting to (SSH, RDP, etc.).
          • Ability to load-balance the Guacamole client and share sessions and configuration information between multiple instances of the client. This is likely already possible to some degree, although I'm not entirely sure how safe it is. There are some things that probably wouldn't work correctly - like tracking active connections - and some others that might be unsafe - like multiple admins editing the same connections.

          Anyway, probably worth opening a couple of separate tickets for these issues.

          Show
          nick.couchman@yahoo.com Nick Couchman added a comment - This particular ticket doesn't necessarily deal with high availability or failing from one guacd server to another, just being able to assign a connection to a particular guacd instance, as might be necessary to overcome firewall issues and deal with distributed networks, and as is necessary for implementing the X.org driver. You're asking about two other things, which are probably good things to implement, but separate from this particular ticket and probably separate from each other: Ability to load-balance or at least fail over from one guacd instance to another. guacd doesn't really care about where the client is getting its connection information (MySQL, PostgreSQL, LDAP, etc.), it just receives the Guacamole protocol information from the client and processes the translation of the Guacamole protocol to whatever back-end you're connecting to (SSH, RDP, etc.). Ability to load-balance the Guacamole client and share sessions and configuration information between multiple instances of the client. This is likely already possible to some degree, although I'm not entirely sure how safe it is. There are some things that probably wouldn't work correctly - like tracking active connections - and some others that might be unsafe - like multiple admins editing the same connections. Anyway, probably worth opening a couple of separate tickets for these issues.
          Hide
          TdSN Thiago dos Santos Nunes added a comment -

          In this ticket we will have a option to create a High availability guacamole cluster?

          Many guacd and/or many tomcat to rely.

          If we have the option to create an environment where we have several guacd and they count the connections between them.

          For example:

          An environment with 2 tomcats of frontend and 2 guacd of backend and 1 MySQL of integrated bank between them. It´s will be a VERY GREAT OPTION.

          Show
          TdSN Thiago dos Santos Nunes added a comment - In this ticket we will have a option to create a High availability guacamole cluster? Many guacd and/or many tomcat to rely. If we have the option to create an environment where we have several guacd and they count the connections between them. For example: An environment with 2 tomcats of frontend and 2 guacd of backend and 1 MySQL of integrated bank between them. It´s will be a VERY GREAT OPTION.

            People

            • Assignee:
              mike.jumper Michael Jumper
              Reporter:
              mike.jumper Michael Jumper
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development