cwielenb/CNCF-Dataset huggingface dataset:
Project: ArangoDB (App Definition and Development / Database)
File: status_result.md

+++ title = "`statusresult` and `statusoutcome`" weight = 40 +++ `statusresult` and `statusoutcome` are type aliases to {{< api "basic_result<T, E, NoValuePolicy>" >}} and {{< api "basic_outcome<T, EC, EP, NoValuePolicy>" >}} in the usual way, but with a defaulted `NoValuePolicy` which selects on the basis of `status_code<DomainType>` instead. {{% notice note %}} If the `E` type is not some `status_code<>`, the default policy selector will complain. {{% /notice %}} The specifications are: ```c++ experimental::status_result<T, E = experimental::error> experimental::statusoutcome<T, E = experimental::error, EP = std::exceptionptr> ``` So, the default `E` is the erased errored status code `system_code`, which can represent any `genericcode`, `posixcode`, `win32code`, `ntcode`, `com_code` and many other integer error and status codings. Because it is an errored status code, it will always represent a failure. You can absolutely choose an `E` type which is non-erased e.g. `posix_code` directly. You can also choose an `E` type which is not contract guaranteed to be a failure, though your users may find that surprising. Whether to choose typed status codes versus the erased status codes depends on your use cases. Outcome replicates faithfully the implicit and explicit conversion semantics of its underlying types, so you can mix results and outcomes of `<systemerror2>` types exactly as you can the `<systemerror2>` types themselves e.g. typed forms will implicitly convert into erased forms if the source type is trivially copyable or move relocating. This means that you can return a `genericcode` from a function returning a `systemcode` or `error`, and it'll work exactly as you'd expect (implicit conversion). {{% notice note %}} As `statuscode<erased<T>>` is move-only, so is any `statusresult` or `status_outcome`. For some reason this surprises a lot of people, and they tend to react by not using the erased form because it seems "difficult". {{% /notice %}} It is actually, in fact, a wise discipline to follow to make all functions return move-only types if you care about determinism and performance. Whilst C++ 17 onwards does much to have the compiler avoid copying of identical function return values thanks to guaranteed copy elision, when a chain of functions return different types, if the programmer forgets to scatter `std::move()` appropriately, copies rather than moves tend to occur in non-obvious ways. No doubt future C++ standards will improve on the automatic use of moves instead of copies where possible, but until then making all your `result` and `outcome` types move-only is an excellent discipline. Note that move-only `result` and `outcome` capable code (i.e. your project is in Experimental Outcome configuration) usually compiles fine when `result` and `outcome` are copyable (i.e. your project is in Standard Outcome configuration), albeit sometimes with a few compiler warnings about unnecessary use of `std::move()`.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-volume-exists.1.md

% podman-volume-exists 1 podman\-volume\-exists - Check if the given volume exists podman volume exists volume podman volume exists checks if a volume exists. Podman returns an exit code of `0` when the volume is found. A `1` is returned otherwise. An exit code of `125` indicates there was another issue. Print usage statement Check if a volume called `myvol` exists (the volume does actually exist). ``` $ podman volume exists myvol $ echo $? 0 $ ``` Check if a volume called `mysql` exists (the volume does not actually exist). ``` $ podman volume exists mysql $ echo $? 1 $ ``` , January 2021, Originally compiled by Paul Holzinger `<paul.holzinger@web.de>`
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: sql-ref-syntax-ddl-drop-table.md

layout: global title: DROP TABLE displayTitle: DROP TABLE license: | 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. `DROP TABLE` deletes the table and removes the directory associated with the table from the file system if the table is not `EXTERNAL` table. If the table is not present it throws an exception. In case of an external table, only the associated metadata information is removed from the metastore database. If the table is cached, the command uncaches the table and all its dependents. ```sql DROP TABLE [ IF EXISTS ] table_identifier [ PURGE ] ``` IF EXISTS* If specified, no exception is thrown when the table does not exist. table_identifier* Specifies the table name to be dropped. The table name may be optionally qualified with a database name. Syntax: `[ databasename. ] tablename` PURGE* If specified, completely purge the table skipping trash while dropping table(Note: PURGE available in Hive Metastore 0.14.0 and later). ```sql -- Assumes a table named `employeetable` exists. DROP TABLE employeetable; -- Assumes a table named `employeetable` exists in the `userdb` database DROP TABLE userdb.employeetable; -- Assumes a table named `employeetable` does not exist. -- Throws exception DROP TABLE employeetable; Error: org.apache.spark.sql.AnalysisException: Table or view not found: employeetable; (state=,code=0) -- Assumes a table named `employeetable` does not exist,Try with IF EXISTS -- this time it will not throw exception DROP TABLE IF EXISTS employeetable; -- Completely purge the table skipping trash. DROP TABLE employeetable PURGE; ```
Project: StarRocks (App Definition and Development / Database)
File: privilege_faq.md

displayed_sidebar: "English" This error may happen if the role is not activated. You can run `select current_role();` to query the roles that have been activated for the user in the current session. If the required role is not activated, run to activate this role and perform operations using this role. If you want roles to be automatically activated upon login, the `user_admin` role can run or to set a default role for each user. After the default role is set, it will be automatically activated when the user logs in. If you want all the assigned roles of all users to be automatically activated upon login, you can run the following command. This operation requires the OPERATE permission at the System level. ```SQL SET GLOBAL activateallrolesonlogin = TRUE; ``` However, we recommend that you follow the principle of "least privilege" by setting default roles with limited privileges to prevent potential risks. For example: Common users can set the `read_only` role that has only the SELECT privilege as the default role, while avoiding setting roles with privileges like ALTER, DROP, and INSERT as default roles. Administrators can set the `dbadmin` role as the default role, while avoiding setting the `nodeadmin` role, which has the privilege to add and drop nodes, as the default role. This approach helps ensure that users are assigned roles with appropriate permissions, reducing the risk of unintended operations. You can run to assign the required privileges or roles to users. Creating tables within a database requires the database-level CREATE TABLE privilege. You need to grant the privilege to the user. ```SQL GRANT CREATE TABLE ON DATABASE <dbname> TO USER <useridentity>;; ``` `SHOW TABLES;` returns only tables on which the user has any privilege. If the user has no privilege on a table, this table will not be returned. You can grant any privilege on all tables in this database (using SELECT for example) to the user: ```SQL GRANT SELECT ON ALL TABLES IN DATABASE <dbname> TO USER <useridentity>; ``` The statement above is equivalent to `GRANT selectpriv ON db.* TO <useridentity>;` used in versions earlier than v3.0.
Project: Teleport (Provisioning / Security & Compliance)
File: 0158-account-recovery-protections.md

authors: Mike Jensen (mike.jensen@goteleport.com) state: draft Engineering @zmb3 && (@codingllama || @nklaassen) Product: (@xinding33 || @klizhentas || @russjones) This RFD addresses a flaw from a prior RFD when an account is under a targeted attack. This RFD clarifies how accounts are recovered when they are being targeted to by an attacker trying to prevent authentication. In order to accomplish this we only need a small change in the product behavior, the removal of the account lock on failed recovery attempts. The defines how an account can be recovered after the loss of credentials. However it does not ensure that an account is recoverable under the condition that it is under a targeted attack. Account authentication can (and should be) locked out after invalid attempts. Because passwords are user supplied, there are real brute force risks that must be considered. However this lockout mechanism can also prevent accounts from being accessible by the legitimate user. We must allow users access to their accounts even under conditions where they are under a targeted attack. In many applications (including Teleport) using a password reset will also reset any potential account auth lockouts. Because a user may have locked themselves out after failed attempts prior to the reset, this is a very intuitive UX. Prior to this RFD the reset mechanism also incorporated a lockout after 3 failures. This means that if an attacker wants to prevent access for an account they simply need to deny these two mechanisms. A failed reset lockout combined with a failed authentication lockout means that a legitimate users will have no ability to access their account. Because reset tokens are not user controlled, and neither tokens nor MFA devices are able to be brute forced, this lockout on reset is unnecessary. We should remove this mechanism so that legitimate users who have control over reset tokens or associated MFA can maintain access even under attack conditions. The API for retrieving and deleting recovery attempt records will be removed, as they exclusively support the now-obsolete lock mechanism. Additionally, the user status will no longer include a recovery attempt lock expiration. An event is already sent when an account recovery fails. That auditing will be preserved, no new metrics will be added. Upon implementing this change, all accounts previously locked due to account recovery issues will be immediately unlocked, making them available for recovery.
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-exp-model-search.md

layout: default title: mesheryctl-exp-model-search permalink: reference/mesheryctl/exp/model/search redirect_from: reference/mesheryctl/exp/model/search/ type: reference display-title: "false" language: en command: exp subcommand: model search models search a models by search string <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp model search [flags] </div> </pre> View current provider <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp model search [query-text] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for search </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -v, --verbose verbose output </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: in-toto (Provisioning / Security & Compliance)
File: exclude-patterns.md

The optional argument `excludepatterns` in the `intoto_run` API, also used by `--exclude` in the `in-toto-run` command line tool, applies to compile . Artifacts (materials and products) matched by an exclude pattern are not recorded when generating link metadata. Single asterisks match everything except a slash. Question marks match any one character except a slash. Ranges of characters can be used in patterns using the `[]` notation (i.e., `[a-z]`). A forward slash indicates a directory separator. A single `/` does not match any file. Separators at the beginning or middle (or both) of a pattern are relative to the current directory. Separators at the end of the pattern only match directories. (e.g., `/frotz` matches `frotz/` but not `doc/frotz`, `doc/frotz/` matches the `doc/frotz/` directory but not `a/doc/frotz/`; however `frotz/` matches `frotz/` and `a/frotz/`). To match an absolute path using a pattern, a single forward slash (`/`) at the beginning of the pattern is not sufficient. A single forward slash is used for relative roots rather than the "actual" root found in absolute paths. Using double forward slashes will get around this (i.e., `//<pattern>`). Leading double asterisks match any preceding path segments (e.g., `/foo` matches file or directory `foo`, and `/foo/bar` matches file or directory `bar` anywhere that is directly under directory `foo`). Trailing double asterisks match any succeeding path segments (e.g., `abc/` matches all files inside directory `abc`). A slash followed by two consecutive asterisks and a slash matches path segments between two directories (e.g., `a//b` matches `a/b`, `a/x/b`, `a/x/y/b` and so on). A pattern ending with a slash will match all descendant paths. This is equivalent to `{pattern}/`. If a pattern matches a directory, all files and subdirectories are also excluded. A hash serves as a comment, but it doesn't apply to this context. The hash can be escaped with a back-slash to match a literal hash (i.e., `\#`). An exclamation mark negates the rest of the pattern. Like the hash, this isn't particularly necessary for the context of exclude patterns. This can be escaped with a back-slash to match a literal exclamation mark (i.e., `\!`).
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.0.7.2.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Classpath of tasks is not set correctly (bug happens for multiple mapred local dirs only) | Critical | . | Mahadev konar | Mahadev konar | | | hadoop dfs does not complain about unknown option | Minor | . | dhruba borthakur | dhruba borthakur | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Mini map/reduce cluster should use multiple temp directories | Major | . | Owen O'Malley | Mahadev konar |
Project: Chef InSpec (Provisioning / Security & Compliance)
File: auditd_conf.md

+++ title = "auditd_conf resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "auditd_conf" identifier = "inspec/resources/os/auditdconf.md auditdconf resource" parent = "inspec/resources/os" +++ Use the `auditd_conf` Chef InSpec audit resource to test the configuration settings for the audit daemon. This file is typically located under `/etc/audit/auditd.conf'` on Unix and Linux platforms. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `auditd_conf` resource block declares configuration settings that should be tested: describe auditd_conf('path') do its('keyword') { should cmp 'value' } end where `'keyword'` is a configuration setting defined in the `auditd.conf` configuration file `('path')` is the non-default path to the `auditd.conf` configuration file `{ should cmp 'value' }` is the value that is expected This matcher will match any property listed in the `auditd.conf` configuration file. Property names and expected values are case-insensitive: `adminspaceleft`, `adminspaceleftaction`, `actionmailacct`, `confpath`, `content`, `diskerroraction`, `diskfullaction`, `flush`, `freq`, `logfile`, `logformat`, `maxlogfile`, `maxlogfileaction`, `numlogs`, `params`, `spaceleft`, `spaceleft_action` The following examples show how to use this Chef InSpec audit resource. describe auditd_conf do its('log_file') { should cmp '/full/path/to/file' } its('log_format') { should cmp 'raw' } its('flush') { should cmp 'none' } its('freq') { should cmp 1 } its('num_logs') { should cmp 0 } its('maxlogfile') { should cmp 6 } its('maxlogfile_action') { should cmp 'email' } its('space_left') { should cmp 2 } its('actionmailacct') { should cmp 'root' } its('spaceleftaction') { should cmp 'email' } its('adminspaceleft') { should cmp 1 } its('adminspaceleft_action') { should cmp 'halt' } its('diskfullaction') { should cmp 'halt' } its('diskerroraction') { should cmp 'halt' } end describe file(auditdconf.confpath) do its('group') { should cmp 'root' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `cmp` matcher compares values across types. its('freq') { should cmp 1 }
Project: Eclipse Che (App Definition and Development / Application Definition & Image Build)
File: release.md

Release is performed with GitHub Actions workflow . It is also used to release , if appropriate input parameter `releaseParent` is set to true. The release will perform the build of Maven Artifacts, build and push of all nesessary docker images, and bumping up development version. is the script that can be used for standalone release outside of GitHub Actions. However, ensure that all environment variables are set in place before invoking `./make-release.sh`, similarly to how it is outlined in : RELEASECHEPARENT - if `true`, will perform the release of Che Parent as well. VERSIONCHEPARENT - if RELEASECHEPARENT is `true`, here the version of Che Parent must be provided. REBUILDFROMEXISTING_TAGS - if `true`, release will not create new tag, but instead checkout to existing one. Use this to rerun failed attempts, without having to recreate the tag. BUILDANDPUSH_IMAGES - if `true`, will build all asociated images in directory. Set `false`, if this step needs to be skipped. BUMPNEXTVERSION - if `true`, will increase the development versions in main and bugfix branches. Set false, if this step needs to be skipped
Project: YDB (App Definition and Development / Database)
File: auth-sa-data.md

```typescript import { Driver, IamAuthService } from 'ydb-sdk'; import { IIamCredentials } from 'ydb-sdk/build/cjs/src/credentials'; export async function connect(endpoint: string, database: string) { const saCredentials: IIamCredentials = { serviceAccountId: 'serviceAccountId', accessKeyId: 'accessKeyId', privateKey: Buffer.from('--BEGIN PRIVATE KEY--\nyJ1yFwJq...'), iamEndpoint: 'iam.api.cloud.yandex.net:443', }; const authService = new IamAuthService(saCredentials); const driver = new Driver({endpoint, database, authService}); const timeout = 10000; if (!await driver.ready(timeout)) { console.log(`Driver has not become ready in ${timeout}ms!`); process.exit(1); } console.log('Driver connected') return driver } ```
Project: ClickHouse (App Definition and Development / Database)
File: crash-log.md

slug: /en/operations/system-tables/crash-log Contains information about stack traces for fatal errors. The table does not exist in the database by default, it is created only when fatal errors occur. Columns: `hostname` () Hostname of the server executing the query. `event_date` () Date of the event. `event_time` () Time of the event. `timestamp_ns` () Timestamp of the event with nanoseconds. `signal` () Signal number. `thread_id` () Thread ID. `query_id` () Query ID. `trace` (()) Stack trace at the moment of crash. Each element is a virtual memory address inside ClickHouse server process. `trace_full` (()) Stack trace at the moment of crash. Each element contains a called method inside ClickHouse server process. `version` () ClickHouse server version. `revision` () ClickHouse server revision. `build_id` () BuildID that is generated by compiler. Example Query: ``` sql SELECT * FROM system.crashlog ORDER BY eventtime DESC LIMIT 1; ``` Result (not full): ``` text Row 1: hostname: clickhouse.eu-central1.internal event_date: 2020-10-14 event_time: 2020-10-14 15:47:40 timestamp_ns: 1602679660271312710 signal: 11 thread_id: 23624 query_id: 428aab7c-8f5c-44e9-9607-d16b44467e69 trace: [188531193,...] tracefull: ['3. DB::(anonymous namespace)::FunctionFormatReadableTimeDelta::executeImpl(std::1::vector<DB::ColumnWithTypeAndName, std::1::allocator<DB::ColumnWithTypeAndName> >&, std::1::vector<unsigned long, std::_1::allocator<unsigned long> > const&, unsigned long, unsigned long) const @ 0xb3cc1f9 in /home/username/work/ClickHouse/build/programs/clickhouse',...] version: ClickHouse 20.11.1.1 revision: 54442 build_id: ``` See also system table
Project: Trivy (Provisioning / Security & Compliance)
File: alpine.md

Trivy supports the following scanners for OS packages. | Scanner | Supported | | :--: | :-: | | SBOM | | | Vulnerability | | | License | | Please see for supported versions. The table below outlines the features offered by Trivy. | Feature | Supported | |::|::| | Unfixed vulnerabilities | - | | | | Trivy detects packages that have been installed through `apk`. Alpine Linux offers its own security advisories, and these are utilized when scanning Alpine for vulnerabilities. See . When looking at fixed versions, it's crucial to consider the patches supplied by Alpine. For example, for CVE-2023-0464, the fixed version for Alpine Linux is listed as `3.1.0-r1` in . Note that this is different from the upstream fixed version, which is `3.1.1`. Typically, only the upstream information gets listed on [NVD], so it's important not to get confused. For Alpine vulnerabilities, the severity is determined using the values set by NVD. Trivy supports the following [vulnerability statuses] for Alpine. | Status | Supported | | :--: | :-: | | Fixed | | | Affected | | | Under Investigation | | | Will Not Fix | | | Fix Deferred | | | End of Life | | Trivy identifies licenses by examining the metadata of APK packages.
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.0.18.4.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Block reciever should not remove a finalized block when block replication fails | Blocker | . | Hairong Kuang | Hairong Kuang | | | FSNamesystem#commitBlockSynchronization adds under-construction block locations to blocksMap | Blocker | . | Hairong Kuang | dhruba borthakur | | | TestInjectionForSimulatedStorage occasionally fails on timeout | Major | . | Hairong Kuang | Hairong Kuang | | | Write pipeline recovery fails | Blocker | . | Hairong Kuang | dhruba borthakur | | | Blocks remain under-replicated | Blocker | . | Hairong Kuang | Hairong Kuang | | | Two minor problems in TestOverReplicatedBlocks | Minor | test | Tsz Wo Nicholas Sze | Tsz Wo Nicholas Sze | | | Namnode is stuck in safe mode | Major | . | Suresh Srinivas | Suresh Srinivas | | | NameNode and SecondaryNameNode fail to restart because of abnormal filenames. | Blocker | . | Raghu Angadi | Tsz Wo Nicholas Sze | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | A bunch of mapred unit tests are failing on Windows | Minor | test | Ramya Sunil | Raghu Angadi |