Repository: bottlerocket-os/bottlerocket
File: sources/logdog/src/log_request.rs (Rust)

Code before:
const VARIANT_REQUESTS: &str = include_str!("../conf/current/logdog.conf");

/// Patterns to filter from settings output.  These follow the Unix shell style pattern outlined
/// here: https://docs.rs/glob/0.3.0/glob/struct.Pattern.html.
const SENSITIVE_SETTINGS_PATTERNS: &[&str] = &[
    "*.user-data",
    "settings.kubernetes.bootstrap-token",
    // Can contain a username:password component
    "settings.network.https-proxy",
    "settings.kubernetes.server-key",
    "settings.container-registry.credentials",
    // Can be stored in settings.aws.credentials, but user can also add creds here
    "settings.aws.config",
    "settings.aws.credentials",
];

/// Returns the list of log requests to run by combining `VARIANT_REQUESTS` and `COMMON_REQUESTS`.
/// These are read at compile time from files named `logdog.conf` and `logdog.common.conf`
/// respectively.
pub(crate) fn log_requests() -> Vec<&'static str> {
    COMMON_REQUESTS
        .lines()
        .chain(VARIANT_REQUESTS.lines())
        .filter(|&command| !command.is_empty() && !command.trim_start().starts_with('#'))
        .collect()
}

/// A logdog `LogRequest` represents a line from the config file. It starts with a "mode" that
/// specifies what type of request it is, e.g. `exec ` for a command or `http` for an HTTP get
/// request. Some modes then require a `filename` that determines where the data will be saved in
/// the output tarball.  The final field is `instructions` which is any additional information
/// needed by the given mode.  For example, an `exec` requests' instructions will include the
/// program and program arguments. An `http` request's instructions will be the URL.
///
/// # Examples
///
/// This request will run the echo program with the arguments `hello` `world` and write the output
/// to a file named `hello.txt`. In this example `exec` is the mode, `hello.txt` is the output
/// filename, and `echo hello world` is the instructions.
///
/// ```text
/// exec hello.txt echo hello world
/// ```
///
/// This request will run an HTTP get request to the url `http://example.com` and write the response
/// body to `example.txt`:
///
/// ```text
/// http example.txt http://example.com
/// ```
///

Review comment (suggestion):
Typically for these `.conf.d` directories, the snippets are added in order, e.g.:
```
00-release.conf
10-networkd.conf
20-k8s.conf
```

That doesn't matter a whole lot here, since entries can't really conflict or overwrite each other, but it might still be useful so that all the commands are run in a predictable order. And it 

Also, I would set min and max depth to 1 since we don't expect to recurse into nested dirs.

Code after:
/// Patterns to filter from settings output.  These follow the Unix shell style pattern outlined
/// here: https://docs.rs/glob/0.3.0/glob/struct.Pattern.html.
const SENSITIVE_SETTINGS_PATTERNS: &[&str] = &[
    "*.user-data",
    "settings.kubernetes.bootstrap-token",
    // Can contain a username:password component
    "settings.network.https-proxy",
    "settings.kubernetes.server-key",
    "settings.container-registry.credentials",
    // Can be stored in settings.aws.credentials, but user can also add creds here
    "settings.aws.config",
    "settings.aws.credentials",
];

/// Returns the list of log requests to run by combining `VARIANT_REQUESTS` and `COMMON_REQUESTS`.
/// These are read at compile time from files named `logdog.conf` and `logdog.common.conf`
/// respectively.
pub(crate) fn log_requests() -> Result<Vec<String>> {
    Ok(WalkDir::new(REQUESTS_DIR)
        .max_depth(1)
        .min_depth(1)
        .sort_by_file_name()
        .into_iter()
        .collect::<std::result::Result<Vec<_>, _>>()?
        .into_iter()
        .filter(|entry| entry.path().is_file())
        .map(|entry| {
            eprintln!("Checking: {}", entry.path().display());
            fs::read_to_string(entry.path()).context(error::FileReadSnafu { from: entry.path() })
        })
        .collect::<std::result::Result<Vec<_>, _>>()?
        .iter()
        .flat_map(|commands| commands.lines())
        .map(std::borrow::ToOwned::to_owned)
        .filter(|command| !command.is_empty() && !command.trim_start().starts_with('#'))
        .collect())
}

/// A logdog `LogRequest` represents a line from the config file. It starts with a "mode" that
/// specifies what type of request it is, e.g. `exec ` for a command or `http` for an HTTP get
/// request. Some modes then require a `filename` that determines where the data will be saved in
/// the output tarball.  The final field is `instructions` which is any additional information
/// needed by the given mode.  For example, an `exec` requests' instructions will include the
/// program and program arguments. An `http` request's instructions will be the URL.
///
/// # Examples
///
/// This request will run the echo program with the arguments `hello` `world` and write the output
/// to a file named `hello.txt`. In this example `exec` is the mode, `hello.txt` is the output
/// filename, and `echo hello world` is the instructions.
///