Install Curator in Linux with no Network & Root Access or Pip

I'm having trouble installing curator in my Linux stage environment.

I don't have network and root access, or pip to help me install curator in my evnironment.

What I've tried is using pip to install curator on my localmachine then transfer the files and packages to my stage. However, I'm not able to find curator.exe in my stage to run curator.

I came across to this post on how to install curator offline but it requires pip in the offline host. Is there another way I can do it?


Sorry for the outdated information. That install document predates Curator's addition to Elastic's official documentation online. Curator's official documentation has direct downloads for RHEL/CentOS 6, 7, and Debian 8 flavors in the installation chapter:

These packages do not require Python to be installed, as they are completely self-contained (frozen, in Python parlance).

Is there a way to install it without root access?

Not the RPMs, no. That sounds like a discussion that should happen, so that you can install necessary tools.

If you were to install the RPM on a separate machine, however, it would put Curator into /opt/elasticsearch-curator. If you were to copy this entire directory into a target directory of your choice, it might work. The binaries are in the top level of that directory.

Alternatives to this are kind of difficult, as they'd require you installing a virtualenv on one machine, and then trying to copy it exactly over to another. This would only work if the virtualenv had exactly the same paths on both machines (if I recall correctly), and even that requires that virtualenv be installed in Python.

Just wondering, how come I'm not able to use pip to install curator and the necessary packages and then transfer all the files to my Linux machine and run curator?

I've tried it and it didn't work.

Because pip installs not only the package, but metadata that indicates the package was installed, and where. Without that metadata, the import module_name lines at the top of the python code files would be unable to find where those modules were installed. That's why it fails. That's why doing this in a virtualenv would work, because it packages the metadata with the modules. But that's also why virtualenv is hard, because it has to be in the same path on both the source and the target machine to work.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.