Configure kredits-github #37
No Reviewers
Labels
Clear labels
monitoring
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
security
ui/ux
wontfix
service
discourse
Kosmos Community Forums
Infrastructure metrics, alerts, notifications, etc.
service
accounts
Kosmos Accounts
service
drone-ci
Kosmos Drone CI
service
email
mail.kosmos.org
service
garage
S3-compatible object storage
service
gitea
Kosmos Gitea
service
ipfs
Kosmos IPFS
service
mastodon
kosmos.social
service
nostr
Relays, Blossom server, etc.
service
postgres
Database cluster
service
remotestorage
Portable data storage for the Web
service
wiki
Kosmos Wiki
service
xmpp
Kosmos Chat
Something is not working
Graphic/visual design
Config, builds, CI, deployment, etc.
Documentation
This issue or pull request already exists
Improving existing functionality
New functionality
Dive in, and start contributing
Something to consider
Not a bug
Small contribution
Medium contribution
Large contribution
Currently not actionable
Manual IT ops activities
Looking for an answer
release
major
release
minor
release
patch
All your base are belong to us
User interface, process design, etc.
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/chef#37
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This is running on
barnard.kosmos.org, but for some reason that I can't figure out nginx just refuses connections to the site. All configs and services look good to me, and nothing is throwing errors.closes #35
Configure kosmos-githubto Configure kredits-githubSorry, the commit has the wrong app name.
I fixed the issue. All working now.
As the environment contains secret I'm switching the systemd unit to use EnvironmentFile instead.
LGTM apart from that and the references to sockethub that I fixed.
I cannot see how that makes it more secure from the document you linked. Care to explain?
(I assume this comes from me pasting a sentence from and link to the official systemd docs, where it says you shouldn't put secrets in systemd environment vars?)
Also, wouldn't we need to do that for all our cookbooks/systemd units then? (Meaning there's an issue missing about it.)
I checked, it turns out I misunderstood EnvironmentFile. Using it I thought it wouldn't show the environment variables in
/proc/$ID/environ, but that can only be read by root, not regular users. So we can use Environment directives, as long as the systemd unit file is not world readable (so the unit file itself to be something like 640)I think every systemd unit file that contains secrets shouldn't be world readable, we can create an issue about it
I have also found this regarding
EnvironmentFile, Poettering said it was a mistake: https://unix.stackexchange.com/a/419061I reverted my
EnvironmentFilechange and fixed the permission in2cf6112OK, but that still doesn't explain why this one cookbook would be the only one where we have to solve the problem. I merely did what we do in literally all of our site cookbooks.
Also, that still leaves the question about env vars in systemd units being unsecure for other reasons than reading the file itself, as outlined by the systemd docs I linked.
Can you link that page again? I can't find it
Edit: I created #38 for the Systemd environment variables