Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

letsencrypt: Improved Logging #3847

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

marcohald
Copy link

@marcohald marcohald commented Nov 29, 2024

I had struggles to get access to the certbot Logs, the only way i found was with an Backup and there in the Data dir of the addon.
So I changed the Log Directory to /ssl/letsencrypt-logs to make it easier for the users to get access.

I also added max_logs_backup as a configurable option with a default of 100 Log Files.
If it is not specified certbot creates 1000 Files.

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced a new configuration option to specify the maximum number of log backups to retain.
    • Added a new directory for storing Let's Encrypt logs during initialization.
    • Enhanced logging and configuration management for Let's Encrypt certificates.
  • Documentation

    • Updated translations to include descriptions for the new log backup configuration option.

Copy link

@home-assistant home-assistant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @marcohald

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@home-assistant home-assistant bot marked this pull request as draft November 29, 2024 12:20
@home-assistant
Copy link

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Copy link
Contributor

coderabbitai bot commented Nov 29, 2024

📝 Walkthrough

Walkthrough

The changes introduce a new configuration option max_logs_backup in the letsencrypt/config.yaml, allowing users to specify the maximum number of log backups to retain. The file-structure.sh script is updated to create a directory for Let's Encrypt logs. Additionally, the run script in the services directory is modified to enhance logging capabilities by incorporating the new LOGS_DIR and MAX_LOGS_BACKUP variables. Lastly, the translations/en.yaml file is updated to include a description for the new configuration option, ensuring users understand its purpose.

Changes

File Path Change Summary
letsencrypt/config.yaml Added new option max_logs_backup: 100 in options and max_logs_backup: int in schema.
letsencrypt/rootfs/etc/cont-init.d/file-structure.sh Added directory creation for Let's Encrypt logs: mkdir -p /ssl/letsencrypt-logs.
letsencrypt/rootfs/etc/services.d/lets-encrypt/run Introduced LOGS_DIR and MAX_LOGS_BACKUP variables; updated commands to use new logging options.
letsencrypt/translations/en.yaml Added new entry for max_logs_backup with name and description in the configuration section.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Config
    participant Script
    participant LogDir

    User->>Config: Set max_logs_backup
    Config->>Script: Retrieve max_logs_backup
    Script->>LogDir: Create /ssl/letsencrypt-logs
    Script->>Script: Use max_logs_backup in logging options
    Script->>User: Log management updated
Loading

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @coderabbitai title anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (4)
letsencrypt/translations/en.yaml (1)

45-51: Enhance the configuration description with additional details

While the description effectively explains the basic functionality, consider adding more details to help users make informed decisions:

  max_logs_backup:
    name: Max Logs Backup
    description: >-
      Specifies the maximum number of backup logs that
-      should be kept by Certbot's built in log rotation.
-      Setting this flag to 0 disables log rotation entirely,
-      causing Certbot to always append to the same log file.
+      should be kept by Certbot's built-in log rotation in the
+      /ssl/letsencrypt-logs directory. Defaults to 100 (previously 1000).
+      Setting this to 0 disables log rotation entirely,
+      causing Certbot to always append to the same log file.
+      Must be a non-negative integer.

This enhanced description:

  • Specifies the log directory location
  • Mentions the default and previous values
  • Clarifies the valid range for the setting
letsencrypt/rootfs/etc/cont-init.d/file-structure.sh (2)

7-7: Add error handling and set appropriate permissions for the logs directory.

While creating the logs directory is good, consider:

  1. Adding error handling for directory creation
  2. Setting appropriate permissions to ensure the logs are readable by users but secure
-mkdir -p /ssl/letsencrypt-logs
+if ! mkdir -p /ssl/letsencrypt-logs; then
+    bashio::log.error "Failed to create letsencrypt-logs directory"
+    exit 1
+fi
+chmod 755 /ssl/letsencrypt-logs

Line range hint 87-92: Enhance security of TransIP RSA key handling.

The current implementation might expose the API key in process listings. Consider:

  1. Adding error handling for the openssl command
  2. Using a more secure way to pass the API key to openssl
 if bashio::config.exists 'dns.transip_api_key'; then
     TRANSIP_API_KEY=$(bashio::config 'dns.transip_api_key')
-    echo "${TRANSIP_API_KEY}" | openssl rsa -out /data/transip-rsa.key
+    if ! echo "${TRANSIP_API_KEY}" | openssl rsa -out /data/transip-rsa.key 2>/dev/null; then
+        bashio::log.error "Failed to process TransIP RSA key"
+        exit 1
+    fi
     chmod 600 /data/transip-rsa.key
 fi
letsencrypt/rootfs/etc/services.d/lets-encrypt/run (1)

340-343: Consider reducing duplication of logging parameters.

While the logging parameters are correctly implemented for both DNS and HTTP challenges, they are duplicated in both certbot commands.

Consider extracting the common parameters into a variable:

+ LOGGING_ARGS=("--logs-dir" "$LOGS_DIR" "--max-log-backups" "$MAX_LOGS_BACKUP")

# For DNS challenge
certbot certonly --non-interactive --keep-until-expiring --expand \
    --email "$EMAIL" --agree-tos \
    "${KEY_ARGUMENTS[@]}" \
    --cert-name "${DOMAIN_ARR[1]}" "${DOMAIN_ARR[@]}" \
    --config-dir "$CERT_DIR" --work-dir "$WORK_DIR" \
-    --logs-dir "$LOGS_DIR" --max-log-backups "$MAX_LOGS_BACKUP" \
+    "${LOGGING_ARGS[@]}" \
    --preferred-challenges "$CHALLENGE" "${PROVIDER_ARGUMENTS[@]}" \
    --preferred-chain "ISRG Root X1" \
    "${EAB_ARGUMENTS[@]}"

# For HTTP challenge
certbot certonly --non-interactive --keep-until-expiring --expand \
    --email "$EMAIL" --agree-tos \
    "${KEY_ARGUMENTS[@]}" \
    --cert-name "${DOMAIN_ARR[1]}" "${DOMAIN_ARR[@]}" \
    --config-dir "$CERT_DIR" --work-dir "$WORK_DIR" \
-    --logs-dir "$LOGS_DIR" --max-log-backups "$MAX_LOGS_BACKUP" \
+    "${LOGGING_ARGS[@]}" \
    --preferred-challenges "$CHALLENGE" "${ACME_CUSTOM_SERVER_ARGUMENTS[@]}" --standalone \
    --preferred-chain "ISRG Root X1" \
    "${EAB_ARGUMENTS[@]}"

Also applies to: 350-353

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 5d9cb42 and defc040.

📒 Files selected for processing (4)
  • letsencrypt/config.yaml (2 hunks)
  • letsencrypt/rootfs/etc/cont-init.d/file-structure.sh (1 hunks)
  • letsencrypt/rootfs/etc/services.d/lets-encrypt/run (5 hunks)
  • letsencrypt/translations/en.yaml (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
letsencrypt/config.yaml (6)

Pattern */**(html|markdown|md): - For instructional content in documentation, use a direct and authoritative tone. Avoid expressions of politeness such as 'may' or 'please', and ensure the goal of the instruction is fronted.

  • Apply the Microsoft Style Guide to ensure documentation maintains clarity and conciseness.
  • In step-by-step instructions, front the location phrase in the instructional sentence.
  • In step-by-step instructions, front the 'goal' in the instructional sentence.
  • In step-by-step instructions, if in doubt what to front, front the 'goal' before the location phrase in the instructional sentence.
  • do not hyphenate terms like 'top-right' or 'bottom-left' with 'corner'

Pattern */**(html|markdown|md): - Use bold to mark UI strings.

  • If "" are used to mark UI strings, replace them by bold.

Pattern */**(html|markdown|md): - Be brief in your replies and don't add fluff like "thank you for..." and "Please let me know if"


Pattern */**(html|markdown|md): - Use sentence-style capitalization also in headings.


Pattern */**(html|markdown|md): do not comment on HTML used for icons


Pattern */**(html|markdown|md): Avoid flagging inline HTML for embedding videos in future reviews for this repository.

🔇 Additional comments (8)
letsencrypt/config.yaml (1)

27-27: LGTM: New configuration option added correctly.

The default value of 100 log backups is a reasonable choice, being more conservative than certbot's default of 1000.

letsencrypt/rootfs/etc/cont-init.d/file-structure.sh (4)

Line range hint 9-71: LGTM! Secure handling of sensitive DNS configuration.

The code correctly:

  • Uses bashio::config for safe configuration reading
  • Sets appropriate file permissions (600) for the sensitive data

Line range hint 73-85: LGTM! Well-documented ClouDNS configuration handling.

The code correctly implements the special case for ClouDNS authentication options with clear documentation.


Line range hint 94-108: LGTM! Clean handling of deprecated options.

The code properly removes deprecated configuration options using the appropriate bashio::addon.option command.


7-7: Verify integration with max_logs_backup configuration.

Let's ensure that the new logs directory is properly integrated with the max_logs_backup configuration mentioned in the PR description.

✅ Verification successful

Based on the search results, I can now provide a final response since I found the relevant configuration and implementation details:

Verified: The logs directory is properly integrated with max_logs_backup configuration

The new /ssl/letsencrypt-logs directory is correctly integrated with the max_logs_backup configuration option:

  • The max_logs_backup option is properly defined in letsencrypt/config.yaml with a default value of 100
  • The option is documented in the translations file with a clear description of its purpose
  • The logs directory and configuration are properly used together in the service script (letsencrypt/rootfs/etc/services.d/lets-encrypt/run), where both are passed to certbot:
    --logs-dir "$LOGS_DIR" --max-log-backups "$MAX_LOGS_BACKUP"
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the integration of the new logs directory with max_logs_backup configuration

# Check if max_logs_backup is defined in config.yaml
echo "Checking config.yaml for max_logs_backup:"
rg -A 2 "max_logs_backup" config.yaml

# Check if the logs directory is used in the service script
echo "Checking service script for logs directory usage:"
rg -A 2 "letsencrypt-logs" "rootfs/etc/services.d/lets-encrypt/run"

Length of output: 436


Script:

#!/bin/bash
# Let's first find the configuration and service files
echo "Finding configuration files:"
fd -e yaml -e json

echo -e "\nFinding service-related files:"
fd "run|lets-encrypt"

echo -e "\nChecking content of found files for logs and backup configuration:"
for file in $(fd -t f); do
    if grep -q "max_logs\|letsencrypt-logs" "$file" 2>/dev/null; then
        echo -e "\nFile: $file"
        cat "$file"
    fi
done

Length of output: 99231

letsencrypt/rootfs/etc/services.d/lets-encrypt/run (3)

7-7: LGTM! Variable declarations are well-structured.

The new variables LOGS_DIR and MAX_LOGS_BACKUP are appropriately declared and initialized. The log directory path under /ssl is a suitable choice for certificate-related logs.

Also applies to: 23-23


Line range hint 307-326: LGTM! Certificate detection logic is robust.

The certbot command has been correctly updated to include the new logging parameters while maintaining the existing robust certificate detection logic.


7-7: Verify log directory creation.

Ensure that the LOGS_DIR path (/ssl/letsencrypt-logs) is created before it's used by certbot.

✅ Verification successful

Log directory creation is properly handled

The /ssl/letsencrypt-logs directory is created by the initialization script at letsencrypt/rootfs/etc/cont-init.d/file-structure.sh before any service starts. The directory creation is handled with mkdir -p command which ensures the directory exists.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if the log directory is created in the file-structure initialization script
rg -l "mkdir.*letsencrypt-logs" rootfs/etc/cont-init.d/

Length of output: 121


Script:

#!/bin/bash
# Let's first find all initialization scripts in the repository
fd "cont-init.d" --type d

# Then search for any file that creates the logs directory
rg -l "mkdir.*ssl" 

Length of output: 366


Script:

#!/bin/bash
# Let's check the content of file-structure.sh to verify log directory creation
cat letsencrypt/rootfs/etc/cont-init.d/file-structure.sh

Length of output: 7292

letsencrypt/config.yaml Show resolved Hide resolved
Log Directory is now stored in /ssl/letsencrypt-logs to make it easier for the users to get access
max_logs_backup is now a configurable option with a default of 100 Log Files (1000 if not specified)
@agners
Copy link
Member

agners commented Dec 3, 2024

Hm, we do log and store the output of the add-on. Does the Certbot internal logs have additional information then what is shown in the output?

@marcohald
Copy link
Author

Yes they do, I should have mentioned that in the PR.
For example i use the Cloudflare DNS Integration.
It failed for me with an exception in the underling library, that was not fully logged in the normal Container Output

@agners
Copy link
Member

agners commented Dec 4, 2024

It failed for me with an exception in the underling library, that was not fully logged in the normal Container Output

I wonder if we could make it output all information on the console 🤔 There are the verbosity levels. Maybe we could just make this an add-on setting, and then the user can just run the add-on on sees the error there? I think this would be more user friendly.

In a way, we want to logs all over the place. Having it just part of the regular add-on log would be kinda nice IMHO. Especially, now, with the new add-on logs where you can use the full history of the journald based log you can go back quite significantly.

That said, if something logs massive amount of data, you'll loose the add-on log at one point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants