On Tue, Apr 30, 2019 at 4:27 PM Lance Gropper <
[email protected]> wrote:

> Hello Mike:
>
>
>
> That's what I originally did, then had no guacadmin user login
>

The "guacadmin" user is a user unique to the database authentication
backend. It will exist only once a database authentication backend (MySQL /
PostgreSQL / SQL Server) has been set up, same for the admin functionality.


> ... Nick Couchman install Postgresql, and that turned out to be a big
> nightmare...
>

Please try to remain respectful on this list. Everyone here, especially
Nick, is devoting their free time to try to help you and to produce the
software itself. Be patient, be respectful, refrain from personal attacks.

https://www.apache.org/foundation/policies/conduct.html
https://www.apache.org/dev/contrib-email-tips#respect

Originally, I tried 1.0.0, but it had some sort of known issue that isn't
> being fixed until 1.10.0, so I went back to 0.9.14...I can start over, but
> am afraid I would end up like I did yesterday - i.e. basically no admin
> GUI, editing XML files, etc., before I blew that away. The instructions
> need improvement - especially chapters 5 and 6. In chapter 5, for example,
> it says "GUACAMOLE_HOME is the name given to Guacamole's configuration
> directory, which is located at /etc/guacamole by default." - that
> directory does not exist if you follow the chapter 2 instructions. In
> chapter 6, I did not know that knowing how to install and configure a SQL
> server was a prerequesite for installing Guacamole. That is a bit more
> difficult than the Guacamole installation itself, and could use some
> explanation (at least minimal explanation). The guy in the link I sent does
> MySQL in about 7 steps. So what I might try to 0.9.14 under CentOS 7, built
> from source with the instructions that other guy gave for MySQL, since that
> part of it seems to be working. To make things even more difficult for me
> here, I have to go through a squid proxy server, which means custom
> settings for ftp, yum, wget, maven, and several other things just to
> complete the task. Originally, to get the machine going yesterday, I had to
> configure an identical system at home using yum --downloadonly to get the
> files, then bring them in on a USB key.
>

The manual can always stand improvement, but the totality of it is meant as
a reference. It's only the isolated content of the individual chapters that
is step-by-step. The expectation is that you will get a basic install up
and running following the installation instructions, and then come back to
the manual as you iterate on that base according to your specific needs.

I think you need to take a step back, take a breath, and look at the
overall architecture without the emotional coloring.

At it's absolute, stripped down core, you will install the following:

* Tomcat (a servlet container to run the web application)
* guacamole.war (the web application)
* guacamole-server (the union of guacd, libguac, and the various protocol
support libraries libguac-client-*)

The web application (guacamole.war) has a built-in authentication/extension
subsystem. Built into the web application itself is the "user-mapping.xml"
mechanism which is meant for easy setup / testing. It is the only
authentication mechanism that does not require an extension. The other
methods are separated into extensions such that the webapp itself does not
become monolithic. The default "user-mapping.xml" does not provide any
default users, there is no admin functionality, there is no "guacadmin",
etc. There is only what you explicitly specify in the "user-mapping.xml"
file.

Making sure the base Guacamole install works from a sheer functionality
perspective is a good idea before progressing on to more complicated
configurations. This is part of the reason "user-mapping.xml" continues to
exist. Achieving a base install like this is the purpose of those initial
installation chapters you mentioned.

Now, on to the extensions:

Guacamole's features can be augmented with extensions. This mainly centers
around authentication and allows Guacamole to delegate auth and data
storage to LDAP, MySQL, PostgreSQL, SQL Server, or some combination of
these. You extend Guacamole using these extensions and the method for doing
this is documented in the manual within chapters dedicated to each
extension.

Guacamole itself will not create files for you. The location of
GUACAMOLE_HOME is documented and logged, yes, but it will not be
specifically created by any step. It is on you to create it, same with
guacamole.properties, to satisfy the requirements of the task(s) at hand.

With all that in mind, hopefully it's clear that you can achieve what
you're trying to achieve. If there's anything above which is confusing, we
can clarify, but again - please be patient and respectful and remember
everyone here is a volunteer. You best path forward is:

* Start from scratch, one step at a time, verifying things each step of the
way.
* Once you have things testable, test them (again: user-mapping.xml is
meant for this) so you can eliminate confusion as early as possible.
* If things get confusing, you can come to us, and we will try to help.
Just be patient and respectful.

Getting frustrated when things don't go as smoothly as planned is
understandable, but you should also keep in mind that Guacamole is actively
used by millions. The documentation is thorough and we participate here on
the mailing list to assist. Just try to move systematically and
methodically, and all will work out. Difficulties/confusion as you are
having are the exception, not the rule, though they do squeak louder than
success.

- Mike

Reply via email to