Re: Installing Guacamole 1.5.5 tomcat listener failed to start
Hi, On 21/04/2024 06:47, My Data Belongs to Me! wrote: Hello, I am running Alma 8, and followed the these instructions to get Guacamole installed and running: https://guacamole.apache.org/doc/gug/installing-guacamole.html when things were not working (guacd would run and exit, tomcat would not unpack any wars at all), I then reviewed these https://idroot.us/install-apache-tomcat-almalinux-8/ https://idroot.us/install-apache-guacamole-almalinux-8/ Funny. I just learnt in my last thread that guacamole does not work on tomcat10. Check work in progress here [1][2] . I doubt this documentation is right. 1. https://issues.apache.org/jira/browse/GUACAMOLE-1325 2. https://github.com/apache/guacamole-client/pull/972 and I have gotten to the point where tomcat is running and reachable, the war unpacks, guacd is running, but catalina.out still reports: " 21-Apr-2024 02:29:31.065 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file 21-Apr-2024 02:29:31.088 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal Context [/guacamole] startup failed due to previous errors " I tried syslog, but this VPS doesn't appear to have that. I guess you are using systemd. Thus, you can check the logs with journalctl --system -- Willy Manga - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Installing Guacamole 1.5.5 tomcat listener failed to start
Hello,
I am running Alma 8, and followed the these instructions to get Guacamole
installed and running:
https://guacamole.apache.org/doc/gug/installing-guacamole.html
when things were not working (guacd would run and exit, tomcat would not unpack
any wars at all), I then reviewed these
https://idroot.us/install-apache-tomcat-almalinux-8/
https://idroot.us/install-apache-guacamole-almalinux-8/
and I have gotten to the point where tomcat is running and reachable, the war
unpacks, guacd is running, but catalina.out still reports:
"
21-Apr-2024 02:29:31.065 SEVERE [main]
org.apache.catalina.core.StandardContext.startInternal One or more listeners
failed to start. Full details will be found in the appropriate container log
file
21-Apr-2024 02:29:31.088 SEVERE [main]
org.apache.catalina.core.StandardContext.startInternal Context [/guacamole]
startup failed due to previous errors
"
I tried syslog, but this VPS doesn't appear to have that.
ss -tlnp reports guacd is running and listening:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 5 127.0.0.1:4822 0.0.0.0:* users:(("guacd"
Not sure where to go from here - maybe dnf -install rsyslog and restart things.
Thanks for any help you can provide.
Re: How to get client IP address ?
> > Hello Nick, > > first of all, thank you for looking into the issue. So please let me ask > this > as a real question and no offence. > None taken, perfectly fine to ask this. > Why does the project _at all_ use a rather complicated API for > authentication > instead of "outsourcing" the function into a simple called hook (call it a > script), and let this implement the wanted api to ldap, mysql, radius or > just > about anything that might be needed. This is what we already do. Yes, the entire web-based application works through a REST API, but, on the back-end, we take the REST API calls and feed them, through a set of standard interfaces, to a back-end authentication mechanism. The back-end authentication mechanisms are standardized, interchangeable and stackable - you can use one or more in combination, or you can write your own. The mechanisms can also "decorate" other ones, so that you can use a back-end mechanism (like JDBC), but extend its functionality to do something else. > Still in the end an authentication is no > more than giving parameters (like username, password, or client ip or > whatever the caller (i.e. guacamole) has) and getting the simple answer: > yes > (authenticated) or no (login failed). > This is really what the REST API does - it allows the front-end web application to 1) receive a list of requirements from the back-end authentication mechanism, 2) provide those requirements, either automatically (client IP) or by user input (username and password), 3) get an answer about whether authentication has succeeded or not, and 4) receive and process data that the client has been authorized to receive (in our case, connections, connection groups, users, groups, etc.). > If you cut off the whole process at this point the whole story gets a lot > more > flexible, as anyone can then implement his needed hook (script) for his > needs. > As mentioned above, this is exactly how it works with the authentication extensions. > You may then distribute such hooks inside the project for standard APIs > like > ldap or the like - or leave it to the users to make/find their own. > Yep, and Guacamole's design allows for exactly this - and the REST API does not get in the way of that, in fact, it makes it possible to do that without having to change the front-end web application at all. Also, none of the things you've mentioned actually address the issue you've originally raised - no matter what method you use to communicate between the web browser and the server, you still need to be able to provide the data you're interested in providing - IP address, username, and password - to the authentication system (LDAP you specifically mentioned). Unless your solution is to have the client authenticate to LDAP directly and then somehow tell the server that it is authenticated - which has a lot of security risks to it (how does the server know to trust the client when it says it authenticated successfully?) - I don't know of a way, with *LDAP* specifically, to have the client IP address be part of the authentication process, regardless of the language (PHP, ldapsearch, Java/JSP, CGI/Perl...etc.). RADIUS, as a protocol, has those things built into it - the NAS IP field within a RADIUS authentication request allows you to pass the client IP on to the RADIUS server and then allow the RADIUS server to make a determination about authentication success or failure based on that in combination with the other information asked and provided (RADIUS secret, username, password, one-time-password, etc.). So does Kerberos - in fact, Kerberos actually does exactly what is mentioned above - establishes a trusted relationship between KDC, Server/Service, and Client, such that the client can authenticate and then reliably tell the server that it should trust the client because they share information that makes it trustworthy. And so Kerberos also has a way of factoring the client system into the authentication process, in addition to the username and password. At some point I will probably take a crack at a Kerberos extension or configuration that does this, which also allows for doing very seamless authentication with no need for entering credentials if you're already logged into a client where you have a valid Kerberos ticket. If you're also just looking for a way to factor a client IP address into the authentication process, but it doesn't have to be linked directly to the username or password, there are ways to do that, as well: * Have a front-end proxy or Web Application Firewall filter based on IP address. * The 1.6.0 version of Guacamole Client will have an extension that allows for banning IP addresses that repeatedly fail authentication. This can be done, today, using something like fail2ban, but it'll be a bit more integrated and easy with the extension. * Write another authentication extension that either allows or disallows authentication based on IP address or CIDR range. * The
Re: guacd and guac-client in different hosts
Robert, You might want to look to the links that Nick posted, they will give you an idea of where progress is on this matter. Also, you are always welcome to contribute, particularly if there's an issue you see would assist the project as a whole in addition to your operation. On 21/04/24 00:30, Robert Dinse wrote: It is six years old, in computer terms this is stone age. As one who usually maintains the current distro on my servers apps with old requirements are a PITA, especially pitted against other apps that only work with the latest and perhaps not always greatest. - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: How to get client IP address ?
On Sat, 20 Apr 2024 15:52:58 -0400 Nick Couchman wrote: > > > > > > > I believe the issue that Stephan is describing is that, when the user > > logs > > > in to Guacamole, and the remote LDAP server that is authenticating the > > user > > > logs a client IP address, it should log the IP address of the browser > > (far > > > end client) and not the IP address of the Guacamole Client (tomcat) > > system. > > > I'm just trying to get clarity from Stephan on whether this is what he's > > > actually trying to do and why. > > > > > > -Nick > > > > Yes, Nick, you are exactly on the right track here. And I am really not in > > a > > logging question, but truely in the authentication process where I want to > > know the far end client. > > > > > After looking at this a bit more, I cannot find a way, at least in the > Apache LDAP API that we use, to configure a client IP or send any sort of a > message that will pass that information through to the client, so I'm not > sure how feasible this actually is. RADIUS uas the NAS IP designed > specifically for this type of scenario, but I'm not finding any sort of > feature similar to NAS IP that allows for this kind of messaging. > > -Nick Hello Nick, first of all, thank you for looking into the issue. So please let me ask this as a real question and no offence. Why does the project _at all_ use a rather complicated API for authentication instead of "outsourcing" the function into a simple called hook (call it a script), and let this implement the wanted api to ldap, mysql, radius or just about anything that might be needed. Still in the end an authentication is no more than giving parameters (like username, password, or client ip or whatever the caller (i.e. guacamole) has) and getting the simple answer: yes (authenticated) or no (login failed). If you cut off the whole process at this point the whole story gets a lot more flexible, as anyone can then implement his needed hook (script) for his needs. You may then distribute such hooks inside the project for standard APIs like ldap or the like - or leave it to the users to make/find their own. To me, designing (and coding) software since the 1980s, this is a pretty clear design decision to be taken. Regards, Stephan - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: How to get client IP address ?
> > > > I believe the issue that Stephan is describing is that, when the user > logs > > in to Guacamole, and the remote LDAP server that is authenticating the > user > > logs a client IP address, it should log the IP address of the browser > (far > > end client) and not the IP address of the Guacamole Client (tomcat) > system. > > I'm just trying to get clarity from Stephan on whether this is what he's > > actually trying to do and why. > > > > -Nick > > Yes, Nick, you are exactly on the right track here. And I am really not in > a > logging question, but truely in the authentication process where I want to > know the far end client. > > After looking at this a bit more, I cannot find a way, at least in the Apache LDAP API that we use, to configure a client IP or send any sort of a message that will pass that information through to the client, so I'm not sure how feasible this actually is. RADIUS uas the NAS IP designed specifically for this type of scenario, but I'm not finding any sort of feature similar to NAS IP that allows for this kind of messaging. -Nick
Re: guacd and guac-client in different hosts
It is six years old, in computer terms this is stone age. As one who usually maintains the current distro on my servers apps with old requirements are a PITA, especially pitted against other apps that only work with the latest and perhaps not always greatest. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874. On Sat, 20 Apr 2024, Nick Couchman wrote: Date: Sat, 20 Apr 2024 07:45:53 -0400 From: Nick Couchman Reply-To: user@guacamole.apache.org To: user@guacamole.apache.org Subject: Re: guacd and guac-client in different hosts On Sat, Apr 20, 2024 at 7:14 AM Robert Dinse wrote: Really should port to the most recent since other projects may not remain in the stone age. 1. "Stone age" is not a fair assessment - Tomcat 9 is still actively maintained with current releases (April 16, 2024 was the latest - 9.0.88), as is Java 8. 2. There's already an effort to do this: https://issues.apache.org/jira/browse/GUACAMOLE-1325 https://github.com/apache/guacamole-client/pull/972 -Nick - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: guacd and guac-client in different hosts
On Sat, Apr 20, 2024 at 7:14 AM Robert Dinse wrote: > > Really should port to the most recent since other projects may not > remain > in the stone age. > 1. "Stone age" is not a fair assessment - Tomcat 9 is still actively maintained with current releases (April 16, 2024 was the latest - 9.0.88), as is Java 8. 2. There's already an effort to do this: https://issues.apache.org/jira/browse/GUACAMOLE-1325 https://github.com/apache/guacamole-client/pull/972 -Nick
Re: guacd and guac-client in different hosts
Really should port to the most recent since other projects may not remain in the stone age. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874. On Sat, 20 Apr 2024, Willy Manga wrote: Date: Sat, 20 Apr 2024 14:48:52 +0400 From: Willy Manga Reply-To: user@guacamole.apache.org To: user@guacamole.apache.org Subject: Re: guacd and guac-client in different hosts On 20/04/2024 10:25, Alessandro Sironi wrote: Hi, Tomcat 10 is the issue, ti is not supported, you can go with T9 or T8 Regards, Alessandro Ouch.. I was not careful on the requirements. THank you. With tomcat9, it's working. -- Willy Manga - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: guacd and guac-client in different hosts
On 20/04/2024 10:25, Alessandro Sironi wrote: Hi, Tomcat 10 is the issue, ti is not supported, you can go with T9 or T8 Regards, Alessandro Ouch.. I was not careful on the requirements. THank you. With tomcat9, it's working. -- Willy Manga - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
Re: guacd and guac-client in different hosts
Hi, Tomcat 10 is the issue, ti is not supported, you can go with T9 or T8 Regards, Alessandro Inviato da iPhone > Il giorno 20 apr 2024, alle ore 05:56, Willy Manga ha > scritto: > > Hi, > > I guess it's possible to have them in different machine and I assume I'm > missing something. > > I set guacd in 1 host, set accordingly the hostname (bind_hosts) in > /etc/guacamole/guacd.conf. > > In the other host (running tomcat10 under debian12), I deployed the war file > (1.5.5) in /var/lib/tomcat10/webapps. > Tomcat deployed automatically the war file and I set the name of the guacd > server in /etc/guacamole/guacamole.properties . > > At this point if I go to http://mytomcat:8080/guacamole , I get a http 404 > error ... What did I miss please? > > > -- > Willy Manga > > - > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > - To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
