Multiple issues with installation documentation #5304
Comments
|
Mike it looks like our documentation for the RPMs is missing an additional RPM repo, which I've now added to the document: Give that a go on your CentOS 7 box and that should hopefully resolve your installation issue. |
|
Sorry - no - no luck I'm afraid. Some are within a smidgeon - such as nodejs Error: Package: hootenanny-core-0.2.70-1.el7.x86_64 (hoot-release) but if anything, it seems worse. I'll include the full install below - thanks for the quick response, by the way. I'm wondering if we've done something in the other repo's, so I will double check. In the meantime, I've removed the gdal packages I previously installed and used the ones from the new repo provided. If I don't show the two long sections caused by nodejs, this is what we still have going wrong. --> Finished Dependency Resolution Error: Package: hootenanny-services-ui-0.2.70-1.el7.x86_64 (hoot-release) Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release) Full output, pre gdal removal. [root@vrdev ~]# yum-config-manager --add-repo https://geoint-deps.s3.amazonaws.com/el7/stable/geoint-deps.repo
|
|
My apols, had to re-add the hoot-deps.repo. Now, other than the strangeness with node, we are down to the following. --> Finished Dependency Resolution I suspect we could live with that, just not sure what's up with nodejs |
|
Final one for the night - I've tried to use nvm to install 14.16.1, which seems to have worked, but the subsequent hoot install doesn't seem to see it. |
|
Node was a tricky thing for us. We actually had to compile our own version of it because it is distributed without dynamic libraries. The node executable has all of the libraries statically linked into it which wouldn't do for us since we need to dynamically link to the node and v8 libraries. That is why using If you look at the vagrant install script you'll see the list of steps to setup Hootenanny using the release RPMs. |
|
Hootenanny summary Situation as I see it, please accept my apols if I'm wrong. I'm assuming we are using Centos 7 putting Docker aside, there are 2 current methods of installing the s/w, and two platform types to install on. We can install via RPM, with a choice of a stable or current build. Information on previous versions not readily available, The s/w can also be compiled from scratch. Platform type can be a physical server, or Virtualbox VM running via Vagrant. Hoot boxes are available in Vagrant Cloud. Of the 4 options available, install via RPM appears to fail on both platforms due to dependencies, primarily due to Nodejs. We intend to try the Make route on our Physical server, to see if its possible. I'd like to suggest that a clean install via both methods should be carried out, to see if there are any other steps missing from the documentation, and to see if the dependencies can be ironed out to allow an install via RPM. Many thanks, Mike |
|
Mike: The RPM installs should work on bare metal and via VM. With We just tried it this morning and it came up successfully. I also created an "empty" CentOS7 VM in VirtualBox using a minimal install prebuilt VM. (Further down the page gives you instructions on how to setup the VM and the user/pass to login.) Once I setup the VM and started it up. I ran the following commands: There were no issues installing Hootenanny with either of those two options. I suspect that your issue lies in the fact that you already have a version of NodeJS installed (nodejs-8.17.0-1nodesource.x86_64 from nodesource : from above). Like I said, Hootenanny requires a very specific version of NodeJS that is built with the shared libraries. This isn't found on nodesource (or anywhere else that I found out on the internet) and therefore we had to create our own. Older versions of NodeJS used to provide dynamic libraries but it has been years since they stopped. If you have other programs on the machine that require NodeJS, the version we provide will work as it provides the |
|
Hi, I will try what you suggested. However, I've tried doing the RPM's after removing nodejs and clearing the cache, and run into the same issue, whichever version I try to install. (I've cracked the versioning with yum, and have tried to go back over 10 versions) The software always wants a version that is close, but unavailable, even looking in the hoot-deps repo, where I would expect to find them, That goes for the versions built on 14.16.1 or 8.9.3. hoot-deps currently has 14.16.1-1, and 8.9.3-2 and thus fails. If you happen to have a way round this, it would be nice to know. At one stage I had this down to just the 2 packages preventing the install, however, even if we work round nodejs, for later versions, this might also be an issue. Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release) What might work best, is if you can point me in the right direction from this point. I've cloned the software into a hoot subdir on the physical server using the command shown below, from your suggestion above. git clone https://github.com/ngageoint/hootenanny hoot which option do I take to proceed from this point ? Thanks for you assistance so far. I'm going to take a backup of the Virtualbox vm, and have another go with that as well. Mike |
|
Quick update I took option 1 - cleared out my existing setup, git cloned using https + Windows options, and then built a vbox using vagrant up hoot_centos7_rpm. All the build dependencies were clear, but I have one issue. How do you pass the NIGHTLY=no as an env variable when using Windows 10 ? I couldn't get the vagrant command to work with it as a prefix, and can see the effect from this line hoot_centos7_rpm: ### Adding the Hoot nightly master repo ### So built the box without it. We are going to repeat on the better spec'd laptop, but might redo once we know how, as the build process this way seems much more rapid. As a by the by, this build brought down the following rpm's from hoot-deps with no problems The dependency list for nodejs is very small, I can provide it if it helps. Mike |
|
More good news, I've played around with packages, repos and caches on our physical dev box, and finally cracked an install of the current master build. The only issue appears to be with authorisation - which I fixed on virtualbox by altering the setup to point to port 8888. Here, port 8080 is in use, but the oauth request is failing to return - any suggestions ? |
|
I think using the nightly master RPMs is fine for your test environment. We use them in our ci pipeline. For the |
|
Many thanks - it's not our day I don't think. My colleague, who has the better machine, may have run into issues with Vbox and Windows 11. It's just not behaving the same way as my Windows 10 box, all Virtualbox issues but preventing progress. I suspect my attempts to get this running on a real Centos 7 server are also doomed, at least remotely, due to having to access it from home through a vpn. That's also our problem, will drop an update if we can solve either issue. Replacing with an internal ip doesn't seem to work, not that I'm surprised. Thanks |
|
Is your Hoot vm on your local host or is this a remote vm or bare metal server? The web browser is using the |
|
Morning Brian, The good news is that in the office, once I make the change from localhost to ip address, we get a working interface. That's probably not going to fly for our remote workers, but that's not your problem, and I can deal with that in either AWS or a hosted server. However, any attempt to run hoot just fails completely. I was hoping to run some of the inbuilt tests, but they, and even hoot help, all fail as follows. [root@vrdev hoot]# source ./SetupEnv.sh [root@vrdev hoot]# hoot help Is there something truly obvious that I'm missing here ? Thanks Mike |
|
on server restart, we get 6 of these in 4 seconds. Have to do some tweaks to get the crash dumps, if that would help. Apr 1 12:08:43 vrdev kernel: hoot.bin[8802]: segfault at 7f8d255fbd00 ip 00007f8d1aa6ec10 sp 00007ffecc2c93a0 error 6 in libSFCGAL.so.1.3.1[7f8d1a683000+894000] |
|
I have crash dump info - what would you need to help - is this info or do you need everything? reason: hoot.bin killed by SIGSEGV core_backtrace: |
|
I realize now there might be a source of confusion in the So, the documented commands like I was able to get the HootTest to run, but not without some fixes (which leads me to believe we don't run them from an rpm install often). If you exit and re-ssh to the server you should confirm that I saw an error about a missing josm jar that hoot uses for validation checks. We will need to fix this so that dependency is installed by the rpm. Until then, a manual fix that will leverage the full hoot source tree in the shared dir Then you should be able to run |
|
Hi Brian, I think we might be getting our lines crossed - so here goes. To remove any issues with previous software installs, I've built a new Centos 7.9 server in AWS Then I've followed the instructions give here https://github.com/ngageoint/hootenanny-rpms/blob/master/docs/install.md on how to do a release from the S3 rpms. I may have confused both you and myself by doing a git clone beforehand. The only additions necessary were the following. yum-config-manager --add-repo https://geoint-deps.s3.amazonaws.com/el7/stable/geoint-deps.repo software then installed using yum install -y hootenanny-autostart giving me the following [root@ip-172-31-22-59 conf]# rpm -qa |grep hoot I have no target directory for hoot-josm in the git cloned area, so the above fix doesn't fly for me. I have the following services running postgres 9302 1 0 15:19 ? 00:00:00 /usr/pgsql-13/bin/postmaster -D /var/lib/pgsql/13/data/ I'm not sure that we didn't have a security group issue with Postgres, so I've fixed that, going to reboot and see where we get to. No Luck - HOOT_HOME is correctly defined, but HootTest --quick fails as before. Fun isn't it. I might give up for the weekend after that. My colleague is trying out slightly older versions of vbox on W11, to see if they behave a bit better, will let you know how we get on. And no, they don't work either, apparently - just as vm's that is. Mike |
|
Ok, so no vagrant in this setup. We tried the steps you documented and indeed got a seg fault from the HootTest command. I'm not exactly sure what the culprit is, but our RPM install doc needed more updates to reflect our Give these install steps a try on a fresh image and we'll see what difference it makes. |
|
So, the bad news is - no apparent difference at all. Both Master and Release method crash while the server restarts. Installation and removal is now quite smooth, with the exception of requiring a couple of setsebool ops. setsebool -P tomcat_can_network_connect_db on To allow DB connections etc. UI works ok, but not other parts. I'd noticed that the translators don't come up, amongst other things. First sign of a problem comes here - from the messages file Apr 5 07:31:53 ip-172-31-22-59 server: 05-Apr-2022 07:31:53.068 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager First error here Apr 5 07:32:02 ip-172-31-22-59 server: 2022-04-05 07:32:02,762 INFO ElementMergeServiceResource:122 - Element Merge Service started and then Apr 5 07:32:04 ip-172-31-22-59 server: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) In total, there are 2 --tag-mergers and 4 --way-snap-criteria errors on startup, and it all ends with a message saying Server Startup in 13636 ms. Any attempt at a hoot test fails with a seg fault, as before. as an fyi, from a clean C7 AWS install - plus update, 247 packages are installed by yum. As my last attempt was with the Master branch, these are the installed hootenanny packages. Apr 04 20:42:46 Installed: hootenanny-core-deps-0.2.71-0.8.20220404.46a04b2.el7.noarch Suggestions appreciated. Mike |
|
I'm not sure what the problem could be. Here is an ami with the rpms installed (and the missing josm jar included) In running and some warnings about tests running longer than expected but not consistently. Maybe give that ami a try. |
|
Gents, Just a quick update that the provided ami worked really well, and the subsequent demo was well received. Have a fun weekend, and then perhaps we could talk outside the issue forum, but for now, many thanks for you kind assistance. Cheers, Mike |
Current Installation instructions are unclear, and the product fails to install at present with dependency issues.
In attempting to help our companies cartographer to evaluate Hootenanny, we have both tried multiple ways of installing and running the software on Centos 7 based physical and virtual machines.
These are some of the current issues
On a physical intel server, 8 cores and 32 gb Mem, running Centos 7.9.2009 and following these instructions
https://github.com/ngageoint/hootenanny-rpms/blob/master/docs/install.md
Setting up to use the S3 hosted repos, fails with multiple dependency issues, using el7/release repo
eg
--> Finished Dependency Resolution
Error: Package: hootenanny-core-0.2.70-1.el7.x86_64 (hoot-release)
Requires: libgeocoding.so.8()(64bit)
Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release)
Requires: gdal-python-tools = 3.2.3
Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release)
Requires: geos = 3.9.2
Available: geos-3.4.2-2.el7.x86_64 (epel)
geos = 3.4.2-2.el7
Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release)
Requires: gdal-devel = 3.2.3
Available: gdal-devel-1.11.4-3.el7.x86_64 (epel)
gdal-devel = 1.11.4-3.el7
Error: Package: hootenanny-core-deps-0.2.70-1.el7.noarch (hoot-release)
Requires: libpostal-data
Error: Package: hootenanny-services-ui-0.2.70-1.el7.x86_64 (hoot-release)
Requires: tomcat8 < 8.6.0
Error: Package: hootenanny-services-ui-0.2.70-1.el7.x86_64 (hoot-release)
Requires: tomcat8 >= 8.5.0
Error: Package: hootenanny-core-0.2.70-1.el7.x86_64 (hoot-release)
Requires: nodejs = 1:14.16.1
Installed: 2:nodejs-8.17.0-1nodesource.x86_64 (@nodesource)
nodejs = 2:8.17.0-1nodesource
Available: 1:nodejs-16.14.1-1.el7.x86_64 (epel)
nodejs = 1:16.14.1-1.el7
This is despite installing the gdal 3.2.3 packages separately.
The section above this, Local RPMs, gives no indication of how to download and build the RPMS's, nor is there an accessible list of previous versions.
Moving on, we attempted to find a workaround by downloading a previously prepared vbox from Vagrant Cloud.
Bearing in mind, that while my colleague has a reasonably spec for his laptop, mine is a 5 year old machine with 8 GB of memory, which takes quite a while to build (hours), and I have to close most other apps.
The provided instructions here are also somewhat frustrating, but there are at least 2 issues.
A security change in github access from Sept 2021 has not been reflected in the configuration, causing the build to fail.
4 references to git:// need to be replaced with https://, in the imagery and suggestions area's.
It's also not made very clear that as the vbox setup uses port 8888, that the OAuth Configuration would need to be changed to match.
Despite all this, the software built, ran in under 4 Gb of memory, we both connected via our OSM accounts, and then failed in most things with the following error.
Error: signal 11:
stack trace:
hoot::SignalCatcher::default_handler(int) +0x2d
/usr/lib64/libc.so.6 : ()+0x36400
std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>::_M_dispose() +0xa
usually at around 29%
This issue will be logged in a separate case
To sum up, the virtualbox method needs a small number of config changes, and stand alone rpm installs fail.
If you get past this stage, the s/w appears to fail.
A stable, well documented Docker image would be appreciated, with a few test cases to check we have a sucessful build.
Thanks
Mike
The text was updated successfully, but these errors were encountered: