Re: guacamole server - libfreerdp-dev incompatible with Debian buster
On Tue, Jul 2, 2019, 13:20 M Bond wrote: > Hello, kindly be informed that the libfreerdp-dev no longer work with > guacamole-server-1.0.0 on Debian buster, although it worked with Debian > stretch. > > http://guacamole.apache.org/doc/gug/installing-guacamole.html > > I tried to use libfree2-dev to configure the compile list but it didn't > work. > > As a result, freedrp is missing on guacamole-server-1.0.0 on Debian buster. > > Kindly advise. > You'll want to follow this issue in JIRA: https://issues.apache.org/jira/browse/GUACAMOLE-249 Support for FreeRDP 2.0.0 is essentially a rewrite but is underway. It is part of the upcoming 1.1.0 release. - Mike
Re: guacamole-common-js BlobWriter.js Bug
Hi James, Thanks! However: 1) Your modified BlobWriter.js didn't actually make it through. The attachment was likely stripped. 2) That doesn't matter anyway, as contributions need to be submitted via pull request, not via email / mailing list. If you would like to contribute a change, please submit that change by opening an issue in JIRA describing the bug/feature/etc and then opening a pull request in GitHub containing your change. Please see our contribution guidelines: https://github.com/apache/guacamole-client/blob/master/CONTRIBUTING You can also see this in practice if you look over the git history and past merged pull requests. - Mike On Mon, Jun 24, 2019 at 7:44 PM James Caple wrote: > Hi, > > Thanks for the guacamole project. I've been using it with good success on > a project at work. I've been developing a Javascript Client to integrate > with MS Windows Virtual Machines. I used the Javascript API to develop > some file transfer capabilities. I was unable to get the BlobWriter JS > file to work as currently available here ( > https://github.com/apache/guacamole-client/tree/master/guacamole-common-js/src/main/webapp/modules). > I kept getting the following error whenever I'd try to write files to the > VM: > > zone.js:1495 Uncaught (in promise) DOMException: Failed to execute > 'readAsArrayBuffer' on 'FileReader': The object is already busy reading > Blobs. > at _global.. [as readAsArrayBuffer] ( > https://redacted/polyfills.6e39da16eddfecb84434.js:3830:60) > at readNextChunk ( > https://redacted/main.51a4f7c78afe09ae8d5e.js:168269:20) > at > push../src/app/components/core/desktop/js/BlobWriter.js.redacted.ArrayBufferWriter.sendMoreChunks > [as onack] (https://redacted/main.51a4f7c78afe09ae8d5e.js:168295:17) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.OutputStream.stream.onack > (https://redacted/main.51a4f7c78afe09ae8d5e.js:168396:25) > at ack (https://redacted/main.51a4f7c78afe09ae8d5e.js:114024:28) > at > push../node_modules/guacamole-common-js/dist/guacamole-common.js.Guacamole.HTTPTunnel.tunnel.oninstruction > (https://redacted/main.51a4f7c78afe09ae8d5e.js:114685:13) > at XMLHttpRequest.parseResponse [as > __zone_symbol__ON_PROPERTYreadystatechange] ( > https://redacted/main.51a4f7c78afe09ae8d5e.js:123910:40) > at XMLHttpRequest.wrapFn ( > https://redacted/polyfills.6e39da16eddfecb84434.js:3667:39) > at > ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask > (https://redacted/polyfills.6e39da16eddfecb84434.js:2758:31) > at Object.onInvokeTask ( > https://redacted/main.51a4f7c78afe09ae8d5e.js:33312:33) > > I came up with an easy workaround to this issue, and thought someone might > be interested. My amended BlobWriter.js is attached. > > Thanks, > > James Caple >
Re: When it says "connection selection menu"...
On Sun, Jun 23, 2019 at 7:52 PM Mark Nolan wrote: > ... does it mean the list of connections on the home page after logging in? > > https://github.com/apache/guacamole-client/pull/417 > > No, it's referring to a dropdown of available connections within the Guacamole menu. See: * https://github.com/apache/guacamole-client/pull/391 * https://issues.apache.org/jira/browse/GUACAMOLE-723 If so, is it possible to make this functionality configurable since, in my > set up, that host may not actually be running and the user may need to > start it before connecting. > No. I don't know what you're doing specifically that would make the feature problematic, or that would make the behavior of your extension fragile, but I wouldn't expect it to be. The new UI element is powered by the same data as the home screen and shares a common core. I would recommend (1) testing your extension against this feature to see if updating it is even needed and (2) updating it accordingly if things fail. - Mike
Re: Auth Provider from 0.9.14 does not work with 1.0.0
On Tue, Jun 18, 2019 at 10:30 AM Mark Nolan wrote:
> There were no other errors at all!
>
> For a moment I was very excited that I might have forgotten to update that
> dependency, but I hadn't been that stupid (wouldn't have been the first
> time!). I didn't know whether to be relieved or frustrated!
>
> Anyway, I created a minimal version and went through it all bit by bit. The
> problem was that I had another version of the JAX-RS api in the pom:
>
>
> org.glassfish.jersey.media
> jersey-media-json-jackson
> 2.27
>
>
> Need this to get a much more up to date version of Jackson and,
> conveniently, it also allowed the JAX-RS annotations to compile.
>
As it's the Guacamole webapp that will be using the base parts of Jersey,
this may be causing trouble.
>
> This worked fine in 0.9.14, but not in 1.0.0. Not really sure why that
> should have changed.
>
My guess would be that including this previously had no effect, with your
extension actually using the classes exposed by the webapp. Part of the
changes for 1.0.0 included giving extensions priority for classes on the
classpath, allowing extensions to use different versions of classes
internally even if the webapp uses the same library. That may not work as
expected for something like Jersey.
See:
http://guacamole.apache.org/releases/1.0.0/#improvements-to-extension-api
("... Dependency
precedence has been updated so that extensions always see the classes they
bundle, even if the web application bundles a different version of the same
class. ...")
Are you sure you need to include Jersey in your dependencies? I've normally
used the following to make JAX-RS annotations available within an extension
and let the webapp handle the rest:
javax.ws.rs
jsr311-api
1.1.1
provided
- Mike
Re: AngularJS issue upgrading authentication provider from 0.9.14 to 1.0.0
On Tue, Jun 18, 2019 at 11:14 AM Mark Nolan wrote:
> ...
> The browser console shows this:
>
> angular.js:14800 Error: [$parse:syntax]
>
> http://errors.angularjs.org/1.6.9/$parse/syntax?p0=%7B=invalid%20key=17=xxxAuthGcpStop(%7B%7Bitem.identifier%7D%7D)=%7Bitem.identifier%7D%7D
> )
> at angular.js:88
> at q.throwError (angular.js:15358)
> at q.object (angular.js:15347)
> at q.primary (angular.js:15236)
> at q.unary (angular.js:15224)
> at q.multiplicative (angular.js:15211)
> at q.additive (angular.js:15202)
> at q.relational (angular.js:15193)
> at q.equality (angular.js:15184)
> at q.logicalAND (angular.js:15176) " height="100%" viewBox="0 0 16 24" fit="" focusable="false" xmlns="
> http://www.w3.org/2000/svg; preserveAspectRatio="xMidYMid meet"
> class="xxx-icon xxx-enabled"
> ng-click="xxxAuthGcpStop({{item.identifier}})">"
>
Did you mean:
ng-click="xxxAuthGcpStop(item.identifier)"
?
For AngularJS, depending on the directive, you'll find things like
some-attribute="{{ angular expression }}" and some-attribute="angular
expression". The ngClick directive is one of the latter. The double braces
introduce an angular expression, when necessary, but are not valid syntax
_within_ an angular expression.
- Mike
Re: Jenkins build is back to normal : guacamole-client-coverity #108
On Sat, Apr 27, 2019 at 2:05 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See < > https://builds.apache.org/job/guacamole-client-coverity/108/display/redirect > > > Note - the original issue with scan.coverity.com not sending intermediate certs [1] is still present. To unblock things on our end, I've manually downloaded the full certificate chain and added it to the Jenkins build. - Mike [1] https://lists.apache.org/thread.html/c7cd6865dac630c17df746fddcf8d6a32a5c01a039edbe82677ea5f3@%3Cdev.guacamole.apache.org%3E
Re: Build failed in Jenkins: guacamole-client-coverity #104
On Sat, Apr 20, 2019 at 10:55 AM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See < > https://builds.apache.org/job/guacamole-client-coverity/104/display/redirect?page=changes > > > ... > + curl --data-urlencode token=[***] --data-urlencode > project=guacamole-client https://scan.coverity.com/download/linux64 > + tar -xz > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >0 0 00 00 0 0 0 --:--:-- --:--:-- > --:--:-- 0 0 00 00 0 0 0 --:--:-- > --:--:-- --:--:-- 0 > curl: (60) server certificate verification failed. CAfile: > /etc/ssl/certs/ca-certificates.crt CRLfile: none > It looks like the SSL certificate chain for scan.coverity.com became incomplete sometime between the last successful build (2019-04-10) and today. Browsers that will automatically download missing certs will continue to function, but tools like curl which rely on receiving the full chain will fail. I've sent an email to Coverity to let them know of the issue (if they don't already) and hopefully correct things. - Mike
Re: Guacamole Prompting, Round 4,963,211
On Sat, Apr 6, 2019 at 11:38 PM Nick Couchman wrote: > On Wed, Mar 13, 2019 at 1:18 PM Nick Couchman wrote: > > > > > >> Looks reasonable. Naming convention within libguac for the various > >> instruction sending functions is guac_protocol_send_OPCODE(), though, so > >> this would need to be guac_protocol_send_required(). > >> > > > > I've updated the naming conventions on these... > > > > > >> > >> Perhaps the instruction should accept a list of parameter names rather > >> than > >> just a single name? This is what is done for the related "args" > >> instruction: > >> > >> > https://guacamole.apache.org/doc/1.0.0/libguac/protocol_8h.html#a6047d380b097ebc7d5f35b167e3419e6 > >> > >> > > Yeah, this was my next step, but just thought I should start with getting > > it working, then move on to making the code more efficient. > > > > > >> Client: > >> > > >> > > >> > https://github.com/necouchman/guacamole-client/commit/72de5595880baea46505cf4f9ad49640f16519e7 > >> > >> > >> Same here - convention is "onOPCODE", so this would need to be > >> "onrequired". > >> > > > > Fixed. > > > > > >> > > >> I think you will run into trouble manually parsing the Guacamole > protocol > >> with a guac_parser in a context where inbound instructions are already > >> being parsed received. Is this because the FreeRDP authentication > callback > >> must be synchronous? > >> > >> > > I'm not sure. On the xfreerdp side of things, this code results in a > > Password: prompt on the command line, and the xfreerdp app waits until > you > > enter something before proceeding. > > > > Yeah, looks like this is going to be problematic. Parsing the Guacamole > protocol while it is already running doesn't seem to work - if I use > guac_parser_expect(), it fails because there are other things going on in > the background for the connection and the argv opcode isn't the first thing > through, so it doesn't get what it's expecting. I also tried just looping > on guac_parser_read() and looking at the opcodes as they come across, > ignoring anything but argv, but it still fails. Right. You cannot have two parsers reading from the same socket, nor should protocol support be attempting to parse the Guacamole protocol manually. To handle argv, you need to provide an argv_handler to the guac_user struct. That handler will be called when argv is received. This probably means that the use of the FreeRDP authentication callback > will not work, unless > there's some other way to accomplish this. I could still try to block the > pthread until the input is received, but this might cause other problems on > the client side with an unresponsive connection? > If FreeRDP depends on this being synchronous, yes, the handler will need to block on some sort of pthread condition which is signalled when the credentials are set. Reading of the argv instruction should happen magically as long as argv_handler is properly set, as Guacamole protocol parsing is handled for you by guacd and libguac in a separate thread. If blocking will potentially result in the connection going silent, there's a function for that - guac_socket_require_keep_alive(): http://guacamole.apache.org/doc/libguac/socket_8h.html#a1d8c5111a8234c7785ae23f379f7db03 That will force the guac_socket to send a "nop" instruction roughly every 5 seconds if nothing else is sent during that period. - Mike
Re: Not set width and height,Not auto suite my screen.
On Wed, Mar 13, 2019 at 7:37 PM 若鸟 wrote: > My English is so bad,you may find it difficult to read. > I coding with guacamole-ext and implement the example servlet from the > official manual.I am not set width and height but the dispaly form browser > don't auto suite my screen. > As far as RDP is concerned, there are three sets of dimensions involved: 1) The "width" and "height" connection parameters. These values explicitly set the width and height in pixels. They are raw parameters without any implications about what these dimensions mean for the client. 2) The client's requested/desired/optimal width and height. These are part of the connection handshake and are used by the RDP implementation if "width" and "height" aren't given. The protocol implementation is allowed to adjust these values. 3) The dimensions of the client display in the browser. Unless you set otherwise through a call to scale(), the size of the client display will exactly match the remote display, with the remote display being set as described in #1 and #2 above. If you want your custom application to scale the display automatically, you will need to: 1) Forward the relevant dimensions to your tunnel implementation so that it can forward them to guacd during the connection handshake (using an instance of GuacamoleClientInformation): http://guacamole.apache.org/doc/guacamole-common/org/apache/guacamole/protocol/GuacamoleClientInformation.html#setOptimalScreenWidth-int- http://guacamole.apache.org/doc/guacamole-common/org/apache/guacamole/protocol/GuacamoleClientInformation.html#setOptimalScreenHeight-int- http://guacamole.apache.org/doc/guacamole-common/org/apache/guacamole/protocol/ConfiguredGuacamoleSocket.html#ConfiguredGuacamoleSocket-org.apache.guacamole.net.GuacamoleSocket-org.apache.guacamole.protocol.GuacamoleConfiguration-org.apache.guacamole.protocol.GuacamoleClientInformation- 2) When the display changes size on the client side (the "onresize" event) and when the browser is resized, recalculate the necessary scale and set it explicitly through a call to scale(): http://guacamole.apache.org/doc/guacamole-common-js/Guacamole.Display.html#event:onresize http://guacamole.apache.org/doc/guacamole-common-js/Guacamole.Display.html#scale - Mike
Re: Guacamole Prompting, Round 4,963,211
On Thu, Mar 7, 2019 at 1:13 PM Nick Couchman wrote: > Well, I'm taking my next stab, of who knows how many, at getting prompting > to work in Guacamole, but going the route that Mike suggested on the pull > request and using the protocol to request the parameters rather than > tokens. I'm determined to do this :-). > > Nice! :) > I'm running into some challenges with this that I think may be related to > handling the usually-asynchronous nature of JavaScript and the connection > protocol, but needing to temporarily make the connection pause to wait for > the input. I've implemented the protocol-level changes for this - I'd > appreciate some sanity check on my code, but those items were pretty easy. > See the following commits: > > Server: > > https://github.com/necouchman/guacamole-server/commit/c3bf085076344951621a0170b205d51e387f7cd6 > > Looks reasonable. Naming convention within libguac for the various instruction sending functions is guac_protocol_send_OPCODE(), though, so this would need to be guac_protocol_send_required(). Perhaps the instruction should accept a list of parameter names rather than just a single name? This is what is done for the related "args" instruction: https://guacamole.apache.org/doc/1.0.0/libguac/protocol_8h.html#a6047d380b097ebc7d5f35b167e3419e6 Client: > > https://github.com/necouchman/guacamole-client/commit/72de5595880baea46505cf4f9ad49640f16519e7 Same here - convention is "onOPCODE", so this would need to be "onrequired". Easy enough - hopefully those look sane? I've done a little more building > out for RDP connections, for both server and client. On the server-side, > there's actually a callback function that is invoked by FreeRDP when > authentication fails. I'm using this as a way to send the prompts back to > the client: > > > https://github.com/necouchman/guacamole-server/blob/cfe68a796eb58b1aaecf82bbd01fe49e685f3846/src/protocols/rdp/rdp.c#L445-L501 > > I think you will run into trouble manually parsing the Guacamole protocol with a guac_parser in a context where inbound instructions are already being parsed received. Is this because the FreeRDP authentication callback must be synchronous? Things will need to be changed to allow normal handling of received instructions, with the response to your prompt being received via two argv streams, handled with user->argv_handler, etc. This may already be doable if the FreeRDP aspects of the connection are in a separate thread (I think they are), as this function could (1) send the request for credentials and (2) block on a pthread conditional waiting for those credentials to be received. This seems to be working, fine - I see the prompt come through on the > client-side when implementing a simple GuacClient.onprompt() function that > just logs the request. However, I don't think the connection is pausing > and waiting for the response - rather than getting a prompt on the client > side, I get a notification that the connection failed. Relevant client > code is here: > > > https://github.com/necouchman/guacamole-client/blob/23c784e9d812ba3fd3ee0dd352f3b75e7f422381/guacamole/src/main/webapp/app/client/types/ManagedClient.js#L517-L581 What error are you seeing specifically? - Mike
Re: Guacamole docker image version?
On Wed, Feb 20, 2019, 11:44 Tezarin wrote: > Hi Nick, > I decided to upgrade my guacamole version so puled down the v 1.0.0 (was > running 0.9.14 before), I have a RDS as a database and after I got the > containers running, I noticed the GUI doesn't come up. docker logs shows > this schema error: > ### Error querying database. Cause: > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table > 'guacamole.guacamole_entity' doesn't exist### The error may exist in > org/apache/guacamole/auth/jdbc/user/UserMapper.xml### The error may involve > defaultParameterMap### The error occurred while setting parameters### SQL: > SELECT guacamole_user.user_id, > guacamole_entity.entity_id, guacamole_entity.name, >password_hash, password_salt, password_date, > disabled, expired, access_window_start, > access_window_end, valid_from, > valid_until, timezone, full_name, > email_address, organization, organizational_role, >MAX(start_date) AS last_active FROM guacamole_user >JOIN guacamole_entity ON guacamole_user.entity_id = > guacamole_entity.entity_id LEFT JOIN guacamole_user_history ON > guacamole_user_history.user_id = guacamole_user.user_id WHERE >guacamole_entity.name = ? AND guacamole_entity.type = > 'USER' GROUP BY guacamole_user.user_id, > guacamole_entity.entity_id; SELECT > guacamole_user_attribute.user_id, > guacamole_user_attribute.attribute_name, > guacamole_user_attribute.attribute_value FROM > guacamole_user_attribute JOIN guacamole_user ON > guacamole_user.user_id = guacamole_user_attribute.user_id JOIN > guacamole_entity ON guacamole_user.entity_id = guacamole_entity.entity_id >WHERE guacamole_entity.name = ? AND > guacamole_entity.type = 'USER'### Cause: > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table > 'guacamole.guacamole_entity' doesn't exist > > > Can you please advise what I did wrong? http://guacamole.apache.org/releases/1.0.0/#database-schema-changes Also: http://guacamole.apache.org/doc/1.0.0/gug/jdbc-auth.html#idm46248438612160 - Mike
Re: Maven Dependency Glitch
On Mon, Feb 11, 2019 at 3:33 PM Nick Couchman wrote: > After a question on the mailing list recently I decided to try to write an > extension that starts a Docker container upon login and sets up a > connection to the container automatically. I decided to use the > docker-java client: > > https://github.com/docker-java/docker-java > > I've run into an interesting issue with this. If I include the dependency > normally - without specifying a scope - it pulls in between 15 and 20 MB > (!) of dependencies - the overall size of the target file is between 18 and > 20 MB. Interestingly Guacamole fails to load this extension with an error > that the Authentication Provider class cannot be found. It's almost as if > there is a size limitation, either overall file size in bytes, or number of > entries within the JAR, that the load chokes on. I cannot find anywhere in > the Guacamole code where this is specified, so I'm not sure where the > limitation is, or if that's really the issue, but it seems that way. > Might the .jar be signed? Does the documentation for the docker-java client indicate that some other dependencies must be manually added? > Any ideas the best way to proceed with this, either any insight on the > limitation for the file size for a Guacamole extension, or how to correctly > generate a JAR for the Docker client that could be placed into a lib > directory (similar to a JDBC driver) that would contain the correct > dependencies? > There's definitely no size limit. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Sat, Feb 9, 2019 at 12:14 PM Nick Couchman wrote: > > > > > Definitely. > > > > Outside of the above, it looks like scope is generally settled. I'll move > > forward with the creation of 1.1.0 branches, etc.: > > > > http://guacamole.apache.org/release-procedures-part1/ > > > > Very nice. > > Do we want to create any branches for other versions - 1.1.1, 1.2.0, 2.0.0, > etc. - at this point? Or just continue to be careful about what gets > merged to master until we get past 1.1.0? > IMHO, let's hold off on creating other release branches until the time comes to make a decision about API-incompatible changes. We should do what we can to ensure that all changes are compatible, and bristle accordingly at changes which propose to break compatibility. If breaking compatibility is the only option, then I suppose it's discussion time for whether the community wants to support 1.2.x and 2.0.x branches simultaneously. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Sat, Feb 2, 2019 at 4:11 PM Nick Couchman wrote: > ... > >> > >> Okay, sounds good. I've also added this to the 1.1.0 release in JIRA. > >> This brings us to 56 total issues, with 17 remaining to complete. > Several > >> of those are in progress and can be closed out as soon as code is > reviewed > >> and merged. > >> > >> > > I've also tacked -694 on this one - it deals with a missing package that > > results in certificate verification failure in Docker. Relative > small/easy > > to resolve. > > > > > And maybe 637?? > > https://issues.apache.org/jira/browse/GUACAMOLE-637 Definitely. Outside of the above, it looks like scope is generally settled. I'll move forward with the creation of 1.1.0 branches, etc.: http://guacamole.apache.org/release-procedures-part1/ - Mike
Re: Unable to save PDF and RTF file in Redirected Drive
On Tue, Feb 5, 2019 at 9:50 AM Amarjeet Singh wrote: > ... > While trying to download pdf and rtf files in the local operating system [ > Windows 10 ], I am getting the below error :- > > Report Builder *REP-0081* error during file i/o operation scaba 16 > > > ... It is only writing *10 bytes* and corrupted pdf file is downloaded. > If you are attempting to save the file directly into the "Download" folder, it is likely that the application is repeatedly closing and reopening the file over the course of saving things. As Guacamole will automatically delete the file and begin downloading once the file is closed, an application which behaves in this way will not work correctly. You will need to save the file elsewhere and then move it to the "Download" folder. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Fri, Feb 1, 2019 at 5:42 PM Nick Couchman wrote: > > On Tue, Jan 22, 2019 at 7:57 PM Nick Couchman wrote: > > > > >> I think the new versioning scheme still seems sensible, but following > >> 1.1.0 > >> I suggest we consider whether we should adopt a branching scheme like you > >> mentioned before. It would be nice to rely on being able to always produce > >> bugfix/minor releases without breaking compatibility. > > > > > > Agreed, and, until we do handle the branching scheme, we need to be > > looking really close at any commits we make to insure that we're not > > Introducing changes that will impact compatibility, or, if we do, that > > we're introducing the necessary changes to keep things > > backward-compatible. Just something for all committers to be aware of at > > this point. > > > > > >> > >> Our issues with producing a release following 1.0.0 are more with the > >> current existence of an incompatible change on master (and the upgrade > >> headache that implies for any users affected by bugs in 1.0.0), not with > >> the numbering. > > > > > > Sounds good. > > > > -Nick > > > > So, I think we've probably had enough time to at least catch the biggest > bugs in 1.0.0 and get those into JIRA, and I think many of those have been > squashed. Are we good fixing 1.1.0 release at the following list of issues: > > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12343049 > > And moving forward with the release? By this list we have 17 issues > needing to be finished up prior to cutting the release. There are several > PRs waiting for reviews to be finished up - any of the committers who can > jump on and do reviews, your help would be greatly appreciated! > +1 > Any others that we think should get added to the next version? > I'd suggest also including: https://issues.apache.org/jira/browse/GUACAMOLE-696 - "Apply database groups if authenticated user matches database user" and: https://issues.apache.org/jira/browse/GUACAMOLE-715 - "Permission management based on LDAP groups not working as documented" Both of which are issues encountered with the new user group support following release of 1.0.0. The former is a point of confusion which has resulted in a few threads on the mailing list, while the latter is a legitimate bug in the way delegated authentication is handled by the database auth (it still assumes there will be a corresponding database user). I'd also say let's add the FreeRDP 2.0.0 support to the scope, and try to buckle down and get it done. It's becoming increasingly critical, particularly for downstream Linux distributions that wish to drop support for older FreeRDP releases. I think I should be able to manage it within February: https://issues.apache.org/jira/browse/GUACAMOLE-249 - Mike
Re: Copy/Paste from remote to local machine using API
On Sun, Jan 27, 2019 at 5:59 AM Jaymin Patel wrote: > > Hi Team, > > I am using Guacamole to access RDP machine using API.I tried following API > but I could not do copy from remote machine to local machine. > > http://guacamole.apache.org/doc/guacamole-common-js/Guacamole.Client.html#createClipboardStream > > http://guacamole.apache.org/doc/guacamole-common-js/Guacamole.Client.html#event:onclipboard > What specifically have you tried? - Mike
[SECURITY] CVE-2018-1340: Secure flag missing from Apache Guacamole session cookie
CVE-2018-1340: Secure flag missing from Apache Guacamole session cookie Versions affected: Apache Guacamole 0.9.4 through 0.9.14 Description: Prior to 1.0.0, Apache Guacamole used a cookie for client-side storage of the user's session token. This cookie lacked the "secure" flag, which could allow an attacker eavesdropping on the network to intercept the user's session token if unencrypted HTTP requests are made to the same domain. Mitigation: Users of Apache Guacamole 0.9.14 or older should upgrade to 1.0.0. Credit: We would like to thank Ross Golder for reporting this issue.
Re: Build failed in Jenkins: guacamole-client-docker #28
On Tue, Jan 22, 2019 at 5:57 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See < > https://builds.apache.org/job/guacamole-client-docker/28/display/redirect?page=changes > > > > Changes: > > [jbest] GUACAMOLE-704: Add ldap-follow-referrals setting for Docker > containers > > [jbest] GUACAMOLE-704: Add ldap-follow-referrals setting for Docker > containers > ...curl: (7) Failed to connect to jdbc.postgresql.org port 443: > Connection timed out > It looks like jdbc.postgresql.org is having issues. The website appears up, but is responding very slowly. This is apparently long enough to cause curl to timeout within the Docker image build (while the build is downloading the JDBC driver to be bundled within the image). - Mike
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 4:19 PM Nick Couchman wrote: > On Tue, Jan 22, 2019 at 19:10 Mike Jumper wrote: > > > On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman wrote: > > > > > Very cool. Was 524 the only change that would push us to a major > version > > > (2.0.0)? I can't remember off the top of my head if anything else > > > introduced API-relevant changes. > > > > > > > Yep. Other than the changes to Connectable, no other changes break > > extension compatibility with 1.0.0. > > > Very nice. So shall we try for a 1.1.0 release, next (soon)? Maybe squash > a few more bugs that have surfaced from 1.0.0? > Sounds good to me. > And do we want to continue this versioning scheme, or continue to toss > around some of the other ideas we've talked about? > I think the new versioning scheme still seems sensible, but following 1.1.0 I suggest we consider whether we should adopt a branching scheme like you mentioned before. It would be nice to rely on being able to always produce bugfix/minor releases without breaking compatibility. Our issues with producing a release following 1.0.0 are more with the current existence of an incompatible change on master (and the upgrade headache that implies for any users affected by bugs in 1.0.0), not with the numbering. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman wrote: > Very cool. Was 524 the only change that would push us to a major version > (2.0.0)? I can't remember off the top of my head if anything else > introduced API-relevant changes. > Yep. Other than the changes to Connectable, no other changes break extension compatibility with 1.0.0. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Mon, Jan 21, 2019 at 5:29 PM Mike Jumper wrote: > On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper wrote: > >> On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: >> >>> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: >>> ... >>> > >>> > A compat layer would be pretty tricky. >>> > >>> > If we can somehow modify the API changes such that things are >>> inherently >>> > compatible, then fairly easy. Maybe something can be done with default >>> > methods now that we're Java 8+? >>> > >>> >>> So, for a change like this (to the Connectable interface): >>> >>> https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea >>> >>> something like this: >>> >>> https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae >>> >>> ?? >>> >>> >> Something similar to that, yes. We would need default implementations for >> both old and new versions of connect(): >> >> >> https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 >> >> We would still run into trouble with the SimpleConnection class for any >> downstream uses which override the old connect(). Those overrides would >> suddenly cease to have any effect. Further, if such a downstream use also >> uses SimpleAuthenticationProvider, they might expect the provided >> GuacamoleConfiguration to already have tokens applied (the old behavior) >> rather than dynamically applied upon connect() (the new behavior). >> >> Maybe it's not possible without a compatibility layer... >> > > I think we can allow the old connect() to be overridden and still work as > intended by leveraging thread-local storage. We could use a thread-local > variable to effectively pass the tokens received by the new connect() such > that they are available internally by SimpleConnection's implementation of > the old connect(). With the new version internally leveraging the old, > users which override either will see the behavior they expect. > > The GuacamoleConfiguration returned by getConfiguration() would still no > longer have tokens applied, unlike past releases where tokens were baked in > before each instance of SimpleConnection was created, but perhaps that's a > reasonable enough sacrifice? > For example: https://github.com/mike-jumper/guacamole-client/commit/7e67dde75155ab88af4570bcfeb3a94175093fc9
Re: [DISCUSS] Beyond 1.0.0
On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper wrote: > On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: > >> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: >> ... >> > >> > A compat layer would be pretty tricky. >> > >> > If we can somehow modify the API changes such that things are inherently >> > compatible, then fairly easy. Maybe something can be done with default >> > methods now that we're Java 8+? >> > >> >> So, for a change like this (to the Connectable interface): >> >> https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea >> >> something like this: >> >> https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae >> >> ?? >> >> > Something similar to that, yes. We would need default implementations for > both old and new versions of connect(): > > > https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 > > We would still run into trouble with the SimpleConnection class for any > downstream uses which override the old connect(). Those overrides would > suddenly cease to have any effect. Further, if such a downstream use also > uses SimpleAuthenticationProvider, they might expect the provided > GuacamoleConfiguration to already have tokens applied (the old behavior) > rather than dynamically applied upon connect() (the new behavior). > > Maybe it's not possible without a compatibility layer... > I think we can allow the old connect() to be overridden and still work as intended by leveraging thread-local storage. We could use a thread-local variable to effectively pass the tokens received by the new connect() such that they are available internally by SimpleConnection's implementation of the old connect(). With the new version internally leveraging the old, users which override either will see the behavior they expect. The GuacamoleConfiguration returned by getConfiguration() would still no longer have tokens applied, unlike past releases where tokens were baked in before each instance of SimpleConnection was created, but perhaps that's a reasonable enough sacrifice? - Mike
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: > On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: > > > On Thu, Jan 17, 2019, 13:02 Nick Couchman > > > > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper > wrote: > > > > > > > > > > > Another option might be to provide some sort of API compatibility > layer > > > > within the webapp, allowing the extensions of prior releases to > > continue > > > to > > > > function. If compatibility doesn't break as a result of API changes, > > > > there's no need for a full major version bump, and downstream > migration > > > for > > > > future releases is much easier. > > > > > > > > > > > I'm open to this, as well. How much effort do we think would be > involved > > > in introducing something like this? > > > > > > > A compat layer would be pretty tricky. > > > > If we can somehow modify the API changes such that things are inherently > > compatible, then fairly easy. Maybe something can be done with default > > methods now that we're Java 8+? > > > > So, for a change like this (to the Connectable interface): > > https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea > > something like this: > > https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae > > ?? > > Something similar to that, yes. We would need default implementations for both old and new versions of connect(): https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 We would still run into trouble with the SimpleConnection class for any downstream uses which override the old connect(). Those overrides would suddenly cease to have any effect. Further, if such a downstream use also uses SimpleAuthenticationProvider, they might expect the provided GuacamoleConfiguration to already have tokens applied (the old behavior) rather than dynamically applied upon connect() (the new behavior). Maybe it's not possible without a compatibility layer... > On another note, I have started looking at the changes required to support > FreeRDP 2.0. I know you asked for help on this a while back, with no > takers. It might take me 10x as long as someone else to figure it out, but > it's clear from some recent traffic on the list that it's going to be > pretty important that we support FreeRDP 2.0 going forward. So, time to > tackle it :-). Unfortunately just an hour or so into it and I already want > to run my head through a brick wall. Speaking of API compatibility, these > changes are not insignificant... Yeah, that's pretty typical in my experience of FreeRDP API changes. I did some work recently trying to abstract away the VNC support from the underlying library, and I think we can do the same with the RDP - allowing FreeRDP 1.x and 2.x to be alternative backends fo the same support. It's not the easiest thing ever, but it wasn't too horrible. I'll give it a shot. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Thu, Jan 17, 2019, 13:02 Nick Couchman On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper wrote: > > > On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman wrote: > > > > > On Fri, Jan 11, 2019 at 8:11 AM carl harris > > wrote: > > > ... > > > > > > > > Many products have skirted this question by dropping the semantic > > > > versioning in favor of some sort of version scheme based on a > > time-boxed > > > > release cycle. Would something like that be more appropriate here? > What > > > > would that mean with respect to versioning for the API that Guacamole > > > > exposes for extensions and such? > > > > > > > > > > I'm not opposed to such a versioning scheme. My only question would be > > how > > > to deal with the API-level changes that you mentioned before, and that > > > we've currently identified for the "major release" changes? Is there a > > way > > > that these sort of time-boxed releases handle that in the versioning? > > > > > > > Another option might be to provide some sort of API compatibility layer > > within the webapp, allowing the extensions of prior releases to continue > to > > function. If compatibility doesn't break as a result of API changes, > > there's no need for a full major version bump, and downstream migration > for > > future releases is much easier. > > > > > I'm open to this, as well. How much effort do we think would be involved > in introducing something like this? > A compat layer would be pretty tricky. If we can somehow modify the API changes such that things are inherently compatible, then fairly easy. Maybe something can be done with default methods now that we're Java 8+? > I guess, whatever methodology we choose for this going forward, I'm > interested in maintaining the momentum of the really cool 1.0.0 release we > just put out - I think we'll be able to increase community involvement and > interest by maintaining and more frequent release cycle, which I believe > the new version numbering is supposed to facilitate. It'd be nice to > identify a sustainable way to develop and version going forward, and turn > around another release (2.0.0, 1.0.1, 1.0-201902, etc.) quickly. > +1 > Sorry if I'm coming across as push, but I'm very interested in carrying the > energy and momentum forward :-). > I definitely agree. There's been a remarkable uptick in community involvement following 1.0.0 which we should work to encourage. - Mike
Re: [DISCUSS] Migration of git repositories to gitbox (Was: Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org)
So far, so good. We can merge with the merge button! Beware that GitHub now apparently provides two fields for the merge commit message. This threw me at first (isn't there only one message for a commit?) but it's really all for the same message. The first field is the first line, while the second, multi-line field is for an optional extended description to be included after a blank line in the same message. There seems to be some issues with the way emails, etc. work: 1) Once merged, the email from GitBox alerting to the merge introduces/complains about GitHub behavior twice. Based on how it's worded, it looks like this was two attempts to say the same thing, only one of which was meant to be kept: "[absolute ton of blank lines] This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): [the diff]" 2) GitBox automatically comments on the associated JIRA issue with an incorrect / partly useless comment saying that the committer that merged the PR commented on the PR: "mike-jumper commented on pull request #351: GUACAMOLE-683: Add OpenID support in Docker Build Scripts URL: https://github.com/apache/guacamole-client/pull/351 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org" (see https://issues.apache.org/jira/browse/GUACAMOLE-683?focusedCommentId=16741527=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16741527 ) It'd be nice if GitHub integration for JIRA were installed rather than having a bot comment on issues. The GitHub integration maintains a nice, unobtrusive list of relevant commits and the status of associated pull requests. I'm not sure why it's necessary to have an in-house bot comment and create links when a polished integration for JIRA already exists. 3) No emails containing the actual commits are sent out to commits@. There is an email regarding the pull request closure that goes to commits@ and others for the various commits, but those only the diff statistics and commit message, not the diff/commit itself. There is one message that does contain the entire diff (the one mentioned in #1 above), but it goes to dev@ and contains the entire diff. Whatever happened to the old functionality where there was one email per commit sent to commits@? Doesn't git provide its own commit to email mapping out-of-the-box? I'd think that there would be email-formatted diffs for the new commits sent to commits@, and a simple message (no diff) noting the fact that PR was merged sent to dev@. - Mike On Sun, Jan 13, 2019 at 1:22 AM Jean-Baptiste Onofré wrote: > Done, the repositories are now on gitbox. > > You just have to update the git remote. > > Regards > JB > > On 12/01/2019 21:11, Nick Couchman wrote: > > On Fri, Jan 11, 2019 at 1:44 AM Mike Jumper wrote: > > > >> On Thu, Jan 10, 2019, 22:29 Jean-Baptiste Onofré wrote: > >> > >>> Hi, > >>> > >>> No problem to do it now. It's very fast (let's 5 minutes) and smooth ;) > >>> > >>> Do you want me to create a Jira for INFRA ? > >>> > >> > >> Sure! Thanks, JB. > >> > >> - Mike > >> > > > > Thanks for doing this, JB. Any word on the timeline for it (maybe it's > > already done)? > > > > -Nick > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
[GitHub] guacamole-client pull request #356: GUACAMOLE-699: Add helper script for ver...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-client/pull/356 GUACAMOLE-699: Add helper script for verifying translations. This change adds a utility script, `guacamole/util/check-translation.py`, which performs automated comparisons between the JSON files that define Guacamole's translated strings. By default, strings which are present in English but absent in the translation will be listed (these will need to be added), as well as strings which are present in the translation but not in English (these are likely incorrect and should be removed). These checks can be disabled with command line options, if desired. An additional duplicate string check can be enabled to test whether strings were incorrectly copied verbatim from English without being translated at all. This check includes some obvious exclusions (empty strings, simple numbers, protocol names, "Apache Guacamole"), but will likely produce false positives. It is disabled by default unless requested on the command line. Usage - ``` usage: check-translation.py [-h] [--no-missing] [--no-unused] [--check-copied] [ORIGINAL] TRANSLATED Compares two JSON translation files, as used by the Apache Guacamole web application, listing the strings which appear to be missing or incorrect. positional arguments: ORIGINALThe JSON file which should be used as the basis for comparison. This should be JSON which can be expected to contain every string used by the web application and no others. Typically, this will be the primary, original language of the web application. In the case of Apache Guacamole, this should be English. If omitted, the file "en.json" within the same directory as TRANSLATED will be used by default. TRANSLATED The JSON file which should be compared against ORIGINAL. This should be the JSON which has been translated from ORIGINAL, and thus should contain the same set of strings if the translation is complete. optional arguments: -h, --help show this help message and exit --no-missingDisables checking for strings which are present in ORIGINAL but are missing from TRANSLATED. Assuming ORIGINAL represents the set of strings actually used by the web application, these strings are those which are missing and need to be defined for the translation to be complete. By default, the comparison will check for missing translations. --no-unused Disables checking for strings which are present in TRANSLATED but not in ORIGINAL. Assuming ORIGINAL represents the set of strings actually used by the web application, these strings are those which are defined by the translation but unused. By default, the comparison will check for unused translations. --check-copied Enables checking for strings defined in TRANSLATED which are identical to the corresponding strings in ORIGINAL. Such strings may have been incorrectly copied verbatim from the original without being translated at all. It is also possible that both languages simply use the same text for that string, and the string is correct. As this test can produce false positives, it is disabled by default. ``` Example output - ``` [mjumper@dev-mjumper guacamole]$ ./util/check-translation.py --check-copied src/main/webapp/translations/de.json Original language: en (English) Translation language: de (Deutsch) The following strings are missing from the translation and should be added: APP.ACTION_DOWNLOAD APP.ACTION_MANAGE_USER_GROUPS APP.ACTION_SHARE APP.ERROR_PAGE_UNAVAILABLE APP.TEXT_ANONYMOUS_USER CLIENT.ACTION_SHARE CLIENT.ERROR_CLIENT_207 CLIENT.ERROR_CLIENT_208 CLIENT.ERROR_CLIENT_209 CLIENT.ERROR_CLIENT_20A CLIENT.ERROR_CLIENT_20B CLIENT.ERROR_TUNNEL_207 CLIENT.ERROR_TUNNEL_208 CLIENT.HELP_SHARE_LINK CLIENT.INFO_CONNECTION_SHARED CLIENT.TEXT_CLIENT_STATUS_UNSTABLE LIST.TEXT_ANONYMOUS_USER MANAGE_CONNECTION.TABLE_HEADER_HISTORY_REMOTEHOST MANAGE_CONNECTION_GROUP.ACTION_CLONE MANAGE_SHARING_PROFILE.DIALOG_HEADER_CONFIRM_DELETE MANAGE_SHARING_PROFILE.FIELD_HEADE
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman wrote: > On Fri, Jan 11, 2019 at 8:11 AM carl harris wrote: > ... > > > > Many products have skirted this question by dropping the semantic > > versioning in favor of some sort of version scheme based on a time-boxed > > release cycle. Would something like that be more appropriate here? What > > would that mean with respect to versioning for the API that Guacamole > > exposes for extensions and such? > > > > I'm not opposed to such a versioning scheme. My only question would be how > to deal with the API-level changes that you mentioned before, and that > we've currently identified for the "major release" changes? Is there a way > that these sort of time-boxed releases handle that in the versioning? > Another option might be to provide some sort of API compatibility layer within the webapp, allowing the extensions of prior releases to continue to function. If compatibility doesn't break as a result of API changes, there's no need for a full major version bump, and downstream migration for future releases is much easier. - Mike
[GitHub] guacamole-client pull request #351: GUACAMOLE-683: Add OpenID support in Doc...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/351#discussion_r247040348
--- Diff: guacamole-docker/bin/start.sh ---
@@ -404,6 +404,42 @@ END
ln -s /opt/guacamole/radius/guacamole-auth-*.jar "$GUACAMOLE_EXT"
}
+## Adds properties to guacamole.properties which select the OPENID
+## authentication provider, and configure it to connect to the specified
OPENID
+## provider.
+##
+associate_openid() {
+
+# Verify required parameters are present
+if [ -z "$OPENID_AUTHORIZATION_ENDPOINT" ] || \
+ [ -z "$OPENID_JWKS_ENDPOINT" ] || \
+ [ -z "$OPENID_ISSUER" ] || \
+ [ -z "$OPENID_CLIENT_ID" ] || \
+ [ -z "$OPENID_REDIRECT_URI" ]
+then
+cat <https://github.com/apache/guacamole-client/blob/78f1ae1b4eac25501d532ddee94fd1d8588e56dc/guacamole-docker/bin/start.sh#L131-L143
---
Re: [DISCUSS] Migration of git repositories to gitbox (Was: Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org)
On Thu, Jan 10, 2019, 22:29 Jean-Baptiste Onofré Hi, > > No problem to do it now. It's very fast (let's 5 minutes) and smooth ;) > > Do you want me to create a Jira for INFRA ? > Sure! Thanks, JB. - Mike
[GitHub] guacamole-website pull request #67: Archive releases older than 1.0.0.
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-website/pull/67 Archive releases older than 1.0.0. These changes archive the releases which are older than 1.0.0 (link to them only via archive.apache.org). The release layout has also been modified to add a message at the top of the release notes pointing users at the latest release if they are currently looking at the release notes of an archived release. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-website archive-releases Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-website/pull/67.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #67 commit 5d04c3e3ff09fc215e0f06380eeb99e1dc8f4708 Author: Michael Jumper Date: 2017-02-16T22:43:50Z Note when a release is archived. Link to latest release in older release notes. commit c7ef9422fbad701ce6998bd02defd21503779310 Author: Michael Jumper Date: 2019-01-10T06:07:46Z Link to archive.apache.org for 0.9.13-incubating and 0.9.14 releases. commit e86e41eb6bece825fb5f1761eec20796676c30b5 Author: Michael Jumper Date: 2019-01-10T06:08:35Z Mark all archived releases as such. ---
[DISCUSS] Migration of git repositories to gitbox (Was: Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org)
Greetings all, All projects under the ASF using git are eventually being migrated to gitbox. Now that 1.0.0 is out of the way, there seems little reason/benefit to put this off. It will happen automatically on February 7th, but we can opt in to doing this sooner. Thoughts on opting in to an earlier migration? Seems way better to me than being "mass migrated without warning" come 2019-02-07... If there's general consensus, I'll create a ticket with Infra pointing at this thread and things will move forward. See details below. Thanks, - Mike On Thu, Jan 3, 2019 at 5:19 AM Apache Infrastructure Team < infrastruct...@apache.org> wrote: > Hello, guacamole folks. > As stated earlier in 2018, all git repositories must be migrated from > the git-wip-us.apache.org URL to gitbox.apache.org, as the old service > is being decommissioned. Your project is receiving this email because > you still have repositories on git-wip-us that needs to be migrated. > > The following repositories on git-wip-us belong to your project: > - guacamole-manual.git > - guacamole-website.git > - guacamole-server.git > - guacamole-client.git > > > We are now entering the mandated (coordinated) move stage of the roadmap, > and you are asked to please coordinate migration with the Apache > Infrastructure Team before February 7th. All repositories not migrated > on February 7th will be mass migrated without warning, and we'd appreciate > it if we could work together to avoid a big mess that day :-). > > Moving to gitbox means you will get full write access on GitHub as well, > and be able to close/merge pull requests and much more. > > To have your repositories moved, please follow these steps: > > - Ensure consensus on the move (a link to a lists.apache.org thread will > suffice for us as evidence). > - Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA > > Your migration should only take a few minutes. If you wish to migrate > at a specific time of day or date, please do let us know in the ticket. > > As always, we appreciate your understanding and patience as we move > things around and work to provide better services and features for > the Apache Family. > > Should you wish to contact us with feedback or questions, please do so > at: us...@infra.apache.org. > > > With regards, > Apache Infrastructure > >
[ANNOUNCE] Apache Guacamole 1.0.0
The Apache Guacamole community is proud to announce the release of Apache Guacamole 1.0.0. Apache Guacamole is a clientless remote desktop gateway which supports standard protocols like VNC, RDP, and SSH. We call it "clientless" because no plugins or client software are required; once Guacamole is installed on a server, all you need to access your desktops is a web browser. The 1.0.0 release features support for user groups, improved clipboard integration leveraging the Asynchronous Clipboard API, as well as support for TOTP (Google Authenticator), RADIUS, and dead keys. A full list of the changes in this release, along with links to downloads and updated documentation, can be found in the release notes: http://guacamole.apache.org/releases/1.0.0/ For more information on Apache Guacamole, please see: http://guacamole.apache.org/ Thanks! The Apache Guacamole Community
[GitHub] guacamole-website pull request #66: GUACAMOLE-692: Update artifact checksums...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-website/pull/66 GUACAMOLE-692: Update artifact checksums to comply with latest ASF release policy. This change updates the release layout such that the specific checksums provided and the extensions used by those checksums can be specified on a per-release basis. The ASF release policy changed last year to require (1) no MD5 and (2) a `.sha256` extension for SHA-256 (not the old `.sha`). These changes allow us to comply, and update the 1.0.0 release notes to do so. Note that past releases are migrated to the new layout but not updated with respect to the new checksums. That's OK - we'll be archiving the older releases following 1.0.0. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-website checksum-policy Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-website/pull/66.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #66 commit 229be79274d418feabaf35dc36d1240215845212 Author: Michael Jumper Date: 2019-01-09T17:44:37Z GUACAMOLE-692: Define the specific checksums included with each release. commit a79b91a7ed33d3ce9f56482493f3a0cdfd330ec2 Author: Michael Jumper Date: 2019-01-10T03:15:17Z GUACAMOLE-692: Update 1.0.0 release downloads to comply with latest ASF policy for checksums. ---
The new issues@ list (JIRA notifications) is now available
Notifications from JIRA previously were sent to the comm...@guacamole.apache.org list. The commits@ list is now dedicated to commits only (as it should be), with the new iss...@guacamole.apache.org list dedicated to JIRA notifications. To subscribe to the new list, send an email to: issues-subscr...@guacamole.apache.org - Mike
[GitHub] guacamole-website pull request #65: Release 1.0.0.
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-website/pull/65 Release 1.0.0. This change marks 1.0.0 as released, and updates the top-level symbolic links to the latest documentation. We'll still need to hold off on actually *deploying* these changes until 2019-01-09 19:52:02 -0800, as that will be 24 hours since the release artifacts were deployed (and the mirrors need roughly 24 hours to sync). From http://www.apache.org/dev/release.html#release-announcements: > Please ensure that you wait at least 24 hours after uploading a new release before updating the project download page and sending the announcement email(s). This is so that mirrors have sufficient time to catch up. (For time-critical security releases, the download pages script supports bypassing this requirement.) Also, from http://www.apache.org/dev/release-publishing.html#sync-delay: > Apache uses svnpubsub internally and rsync mirrroring externally. Files committed to the Subversion repository at https://dist.apache.org/repos/dist/ are automatically copied, using svnpubsub, to www.apache.org , and then the external mirrors pick up the files from www.apache.org. It may take up to 24 hours or more for a newly published release to be sync'd to all mirrors. Mirrors have their own schedules. [Mirrors are required](http://www.apache.org/info/how-to-mirror.html#Requirements) to check at least once a day, but most will check for updates 2 to 4 times per day. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-website release-1.0.0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-website/pull/65.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #65 commit 3f8f3ca914ff1efed5ae76d3a97685fc6333a8ae Author: Michael Jumper Date: 2019-01-09T04:45:01Z Mark 1.0.0 as released. commit 1379d00dc6194c4812d2a5da197b6623a7e99d51 Author: Michael Jumper Date: 2019-01-09T04:46:10Z Update top-level symbolic links to point to 1.0.0 documentation. ---
[RESULT] [VOTE] Release Apache Guacamole 1.0.0 (RC1)
On Fri, Jan 4, 2019 at 10:02 PM Mike Jumper wrote: > Hello all, > > The first release candidate for Apache Guacamole 1.0.0 has been uploaded > and is ready for VOTE. The draft release notes (along with links to > artifacts, signatures/checksums, and updated documentation) can be found > here: > > http://guacamole.apache.org/releases/1.0.0/ > > The git tag for all relevant repositories is "1.0.0-RC1": > > https://github.com/apache/guacamole-client/tree/1.0.0-RC1 > https://github.com/apache/guacamole-server/tree/1.0.0-RC1 > https://github.com/apache/guacamole-manual/tree/1.0.0-RC1 > > Build instructions are included in the manual, which is part of the > updated documentation referenced above. For convenience: > > http://guacamole.apache.org/doc/1.0.0/gug/installing-guacamole.html > > Maven artifacts for guacamole-common, guacamole-common-js, and > guacamole-ext can be found in the following staging repository: > > https://repository.apache.org/content/repositories/orgapacheguacamole-1009 > > Source and binary distributions (also linked within the release notes): > > https://dist.apache.org/repos/dist/dev/guacamole/1.0.0-RC1/ > > Artifacts have been signed with the "mjum...@apache.org" key listed in: > > https://dist.apache.org/repos/dist/dev/guacamole/KEYS > > Please review and vote: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > The VOTE to release RC1 of Apache Guacamole 1.0.0 is now closed. With a total of +3 binding votes from the PMC, +1 from the community, and NO -1 votes, the VOTE passes. Overall vote breakdown is as follows: +1 Michael Jumper (binding) +1 Nick Couchman (binding) +1 James Muehlner (binding) +1 Fouad Thanks to everyone who voted. I'll move forward with promoting the release candidate to release. - Mike
Re: Build failed in Jenkins: guacamole-server-coverity #57
On Tue, Jan 8, 2019 at 6:32 AM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > ... > [0m [91mcurl: (51) Unable to communicate securely with peer [0m [91m: > requested domain name does [0m [91mnot match the server' [0m [91ms > certificate. [0m [91m > [0m [91m > gzip: stdin: unexpected end of file > [0m [91mtar: Child returned status 1 > tar: Error is not recoverable: exiting now > Coverity Scan is apparently unavailable until they can find new hosting: https://community.synopsys.com/s/article/Coverity-Scan-Update I'll disable the Coverity builds until service resumes. - Mike
Re: [VOTE] Release Apache Guacamole 1.0.0 (RC1)
Thanks, guys! Anyone else have a few moments to look things over? We've accumulated enough +1 votes to move forward with release once the 72 hours is up, but it would be a shame to not have more eyes. This is the largest release we've ever had. - Mike On Mon, Jan 7, 2019, 15:26 James Muehlner Looks good to me. > > +1 > > James > > On Sat, Jan 5, 2019 at 5:40 AM Nick Couchman wrote: > > > On Sat, Jan 5, 2019 at 1:03 AM Mike Jumper wrote: > > > > > Hello all, > > > > > > The first release candidate for Apache Guacamole 1.0.0 has been > uploaded > > > and is ready for VOTE. The draft release notes (along with links to > > > artifacts, signatures/checksums, and updated documentation) can be > found > > > here: > > > > > > http://guacamole.apache.org/releases/1.0.0/ > > > > > > The git tag for all relevant repositories is "1.0.0-RC1": > > > > > > https://github.com/apache/guacamole-client/tree/1.0.0-RC1 > > > https://github.com/apache/guacamole-server/tree/1.0.0-RC1 > > > https://github.com/apache/guacamole-manual/tree/1.0.0-RC1 > > > > > > Build instructions are included in the manual, which is part of the > > updated > > > documentation referenced above. For convenience: > > > > > > http://guacamole.apache.org/doc/1.0.0/gug/installing-guacamole.html > > > > > > Maven artifacts for guacamole-common, guacamole-common-js, and > > > guacamole-ext can be found in the following staging repository: > > > > > > > > > https://repository.apache.org/content/repositories/orgapacheguacamole-1009 > > > > > > Source and binary distributions (also linked within the release notes): > > > > > > https://dist.apache.org/repos/dist/dev/guacamole/1.0.0-RC1/ > > > > > > Artifacts have been signed with the "mjum...@apache.org" key listed > in: > > > > > > https://dist.apache.org/repos/dist/dev/guacamole/KEYS > > > > > > Please review and vote: > > > > > > [ ] +1 Approve the release > > > [ ] -1 Don't approve the release (please provide specific comments) > > > > > > This vote will be open for at least 72 hours. > > > > > > Here is my +1. > > > > > > Thanks, > > > > > > - Mike > > > > > > > +1 from me. > > > > -Nick > > >
Re: [DISCUSS] Creating additional lists for announcements and JIRA
On Mon, Jan 7, 2019 at 4:16 PM Mike Jumper wrote: > On Mon, Jan 7, 2019 at 4:04 PM Nick Couchman wrote: > >> On Mon, Jan 7, 2019 at 17:38 Mike Jumper >> >> > > >> > > I'll also use this opportunity to ping on the topic of resurrecting >> the >> > > Guacamole Twitter account - any further thoughts/discussion on this? >> > > >> > >> > I think the main issue with Twitter is that there can be only one set of >> > credentials. AFAIK, we can't have a project account to which various >> people >> > have permission to post without sharing a username/password. Other than >> > that, I would have nothing against a project Twitter account, though I'm >> > not sure I would find occasion to post to it except at release time. I >> do >> > see other Apache projects with a PMC-wide twitter, so it should be >> > doable... >> > >> > Are you familiar with any way to share a Twitter account without having >> to >> > share credentials? >> > >> >> Admittedly, no, I don't know if a great way to do this. I did stumble >> across this: >> >> https://help.twitter.com/en/using-twitter/tweetdeck-teams >> >> Looks like it may be doable there, and we'd just have to have someone be >> the primary account holder and hold the credentials, and that person could >> grant access to others? > > > Since I'm the one with the credentials to the old account, I can give that > a shot. > > I'll also try to rename from @GuacDev to something like @ApacheGuacamole. > All set: https://twitter.com/ApacheGuacamole Since granting access to tweetdeck requires Twitter accounts, I'll send a separate email on private@ to ask for usernames of any PMC members having accounts. - Mike
Re: [DISCUSS] Creating additional lists for announcements and JIRA
On Mon, Jan 7, 2019 at 4:04 PM Nick Couchman wrote: > On Mon, Jan 7, 2019 at 17:38 Mike Jumper > > > > > > > I'll also use this opportunity to ping on the topic of resurrecting the > > > Guacamole Twitter account - any further thoughts/discussion on this? > > > > > > > I think the main issue with Twitter is that there can be only one set of > > credentials. AFAIK, we can't have a project account to which various > people > > have permission to post without sharing a username/password. Other than > > that, I would have nothing against a project Twitter account, though I'm > > not sure I would find occasion to post to it except at release time. I do > > see other Apache projects with a PMC-wide twitter, so it should be > > doable... > > > > Are you familiar with any way to share a Twitter account without having > to > > share credentials? > > > > Admittedly, no, I don't know if a great way to do this. I did stumble > across this: > > https://help.twitter.com/en/using-twitter/tweetdeck-teams > > Looks like it may be doable there, and we'd just have to have someone be > the primary account holder and hold the credentials, and that person could > grant access to others? Since I'm the one with the credentials to the old account, I can give that a shot. I'll also try to rename from @GuacDev to something like @ApacheGuacamole. - Mike
Re: Sound not working on custom application
On Thu, Dec 13, 2018 at 10:08 AM Hanke, Alex wrote:
> I created my own application following Chapter 23 of the guacamole guide.
> I
> implemented it using the websocket tunnel instead of the http tunnel. I
> am
> using rdp to connect to a windows 10 machine. Everything works fine
> except
> for the sound. To implement my custom application I cloned a VM that had
> a
> standalone instance of guacamole and just replaced the tomcat portion with
> my custom web app so I dont think it should have anything to do with
> guacd.
> I also don't get any error in the logs for guacd. Is there something I
> have
> to do on the javascript side to enable the sound? Or perhaps on the java
> side I have to enable something to make the sound pass through?
>
>
Other than passing the supported mimetypes through via
GuacamoleClientInformation as you've done below, no, there's nothing else
you need to do on the Java or JavaScript side to enable sound.
Are you sure the Windows audio service is running on the RDP machine? Could
there be a group policy set which disables audio?
>
>
> As a proof of concept I added the following lines to my java code that
> creates the connection and sent it along with my request to create the
> ConfiguredGuacamoleSocket. However this still did not produce any sound.
> I
> also tried L16 and adding ,channels=2 but none of those combinations
> produced sound.
>
> GuacamoleClientInformation gci = new GuacamoleClientInformation();
> gci.getAudioMimetypes().add("audio/L8;rate=44100");
>
> I do see this in the logs
>
> Dec 4 06:03:45 irixgw1 guacd[22874]: Accepted format: 16-bit PCM
> with 2 channels at 44100 Hz
>
> Also I am using chrome to test and running the getSupportedTypes yields
> ["audio/L8", "audio/L16"]
>
Anything in the console of Chrome's dev tools?
- Mike
Re: [DISCUSS] Creating additional lists for announcements and JIRA
On Mon, Jan 7, 2019 at 2:38 PM Mike Jumper wrote: > On Mon, Jan 7, 2019 at 2:20 PM Nick Couchman wrote: > >> On Mon, Jan 7, 2019 at 4:33 PM Mike Jumper wrote: >> >> > It occurs to me that it might be beneficial to have a low-traffic >> announce@ >> > list for Guacamole which would receive only things like release >> > announcements or security advisories. >> > >> ... > > > >> > Similarly, JIRA issues and comments currently go to commits@. Perhaps a >> > separate issues@ list would be more appropriate, leaving commits@ for >> > truly >> > only pushed git commits? >> > >> >> This is probably a good idea, too. Concurrently, I'd like to make sure >> I'm >> on both the commits@ and issues@ lists - I'm not 100% certain I get >> either >> JIRA issues or pushed commits at the moment, unless I'm tagged on them >> specifically. >> > > I'll move ahead with creating the lists and see how things go. > > Alrighty - creation of the issues@ list has been queued. Once the list is ready, I'll open a ticket with Infra to update the JIRA project to send all mail there. Since the announce@ list needs special setup (only posts from apache.org addresses should be allowed), I've opened a ticket with Infra for that: https://issues.apache.org/jira/browse/INFRA-17578 - Mike
Re: [DISCUSS] Creating additional lists for announcements and JIRA
On Mon, Jan 7, 2019 at 2:20 PM Nick Couchman wrote: > On Mon, Jan 7, 2019 at 4:33 PM Mike Jumper wrote: > > > It occurs to me that it might be beneficial to have a low-traffic > announce@ > > list for Guacamole which would receive only things like release > > announcements or security advisories. > > > > Sounds good to me. I'm hoping this year will see an increase in number of > release (and, thus, release traffic) with the adoption of the new > versioning scheme :-D. > > I'll also use this opportunity to ping on the topic of resurrecting the > Guacamole Twitter account - any further thoughts/discussion on this? > I think the main issue with Twitter is that there can be only one set of credentials. AFAIK, we can't have a project account to which various people have permission to post without sharing a username/password. Other than that, I would have nothing against a project Twitter account, though I'm not sure I would find occasion to post to it except at release time. I do see other Apache projects with a PMC-wide twitter, so it should be doable... Are you familiar with any way to share a Twitter account without having to share credentials? > > > > Similarly, JIRA issues and comments currently go to commits@. Perhaps a > > separate issues@ list would be more appropriate, leaving commits@ for > > truly > > only pushed git commits? > > > > This is probably a good idea, too. Concurrently, I'd like to make sure I'm > on both the commits@ and issues@ lists - I'm not 100% certain I get either > JIRA issues or pushed commits at the moment, unless I'm tagged on them > specifically. > I'll move ahead with creating the lists and see how things go. We should poke the other members of the PMC (as well as any non-PMC committers) to subscribe if not already subscribed. I can manually check to see who's missing. - Mike
[DISCUSS] Creating additional lists for announcements and JIRA
It occurs to me that it might be beneficial to have a low-traffic announce@ list for Guacamole which would receive only things like release announcements or security advisories. Similarly, JIRA issues and comments currently go to commits@. Perhaps a separate issues@ list would be more appropriate, leaving commits@ for truly only pushed git commits? Thoughts? - Mike
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245799935
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -167,18 +201,34 @@
// Parse name
String name = parameter.substring(0, equals);
String value = parameter.substring(equals+1);
-
-config.setParameter(name, value);
+
+// Pull out and set proxy parameters, if
present
+// Otherwise set the parameter.
+switch(name) {
+case PROXY_HOST_PARAMETER:
--- End diff --
Depending on OID assignment, it looks like we should be fine with the above
system. There is no standard limit imposed on OID length, and longer OIDs are
already actively used.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245791722
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -167,18 +201,34 @@
// Parse name
String name = parameter.substring(0, equals);
String value = parameter.substring(equals+1);
-
-config.setParameter(name, value);
+
+// Pull out and set proxy parameters, if
present
+// Otherwise set the parameter.
+switch(name) {
+case PROXY_HOST_PARAMETER:
--- End diff --
According to
https://cwiki.apache.org/confluence/display/DIRxPMGT/OID+Assignment+Scheme:
> Each contact person is the authority for assigning unique OID values and
ranges to projects or persons. Contact that person for more assignments.
The contact person listed for the main ASF OID is Alex Karasulu. Feels
weird to me to not use a mailing list, but I'll shoot him an email. ;)
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245786503
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -167,18 +201,34 @@
// Parse name
String name = parameter.substring(0, equals);
String value = parameter.substring(equals+1);
-
-config.setParameter(name, value);
+
+// Pull out and set proxy parameters, if
present
+// Otherwise set the parameter.
+switch(name) {
+case PROXY_HOST_PARAMETER:
--- End diff --
Found it!
Quoting the contents here for reference:
> 1.3.6.1.4.1.38971= guac
> .1 = LDAP schema OID's
>.1= attribute types
> .1 = guacConfigProtocol
> .2 = guacConfigParameter
>.2= object classes
> .1 = guacConfigGroup
Using the ASF OID, assuming we end up with "1.3.6.1.4.1.18060.18", we could
redefine things beneath that. Presumably:
1.3.6.1.4.1.18060.18= Apache Guacamole
.1 = LDAP schema
.1= attribute types
.1 = guacConfigProtocol
.2 = guacConfigParameter
.2= object classes
.1 = guacConfigGroup
I'm looking around to see if there is a limit on the number of numeric
groups in an LDAP OID, or at least if there are examples in the wild of LDAP
schemas having OIDs at least as long as those proposed above.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245779470
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -167,18 +201,34 @@
// Parse name
String name = parameter.substring(0, equals);
String value = parameter.substring(equals+1);
-
-config.setParameter(name, value);
+
+// Pull out and set proxy parameters, if
present
+// Otherwise set the parameter.
+switch(name) {
+case PROXY_HOST_PARAMETER:
--- End diff --
We could switch over to the ASF one:
https://cwiki.apache.org/confluence/display/DIRxPMGT/OID+Assignment+Scheme
Probably a good idea to do so. I'll still locate the ancient scrap of paper
to server as a reference for assigning numbers from that, though - we need to
use some consistent method for assigning the numbers within the Guacamole part
of the ASF space (once that exists).
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-client/pull/353#discussion_r245753521 --- Diff: guacamole-ext/src/main/java/org/apache/guacamole/net/auth/Connection.java --- @@ -125,5 +125,17 @@ * connection. */ public Set getSharingProfileIdentifiers() throws GuacamoleException; + +/** + * Get the GuacamoleProxyConfiguration for this connection. --- End diff -- There should be more to the documentation of `X.getFoo()` than "Gets the Foo for this X". There are semantics which apply here that should be noted. ---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245747944
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -148,12 +169,25 @@
// Set protocol
GuacamoleConfiguration config = new
GuacamoleConfiguration();
+
+GuacamoleProxyConfiguration proxyConfig;
+try {
+proxyConfig = new
LocalEnvironment().getDefaultGuacamoleProxyConfiguration();
+}
+catch (GuacamoleException e) {
+return null;
--- End diff --
If retrieval of the proxy config fails, that failure should be logged
rather than silently ignored.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245755153
--- Diff:
guacamole-ext/src/main/java/org/apache/guacamole/net/auth/simple/SimpleConnection.java
---
@@ -68,21 +72,34 @@ public SimpleConnection() {
* @param identifier The identifier to associate with this connection.
* @param config The configuration describing how to connect to this
* connection.
+ *
+ * @throws GuacamoleException
+ * If the default proxy configuration cannot be retrieved.
*/
public SimpleConnection(String name, String identifier,
-GuacamoleConfiguration config) {
+GuacamoleConfiguration config) throws GuacamoleException {
// Set name
-setName(name);
+super.setName(name);
// Set identifier
-setIdentifier(identifier);
+super.setIdentifier(identifier);
// Set config
-setConfiguration(config);
+super.setConfiguration(config);
this.config = config;
+this.proxyConfig = new
LocalEnvironment().getDefaultGuacamoleProxyConfiguration();
}
+
+public SimpleConnection(String name, String identifier,
--- End diff --
Please document this constructor.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245754954
--- Diff:
guacamole-ext/src/main/java/org/apache/guacamole/net/auth/simple/SimpleConnection.java
---
@@ -68,21 +72,34 @@ public SimpleConnection() {
* @param identifier The identifier to associate with this connection.
* @param config The configuration describing how to connect to this
* connection.
+ *
+ * @throws GuacamoleException
+ * If the default proxy configuration cannot be retrieved.
*/
public SimpleConnection(String name, String identifier,
-GuacamoleConfiguration config) {
+GuacamoleConfiguration config) throws GuacamoleException {
--- End diff --
If possible, we should avoid adding new exceptions to an existing
constructor, as downstream users of that constructor will suddenly have new
things to catch.
Perhaps retrieving the configuration from the local environment could still
be put off until `connect()`, being the default behavior if no
`GuacamoleProxyConfiguration` is provided?
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245747651
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -148,12 +169,25 @@
// Set protocol
GuacamoleConfiguration config = new
GuacamoleConfiguration();
+
+GuacamoleProxyConfiguration proxyConfig;
+try {
+proxyConfig = new
LocalEnvironment().getDefaultGuacamoleProxyConfiguration();
--- End diff --
The `LocalEnvironment` should not be repeatedly recreated if it can be
avoided.
A singleton instance of it is actually already bound during startup of the
LDAP extension, so that would be the instance of choice:
https://github.com/apache/guacamole-client/blob/78f1ae1b4eac25501d532ddee94fd1d8588e56dc/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/LDAPAuthenticationProviderModule.java#L74
That singleton instance can be injected within this class if needed, for
example:
https://github.com/apache/guacamole-client/blob/78f1ae1b4eac25501d532ddee94fd1d8588e56dc/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ConfigurationService.java#L41-L45
Since this is configuration, though, I'd think it would make more sense to
provide this via a function within `ConfigurationService`.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/353#discussion_r245744066
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/connection/ConnectionService.java
---
@@ -167,18 +201,34 @@
// Parse name
String name = parameter.substring(0, equals);
String value = parameter.substring(equals+1);
-
-config.setParameter(name, value);
+
+// Pull out and set proxy parameters, if
present
+// Otherwise set the parameter.
+switch(name) {
+case PROXY_HOST_PARAMETER:
--- End diff --
These should probably be separate, dedicated LDAP attributes, rather than
reusing `guacConfigParameter` (which is meant for connection parameters). This
would mean changes to the LDAP schema, which would mean new OID values.
I have the OID number assignment scheme written down on a scrap of paper
from years past ... I'll locate my notes and copy them here. There's an OID
space which was reserved for Guacamole ages ago (see 38971 within
https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers), but
there is a system for consistently assigning numbers within that space.
---
[GitHub] guacamole-client pull request #353: GUACAMOLE-577: Support for configuring t...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-client/pull/353#discussion_r245752774 --- Diff: guacamole-ext/src/main/java/org/apache/guacamole/net/auth/Connection.java --- @@ -125,5 +125,17 @@ * connection. */ public Set getSharingProfileIdentifiers() throws GuacamoleException; + +/** + * Get the GuacamoleProxyConfiguration for this connection. + * + * @return + * The GuacamoleProxyConfiguration for this connection. + * + * @throws GuacamoleException + * If configuration information cannot be retrieved or parsed. + */ +public GuacamoleProxyConfiguration getGuacamoleProxyConfiguration() --- End diff -- We have historically avoided making the assumption that extensions will define a means of connecting to guacd at the `Connection` level. The connection to an underlying Guacamole proxy, whether such a proxy is used at all, etc. is all kept abstract behind the `GuacamoleTunnel` returned by a call to `connect()`. I think it would be better to continue avoiding that assumption. If we will be providing such a getter for convenience (which is OK), there needs to be well-defined semantics allowing implementations to choose not to define it at that level (returning `null` perhaps). ---
[GitHub] guacamole-manual pull request #104: GUACAMOLE-661: Document deprecation of "...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-manual/pull/104 GUACAMOLE-661: Document deprecation of "nest" instruction. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-manual deprecate-nest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-manual/pull/104.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #104 commit 206400f063b7e04e6350fb368fa9506193601b57 Author: Michael Jumper Date: 2019-01-07T17:47:14Z GUACAMOLE-661: Document deprecation of "nest" instruction. ---
[GitHub] guacamole-server pull request #210: GUACAMOLE-661: Mark "nest" instruction a...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-server/pull/210 GUACAMOLE-661: Mark "nest" instruction and socket as deprecated. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-server deprecate-nest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-server/pull/210.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #210 commit d73b86b4b7c41fc7fa16423fc340d644c729b233 Author: Michael Jumper Date: 2019-01-07T17:37:08Z GUACAMOLE-661: Mark "nest" instruction and socket as deprecated. ---
[GitHub] guacamole-server pull request #209: GUACAMOLE-637: Migrate strncpy(), strcat...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-server/pull/209 GUACAMOLE-637: Migrate strncpy(), strcat(), etc. to safer libguac implementations. This change adds platform-independent libguac implementations of the `strlcpy()` and `strlcat()` functions, `guac_strlcpy()` and `guac_strlcat()`, provided via a new `guacamole/string.h` header. These functions will use the versions provided by the platform's libc, if available. Unlike `strncpy()` and `strncat()`, the `strlcpy()` and `strlcat()` variants guarantee that the destination buffer is null-terminated, even if the result had to be truncated: https://www.freebsd.org/cgi/man.cgi?query=strlcpy=3=FreeBSD+6.2-RELEASE This change also adds a similar convenience function, `guac_strljoin()`, which provides an implementation of the familiar "join" operation for strings. Unit tests have been added for each of the new functions. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-server string-functions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-server/pull/209.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #209 commit a379bdecb76a2956e984292d3d7ab6fa734cf0f1 Author: Michael Jumper Date: 2018-10-19T16:30:20Z GUACAMOLE-637: Use proper namespaced path for Guacamole headers within libguac source. commit 563990699bb8a6af68bf65f2c768e51df9d272f1 Author: Michael Jumper Date: 2018-10-19T16:49:23Z GUACAMOLE-637: Add strlcpy() implementation. Use libc strlcpy() if available. commit 4bcab90d0a05024f9b8489b384165ce3759c8489 Author: Michael Jumper Date: 2018-10-19T19:28:04Z GUACAMOLE-637: Add strlcat() implementation. Use libc strlcat() if available. commit f8e9e5017a738aacd852897d087f3e7b99c7adf5 Author: Michael Jumper Date: 2018-10-19T19:28:38Z GUACAMOLE-637: Add convenience function for joining an array of strings using a given delimiter. commit c1c7d096738296e2027be8b6ddfecbff61c2c2ac Author: Michael Jumper Date: 2018-11-12T23:19:33Z GUACAMOLE-637: Replace usages of strncpy() with guac_strlcpy(). commit 3490ffd1d8efbc4fa193b400d4a408ccf55a4c9f Author: Michael Jumper Date: 2018-11-12T23:38:02Z GUACAMOLE-637: Replace usages of strncat() with guac_strlcat(). commit 143e82c32bd2525be8187f316aa969ae9678c5f4 Author: Michael Jumper Date: 2018-11-13T00:10:24Z GUACAMOLE-637: Simplify path translation logic. Update to use guac_strl*(). Fix return values. commit 8353ea3e3f3c5643f1929b9e8c554760cb8298f1 Author: Michael Jumper Date: 2018-11-19T20:37:24Z GUACAMOLE-637: Add unit tests for guac_strlcpy(). commit 78dc18eda2e376714ea8bc3b6d1d21b9c1fc8931 Author: Michael Jumper Date: 2018-11-20T07:16:22Z GUACAMOLE-637: Add unit tests for guac_strlcat(). commit c257b8545ac17e1a4bd296f0f76dfe4d42fbfdf8 Author: Michael Jumper Date: 2019-01-06T23:03:54Z GUACAMOLE-637: Correctly handle string lengths as size_t (unsigned). commit 8732ee0668a2102c4c6fb9a7875892273d9067c0 Author: Michael Jumper Date: 2019-01-06T23:26:45Z GUACAMOLE-637: Add unit tests for guac_strljoin(). ---
Re: Build failed in Jenkins: guacamole-server-master #80
With the handling of unit tests now corrected, this build failure is expected (see: https://github.com/apache/guacamole-server/pull/203 and https://issues.apache.org/jira/browse/GUACAMOLE-662). This should be fixed by: https://github.com/apache/guacamole-server/pull/208 - Mike On Sun, Jan 6, 2019 at 4:47 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See < > https://builds.apache.org/job/guacamole-server-master/80/display/redirect?page=changes > > > > Changes: > > [mjumper] GUACAMOLE-662: Correct fork logic (main test process should be > PARENT, > > [mjumper] GUACAMOLE-662: Add utility script for automatically generating > CUnit > > [mjumper] GUACAMOLE-662: Log test output in TAP format. > > [mjumper] GUACAMOLE-662: Force line-buffered output. > > [mjumper] GUACAMOLE-662: Migrate tests to test runners generated by new > > -- > [...truncated 136.18 KB...] > [0m [91mAdded: en-us-qwerty > [0m [91mAdded: es-es-qwerty > [0m [91mAdded: fr-fr-azerty > [0m [91mAdded: fr-ch-qwertz > [0m [91mAdded: it-it-qwerty > [0m [91mAdded: ja-jp-qwerty > [0m [91mAdded: pt-br-qwerty > [0m [91mAdded: sv-se-qwerty > [0m [91mAdded: tr-tr-qwerty > [0mmake all-am > make[3]: Entering directory `/build/guacamole-server/src/protocols/rdp' > CC guacai_la-audio_input.lo > CC guac_ai/guacai_la-ai_messages.lo > CC guac_ai/guacai_la-ai_service.lo > CC guacai_la-ptr_string.lo > CC compat/guacai_la-winpr-stream.lo > CCLD guacai.la > CC guac_rdpdr/guacdr_la-rdpdr_fs_messages.lo > CC guac_rdpdr/guacdr_la-rdpdr_fs_messages_dir_info.lo > CC guac_rdpdr/guacdr_la-rdpdr_fs_messages_file_info.lo > CC guac_rdpdr/guacdr_la-rdpdr_fs_messages_vol_info.lo > CC guac_rdpdr/guacdr_la-rdpdr_fs_service.lo > CC guac_rdpdr/guacdr_la-rdpdr_messages.lo > CC guac_rdpdr/guacdr_la-rdpdr_printer.lo > CC guac_rdpdr/guacdr_la-rdpdr_service.lo > CC guacdr_la-rdp_fs.lo > CC guacdr_la-rdp_print_job.lo > CC guacdr_la-rdp_stream.lo > CC guacdr_la-unicode.lo > CC compat/guacdr_la-winpr-stream.lo > CCLD guacdr.la > CC guac_rdpsnd/guacsnd_la-rdpsnd_messages.lo > CC guac_rdpsnd/guacsnd_la-rdpsnd_service.lo > CC compat/guacsnd_la-winpr-stream.lo > CCLD guacsnd.la > CC guac_svc/guacsvc_la-svc_service.lo > CC guacsvc_la-rdp_svc.lo > CC compat/guacsvc_la-winpr-stream.lo > CCLD guacsvc.la > CC libguac_client_rdp_la-audio_input.lo > CC libguac_client_rdp_la-client.lo > CC libguac_client_rdp_la-decompose.lo > CC libguac_client_rdp_la-dvc.lo > CC libguac_client_rdp_la-error.lo > CC libguac_client_rdp_la-input.lo > CC libguac_client_rdp_la-keyboard.lo > CC libguac_client_rdp_la-ptr_string.lo > CC libguac_client_rdp_la-rdp.lo > CC libguac_client_rdp_la-rdp_bitmap.lo > CC libguac_client_rdp_la-rdp_cliprdr.lo > CC libguac_client_rdp_la-rdp_color.lo > CC libguac_client_rdp_la-rdp_disp.lo > CC libguac_client_rdp_la-rdp_fs.lo > CC libguac_client_rdp_la-rdp_gdi.lo > CC libguac_client_rdp_la-rdp_glyph.lo > CC libguac_client_rdp_la-rdp_keymap.lo > CC libguac_client_rdp_la-rdp_print_job.lo > CC libguac_client_rdp_la-rdp_pointer.lo > CC libguac_client_rdp_la-rdp_rail.lo > CC libguac_client_rdp_la-rdp_settings.lo > CC libguac_client_rdp_la-rdp_stream.lo > CC libguac_client_rdp_la-rdp_svc.lo > CC libguac_client_rdp_la-resolution.lo > CC libguac_client_rdp_la-unicode.lo > CC libguac_client_rdp_la-user.lo > CC compat/libguac_client_rdp_la-winpr-stream.lo > CC libguac_client_rdp_la-sftp.lo > CC libguac_client_rdp_la-_generated_keymaps.lo > CCLD libguac-client-rdp.la > make[3]: Leaving directory `/build/guacamole-server/src/protocols/rdp' > make[2]: Leaving directory `/build/guacamole-server/src/protocols/rdp' > Making all in src/protocols/ssh > make[2]: Entering directory `/build/guacamole-server/src/protocols/ssh' > CC libguac_client_ssh_la-argv.lo > CC libguac_client_ssh_la-client.lo > CC libguac_client_ssh_la-clipboard.lo > CC libguac_client_ssh_la-input.lo > CC libguac_client_ssh_la-pipe.lo > CC libguac_client_ssh_la-settings.lo > CC libguac_client_ssh_la-sftp.lo > CC libguac_client_ssh_la-ssh.lo > CC libguac_client_ssh_la-ttymode.lo > CC libguac_client_ssh_la-user.lo > CCLD libguac-client-ssh.la > make[2]: Leaving directory `/build/guacamole-server/src/protocols/ssh' > Making all in src/protocols/telnet > make[2]: Entering directory `/build/guacamole-server/src/protocols/telnet' > CC libguac_client_telnet_la-argv.lo > CC libguac_client_telnet_la-client.lo > CC
[GitHub] guacamole-server pull request #208: GUACAMOLE-662: Correct behavior of neste...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-server/pull/208 GUACAMOLE-662: Correct behavior of nested socket. The nested `guac_socket` implementation has apparently been broken for some time. Besides the index not being properly initialized, the data written to the socket is (incorrectly) immediately flushed as a "nest" instruction. This behavior has resulted in the nested socket unit test failing. These changes correct the above, properly initializing the socket index and properly buffering UTF-8 data for eventual flushing as "nest" instructions. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-server fix-nest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-server/pull/208.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #208 commit 47ad6f4b59dc861ae8f17e41885c7f2947ff2bad Author: Michael Jumper Date: 2019-01-06T23:43:55Z GUACAMOLE-662: Properly initialize nested socket index (fixes GUACAMOLE-510). commit cc4671d7a168cd7424282f9b4be7b59cc1ee36a2 Author: Michael Jumper Date: 2019-01-07T01:06:45Z GUACAMOLE-662: Correct handling of buffering within nested socket. The nested socket implementation seems to have never been properly updated since guac_socket was changed to rely on implementation-specific buffering. This meant that absolutely every write resulted in a nest instruction being sent to the parent socket. Data should instead be built up within the internal buffer, with each flush writing as much of the internal buffer as possible within a nest instruction, leaving any partial UTF-8 characters at the end of the buffer for later completion with future writes. ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r245522648 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) --- End diff -- That would probably be better (to avoid users trying things like `--with-pthread_stack=8MB`), though this may no longer be necessary based on your latest suggestion to simplify everything. I agree that it doesn't make sense to have a low-level option to tweak the stack size if it's known that the stack size absolutely must be at least 8MB. ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r245522605 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) +],pthread_stack_size=$withval + AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE], [$pthread_stack_size], [pthread stack size (8MB is recommended)]) +) +if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then +AC_MSG_CHECKING([whether default pthread stack is larger than 8MB]) +ac_save_libs="$LIBS" +LIBS="$LIBS -lpthread" --- End diff -- What I mean is the failure of this test (whether `pthread_create()` is defined within libpthread) does not mean `pthread_create()` is not present at all, nor that the test for `pthread_setattr_default_np()` need not be performed. This test is essentially a check for whether libpthread needs to be linked in. If it fails, `pthread_create()`, etc. are still used; POSIX threads are then simply assumed to be part of libc. ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r245522526 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) +],pthread_stack_size=$withval + AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE], [$pthread_stack_size], [pthread stack size (8MB is recommended)]) +) +if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then +AC_MSG_CHECKING([whether default pthread stack is larger than 8MB]) +ac_save_libs="$LIBS" +LIBS="$LIBS -lpthread" +AC_RUN_IFELSE([AC_LANG_SOURCE([[ --- End diff -- > ON THE OTHER HAND -- if you're willing to make it a firm guarantee -- not an option that this size of a stack is alway requested -- perhaps we can simplify this patch quite a bit. Making this a firm guarantee sounds like the best idea, particularly since you've demonstrated things simply don't work unless the stack size is at least 8MB. I'd suggest: 1. If default stack size is less than 8MB, guacd should attempt to set the default stack size to 8MB. 2. If the default stack size cannot be set (either because setting the attribute fails or `pthread_setattr_default_np()` is unavailable, a warning should be logged. > Is this something that would be better discussed on the mailing list? If there are other angles to consider, hopping onto the mailing list is always a good thing. ---
[VOTE] Release Apache Guacamole 1.0.0 (RC1)
Hello all, The first release candidate for Apache Guacamole 1.0.0 has been uploaded and is ready for VOTE. The draft release notes (along with links to artifacts, signatures/checksums, and updated documentation) can be found here: http://guacamole.apache.org/releases/1.0.0/ The git tag for all relevant repositories is "1.0.0-RC1": https://github.com/apache/guacamole-client/tree/1.0.0-RC1 https://github.com/apache/guacamole-server/tree/1.0.0-RC1 https://github.com/apache/guacamole-manual/tree/1.0.0-RC1 Build instructions are included in the manual, which is part of the updated documentation referenced above. For convenience: http://guacamole.apache.org/doc/1.0.0/gug/installing-guacamole.html Maven artifacts for guacamole-common, guacamole-common-js, and guacamole-ext can be found in the following staging repository: https://repository.apache.org/content/repositories/orgapacheguacamole-1009 Source and binary distributions (also linked within the release notes): https://dist.apache.org/repos/dist/dev/guacamole/1.0.0-RC1/ Artifacts have been signed with the "mjum...@apache.org" key listed in: https://dist.apache.org/repos/dist/dev/guacamole/KEYS Please review and vote: [ ] +1 Approve the release [ ] -1 Don't approve the release (please provide specific comments) This vote will be open for at least 72 hours. Here is my +1. Thanks, - Mike
[GitHub] guacamole-website pull request #64: Add draft release notes for first RC of ...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-website/pull/64#discussion_r245442866 --- Diff: _releases/1.0.0.md --- @@ -0,0 +1,805 @@ +--- + +released: false +title: 1.0.0 +date: 2018-12-20 22:00:00 -0800 +summary: > +User groups, improved clipboard integration, TOTP (Google Authenticator), +RADIUS, dead keys. + +artifact-root: "https://dist.apache.org/repos/dist/dev/; +checksum-root: "https://dist.apache.org/repos/dist/dev/; +download-path: "guacamole/1.0.0-RC1/" + +source-dist: +- "source/guacamole-client-1.0.0.tar.gz" +- "source/guacamole-server-1.0.0.tar.gz" + +binary-dist: +- "binary/guacamole-1.0.0.war" +- "binary/guacamole-auth-cas-1.0.0.tar.gz" +- "binary/guacamole-auth-duo-1.0.0.tar.gz" +- "binary/guacamole-auth-header-1.0.0.tar.gz" +- "binary/guacamole-auth-jdbc-1.0.0.tar.gz" +- "binary/guacamole-auth-ldap-1.0.0.tar.gz" +- "binary/guacamole-auth-openid-1.0.0.tar.gz" +- "binary/guacamole-auth-quickconnect-1.0.0.tar.gz" +- "binary/guacamole-auth-totp-1.0.0.tar.gz" + +documentation: +"Manual" : "/doc/1.0.0/gug" +"guacamole-common": "/doc/1.0.0/guacamole-common" +"guacamole-common-js" : "/doc/1.0.0/guacamole-common-js" +"guacamole-ext" : "/doc/1.0.0/guacamole-ext" +"libguac" : "/doc/1.0.0/libguac" + +--- + +The 1.0.0 release features support for user groups, improved clipboard +integration leveraging the Asynchronous Clipboard API, as well as support for +TOTP (Google Authenticator), RADIUS, and dead keys. + +**This release contains changes which break compatibility with past releases.** +Please see the [deprecation / compatibility +notes](#deprecation--compatibility-notes) section for more information. + + +New features and improvements +- + +### Support for user groups + +Guacamole now supports [granting permissions based on group +membership](/doc/1.0.0/gug/administration.html#user-group-management). While +this has been supported to a degree for some time via LDAP and the `seeAlso` +attribute, groups can now be defined and used within a database, with LDAP and +a database combined, or within other extensions using Guacamole's extension +API. + + * [GUACAMOLE-220](https://issues.apache.org/jira/browse/GUACAMOLE-220) - Implement user groups + +### Clipboard integration with the Asynchronous Clipboard API + +For browsers which implement the [Asynchronous Clipboard +API](https://www.w3.org/TR/clipboard-apis/#async-clipboard-api), Guacamole will +now automatically synchronize the local and remote clipboards. Users will be +prompted to grant clipboard access upon opening Guacamole, and Guacamole will +synchronize the clipboard if access is granted. + +This API [has been implemented in Google Chrome since version +66](https://developers.google.com/web/updates/2018/03/clipboardapi), and other +browsers will likely follow suit. The legacy synchronous clipboard API will +continue to be used as a fallback for browsers that support clipboard access +but lack support for the newer API (Internet Explorer). + + * [GUACAMOLE-559](https://issues.apache.org/jira/browse/GUACAMOLE-559) - Add support for the new Asynchronous Clipboard API + +### Multi-factor authentication with Google Authenticator / TOTP + +Guacamole now has support for TOTP as an additional authentication factor. +TOTP ([Time-based One-Time Password](https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm)) +is a [standardized algorithm](https://tools.ietf.org/html/rfc6238) used for +multi-factor authentication. With this new support, Guacamole may be used with +any application or authentication device which supports the TOTP standard, +including the popular Google Authenticator. + + * [GUACAMOLE-96](https://issues.apache.org/jira/browse/GUACAMOLE-96) - Two factor authentication with Google Authenticator + +### Support for RADIUS authentication + +RADIUS support has been added, allowing Guacamole to delegate authentication to +a RADIUS service like FreeRADIUS for validating credentials, enforcing multiple +authentication factors, etc. + +Because the RADIUS library used by this support is licensed under the LGPL, a +convenience binary for this extension is not provided. If you wish to use the +RADIUS support
[GitHub] guacamole-website pull request #64: Add draft release notes for first RC of ...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-website/pull/64#discussion_r245442909 --- Diff: _releases/1.0.0.md --- @@ -0,0 +1,805 @@ +--- + +released: false +title: 1.0.0 +date: 2018-12-20 22:00:00 -0800 +summary: > +User groups, improved clipboard integration, TOTP (Google Authenticator), +RADIUS, dead keys. + +artifact-root: "https://dist.apache.org/repos/dist/dev/; +checksum-root: "https://dist.apache.org/repos/dist/dev/; +download-path: "guacamole/1.0.0-RC1/" + +source-dist: +- "source/guacamole-client-1.0.0.tar.gz" +- "source/guacamole-server-1.0.0.tar.gz" + +binary-dist: +- "binary/guacamole-1.0.0.war" +- "binary/guacamole-auth-cas-1.0.0.tar.gz" +- "binary/guacamole-auth-duo-1.0.0.tar.gz" +- "binary/guacamole-auth-header-1.0.0.tar.gz" +- "binary/guacamole-auth-jdbc-1.0.0.tar.gz" +- "binary/guacamole-auth-ldap-1.0.0.tar.gz" +- "binary/guacamole-auth-openid-1.0.0.tar.gz" +- "binary/guacamole-auth-quickconnect-1.0.0.tar.gz" +- "binary/guacamole-auth-totp-1.0.0.tar.gz" + +documentation: +"Manual" : "/doc/1.0.0/gug" +"guacamole-common": "/doc/1.0.0/guacamole-common" +"guacamole-common-js" : "/doc/1.0.0/guacamole-common-js" +"guacamole-ext" : "/doc/1.0.0/guacamole-ext" +"libguac" : "/doc/1.0.0/libguac" + +--- + +The 1.0.0 release features support for user groups, improved clipboard +integration leveraging the Asynchronous Clipboard API, as well as support for +TOTP (Google Authenticator), RADIUS, and dead keys. + +**This release contains changes which break compatibility with past releases.** +Please see the [deprecation / compatibility +notes](#deprecation--compatibility-notes) section for more information. + + +New features and improvements +- + +### Support for user groups + +Guacamole now supports [granting permissions based on group +membership](/doc/1.0.0/gug/administration.html#user-group-management). While +this has been supported to a degree for some time via LDAP and the `seeAlso` +attribute, groups can now be defined and used within a database, with LDAP and +a database combined, or within other extensions using Guacamole's extension +API. + + * [GUACAMOLE-220](https://issues.apache.org/jira/browse/GUACAMOLE-220) - Implement user groups + +### Clipboard integration with the Asynchronous Clipboard API + +For browsers which implement the [Asynchronous Clipboard +API](https://www.w3.org/TR/clipboard-apis/#async-clipboard-api), Guacamole will +now automatically synchronize the local and remote clipboards. Users will be +prompted to grant clipboard access upon opening Guacamole, and Guacamole will +synchronize the clipboard if access is granted. + +This API [has been implemented in Google Chrome since version +66](https://developers.google.com/web/updates/2018/03/clipboardapi), and other +browsers will likely follow suit. The legacy synchronous clipboard API will +continue to be used as a fallback for browsers that support clipboard access +but lack support for the newer API (Internet Explorer). + + * [GUACAMOLE-559](https://issues.apache.org/jira/browse/GUACAMOLE-559) - Add support for the new Asynchronous Clipboard API + +### Multi-factor authentication with Google Authenticator / TOTP + +Guacamole now has support for TOTP as an additional authentication factor. +TOTP ([Time-based One-Time Password](https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm)) +is a [standardized algorithm](https://tools.ietf.org/html/rfc6238) used for +multi-factor authentication. With this new support, Guacamole may be used with +any application or authentication device which supports the TOTP standard, +including the popular Google Authenticator. + + * [GUACAMOLE-96](https://issues.apache.org/jira/browse/GUACAMOLE-96) - Two factor authentication with Google Authenticator + +### Support for RADIUS authentication + +RADIUS support has been added, allowing Guacamole to delegate authentication to +a RADIUS service like FreeRADIUS for validating credentials, enforcing multiple +authentication factors, etc. + +Because the RADIUS library used by this support is licensed under the LGPL, a +convenience binary for this extension is not provided. If you wish to use the +RADIUS support
[GitHub] guacamole-website pull request #64: Add draft release notes for first RC of ...
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-website/pull/64 Add draft release notes for first RC of 1.0.0. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-website draft-1.0.0-RC1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-website/pull/64.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #64 commit 0fc74a5a7e661ca34caa88087eedb32e8717 Author: Michael Jumper Date: 2018-12-10T07:08:05Z Add draft release notes for first RC of 1.0.0. commit b06f4f88ca18525a7d86057d1cf147f0a2d020f5 Author: Nick Couchman Date: 2019-01-01T19:32:33Z Update draft release notes for 1.0.0-RC1 commit 6f785e121b845dc9482e67f6bc8e0d9894c4bccc Author: Michael Jumper Date: 2019-01-02T09:02:50Z Clarify wording of draft 1.0.0 release notes, fix typos. commit 26d79b03a48b321079ae196d6de9a82413528b22 Author: Michael Jumper Date: 2019-01-04T18:42:20Z Add links to documentation where applicable. commit c165e3c23f2448f4897f1ad089ba742125df4c0a Author: Michael Jumper Date: 2019-01-04T19:51:18Z Add remaining descriptions of changes in 1.0.0. commit de832ea8f8c28619b01ca3c2023f525d75be31b4 Author: Michael Jumper Date: 2019-01-04T20:02:57Z The "known_hosts" file is called "ssh_known_hosts" within GUACAMOLE_HOME. commit 72a711c945172ed118d0c908dcbd8a2e8504d021 Author: Michael Jumper Date: 2019-01-04T20:16:17Z Add additional links to documentation where relevant to 1.0.0 changes. ---
Re: 1.0.0 Release?
On Tue, Jan 1, 2019 at 11:35 AM Nick Couchman wrote: > I'm about half done (ish). Some is written while the rest is > > outlined/stubbed. Here's what I have so far: > > > > https://github.com/mike-jumper/guacamole-website/tree/draft-1.0.0-RC1 > > > > If you'd like to assist, please do. I can pull commits off your fork, > etc. > > so that the ultimate pull request has both of our changes. > > > > > I've taken a stab at writing some of this, for at least the items I was > familiar enough with to begin > documenting. Here is my branch: > > https://github.com/necouchman/guacamole-website/tree/draft-1.0.0-RC1 > > I'll continue to work it and you can use what you like and discard what you > don't. I wasn't entirely sure how much detail should be included in > particular sections of changes, so I erred on the verbose side. > Thanks, Nick! - Mike
Re: 1.0.0 Release?
On Mon, Dec 31, 2018 at 8:59 AM Nick Couchman wrote: > > > > > > Pretty good, I'd say. I'll type up draft release notes, etc. > > > > - Mike > > > > Mike, > Any progress on the release notes? I started working on some myself, if > you haven't started on them I can finish up a cut and send those over? > > I'm about half done (ish). Some is written while the rest is outlined/stubbed. Here's what I have so far: https://github.com/mike-jumper/guacamole-website/tree/draft-1.0.0-RC1 If you'd like to assist, please do. I can pull commits off your fork, etc. so that the ultimate pull request has both of our changes. - Mike
[GitHub] guacamole-client pull request #347: GUACAMOLE-682: docker build with optiona...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-client/pull/347#discussion_r243742443 --- Diff: guacamole-docker/bin/build-guacamole.sh --- @@ -41,6 +41,7 @@ BUILD_DIR="$1" DESTINATION="$2" +BUILD_PROFILE="$3" --- End diff -- This new `BUILD_PROFILE` parameter for `build-guacamole.sh` needs to be documented with an `@param` in the corresponding comment block (see the Doxygen-style block above covering this script and the other two parameters). ---
[GitHub] guacamole-website pull request #63: Add documentation for 1.0.0.
GitHub user mike-jumper opened a pull request: https://github.com/apache/guacamole-website/pull/63 Add documentation for 1.0.0. Documentation for the first RC per: http://guacamole.apache.org/release-procedures-part2/#upload-docs You can merge this pull request into a Git repository by running: $ git pull https://github.com/mike-jumper/guacamole-website doc-1.0.0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/guacamole-website/pull/63.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #63 commit 044692cfe4a81b68c2dbe29c5c5e08b1da0645f2 Author: Michael Jumper Date: 2018-12-21T21:49:53Z Add documentation for 1.0.0. commit a5693fdfe4751554e6779fd6cd3c26dbd9bb0a4b Author: Michael Jumper Date: 2018-12-21T21:51:23Z Add Google Analytics tracking code to 1.0.0 documentation. ---
Re: Help with Single Sign Out/Single Log Out
On Sat, Dec 15, 2018 at 12:39 PM Nick Couchman wrote: > Hey, everyone, > I'm looking at implementing the Single Sign Out/Single Log Out in the CAS, > OpenID, and Header modules, and need a little guidance in the best way to > accomplish this. For each of these modules, it seems like the way to > accomplish the SLO functionality is to redirect the user to a logout page > for the given IDP. I'm just having a little trouble figuring out where and > how to accomplish it. > > My thought is that the place to do this would be in the invalidate() method > within the various implementations of the AuthenticatedUser in the > modules. However, most of the redirection to other places for > authentication is handled by throwing exceptions that are then translated > by the AngularJS application to redirect. However, the current > implementation of invalidate() doesn't include the specification to throw > exceptions, so that's not going to work out of the box. > > The other option would seem to be to generate an HttpServletResponse that > can redirect the client, but I can't pull this out of thin air and don't > seem to be able to figure out where to make it come from. > > Suggestions on what direction I should look in? Is this something that > should work by writing something simple in the invalidate() method, or do I > need to be looking at retooling the API and/or guacamole-ext stuff a little > bit to allow this functionality? I think this can be accomplished with what is already present. It depends on what must happen during logout, though. Depending on the needs of the IDP, there are two sides to single logout that may come into play: 1) Notifying the IDP that the user has logged out. If the IDP or use case requires this sort of thing, and there is some sort of endpoint which must be used to notify the IDP that the user has logged out, then a server-side request to that endpoint within invalidate() is exactly what would need to be done. 2) Cosmetically redirecting the user away from Guacamole and to some other URL. There is a "guacLogout" event broadcast by the authentication service which is tempting: https://github.com/apache/guacamole-client/blob/fd2198d62bd5181c6a193dbcedc401823e0fbabe/guacamole/src/main/webapp/app/auth/service/authenticationService.js#L293-L294 But that fires before the token is invalidated, and there is a different redirect that takes place after the logout() call succeeds: https://github.com/apache/guacamole-client/blob/a1e6db170f286882670957e1e127cae061096bb3/guacamole/src/main/webapp/app/navigation/directives/guacUserMenu.js#L145-L148 I think we would need to split that event up a bit - adding a "guacBeforeLogout" to replace what is currently "guacLogout", moving "guacLogout" such that it fires after the logout request has completed, and moving the redirect into default handling which takes effect if preventDefault() for "guacLogout" is not set. The behavior upon logout could then be overridden by adding an event handler for "guacLogout". The problem then becomes exposing the configured redirect URL for consumption by the overridden logout handling. - Mike
[GitHub] guacamole-client pull request #345: GUACAMOLE-234: Migrate to Apache Directo...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/345#discussion_r241908453
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ObjectQueryService.java
---
@@ -188,46 +183,50 @@ public String generateQuery(String filter,
* information required to execute the query cannot be read from
* guacamole.properties.
*/
-public List search(LDAPConnection ldapConnection,
-String baseDN, String query) throws GuacamoleException {
+public List search(LdapConnection ldapConnection,
+Dn baseDN, ExprNode query) throws GuacamoleException {
logger.debug("Searching \"{}\" for objects matching \"{}\".",
baseDN, query);
try {
+LdapConnectionConfig ldapConnectionConfig =
+((LdapNetworkConnection) ldapConnection).getConfig();
+
// Search within subtree of given base DN
-LDAPSearchResults results = ldapConnection.search(baseDN,
-LDAPConnection.SCOPE_SUB, query, null, false,
-confService.getLDAPSearchConstraints());
+SearchRequest request = ldapService.getSearchRequest(baseDN,
+query);
+
+SearchCursor results = ldapConnection.search(request);
// Produce list of all entries in the search result,
automatically
// following referrals if configured to do so
-List entries = new ArrayList<>(results.getCount());
-while (results.hasMore()) {
+List entries = new ArrayList<>();
+while (results.next()) {
-try {
-entries.add(results.next());
+Response response = results.get();
+if (response instanceof SearchResultEntry) {
+entries.add(((SearchResultEntry) response).getEntry());
}
-
-// Warn if referrals cannot be followed
-catch (LDAPReferralException e) {
-if (confService.getFollowReferrals()) {
-logger.error("Could not follow referral: {}",
e.getFailedReferral());
-logger.debug("Error encountered trying to follow
referral.", e);
-throw new GuacamoleServerException("Could not
follow LDAP referral.", e);
-}
-else {
-logger.warn("Given a referral, but referrals are
disabled. Error was: {}", e.getMessage());
-logger.debug("Got a referral, but configured to
not follow them.", e);
+else if (response instanceof SearchResultReference &&
+request.isFollowReferrals()) {
+
+Referral referral = ((SearchResultReference)
response).getReferral();
+int referralHop = 0;
+for (String url : referral.getLdapUrls()) {
+LdapConnection referralConnection =
ldapService.referralConnection(
+new LdapUrl(url), ldapConnectionConfig,
referralHop++);
+entries.addAll(search(referralConnection, baseDN,
query));
--- End diff --
I'm not sure this is correct. Each call to `search()` will effectively
reset that `referralHop` counter. Doesn't this need to be tracked recursively
such that it limits the depth of the referral tree?
---
[GitHub] guacamole-client pull request #336: GUACAMOLE-641: Add support for populatin...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/336#discussion_r241549475
--- Diff:
extensions/guacamole-auth-vault/modules/guacamole-auth-vault-base/src/main/java/org/apache/guacamole/auth/vault/user/VaultUserContext.java
---
@@ -0,0 +1,325 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.guacamole.auth.vault.user;
+
+import com.google.inject.Inject;
+import com.google.inject.assistedinject.Assisted;
+import com.google.inject.assistedinject.AssistedInject;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import org.apache.guacamole.GuacamoleException;
+import org.apache.guacamole.GuacamoleServerException;
+import org.apache.guacamole.auth.vault.conf.VaultConfigurationService;
+import org.apache.guacamole.net.auth.Connection;
+import org.apache.guacamole.net.auth.ConnectionGroup;
+import org.apache.guacamole.net.auth.TokenInjectingUserContext;
+import org.apache.guacamole.net.auth.UserContext;
+import org.apache.guacamole.auth.vault.secret.VaultSecretService;
+import org.apache.guacamole.protocol.GuacamoleConfiguration;
+import org.apache.guacamole.token.GuacamoleTokenUndefinedException;
+import org.apache.guacamole.token.TokenFilter;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * UserContext implementation which automatically injects tokens
containing the
+ * values of secrets retrieved from a vault.
+ */
+public class VaultUserContext extends TokenInjectingUserContext {
+
+/**
+ * Logger for this class.
+ */
+private final Logger logger =
LoggerFactory.getLogger(VaultUserContext.class);
--- End diff --
SLF4J formerly recommended that instance variables be used (non-static),
but no longer takes either stance:
https://www.slf4j.org/faq.html#declared_static
If we have to pick something to be the standard going forward, I'd say
let's stick with the accepted idiom of `private final static` loggers, with the
exception being where it's actually necessary to not be `static` (dependency
injection).
---
[GitHub] guacamole-client pull request #336: GUACAMOLE-641: Add support for populatin...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/336#discussion_r241526587
--- Diff:
extensions/guacamole-auth-vault/modules/guacamole-auth-vault-base/src/main/java/org/apache/guacamole/auth/vault/user/VaultUserContext.java
---
@@ -0,0 +1,325 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.guacamole.auth.vault.user;
+
+import com.google.inject.Inject;
+import com.google.inject.assistedinject.Assisted;
+import com.google.inject.assistedinject.AssistedInject;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import org.apache.guacamole.GuacamoleException;
+import org.apache.guacamole.GuacamoleServerException;
+import org.apache.guacamole.auth.vault.conf.VaultConfigurationService;
+import org.apache.guacamole.net.auth.Connection;
+import org.apache.guacamole.net.auth.ConnectionGroup;
+import org.apache.guacamole.net.auth.TokenInjectingUserContext;
+import org.apache.guacamole.net.auth.UserContext;
+import org.apache.guacamole.auth.vault.secret.VaultSecretService;
+import org.apache.guacamole.protocol.GuacamoleConfiguration;
+import org.apache.guacamole.token.GuacamoleTokenUndefinedException;
+import org.apache.guacamole.token.TokenFilter;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * UserContext implementation which automatically injects tokens
containing the
+ * values of secrets retrieved from a vault.
+ */
+public class VaultUserContext extends TokenInjectingUserContext {
+
+/**
+ * Logger for this class.
+ */
+private final Logger logger =
LoggerFactory.getLogger(VaultUserContext.class);
+
+/**
+ * The name of the token which will be replaced with the username of
the
+ * current user if specified within the name of a secret. This token
+ * applies to both connections and connection groups.
+ */
+private static final String USERNAME_TOKEN = "GUAC_USERNAME";
+
+/**
+ * The name of the token which will be replaced with the name of the
+ * current connection group if specified within the name of a secret.
This
+ * token only applies only to connection groups.
+ */
+private static final String CONNECTION_GROUP_NAME_TOKEN =
"CONNECTION_GROUP_NAME";
+
+/**
+ * The name of the token which will be replaced with the identifier of
the
+ * current connection group if specified within the name of a secret.
This
+ * token only applies only to connection groups.
+ */
+private static final String CONNECTION_GROUP_IDENTIFIER_TOKEN =
"CONNECTION_GROUP_ID";
+
+/**
+ * The name of the token which will be replaced with the \"hostname\"
+ * connection parameter of the current connection if specified within
the
+ * name of a secret. This token only applies only to connections.
+ */
+private static final String CONNECTION_HOSTNAME_TOKEN =
"CONNECTION_HOSTNAME";
+
+/**
+ * The name of the token which will be replaced with the \"username\"
+ * connection parameter of the current connection if specified within
the
+ * name of a secret. This token only applies only to connections.
+ */
+private static final String CONNECTION_USERNAME_TOKEN =
"CONNECTION_USERNAME";
+
+/**
+ * The name of the token which will be replaced with the name of the
+ * current connection if specified within the name of a secret. This
token
+ * only applies only to connections.
+ */
+private static final String CONNECTION_NAME_TOKEN = "CONNECTION_NAME";
+
+/**
+ * The name of the token which will be replaced with the ide
[GitHub] guacamole-client pull request #336: GUACAMOLE-641: Add support for populatin...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/336#discussion_r241526412
--- Diff:
extensions/guacamole-auth-vault/modules/guacamole-auth-vault-azure/src/main/java/org/apache/guacamole/auth/vault/azure/secret/AzureKeyVaultSecretService.java
---
@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.guacamole.auth.vault.azure.secret;
+
+import com.google.inject.Inject;
+import com.google.inject.Provider;
+import com.google.inject.Singleton;
+import com.microsoft.azure.keyvault.KeyVaultClient;
+import com.microsoft.azure.keyvault.authentication.KeyVaultCredentials;
+import com.microsoft.azure.keyvault.models.SecretBundle;
+import com.microsoft.rest.ServiceCallback;
+import java.util.concurrent.CompletableFuture;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+import org.apache.guacamole.GuacamoleException;
+import
org.apache.guacamole.auth.vault.azure.conf.AzureKeyVaultAuthenticationException;
+import
org.apache.guacamole.auth.vault.azure.conf.AzureKeyVaultConfigurationService;
+import org.apache.guacamole.auth.vault.secret.CachedVaultSecretService;
+
+/**
+ * Service which retrieves secrets from Azure Key Vault.
+ */
+@Singleton
+public class AzureKeyVaultSecretService extends CachedVaultSecretService {
+
+/**
+ * Pattern which matches contiguous groups of characters which are not
+ * allowed within Azure Key Vault secret names.
+ */
+private static final Pattern DISALLOWED_CHARACTERS =
Pattern.compile("[^a-zA-Z0-9-]+");
+
+/**
+ * Service for retrieving configuration information.
+ */
+@Inject
+private AzureKeyVaultConfigurationService confService;
+
+/**
+ * Provider for Azure Key Vault credentials.
+ */
+@Inject
+private Provider credentialProvider;
+
+/**
+ * {@inheritDoc}
+ *
+ * Azure Key Vault allows strictly a-z, A-Z, 0-9, and "-". This
--- End diff --
Yep, exactly right.
---
[GitHub] guacamole-client pull request #336: GUACAMOLE-641: Add support for populatin...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/336#discussion_r241525041
--- Diff:
extensions/guacamole-auth-vault/modules/guacamole-auth-vault-azure/src/main/java/org/apache/guacamole/auth/vault/azure/conf/AzureKeyVaultAuthenticationException.java
---
@@ -0,0 +1,57 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.guacamole.auth.vault.azure.conf;
+
+/**
+ * Unchecked exception thrown by AzureKeyVaultCredentials if an error
occurs
+ * during the authentication process. Note that the base
KeyVaultCredentials
+ * base class does not provide for checked exceptions within the
authentication
+ * process.
+ *
+ * @see AzureKeyVaultCredentials#doAuthenticate(java.lang.String,
java.lang.String, java.lang.String)
+ */
+public class AzureKeyVaultAuthenticationException extends RuntimeException
{
--- End diff --
Yep. From the top of the class:
https://github.com/apache/guacamole-client/blob/4d90b34732d81efd1fbdeab8df9d9edb939f6266/extensions/guacamole-auth-vault/modules/guacamole-auth-vault-azure/src/main/java/org/apache/guacamole/auth/vault/azure/conf/AzureKeyVaultAuthenticationException.java#L22-L30
The API provided for Azure does not allow for checked exceptions like
`GuacamoleException` to be thrown. Only unchecked exceptions can be used for
things which must be thrown within callbacks, etc. in their API. We catch this
specific exception and translate into a `GuacamoleException` before things make
their way back out to Guacamole.
---
[GitHub] guacamole-client pull request #336: GUACAMOLE-641: Add support for populatin...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/336#discussion_r241524434
--- Diff:
extensions/guacamole-auth-vault/modules/guacamole-auth-vault-azure/src/main/java/org/apache/guacamole/auth/vault/azure/AzureKeyVaultAuthenticationProviderModule.java
---
@@ -0,0 +1,61 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.guacamole.auth.vault.azure;
+
+import com.microsoft.azure.keyvault.authentication.KeyVaultCredentials;
+import org.apache.guacamole.GuacamoleException;
+import org.apache.guacamole.auth.vault.VaultAuthenticationProviderModule;
+import
org.apache.guacamole.auth.vault.azure.conf.AzureKeyVaultConfigurationService;
+import org.apache.guacamole.auth.vault.azure.conf.AzureKeyVaultCredentials;
+import
org.apache.guacamole.auth.vault.azure.secret.AzureKeyVaultSecretService;
+import org.apache.guacamole.auth.vault.conf.VaultConfigurationService;
+import org.apache.guacamole.auth.vault.secret.VaultSecretService;
+
+/**
+ * Guice module which configures injections specific to Azure Key Vault
+ * support.
+ */
+public class AzureKeyVaultAuthenticationProviderModule
+extends VaultAuthenticationProviderModule {
+
+/**
+ * Creates a new AzureKeyVaultAuthenticationiProviderModule which
--- End diff --
OK - will fix.
---
Re: 1.0.0 Release?
On Thu, Dec 6, 2018, 07:13 Nick Couchman On Sun, Dec 2, 2018 at 4:18 PM Nick Couchman wrote: > > > > >>> Very nice. I do need to try to investigate the issue reported with the > >> RADIUS extension this week - going to try to do some testing on that > this > >> weekend and see if there's anything that needs to be corrected there > prior > >> to the release. > >> > >> > > Just FYI - I'm chasing a couple of regressions in the 1.0.0 release - one > > having to do with incompatible slf4j dependencies being loaded into > various > > modules (PR created for this) and one for the CAS module not redirecting > > properly (which I'm banging my head trying to figure out). > > > > > Okay, I think we got those 2-3 bugs squashed. How are we feeling about > RC1? > Pretty good, I'd say. I'll type up draft release notes, etc. - Mike
[GitHub] guacamole-client pull request #342: GUACAMOLE-598: Ignore if current user ha...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/342#discussion_r239300359
--- Diff:
guacamole/src/main/webapp/app/navigation/directives/guacUserMenu.js ---
@@ -95,13 +95,10 @@ angular.module('navigation').directive('guacUserMenu',
[function guacUserMenu()
*/
$scope.role = null;
-// Pull user data
+// Display user profile attributes if available
userService.getUser(authenticationService.getDataSource(),
$scope.username)
.then(function userRetrieved(user) {
-// Store retrieved user object
-$scope.user = user;
--- End diff --
> Just want to make sure this doesn't have any impact? Was this $scope.user
not used at all?
It wasn't used at all. I removed this unnecessary assignment to
`$scope.user` after a brief "how is this working at all???" moment. As that
assignment will only occur if `userService.getUser()` succeeds, anything which
depends on it would fail in cases where that failure previously resulted in a
warning, yet clearly those cases (CAS, OpenID, header auth) work just fine.
The relevant template only references `$scope.username`. Neither the
template nor the directive reference `$scope.user`.
The `$scope.user` assignment was introduced briefly via e9549fb, at which
point it should have been documented (but wasn't). The usefulness of that
assignment was removed via 06fb054. Both of these changes were due to
[GUACAMOLE-292](https://issues.apache.org/jira/browse/GUACAMOLE-292), part of
0.9.13-incubating.
---
Re: Help with CAS Module Regression
On Sun, Dec 2, 2018 at 1:48 PM Nick Couchman wrote:
>
> Okay, banging my head against the wall here trying to figure out what's
> going on with the CAS module. At this point the redirect doesn't work at
> all - the CAS module just sits on the screen with the non-translated
> message:
>
> {{ 'LOGIN.INFO_CAS_REDIRECT_PENDING' | translate }}
>
> and never redirects. In the JS console I get the following:
>
> Failed to retrieve field with type "GUAC_CAS_TICKET"
>
That specific message will occur if a custom field type cannot be used:
https://github.com/apache/guacamole-client/blob/fc457c080d813044e30e1f4e8fe855d6a5900259/guacamole/src/main/webapp/app/form/directives/formField.js#L152
That's just a generic "catch", though. If an exception occurs
somewhere within the promise handling (due to something now being
broken in our handling of custom fields?), you could see the same
result, despite the field type being correctly registered. If this is
the case, other things that use custom fields like Duo or TOTP may
also not work as expected. Worth rechecking.
> Any ideas what might be going on here? I've looked at the various parts of
> the CAS module, particularly the AngularJS stuff, and compared to OpenID to
> see what differences might be there, and can't see anything obvious. I'm
> sure it's something simple/stupid, but I need another set of eyes on it.
> Also, has the OpenID module been tested recently to make sure it works? I
> don't think I have an OpenID provider I can test against, else I would do
> it myself...
I have a test deployment which uses OpenID against Google - I'll recheck.
>
> Let me know if I can provide any additional information. I don't see
> anything obviously wrong in the catalina.out file, so figure it's something
> AngularJS-based that's going on.
>
Did this error occur in 0.9.14?
If this is breaking things, and did not occur when CAS support was
initially released, I'd suggest a git bisect to narrow down when it
started.
- Mike
[GitHub] guacamole-server pull request #204: GUACAMOLE-354: Add Swiss-German keymap f...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/204#discussion_r238316700 --- Diff: src/protocols/rdp/keymaps/de_ch_qwertz.keymap --- @@ -0,0 +1,58 @@ +# +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +parent "base" +name"ch-de-qwertz" --- End diff -- The keyboard name should be LANG-COUNTRY-VARIANT, same as the filename except with dashes instead of underscores. Is "de-ch-qwertz" correct here or "ch-de-qwertz"? ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/206#discussion_r238167956
--- Diff: src/guacd/daemon.c ---
@@ -275,6 +281,17 @@ int main(int argc, char* argv[]) {
/* General */
int retval;
+#ifdef PTHREAD_STACK_SIZE
+/* Set default stack size */
+pthread_attr_t default_pthread_attr;
+if (pthread_attr_init(_pthread_attr) ||
+pthread_attr_setstacksize(_pthread_attr,
PTHREAD_STACK_SIZE) ||
+pthread_setattr_default_np(_pthread_attr)) {
+ fprintf(stderr, "Couldn't set requested pthread stack size of
%d\n", PTHREAD_STACK_SIZE);
--- End diff --
Why `fprintf()` early rather than `guacd_log()` after the logging system is
ready?
---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r238170624 --- Diff: src/guacd/daemon.c --- @@ -19,6 +19,12 @@ #include "config.h" +#ifdef PTHREAD_STACK_SIZE +#define _GNU_SOURCE 1 --- End diff -- I'm concerned over explicitly setting `_GNU_SOURCE` and using the non-portable `pthread_setattr_default_np()`. There's no guarantee that `pthread_setattr_default_np()` will be available, or that it will be available if `_GNU_SOURCE` is set. Testing for these within configure would be an improvement, but the non-portability is still concerning. Is there no portable way to do this? ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r238171069 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) --- End diff -- This may be confusing as "8MB" is not a value accepted by this option. ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r238171680 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) +],pthread_stack_size=$withval + AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE], [$pthread_stack_size], [pthread stack size (8MB is recommended)]) +) +if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then +AC_MSG_CHECKING([whether default pthread stack is larger than 8MB]) +ac_save_libs="$LIBS" +LIBS="$LIBS -lpthread" --- End diff -- Not all platforms use libpthread for POSIX threads. Some have this built into libc. If necessary, you might be able to use `$PTHREAD_LIBS` which is set by an earlier test: https://github.com/apache/guacamole-server/blob/bbb6afaf462f6930a589f962302806c52f350c0b/configure.ac#L61-L64 ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/206#discussion_r238170864
--- Diff: src/guacd/daemon.c ---
@@ -275,6 +281,17 @@ int main(int argc, char* argv[]) {
/* General */
int retval;
+#ifdef PTHREAD_STACK_SIZE
+/* Set default stack size */
+pthread_attr_t default_pthread_attr;
+if (pthread_attr_init(_pthread_attr) ||
+pthread_attr_setstacksize(_pthread_attr,
PTHREAD_STACK_SIZE) ||
+pthread_setattr_default_np(_pthread_attr)) {
+ fprintf(stderr, "Couldn't set requested pthread stack size of
%d\n", PTHREAD_STACK_SIZE);
+ exit(EXIT_FAILURE);
--- End diff --
Please use 4-space indents per level. See:
http://guacamole.apache.org/guac-style/#general-style
---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r238172953 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) +],pthread_stack_size=$withval + AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE], [$pthread_stack_size], [pthread stack size (8MB is recommended)]) +) +if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then +AC_MSG_CHECKING([whether default pthread stack is larger than 8MB]) +ac_save_libs="$LIBS" +LIBS="$LIBS -lpthread" +AC_RUN_IFELSE([AC_LANG_SOURCE([[ --- End diff -- [The documentation for `AC_RUN_IFELSE`](https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Runtime.html) states: > Avoid running test programs if possible, because this prevents people from configuring your package for cross-compiling. Is there any other way to achieve this which would not hurt cross-compilation? ---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/206#discussion_r238168882
--- Diff: src/guacd/daemon.c ---
@@ -275,6 +281,17 @@ int main(int argc, char* argv[]) {
/* General */
int retval;
+#ifdef PTHREAD_STACK_SIZE
+/* Set default stack size */
+pthread_attr_t default_pthread_attr;
+if (pthread_attr_init(_pthread_attr) ||
+pthread_attr_setstacksize(_pthread_attr,
PTHREAD_STACK_SIZE) ||
+pthread_setattr_default_np(_pthread_attr)) {
+ fprintf(stderr, "Couldn't set requested pthread stack size of
%d\n", PTHREAD_STACK_SIZE);
--- End diff --
> `"Couldn't set requested pthread stack size of %d\n"`
At the time this failure occurs, the user hasn't requested anything - the
stack size is set permanently at build time. This message should be rephrased
such that the nature of the error can be understood by the user running guacd.
---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/206#discussion_r238172374
--- Diff: configure.ac ---
@@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE],
'-I$(top_srcdir)/src/common-ssh')
AC_SUBST([TERMINAL_LTLIB],
'$(top_builddir)/src/terminal/libguac_terminal.la')
AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS)
$(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)')
+# pthread stack size
+AC_ARG_WITH(pthread_stack,
+[AS_HELP_STRING([--with-pthread_stack=],
+[explicitly set pthread stack size (8MB is
recommended)])
+],pthread_stack_size=$withval
+ AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE],
[$pthread_stack_size], [pthread stack size (8MB is recommended)])
+)
+if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then
+AC_MSG_CHECKING([whether default pthread stack is larger than 8MB])
+ac_save_libs="$LIBS"
+LIBS="$LIBS -lpthread"
+AC_RUN_IFELSE([AC_LANG_SOURCE([[
+#include
+
+int main() {
+pthread_attr_t default_pthread_attr;
+size_t stacksize;
+
+#ifdef PTHREAD_STACK_SIZE
+return PTHREAD_STACK_SIZE < 8*1024*1024;
+#else
+pthread_attr_init(_pthread_attr);
+pthread_attr_getstacksize(_pthread_attr,
);
+return stacksize < 8*1024*1024;
+#endif
+}
+
+ ]])],
+ [AC_MSG_RESULT([yes])],
+ [AC_MSG_RESULT([no])
+ AC_MSG_WARN([
+
+ Default pthread stack size is less than 8MB
--- End diff --
Do we know for certain that 8MB satisfies our stack requirements?
---
[GitHub] guacamole-server pull request #206: GUACAMOLE-663: guacd SEGVs intermittentl...
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-server/pull/206#discussion_r238171724 --- Diff: configure.ac --- @@ -140,6 +140,46 @@ AC_SUBST([COMMON_SSH_INCLUDE], '-I$(top_srcdir)/src/common-ssh') AC_SUBST([TERMINAL_LTLIB], '$(top_builddir)/src/terminal/libguac_terminal.la') AC_SUBST([TERMINAL_INCLUDE], '-I$(top_srcdir)/src/terminal $(PANGO_CFLAGS) $(PANGOCAIRO_CFLAGS) $(COMMON_INCLUDE)') +# pthread stack size +AC_ARG_WITH(pthread_stack, +[AS_HELP_STRING([--with-pthread_stack=], +[explicitly set pthread stack size (8MB is recommended)]) +],pthread_stack_size=$withval + AC_DEFINE_UNQUOTED([PTHREAD_STACK_SIZE], [$pthread_stack_size], [pthread stack size (8MB is recommended)]) +) +if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then --- End diff -- Where does `ac_cv_lib_pthread_pthread_create` come from? ---
[GitHub] guacamole-server pull request #205: GUACAMOLE-667: Enable loading configurat...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/205#discussion_r23656
--- Diff: src/guacd/conf-file.c ---
@@ -188,15 +188,21 @@ guacd_config* guacd_conf_load() {
conf->key_file = NULL;
#endif
+/* Determine path of configuration file */
+if(conf_file_path == NULL) {
--- End diff --
> Why do this particular check, here? Why not always make sure this
function is fed a path, and then upstream feed either the provided location or
the constant `GUACD_CONF_FILE`?
I agree with this. This doesn't seem the place for a `NULL` check and
additional semantics. It would be far better if the default value for the
config file path were handled like other defaults.
I'd argue that it's the current handling of defaults that should be
restructured - bringing that out of `guacd_conf_load()` such that the process
becomes:
1. Populate `guacd_config` with defaults.
2. Apply any settings from config file to that `guacd_config`, overriding
default values.
3. Apply any settings from command line to that `guacd_config`, overriding
default values and those from the config file.
See:
https://github.com/apache/guacamole-server/blob/bbb6afaf462f6930a589f962302806c52f350c0b/src/guacd/conf-file.c#L178-L184
---
[GitHub] guacamole-server pull request #205: GUACAMOLE-667: Enable loading configurat...
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-server/pull/205#discussion_r236553937
--- Diff: src/guacd/conf-args.c ---
@@ -122,3 +128,15 @@ int guacd_conf_parse_args(guacd_config* config, int
argc, char** argv) {
}
+const char* guacd_conf_get_path(int argc, char** argv) {
+
+/* Find -c option */
+int i;
+for(i=1; i
Re: RADIUS Module Issue
On Wed, Nov 21, 2018 at 2:25 PM Nick Couchman wrote: > ... > That authentication of that user moves through each of the modules. So, if > the JDBC module fails, either because the user is not present in JDBC or is > present but password does not match, authentication moves on to the RADIUS > module and is checked against that module. I believe this works correctly > between, for example, LDAP -> JDBC (although I've never tried putting LDAP > authentication *after* JDBC), so I'm not sure why it isn't working for JDBC > -> RADIUS. > In the JDBC -> RADIUS case where it's not working as expected, what exceptions are thrown during the authentication process? It might help to step through the auth process with a debugger to see what throws what and when. - Mike
[GitHub] guacamole-client pull request #340: Urdu language
Github user mike-jumper commented on a diff in the pull request: https://github.com/apache/guacamole-client/pull/340#discussion_r235649378 --- Diff: extensions/guacamole-auth-cas/nb-configuration.xml --- @@ -0,0 +1,18 @@ + --- End diff -- Please do not include IDE project/configuration files in your commits. ---
[GitHub] guacamole-client pull request #340: Urdu language
Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/guacamole-client/pull/340#discussion_r235650645
--- Diff: guacamole/src/main/webapp/translations/ur.json ---
@@ -0,0 +1,874 @@
+{
+
+"NAME" : "اردÙ",
+
+"DIRECTION":"rtl",
--- End diff --
Please follow the style of the surrounding code (see other comment). The
new JSON should be consistent in style with existing translations.
---
Re: RADIUS Module Issue
On Tue, Nov 20, 2018 at 10:46 AM Nick Couchman wrote: > Hey, everyone, > Ran back into an issue with the RADIUS module that I thought was resolved a > while back, but seems to have re-appeared. In my current testing, I'm > using both RADIUS and JDBC PostgreSQL for authentication. Guacamole loads > and evaluates authentication against each of the extensions in alphabetical > order. If I have the RADIUS module installed such that it loads and > evaluates *after* the JDBC module, authentication fails for the RADIUS > users. If I have the RADIUS module installed such that it loads and > evaluates *before* the JDBC module (put a 0 in front of radius - e.g. > guacamole-auth-0radius-1.0.0.jar), it works correctly. > > What is the expected behavior for the case that RADIUS is queried last? - Mike
Re: Kubernetes vs. Docker Engine protocol
On Sat, Nov 17, 2018 at 9:04 PM Roman Shaposhnik wrote: > On Sat, Nov 17, 2018 at 7:15 PM Mike Jumper wrote: > > > > On Sat, Nov 17, 2018 at 2:59 PM Roman Shaposhnik wrote: > > > > > Hi! > > > > > > I was very pleasantly surprised to discover that Kubernetes > > > container TTY support is now part of Guacamole. The JIRA, > > > however, talks about both Docker Engine and Kubernetes. > > > Looking at the source code I'm not sure I see the code that > > > would talk to Docker Engine. Am I missing something? > > > > > > > > What JIRA issue are you referring to? The one I have in front of me is > > Kubernetes-specific: > > > > https://issues.apache.org/jira/browse/GUACAMOLE-623 > > I was looking at: https://jira.glyptodon.org/browse/GUAC-1658 > > The JIRA at jira.glyptodon.org is the JIRA instance for Glyptodon, Inc. It was used by the Guacamole project before it moved to the ASF and became Apache Guacamole. That JIRA continues to be used by Glyptodon to track downstream work/contributions, while the correct JIRA instance for the upstream project is the one hosted by the ASF at issues.apache.org: https://issues.apache.org/jira/browse/GUACAMOLE As I worked on both of the above (GUAC-1658 was the issue that tracked this work for my day job at Glyptodon), I can hopefully clarify the difference between the two issues' scopes: The original downstream motivation for the task was to add Kubernetes support. Early research lead me to believe that doing so would involve Docker to such an extent that support for both Docker and Kubernetes would be equivalent and implemented simultaneously. As it turns out, the two have very different APIs when it comes to attaching to the console of a container, and the scope had to be tightened to strictly Kubernetes. Similar support could certainly be added for Docker containers, as well, but would need to be tackled separately. - Mike
Re: guacd immediately disconnects when built and run on Alpine 3.7 (musl libc)
On Sat, Nov 17, 2018 at 12:59 PM Roman Shaposhnik wrote: > Hi! > > happy to report that I got to the bottom of this and have a patch that > makes guacd run on Alpine 3.8 just fine now: >https://issues.apache.org/jira/browse/GUACAMOLE-663 > > Thanks, Roman. Please open a pull request with your proposed changes rather than attaching a patch to JIRA. We can then review your changes and merge when everything is accepted. See: https://github.com/apache/guacamole-server/blob/master/CONTRIBUTING http://guacamole.apache.org/open-source/#contribute Would be awesome if something along these lines made it into 1.0 > release. I'd love to help with testing or anything else. > The scope of the 1.0.0 release has already been finalized. Only changes directly related to those already within release scope will be merged for inclusion in 1.0.0. The changes you've contributed, after review and when accepted, would go into the next release whose scope has not yet been finalized. At the moment, that release would be 2.0.0. - Mike
