On Sun, Mar 20, 2022 at 12:05 PM Stuart Blake Tener < [email protected]> wrote:
> Guacamole users/developers, > > I am a reasonably new user of this software package (the effectuating of > an installation into a container on my ProxMox server having become > occurring just yesterday evening). Thus, in succession thereof, some > several questions came to mind and there enumeration follows hereupon. > > Welcome. > 1) My initial observations of the guacamole's functionality seemed to not > obviously stand demonstrative of a manner by which to purge or clear out > the entirety of accumulated log entries via the GUI. Are there plans to add > such functionality? If so, I would recommend being able to clear all > entries and also a manner by which to clear entries betwixt a start and end > date as well. > > No, there is no way to do this today via the GUI. The Jira page would be the location to request such a feature: https://issues.apache.org/jira/projects/GUACAMOLE/issues > 2) I was attempting to use guacamole to SSH into a Cisco 3560G switch and > realized that certain SSH parameters (such as cipher & kexalgorithms in the > instant case) needed to be set forth for an SSH session to initiate > properly, is there a manner by which guacamole can be impelled to assert > honoring such configuration parameters during the instantiation of an SSH > connection or are there plans to add this functionality to the GUI? > > In general Guacamole will auto-negotiate such features, assuming that the version of libssh2 in use on the system running guacd supports the given Cipher and Key Exchange algorithms. This is a pretty frequently-asked question of Guacamole, and it's generally (though not always) due to an older version of libssh2 being used/present on the system where guacd has been installed. In a few cases libssh2 lacks the required cipers or kex algorithms entirely. The overall point is that Guacamole's ability to support certain SSH features is usually more dependent on the underlying library, libssh2. I don't know that there are many, if any cases, where manually forcing parameters is required. > 3) I could see where there could be usefulness to having a mechanism by > which one could kill all active sessions for the currently logged in user. > Additionally, the ability for an administrative level account to terminate > all connections for a different actively logged in user and as well cause > said user to be instantly locked out from logging back in would also be a > rather useful functionality to have in the package. > The first part of your request already exists - sessions can be managed by administrative users, including the ability to join the active session, as well as the ability to forcibly kill sessions. The second part of it is not necessarily immediately available - you cannot completely lock out and kill a user all in one click of a button, but it shouldn't take much - you could disable the user's account, and then go search for all the sessions open by a particular user and kill those. > > 4) I can see where having a preference setting (on a per user basis) to > cause the package to immediately return to the recent connections / all > connections menu after disconnecting from a particular connection (instead > of the "home/reconnect/logout" prompt) would be a nice to have. > > I'm not sure I see the value in this - there has been a request that comes up periodically to disable the auto-reconnect feature, and I can see instances where that would be nice, but I don't know that I see a lot of value in getting rid of the prompt. Just my opinion. > 5) I see that all connection entries added into the package are then > presented in an alphabetically sorted manner. I would enjoy having a way to > substantiate the list so that the order was something I could arrange via > the GUI vice alphabetical sorting or at least in the ordered add. > > I would say that organizing connections into groups is the best way to accomplish this. I'm not sure that the complexity of allowing re-sorting outside of alphabetical sorting is worth > I have not yet tested the VNC or RDP functionality as yet, though I plan > to attempt leveraging such connective functionality later today in > pursuance of evaluating those capabilities as well. In no uncertain terms > the capability of amalgamating in a centralized manner access to SSH, RDP, > and VNC via a web interface is of great utility to me and I am happy to > have found guacamole. > Yep, that's the goal of the project! > > These are my ideas after a first blush encounter with the package. The > forgoing notwithstanding, I find this package to be very useful and I saw > no outright bugs in it as I used it initially. Thank you to everyone that > has worked so hard to create and maintain this package and I hope to see to > its improvement with my ideas and potentially code contributions in the > future. > > Glad to hear it, and welcome to the community. > Thank you in advance to any respondents to this epistle and do have a most > healthy and safe day whilst avoiding the thugs! > > I would agree that avoiding thugs is a wise choice. -Nick >
