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

+++ title = "googleiamservice_accounts resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleiamservice_accounts" identifier = "inspec/resources/gcp/googleiamserviceaccounts.md googleiamserviceaccounts resource" parent = "inspec/resources/gcp" +++ A `googleiamservice_accounts` is used to test a Google ServiceAccount resource ```ruby describe googleiamservice_accounts(project: 'chef-gcp-inspec', name: "display-name@project-id.iam.gserviceaccount.com") do its('serviceaccountemails') { should include "display-name@project-id.iam.gserviceaccount.com" } its('count') { should be <= 1000 } end ``` Properties that can be accessed from the `googleiamservice_accounts` resource: See the resource for more information. `serviceaccountnames` : an array of `googleiamservice_account` name `project_ids` : an array of `googleiamserviceaccount` projectid `serviceaccountids` : an array of `googleiamserviceaccount` uniqueid `serviceaccountemails` : an array of `googleiamservice_account` email `serviceaccountdisplay_names` : an array of `googleiamserviceaccount` displayname `oauth2clientids` : an array of `googleiamserviceaccount` oauth2client_id This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: KICS (Provisioning / Security & Compliance)
File: b187edca-b81e-4fdc-aff4-aab57db45edb.md

title: SQL DB Instance Publicly Accessible hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b187edca-b81e-4fdc-aff4-aab57db45edb Query name: SQL DB Instance Publicly Accessible Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Insecure Configurations URL: Cloud SQL instances should not be publicly accessible.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="24 41 56 6" resource "googlesqldatabase_instance" "positive1" { name = "master-instance" databaseversion = "POSTGRES11" region = "us-central1" settings { tier = "db-f1-micro" } } resource "googlesqldatabase_instance" "positive2" { name = "postgres-instance-2" databaseversion = "POSTGRES11" settings { tier = "db-f1-micro" ip_configuration { authorized_networks { name = "pub-network" value = "0.0.0.0/0" } } } } resource "googlesqldatabase_instance" "positive3" { name = "master-instance" databaseversion = "POSTGRES11" region = "us-central1" settings { tier = "db-f1-micro" ip_configuration { ipv4_enabled = true } } } resource "googlesqldatabase_instance" "positive4" { name = "master-instance" databaseversion = "POSTGRES11" region = "us-central1" settings { tier = "db-f1-micro" ip_configuration {} } } ``` ```tf title="Negative test num. 1 - tf file" resource "googlesqldatabase_instance" "negative1" { name = "private-instance-1" databaseversion = "POSTGRES11" settings { ip_configuration { ipv4_enabled = false privatenetwork = "someprivate_network" } } } resource "googlesqldatabase_instance" "negative2" { name = "postgres-instance-2" databaseversion = "POSTGRES11" settings { tier = "db-f1-micro" ip_configuration { authorized_networks { content { name = "sometrustednetwork" value = "sometrustednetwork_address" } } authorized_networks { content { name = "anothertrustednetwork" value = "anothertrustednetwork_address" } } } } } ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: plugins.md

+++ title = "About Chef InSpec and Train Plugins" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "Plugins" identifier = "inspec/Plugins" parent = "inspec" weight = 90 +++ Chef InSpec plugins are optional software components that extend the capabilities of InSpec. For example, is a plugin project that aims to generate Chef InSpec controls from infrastructure-as-code files. Plugins are distributed as RubyGems, and Chef InSpec manages their installation. Chef InSpec plugins always begin with the prefix 'inspec-'. Train plugins allow Chef InSpec to speak to new kinds of targets (typically new remote targets or APIs, but you could treat the local system in a new way if you wished to). For example, if you wanted to audit a Kubernetes cluster, you might want a transport that can talk to the supervisor API. You would develop a Train plugin for that, and install it using the Chef InSpec command line. Train plugins always begin with the prefix 'train-'. Currently, each plugin can offer one or more of these capabilities: define new output formats ("reporters") input sources define a new command-line-interface (CLI) command suite (`inspec` plugins) connectivity to new types of hosts or cloud providers (`train` plugins) DSL extensions at the file, control, describe block, or test level DSL extensions for custom resources The Chef InSpec CLI can tell you which plugins are available: ```bash inspec plugin search inspec- ``` The Chef InSpec command line now offers a new subcommand just for managing plugins. You can install a plugin by running: ```bash inspec plugin install inspec-some-plugin inspec plugin install train-some-plugin ``` For more details on what the `plugin` command can do, run `inspec plugin help`. You can specify an alternate source by passing the base of your Gem repository to the `--source` parameter: ```bash inspec plugin search --source https://private.example.com inspec-private inspec plugin install --source https:/private.example.com inspec-private-plugin ``` For details on creating a Chef InSpec plugin, see the For details on creating a Train plugin, see the
Project: LinuxKit (Provisioning / Automation & Configuration)
File: 2017-08-16.md

Time: 9am PDT (12pm EDT, 5pm BST) Meeting location: https://docker.zoom.us/j/779801882 Announcement: [Moby project forum post](https://forums.mobyproject.org/t/2017-08-16-linuxkit-security-sig-meeting/126/1) Video Recording: https://youtu.be/5lzVdfuM4Eo Previous meeting notes: Introductions & Administrivia (5 min) Linux okernel project - deep dive - HPE (45 min) Project updates (10 min) Next meeting: 2017-08-30 deep dive TBD please feel free to propose additional deep dives and discussion topics! okernel intro by HPE Question: is it possible to do KVM and okernel stuff on the same machine given that they both use EPT? Answer: theoretically yes, but untested. Question: what's the goal of this work? Answer: definitely upstreaming it at some point, although some cleanup and such needs to happen. Question: what's the interest in XPFO? Answer: want to track when +x pages come back from userspace, so that we can set them -x.
Project: Flink (App Definition and Development / Streaming & Messaging)
File: reset.md

title: "RESET Statements" weight: 15 type: docs aliases: /dev/table/sql/reset.html <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF 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 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. --> `RESET` statements are used to reset the configuration to the default. {{< tabs "reset statement" >}} {{< tab "SQL CLI" >}} `RESET` statements can be executed in . The following examples show how to run a `RESET` statement in SQL CLI. {{< /tab >}} {{< /tabs >}} {{< tabs "reset" >}} {{< tab "SQL CLI" >}} ```sql Flink SQL> RESET 'table.planner'; [INFO] Session property has been reset. Flink SQL> RESET; [INFO] All session properties have been set to their default values. ``` {{< /tab >}} {{< /tabs >}} ```sql RESET ('key')? ``` If no key is specified, it reset all the properties to the default. Otherwise, reset the specified key to the default. {{< top >}}
Project: ArangoDB (App Definition and Development / Database)
File: strong_swap.md

+++ title = "`void strongswap(bool &allgood, T &a, T &b)`" description = "Tries to perform a strong guarantee swap." +++ The standard `swap()` function provides the weak guarantee i.e. that no resources are lost. This ADL discovered function provides the strong guarantee instead: that if any of these operations throw an exception (i) move construct to temporary (ii) move assign `b` to `a` (iii) move assign temporary to `b`, an attempt is made to restore the exact pre-swapped state upon entry, and if that recovery too fails, then the boolean `all_good` will be false during stack unwind from the exception throw, to indicate that state has been lost. This function is used within `basicresult::`{{% api "swap(basicresult &)" %}} if, and only if, either or both of `valuetype` or `errortype` have a throwing move constructor or move assignment. It permits you to customise the implementation of the strong guarantee swap in Outcome with a more efficient implementation. Overridable: By Argument Dependent Lookup (ADL). Requires: That `T` is both move constructible and move assignable. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/basic_result.hpp>`
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_nfs_delete.md

Delete a NFS YugabyteDB Anywhere storage configuration Delete a NFS storage configuration in YugabyteDB Anywhere ``` yba storage-config nfs delete [flags] ``` ``` -f, --force [Optional] Bypass the prompt for non-interactive usage. -h, --help help for delete ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the storage configuration for the operation. Required for create, delete, describe, update. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage a YugabyteDB Anywhere NFS storage configuration
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-system-check.md

layout: default title: mesheryctl-system-check permalink: reference/mesheryctl/system/check redirect_from: reference/mesheryctl/system/check/ type: reference display-title: "false" language: en command: system subcommand: check Meshery environment check Verify environment pre/post-deployment of Meshery. <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check [flags] </div> </pre> Run system checks for both pre and post mesh deployment scenarios on Meshery <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check </div> </pre> Run Pre-mesh deployment checks (Docker and Kubernetes) <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check --preflight </div> </pre> Run checks on specific mesh adapter <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check --adapter meshery-istio:10000 </div> </pre> or <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check --adapter meshery-istio </div> </pre> Run checks for all the mesh adapters <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check --adapters </div> </pre> Verify the health of Meshery Operator's deployment with MeshSync and Broker <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system check --operator </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --adapter string Check status of specified meshery adapter --adapters Check status of meshery adapters --components Check status of Meshery components -h, --help help for check --operator Verify the health of Meshery Operator's deployment with MeshSync and Broker --pre Verify environment readiness to deploy Meshery --preflight Verify environment readiness to deploy Meshery </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -c, --context string (optional) temporarily change the current context. -v, --verbose verbose output -y, --yes (optional) assume yes for user interactive prompts. </div> </pre> Usage of mesheryctl system check Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_data_drop_redis.md

title: Kubectl-Dba Data Drop Redis menu: docs_{{ .version }}: identifier: kubectl-dba-data-drop-redis name: Kubectl-Dba Data Drop Redis parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Delete data from redis database Use this cmd to delete inserted data in a redis object ``` kubectl-dba data drop redis [flags] ``` ``` kubectl dba data drop redis -n demo sample-redis ``` ``` -h, --help help for redis ``` ``` --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/runner/.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 --default-seccomp-profile-type string Default seccomp profile --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 --password string Password for basic authentication to the API server --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 --username string Username for basic authentication to the API server ``` - Drop data from a database
Project: external-secrets (Provisioning / Security & Compliance)
File: disable-cluster-features.md

When deploying External Secrets Operator via Helm chart, the default configuration will install `ClusterSecretStore` and `ClusterExternalSecret` CRDs and these objects will be processed by the operator. In order to disable both or one of these features, it is necessary to configure the `crds.` Helm value, as well as the `process` Helm value, as these 2 values are connected. If you would like to install the operator without `ClusterSecretStore` and `ClusterExternalSecret` management, you will have to : set `crds.createClusterExternalSecret` to false set `crds.createClusterSecretStore` to false set `processClusterExternalSecret` to false set `processClusterStore` to false Example: ```bash helm install external-secrets external-secrets/external-secrets --set crds.createClusterExternalSecret=false \ --set crds.createClusterSecretStore=false \ --set processClusterExternalSecret=false \ --set processClusterStore=false ```
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: fix-11565.en.md

Upgraded jq library from v0.3.10 to v0.3.11. In this version, jqport programs are initiated on-demand and will not appear in users' processes unless the jq function in EMQX is used. Additionally, idle jqport programs will auto-terminate after a set period. Note: Most EMQX users, running jq in NIF mode, will be unaffected by this update.
Project: VoltDB (App Definition and Development / Database)
File: README-groovy-kafka.md

Groovy Kafka Tools ================== A set of scripts to read and manipulate VoltDB importer commit offsets. To execute them you need to install groovy first. This can be done easly by using for Linux, or for the Mac. The first time you run one of the scripts it will download, cache, and use all the required dependency artifacts. For usage information invoke the scripts without any arguments `kafka10-message-prober.groovy` prints out topic partition offset consumption statistics, and reads from each topic partition about a thousand messages `kafka10-offset-info.groovy` prints out topic partition offset consumption statistics from Kafka 10 cluster `kafka10-reset-consumer-offset.groovy` it can be used to reset the consumer offset in Kafka 10 cluster used by VoltDB importers.
Project: NebulaGraph (App Definition and Development / Database)
File: 0000-template.md

name: Request for Comments about: Detail an idea for this project <!-- Different from feature request, RFC require you explain the more detail in nebula. --> <!-- The section `Drawbacks`, `Prior art`, `Unresolved questions` and `Future possibilities` could be blank if it should be. --> The overview explanation of the feature. Why are we doing this? What use cases does it support? What is the expected outcome? Explain usage of the proposal as if it was already introduced in the project. That generally means: Introducing new named concepts, syntax or configuration. Explaining the feature largely in terms of examples. If applicable, provide sample usage, output or error messages. Explaining the compatibility in several levels like query language, RPC structure and storage format etc. This is the technical section of the RFC. Explain the design in sufficient detail that: Detail how the feature will be implemented. From syntax, AST, planning, executing and even deep into storage etc. Explain the ultimate purpose of the proposal. Why is this design the best in the space of possible designs? What other designs have been considered and what is the rationale for not choosing them? Why should we not accept this? List the negative affection or shortage if exists. Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are: For practical proposals: Does this feature exist in other database and what experience have their community had? Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. The proposal won't be accepted for they are in other projects, but this will show us more productive meaning. What parts of the design do you expect to resolve through the RFC process before this gets accepted? What parts of the design do you expect can't to resolve eventually in this RFC? What related issues do you consider out of scope for this RFC but could be addressed in the future independently of the solution that comes out of this RFC? List the expected extensions of this proposal in future, and why better not include in current stage. But all content in this section has no effort to determine whether we accept this proposal, in fact, it's just additional notes or even brainstorming.
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: erlang-memory-allocators-11350.md

Erlang VM memory utilisation from erts_alloc perspective RabbitMQ Understand Erlang VM memory breakdown across all allocators & schedulers. Metrics displayed: Resident Set Size - as captured by `rabbitmqprocessresidentmemorybytes` Allocated Total Used Unused Allocated by Allocator Type (Min / Max / Avg / Current) binary_alloc driver_alloc eheap_alloc ets_alloc exec_alloc fix_alloc literal_alloc ll_alloc sl_alloc std_alloc temp_alloc For each allocator type: Multiblock Used Block Carrier Unused Multiblock Pool Used Block Carrier Unused Singleblock Used Block Carrier Unused Filter by: RabbitMQ Cluster RabbitMQ Node Erlang Memory Allocator (Multi-value + All) Depends on `rabbitmq-prometheus` plugin, built-in since Learn more about To get it working locally with RabbitMQ in 3 simple steps, follow this
Project: YugabyteDB (App Definition and Development / Database)
File: rename.md

title: RENAME linkTitle: RENAME description: RENAME menu: preview: parent: api-yedis weight: 2265 aliases: /preview/api/redis/rename /preview/api/yedis/rename type: docs `RENAME key1 key2` Limited support: RENAME command is useful to rename one key as another key. This is currently a best-effort mechanism and is intended to only work when there is no concurrent updates to either the source or the destination keys. The TTL setting for the key itself is copied over to the destination key. However, for container types such as the time series type, the ttl settings for the sub-keys are not copied. Returns status string. , , , ,