I used to install elasticsearch-transport-couchbase plugin very easy, however this time it didn't go well.
First I tried to install plugin using README as bellow:
bin/plugin -install transport-couchbase -url http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.1/elasticsearch-transport-couchbase-2.1.1.zip
It returns following error:
ERROR: unknown command [-install]. Use [-h] option to list available commands
According to es documentations:
A plugin can also be downloaded directly from a custom location by specifying the URL:
sudo bin/plugin install [url]
I tried this:
bin/plugin install http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.1/elasticsearch-transport-couchbase-2.1.1.zip
And the results was:
Downloading
.........................................................................................................................DONE
Verifying
http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.1/elasticsearch-transport-couchbase-2.1.1.zip
checksums if available ... Failed: IOException[Server returned HTTP
response code: 403 for URL:
http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.1/elasticsearch-transport-couchbase-2.1.1.zip.sha1];
nested: IOException[Server returned HTTP response code: 403 for URL:
http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/2.1.1/elasticsearch-transport-couchbase-2.1.1.zip.sha1];
NOTE: Unable to verify checksum for downloaded plugin (unable to find
.sha1 or .md5 file to verify) ERROR: Could not find plugin descriptor
'plugin-descriptor.properties' in plugin zip
How can I install the plugin?
Couchbase transport plugin v2.1.2 is not supporting Elasticsearch higher than 1.7.3.
As Reza notes, ElasticSearch versions > 2 require a newer plugin.
At the current time, that newer plugin would be version v2.2.1.2, but don't rely on this - instead, follow the installation guide on the couchbase git repository: couchbase git repository elasticsearch plugin. This is much more likely to have up to date information on both the process and correct plugin version.
Related
Desired behavior
I would like to use CYPRESS_DOWNLOAD_MIRROR pointing toward my artifactory configuration for Cypress and just be able to do npm install and download library AND binary of Cypress
Current behavior
When setting Cypress in artifactory, and downloading it with CYPRESS_DOWNLOAD_MIRROR set toward this tool, the download script find binary files as X.Y.Z and not cypress.zip and fail. Apparently I can't rename binaries in artifactory. It seems to have made it available in a name X.Y.Z instead of cypress.zip
My artifactory admin tell me to do this command before but I can't since it's a post action of Cypress
curl –v « https://artifactory.mycompany.fr/artifactory/remote-download.cypress-generic/desktop/6.8.0?platform=win32&arch=x64 » > cypress.zip
Workaround
For now, I'm using CYPRESS_INSTALL_BINARY to point to a manually uploaded binary in artifactory but it's a pain because I have to separate Linux binary (for CI) and Windows binary (for dev) and if my package is configured with "cypress": "^6.2.1" the npm library will go to 6.2.1 and my binary will stuck to 6.2.0 for example...
Debug logs
Installing Cypress (version: 6.8.0)
× Downloading Cypress
→ Cypress Version: 6.8.0
Unzipping Cypress
Finishing Installation
The Cypress App could not be downloaded.
Does your workplace require a proxy to be used to access the Internet? If so, you must configure the HTTP_PROXY environment variable before downloading
Cypress. Read more: https://on.cypress.io/proxy-configuration
Otherwise, please check network connectivity and try again:
URL: https://artifactory.mycompany.fr/artifactory/remote-download.cypress.io/desktop/6.8.0?platform=win32&arch=x64
Error: self signed certificate in certificate chain
Download method
npm
Operating System
Linux
Windows
Other
I'm behind a proxy
I don't really know if it's an artifactory or a Cypress matter but I need help ^^
In addition to accepted answer, it is possible to replace pre-defined 'Query Params' with enabling 'Propagate Query Params'. If set, the query params passed with the request to Artifactory, will be passed on to the remote repo.
Please note, according to JFrog docs, this setting is only available for Generic type repositories.
I was able to make it work on Windows using the following:
I created a generic remote repository, making sure it is pointing to https://download.cypress.io, and under the advanced tab, added the query params: platform=win32&arch=x64 (notice there is a dedicated field for it).
The above is required in order to cache the correct binary based on the OS and arch (you might require a different remote repository with different query params).
I found it on Cypress doc that these query params control the binary type which will be downloaded (so we need to make sure it fits the client os and arch).
In the .npmrc I simply provided the following:
CYPRESS_DOWNLOAD_MIRROR=https://user:myverystrongpassword#myartifactory/artifactory/generic-cypress-windows
I've used this command (on MacOS) to directly pass path to downloaded Cypress.zip file
CYPRESS_INSTALL_BINARY=~/Downloads/cypress.zip yarn add cypress --D
We are running a local Artifactory Pro installation and have rubygems.org configured as a Remote Repository.
When running bundle install in a CI Job, the local Artifactory Instance does return a 404 File not found when querying for the /versions file. When doing a manual lookup in the Remote (&Cache) Repo, the file >is present<.
The path we pass to bundle install is provided by the Set me up Wizard and looks like this:
https://$rtf-instance.com/artifactory/api/gems/gems-remote/versions
This was mentioned in an issue here: https://www.jfrog.com/jira/browse/RTFACT-16005
and should have been fixed, but it is still not working in our installation.
Can't find any mention of RTFACT-16005 or the related RTFACT-19012 in the Release Notes.
Repo is setup with default values, no additional config done.
Are we missing something?
Environment:
debian 10 (buster)
nginx 1.14.2
artifactory-pro 7.15.4 / 7.15.3
To enable the gems compact index support you need to add the following system property (under $JFROG_HOME/var/etc/artifactory/artifactory.system.properties):
artifactory.gems.compact.index.enabled=true
You will need to restart Artifactory afterward.
This can be found in JFrog Wiki, here: https://www.jfrog.com/confluence/display/JFROG/RubyGems+Repositories#RubyGemsRepositories-RetrievingLatestRubyGemsPackageCompatiblewithYourRubyVersions
I'm trying to setup a remote repository for Homebrew on Artifactory. I'm following the steps as described in the following page https://jfrog.com/knowledge-base/how-do-i-set-up-a-remote-homebrew-repository.
However, When testing the remote url connection (http://homebrew.bintray.com/bottles) I got this error:
Connection failed: Error 403: Forbidden
I also checked the website in a browser and got the same error message. What are the work arounds for this?
try this:
Create Generic remote repo named homebrew point it to https://homebrew.bintray.com/.
then set env HOMEBREW_BOTTLE_DOMAIN=http://localhost:8080/artifactory/homebrew/.
brew install wget
I have HDP installed with Ambari using public repositories.
I wanted to add Hue to the ecosystem. Since Ambari didn't have Hue as a service to install, I went on with the guide here:
https://github.com/EsharEditor/ambari-hue-service
As far as I understand this guide adds Hue as a service in possible services that Ambari can install.
I think it (this guide) is for local repository installation as I've learned.
My installation failed when it tried to download from public repository. It couldn't find hue server package.
Error log start
2017-01-24 18:53:50,351 - Downloading Hue Service
2017-01-24 18:53:50,351 - Execute['cat /etc/yum.repos.d/HDP.repo | grep "baseurl" | awk -F '=' '{print $2"hue/hue-3.11.0.tgz"}' | xargs wget -O hue.tgz'] {}
Command failed after 1 tries
Error log end
Then I wanted to try installing Hue manually
I followed the guide here:
http://gethue.com/hadoop-hue-3-on-hdp-installation-tutorial
Installation was successfull but my installation was not integrated with Ambari.
I wanted to try the first method again, changing my OS repo files to local repository at first step.
I changed the contents of the files under /etc/yum.repos.d/ to local repository paths to make Ambari use local repository packages but Ambari displayed public-repository. I had tried to install over public repository before. Got the same shell command error this time again as I went on the the next step of ambari add service wizard:
After a short search I found following file and updated also that file with local repository paths:
/var/lib/ambari-server/resources/stacks/HDP/2.5/repos/repoinfo.xml
However, it didn't work either. Ambari was still trying to download from public repository.
Does anyone have a comment?
If I achieve using public repository problem, next step will be finding rpm packages of hue for 3.9.0 or 3.11.0 because my local HDP repository had 2.6 version.
Any help also for this will be appreciated.
OS: Centos 7
HDP: 2.5.3
Ambari: 2.4.2
Hue: 3.9.0
I worked on this with a friend and we were able to overcome this.
I can't say it is the ideal answer but it is a workaround for my case:
The scripts under path
/var/lib/ambari-agent/cache/stacks/HDP/2.5/services/HUE/package/scripts
`$ ls`
common.py hue_server.py params.py setup_hue.py status_params.py
common.pyc hue_server.pyc params.pyc setup_hue.pyc status_params.pyc
were managing the Hue installation over Ambari.
The error message we received was due to a command in common.py
Although we couldn't find out how it overrides our local repository, we searched for pattern "public-repo" and found following files:
/usr/lib/ambari-server/web/data/wizard/stack/HDP_versions.json
/usr/lib/ambari-server/web/data/wizard/stack/HDP_version_definitions.json
/usr/lib/ambari-server/web/data/stacks/HDP-2.1/operating_systems.json
Instead of replacing content of these files, we updated the "download_url" variable inside params.py file.
We hard-coded our local repository URL as value.
We executed the command that we received error from common.py (line 57)
We tried and received another error for the next command.
Then we also applied that command manually
and converted the manually applied command line to comment line
and we retried.
We had to use this apply-manually, comment, retry, receive-error thing for the next command as latest one (3 commands of common.py in total).
On the next retry, installation was successful and hue was up. Rest of is the normal procedure. We updated the hue.ini file.
Currently I am having errors on Hue page as the errors mentioned in this unanswered post :)
https://community.cloudera.com/t5/Web-UI-Hue-Beeswax/Hue-cannot-access-database-Failed-to-access-filesystem-root/td-p/40318
Good luck!
I am trying to install the datanode and it gives the error "metadata file does not match checksum"
I am behind a proxy
I have tried everything- yum clear all, yum clear metadata. I also edited the yum conf and disabled caching.
In addition, i also manually deleted the cache directory. Nothing works. Nothing. Please help.
On another machine, i was able to get the name node successfully installed
**[root#bi ~]# export http_proxy= myproxy**
**[root#bi ~]# sudo yum install hadoop-0.20-mapreduce-tasktracker hadoop-hdfs-datanode**
http://archive.cloudera.com/cdh4/redhat/5/x86_64/cdh/4/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://archive.cloudera.com/cdh4/redhat/5/x86_64/cdh/4/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from cloudera-cdh4: [Errno 256] No more mirrors to try
I had the same problem, there seams to be a problem with proxy. Try an other proxy or take a look at your configures there.
cloudera manager creates a .repo before installing, and if there are any conflicts it causes that error.
To avoid such conflicts,
1)Create a /etc/yum.repos.d/cloudera-manager.repo file using any stable version of cloudera manager.(5.2.1 was the version when I did this)
My cloudera-manager.repo file looked like this:
[cloudera-manager]
name = Cloudera Manager, Version 5.2.1
baseurl = http://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5.2.1/
gpgkey = http://archive.cloudera.com/redhat/cdh/RPM-GPG-KEY-cloudera
gpgcheck = 1
2) Now run the following command to make the installer use the local repo file.
./cloudera-manager-installer.bin --skip_repo_package=1