thanks for the updates - see my comments inline... On Fri, May 1, 2020 at 10:25 AM Zer0Cool <melin3...@gmail.com> wrote:
> Thanks to both of you. I ended up working this out and figured I would post > back my findings in case they help others. > > -libtelnet | I gave up on this one. Does NOT seem to be in regular EPEL > repo, maybe one of the testing or something but honestly didnt push hard to > find it. Really, I have trouble thinking of a use case in which I or most > need telnet support via Guac. I am sure some may use it for particular > things, but it cant be that wide spread. > > Yeah, it isn't shocking that support for telnet is becoming harder and harder to find. Most people have ditched it in favor of SSH - like a decade ago :-). I know there are still legitimate uses for it out there, but SSH support has become pretty common. > - libwebsockets-devel | the package itself is actually in the epel-testing > (version 4.x vs 2/3.x in 3rd party repos), but has dependent packages from > CentOS's Devel repo. The major dependency being libuv. To install I used: > dnf install -y libwebsockets-devel --enablerepo=epel-testing > --enablerepo=Devel > > - libssh2 | came from epel. Should Guac move to libssh, that is in the > CentOS repo I believe. > > Yes, both RHEL and CentOS package libssh by default in EL8, now. Mike is working on implementing support for that in guacd, in his huge amount of free time these days :-). > As for Tomcat, my attempt to subtly throw shade at them for removing it may > not have translated in email. According to the RHEL 8.x release notes they > deprecated tomcat in favor of JBoss web server...which is not free, but is > based on Apache tomcat and web server. I would imagine its not in CentOS > 8.x, at least when exploring alternatives it didnt come up. Maybe the open > source base of Jboss is in CentOS, forget the name of it. In any case I > plan > to install Tomcat 9.x for my needs from the tar.gz. Not thrilled by the > seemingly greedy move on RH's part here. > > <soapbox> At the risk of starting a religious war on the mailing list, I have to defend Red Hat, here, because I don't think this is a fair characterization. I actually think that Red Hat is one of a handful of companies that have done a good job of balancing the need to make money as an organization with/against supporting Open Source initiatives (we can argue about who does it better than who, but they're on the top of the list). Every single one of Red Hat's products is available in an Open Source (aka Community) version - at least, I don't know of any exceptions to this. RHEL -> CentOS, RHV -> oVirt, Satellite -> SpaceWalk, OpenShift -> OpenShift, Ansible, etc. JBOSS is *not* an exception to this rule - I believe the Open Source equivalent is called WildFly ( https://wildfly.org/downloads/). It may be harder to find, and, obviously, RedHat is going to steer you in the direction of the subscription equivalents, because they're a business and they need to make money to survive. But, IMHO, they have earned a good reputation for support of Open Source software. Whether that sticks around as the Red Hat + IBM stuff moves forward remains to be seen - I hope so, but these things have a way of going sideways at some point in time, and only time will tell. Also, related to JBOSS, specifically, IBM has a competing product (Websphere), so it'll be interesting to see how that Java Application Server game plays out. And, lest there's any question about my defense, I do not work for Red Hat, they don't support (e.g. pay, sponsor) me, etc. In my Day Job I am a customer, so I pay them - but I'm happy to pay a company like that based on how fair I think they are in providing open source software versus charging for it. </soapbox> As far as why they'd move away from packaging Tomcat and push you toward JBOSS - well, they are a business and it is a product. Outside of that, there are other considerations - like the amount of time it takes to test and package updated versions, and Tomcat has a pretty active release schedule, so I would imagine this isn't a trivial effort for them to go through. Between that and probably looking at their data from their RHEL customers to see who's running what, I would imagine it just made the most sense from a maintainability standpoint. EL7 never really got much of an update of Tomcat after its initial release - it stuck at version 7 the whole time, while Tomcat progressed through versions 8.0, 8.5, and 9.0. And, if we're being fair, installing Tomcat from .tar.gz or .zip isn't all that difficult. Not as clean/easy as "yum install", but, still, reasonably easy, and updating it is pretty easy - probably a 3-line script to pull the latest version, make a backup copy, and extract the new version. - make | for what its worth, despite installing gcc, and in CentOS 7.x that > including make (I think) I had to explicitly install make on CentOS 8.x > > In EL7 there is a Development tools group - not sure if this carried over to EL8 - that would get you the right base packages: yum groupinstall Development\ tools > To clarify with libjpeg-turbo (LJT onward for ease) there are 2 packages. > LJT itself, which is in the CentOS repo as version 1.5.x and available from > the LJT yum repo as version 2.x.x. Likewise, LJT-devel is available in the > CentOS repos as version 1.5.x but does not seem to be packaged in the LJT > yum repo, aka they have no -devel version. > > So my questions is basically this: ljt/ljt-devel 1.5.x from CentOS OR ljt > 2.x.x from ljt repo with ljt-devel 1.5.x from CentOS (OR is it possible to > get ljt/ljt-devel 2.x.x both ?)? Put another way, any advantage to having > ljt 2.x.x with ljt-devel 1.5.x? > > No, there would be no use of having the 2.x libraries with the 1.5.x devel package - generally if you install the -devel package it will also install the runtime, and Guacamole will likely build against the 1.5.x versions. You can use ldd to verify this against the libraries. I also do not know of any additional optimizations (performance or bandwidth) with Guacamole that having the 2.x version would provide, but I haven't looked all that deep. -Nick
