cwielenb/CNCF-Dataset huggingface dataset:
Project: Chef InSpec (Provisioning / Security & Compliance)
File: audit_policy.md

+++ title = "audit_policy resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "audit_policy" identifier = "inspec/resources/os/auditpolicy.md auditpolicy resource" parent = "inspec/resources/os" +++ Use the `audit_policy` Chef InSpec audit resource to test auditing policies on the Windows platform. An auditing policy is a category of security-related events to be audited. Auditing is disabled by default and may be enabled for categories like account management, logon events, policy changes, process tracking, privilege use, system events, or object access. For each enabled auditing category property, the auditing level may be set to `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure`. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. An `audit_policy` resource block declares a parameter that belongs to an audit policy category or subcategory: describe audit_policy do its('parameter') { should eq 'value' } end where `'parameter'` must specify a parameter `'value'` must be one of `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure` The following examples show how to use this Chef InSpec audit resource. describe audit_policy do its('Other Account Logon Events') { should_not eq 'No Auditing' } end describe audit_policy do its('User Account Management') { should eq 'Success' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_cluster_describe-ops.md

title: kbcli cluster describe-ops Show details of a specific OpsRequest. ``` kbcli cluster describe-ops [flags] ``` ``` kbcli cluster describe-ops mysql-restart-82zxv ``` ``` -h, --help help for describe-ops ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "$HOME/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use ``` - Cluster command.
Project: Kapitan (Provisioning / Automation & Configuration)
File: advanced.md

Kapitan allows you to define labels in your inventory, which can then be used to group together targets with similar labels. For instance you could define the following: !!! example "" Defines a class to add the `customer` label to selected targets !!! example "`inventory/classes/type/customer_project.yml`" ```yaml parameters: customername: ${targetname} # Defaults to the target_name kapitan: labels: customer: ${customer_name} ``` Apply the class to the target for customer `acme` !!! example "`inventory/targets/customers/acme.yml`" ```yaml classes: ... type.customer_project parameters: ... ``` You can now selectively compile targets for customer `acme` using the following (see see for more details ) !!! example "" ```shell kapitan compile -l customer=acme Compiled acme (0.06s) Compiled acme-documentation (0.09s) ```
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: e5.3.0.en.md

Upgraded ekka to 0.15.13, which incorporates the following changes: Upgraded Mria to 0.6.2. Introduced the ability to configure the bootstrap data sync batch size, as detailed in . Enhanced the reliability of mria_membership processes, as described in . Fix log message formatting error. Added `node.defaultbootstrapbatch_size` option to EMQX configuration. Increasing the value of this option can greatly reduce a replicant node startup time, especially when the EMQX cluster interconnect network latency is high and the EMQX built-in database holds a large amount of data, e.g. when the number of subscriptions is high. Added a new rule-engine SQL function `bytesize` to get the size of a byte-string. e.g. `SELECT * FROM "t/#" WHERE bytesize(payload) > 10`. Updated to quicer version 0.0.200 in preparation for enabling openssl3 support for QUIC transport. Implemented a preliminary Role-Based Access Control for the Dashboard. In this version, there are two predefined roles: Administrator: This role could access all resources. Viewer: This role can only view resources and data, corresponding to all GET requests in the REST API. Added Single Sign-On (SSO) feature and integrated with LDAP. Integrated the SAML 2.0 Support for SSO. Supported audit logs to record operations from CLI, REST API, and Dashboard in separate log files. Fixed an issue where logging would stop if "Rotation Size" would be set to `infinity` on file log handlers. Improve EMQX graceful shutdown (`emqx stop` command): Increase timeout from 1 to 2 minutes. Printed an error message if EMQX can't stop gracefully within the configured timeout. Print periodic status messages while EMQX is shutting down. Fixed telemetry reporting error on Windows when os_mon module is unavailable. Lowered CMD_overridden log severity from warning to info. Upgraded rpc library gen_rpc from 2.8.1 to 3.1.0. Upgraded library `esockd` from 5.9.6 to 5.9.7. This upgrade included: Enhancements regarding proxy protocol error and timeout. Lowered `ssl_error` exceptions to info-level logging. Malformed MQTT packet parsing exception log level is lowered from `error` to `info`. In command `emqx ctl listeners` output, the `shutdown_count` counter is incremented when TLS handshake failure (`sslerror`) or Malformed packet (`frameerror`) happens. Fixed log formatter when log.HANDLER.formatter is set to 'json'. The bug was introduced in v5.0.4 where the log line was no longer a valid JSON, but prefixed with timestamp string and level name. Disable access to the `logout` endpoint by the API key, this endpoint is for the Dashboard only. Fixed resources cleanup in HStreamdB bridge. Prior to this fix, HStreamDB bridge might report errors during bridge configuration updates, since hstreamdb client/producer were not stopped properly.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: support-question.md

name: Support Question about: Any support questions you might have. title: '' labels: '' assignees: '' <!-- Thanks for filing an issue! Before hitting the button, please answer these questions. Fill in as much of the template below as you can. If you leave out information, we can't help you as well. We will try our best to answer the question, but we also have a mailing list and slack channel for any other questions. --> <!-- Uncomment one or more of the following lines depending on what you are asking about: --> <!-- Best practices --> <!-- How to implement a specific feature --> <!-- General operator-related help --> <!-- Open question --> <!-- A clear and concise description of the steps you took (or insert a code snippet). --> <!-- A clear and concise description of what you expected to happen (or insert a code snippet). --> <!-- A clear and concise description of what you expected to happen (or insert a code snippet). --> Operator type: <!-- Uncomment one or more of the following lines corresponding to the language of the operator type --> <!-- /language go --> <!-- /language ansible - For ansible operator related questions, please create the issue in https://github.com/operator-framework/ansible-operator-plugins --> <!-- /language helm --> Kubernetes cluster type: <!-- The type of cluster used for testing/deployment, ex. "vanilla", "OpenShift" --> `$ operator-sdk version` <!-- Insert the output of `operator-sdk version` here. --> `$ go version` (if language is Go) <!-- Insert the output of `go version` here --> `$ kubectl version` <!-- Insert the output of `kubectl version` here --> <!-- Add any other context about the question here. -->
Project: ArangoDB (App Definition and Development / Database)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: userver (App Definition and Development / Streaming & Messaging)
File: requests_in_flight.md

If your service has a server::handlers::InspectRequests configured, then you may inspect the active requests. The feature is useful for investigating a broken production service to find request parameters that lead to handle malfunction. server::handlers::InspectRequests provides the following REST API: ``` GET /service/inspect-requests GET /service/inspect-requests?body=1 ``` Note that the server::handlers::InspectRequests handler lives at the separate `components.server.listener-monitor` address, so you have to request them using the `listener-monitor` credentials. See @ref scripts/docs/en/userver/tutorial/production_service.md for more info on configuration and ideas on how to change the `/service/inspect-requests` handle path. In this example there is one in-flight request that is being executed for more than 3 seconds. ``` bash $ curl http://localhost:8085/internal/inspect-requests | jq ``` ```json [ { "method": "GET", "url": "/hello", "http_version": "1.1", "request_path": "/hello", "handling-duration-ms": 3865, "start-handling-timestamp": "Thu, 02 Dec 2021 07:57:22 UTC", "host": "localhost", "args": {}, "headers": { "User-Agent": "curl/7.58.0", "Accept": "/", "Host": "localhost" } } ] ``` In this example there are multiple in-flight request that actually have no body. ``` bash $ curl http://localhost:8085/internal/inspect-requests?body=1 | jq ``` ```json [ { "request-body": "", "method": "GET", "url": "/hello", "http_version": "1.1", "request_path": "/hello", "handling-duration-ms": 11909, "start-handling-timestamp": "Thu, 02 Dec 2021 08:11:20 UTC", "host": "localhost", "args": {}, "headers": { "User-Agent": "curl/7.58.0", "Accept": "/", "Host": "localhost" } }, { "request-body": "", "method": "GET", "url": "/hello", "http_version": "1.1", "request_path": "/hello", "handling-duration-ms": 11303, "start-handling-timestamp": "Thu, 02 Dec 2021 08:11:21 UTC", "host": "localhost", "args": {}, "headers": { "User-Agent": "curl/7.58.0", "Accept": "/", "Host": "localhost" } }, { "request-body": "", "method": "GET", "url": "/hello", "http_version": "1.1", "request_path": "/hello", "handling-duration-ms": 10938, "start-handling-timestamp": "Thu, 02 Dec 2021 08:11:21 UTC", "host": "localhost", "args": {}, "headers": { "User-Agent": "curl/7.58.0", "Accept": "/", "Host": "localhost" } } ] ``` @htmlonly <div class="bottom-nav"> @endhtmlonly @ref scripts/docs/en/userver/loglevelrunningservice.md | @ref scripts/docs/en/userver/servicemonitor.md @htmlonly </div> @endhtmlonly
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: kafka-authorization.md

title: Kafka Topic Authorization software: kafka labels: category: streaming layer: data blogs: https://opencredo.com/blogs/controlling-kafka-data-flows-using-open-policy-agent/ tutorials: https://www.openpolicyagent.org/docs/latest/kafka-authorization/ code: https://github.com/StyraInc/opa-kafka-plugin https://github.com/llofberg/kafka-authorizer-opa https://github.com/opencredo/opa-single-message-transformer inventors: ticketmaster styra videos: title: 'OPA at Scale: How Pinterest Manages Policy Distribution' speakers: name: Will Fu organization: pinterest name: Jeremy Krach organization: pinterest venue: OPA Summit at Kubecon San Diego 2019 link: https://www.youtube.com/watch?v=LhgxFICWsA8 docs_features: rest-api-integration: note: | This project implements a custom that uses OPA to make authorization decisions by calling the REST API. Installation and configuration instructions are available in the project's . Apache Kafka is a high-performance distributed streaming platform deployed by thousands of companies. OPA provides fine-grained, context-aware access control of which users can read/write which Kafka topics to enforce important requirements around confidentiality and integrity.
Project: YugabyteDB (App Definition and Development / Database)
File: rooted-tree.md

title: Using a recursive CTE to traverse a rooted tree headerTitle: Finding the paths in a rooted tree linkTitle: Rooted tree description: This section shows how to use a recursive CTE to traverse a rooted tree. menu: v2.18: identifier: rooted-tree parent: traversing-general-graphs weight: 60 type: docs Before trying the code in this section, make sure that you have created the "edges" table (see ) and installed all the code shown in the section . Notice that, because a rooted tree is such a drastically restricted specialization of the general graph, it allows a simpler representation where only the nodes are explicitly represented and where the edges are inferred. This is explained in the section . It's unlikely, therefore, that you'd represent a rooted tree in the way for which the code presented in this section is written. It is, however, important to show that the general approach for graph traversal does indeed handle all the restricted kinds of graph. First, define a suitable constraint on the "edges" table for representing a directed cyclic graph and populate the table with the data that represents the graph shown in the section. ```plpgsql delete from edges; alter table edges drop constraint if exists edges_chk cascade; alter table edges add constraint edgeschk check(node1 <> node_2); insert into edges(node1, node2) values ('n01', 'n02'), ('n01', 'n03'), ('n01', 'n04'), ('n02', 'n05'), ('n02', 'n06'), ('n05', 'n11'), ('n05', 'n12'), ('n03', 'n07'), ('n03', 'n08'), ('n04', 'n09'), ('n04', 'n10'), ('n10', 'n13'), ('n10', 'n14'); ``` Now re-create the simpler implementation of "findpaths()"_, shown at , that omits the cycle prevention code. Because the root is uniquely defined, it can be determined mechanically. Do this: ```plpgsql do $body$ declare root constant text not null := ( select distinct node_1 from edges where node_1 not in ( select node_2 from edges) ); begin call findpaths(startnode => root); end; $body$; \t on select t from listpaths('rawpaths'); \t off ``` This is the result: ``` path # cardinality path -- - 1 2 n01 > n02 2 2 n01 > n03 3 2 n01 > n04 4 3 n01 > n02 > n05 5 3 n01 > n02 > n06 6 3 n01 > n03 > n07 7 3 n01 > n03 > n08 8 3 n01 > n04 > n09 9 3 n01 > n04 > n10 10 4 n01 > n02 > n05 > n11 11 4 n01 > n02 > n05 > n12 12 4 n01 > n04 > n10 > n13 13 4 n01 > n04 > n10 > n14 ``` A rooted tree has only one path to any node, so calling the procedure "restricttoshortestpaths()" will not remove any paths. Confirm this using the same procedure that was used in the section to show that the version of "findpaths()" that implements early pruning produces the same set of paths as does the implementation that uses the recursive CTE ordinarily followed by a call to "restricttoshortestpaths()"_: ```plpgsql call restricttoshortestpaths('rawpaths', 'shortest_paths'); call assertshortestpathssameasrawpaths(); ``` The assertion holds.
Project: KICS (Provisioning / Security & Compliance)
File: 3f5ff8a7-5ad6-4d02-86f5-666307da1b20.md

title: Etcd Client Certificate File Not Defined hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 3f5ff8a7-5ad6-4d02-86f5-666307da1b20 Query name: Etcd Client Certificate File Not Defined Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Secret Management URL: When using kube-apiserver commands, the '--etcd-cafile' flag should be defined<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: [] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--etcd-cafile=/path/to/ca/file.pem"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver","--etcd-cafile=/path/to/ca/file.pem"] args: [] restartPolicy: OnFailure ```
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: decision_records.md

Architecture Decision Records (ADRs or simply decision records) are a collection of records for "architecturally significant" decisions. A decision record is a short markdown file in a specific light-weight format. This folder contains all the decisions we have recorded in Dapr, including Dapr runtime, Dapr CLI as well as Dapr SDKs in different languages. All decisions are categorized in the following folders: Architecture* - Decisions on general architecture, code structure, coding conventions and common practices. - - API* - Decisions on Dapr runtime API designs. - - - - - - CLI* - Decisions on Dapr CLI architecture and behaviors. - SDKs* - Decisions on Dapr SDKs. - Engineering* - Decisions on Engineering practices, including CI/CD, testing and releases. - - A new decision record should be a .md file named as ``` <category prefix>-<sequence number in category>-<descriptive title>.md ``` |Category|Prefix| |-|-| |Architecture|ARC| |API|API| |CLI|CLI| |SDKs|SDK| |Engineering|ENG| A decision record should contain the following fields: Status* - can be "proposed", "accepted", "implemented", or "rejected". Context* - the context of the design discussion. Decision* - Description of the decision. Consequences* - what impacts this decision may create. Implementation* - when a decision is implemented, the corresponding doc should be updated with the following information (when applicable): Release version Associated test cases
Project: StarRocks (App Definition and Development / Database)
File: CANCEL_LOAD.md

displayed_sidebar: "English" Cancels a given load job: , , or . A load job in the `PREPARED`, `CANCELLED` or `FINISHED` state cannot be canceled. Canceling a load job is an asynchronous process. You can use the statement to check whether a load job is successfully canceled. The load job is successfully canceled if the value of `State` is `CANCELLED` and the value of `type` (displayed in `ErrorMsg`) is `USER_CANCEL`. ```SQL CANCEL LOAD [FROM db_name] WHERE LABEL = "label_name" ``` | Parameter | Required | Description | | - | | | | db_name | No | The name of the database to which the load job belongs. If this parameter is not specified, a load job in your current database is canceled by default. | | label_name | Yes | The label of the load job. | Example 1: Cancel the load job whose label is `example_label` in the current database. ```SQL CANCEL LOAD WHERE LABEL = "example_label"; ``` Example 2: Cancel the load job whose label is `examplelabel` in the `exampledb` database. ```SQL CANCEL LOAD FROM example_db WHERE LABEL = "example_label"; ```
Project: StarRocks (App Definition and Development / Database)
File: array_length.md

displayed_sidebar: "English" Returns the number of elements in an array. The result type is INT. If the input parameter is NULL, the result is also NULL. Null elements are counted in the length. It has an alias . ```Haskell INT arraylength(anyarray) ``` `any_array`: the ARRAY value from which you want to retrieve the number of elements. Returns an INT value. ```plain text mysql> select array_length([1,2,3]); +--+ | array_length([1,2,3]) | +--+ | 3 | +--+ 1 row in set (0.00 sec) mysql> select array_length([1,2,3,null]); +-+ | array_length([1, 2, 3, NULL]) | +-+ | 4 | +-+ mysql> select array_length([[1,2], [3,4]]); +--+ | array_length([[1,2],[3,4]]) | +--+ | 2 | +--+ 1 row in set (0.01 sec) ``` ARRAY_LENGTH, ARRAY, CARDINALITY