You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Chris Cook <co...@jlsautomation.com> on 2016/10/10 17:12:19 UTC
Scripted Branding
Greetings,
I am currently reviewing Guacamole for inclusion in an IIoT platform for industrial equipment - to allow for operator interface access via webpage.
Both I and my team LOVE the default Guac 0.9.9 webapp!
However, we have one hurtle that we need some help overcoming... We are estimating approx. 100 uniquely branded deployments every year. As such, generating a deployment specific branding extension for each and every deployment would become rather cumbersome very quickly.
Is there a way to change the application name, the logo, and the favicon of the default web-client without having to generate and deploy a new .war archive?
Ultimately, we would like to create a bash script to 'automate' the installation and branding - ideally declaring a script variable which would query input from the cli user during scripted installation. What edits are necessary to accomplish this? Is it even possible?
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
RE: Scripted Branding
Posted by Chris Cook <co...@jlsautomation.com>.
Anything?
From: Chris Cook [mailto:cookcj@jlsautomation.com]
Sent: Monday, October 17, 2016 9:24 PM
To: user@guacamole.incubator.apache.org
Subject: RE: Scripted Branding
Sorry about the brevity of my earlier response; my better-half and I were entertaining a new client - one who is very keen on implementing and experimenting with a Guac based tablet/mobile HMI infrastructure within his factory...
The logos and the favicons, should both be fixed assets somewhere and should be fairly easy to copy over via script within a BASH environment, following the platform installation/build-out; something like the following should do the trick:
Logo Copyover:
cp /media/installationID/logo.png /guacamole_fixed-asset_directory/logo_whatever.png
Favicon Copyover:
cp /media/installationID/favicon.png /guacamole_fixed-asset_directory/favicon_whatever.png
The issue with this scripting methodology is knowing where the fixed assets are located within the default file structure... If you could provide some illumination as to the path of these static assets, that would be awesome.
Changing the webapp display name and the browser tab display names will be a little more complicated as they are both supposedly generated by a .css file somewhere. If this .css file is a static asset, where is it located? If this .css file is dynamically generated, what generates it and how can I edit it to accept a one-time user entry to establish an application name?
To be clear, the project I am working on is based upon a fixed/static and non-updating, configuration-fixed, and revision-controlled appliance build model - i.e. my company builds and installs the appliance within a system which will then be revision-fixed. If requested/required, I or another engineer would update the core platform, fault test the new core platform, press a new distribution image, and then update/upgrade the production system as specifically requested/contracted.
As such, I am not concerned about an end-client initiated update/upgrade event as my end-client user will not have the ability to independently perform such an operation without the involvement of either myself or one the engineers that works with/for me.
________________________________
From: Chris Cook [cookcj@jlsautomation.com]
Sent: Monday, October 17, 2016 7:14 PM
To: user@guacamole.incubator.apache.org<ma...@guacamole.incubator.apache.org>
Subject: Re: Scripted Branding
Mike,
Thanks for your response. If I am understanding you correctly, I can use a BASH script that includes functions like CAT or an ECHO pipe to write out an installation specific .jar to the guacamole-home folder?
Sent from my iPhone
On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org>> wrote:
On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>> wrote:
Greetings,
I am currently reviewing Guacamole for inclusion in an IIoT platform for industrial equipment - to allow for operator interface access via webpage.
Both I and my team LOVE the default Guac 0.9.9 webapp!
Thanks!
However, we have one hurtle that we need some help overcoming... We are estimating approx. 100 uniquely branded deployments every year. As such, generating a deployment specific branding extension for each and every deployment would become rather cumbersome very quickly.
Branding extensions are the intended way to achieve this. The idea was that by encapsulating such changes within an extension, branding changes could remain stable across upgrades, thus making things more convenient and doing away with the need to patch the webapp itself.
Is there a way to change the application name, the logo, and the favicon of the default web-client without having to generate and deploy a new .war archive?
There's no need to deploy a whole new .war each time (though, since you mentioned branding extensions earlier, perhaps you meant .jar).
It should be possible to script the generation of a branding extension if the specifics are predictable (logo, icon, changes to the strings). Have you given writing such a script a shot?
- Mike
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com<ma...@jlsautomation.com> and destroy all copies of this message and any attachments. Thank you.
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com<ma...@jlsautomation.com> and destroy all copies of this message and any attachments. Thank you.
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Mike Jumper <mi...@guac-dev.org>.
On Thu, Dec 29, 2016 at 8:13 AM, Cyle <cy...@cogmation.com> wrote:
> I made a very simple modification to the docker build script over on Github
> to incorporate my own branding extension into the build process. It's 3
> simple lines of code. You could incorporate whatever bash scripting you need
> to generate the extension, it's just a jar file.
>
>
> build-guacamole.sh:
> https://gist.github.com/nozpheratu/49604355077a7ac91b31b1b3fcc68fba#file-build-guacamole-sh-L112
>
>
> start.sh:
> https://gist.github.com/anonymous/3a56c29247774b368ee304e9271907de#file-start-sh-L178
>
FYI - recent changes should make this easier going forward. We are
adding a "GUACAMOLE_HOME" environment variable which will allow you to
include arbitrary configuration and extensions within a Guacamole
Docker container, where extensions would presumably be exposed into
the container via a mount point:
https://issues.apache.org/jira/browse/GUACAMOLE-100
The above changes are on git master, though the issue remains open
until the documentation changes are complete.
- Mike
Re: Scripted Branding
Posted by Cyle <cy...@cogmation.com>.
I made a very simple modification to the docker build script over on
Github to incorporate my own branding extension into the build process.
It's 3 simple lines of code. You could incorporate whatever bash
scripting you need to generate the extension, it's just a jar file.
build-guacamole.sh:
https://gist.github.com/nozpheratu/49604355077a7ac91b31b1b3fcc68fba#file-build-guacamole-sh-L112
start.sh:
https://gist.github.com/anonymous/3a56c29247774b368ee304e9271907de#file-start-sh-L178
On 2016-12-29 09:50 AM, Chris Cook wrote:
>
> Is there any guidance anywhere that I can refer to on this? Still
> looking for the answer
>
>
>
> *From:*Chris Cook
> *Sent:* Friday, October 21, 2016 2:14 PM
> *To:* 'user@guacamole.incubator.apache.org'; 'mike.jumper@guac-dev.org'
> *Subject:* RE: Scripted Branding
>
>
>
> Anything?
>
>
>
> *From:*Chris Cook [mailto:cookcj@jlsautomation.com]
> *Sent:* Monday, October 17, 2016 9:24 PM
> *To:* user@guacamole.incubator.apache.org
> <ma...@guacamole.incubator.apache.org>
> *Subject:* RE: Scripted Branding
>
>
>
> Sorry about the brevity of my earlier response; my better-half and I
> were entertaining a new client - one who is very keen on implementing
> and experimenting with a Guac based tablet/mobile HMI infrastructure
> within his factory...
>
> The logos and the favicons, should both be fixed assets somewhere and
> should be fairly easy to copy over via script within a BASH
> environment, following the platform installation/build-out; something
> like the following should do the trick:
>
> Logo Copyover:
> cp /media/installationID/logo.png
> /guacamole_fixed-asset_directory/logo_whatever.png
>
> Favicon Copyover:
> cp /media/installationID/favicon.png
> /guacamole_fixed-asset_directory/favicon_whatever.png
>
> The issue with this scripting methodology is knowing where the fixed
> assets are located within the default file structure... If you could
> provide some illumination as to the path of these static assets, that
> would be awesome.
>
> Changing the webapp display name and the browser tab display names
> will be a little more complicated as they are both supposedly
> generated by a .css file somewhere. If this .css file is a static
> asset, where is it located? If this .css file is dynamically
> generated, what generates it and how can I edit it to accept a
> one-time user entry to establish an application name?
>
> To be clear, the project I am working on is based upon a fixed/static
> and non-updating, configuration-fixed, and revision-controlled
> appliance build model - i.e. my company builds and installs the
> appliance within a system which will then be revision-fixed. If
> requested/required, I or another engineer would update the core
> platform, fault test the new core platform, press a new distribution
> image, and then update/upgrade the production system as specifically
> requested/contracted.
>
> As such, I am not concerned about an end-client initiated
> update/upgrade event as my end-client user will not have the ability
> to independently perform such an operation without the involvement of
> either myself or one the engineers that works with/for me.
>
> ------------------------------------------------------------------------
>
> *From:*Chris Cook [cookcj@jlsautomation.com]
> *Sent:* Monday, October 17, 2016 7:14 PM
> *To:* user@guacamole.incubator.apache.org
> <ma...@guacamole.incubator.apache.org>
> *Subject:* Re: Scripted Branding
>
> Mike,
>
>
>
> Thanks for your response. If I am understanding you correctly, I can
> use a BASH script that includes functions like CAT or an ECHO pipe to
> write out an installation specific .jar to the guacamole-home folder?
>
> Sent from my iPhone
>
>
> On Oct 17, 2016, at 18:56, Mike Jumper <mike.jumper@guac-dev.org
> <ma...@guac-dev.org>> wrote:
>
> On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook
> <cookcj@jlsautomation.com <ma...@jlsautomation.com>> wrote:
>
> Greetings,
>
> I am currently reviewing Guacamole for inclusion in an IIoT
> platform for industrial equipment - to allow for operator
> interface access via webpage.
>
> Both I and my team LOVE the default Guac 0.9.9 webapp!
>
>
>
> Thanks!
>
>
>
> However, we have one hurtle that we need some help
> overcoming... We are estimating approx. 100 uniquely branded
> deployments every year. As such, generating a deployment
> specific branding extension for each and every deployment
> would become rather cumbersome very quickly.
>
>
>
> Branding extensions are the intended way to achieve this. The idea
> was that by encapsulating such changes within an extension,
> branding changes could remain stable across upgrades, thus making
> things more convenient and doing away with the need to patch the
> webapp itself.
>
>
>
> Is there a way to change the application name, the logo, and
> the favicon of the default web-client without having to
> generate and deploy a new .war archive?
>
>
>
> There's no need to deploy a whole new .war each time (though,
> since you mentioned branding extensions earlier, perhaps you meant
> .jar).
>
>
>
> It should be possible to script the generation of a branding
> extension if the specifics are predictable (logo, icon, changes to
> the strings). Have you given writing such a script a shot?
>
>
>
> - Mike
>
>
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com
> <ma...@jlsautomation.com> and destroy all copies of this message
> and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com
> <ma...@jlsautomation.com> and destroy all copies of this message
> and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and
> destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Cyle <cy...@cogmation.com>.
If it was so easy that everyone could do it developers would be out of a
job. :)
Have a look at the jar file the user shared in this thread:
https://sourceforge.net/p/guacamole/discussion/1110834/thread/be2a6785/
Download that jar file, open it with an archive manger of your choice
and replace the images / CSS as needed. It should be pretty trivial to
automate this process in a bash script if you just need to swap out the
logo and favicon.
But I don't think you can replace assets on the fly, this extension
needs to be incorporated into the build process. I trust you know how to
build guacamole from source? You're using v9.10 after all.
On 2016-12-29 01:16 PM, Hawkins, Richard wrote:
> I have read this 20 times, I am not a programmer and I really don't know what any of this means. How about a Dummy guide for people like me.
> I am running 9.10 and it is working fine.. easy as pie.. I just can't seem to wrap my head around the branding ext.
>
> Love the Guac!!
>
>
> -----Original Message-----
> From: Mike Jumper [mailto:mike.jumper@guac-dev.org]
> Sent: Thursday, December 29, 2016 1:07 PM
> To: Chris Cook
> Cc: user@guacamole.incubator.apache.org
> Subject: Re: Scripted Branding
>
> There is some basic documentation covering the layout of extensions with respect to theming here, though please beware this should be considered a draft until the IPMC vote regarding 0.9.10-incubating
> (hopefully) passes:
>
> http://guacamole.incubator.apache.org/doc/0.9.10-incubating/gug/guacamole-ext.html#ext-file-format
>
> A Guacamole extension is just a .jar file containing a guac-manifest.json along with anything else your extension uses (see above). In the case of an extension which does nothing more than theming/branding, the only other things within the .jar will be the CSS, HTML, images, etc. you need.
>
> - Mike
>
>
> On Thu, Dec 29, 2016 at 7:50 AM, Chris Cook <co...@jlsautomation.com> wrote:
>> Is there any guidance anywhere that I can refer to on this? Still
>> looking for the answer\u2026
>>
>>
>>
>> From: Chris Cook
>> Sent: Friday, October 21, 2016 2:14 PM
>> To: 'user@guacamole.incubator.apache.org'; 'mike.jumper@guac-dev.org'
>> Subject: RE: Scripted Branding
>>
>>
>>
>> Anything?
>>
>>
>>
>> From: Chris Cook [mailto:cookcj@jlsautomation.com]
>> Sent: Monday, October 17, 2016 9:24 PM
>> To: user@guacamole.incubator.apache.org
>> Subject: RE: Scripted Branding
>>
>>
>>
>> Sorry about the brevity of my earlier response; my better-half and I
>> were entertaining a new client - one who is very keen on implementing
>> and experimenting with a Guac based tablet/mobile HMI infrastructure
>> within his factory...
>>
>>
>>
>> The logos and the favicons, should both be fixed assets somewhere and
>> should be fairly easy to copy over via script within a BASH
>> environment, following the platform installation/build-out; something
>> like the following should do the trick:
>>
>> Logo Copyover:
>> cp /media/installationID/logo.png
>> /guacamole_fixed-asset_directory/logo_whatever.png
>>
>> Favicon Copyover:
>> cp /media/installationID/favicon.png
>> /guacamole_fixed-asset_directory/favicon_whatever.png
>>
>> The issue with this scripting methodology is knowing where the fixed
>> assets are located within the default file structure... If you could
>> provide some illumination as to the path of these static assets, that would be awesome.
>>
>> Changing the webapp display name and the browser tab display names
>> will be a little more complicated as they are both supposedly
>> generated by a .css file somewhere. If this .css file is a static
>> asset, where is it located? If this .css file is dynamically
>> generated, what generates it and how can I edit it to accept a one-time user entry to establish an application name?
>>
>> To be clear, the project I am working on is based upon a fixed/static
>> and non-updating, configuration-fixed, and revision-controlled
>> appliance build model - i.e. my company builds and installs the
>> appliance within a system which will then be revision-fixed. If
>> requested/required, I or another engineer would update the core
>> platform, fault test the new core platform, press a new distribution
>> image, and then update/upgrade the production system as specifically requested/contracted.
>>
>> As such, I am not concerned about an end-client initiated
>> update/upgrade event as my end-client user will not have the ability
>> to independently perform such an operation without the involvement of
>> either myself or one the engineers that works with/for me.
>>
>> ________________________________
>>
>> From: Chris Cook [cookcj@jlsautomation.com]
>> Sent: Monday, October 17, 2016 7:14 PM
>> To: user@guacamole.incubator.apache.org
>> Subject: Re: Scripted Branding
>>
>> Mike,
>>
>>
>>
>> Thanks for your response. If I am understanding you correctly, I can
>> use a BASH script that includes functions like CAT or an ECHO pipe to
>> write out an installation specific .jar to the guacamole-home folder?
>>
>> Sent from my iPhone
>>
>>
>> On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org> wrote:
>>
>> On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook
>> <co...@jlsautomation.com>
>> wrote:
>>
>> Greetings,
>>
>> I am currently reviewing Guacamole for inclusion in an IIoT platform
>> for industrial equipment - to allow for operator interface access via webpage.
>>
>> Both I and my team LOVE the default Guac 0.9.9 webapp!
>>
>>
>>
>> Thanks!
>>
>>
>>
>> However, we have one hurtle that we need some help overcoming... We
>> are estimating approx. 100 uniquely branded deployments every year.
>> As such, generating a deployment specific branding extension for each
>> and every deployment would become rather cumbersome very quickly.
>>
>>
>>
>> Branding extensions are the intended way to achieve this. The idea was
>> that by encapsulating such changes within an extension, branding
>> changes could remain stable across upgrades, thus making things more
>> convenient and doing away with the need to patch the webapp itself.
>>
>>
>>
>> Is there a way to change the application name, the logo, and the
>> favicon of the default web-client without having to generate and
>> deploy a new .war archive?
>>
>>
>>
>> There's no need to deploy a whole new .war each time (though, since
>> you mentioned branding extensions earlier, perhaps you meant .jar).
>>
>>
>>
>> It should be possible to script the generation of a branding extension
>> if the specifics are predictable (logo, icon, changes to the strings).
>> Have you given writing such a script a shot?
>>
>>
>>
>> - Mike
>>
>>
>>
>> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
>> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
>> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
>> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
>> the intended recipient or the employee or agent responsible for
>> delivering the message to the intended recipient, you are hereby
>> notified any dissemination, distribution or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, please notify us immediately by replying to
>> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
>>
>> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
>> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
>> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
>> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
>> the intended recipient or the employee or agent responsible for
>> delivering the message to the intended recipient, you are hereby
>> notified any dissemination, distribution or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, please notify us immediately by replying to
>> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
>>
>> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
>> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
>> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
>> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
>> the intended recipient or the employee or agent responsible for
>> delivering the message to the intended recipient, you are hereby
>> notified any dissemination, distribution or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, please notify us immediately by replying to
>> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
RE: Scripted Branding
Posted by "Hawkins, Richard" <ri...@medctrbarbour.org>.
I have read this 20 times, I am not a programmer and I really don't know what any of this means. How about a Dummy guide for people like me.
I am running 9.10 and it is working fine.. easy as pie.. I just can't seem to wrap my head around the branding ext.
Love the Guac!!
-----Original Message-----
From: Mike Jumper [mailto:mike.jumper@guac-dev.org]
Sent: Thursday, December 29, 2016 1:07 PM
To: Chris Cook
Cc: user@guacamole.incubator.apache.org
Subject: Re: Scripted Branding
There is some basic documentation covering the layout of extensions with respect to theming here, though please beware this should be considered a draft until the IPMC vote regarding 0.9.10-incubating
(hopefully) passes:
http://guacamole.incubator.apache.org/doc/0.9.10-incubating/gug/guacamole-ext.html#ext-file-format
A Guacamole extension is just a .jar file containing a guac-manifest.json along with anything else your extension uses (see above). In the case of an extension which does nothing more than theming/branding, the only other things within the .jar will be the CSS, HTML, images, etc. you need.
- Mike
On Thu, Dec 29, 2016 at 7:50 AM, Chris Cook <co...@jlsautomation.com> wrote:
> Is there any guidance anywhere that I can refer to on this? Still
> looking for the answer…
>
>
>
> From: Chris Cook
> Sent: Friday, October 21, 2016 2:14 PM
> To: 'user@guacamole.incubator.apache.org'; 'mike.jumper@guac-dev.org'
> Subject: RE: Scripted Branding
>
>
>
> Anything?
>
>
>
> From: Chris Cook [mailto:cookcj@jlsautomation.com]
> Sent: Monday, October 17, 2016 9:24 PM
> To: user@guacamole.incubator.apache.org
> Subject: RE: Scripted Branding
>
>
>
> Sorry about the brevity of my earlier response; my better-half and I
> were entertaining a new client - one who is very keen on implementing
> and experimenting with a Guac based tablet/mobile HMI infrastructure
> within his factory...
>
>
>
> The logos and the favicons, should both be fixed assets somewhere and
> should be fairly easy to copy over via script within a BASH
> environment, following the platform installation/build-out; something
> like the following should do the trick:
>
> Logo Copyover:
> cp /media/installationID/logo.png
> /guacamole_fixed-asset_directory/logo_whatever.png
>
> Favicon Copyover:
> cp /media/installationID/favicon.png
> /guacamole_fixed-asset_directory/favicon_whatever.png
>
> The issue with this scripting methodology is knowing where the fixed
> assets are located within the default file structure... If you could
> provide some illumination as to the path of these static assets, that would be awesome.
>
> Changing the webapp display name and the browser tab display names
> will be a little more complicated as they are both supposedly
> generated by a .css file somewhere. If this .css file is a static
> asset, where is it located? If this .css file is dynamically
> generated, what generates it and how can I edit it to accept a one-time user entry to establish an application name?
>
> To be clear, the project I am working on is based upon a fixed/static
> and non-updating, configuration-fixed, and revision-controlled
> appliance build model - i.e. my company builds and installs the
> appliance within a system which will then be revision-fixed. If
> requested/required, I or another engineer would update the core
> platform, fault test the new core platform, press a new distribution
> image, and then update/upgrade the production system as specifically requested/contracted.
>
> As such, I am not concerned about an end-client initiated
> update/upgrade event as my end-client user will not have the ability
> to independently perform such an operation without the involvement of
> either myself or one the engineers that works with/for me.
>
> ________________________________
>
> From: Chris Cook [cookcj@jlsautomation.com]
> Sent: Monday, October 17, 2016 7:14 PM
> To: user@guacamole.incubator.apache.org
> Subject: Re: Scripted Branding
>
> Mike,
>
>
>
> Thanks for your response. If I am understanding you correctly, I can
> use a BASH script that includes functions like CAT or an ECHO pipe to
> write out an installation specific .jar to the guacamole-home folder?
>
> Sent from my iPhone
>
>
> On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook
> <co...@jlsautomation.com>
> wrote:
>
> Greetings,
>
> I am currently reviewing Guacamole for inclusion in an IIoT platform
> for industrial equipment - to allow for operator interface access via webpage.
>
> Both I and my team LOVE the default Guac 0.9.9 webapp!
>
>
>
> Thanks!
>
>
>
> However, we have one hurtle that we need some help overcoming... We
> are estimating approx. 100 uniquely branded deployments every year.
> As such, generating a deployment specific branding extension for each
> and every deployment would become rather cumbersome very quickly.
>
>
>
> Branding extensions are the intended way to achieve this. The idea was
> that by encapsulating such changes within an extension, branding
> changes could remain stable across upgrades, thus making things more
> convenient and doing away with the need to patch the webapp itself.
>
>
>
> Is there a way to change the application name, the logo, and the
> favicon of the default web-client without having to generate and
> deploy a new .war archive?
>
>
>
> There's no need to deploy a whole new .war each time (though, since
> you mentioned branding extensions earlier, perhaps you meant .jar).
>
>
>
> It should be possible to script the generation of a branding extension
> if the specifics are predictable (logo, icon, changes to the strings).
> Have you given writing such a script a shot?
>
>
>
> - Mike
>
>
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF
> THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN
> INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
> DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not
> the intended recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Mike Jumper <mi...@guac-dev.org>.
There is some basic documentation covering the layout of extensions
with respect to theming here, though please beware this should be
considered a draft until the IPMC vote regarding 0.9.10-incubating
(hopefully) passes:
http://guacamole.incubator.apache.org/doc/0.9.10-incubating/gug/guacamole-ext.html#ext-file-format
A Guacamole extension is just a .jar file containing a
guac-manifest.json along with anything else your extension uses (see
above). In the case of an extension which does nothing more than
theming/branding, the only other things within the .jar will be the
CSS, HTML, images, etc. you need.
- Mike
On Thu, Dec 29, 2016 at 7:50 AM, Chris Cook <co...@jlsautomation.com> wrote:
> Is there any guidance anywhere that I can refer to on this? Still looking
> for the answer…
>
>
>
> From: Chris Cook
> Sent: Friday, October 21, 2016 2:14 PM
> To: 'user@guacamole.incubator.apache.org'; 'mike.jumper@guac-dev.org'
> Subject: RE: Scripted Branding
>
>
>
> Anything?
>
>
>
> From: Chris Cook [mailto:cookcj@jlsautomation.com]
> Sent: Monday, October 17, 2016 9:24 PM
> To: user@guacamole.incubator.apache.org
> Subject: RE: Scripted Branding
>
>
>
> Sorry about the brevity of my earlier response; my better-half and I were
> entertaining a new client - one who is very keen on implementing and
> experimenting with a Guac based tablet/mobile HMI infrastructure within his
> factory...
>
>
>
> The logos and the favicons, should both be fixed assets somewhere and should
> be fairly easy to copy over via script within a BASH environment, following
> the platform installation/build-out; something like the following should do
> the trick:
>
> Logo Copyover:
> cp /media/installationID/logo.png
> /guacamole_fixed-asset_directory/logo_whatever.png
>
> Favicon Copyover:
> cp /media/installationID/favicon.png
> /guacamole_fixed-asset_directory/favicon_whatever.png
>
> The issue with this scripting methodology is knowing where the fixed assets
> are located within the default file structure... If you could provide some
> illumination as to the path of these static assets, that would be awesome.
>
> Changing the webapp display name and the browser tab display names will be a
> little more complicated as they are both supposedly generated by a .css file
> somewhere. If this .css file is a static asset, where is it located? If
> this .css file is dynamically generated, what generates it and how can I
> edit it to accept a one-time user entry to establish an application name?
>
> To be clear, the project I am working on is based upon a fixed/static and
> non-updating, configuration-fixed, and revision-controlled appliance build
> model - i.e. my company builds and installs the appliance within a system
> which will then be revision-fixed. If requested/required, I or another
> engineer would update the core platform, fault test the new core platform,
> press a new distribution image, and then update/upgrade the production
> system as specifically requested/contracted.
>
> As such, I am not concerned about an end-client initiated update/upgrade
> event as my end-client user will not have the ability to independently
> perform such an operation without the involvement of either myself or one
> the engineers that works with/for me.
>
> ________________________________
>
> From: Chris Cook [cookcj@jlsautomation.com]
> Sent: Monday, October 17, 2016 7:14 PM
> To: user@guacamole.incubator.apache.org
> Subject: Re: Scripted Branding
>
> Mike,
>
>
>
> Thanks for your response. If I am understanding you correctly, I can use a
> BASH script that includes functions like CAT or an ECHO pipe to write out an
> installation specific .jar to the guacamole-home folder?
>
> Sent from my iPhone
>
>
> On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org> wrote:
>
> On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>
> wrote:
>
> Greetings,
>
> I am currently reviewing Guacamole for inclusion in an IIoT platform for
> industrial equipment - to allow for operator interface access via webpage.
>
> Both I and my team LOVE the default Guac 0.9.9 webapp!
>
>
>
> Thanks!
>
>
>
> However, we have one hurtle that we need some help overcoming... We are
> estimating approx. 100 uniquely branded deployments every year. As such,
> generating a deployment specific branding extension for each and every
> deployment would become rather cumbersome very quickly.
>
>
>
> Branding extensions are the intended way to achieve this. The idea was that
> by encapsulating such changes within an extension, branding changes could
> remain stable across upgrades, thus making things more convenient and doing
> away with the need to patch the webapp itself.
>
>
>
> Is there a way to change the application name, the logo, and the favicon of
> the default web-client without having to generate and deploy a new .war
> archive?
>
>
>
> There's no need to deploy a whole new .war each time (though, since you
> mentioned branding extensions earlier, perhaps you meant .jar).
>
>
>
> It should be possible to script the generation of a branding extension if
> the specifics are predictable (logo, icon, changes to the strings). Have you
> given writing such a script a shot?
>
>
>
> - Mike
>
>
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE
> INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION
> THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
> LAW. If the reader of this message is not the intended recipient or the
> employee or agent responsible for delivering the message to the intended
> recipient, you are hereby notified any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy
> all copies of this message and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE
> INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION
> THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
> LAW. If the reader of this message is not the intended recipient or the
> employee or agent responsible for delivering the message to the intended
> recipient, you are hereby notified any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy
> all copies of this message and any attachments. Thank you.
>
> THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE
> INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION
> THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
> LAW. If the reader of this message is not the intended recipient or the
> employee or agent responsible for delivering the message to the intended
> recipient, you are hereby notified any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by replying to
> this message or by sending an e-mail to info@jlsautomation.com and destroy
> all copies of this message and any attachments. Thank you.
RE: Scripted Branding
Posted by Chris Cook <co...@jlsautomation.com>.
Is there any guidance anywhere that I can refer to on this? Still looking for the answer...
From: Chris Cook
Sent: Friday, October 21, 2016 2:14 PM
To: 'user@guacamole.incubator.apache.org'; 'mike.jumper@guac-dev.org'
Subject: RE: Scripted Branding
Anything?
From: Chris Cook [mailto:cookcj@jlsautomation.com]
Sent: Monday, October 17, 2016 9:24 PM
To: user@guacamole.incubator.apache.org<ma...@guacamole.incubator.apache.org>
Subject: RE: Scripted Branding
Sorry about the brevity of my earlier response; my better-half and I were entertaining a new client - one who is very keen on implementing and experimenting with a Guac based tablet/mobile HMI infrastructure within his factory...
The logos and the favicons, should both be fixed assets somewhere and should be fairly easy to copy over via script within a BASH environment, following the platform installation/build-out; something like the following should do the trick:
Logo Copyover:
cp /media/installationID/logo.png /guacamole_fixed-asset_directory/logo_whatever.png
Favicon Copyover:
cp /media/installationID/favicon.png /guacamole_fixed-asset_directory/favicon_whatever.png
The issue with this scripting methodology is knowing where the fixed assets are located within the default file structure... If you could provide some illumination as to the path of these static assets, that would be awesome.
Changing the webapp display name and the browser tab display names will be a little more complicated as they are both supposedly generated by a .css file somewhere. If this .css file is a static asset, where is it located? If this .css file is dynamically generated, what generates it and how can I edit it to accept a one-time user entry to establish an application name?
To be clear, the project I am working on is based upon a fixed/static and non-updating, configuration-fixed, and revision-controlled appliance build model - i.e. my company builds and installs the appliance within a system which will then be revision-fixed. If requested/required, I or another engineer would update the core platform, fault test the new core platform, press a new distribution image, and then update/upgrade the production system as specifically requested/contracted.
As such, I am not concerned about an end-client initiated update/upgrade event as my end-client user will not have the ability to independently perform such an operation without the involvement of either myself or one the engineers that works with/for me.
________________________________
From: Chris Cook [cookcj@jlsautomation.com]
Sent: Monday, October 17, 2016 7:14 PM
To: user@guacamole.incubator.apache.org<ma...@guacamole.incubator.apache.org>
Subject: Re: Scripted Branding
Mike,
Thanks for your response. If I am understanding you correctly, I can use a BASH script that includes functions like CAT or an ECHO pipe to write out an installation specific .jar to the guacamole-home folder?
Sent from my iPhone
On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org>> wrote:
On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>> wrote:
Greetings,
I am currently reviewing Guacamole for inclusion in an IIoT platform for industrial equipment - to allow for operator interface access via webpage.
Both I and my team LOVE the default Guac 0.9.9 webapp!
Thanks!
However, we have one hurtle that we need some help overcoming... We are estimating approx. 100 uniquely branded deployments every year. As such, generating a deployment specific branding extension for each and every deployment would become rather cumbersome very quickly.
Branding extensions are the intended way to achieve this. The idea was that by encapsulating such changes within an extension, branding changes could remain stable across upgrades, thus making things more convenient and doing away with the need to patch the webapp itself.
Is there a way to change the application name, the logo, and the favicon of the default web-client without having to generate and deploy a new .war archive?
There's no need to deploy a whole new .war each time (though, since you mentioned branding extensions earlier, perhaps you meant .jar).
It should be possible to script the generation of a branding extension if the specifics are predictable (logo, icon, changes to the strings). Have you given writing such a script a shot?
- Mike
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com<ma...@jlsautomation.com> and destroy all copies of this message and any attachments. Thank you.
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com<ma...@jlsautomation.com> and destroy all copies of this message and any attachments. Thank you.
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Mike Jumper <mi...@guac-dev.org>.
On Mon, Oct 17, 2016 at 6:23 PM, Chris Cook <co...@jlsautomation.com>
wrote:
> Sorry about the brevity of my earlier response; my better-half and I were
> entertaining a new client - one who is very keen on implementing and
> experimenting with a Guac based tablet/mobile HMI infrastructure within his
> factory...
>
> The logos and the favicons, should both be fixed assets somewhere and
> should be fairly easy to copy over via script within a BASH environment,
> following the platform installation/build-out; something like the following
> should do the trick:
>
> Logo Copyover:
> cp /media/installationID/logo.png /guacamole_fixed-asset_
> directory/logo_whatever.png
>
> Favicon Copyover:
> cp /media/installationID/favicon.png /guacamole_fixed-asset_
> directory/favicon_whatever.png
>
> The issue with this scripting methodology is knowing where the fixed
> assets are located within the default file structure... If you could
> provide some illumination as to the path of these static assets, that would
> be awesome.
>
>
The icons are overridden by branding extensions, with the paths being
specified within the extension manifest JSON. The properties for those seem
to be missing from the manual, but they are "smallIcon" and "largeIcon",
both pointing to an arbitrary PNG file within the extension.
Beware that testing changes to favicons can be tricky if you've already
visited the site in question. Chrome maintains a separate cache for
favicons which is not cleared even when you explicitly clear browser cache.
Other browsers may have similar issues.
Changing the webapp display name and the browser tab display names will be
> a little more complicated as they are both supposedly generated by a .css
> file somewhere.
>
Neither of these are specified via CSS.
The webapp name is defined within the translation strings, which are JSON.
Those can be overridden on a per-language basis via extensions, as well.
See the "translations" property of the extension manifest:
http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html#extension-format
The browser tab names are either the application name (defined via the
translations) or the name of the Guacamole connection (defined when the
connection was created).
If this .css file is a static asset, where is it located? If this .css
> file is dynamically generated, what generates it and how can I edit it to
> accept a one-time user entry to establish an application name?
>
>
The CSS file is both static and dynamic. While you could technically modify
the static file, the best place to do that would be within the source of
the web application itself (such that your changes are included in the
build), and we would recommend against that. Doing so would require
re-patching the Guacamole source with each release.
The CSS can be augmented via extensions in the same way as translations.
CSS files which are to be appended to the existing styles are specified via
the "css" property of the extension manifest (see link above).
To be clear, the project I am working on is based upon a fixed/static and
> non-updating, configuration-fixed, and revision-controlled appliance build
> model - i.e. my company builds and installs the appliance within a system
> which will then be revision-fixed. If requested/required, I or another
> engineer would update the core platform, fault test the new core platform,
> press a new distribution image, and then update/upgrade the production
> system as specifically requested/contracted.
>
> As such, I am not concerned about an end-client initiated update/upgrade
> event as my end-client user will not have the ability to independently
> perform such an operation without the involvement of either myself or one
> the engineers that works with/for me.
>
Even if the customers themselves will not be the ones performing the
upgrade, it will be beneficial to you to keep your changes as separate and
independent as possible, for the sake of maintainability. Having to rebase
patches and address conflicts each release will be a pain, and the branding
portion of the extension subsystem is designed with exactly this in mind.
My recommendation would be to have your script generate the extension JSON
and contents based on a few pre-defined configurables, the final output of
the script being a .jar containing the generated JSON and the provided
files.
- Mike
RE: Scripted Branding
Posted by Chris Cook <co...@jlsautomation.com>.
Sorry about the brevity of my earlier response; my better-half and I were entertaining a new client - one who is very keen on implementing and experimenting with a Guac based tablet/mobile HMI infrastructure within his factory...
The logos and the favicons, should both be fixed assets somewhere and should be fairly easy to copy over via script within a BASH environment, following the platform installation/build-out; something like the following should do the trick:
Logo Copyover:
cp /media/installationID/logo.png /guacamole_fixed-asset_directory/logo_whatever.png
Favicon Copyover:
cp /media/installationID/favicon.png /guacamole_fixed-asset_directory/favicon_whatever.png
The issue with this scripting methodology is knowing where the fixed assets are located within the default file structure... If you could provide some illumination as to the path of these static assets, that would be awesome.
Changing the webapp display name and the browser tab display names will be a little more complicated as they are both supposedly generated by a .css file somewhere. If this .css file is a static asset, where is it located? If this .css file is dynamically generated, what generates it and how can I edit it to accept a one-time user entry to establish an application name?
To be clear, the project I am working on is based upon a fixed/static and non-updating, configuration-fixed, and revision-controlled appliance build model - i.e. my company builds and installs the appliance within a system which will then be revision-fixed. If requested/required, I or another engineer would update the core platform, fault test the new core platform, press a new distribution image, and then update/upgrade the production system as specifically requested/contracted.
As such, I am not concerned about an end-client initiated update/upgrade event as my end-client user will not have the ability to independently perform such an operation without the involvement of either myself or one the engineers that works with/for me.
________________________________
From: Chris Cook [cookcj@jlsautomation.com]
Sent: Monday, October 17, 2016 7:14 PM
To: user@guacamole.incubator.apache.org
Subject: Re: Scripted Branding
Mike,
Thanks for your response. If I am understanding you correctly, I can use a BASH script that includes functions like CAT or an ECHO pipe to write out an installation specific .jar to the guacamole-home folder?
Sent from my iPhone
On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org>> wrote:
On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>> wrote:
Greetings,
I am currently reviewing Guacamole for inclusion in an IIoT platform for industrial equipment - to allow for operator interface access via webpage.
Both I and my team LOVE the default Guac 0.9.9 webapp!
Thanks!
However, we have one hurtle that we need some help overcoming... We are estimating approx. 100 uniquely branded deployments every year. As such, generating a deployment specific branding extension for each and every deployment would become rather cumbersome very quickly.
Branding extensions are the intended way to achieve this. The idea was that by encapsulating such changes within an extension, branding changes could remain stable across upgrades, thus making things more convenient and doing away with the need to patch the webapp itself.
Is there a way to change the application name, the logo, and the favicon of the default web-client without having to generate and deploy a new .war archive?
There's no need to deploy a whole new .war each time (though, since you mentioned branding extensions earlier, perhaps you meant .jar).
It should be possible to script the generation of a branding extension if the specifics are predictable (logo, icon, changes to the strings). Have you given writing such a script a shot?
- Mike
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Chris Cook <co...@jlsautomation.com>.
Mike,
Thanks for your response. If I am understanding you correctly, I can use a BASH script that includes functions like CAT or an ECHO pipe to write out an installation specific .jar to the guacamole-home folder?
Sent from my iPhone
On Oct 17, 2016, at 18:56, Mike Jumper <mi...@guac-dev.org>> wrote:
On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>> wrote:
Greetings,
I am currently reviewing Guacamole for inclusion in an IIoT platform for industrial equipment - to allow for operator interface access via webpage.
Both I and my team LOVE the default Guac 0.9.9 webapp!
Thanks!
However, we have one hurtle that we need some help overcoming... We are estimating approx. 100 uniquely branded deployments every year. As such, generating a deployment specific branding extension for each and every deployment would become rather cumbersome very quickly.
Branding extensions are the intended way to achieve this. The idea was that by encapsulating such changes within an extension, branding changes could remain stable across upgrades, thus making things more convenient and doing away with the need to patch the webapp itself.
Is there a way to change the application name, the logo, and the favicon of the default web-client without having to generate and deploy a new .war archive?
There's no need to deploy a whole new .war each time (though, since you mentioned branding extensions earlier, perhaps you meant .jar).
It should be possible to script the generation of a branding extension if the specifics are predictable (logo, icon, changes to the strings). Have you given writing such a script a shot?
- Mike
THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message or by sending an e-mail to info@jlsautomation.com and destroy all copies of this message and any attachments. Thank you.
Re: Scripted Branding
Posted by Mike Jumper <mi...@guac-dev.org>.
On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <co...@jlsautomation.com>
wrote:
> Greetings,
>
> I am currently reviewing Guacamole for inclusion in an IIoT platform for
> industrial equipment - to allow for operator interface access via webpage.
>
> Both I and my team LOVE the default Guac 0.9.9 webapp!
>
>
Thanks!
However, we have one hurtle that we need some help overcoming... We are
> estimating approx. 100 uniquely branded deployments every year. As such,
> generating a deployment specific branding extension for each and every
> deployment would become rather cumbersome very quickly.
>
Branding extensions are the intended way to achieve this. The idea was that
by encapsulating such changes within an extension, branding changes could
remain stable across upgrades, thus making things more convenient and doing
away with the need to patch the webapp itself.
Is there a way to change the application name, the logo, and the favicon of
> the default web-client without having to generate and deploy a new .war
> archive?
>
>
There's no need to deploy a whole new .war each time (though, since you
mentioned branding extensions earlier, perhaps you meant .jar).
It should be possible to script the generation of a branding extension if
the specifics are predictable (logo, icon, changes to the strings). Have
you given writing such a script a shot?
- Mike