cwielenb/CNCF-Dataset huggingface dataset:
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.11.9.md

RabbitMQ `3.11.9` is a maintenance release in the `3.11.x` . Please refer to the upgrade section from if upgrading from a version prior to 3.11.0. This release requires Erlang 25. has more details on Erlang version requirements for RabbitMQ. As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases. Erlang 25 as our new baseline means much improved performance on ARM64 architectures, across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users. Release notes can be found on GitHub at . Stream delivery using v2 could fail to start in some cases. GitHub issue: Nodes could run into an exception with certain publishers that used QPid for client library. GitHub issue: When discovering feature flags across the cluster, default stability level is now `experimental` and not `stable`. GitHub issue: Reset and manually added nodes could start receiving stream replica data before its database was initialized, confusing all code paths that expected a blank node state. GitHub issue: Fixed a minor issue with feature flag log message formatting. GitHub issue: Improved support for the AMQP 1.0 message format (used internally by streams), in particular, when original message was published using AMQP 1.0. GitHub issue: `rabbitmqctl setpermissionsglobally` is a new command that sets up user permissions in all existing virtual hosts. GitHub issue: `rabbitmq-diagnostics cluster_status` now lists how many CPU cores are available to individual nodes, plus a total. GitHub issue: Limits tab failed to load when there were no limits configured. GitHub issue: It is now possible to disable operator policy modifications. This can be necessary in RabbitMQ-as-a-Service environments. Contributed by @illotum (AWS). GitHub issue: Support for . GitHub issue: MQTT nodes did not correctly remove client IDs for clients connected to a node that was in the process of being removed from the cluster. GitHub issue: `authoauth2.additionalscopes_key` had no effect. Contributed by @brunomedeirosdedalus. GitHub issue: Due to a `$` sign escaping differences between Make and Bazel (the newly adopted build tool), default value of of `userdnpattern` setting was incorrect (had an extra `$`). GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.11.9.tar.xz` instead of the source tarball produced by GitHub.
Project: KICS (Provisioning / Security & Compliance)
File: d24c0755-c028-44b1-b503-8e719c898832.md

title: S3 Bucket Allows Put Action From All Principals hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: d24c0755-c028-44b1-b503-8e719c898832 Query name: S3 Bucket Allows Put Action From All Principals Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Access Control URL: S3 Buckets must not allow Put Action From All Principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering / deletion. This means the 'Effect' must not be 'Allow' when the 'Action' is Put, for all Principals.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="4" resource "awss3bucket_policy" "positive1" { bucket = awss3bucket.b.id policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="5" resource "awss3bucket_policy" "positive2" { bucket = awss3bucket.b.id policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Positive test num. 3 - tf file" hl_lines="12" module "s3_bucket" { source = "terraform-aws-modules/s3-bucket/aws" version = "3.7.0" bucket = "my-s3-bucket" acl = "private" versioning = { enabled = true } policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Negative test num. 1 - tf file" resource "awss3bucket_policy" "negative1" { bucket = awss3bucket.b.id policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Negative test num. 2 - tf file" module "s3_bucket" { source = "terraform-aws-modules/s3-bucket/aws" version = "3.7.0" bucket = "my-s3-bucket" acl = "private" versioning = { enabled = true } policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ```
Project: Strimzi (App Definition and Development / Streaming & Messaging)
File: KAFKA_VERSION_SUPPORT.md

It is not feasible to maintain support for all available Apache Kafka versions. The following rules describe our plans for Kafka versions supported in Strimzi: Support at least the last two major/minor versions of Apache Kafka. For example: Support for Kafka 2.2.x could be removed when support for 2.4.x is added. Support at least one common Kafka release in two consecutive major/minor Strimzi releases to allow smooth upgrades between Strimzi and Kafka versions. For example: when Strimzi 0.13.x supports Kafka 2.2.0 and 2.3.0, Strimzi 0.14.x has to provide support for 2.3.0 as well.
Project: Harbor (Provisioning / Container Registry)
File: 7-15-Endpoints-endpoints-filter.md

Test 7-15 Endpoints endpoints filter ======= To verify endpoints filter works correctly. User guide This test requires at least one Harbor instance is running and available. There are a few endpoints in the system. Login UI as admin user. In `Administration->Registries`,add some endpoints. Input some characters in endpoints filter and then clear the filter. In step3, endpoints can be filtered, after clearing the filter, all endpoints should be shown again. None
Project: Redis (App Definition and Development / Database)
File: feature_request.md

name: Feature request about: Suggest a feature for Redis title: '[NEW]' labels: '' assignees: '' The problem/use-case that the feature addresses A description of the problem that the feature will solve, or the use-case with which the feature will be used. Description of the feature A description of what you want to happen. Alternatives you've considered Any alternative solutions or features you've considered, including references to existing open and closed feature requests in this repository. Additional information Any additional information that is relevant to the feature request.
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: sup_pkg_config.md

+++ title = "Supervisor Configuration" description = "Configure the Supervisor for faster package development" gh_repo = "habitat" [menu] [menu.habitat] title = "Supervisor Package Configuration" identifier = "habitat/supervisors/sup-pkg-config" parent = "habitat/supervisors" weight = 100 +++ To assist in creating new packages, or modifying existing ones, the Supervisor has an option to allow you to use the configuration directly from a specific directory, rather than the one it includes in the compiled artifact. This can significantly shorten the cycle time when working on configuration and application lifecycle hooks. Build the plan as you normally would. When you start the Supervisor, pass the name of the directory with your plan inside it: ```bash $ hab sup run core/redis --config-from /src ``` The Supervisor will now take its configuration and hooks from /src, rather than from the package you previously built. When the configuration is as you want it, do a final rebuild of the package.
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.3.0.0-alpha3.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Blocker | Root privilege escalation in experimental Docker support* CVE-2017-7669 / YARN's Docker support did not do enough input validation. This allowed a root level escalation from an ordinary user account.
Project: external-secrets (Provisioning / Security & Compliance)
File: webhook.md

External Secrets Operator can integrate with simple web apis by specifying the endpoint First, create a SecretStore with a webhook backend. We'll use a static user/password `root`: ```yaml {% raw %} apiVersion: external-secrets.io/v1beta1 kind: SecretStore metadata: name: webhook-backend spec: provider: webhook: url: "http://httpbin.org/get?parameter={{ .remoteRef.key }}" result: jsonPath: "$.args.parameter" headers: Content-Type: application/json Authorization: Basic {{ print .auth.username ":" .auth.password | b64enc }} secrets: name: auth secretRef: name: webhook-credentials {%- endraw %} apiVersion: v1 kind: Secret metadata: name: webhook-credentials data: username: dGVzdA== # "test" password: dGVzdA== # "test" ``` NB: This is obviously not practical because it just returns the key as the result, but it shows how it works NOTE: In case of a `ClusterSecretStore`, Be sure to provide `namespace` in all `secrets` references with the namespaces where the secrets reside. Now create an ExternalSecret that uses the above SecretStore: ```yaml apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: webhook-example spec: refreshInterval: "15s" secretStoreRef: name: webhook-backend kind: SecretStore target: name: example-sync data: secretKey: foobar remoteRef: key: secret kind: Secret metadata: name: example-sync data: foobar: c2VjcmV0 ``` Webhook does not support authorization, other than what can be sent by generating http headers !!! note If a webhook endpoint for a given `ExternalSecret` returns a 404 status code, the secret is considered to have been deleted. This will trigger the `deletionPolicy` set on the `ExternalSecret`. Generic WebHook provider uses the templating engine to generate the API call. It can be used in the url, headers, body and result.jsonPath fields. The provider inserts the secret to be retrieved in the object named `remoteRef`. In addition, secrets can be added as named objects, for example to use in authorization headers. Each secret has a `name` property which determines the name of the object in the templating engine. ```yaml apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: statervault spec: provider: webhook: url: <url> method: <method> timeout: 1s result: jsonPath: <jsonPath> headers: <Header-Name>: <header contents> body: <body> secrets: name: <name> secretRef: namespace: <namespace> # Only used in ClusterSecretStores name: <name> caBundle: <base64 encoded cabundle> caProvider: type: Secret or ConfigMap name: <name of secret or configmap> namespace: <namespace> # Only used in ClusterSecretStores key: <key inside secret> ``` You can also leverage webhooks as generators, following the same syntax. The only difference is that the webhook generator needs its source secrets to be labeled, as opposed to webhook secretstores. Please see the documentation for more information.
Project: OceanBase (App Definition and Development / Database)
File: pull_request_template.md

<!-- Thank you for contributing to OceanBase! Please read the document BEFORE filling this PR. If this pull request have a significant impact, please make sure you have discussed with OceanBase group. --> <!-- The problem you resolved by this pull request. You can link the issue via the "close #xxx" or "ref #xxx". --> <!-- Please clearly and consice descipt the solution. --> <!-- Unittest, mysql test or test it manually? --> <!-- Please make sure this is compatible with old version or you should give us upgrading solution. --> <!-- Any information helping to review this pull request. --> <!-- A concise release note can help users to understand how your pull request makes difference. -->
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.9.13.md

RabbitMQ `3.9.13` is a maintenance release in the `3.9.x` release series. Please refer to the Upgrading to 3.9 section from if upgrading from a version prior to 3.9.0. This release requires at least Erlang 23.2, and supports Erlang 24. has more details on Erlang version requirements for RabbitMQ. Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and a more consistent release schedule. Disk space monitor now correctly parses output on (at least some) systems where non-ASCII characters are used in paths. GitHub issue: Stream leader election is now deterministic when cluster is undergoing a rolling upgrade. GitHub issue: Queue and binding can be delayed until a moment when at least N nodes (e.g. three) have joined the cluster. This way imported quorum queues will have a desired number of replicas from the start. GitHub issue: Osiris was To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.9.13.tar.xz` instead of the source tarball produced by GitHub.
Project: ClickHouse (App Definition and Development / Database)
File: uniq.md

slug: /en/sql-reference/aggregate-functions/reference/uniq sidebar_position: 190 Calculates the approximate number of different values of the argument. ``` sql uniq(x[, ...]) ``` Arguments The function takes a variable number of parameters. Parameters can be `Tuple`, `Array`, `Date`, `DateTime`, `String`, or numeric types. Returned value A -type number. Implementation details Function: Calculates a hash for all parameters in the aggregate, then uses it in calculations. Uses an adaptive sampling algorithm. For the calculation state, the function uses a sample of element hash values up to 65536. This algorithm is very accurate and very efficient on the CPU. When the query contains several of these functions, using `uniq` is almost as fast as using other aggregate functions. Provides the result deterministically (it does not depend on the query processing order). We recommend using this function in almost all scenarios. See Also
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_filestore_instances.md

+++ title = "googlefilestoreinstances resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlefilestoreinstances" identifier = "inspec/resources/gcp/googlefilestoreinstances.md googlefilestoreinstances resource" parent = "inspec/resources/gcp" +++ A `googlefilestoreinstances` is used to test a Google Instance resource ```ruby describe googlefilestoreinstances(project: 'chef-gcp-inspec', zone: 'us-central1-b') do its('tiers') { should include 'PREMIUM' } end ``` Properties that can be accessed from the `googlefilestoreinstances` resource: See the resource for more information. `names` : an array of `googlefilestoreinstance` name `descriptions` : an array of `googlefilestoreinstance` description `create_times` : an array of `googlefilestoreinstance` create_time `tiers` : an array of `googlefilestoreinstance` tier `labels` : an array of `googlefilestoreinstance` labels `file_shares` : an array of `googlefilestoreinstance` file_shares `networks` : an array of `googlefilestoreinstance` networks `etags` : an array of `googlefilestoreinstance` etag `zones` : an array of `googlefilestoreinstance` zone This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method.
Project: StarRocks (App Definition and Development / Database)
File: RETRY_FILE.md

Retries to load all data files or a specific data file in a pipe. This command is supported from v3.2 onwards. ```SQL ALTER PIPE [ IF EXISTS ] <pipename> { RETRY ALL | RETRY FILE '<filename>' } ``` The name of the pipe. The storage path of the data file that you want to retry to load. Note that you must specify the full storage path of the file. If the file you specify does not belong to the pipe you specify in `pipe_name`, an error is returned. The following example retries to load all data files in a pipe named `userbehaviorreplica`: ```SQL ALTER PIPE [ IF EXISTS ] userbehaviorreplica RETRY ALL; ``` The following example retries to load the data file `s3://starrocks-examples/userbehaviortenmillionrows.parquet` in a pipe named `userbehaviorreplica`: ```SQL ALTER PIPE [ IF EXISTS ] userbehaviorreplica RETRY FILE 's3://starrocks-examples/userbehaviortenmillionrows.parquet'; ```
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-network.1.md

% podman-network 1 podman\-network - Manage Podman networks podman network subcommand The network command manages networks for Podman. Podman supports two network backends and . Netavark is the default network backend and was added in Podman version 4.0. CNI is deprecated and will be removed in the next major Podman version 5.0, in preference of Netavark. To configure the network backend use the `network_backend` key under the `[Network]` in . New systems use netavark by default, to check what backend is used run `podman info --format {{.Host.NetworkBackend}}`. All network commands work for both backends but CNI and Netavark use different config files so networks have to be created again after a backend change. | Command | Man Page | Description | | - | -- | | | connect | | Connect a container to a network | | create | | Create a Podman network | | disconnect | | Disconnect a container from a network | | exists | | Check if the given network exists | | inspect | | Display the network configuration for one or more networks | | ls | | Display a summary of networks | | prune | | Remove all unused networks | | reload | | Reload network configuration for containers | | rm | | Remove one or more networks | | update | | Update an existing Podman network | Podman requires specific default IPs and, thus, network subnets. The default values used by Podman can be modified in the file. The default bridge network (called `podman`) uses 10.88.0.0/16 as a subnet. When Podman runs as root, the `podman` network is used as default. It is the same as adding the option `--network bridge` or `--network podman`. This subnet can be changed in under the [network] section. Set the `default_subnet` to any subnet that is free in the environment. The name of the default network can also be changed from `podman` to another name using the default network key. Note that this is only done when no containers are running. When Podman is run as rootless, the internet connectivity is provided with slirp4netns by default. Slirp4nents uses 10.0.2.0/24 for its default network. This can also be changed in but under the ` man page. To change the CIDR for just one container, specify it on the cli using the `--network` option like this: `--network slirp4netns:cidr=192.168.1.0/24`. When using the default network as rootless, i.e. --network podman/bridge, then it also uses the same subnet as described above in addition to the slirp4netns subnet. When a new network is created with a `podman network create` command, and no subnet is given with the --subnet option, Podman starts picking a free subnet from 10.89.0.0/24 to 10.255.255.0/24. Use the `defaultsubnetpools` option under the ` to change the range and/or size that is assigned by default. , ,
Project: Trivy (Provisioning / Security & Compliance)
File: cluster-scanning.md

To test the following commands yourself, make sure that youre connected to a Kubernetes cluster. A simple kind, a Docker-Desktop or microk8s cluster will do. In our case, well use a one-node kind cluster. Pro tip: The output of the commands will be even more interesting if you have some workloads running in your cluster. Trivy K8s is great to get an overview of all the vulnerabilities and misconfiguration issues or to scan specific workloads that are running in your cluster. You would want to use the Trivy K8s command either on your own local cluster or in your CI/CD pipeline post deployments. The `trivy k8s` command is part of the Trivy CLI. With the following command, we can scan our entire Kubernetes cluster for vulnerabilities and get a summary of the scan: ```sh trivy k8s --report=summary ``` To get detailed information for all your resources, just replace summary with all: ```sh trivy k8s --report=all ``` However, we recommend displaying all information only in case you scan a specific namespace or resource since you can get overwhelmed with additional details. Furthermore, we can specify the namespace that Trivy is supposed to scan to focus on specific resources in the scan result: ```sh trivy k8s --include-namespaces kube-system --report summary ``` Again, if youd like to receive additional details, use the --report=all flag: ```sh trivy k8s --include-namespaces kube-system --report all ``` Like with scanning for vulnerabilities, we can also filter in-cluster security issues by severity of the vulnerabilities: ```sh trivy k8s --severity=CRITICAL --report=summary ``` Note that you can use any of the Trivy flags on the Trivy K8s command. The Trivy K8s command is an imperative model to scan resources. We wouldnt want to manually scan each resource across different environments. The larger the cluster and the more workloads are running in it, the more error-prone this process would become. With the Trivy Operator, we can automate the scanning process after the deployment. The Trivy Operator follows the Kubernetes Operator Model. Operators automate human actions, and the result of the task is saved as custom resource definitions (CRDs) within your cluster. This has several benefits: Trivy Operator is installed CRDs in our cluster. As a result, all our resources, including our security scanner and its scan results, are Kubernetes resources. This makes it much easier to integrate the Trivy Operator directly into our existing processes, such as connecting Trivy with Prometheus, a monitoring system. The Trivy Operator will automatically scan your resources every six hours. You can set up automatic alerting in case new critical security issues are discovered. The CRDs can be both machine and human-readable depending on which applications consume the CRDs. This allows for more versatile applications of the Trivy operator. There are several ways that you can install the Trivy Operator in your cluster. In this guide, were going to use the Helm installation based on the Please follow the Trivy Operator documentation for further information on:
Project: StarRocks (App Definition and Development / Database)
File: database.md

displayed_sidebar: "English" Returns the name of the current database. If no database is selected, an empty value is returned. ```Haskell database() ``` This function does not require parameters. Returns the name of the current database as a string. ```sql -- Select a destination database. use db_test -- Query the name of the current database. select database(); ++ | DATABASE() | ++ | db_test | ++ ``` : Switches to a destination database.