cwielenb/CNCF-Dataset huggingface dataset:
Project: ThreatMapper (Provisioning / Security & Compliance)
File: azure.md

title: Microsoft Azure Cloud Scanner is deployed as a task within your Azure infrastructure. You need to configure Terraform with the appropriate resources and inputs for your particular scenario, and you will need to provide the IP address or DNS name for the ThreatMapper management console and an API key. Copy and paste the following into a new file cloud-scanner.tf. Edit the fields: region, mgmt-console-url and deepfence-key. ```shell provider "azurerm" { features {} subscriptionid = "<SUBSCRIPTIONID eg. XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX>" } module "cloud-scannerexamplesingle-subscription" { source = "deepfence/cloud-scanner/azure//examples/single-subscription" version = "0.2.0" mgmt-console-url = "<Console URL> eg. XXX.XXX.XX.XXX" mgmt-console-port = "443" deepfence-key = "<Deepfence-key> eg. XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" name = "deepfence-cloud-scanner" image = "quay.io/deepfenceio/cloud-scanner:2.1.1" } ``` Ensure that the `name` parameter is set to some unique string to avoid collision with existing resource names in the subscription Then run ```shell terraform init terraform plan terraform apply ``` For full details, refer to the `examples` provided in the GitHub repository: https://github.com/deepfence/terraform-azure-cloud-scanner ThreatMapper builds on a large library of controls - these are specific requirements and matching tests. For example, you will find controls that correspond to best-practice configurations of access to assets, such as enabling TLS access and blocking plain-text HTTP. Controls are grouped into benchmarks. Where multiple benchmarks are available, controls may be used by several benchmarks. When you run a compliance scan, you can select which benchmarks you wish to measure against, and ThreatMapper will then evaluate the appropriate controls and present the results, by benchmark, once the scan has completed. For full information, refer to . :::tip Maximizing Coverage For maximum coverage, you can use both Cloud Scanner and local Sensor Agent compliance scans together. You could scan your Azure infrastructure using Cloud Scanner, and using the Sensor Agent. :::
Project: Apache Ignite (App Definition and Development / Database)
File: CONTRIBUTING.md

Sign-in to Apache JIRA https://issues.apache.org/jira/ (To contribute code patches) Sing-in to Continuous Integration server https://ci.ignite.apache.org/ (To contribute documentation to the wiki) Sing-in to Subscribe to both Apache and lists with your personal (non-corporate) email address. Optionally you can subscribe to . To subscribe to any list in the you can send email to `list_name`-subscribe@ignite.apache.org, e.g., to dev-subscribe@ignite.apache.org and follow instructions. Send a welcome message to the dev list to introduce yourself to the community and saying that you're going to contribute. Request access to in the same email sharing your JIRA ID. Example of message: ``` Hello Ignite Community! My name is Aristarkh. I want to contribute to Apache Ignite and want to start with this issue - IGNITE-NNNNN, my JIRA username Aristarkh. Any help on this will be appreciated. Thanks! ``` Community values any type of contributions from . Community member can contibute to any areas from (Co)mmunity, (P)roject, (Do)cumentation, and (C)ode. Community values code contributions, but project value non-code contributions too, from writers, editors, testers, etc. We value user support on the list, as well as providing a summary of threads to Apache Ignite developers. Detailed guidelines on can be found in Apache Ignite follows . You can also cover Apache Ignite prefer to use , but in case something is going wrong please see Documentation can be contributed to End-User documentation https://ignite.apache.org/docs/latest/ . Use Suggest Edits. See also . Developer documentation, design documents, IEPs . Ask at to be added as editor. Markdown files, visible at GitHub, e.g. README.md; drawings explaining Apache Ignite & product internals. Javadocs for packages (package-info.java), classes, methods, etc. You can also blog about the product. It helps users to understand how to use Apache Ignite and helps spreading ideas. Feel free to share link to your blog with & lists. Blogs are reffered from . Create fork using GitHub interface. Download sources locally and setup project according to Project code style is specified Apache Ignite . Please install following components for development using IntelliJ IDEA Install . Code Inspection . Inspection profile is placed to IDEA , and it should be applied automatically. Configure . Usually all Maven builds are to be run with skipped tests: ``` ./mvnw -DskipTests ``` See also
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-machine-rm.1.md

% podman-machine-rm 1 podman\-machine\-rm - Remove a virtual machine podman machine rm [options] [name] Remove a virtual machine and its related files. What is actually deleted depends on the virtual machine type. For all virtual machines, the generated podman system connections are deleted. The ignition files generated for that VM are also removed as is its image file on the filesystem. Users get a display of what is deleted and are required to confirm unless the option `--force` is used. The default machine name is `podman-machine-default`. If a machine name is not specified as an argument, then `podman-machine-default` will be removed. Rootless only. Stop and delete without confirmation. Print usage statement. Do not delete the generated ignition file. Do not delete the VM image. Remove the specified Podman machine. ``` $ podman machine rm test1 The following files will be deleted: /home/user/.config/containers/podman/machine/qemu/test1.ign /home/user/.local/share/containers/podman/machine/qemu/test1fedora-coreos-33.20210315.1.0-qemu.x8664.qcow2 /home/user/.config/containers/podman/machine/qemu/test1.json Are you sure you want to continue? [y/N] y ``` Remove the specified Podman machine even if it is running. ``` $ podman machine rm -f test1 $ ``` , March 2021, Originally compiled by Ashley Cui <acui@redhat.com>
Project: Pinniped (Provisioning / Key Management)
File: configure-supervisor-with-entra-id.md

title: Configure the Pinniped Supervisor to use Miscrosoft Entra ID as an OIDC provider description: Set up the Pinniped Supervisor to use Miscrosoft Entra ID to login. cascade: layout: docs menu: docs: name: With Entra ID weight: 80 parent: howto-configure-supervisor Microsoft's Entra ID is the rebranding of Microsoft Azure AD. For more information, . To learn how to configure Entra ID, .
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: hostalias.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: application-with-hostalias spec: components: name: busybox-runner type: worker properties: image: busybox cmd: sleep '1000' traits: type: hostalias properties: hostAliases: ip: 127.0.0.1 hostnames: localname locals ```
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.3.1.2.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Major | KMS Accept Queue Size default changed from 500 to 128 in Hadoop 3.x* Restore the KMS accept queue size to 500 in Hadoop 3.x, making it the same as in Hadoop 2.x. | Major | WASB: Add support for StreamCapabilities* WASB: Support for StreamCapabilities. | Critical | triggerActiveLogRoll stuck on dead name node, when ConnectTimeoutException happens.* When a namenode A sends request RollEditLog to a remote NN, either the remote NN is standby or IO Exception happens, A should continue to try next NN, instead of getting stuck on the problematic one. This Patch is based on trunk. | Major | Use DelegationTokenIssuer to create KMS delegation tokens that can authenticate to all KMS instances* <!-- markdown --> This patch improves the KMS delegation token issuing and authentication logic, to enable tokens to authenticate with a set of KMS servers. The change is backport compatible, in that it keeps the existing authentication logic as a fall back. Historically, KMS delegation tokens have ip:port as service, making KMS clients only able to use the token to authenticate with the KMS server specified as ip:port, even though the token is shared among all KMS servers at server-side. After this patch, newly created tokens will have the KMS URL as service. A `DelegationTokenIssuer` interface is introduced for token creation. | Minor | publish all exposed ports to random ports when using bridge network* support -p and -P for bridge type network; | Critical | NM and service AM don't have updated status for reinitialized containers* In progress upgrade status may show READY state sooner than actual upgrade operations. External caller to upgrade API is recommended to wait minimum 30 seconds before querying yarn app -status. | Major | Service Upgrade: With default readiness check, the status of upgrade is reported to be successful prematurely* Improve transient container status accuracy for upgrade. | Major | Plugin interface to support more complex usernames in Hadoop* This patch enables "Hadoop" and "MIT" as options for "hadoop.security.auth\to\local.mechanism" and defaults to 'hadoop'. This should be backward compatible with pre-HADOOP-12751. This is basically HADOOP-12751 plus configurable + extended tests.
Project: Stolon (App Definition and Development / Database)
File: stolon-proxy.md

``` stolon-proxy [flags] ``` ``` --cluster-name string cluster name -h, --help help for stolon-proxy --kube-resource-kind string the k8s resource kind to be used to store stolon clusterdata and do sentinel leader election (only "configmap" is currently supported) --listen-address string proxy listening address (default "127.0.0.1") --log-color enable color in log output (default if attached to a terminal) --log-level string debug, info (default), warn or error (default "info") --metrics-listen-address string metrics listen address i.e "0.0.0.0:8080" (disabled by default) --port string proxy listening port (default "5432") --stop-listening stop listening on store error (default true) --store-backend string store backend type (etcdv2/etcd, etcdv3, consul or kubernetes) --store-ca-file string verify certificates of HTTPS-enabled store servers using this CA bundle --store-cert-file string certificate file for client identification to the store --store-endpoints string a comma-delimited list of store endpoints (use https scheme for tls communication) (defaults: http://127.0.0.1:2379 for etcd, http://127.0.0.1:8500 for consul) --store-key string private key file for client identification to the store --store-prefix string the store base prefix (default "stolon/cluster") --store-skip-tls-verify skip store certificate verification (insecure!!!) --store-timeout duration store request timeout (default 5s) --tcp-keepalive-count int set tcp keepalive probe count number --tcp-keepalive-idle int set tcp keepalive idle (seconds) --tcp-keepalive-interval int set tcp keepalive interval (seconds) ```
Project: Cloud Custodian (Provisioning / Automation & Configuration)
File: README-docker.md

The Cloud Custodian is a simple tool for sending notifications with . This image allows you to run the `c7n_mailer` purely in a Docker container, avoiding the need to install Python requirements. The basic command without Docker is: ```console $ c7n-mailer --update-lambda -c /tmp/mailer.yaml ``` So all we need to do is: Map a volume for the `mailer.yaml` Make sure we pass AWS credentials This single command passes both `~/.aws` and environment variables for AWS credentials. You can pick one or the other, but it's just convenient to pass both. ```console $ docker run --rm --env AWSSESSIONTOKEN=$AWSSESSIONTOKEN --env AWSDEFAULTREGION=$AWSDEFAULTREGION --env AWSACCESSKEYID=$AWSACCESSKEYID --env AWSSECRETACCESSKEY=$AWSSECRETACCESSKEY -v ~/.aws:/root/.aws -v /tmp:/tmp cloudcustodian/mailer:latest --update-lambda -c /tmp/mailer.yaml ``` NOTE: The path doesn't have to be `/tmp`. That's just an example. Just replace `/tmp` with your actual path in `-v /tmp:/tmp`.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: 04-configuring.md

id: configuring title: Configuring Utility APIs sidebar_label: Configuring description: Configuring, extending, and overriding utility APIs NOTE: The new frontend system is in alpha and is only supported by a small number of plugins. Utility APIs are extensions and can therefore optionally be amended with configurability, as well as inputs that other extensions attach themselves to. This section describes how to make use of that as a consumer of such utility APIs. To configure your Utility API extension, first you'll need to know its ID. That ID is formed from the API ref ID; check for details. Our example work API from would have the ID `api:plugin.example.work`. You configure it and all other extensions under the `app.extensions` section of your app-config. ```yaml title="in e.g. app-config.yaml or app-config.production.yaml" app: extensions: api:plugin.example.work: config: goSlow: false # ... other extensions ``` It's important to note that the `extensions` are a list (mind the initial `-`), and that the `api:plugin.example.work` entry is an object such that the `config` key needs to be indented below it. If you do not get those two pieces right, the application may not start up correctly. The extension config schema will tell you what parameters it supports. Here we override the `goSlow` extension config value, which replaces the default. Like with other extension types, you add input attachments to a Utility API by declaring the `attachTo` section of that attachment to point to the Utility APIs ID and input name. Well written input-enabled extension often have extension creator functions that help you make such attachments. Those functions typically set the `attachTo` section correctly on your behalf so that you don't have to figure them out. Like with other extension types, you replace Utility APIs with your own custom implementation using . ```tsx title="in your app" / highlight-add-start / import { createExtensionOverrides } from '@backstage/frontend-plugin-api'; class CustomWorkImpl implements WorkApi { / ... / } const myOverrides = createExtensionOverrides({ extensions: [ createApiExtension({ api: workApiRef, factory: () => createApiFactory({ api: workApiRef, factory: () => new CustomWorkImpl(), }), }), ], }); / highlight-add-end / // Remember to pass the overrides to your createApp export default createApp({ features: [ // ... other features / highlight-add-next-line / myOverrides, ], }); ``` In this example the overriding extension is kept minimal, but just like any other extension it can also have `deps`, configurability, and inputs. Check out for more details about that. When you create a replacement extension, in general you may want to mimic its extension config schema or input shapes where applicable. This makes it an easier thing to slot in to an app, since it'll be responding to extensibility the same way as the original one did.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: azurerm_mysql_servers.md

+++ title = "azurermmysqlservers resource" draft = false gh_repo = "inspec" platform = "azure" [menu] [menu.inspec] title = "azurermmysqlservers" identifier = "inspec/resources/azure/azurermmysqlservers.md azurermmysqlservers resource" parent = "inspec/resources/azure" +++ {{< inspec/azurermdeprecated resource="azuremysql_servers" >}} Use the `azurermmysqlservers` InSpec audit resource to test properties and configuration of multiple Azure MySQL Servers. This resource interacts with version `2017-12-01` of the Azure Management API. For more information see the . At the moment, there doesn't appear to be a way to select the version of the Azure API docs. If you notice a newer version being referenced in the official documentation please open an issue or submit a pull request using the updated version. This resource is available in the `inspec-azure` [resource pack](/inspec/glossary/#resource-pack). To use it, add the following to your `inspec.yml` in your top-level profile: depends: inspec-azure: git: https://github.com/inspec/inspec-azure.git You'll also need to setup your Azure credentials; see the resource pack . This resource first became available in 1.6.0 of the inspec-azure resource pack. An `azurermmysqlservers` resource block returns all Azure MySQL Servers, either within a Resource Group (if provided), or within an entire Subscription. describe azurermmysqlservers do ... end or describe azurermmysqlservers(resource_group: 'my-rg') do ... end The following examples show how to use this InSpec audit resource. describe azurermmysqlservers do it { should exist } its('names') { should include 'my-server-name' } end Filters the results to include only those servers which match the given name. This is a string value. describe azurermmysqlservers.where{ name.eql?('production-server-5') } do it { should exist } end Filters the results to include only those servers which reside in a given location. This is a string value. describe azurermmysqlservers.where{ location.eql?('eastus') } do it { should exist } end `id` `name` `sku` `location` `properties` `tags` `type` Azure resource ID. SQL Server name, e.g. `my-sql-server`. its('names') { should include 'my-sql-database' } SKU of mysql server. This is billing information related properties of a server. Resource location, e.g. `eastus`. its('locations') { should_not include 'eastus' } A collection of additional configuration properties related to the MySQL Server, e.g. `administratorLogin`. Resource tags applied to the MySQL Server. The type of Resource, typically `Microsoft.DBforMySQL/servers`. {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The control will pass if the filter returns at least one result. Use `should_not` if you expect zero matches. describe azurermmysqlservers do it { should exist } end Your [Service Principal](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal) must be setup with a `contributor` role on the subscription you wish to test.
Project: StarRocks (App Definition and Development / Database)
File: SHOW_DATA.md

displayed_sidebar: "English" This statement is used to display the amount of data, the number of copies, and the number of statistical rows in a database or a database table. Syntax: ```sql SHOW DATA [FROM <dbname>[.<tablename>]] ``` Note: If the FROM clause is not specified, the amount of data and copies subdivided into each table in the current db will be displayed. Where the data volume is the total data volume of all replicas. The number of copies is the number of copies of all partitions of the table and all materialized views. If the FROM clause is specified, the amount of data, the number of copies and the number of statistical rows subdivided into each materialized view under the table are displayed. Where the data volume is the total data volume of all replicas. The number of copies is the number of copies of all partitions corresponding to the materialized view. The number of statistical rows is the number of statistical rows of all partitions corresponding to the materialized view. When counting the number of rows, the copy with the largest number of rows among multiple copies shall prevail. The Total row in the result set represents the summary row. The Quota row represents the quota set by the current database. The Left line represents the remaining quota. Example 1: Display the data volume, copy quantity, summary data volume and summary copy quantity of each table in the current database. ```plain text SHOW DATA; +--+-+--+ | TableName | Size | ReplicaCount | +--+-+--+ | tbl1 | 900.000 B | 6 | | tbl2 | 500.000 B | 3 | | Total | 1.400 KB | 9 | | Quota | 1024.000 GB | 1073741824 | | Left | 1021.921 GB | 1073741815 | +--+-+--+ ``` Example 2: Display the amount of breakdown data, the number of copies, and the number of statistical rows in the specified table. ```plain text SHOW DATA FROM example_db.test; +--+--+--+--+-+ | TableName | IndexName | Size | ReplicaCount | RowCount | +--+--+--+--+-+ | test | r1 | 10.000MB | 30 | 10000 | | | r2 | 20.000MB | 30 | 20000 | | | test2 | 50.000MB | 30 | 50000 | | | Total | 80.000 | 90 | | +--+--+--+--+-+ ```
Project: YDB (App Definition and Development / Database)
File: logs.md

| Level | Numeric value | Value | | | | | | TRACE | 8 | Very detailed debugging information. | | DEBUG | 7 | Debugging information for developers. | | INFO | 6 | Debugging information for collecting statistics. | | NOTICE | 5 | An event essential for the system or the user has occurred. | | WARN | 4 | This is a warning, it should be responded to and fixed unless it's temporary. | | ERROR | 3 | A non-critical error. | | CRIT | 2 | A critical state. | | ALERT | 1 | System degradation is possible, system components may fail. | | EMERG | 0 | System outage (for example, cluster failure) is possible. | The logging level for different {{ ydb-short-name }} components can be configured individually. For each component, either an explicitly set value or a default logging level value can be applied. The default logging level value can also be changed. To change the logging level: Follow the link in the format ```bash http://<endpoint>:8765/cms ``` The `Cluster Management System` page opens. On the Configs tab, click on the `LogConfigItems` line. The `Create new item` button will show up along with a list of already created configuration elements. Click `Create new item` to create a new configuration item (or click the pencil button to edit a previously created item). To change the default logging level, select the desired logging level from the `Level` drop-down list under `Default log settings`. To change the logging level for individual components, use the table under `Component log settings`. In the line with the name of the component whose logging level you want to change, in the `Component` column, select the desired logging level from the drop-down list in the `Log level` column. To save changes, click `Submit`
Project: FOSSA (Provisioning / Security & Compliance)
File: init.md

The `fossa init` command creates examples of the following files if they do not exist in the current working directory: : `fossa-cli` Configuration file : File for stubbing and manually providing dependencies Note that both the `.fossa.yml` and `fossa-deps.yml` files are optional. They allow for more specificity on how fossa-cli performs dependency analysis, but they are not required for `fossa-cli` usage.
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: editor-and-ide-support.md

title: Editor and IDE Support kind: misc weight: 2 OPA can be integrated into editors and IDEs to provide features like syntax highlighting, query evaluation, policy coverage, and more. Note: See each integration for what features are supported! Not all support the same features. | Editor | Link | | | | | Atom | | | Emacs | | | IntelliJ IDEA | | | Nano | | | Sublime Text | | | TextMate | | | Vim | | | Visual Studio Code | | The Rego Playground provides a great editor to get started with OPA and share policies. Try it out at