Tree6024

joined 1 year ago
sorted by: new top controversial old
Mirrors.fedoraproject.org Down right now in c/[email protected]
[–] Tree6024 2 points 1 year ago (1 children)

I see this was posted 16 hours ago. Mirrors are back online. ( i didn't notice the outage)

Needed somewhere to talk about my favorite game. in c/osrs
[–] Tree6024 2 points 1 year ago

Haven't played this game in quite a while. I think last time I played I was in edgeville, cutting yew trees. Used to play with friends, but one by one, we all got older and quit. Now, I sign in once or twice a year.

Using Fedora CoreOS, how can I add secrets to podman systemd services? in c/[email protected]
[–] Tree6024 1 points 1 year ago (1 children)

Thanks for the quick response :)

I read through the operator notes yesterday.

To avoid any possibility of leaking sensitive information, it’s best to store secrets in a dedicated service such as Hashicorp Vault.

I just wish there was a short example on how to use:

  • vault + ignition
  • or vault + systemd
  • or vault + podman

I just asked ChatGPT and it's solution seems good:

Within the Unit File, in the PreStart condition, retreive the secrets from vault.

[Unit]
Description=Your Service
...

[Service]
ExecStartPre=/usr/local/bin/fetch_vault_secret.sh
Environment="SECRET_KEY=%i"  # Replace %i with the actual secret path in Vault

ExecStart=/path/to/your/service

[Install]
...

Where the fetch_vault_secret.sh script looks like this:

#!/bin/bash
export VAULT_ADDR="https://vault.lan:8200"
export VAULT_TOKEN="your-vault-token"

SECRET_KEY="${SECRET_KEY//\//%2F}"  # Replace / with %2F in the secret path

secret_value=$(vault kv get -field=value secret/${SECRET_KEY})
export SECRET_VALUE="$secret_value"

I'll play with it some, and post the results back later.

If anyone has a better solution please let me know :)

3
Using Fedora CoreOS, how can I add secrets to podman systemd services? (self.fedora)
 

Like the title says, does anyone know how to give systemd services a secret?

For example: postgresql.bu

variant: fcos
version: 1.4.0
storage:
  directories:
    - path: /opt/services/postgres/data
      overwrite: true
      mode: 0755
systemd:
  units:
    - name: postgres.service
      enabled: true
      contents: |
        [Unit]
        Description=The PostgreSQL object-relational database system
        Wants=network-online.target
        After=network-online.target

        [Service]
        Type=notify
        NotifyAccess=all
        Restart=on-failure
        RestartSec=60
        ExecStartPre=-/bin/podman kill postgres
        ExecStartPre=-/bin/podman rm postgres
        ExecStartPre=/bin/podman pull docker.io/library/postgres:15
        ExecStart=/bin/podman run --name postgres \
            --volume /opt/services/postgres/data:/var/lib/postgresql/data:z \
            --env POSTGRES_USER=admin \
            --env POSTGRES_PASSWORD=admin \
            --env POSTGRES_DB=admin \
            --replace --sdnotify=conmon \
            --publish 0.0.0.0:5432:5432/tcp \
            --restart=unless-stopped \
            --log-level info \
            docker.io/library/postgres:15

        [Install]
        WantedBy=multi-user.target

If that is my SystemD unit file, can I replace:

env POSTGRES_PASSWORD=admin with a value that is discovered at runtime?

Growing Pains? in c/main
[–] Tree6024 7 points 1 year ago (1 children)

I know this is an older post but I'll comment anyway.

I haven't been getting any errors, but sometimes when I browse, I'd be scrolling through the comments of a post, and suddenly the post would change.

I didn't dig into it much, but if it starts happening more often, I'll record my network traffic (for the browser) and attach the .har file.

does sh.itjust.works allow criticism of CCP? in c/main
[–] Tree6024 9 points 1 year ago (1 children)

Technically correct, much like you can't do anything about what your neighbour does in their own home.

However, what sh.itjust.works and lemmy.ml can do is block 'bad server' communication.

They can also enforce rules on their own 'home' as it were.