* allow installing a plugin using proxy without having to use the `--no-verify` flag
* allow the use of proxies that have basic authentication
* add tests for proxy handling in plugin manager
Fixes#8435
use rm_rf to delete dir and shutdown pipeline after run
avoid the use of rescue nil, bad practice
do not mock close as it prevents closing the file an prevents removing it on Windows
cleanup temporary files and relax file name check for Windows
fix paths handling for Windows
flag the read file string as UTF-8 which is what we expect
fix Windows issues
ignore load_average on windows
windows safe URI
cleanup and fix file handling for windows
wait for pipeline shutdown to complete
revert to original puts
cleanups
use environment for windows platform check
fix hash path
wait for pipeline thread to complete after shutdown
On some Linux system like debian, the `HTTP_PROXY` are set to an empty
string and was causing the plugin manager to raise an exception. We now
strip the string and check if it is empty before trying to configure the
proxies.
Fixes: #7045Fixes#7065
Logstash's plugin manager will now follow proxy configuration from the environment.
If you configure `http_proxy` and `https_proxy`, the manager will now use theses information for all the ruby http
connection and will also pass that information down to maven.
Fixes: #6619, #6528Fixes#6825
This PR changes the behavior of the command when you were specify a directory
instead of a filename, if the directory exists it would have deleted the
directory and the files in it.
The new flow and validation is now safer, if you specify a directory
Logstash will tell you to specify a complete filename.
If the ZIP extension is missing, the command line will ask you to make
sure you target a right filename.
If the output file already exist it will *not* delete it but instead
will return a warning message, you can force a delete by using the
`--overwrite` option.
Fixes: #6862Fixes#6861
This PR fix an annoyance when running the `bin/logstash-plugin install
--no-verify` without any plugins, the command was making an unnecessary
call to the artifacts web server.
Fixes#6826
This new command replace the old workflow of `pack`, `unpack` and the `install --local`, and wrap all the logic into one uniform way of installing plugins.
The work is based on the flow developed for installing an x-pack inside Logstash, when you call prepare-offline-pack, the specified plugins and their dependencies will be packaged in a zip.
And this zip can be installed with the same flow as the pack.
Definition:
Source Logstash: Where you run the prepare-offline-pack.
Target Logstash: Where you install the offline package.
PROS:
- If you install a .gem in the source logstash, the .gem and his dependencies will be bundled.
- The install flow doesn't need to have access to the internet.
- Nothing special need to be setup in the target logstash environment.
CONS:
- The is one minor drawback, the plugins need to have their JARS bundled with them for this flow to work, this is currently the case for all the official plugins.
- The source Logstash need to have access to the internet when you install plugins before packaging them.
Usage examples:
bin/logstash-plugin prepare-offline-pack logstash-input-beats
bin/logstash-plugin prepare-offline-pack logstash-filter-jdbc logstash-input-beats
bin/logstash-plugin prepare-offline-pack logstash-filter-*
bin/logstash-plugin prepare-offline-pack logstash-filter-* logstash-input-beats
How to install:
bin/logstash-plugin install file:///tmp/logstash-offline-plugins-XXXX.zip
Fixes#6404
The are a difference between the gems installed and the available spec
loaded in memory making bundler remove the gem that we have just
updated.
Fixes: #6339Fixes#6340
**Motivation**: We have decided to rewrite the documentation generator to add more features
to our documentation and to fix some outstanding bugs.
This PR addresses the following problem:
- Hard to add new features to the code base.
- The code was tied with Logstash.
- No easy way to publish the doc for a single plugin
- The plugin author was not able to test their documentation changes
- The reported errors were hard to understand.
- No easy way to automate it.
- the minimal requirement on base classes.
Fixes#5720
A pack in this context is a *bundle* of plugins that can be distributed outside of rubygems; it is similar to what ES and kibana are doing, and
the user interface is modeled after them. See https://www.elastic.co/downloads/x-pack
**Do not mix it with the `bin/logstash-plugin pack/unpack` command.**
- it contains one or more plugins that need to be installed
- it is self-contains with the gems and the needed jars
- it is distributed as a zip file
- the file structure needs to follow some rules.
- As a reserved name name on elastic.co download http server
- `bin/plugin install logstash-mypack` will check on the download server if a pack for the current specific logstash version exist and it will be downloaded, if it doesn't exist we fallback on rubygems.
- The file on the server will follow this convention `logstash-mypack-{LOGSTASH_VERSION}.zip`
- As a fully qualified url
- `bin/plugin install http://test.abc/logstash-mypack.zip`, if it exists it will be downloaded and installed if it does not we raise an error.
- As a local file
- `bin/plugin install file:///tmp/logstash-mypack.zip`, if it exists it will be installed
Fixes#6168
- Allow plugins author to decide how their plugins are structured
- Allow a new kind of plugin that allow plugins author to add hooks into logstash core.
Fixes#6109
These methods allow outputs to receive their events pre-encoded for them
by the pipeline. This is mostly useful in the context of `#shared` outputs, for whom
encoding a discrete batch in a threadsafe way is not necessarily straightforward.
It would be advised for codecs to prefer `#multi_encode` as the main way of operating
as the standard `#encode` method is not threadsafe.
Fixes#5770
Purpose:
* manage releases through a minimum number of rake tasks
* simplify building of snapshot builds
* create staged artifacts, candidates for releases, that required no changes to become releases
* this means the snapshot release process will not involve publishing gems, therefore:
* the gem artifacts should only be published to rubygems as a final artifact, at the time of GA
Changes:
* release artifacts no longer depend on gems of core components
* all core components are used locally AS-IS to minimize code changes between snapshot, RC and GA
* `versions.yml` describes the versions of all logstash parts and package
* `rake version:set[version]` manage the yaml file and push the changes to the gemspecs/version.rb files
* `rake version:set_plugin_api[version]` manage the yaml file and push the changes to the gemspecs/version.rb files
* `rake artifact:all` generates SNAPSHOT artifacts: tar.gz, zip, rpm, deb
* `RELEASE=1 rake artifact:all` creates release candidate artifacts + 4 gems: logstash-core, logstash-core-event, logstash-core-event-java and logstash-core-plugin-api
implements #5416 and #5414Fixes#5460
Update after-install scripts
Use /usr/lib/logstash instead of /opt/logstash
More revisions.
Using `/usr/share/logstash` instead of `/usr/lib/logstash`
Track these new files
More work in progress.
Proper arg parsing obtained
WIP: Use jvm.options like ES
Remove facter dependency
Due to an update from @jordansissel on pleaserun, facter is no longer necessary
Revert Gemfile to proper version
Latest work in progress.
I added a simple test to logstash.lib.sh to catch empty strings in java options.
Added `startup.options`, and touched up `jvm.options`
Edited the package scripts to make things play nice with new paths.
Tweaked `system-install` to allow users to provide their own `startup.options` file.
Patch up merge failure
Changes to work with the new logstash.yml
Add fpm dependency (build fails without it)
Fix missing gems in Gemfile
Don't know how these got lost
Use /etc/logstash for configuration in packages
Update the instructions/documentation for...
...startup.options
Merging proposed changes
Remove mustache and clamp
They're covered by pleaserun anyway
Prune config dir from /usr/share/logstash...
...but only when using RPM/DEB packages
* by default lives in LOGSTASH_HOME/config/logstash.yml
* location can be changed by $LS_SETTINGS_DIR or --path.settings
* overrides defaults of LogStash::Environment, BUT
* CLI flags override the yaml file
* several breaking changes to cli flag names (see config/logstash.yml)
* setting values are now type checked (see Setting and Settings classes)
Fixes#5313
