397 lines
15 KiB
Java
Raw Normal View History

2010-02-08 15:30:06 +02:00
/*
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch licenses this file to you under
* the Apache License, Version 2.0 (the "License"); you may
* not use this file except in compliance with the License.
* You may obtain a copy of the License at
2010-02-08 15:30:06 +02:00
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.elasticsearch.bootstrap;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.core.Appender;
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.appender.ConsoleAppender;
import org.apache.logging.log4j.core.config.Configurator;
import org.apache.lucene.util.Constants;
2016-01-29 16:26:37 +01:00
import org.apache.lucene.util.IOUtils;
import org.apache.lucene.util.StringHelper;
import org.elasticsearch.ElasticsearchException;
2010-02-08 15:30:06 +02:00
import org.elasticsearch.Version;
import org.elasticsearch.cli.UserException;
import org.elasticsearch.common.PidFile;
import org.elasticsearch.common.SuppressForbidden;
import org.elasticsearch.common.inject.CreationException;
import org.elasticsearch.common.logging.ESLoggerFactory;
import org.elasticsearch.common.logging.LogConfigurator;
import org.elasticsearch.common.logging.ServerLoggers;
import org.elasticsearch.common.logging.Loggers;
import org.elasticsearch.common.network.IfConfig;
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
import org.elasticsearch.common.settings.KeyStoreWrapper;
import org.elasticsearch.common.settings.SecureSettings;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.common.transport.BoundTransportAddress;
2010-02-08 15:30:06 +02:00
import org.elasticsearch.env.Environment;
import org.elasticsearch.monitor.jvm.JvmInfo;
2015-07-06 14:22:01 +02:00
import org.elasticsearch.monitor.os.OsProbe;
import org.elasticsearch.monitor.process.ProcessProbe;
import org.elasticsearch.node.InternalSettingsPreparer;
import org.elasticsearch.node.Node;
import org.elasticsearch.node.NodeValidationException;
2010-02-08 15:30:06 +02:00
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintStream;
import java.io.UnsupportedEncodingException;
import java.net.URISyntaxException;
import java.nio.file.Path;
import java.security.NoSuchAlgorithmException;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.CountDownLatch;
2010-02-08 15:30:06 +02:00
/**
* Internal startup code.
2010-02-08 15:30:06 +02:00
*/
final class Bootstrap {
2010-02-08 15:30:06 +02:00
2015-05-04 14:06:32 -04:00
private static volatile Bootstrap INSTANCE;
private volatile Node node;
2015-05-04 14:06:32 -04:00
private final CountDownLatch keepAliveLatch = new CountDownLatch(1);
private final Thread keepAliveThread;
private final Spawner spawner = new Spawner();
2015-05-04 14:06:32 -04:00
/** creates a new instance */
Bootstrap() {
keepAliveThread = new Thread(new Runnable() {
@Override
public void run() {
try {
keepAliveLatch.await();
} catch (InterruptedException e) {
// bail out
}
}
}, "elasticsearch[keepAlive/" + Version.CURRENT + "]");
keepAliveThread.setDaemon(false);
// keep this thread alive (non daemon thread) until we shutdown
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
keepAliveLatch.countDown();
}
});
}
/** initialize native resources */
public static void initializeNatives(Path tmpFile, boolean mlockAll, boolean systemCallFilter, boolean ctrlHandler) {
final Logger logger = Loggers.getLogger(Bootstrap.class);
2015-05-05 01:29:57 -04:00
// check if the user is running as root, and bail
if (Natives.definitelyRunningAsRoot()) {
throw new RuntimeException("can not run elasticsearch as root");
2015-05-05 01:29:57 -04:00
}
// enable system call filter
if (systemCallFilter) {
Natives.tryInstallSystemCallFilter(tmpFile);
Block process execution with seccomp on linux/amd64 Block execve(), fork(), and vfork() system calls, returning EACCES instead, on kernels that support seccomp-bpf: either via seccomp() or falling back to prctl(). Only linux/amd64 is supported. This feature can be disabled (in case of problems) with bootstrap.seccomp=false. Closes #13753 Squashed commit of the following: commit 92cee05c72b49e532d41be7b16709e1c9f919fa9 Author: Robert Muir <rmuir@apache.org> Date: Thu Sep 24 10:12:51 2015 -0400 Add a note about why we don't parse uname() or anything commit b427971f45cbda4d0b964ddc4a55fae638880335 Author: Robert Muir <rmuir@apache.org> Date: Thu Sep 24 09:44:31 2015 -0400 style only: we already pull errno into a local, use it for catch-all case commit ddf93305525ed1546baf91f7902148a8f5b1ad06 Author: Robert Muir <rmuir@apache.org> Date: Thu Sep 24 08:36:01 2015 -0400 add TODO commit f29d1b7b809a9d4c1fcf15f6064e43f7d1b24696 Author: Robert Muir <rmuir@apache.org> Date: Thu Sep 24 08:33:28 2015 -0400 Add full stacktrace at debug level always commit a3c991ff8b0b16dc5e128af8fb3dfa6346c6d6f1 Author: Robert Muir <rmuir@apache.org> Date: Thu Sep 24 00:08:19 2015 -0400 Add missing check just in case. commit 628ed9c77603699aa9c67890fe7632b0e662a911 Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 22:47:16 2015 -0400 Add public getter, for stats or whatever if they need to know this commit 3e2265b5f89d42043d9a07d4525ce42e2cb1c727 Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 22:43:06 2015 -0400 Enable use of seccomp(2) on Linux 3.17+ which provides more protection. Add nice errors. Add all kinds of checks and paranoia. Add documentation. Add boolean switch. commit 0e421f7fa2d5236c8fa2cd073bcb616f5bcd2d23 Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 21:36:32 2015 -0400 Add defensive checks and nice error messages commit 6231c3b7c96a81af8460cde30135e077f60a3f39 Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 20:52:40 2015 -0400 clean up JNA and BPF. block fork and vfork too. commit bb31e8a6ef03ceeb1d5137c84d50378c270af85a Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 19:00:32 2015 -0400 order is LE already for the JNA buffer, but be explicit about it commit 10456d2f08f12ddc3d60989acb86b37be6a4b12b Author: Robert Muir <rmuir@apache.org> Date: Wed Sep 23 17:47:07 2015 -0400 block process execution with seccomp on linux/amd64
2015-09-24 12:17:21 -04:00
}
// mlockall if requested
if (mlockAll) {
if (Constants.WINDOWS) {
Natives.tryVirtualLock();
} else {
Natives.tryMlockall();
}
}
2010-02-08 15:30:06 +02:00
// listener for windows close event
if (ctrlHandler) {
Natives.addConsoleCtrlHandler(new ConsoleCtrlHandler() {
@Override
public boolean handle(int code) {
if (CTRL_CLOSE_EVENT == code) {
logger.info("running graceful exit on windows");
try {
Bootstrap.stop();
} catch (IOException e) {
throw new ElasticsearchException("failed to stop node", e);
}
return true;
}
return false;
}
});
}
// force remainder of JNA to be loaded (if available).
try {
JNAKernel32Library.getInstance();
} catch (Exception ignored) {
// we've already logged this.
}
Natives.trySetMaxNumberOfThreads();
Natives.trySetMaxSizeVirtualMemory();
Natives.trySetMaxFileSize();
// init lucene random seed. it will use /dev/urandom where available:
StringHelper.randomId();
}
static void initializeProbes() {
// Force probes to be loaded
ProcessProbe.getInstance();
2015-07-06 14:22:01 +02:00
OsProbe.getInstance();
JvmInfo.jvmInfo();
}
private void setup(boolean addShutdownHook, Environment environment) throws BootstrapException {
Persistent Node Names (#19456) With #19140 we started persisting the node ID across node restarts. Now that we have a "stable" anchor, we can use it to generate a stable default node name and make it easier to track nodes over a restarts. Sadly, this means we will not have those random fun Marvel characters but we feel this is the right tradeoff. On the implementation side, this requires a bit of juggling because we now need to read the node id from disk before we can log as the node node is part of each log message. The PR move the initialization of NodeEnvironment as high up in the starting sequence as possible, with only one logging message before it to indicate we are initializing. Things look now like this: ``` [2016-07-15 19:38:39,742][INFO ][node ] [_unset_] initializing ... [2016-07-15 19:38:39,826][INFO ][node ] [aAmiW40] node name set to [aAmiW40] by default. set the [node.name] settings to change it [2016-07-15 19:38:39,829][INFO ][env ] [aAmiW40] using [1] data paths, mounts [[ /(/dev/disk1)]], net usable_space [5.5gb], net total_space [232.6gb], spins? [unknown], types [hfs] [2016-07-15 19:38:39,830][INFO ][env ] [aAmiW40] heap size [1.9gb], compressed ordinary object pointers [true] [2016-07-15 19:38:39,837][INFO ][node ] [aAmiW40] version[5.0.0-alpha5-SNAPSHOT], pid[46048], build[473d3c0/2016-07-15T17:38:06.771Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_51/25.51-b03] [2016-07-15 19:38:40,980][INFO ][plugins ] [aAmiW40] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy, transport-netty], plugins [] [2016-07-15 19:38:43,218][INFO ][node ] [aAmiW40] initialized ``` Needless to say, settings `node.name` explicitly still works as before. The commit also contains some clean ups to the relationship between Environment, Settings and Plugins. The previous code suggested the path related settings could be changed after the initial Environment was changed. This did not have any effect as the security manager already locked things down.
2016-07-23 22:46:48 +02:00
Settings settings = environment.settings();
try {
spawner.spawnNativePluginControllers(environment);
} catch (IOException e) {
throw new BootstrapException(e);
}
initializeNatives(
environment.tmpFile(),
BootstrapSettings.MEMORY_LOCK_SETTING.get(settings),
BootstrapSettings.SYSTEM_CALL_FILTER_SETTING.get(settings),
BootstrapSettings.CTRLHANDLER_SETTING.get(settings));
// initialize probes before the security manager is installed
initializeProbes();
if (addShutdownHook) {
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
2016-01-29 16:26:37 +01:00
try {
IOUtils.close(node, spawner);
LoggerContext context = (LoggerContext) LogManager.getContext(false);
Configurator.shutdown(context);
2016-01-29 16:26:37 +01:00
} catch (IOException ex) {
throw new ElasticsearchException("failed to stop node", ex);
}
}
});
}
Refactor pluginservice Closes #12367 Squashed commit of the following: commit 9453c411798121aa5439c52e95301f60a022ba5f Merge: 3511a9c 828d8c7 Author: Robert Muir <rmuir@apache.org> Date: Wed Jul 22 08:22:41 2015 -0400 Merge branch 'master' into refactor_pluginservice commit 3511a9c616503c447de9f0df9b4e9db3e22abd58 Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 21:50:15 2015 -0700 Remove duplicated constant commit 4a9b5b4621b0ef2e74c1e017d9c8cf624dd27713 Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 21:01:57 2015 -0700 Add check that plugin must specify at least site or jvm commit 19aef2f0596153a549ef4b7f4483694de41e101b Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 20:52:58 2015 -0700 Change plugin "plugin" property to "classname" commit 07ae396f30ed592b7499a086adca72d3f327fe4c Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 23:36:05 2015 -0400 remove test with no methods commit 550e73bf3d0f94562f4dde95239409dc5a24ce25 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 23:31:58 2015 -0400 fix loading to use classname commit 04463aed12046da0da5cac2a24c3ace51a79f799 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 23:24:19 2015 -0400 rename to classname commit 9f3afadd1caf89448c2eb913757036da48758b2d Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 20:18:46 2015 -0700 moved PluginInfo and refactored parsing from properties file commit df63ccc1b8b7cc64d3e59d23f6c8e827825eba87 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 23:08:26 2015 -0400 fix test commit c7febd844be358707823186a8c7a2d21e37540c9 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 23:03:44 2015 -0400 remove test commit 017b3410cf9d2b7fca1b8653e6f1ebe2f2519257 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 22:58:31 2015 -0400 fix test commit c9922938df48041ad43bbb3ed6746f71bc846629 Merge: ad59af4 01ea89a Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 22:37:28 2015 -0400 Merge branch 'master' into refactor_pluginservice commit ad59af465e1f1ac58897e63e0c25fcce641148a7 Author: Areek Zillur <areek.zillur@elasticsearch.com> Date: Tue Jul 21 19:30:26 2015 -0400 [TEST] Verify expected number of nodes in cluster before issuing shardStores request commit f0f5a1e087255215b93656550fbc6bd89b8b3205 Author: Lee Hinman <lee@writequit.org> Date: Tue Jul 21 11:27:28 2015 -0600 Ignore EngineClosedException during translog fysnc When performing an operation on a primary, the state is captured and the operation is performed on the primary shard. The original request is then modified to increment the version of the operation as preparation for it to be sent to the replicas. If the request first fails on the primary during the translog sync (because the Engine is already closed due to shadow primaries closing the engine on relocation), then the operation is retried on the new primary after being modified for the replica shards. It will then fail due to the version being incorrect (the document does not yet exist but the request expects a version of "1"). Order of operations: - Request is executed against primary - Request is modified (version incremented) so it can be sent to replicas - Engine's translog is fsync'd if necessary (failing, and throwing an exception) - Modified request is retried against new primary This change ignores the exception where the engine is already closed when syncing the translog (similar to how we ignore exceptions when refreshing the shard if the ?refresh=true flag is used). commit 4ac68bb1658688550ced0c4f479dee6d8b617777 Author: Shay Banon <kimchy@gmail.com> Date: Tue Jul 21 22:37:29 2015 +0200 Replica allocator unit tests First batch of unit tests to verify the behavior of replica allocator commit 94609fc5943c8d85adc751b553847ab4cebe58a3 Author: Jason Tedor <jason@tedor.me> Date: Tue Jul 21 14:04:46 2015 -0400 Correctly list blobs in Azure storage to prevent snapshot corruption and do not unnecessarily duplicate Lucene segments in Azure Storage This commit addresses an issue that was leading to snapshot corruption for snapshots stored as blobs in Azure Storage. The underlying issue is that in cases when multiple snapshots of an index were taken and persisted into Azure Storage, snapshots subsequent to the first would repeatedly overwrite the snapshot files. This issue does render useless all snapshots except the final snapshot. The root cause of this is due to String concatenation involving null. In particular, to list all of the blobs in a snapshot directory in Azure the code would use the method listBlobsByPrefix where the prefix is null. In the listBlobsByPrefix method, the path keyPath + prefix is constructed. However, per 5.1.11, 5.4 and 15.18.1 of the Java Language Specification, the reference null is first converted to the string "null" before performing the concatenation. This leads to no blobs being returned and therefore the snapshot mechanism would operate as if it were writing the first snapshot of the index. The fix is simply to check if prefix is null and handle the concatenation accordingly. Upon fixing this issue so that subsequent snapshots would no longer overwrite earlier snapshots, it was discovered that the snapshot metadata returned by the listBlobsByPrefix method was not sufficient for the snapshot layer to detect whether or not the Lucene segments had already been copied to the Azure storage layer in an earlier snapshot. This led the snapshot layer to unnecessarily duplicate these Lucene segments in Azure Storage. The root cause of this is due to known behavior in the CloudBlobContainer.getBlockBlobReference method in the Azure API. Namely, this method does not fetch blob attributes from Azure. As such, the lengths of all the blobs appeared to the snapshot layer to be of length zero and therefore they would compare as not equal to any new blobs that the snapshot layer is going to persist. To remediate this, the method CloudBlockBlob.downloadAttributes must be invoked. This will fetch the attributes from Azure Storage so that a proper comparison of the blobs can be performed. Closes elastic/elasticsearch-cloud-azure#51, closes elastic/elasticsearch-cloud-azure#99 commit cf1d481ce5dda0a45805e42f3b2e0e1e5d028b9e Author: Lee Hinman <lee@writequit.org> Date: Mon Jul 20 08:41:55 2015 -0600 Unit tests for `nodesAndVersions` on shared filesystems With the `recover_on_any_node` setting, these unit tests check that the correct node list and versions are returned. commit 3c27cc32395c3624f7c794904d9ea4faf2eccbfb Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 14:15:59 2015 -0400 don't fail junit4 integration tests if there are no tests. instead fail the failsafe plugin, which means the external cluster will still get shut down commit 95d2756c5a8c21a157fa844273fc83dfa3c00aea Author: Alexander Reelsen <alexander@reelsen.net> Date: Tue Jul 21 17:16:53 2015 +0200 Testing: Fix help displaying tests under windows The help files are using a unix based file separator, where as the test relies on the help being based on the file system separator. This commit fixes the test to remove all `\r` characters before comparing strings. The test has also been moved into its own CliToolTestCase, as it does not need to be an integration test. commit 944f06ea36bd836f007f8eaade8f571d6140aad9 Author: Clinton Gormley <clint@traveljury.com> Date: Tue Jul 21 18:04:52 2015 +0200 Refactored check_license_and_sha.pl to accept a license dir and package path In preparation for the move to building the core zip, tar.gz, rpm, and deb as separate modules, refactored check_license_and_sha.pl to: * accept a license dir and path to the package to check on the command line * to be able to extract zip, tar.gz, deb, and rpm * all packages except rpm will work on Windows commit 2585431e8dfa5c82a2cc5b304cd03eee9bed7a4c Author: Chris Earle <pickypg@users.noreply.github.com> Date: Tue Jul 21 08:35:28 2015 -0700 Updating breaking changes - field names cannot be mapped with `.` in them - fixed asciidoc issue where the list was not recognized as a list commit de299b9d3f4615b12e2226a1e2eff5a38ecaf15f Author: Shay Banon <kimchy@gmail.com> Date: Tue Jul 21 13:27:52 2015 +0200 Replace primaryPostAllocated flag and use UnassignedInfo There is no need to maintain additional state as to if a primary was allocated post api creation on the index routing table, we hold all this information already in the UnassignedInfo class. closes #12374 commit 43080bff40f60bedce5bdbc92df302f73aeb9cae Author: Alexander Reelsen <alexander@reelsen.net> Date: Tue Jul 21 15:45:05 2015 +0200 PluginManager: Fix bin/plugin calls in scripts/bats test The release and smoke test python scripts used to install plugins in the old fashion. Also the BATS testing suite installed/removed plugins in that way. Here the marvel tests have been removed, as marvel currently does not work with the master branch. In addition documentation has been updated as well, where it was still missing. commit b81ccba48993bc13c7678e6d979fd96998499233 Author: Boaz Leskes <b.leskes@gmail.com> Date: Tue Jul 21 11:37:50 2015 +0200 Discovery: make sure NodeJoinController.ElectionCallback is always called from the update cluster state thread This is important for correct handling of the joining thread. This causes assertions to trip in our test runs. See http://build-us-00.elastic.co/job/es_g1gc_master_metal/11653/ as an example Closes #12372 commit 331853790bf29e34fb248ebc4c1ba585b44f5cab Author: Boaz Leskes <b.leskes@gmail.com> Date: Tue Jul 21 15:54:36 2015 +0200 Remove left over no commit from TransportReplicationAction It asks to double check thread pool rejection. I did and don't see problems with it. commit e5724931bbc1603e37faa977af4235507f4811f5 Author: Alexander Reelsen <alexander@reelsen.net> Date: Tue Jul 21 15:31:57 2015 +0200 CliTool: Various PluginManager fixes The new plugin manager parser was not called correctly in the scripts. In addition the plugin manager now creates a plugins/ directory in case it does not exist. Also the integration tests called the plugin manager in the deprecated way. commit 7a815a370f83ff12ffb12717ac2fe62571311279 Author: Alexander Reelsen <alexander@reelsen.net> Date: Tue Jul 21 13:54:18 2015 +0200 CLITool: Port PluginManager to use CLITool In order to unify the handling and reuse the CLITool infrastructure the plugin manager should make use of this as well. This obsolets the -i and --install options but requires the user to use `install` as the first argument of the CLI. This is basically just a port of the existing functionality, which is also the reason why this is not a refactoring of the plugin manager, which will come in a separate commit. commit 7f171eba7b71ac5682a355684b6da703ffbfccc7 Author: Martijn van Groningen <martijn.v.groningen@gmail.com> Date: Tue Jul 21 10:44:21 2015 +0200 Remove custom execute local logic in TransportSingleShardAction and TransportInstanceSingleOperationAction and rely on transport service to execute locally. (forking thread etc.) Change TransportInstanceSingleOperationAction to have shardActionHandler to, so we can execute locally without endless spinning. commit 0f38e3eca6b570f74b552e70b4673f47934442e1 Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 17:36:12 2015 -0700 More readMetadata tests and pickiness commit 880b47281bd69bd37807e8252934321b089c9f8e Author: Ryan Ernst <ryan@iernst.net> Date: Tue Jul 21 14:42:09 2015 -0700 Started unit tests for plugin service commit cd7c8ddd7b8c4f3457824b493bffb19c156c7899 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 07:21:07 2015 -0400 fix tests commit 673454f0b14f072f66ed70e32110fae4f7aad642 Author: Robert Muir <rmuir@apache.org> Date: Tue Jul 21 06:58:25 2015 -0400 refactor pluginservice
2015-07-22 10:44:52 -04:00
try {
// look for jar hell
JarHell.checkJarHell();
} catch (IOException | URISyntaxException e) {
throw new BootstrapException(e);
}
// Log ifconfig output before SecurityManager is installed
IfConfig.logIfNecessary();
// install SM after natives, shutdown hooks, etc.
try {
Security.configure(environment, BootstrapSettings.SECURITY_FILTER_BAD_DEFAULTS_SETTING.get(settings));
} catch (IOException | NoSuchAlgorithmException e) {
throw new BootstrapException(e);
}
Persistent Node Names (#19456) With #19140 we started persisting the node ID across node restarts. Now that we have a "stable" anchor, we can use it to generate a stable default node name and make it easier to track nodes over a restarts. Sadly, this means we will not have those random fun Marvel characters but we feel this is the right tradeoff. On the implementation side, this requires a bit of juggling because we now need to read the node id from disk before we can log as the node node is part of each log message. The PR move the initialization of NodeEnvironment as high up in the starting sequence as possible, with only one logging message before it to indicate we are initializing. Things look now like this: ``` [2016-07-15 19:38:39,742][INFO ][node ] [_unset_] initializing ... [2016-07-15 19:38:39,826][INFO ][node ] [aAmiW40] node name set to [aAmiW40] by default. set the [node.name] settings to change it [2016-07-15 19:38:39,829][INFO ][env ] [aAmiW40] using [1] data paths, mounts [[ /(/dev/disk1)]], net usable_space [5.5gb], net total_space [232.6gb], spins? [unknown], types [hfs] [2016-07-15 19:38:39,830][INFO ][env ] [aAmiW40] heap size [1.9gb], compressed ordinary object pointers [true] [2016-07-15 19:38:39,837][INFO ][node ] [aAmiW40] version[5.0.0-alpha5-SNAPSHOT], pid[46048], build[473d3c0/2016-07-15T17:38:06.771Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_51/25.51-b03] [2016-07-15 19:38:40,980][INFO ][plugins ] [aAmiW40] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy, transport-netty], plugins [] [2016-07-15 19:38:43,218][INFO ][node ] [aAmiW40] initialized ``` Needless to say, settings `node.name` explicitly still works as before. The commit also contains some clean ups to the relationship between Environment, Settings and Plugins. The previous code suggested the path related settings could be changed after the initial Environment was changed. This did not have any effect as the security manager already locked things down.
2016-07-23 22:46:48 +02:00
node = new Node(environment) {
@Override
protected void validateNodeBeforeAcceptingRequests(
final BootstrapContext context,
final BoundTransportAddress boundTransportAddress, List<BootstrapCheck> checks) throws NodeValidationException {
BootstrapChecks.check(context, boundTransportAddress, checks);
}
};
}
static SecureSettings loadSecureSettings(Environment initialEnv) throws BootstrapException {
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
final KeyStoreWrapper keystore;
try {
2017-01-06 01:03:45 -08:00
keystore = KeyStoreWrapper.load(initialEnv.configFile());
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
} catch (IOException e) {
throw new BootstrapException(e);
}
if (keystore == null) {
return null; // no keystore
}
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
try {
keystore.decrypt(new char[0] /* TODO: read password from stdin */);
KeyStoreWrapper.upgrade(keystore, initialEnv.configFile(), new char[0]);
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
} catch (Exception e) {
throw new BootstrapException(e);
}
return keystore;
}
private static Environment createEnvironment(
final Path pidFile,
final SecureSettings secureSettings,
final Settings initialSettings,
final Path configPath) {
Settings.Builder builder = Settings.builder();
if (pidFile != null) {
builder.put(Environment.PIDFILE_SETTING.getKey(), pidFile);
}
builder.put(initialSettings);
if (secureSettings != null) {
builder.setSecureSettings(secureSettings);
2017-01-06 09:11:07 -08:00
}
return InternalSettingsPreparer.prepareEnvironment(builder.build(), Collections.emptyMap(), configPath);
2010-02-08 15:30:06 +02:00
}
private void start() throws NodeValidationException {
node.start();
2015-05-04 14:06:32 -04:00
keepAliveThread.start();
2010-02-08 15:30:06 +02:00
}
static void stop() throws IOException {
2015-05-04 14:06:32 -04:00
try {
IOUtils.close(INSTANCE.node, INSTANCE.spawner);
2015-05-04 14:06:32 -04:00
} finally {
INSTANCE.keepAliveLatch.countDown();
2015-05-04 14:06:32 -04:00
}
}
2010-02-08 15:30:06 +02:00
/**
* This method is invoked by {@link Elasticsearch#main(String[])} to startup elasticsearch.
*/
static void init(
final boolean foreground,
final Path pidFile,
final boolean quiet,
2017-01-06 01:03:45 -08:00
final Environment initialEnv) throws BootstrapException, NodeValidationException, UserException {
// force the class initializer for BootstrapInfo to run before
// the security manager is installed
BootstrapInfo.init();
2016-03-08 17:27:53 -08:00
2015-05-04 14:06:32 -04:00
INSTANCE = new Bootstrap();
2010-02-08 15:30:06 +02:00
final SecureSettings keystore = loadSecureSettings(initialEnv);
final Environment environment = createEnvironment(pidFile, keystore, initialEnv.settings(), initialEnv.configFile());
try {
LogConfigurator.configure(environment);
} catch (IOException e) {
throw new BootstrapException(e);
}
if (environment.pidFile() != null) {
try {
PidFile.create(environment.pidFile(), true);
} catch (IOException e) {
throw new BootstrapException(e);
}
}
final boolean closeStandardStreams = (foreground == false) || quiet;
2010-02-08 15:30:06 +02:00
try {
if (closeStandardStreams) {
final Logger rootLogger = ESLoggerFactory.getRootLogger();
final Appender maybeConsoleAppender = ServerLoggers.findAppender(rootLogger, ConsoleAppender.class);
if (maybeConsoleAppender != null) {
ServerLoggers.removeAppender(rootLogger, maybeConsoleAppender);
}
closeSystOut();
2010-02-08 15:30:06 +02:00
}
// fail if somebody replaced the lucene jars
checkLucene();
// install the default uncaught exception handler; must be done before security is
// initialized as we do not want to grant the runtime permission
// setDefaultUncaughtExceptionHandler
Thread.setDefaultUncaughtExceptionHandler(
Persistent Node Names (#19456) With #19140 we started persisting the node ID across node restarts. Now that we have a "stable" anchor, we can use it to generate a stable default node name and make it easier to track nodes over a restarts. Sadly, this means we will not have those random fun Marvel characters but we feel this is the right tradeoff. On the implementation side, this requires a bit of juggling because we now need to read the node id from disk before we can log as the node node is part of each log message. The PR move the initialization of NodeEnvironment as high up in the starting sequence as possible, with only one logging message before it to indicate we are initializing. Things look now like this: ``` [2016-07-15 19:38:39,742][INFO ][node ] [_unset_] initializing ... [2016-07-15 19:38:39,826][INFO ][node ] [aAmiW40] node name set to [aAmiW40] by default. set the [node.name] settings to change it [2016-07-15 19:38:39,829][INFO ][env ] [aAmiW40] using [1] data paths, mounts [[ /(/dev/disk1)]], net usable_space [5.5gb], net total_space [232.6gb], spins? [unknown], types [hfs] [2016-07-15 19:38:39,830][INFO ][env ] [aAmiW40] heap size [1.9gb], compressed ordinary object pointers [true] [2016-07-15 19:38:39,837][INFO ][node ] [aAmiW40] version[5.0.0-alpha5-SNAPSHOT], pid[46048], build[473d3c0/2016-07-15T17:38:06.771Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_51/25.51-b03] [2016-07-15 19:38:40,980][INFO ][plugins ] [aAmiW40] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy, transport-netty], plugins [] [2016-07-15 19:38:43,218][INFO ][node ] [aAmiW40] initialized ``` Needless to say, settings `node.name` explicitly still works as before. The commit also contains some clean ups to the relationship between Environment, Settings and Plugins. The previous code suggested the path related settings could be changed after the initial Environment was changed. This did not have any effect as the security manager already locked things down.
2016-07-23 22:46:48 +02:00
new ElasticsearchUncaughtExceptionHandler(() -> Node.NODE_NAME_SETTING.get(environment.settings())));
Persistent Node Names (#19456) With #19140 we started persisting the node ID across node restarts. Now that we have a "stable" anchor, we can use it to generate a stable default node name and make it easier to track nodes over a restarts. Sadly, this means we will not have those random fun Marvel characters but we feel this is the right tradeoff. On the implementation side, this requires a bit of juggling because we now need to read the node id from disk before we can log as the node node is part of each log message. The PR move the initialization of NodeEnvironment as high up in the starting sequence as possible, with only one logging message before it to indicate we are initializing. Things look now like this: ``` [2016-07-15 19:38:39,742][INFO ][node ] [_unset_] initializing ... [2016-07-15 19:38:39,826][INFO ][node ] [aAmiW40] node name set to [aAmiW40] by default. set the [node.name] settings to change it [2016-07-15 19:38:39,829][INFO ][env ] [aAmiW40] using [1] data paths, mounts [[ /(/dev/disk1)]], net usable_space [5.5gb], net total_space [232.6gb], spins? [unknown], types [hfs] [2016-07-15 19:38:39,830][INFO ][env ] [aAmiW40] heap size [1.9gb], compressed ordinary object pointers [true] [2016-07-15 19:38:39,837][INFO ][node ] [aAmiW40] version[5.0.0-alpha5-SNAPSHOT], pid[46048], build[473d3c0/2016-07-15T17:38:06.771Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_51/25.51-b03] [2016-07-15 19:38:40,980][INFO ][plugins ] [aAmiW40] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy, transport-netty], plugins [] [2016-07-15 19:38:43,218][INFO ][node ] [aAmiW40] initialized ``` Needless to say, settings `node.name` explicitly still works as before. The commit also contains some clean ups to the relationship between Environment, Settings and Plugins. The previous code suggested the path related settings could be changed after the initial Environment was changed. This did not have any effect as the security manager already locked things down.
2016-07-23 22:46:48 +02:00
INSTANCE.setup(true, environment);
2015-05-04 10:18:09 -04:00
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
try {
// any secure settings must be read during node construction
IOUtils.close(keystore);
} catch (IOException e) {
throw new BootstrapException(e);
}
Settings: Add infrastructure for elasticsearch keystore This change is the first towards providing the ability to store sensitive settings in elasticsearch. It adds the `elasticsearch-keystore` tool, which allows managing a java keystore. The keystore is loaded upon node startup in Elasticsearch, and used by the Setting infrastructure when a setting is configured as secure. There are a lot of caveats to this PR. The most important is it only provides the tool and setting infrastructure for secure strings. It does not yet provide for keystore passwords, keypairs, certificates, or even convert any existing string settings to secure string settings. Those will all come in follow up PRs. But this PR was already too big, so this at least gets a basic version of the infrastructure in. The two main things to look at. The first is the `SecureSetting` class, which extends `Setting`, but removes the assumption for the raw value of the setting to be a string. SecureSetting provides, for now, a single helper, `stringSetting()` to create a SecureSetting which will return a SecureString (which is like String, but is closeable, so that the underlying character array can be cleared). The second is the `KeyStoreWrapper` class, which wraps the java `KeyStore` to provide a simpler api (we do not need the entire keystore api) and also extend the serialized format to add metadata needed for loading the keystore with no assumptions about keystore type (so that we can change this in the future) as well as whether the keystore has a password (so that we can know whether prompting is necessary when we add support for keystore passwords).
2016-12-22 16:28:34 -08:00
2015-05-04 14:06:32 -04:00
INSTANCE.start();
2015-05-04 10:18:09 -04:00
if (closeStandardStreams) {
2015-05-04 10:18:09 -04:00
closeSysError();
}
} catch (NodeValidationException | RuntimeException e) {
// disable console logging, so user does not see the exception twice (jvm will show it already)
final Logger rootLogger = ESLoggerFactory.getRootLogger();
final Appender maybeConsoleAppender = ServerLoggers.findAppender(rootLogger, ConsoleAppender.class);
if (foreground && maybeConsoleAppender != null) {
ServerLoggers.removeAppender(rootLogger, maybeConsoleAppender);
}
Logger logger = Loggers.getLogger(Bootstrap.class);
2015-05-04 14:06:32 -04:00
if (INSTANCE.node != null) {
Persistent Node Names (#19456) With #19140 we started persisting the node ID across node restarts. Now that we have a "stable" anchor, we can use it to generate a stable default node name and make it easier to track nodes over a restarts. Sadly, this means we will not have those random fun Marvel characters but we feel this is the right tradeoff. On the implementation side, this requires a bit of juggling because we now need to read the node id from disk before we can log as the node node is part of each log message. The PR move the initialization of NodeEnvironment as high up in the starting sequence as possible, with only one logging message before it to indicate we are initializing. Things look now like this: ``` [2016-07-15 19:38:39,742][INFO ][node ] [_unset_] initializing ... [2016-07-15 19:38:39,826][INFO ][node ] [aAmiW40] node name set to [aAmiW40] by default. set the [node.name] settings to change it [2016-07-15 19:38:39,829][INFO ][env ] [aAmiW40] using [1] data paths, mounts [[ /(/dev/disk1)]], net usable_space [5.5gb], net total_space [232.6gb], spins? [unknown], types [hfs] [2016-07-15 19:38:39,830][INFO ][env ] [aAmiW40] heap size [1.9gb], compressed ordinary object pointers [true] [2016-07-15 19:38:39,837][INFO ][node ] [aAmiW40] version[5.0.0-alpha5-SNAPSHOT], pid[46048], build[473d3c0/2016-07-15T17:38:06.771Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_51/25.51-b03] [2016-07-15 19:38:40,980][INFO ][plugins ] [aAmiW40] modules [percolator, lang-mustache, lang-painless, reindex, aggs-matrix-stats, lang-expression, ingest-common, lang-groovy, transport-netty], plugins [] [2016-07-15 19:38:43,218][INFO ][node ] [aAmiW40] initialized ``` Needless to say, settings `node.name` explicitly still works as before. The commit also contains some clean ups to the relationship between Environment, Settings and Plugins. The previous code suggested the path related settings could be changed after the initial Environment was changed. This did not have any effect as the security manager already locked things down.
2016-07-23 22:46:48 +02:00
logger = Loggers.getLogger(Bootstrap.class, Node.NODE_NAME_SETTING.get(INSTANCE.node.settings()));
2010-02-08 15:30:06 +02:00
}
// HACK, it sucks to do this, but we will run users out of disk space otherwise
if (e instanceof CreationException) {
// guice: log the shortened exc to the log file
ByteArrayOutputStream os = new ByteArrayOutputStream();
PrintStream ps = null;
try {
ps = new PrintStream(os, false, "UTF-8");
} catch (UnsupportedEncodingException uee) {
assert false;
e.addSuppressed(uee);
}
new StartupException(e).printStackTrace(ps);
ps.flush();
try {
logger.error("Guice Exception: {}", os.toString("UTF-8"));
} catch (UnsupportedEncodingException uee) {
assert false;
e.addSuppressed(uee);
}
} else if (e instanceof NodeValidationException) {
logger.error("node validation exception\n{}", e.getMessage());
} else {
// full exception
logger.error("Exception", e);
}
// re-enable it if appropriate, so they can see any logging during the shutdown process
if (foreground && maybeConsoleAppender != null) {
ServerLoggers.addAppender(rootLogger, maybeConsoleAppender);
}
throw e;
2010-02-08 15:30:06 +02:00
}
}
@SuppressForbidden(reason = "System#out")
private static void closeSystOut() {
System.out.close();
}
@SuppressForbidden(reason = "System#err")
private static void closeSysError() {
System.err.close();
}
private static void checkLucene() {
if (Version.CURRENT.luceneVersion.equals(org.apache.lucene.util.Version.LATEST) == false) {
throw new AssertionError("Lucene version mismatch this version of Elasticsearch requires lucene version ["
+ Version.CURRENT.luceneVersion + "] but the current lucene version is [" + org.apache.lucene.util.Version.LATEST + "]");
}
}
2010-02-08 15:30:06 +02:00
}