I need to increase the amount of fields supported for free-text queries in a hosted environment of ELK. I know that the setting is called indices.query.bool.max_clause_count and should be changed in the elasticsearch.yml file on self-hosted installations. But apparently this setting cannot be changed in the cloud according to:
https://www.elastic.co/guide/en/cloud/current/ec-add-user-settings.html#ec-es-elasticsearch-settings
Does anyone have a solution to this?
PS: Without increasing this setting the search-capabilities inside the apm-based index-patterns are severely limited because the number of fields in apm v7.1.16 and later has more than 1024 fields.
Related
I'm working on a project for which I need to collect all the Spark config.
The problem is that if a parameter is not explicitly set, I would need the default value. Is there a way to get all the config, including all defaults?
I tried with:
sc.getConf.getAll, but in this way, I do not get the defaults.
SparkListener, in order to get some specific information (for example the number of executors), but I couldn't find a way to get other needed information like the number of cores per executor, memory per executor etc...
In sidekick, I can create as many versions of a page and can restore as well.
What I am looking for is, how to limit the number of "creation of page versions" . Suppose, after 5 versions I want to display an error - "more versions are not allowed".
I followed the link for reference but no luck: http://www.wemblog.com/2012/08/how-to-work-with-version-in-cq.html
You have to create a osgi:Config within repository for this (com.day.cq.wcm.core.impl.VersionManagerImpl).
You can control number of version created by activation by setting versionmanager.maxNumberVersions property.
Thanks in advance
There is no pro-active way to stop any versions from being created in the AEM repository. The configuration you are referring to is from: https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/version-purging.html#Version Manager
versionmanager.maxNumberVersions (int, default 5)
on purge, any version older than the n-th newest version will be removed. If this value is less than 1, purging is not performed based on the number of versions
This is the setting for version purge task which retains a maximum of n number of versions after purging where n is the number defined in the above config.
A preemptive version disabler won't work as versions are created from background tasks like workflows asynchronously. These tasks will fail without any feedback to user which will be problematic in most scenarios.
If you want to change the sidekick and disallow version creation, then you will have to rewrite core logic of the UI which can be a big task. Version Purging is the recommended way to setup your instance to limit the number of versions.
Well, normally I'm not the person intended to do that, I'm a PHP developer and have general knowledge about Apache and security administration, but for emergency only I have to do this now.
I'm in a situation where I need to write Mod_Security rule that:
- blocks specific IP address from access our website,
- for 5 minutes
- if it try to call more than 10 links in less than 10 seconds
Can I achieve that writing a mod_security rule?
ModSecurity can do this, but wouldn't suggest it.
Have a look at the DOS rules in the OWASP CRS: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/experimental_rules/modsecurity_crs_11_dos_protection.conf. Note these do depend on set up in the main CRS setup file: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/modsecurity_crs_10_setup.conf.example
However ModSecurity collections are not the most stable especially for high volume. You run into problems with multiple threads accessing the collection file. Also might find you have to delete the collection file regularly (e.g. every 24 hours) to prevent it continually growing.
I was getting error "FORM too large" when I submit a form containing many data. As default size for JETTY server is 2 mb and my form size is exceeded.
I solved the issue locally by using system argument in Eclipse ie by setting max form content to -1, which means no limit to form content. But the problem is in UAT environment. How to do that, if we cannot use Eclipse?
Does any one know how to provide this configuration in JETTY or TOMCAT directly so that max form content is unlimited. I have tried the same configuration in start.ini file in JETTY but it is not working in UAT.
Please geeks share your idea,if any.
Thanks
Unlimited form content size is actually a form of vulnerability. (Look into how map hash key collision can be a harsh form of DOS attack)
Are you really sure you need to send 2MB of form data?
Note: multipart/form-data content that are FILES (not form fields) are handled with different max size configurations.
Look into the <multipart-config> entries in WEB-INF/web.xml or #MultiPartConfig annotations for more about those limits.
I'm having some issues with the installation of Rational Team Concert on my server.
The thing is that when I upload some changes to the server (any kind), it changes the last modified attribute of the file, but it shouldn't do it.
Is there a way to avoid this behavior?
Thank you in advance!
This is something that we have tried to add to RTC SCM (and we still plan to). However, we found that it needs to be an option on load/update.
There are numerous details and discussions available # this work item on jazz.net
Regarding timestamp, getting over the fact that relying on it in a version control tool isn't always considered a best-practice (see "What's the equivalent of use-commit-times for git?"), it is actually a complex issue:
an SCM loader wouldn't use just timestamp to determined what file has changed (Task 179263)
you can have various requirements for that timestamp (like in Defect 159043, where the file timestamp of the modified file on disk that of when it was delivered, not when I accepted.). The variable JAZZ_CCM_SKIP_MOD_TIME=true is mentioned so check if that could improve your specific case.
it is all based on the assumption the timestamp is correctly set by the local workstation, which isn't always true, as illustrated in Task 77201