Gerrit plugins can contribute to submit rules evaluation, that are a
part of secondary index. Therefore it is crucial that plugins are
loaded prior to triggering of online reindexing.
This change de-couples online reindex activation from index module and
thus postpones the triggering of online reindexing until after loading
of the plugins:
1. Load secondary index
2. Load all plugins
3. Trigger online reindex if needed
Bug: Issue 10082
Change-Id: I1706d42cb50eb342c2b9eca076e2def5bd1426c0
Loading plugins before activating the index breaks any plugin that
relies on the index. This is more of a problem in 2.15 since the
caches refer to the index, and therefore breaks any plugin that
relies on caches.
This reverts commit 86a1dd735cbd14dab9eb05a0b2dbfd862ce8c8d9.
Bug: Issue 10082
Change-Id: I99f81cfdadf4e652e2cfe72c6dc6b3686de3a806
Before this change only git over SSH commands were audited, this
change allows auditing of git-receive-pack and git-upload-pack
commands over http.
To allow testing AuditService is now an interface so that a fake
implementation can be injected in the tests.
Bug: Issue 9982
Change-Id: Iffcd0fbd7332ef0f6b4b4a8e57bb5d571ee4cb39
* stable-2.14:
GitOverHttpModule: Bind REST auth filter in its own module
Ensure user authentication in AllRequestFilter filters
Change-Id: I873737ead014c20f0590ab0f246e9ded0601e4ef
* changes:
InitSshd: Use correct flag to set empty passphrase
SshSession: Specify charset in constructor of Scanner
Specify charset in constructors of InputStreamReader
GitOverHttpModule is binding both filters for git over HTTP and for REST
requests. Extract filter definition for REST requests in its own module.
Change-Id: If03e76c906bc3e0cac827b49f5f087cc859be4cd
The current order of filters declaration make request authentication
only work when HTTP request is issued from the Gerrit UI, but not
work when REST API is used.
In Daemon#createWebInjector() we have this:
[...]
modules.add(RequestContextFilter.module());
modules.add(AllRequestFilter.module());
modules.add(RequestMetricsFilter.module());
modules.add(H2CacheBasedWebSession.module());
modules.add(sysInjector.getInstance(GitOverHttpModule.class));
[...]
The are two major use cases to consider:
1. Gerrit UI request: when authenticated user session is found and set
in RequestContextFilter, before AllRequestFilter, that's why in
AllRequestFilter we have a user:
Account: 1000000 username: admin
2. REST API request, e.g.:
curl --user user http://localhost:8080/a/config/server/version
"2.14.7-9-g9ebfce95b7-dirty"
Here the AllRequestFilter is bound before GitOverHttpModule, that
provides ProjectBasicAuthFilter filter, and thus, there is no identified
user:
anonymous
Adapt the AllRequestFilter registration order to fix authentication also
for REST API requests.
This is needed for Javamelody's monitoring filter to work properly for
Prometheus scraping request:
curl -u user http://localhost:8080/a/monitoring?format=prometheus
There is more context and discussions in these CLs:
https://gerrit-review.googlesource.com/c/plugins/javamelody/+/192411https://gerrit-review.googlesource.com/c/plugins/javamelody/+/192170https://gerrit-review.googlesource.com/c/gerrit/+/164991
Change-Id: I925e952474440cb612080dafd917a01dba8f3330
* stable-2.14:
InitSshd: Use correct flag to set empty passphrase
SshSession: Specify charset in constructor of Scanner
Specify charset in constructors of InputStreamReader
Update JGit dependencies to fix building from source
Change-Id: I994d9d26bb7a1b1333a6380fb81126c1e8dc026d
From https://www.ssh.com/ssh/keygen/:
-N "New" Provides a new passphrase for the key.
-P "Passphrase" Provides the (old) passphrase when reading a key.
PiperOrigin-RevId: 210948400
Change-Id: Iba3a674f81686987fef60f0fd5a5f42aa5b9dd86
When gerrit.sh gets started from a non-root user, the JVM PID is not
protected against the Kernel OOM killer attacks.
Instead of silently ignoring the setting, display a warning making aware
of the danger and telling the user what to do.
Bug: Issue 9514
Change-Id: I4c1c0e06b260e75d900f436d37f0b91d031cd24e
* stable-2.14:
ConfigInfoImpl: Factor out initialization of MaxObjectSizeLimitInfo to a method
Rename instances of TransferConfig to transferConfig
Clarify inherited_value in documentation of MaxObjectSizeLimitInfo
Reword docmentation of project specific object size limit for clarity
PutConfig: Reload project config before returning response
SiteProgram: Extract local variable
SiteProgram: Extract constant
SiteProgram: Inline variable to avoid hiding field
DataSourceProvider: Rename local variable to avoid hiding field
DataSourceProvider: Remove unneeded finals
DataSourceProvider: Replace inner class with lambda
DataSourceProvider: Extract constant
Migrate `tools/bazel.rc` to `.bazelrc`
ProjectIT: Add tests for maxObjectSize configuration
EventRecorder: Add assertNoRefUpdatedEvents helper method
ProjectIT: Rename 'config' method to 'submitType'
Change-Id: If803aa7390a2644c3ccd9baa04e1b874c3de5d40
The issue here was that Sonar complains about 'ifs' that can be merged
but doing so was less readable than just extracting a local variable.
Change-Id: I5898fd2860fc7d54e6ff04376e3b4ea0120ca8fa
* stable-2.14:
Minor improvements in receive.maxObjectSizeLimit documentation
Bazel: Consume rules_closure from HEAD
Bump auto-value to 1.6.2
Change-Id: I401942a40c5001300f77f9437d342001cd42e619
* stable-2.14:
ElasticTestUtils: Set index.maxLimit as integer rather than string
ElasticConfigurationTest: Add tests for elasticsearch.maxRetryTimeout
ElasticConfigurationTest: Add tests for elasticsearch.prefix
ElasticConfigurationTest: Add tests for elasticsearch.{username,password}
ElasticConfiguration: Extract constants to statics
Elasticsearch: Simplify configuration of servers
Change-Id: Ic579d37734f285043f2d5ea9b764ec75cb485768
Instead of configuring each server in its own section with separate
values for protocol, host and port, i.e.:
[elasticsearch "elastic1"]
hostname = elastic1
protocol = https
port = 1234
[elasticsearch "elastic2"]
hostname = elastic2
protocol = https
port = 1234
Configure them all under the main "elasticsearch" section as multiple
values, i.e.
[elasticsearch]
server = https://elastic1:1234
server = https://elastic2:1234
Allow the port to be omitted, and default it to 9200.
Require at least one server to be explicitly configured and throw a
provision exception if there are none.
During init prompt for the server, defaulting to http://localhost:9200.
Since the init framework doesn't support reading or setting string lists,
if there are multiple server values it will prompt the last one. Mention
in the documentation that configuration of multiple servers must be done
manually.
Since it is not expected that Elasticsearch is being used in production
anywhere, no backwards compatibility with the previous configuration is
provided. Users must adjust their configuration to the new format.
Add a new test, ElasticConfigurationTest, which in this initial version
only tests the configuration of the elasticsearch.server. More tests may
be added in follow-up commits.
Bug: Issue 9372
Bug: Issue 9383
Change-Id: Iad2c547ae82ba89b7ede777072e0869bc77d2025
Reformat all files with the exception of:
- lib/asciidoctor/java/AsciiDoctor.java
to avoid requiring the Library-Compliance label.
Change-Id: Iedba3f24ac00e2186e3e0688fabea817ddf43739
Reformat all files with the exception of:
- lib/asciidoctor/java/AsciiDoctor.java
to avoid requiring the Library-Compliance label.
Change-Id: Iedba3f24ac00e2186e3e0688fabea817ddf43739
* stable-2.14:
Use Logger's built-in string formatting where possible
Doc: Fix code example in JS API
Change-Id: I1b953b6d9ab5cd066b8b6f43bb1843dcb1736d1b
* stable-2.14:
Update git submodules
Update git submodules
ldap.Helper: Use local logger and make logger in LdapRealm private
Remove ValidationError#createLoggerSink to avoid passing around loggers
LdapLoginServlet: Improve exception handling
OperatingSystemMXBeanProvider: Log exception for ReflectiveOperationException
WorkQueue: Don't fail when queue metric already exists
WorkQueue: Sanitize metric name when queue is created
DropWizardMetricMaker: Introduce method to sanitize metric name
Change-Id: I4729d537aeb5ef934fcae90b610e28966a6ada9a
Passing loggers between classes is bad and we should avoid this if
possible.
ValidationError#createLoggerSink required to pass in a logger just to
return it back to the caller wrapped in a lambda. Remove this method and
instead create the lambda directly in the caller. This brings us minimal
code duplication for formatting the message, but it's better than
passing the logger around.
Change-Id: I6b475de50fb2a1745c16ac424e0a95d358aaaf7d
Signed-off-by: Edwin Kempin <ekempin@google.com>
* stable-2.14:
HttpPluginServlet: Don't trim leading whitespace from about.md content
ProjectConfig: Don't use JGit's StringUtils to convert to lower case
Do not abort indexing if < 50% projects failed
Revert "AllChangesIndexer: Don't abort when failing to open repository"
VersionedAccountDestinations: Remove unused createSink(String) method
ProjectBasicAuthFilter: Add comment why cause is not logged
BazelBuild: Fix exception message when command was interrupted
GitwebServlet: Write only one log entry for CGI errors
GitwebServlet: Log unexpected errors on error level
PostGpgKeys: Remove unneeded use of Joiner
Remove some logs for errors that are rethrown
DropWizardMetricMaker: Improve error messages for invalid arguments
DropWizardMetricMaker: Improve error message when metric name is invalid
AllChangesIndexer: Don't abort when failing to open repository
Change-Id: I6febb890b7717731fcb5f0653360982668469069
"log and throw" is considered a poor practice. The logging is uneeded
since the thrown exception will be logged somewhere else.
Change-Id: I82c210fe1e053a4ffd7a58b7fc7de6056f9875a7
Signed-off-by: Edwin Kempin <ekempin@google.com>
CacheImpl [1] introduced the possibility to overload core Gerrit
module with one that is provided by library. This change
generalizes it so that any Gerrit core module can be overloaded.
How to overload Gerrit core module:
* identify module that needs to be overloaded and mark it with
@ModuleImpl(name="moduleX") annotation; note that circular dependencies
from different module qualifies particular instance as non-candidate
* build lib module that provides alternative implementation
to the module in question and mark it with the same
annotation
* place implementation jar under GERRIT_SITE/lib dir and add
gerrit.installModule entry with your.package.Module path to
gerrit.config.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/173162
Change-Id: Ic6dac8d1cc558abdcfd7a1cc257dbd7f8924ff9b
Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>
The memory cache doesn't depend on H2 at all, and this separation of
packages makes it harder to reintroduce the kind of source-level
dependency that was removed in I570fd54adf.
Change-Id: Ie23e39cd7ea9a0813a914e65614b889c248342ae
There is existing mechanism to provide different implementation for
instance to secure-store but one can replace only certain binding
with it (through provider class). In this case when H2CacheImpl is
installed it adds more bindings and replacing only this class would
keep leftovers being still initiated/running in Gerrit core.
CacheImpl annotation contains 2 types:
MEMORY
PERSISTENT
It is applied to modules that provide corresponding default caches
implementations.
When CacheImpl annotation is added to lib module then it will
override particular default implementation.
Change-Id: I7562b210fad4c5f6dc67887f627cf76815a378cb
Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>
There is mutual dependency between these 2 implementations
(including Guice module that is responsible for installing them)
and it prevents from providing alternative implementations.
Change-Id: I570fd54adf58c466925f4a31a3bf3cd5ace8742c
Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>
Add a new setting, http.addUserAsResponseHeader, which when enabled
causes the servlet response to include a 'User' header that contains
the name of the logged in user.
This will enable reverse proxies to log the name of the user that
issued the http request.
The new setting is disabled by default.
Change-Id: I5c3c783813f3aa71209320610bb8168a51305cba
Binding the class with in(SINGLETON) creates a singleton per injector,
and because it is done in two injectors (the SSH injector and the HTTP
injector), we end up with two instances and thus two work queues for
both SSH-Interactive-Worker and SSH-Batch-Worker.
Remove the in(SINGLETON) and instead explicitly make the class singleton
by annotating with @Singleton
Change-Id: Ifa782b7ea7f97d88d0afdfa9efc87ad7baa15b93
Signed-off-by: Eryk Szymanski <eryksz@gmail.com>
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
* stable-2.14:
SshCommandsIT: Include `logging ls` and `logging set` commands
Add tests to make sure ssh commands can be executed
Align ElasticIndexModule with LuceneIndexModule
Revert "Remove unneeded nested MultiVersionModule class"
Remove unneeded nested MultiVersionModule class
Only bind index {start/activate} if needed
InitIndex: Allow to configure index.maxLimit for Elasticsearch
Change-Id: Icf925e3724ca6974831676e505692807a771e70b
These commands are only interacting with the AbstractVersionManager, if
it is not available then they have no reason to be available.
Because those commands were always binded, binding an implementation of
AbstractVersionManager was mandatory otherwise Guice would have
complained. For that reason, the implementation of
AbstractVersionManager was done even in the case when index is a single
version and an implementation of AbstractVersionManager is not required.
Only bind implementations of AbstractVersionManager when needed and bind
the commands only if AbstractVersionManager implementation is binded.
Change-Id: I3db48f6b5d030ecc6efa840c59eb4e177ae1b6b1
When using the Elasticsearch secondary index, `index.maxLimit` should
not exceed the value of `index.max_result_window` configured on the
Elasticsearch server.
By default `index.maxLimit` is not set, which effectively means that the
value used is Integer.MAX_VALUE. When Elasticsearch is used out of the
box the default `index.max_result_window` is 10000, and this results in
query failures:
"Result window is too large, from + size must be less than or equal
to: [10000] but was [2147483647]."
When the index type is Elasticsearch, prompt for the max limit during
initialization, defaulting to Elasticsearch's default value of 10000.
Bug: Issue 8527
Change-Id: I983a83b5cdd0eaf5ba875c3310dfd484e53fe064
