cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 95601b9a-7fe8-4aee-9b58-d36fd9382dfc.md

title: Stackdriver Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 95601b9a-7fe8-4aee-9b58-d36fd9382dfc Query name: Stackdriver Logging Disabled Platform: GoogleDeploymentManager Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Kubernetes Engine Clusters must have Stackdriver Logging enabled, which means the attribute 'loggingService' must be defined and different from 'none'<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="4" resources: name: cluster type: container.v1.cluster properties: name: my-cluster ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="6" resources: name: cluster type: container.v1.cluster properties: name: my-cluster loggingService: none ``` ```yaml title="Negative test num. 1 - yaml file" resources: name: cluster type: container.v1.cluster properties: name: my-cluster loggingService: "logging.googleapis.com" ```
Project: KICS (Provisioning / Security & Compliance)
File: fc101ca7-c9dd-4198-a1eb-0fbe92e80044.md

title: IAM Group Without Users hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fc101ca7-c9dd-4198-a1eb-0fbe92e80044 Query name: IAM Group Without Users Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: IAM Group should have at least one user associated<br> ```tf title="Positive test num. 1 - tf file" hl_lines="33 12" resource "awsiamgroup_membership" "team2" { name = "tf-testing-group-membership" users = [ awsiamuser.user_one2.name, awsiamuser.user_two2.name, ] group = awsiamgroup.group222.name } resource "awsiamgroup" "group2" { name = "test-group" } resource "awsiamuser" "user_one2" { name = "test-user" } resource "awsiamuser" "user_two2" { name = "test-user-two" } resource "awsiamgroup_membership" "team3" { name = "tf-testing-group-membership" users = [ ] group = awsiamgroup.group3.name } resource "awsiamgroup" "group3" { name = "test-group" } ``` ```tf title="Negative test num. 1 - tf file" resource "awsiamgroup_membership" "team" { name = "tf-testing-group-membership" users = [ awsiamuser.user_one.name, awsiamuser.user_two.name, ] group = awsiamgroup.group.name } resource "awsiamgroup" "group" { name = "test-group" } resource "awsiamuser" "user_one" { name = "test-user" } resource "awsiamuser" "user_two" { name = "test-user-two" } ```
Project: ClickHouse (App Definition and Development / Database)
File: dns_cache.md

slug: /en/operations/system-tables/dns_cache Contains information about cached DNS records. Columns: `hostname` () cached hostname `ip_address` () ip address for the hostname `ip_family` () family of the ip address, possible values: 'IPv4' 'IPv6' 'UNIX_LOCAL' `cached_at` () - when the record was cached Example Query: ```sql SELECT * FROM system.dns_cache; ``` Result: | hostname | ip\address | ip\family | cached\_at | | : | : | : | : | | localhost | ::1 | IPv6 | 2024-02-11 17:04:40 | | localhost | 127.0.0.1 | IPv4 | 2024-02-11 17:04:40 | See also
Project: YDB (App Definition and Development / Database)
File: insert_into_table_people_many_rows.md

```sql INSERT INTO people (name, lastname, age, country, state, city, birthday, sex) VALUES ('Jane', 'Smith', 25, 'Canada', 'Ontario', 'Toronto', CAST('1997-08-23' AS Date), 'Female'), ('Alice', 'Johnson', 28, 'UK', 'England', 'London', CAST('1994-05-05' AS Date), 'Female'), ('Bob', 'Brown', 40, 'USA', 'Texas', 'Dallas', CAST('1982-12-10' AS Date), 'Male'), ('Charlie', 'Davis', 35, 'Canada', 'Quebec', 'Montreal', CAST('1987-02-17' AS Date), 'Male'), ('Eve', 'Martin', 29, 'UK', 'Scotland', 'Edinburgh', CAST('1993-11-21' AS Date), 'Female'), ('Frank', 'White', 45, 'USA', 'Florida', 'Miami', CAST('1977-03-14' AS Date), 'Male'), ('Grace', 'Clark', 50, 'Canada', 'British Columbia', 'Vancouver', CAST('1972-04-26' AS Date), 'Female'), ('Hank', 'Miller', 33, 'UK', 'Wales', 'Cardiff', CAST('1989-07-30' AS Date), 'Male'), ('Ivy', 'Garcia', 31, 'USA', 'Arizona', 'Phoenix', CAST('1991-09-05' AS Date), 'Female'), ('Jack', 'Anderson', 22, 'Canada', 'Manitoba', 'Winnipeg', CAST('2000-06-13' AS Date), 'Male'), ('Kara', 'Thompson', 19, 'UK', 'Northern Ireland', 'Belfast', CAST('2003-10-18' AS Date), 'Female'), ('Liam', 'Martinez', 55, 'USA', 'New York', 'New York City', CAST('1967-01-29' AS Date), 'Male'), ('Molly', 'Robinson', 40, 'Canada', 'Alberta', 'Calgary', CAST('1982-12-01' AS Date), 'Female'), ('Noah', 'Lee', 47, 'UK', 'England', 'Liverpool', CAST('1975-05-20' AS Date), 'Male'), ('Olivia', 'Gonzalez', 38, 'USA', 'Illinois', 'Chicago', CAST('1984-03-22' AS Date), 'Female'), ('Paul', 'Harris', 23, 'Canada', 'Saskatchewan', 'Saskatoon', CAST('1999-08-19' AS Date), 'Male'), ('Quinn', 'Lewis', 34, 'UK', 'England', 'Manchester', CAST('1988-07-25' AS DATE), 'Female'), ('Rachel', 'Young', 42, 'USA', 'Ohio', 'Cleveland', CAST('1980-02-03' AS Date), 'Female'); ```
Project: KICS (Provisioning / Security & Compliance)
File: e86e26fc-489e-44f0-9bcd-97305e4ba69a.md

title: ECR Repository Is Publicly Accessible hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e86e26fc-489e-44f0-9bcd-97305e4ba69a Query name: ECR Repository Is Publicly Accessible Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Access Control URL: Amazon ECR image repositories shouldn't have public access<br> ```tf title="Positive test num. 1 - tf file" hl_lines="8" resource "awsecrrepository" "positive1" { name = "bar" } resource "awsecrrepository_policy" "positive2" { repository = awsecrrepository.foo.name policy = <<EOF { "Version": "2008-10-17", "Statement": [ { "Sid": "new policy", "Effect": "Allow", "Principal": "*", "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability", "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload", "ecr:DescribeRepositories", "ecr:GetRepositoryPolicy", "ecr:ListImages", "ecr:DeleteRepository", "ecr:BatchDeleteImage", "ecr:SetRepositoryPolicy", "ecr:DeleteRepositoryPolicy" ] } ] } EOF } ``` ```tf title="Negative test num. 1 - tf file" resource "awsecrrepository" "negative1" { name = "bar" } resource "awsecrrepository_policy" "negative2" { repository = awsecrrepository.foo.name policy = <<EOF { "Version": "2008-10-17", "Statement": [ { "Sid": "new policy", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::##account_number##:root" }, "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability", "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload", "ecr:DescribeRepositories", "ecr:GetRepositoryPolicy", "ecr:ListImages", "ecr:DeleteRepository", "ecr:BatchDeleteImage", "ecr:SetRepositoryPolicy", "ecr:DeleteRepositoryPolicy" ] } ] } EOF } ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: bsd_service.md

+++ title = "bsd_service resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "bsd_service" identifier = "inspec/resources/os/bsdservice.md bsdservice resource" parent = "inspec/resources/os" +++ Use the `bsd_service` Chef InSpec audit resource to test a service using a Berkeley OS-style `init` on the FreeBSD platform. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `bsd_service` resource block declares the name of a service and then one (or more) matchers to test the state of the service: describe bsdservice('servicename') do it { should be_installed } it { should be_enabled } it { should be_running } end where `('service_name')` must specify a service name `beinstalled`, `beenabled`, and `be_running` are the different for this resource. The path to the service manager's control may be specified for situations where the path isn't available in the current `PATH`. For example: describe bsdservice('servicename', '/path/to/control') do it { should be_enabled } it { should be_installed } it { should be_running } end All properties available to the resource may be used. {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `be_enabled` matcher tests if the named service is enabled: it { should be_enabled } The `be_installed` matcher tests if the named service is installed: it { should be_installed } The `be_running` matcher tests if the named service is running: it { should be_running }
Project: Metal³ (Provisioning / Automation & Configuration)
File: configuration.md

Configuration Settings ====================== The operator supports several configuration options for controlling its interaction with Ironic. `DEPLOYRAMDISKURL` -- The URL for the ramdisk of the image containing the Ironic agent. `DEPLOYKERNELURL` -- The URL for the kernel to go with the deploy ramdisk. `DEPLOYISOURL` -- The URL for the ISO containing the Ironic agent for drivers that support ISO boot. Optional if kernel/ramdisk are set. `IRONIC_ENDPOINT` -- The URL for the operator to use when talking to Ironic. `IRONICCACERTFILE` -- The path of the CA certificate file of Ironic, if needed `IRONIC_INSECURE` -- ("True", "False") Whether to skip the ironic certificate validation. It is highly recommend to not set it to True. `IRONICCLIENTCERT_FILE` -- The path of the Client certificate file of Ironic, if needed. Both Client certificate and Client private key must be defined for client certificate authentication (mTLS) to be enabled. `IRONICCLIENTPRIVATEKEYFILE` -- The path of the Client private key file of Ironic, if needed. Both Client certificate and Client private key must be defined for client certificate authentication (mTLS) to be enabled. `IRONICSKIPCLIENTSANVERIFY` -- ("True", "False") Whether to skip the ironic client certificate SAN validation. `BMO_CONCURRENCY` -- The number of concurrent reconciles performed by the Operator. Default is the number of CPUs, but no less than 2 and no more than 8. `PROVISIONING_LIMIT` -- The desired maximum number of hosts that could be (de)provisioned simultaneously by the Operator. The limit does not apply to hosts that use virtual media for provisioning. The Operator will try to enforce this limit, but overflows could happen in case of slow provisioners and / or higher number of concurrent reconciles. For such reasons, it is highly recommended to keep BMOCONCURRENCY value lower than the requested PROVISIONINGLIMIT. Default is 20. `IRONICEXTERNALURL_V6` -- This is the URL where Ironic will find the image for nodes that use IPv6. In dual stack environments, this can be used to tell Ironic which IP version it should set on the BMC. Kustomization Configuration It is possible to deploy ```baremetal-operator``` with three different operator configurations, namely: operator with ironic operator without ironic ironic without operator A detailed overview of the configuration is presented in [Bare Metal Operator and Ironic Configuration](https://book.metal3.io/bmo/installbaremetaloperator) Notes on external Ironic When an external Ironic is used, the following requirements must be met: Either HTTP basic or no-auth authentication must be used (Keystone is not supported). API version 1.81 (2023.1 "Antelope" release cycle) or newer must be available.
Project: ArangoDB (App Definition and Development / Database)
File: on_outcome_in_place_construction.md

+++ title = "`static void onoutcomeinplaceconstruction(T *, inplacetype_t<U>, Args &&...) noexcept`" description = "(>= Outcome v2.2.0) Hook invoked by the in-place constructors of `basic_outcome`." categories = ["observer-policies"] weight = 450 +++ One of the constructor hooks for {{% api "basicoutcome<T, EC, EP, NoValuePolicy>" %}}, generally invoked by the in-place constructors of `basicoutcome`. See each constructor's documentation to see which specific hook it invokes. Requires: Always available. Guarantees: Never throws an exception.
Project: Harbor (Provisioning / Container Registry)
File: 8-04-Replication-edit-verify-remote-certificate.md

Test 8-04 - Update-verify-remote-cert-settings ======= To verify that an admin user can update verify remote cert setting. User guide This test requires that a Harbor instance is running and available. A linux host with Docker CLI installed (Docker client). Login UI as admin user. In configuration replication page, uncheck verify remote certificate settings. Save settings. Add an end point that use a selfsigned certificate. Add a replication rule of any project and enable the rule. In step5, project can be replicated. None
Project: BigchainDB (App Definition and Development / Database)
File: networks.md

<! Copyright 2020 Interplanetary Database Association e.V., BigchainDB and IPDB software contributors. SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0) Code is Apache-2.0 and docs are CC-BY-4.0 > A BigchainDB network is a set of connected BigchainDB nodes, managed by a BigchainDB consortium (i.e. an organization). Those terms are defined in the . The consortium might be a company, a foundation, a cooperative, or . It must make many decisions, e.g. How will new members be added? Who can read the stored data? What kind of data will be stored? A governance process is required to make those decisions, and therefore one of the first steps for any new consortium is to specify its governance process (if one doesn't already exist). This documentation doesn't explain how to create a consortium, nor does it outline the possible governance processes. It's worth noting that the decentralization of a BigchainDB network depends, to some extent, on the decentralization of the associated consortium. See the pages about and . We now describe how we set up the external (public-facing) DNS records for a BigchainDB network. Your consortium may opt to do it differently. There were several goals: Allow external users/clients to connect directly to any BigchainDB node in the network (over the internet), if they want. Each BigchainDB node operator should get an SSL certificate for their BigchainDB node, so that their BigchainDB node can serve the via HTTPS. (The same certificate might also be used to serve the .) There should be no sharing of SSL certificates among BigchainDB node operators. Optional: Allow clients to connect to a "random" BigchainDB node in the network at one particular domain (or subdomain). Register a domain (or use one that you already have) for your BigchainDB node. You can use a subdomain if you like. For example, you might opt to use `abc-org73.net`, `api.dynabob8.io` or `figmentdb3.ninja`. Get an SSL certificate for your domain or subdomain, and properly install it in your node (e.g. in your NGINX instance). Create a DNS A Record mapping your domain or subdomain to the public IP address of your node (i.e. the one that serves the BigchainDB HTTP API). Optional: The consortium managing the BigchainDB network could register a domain name and set up CNAME records mapping that domain name (or one of its subdomains) to each of the nodes in the network. For example, if the consortium registered `bdbnetwork.io`, they could set up CNAME records like the following: CNAME record mapping `api.bdbnetwork.io` to `abc-org73.net` CNAME record mapping `api.bdbnetwork.io` to `api.dynabob8.io` CNAME record mapping `api.bdbnetwork.io` to `figmentdb3.ninja`
Project: YDB (App Definition and Development / Database)
File: options_cloud.md

`--token-file <filepath>`: Enables the Access Token authentication mode using the contents of the file specified in this option `--yc-token-file <filepath>`: Enables the Refresh Token authentication mode using the contents of the file specified in this option `--use-metadata-credentials` : The Metadata authentication mode is used. `--sa-key-file <filepath>`: Enables the Service Account Key authentication mode, where the key and other parameters are taken from the JSON file specified in this option
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno_completion_fish.md

Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: kyverno completion fish | source To load completions for every new session, execute once: kyverno completion fish > ~/.config/fish/completions/kyverno.fish You will need to start a new shell for this setup to take effect. ``` kyverno completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Generate the autocompletion script for the specified shell
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.2.6.5.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Major | Annotate CanUnbuffer with @InterfaceAudience.Public* Made CanBuffer interface public for use in client applications. | Critical | Add capability to set JHS job cache to a task-based limit* Two recommendations for the mapreduce.jobhistory.loadedtasks.cache.size property: 1) For every 100k of cache size, set the heap size of the Job History Server to 1.2GB. For example, mapreduce.jobhistory.loadedtasks.cache.size=500000, heap size=6GB. 2) Make sure that the cache size is larger than the number of tasks required for the largest job run on the cluster. It might be a good idea to set the value slightly higher (say, 20%) in order to allow for job size growth. | Major | inconsistent value type of the "type" field for LeafQueueInfo in response of RM REST API - cluster/scheduler* Fix inconsistent value type ( String and Array ) of the "type" field for LeafQueueInfo in response of RM REST API
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: tmpfs.md

Create a tmpfs mount. Mount a temporary filesystem (tmpfs) mount into a container, for example: ``` $ podman <<subcommand>> -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image ``` This command mounts a tmpfs at /tmp within the container. The supported mount options are the same as the Linux default mount flags. If no options are specified, the system uses the following options: rw,noexec,nosuid,nodev.
Project: Beam (App Definition and Development / Streaming & Messaging)
File: 26_io_avro.md

Prompt: Is Apache Avro format supported in Apache Beam? Response: is a data format for storing and exchanging data. Apache Beam supports reading from and writing to Avro files using the `ReadFromAvro` and `WriteToAvro` transforms in the `AvroIO` module. For more information, see the AvroIO connector documentation for the following languages: To get started with Avro and Apache Beam, refer to the . Here is an example of Apache Beam pipeline code for reading data from an Avro file: ```python class ReadAvroOptions(PipelineOptions): @classmethod def addargparse_args(cls, parser): parser.add_argument( "--path", default="gs://cloud-samples-data/bigquery/us-states/*.avro", help="GCS path to read from") options = ReadAvroOptions() with beam.Pipeline(options=options) as p: (p | "Read from Avro" >> ReadFromAvro(options.path) | Map(logging.info)) ```
Project: Harbor (Provisioning / Container Registry)
File: 1-09-admin-create-delete-user.md

Test 1-09 - Admin User Create, Delete and Recreate a User(DB Mode) ======= To verify that an admin user can create/delete/recreate a user when users are managed locally by Harbor (DB mode). User guide This test requires that a Harbor instance is running and available. Harbor is set to authenticate against a local database. A linux host with Docker CLI installed (Docker client). The admin user logs in to the UI. The admin user creates a user from the UI. On a different browser, log in as the newly created user. The user views his/her own account settings. The user create two projects in the UI. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in. The admin user deletes the user from the UI. When clicking on any link on the page, the deleted user's session on the different browser should be redirected to the login page and logged out. On a Docker client host, use `docker login <harbor_host>` command to verify the user cannot log in. The admin user re-creates a user with the same username of the deleted user. On a different browser, log in as the re-created user. The user views his/her own account settings. The user views "My Projects" to see what projects he/she owns. On a Docker client host, use `docker login <harbor_host>` command to verify the re-created user can log in. The admin user view logs from the dashboard and should see two items of two project creation of the deleted user. The user has special number associated with him/her username. The newly created user can log in successfully in Step 3. The newly created user can view his/her own settings as entered by the admin in Step 4. The newly created user can create project successfully in Step 5. The admin should be able to re-create the user in Step 10. The re-created user should be able to log in, however, the previous projects no longer belong to him/her (Step 11-13). Docker client logs in successfully in Step 14. Should see special user id in logs in Step 15. None