Add statelessness doc for users #408
Conversation
There was a problem hiding this comment.
This is a really good start. I would recommend having a warning / note box at the top of "Using statelessness" that if the user adds a custom config, it is their responsibility to make sure it still works after system updates.
I'd also recommend changing this subhead to "Customizing configurations" or such, since that's more relatable to the average user.
-or- separate out the topics. This doc for describing statelessness. The other doc (Configuration File Locations) can describe which configs should be edited to customize software. I'll write something up in the other one and we / the team can decide what looks best.
|
|
||
| ### TODO: Others? | ||
|
|
||
| - pam, ssl |
There was a problem hiding this comment.
samba, acupsd
Found this in /etc/, used by the APC UPS daemon (not installed by default, in the repos)
❯ head /etc/changeme [12:43:38]
#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when apcupsd
# detects that the battery should be replaced.
# We send an email message to root to notify him.
There was a problem hiding this comment.
In my mind, this list is for things that a typical user might change. I don't want to make an exhaustive list of all the configs we ship
For pam and ssl, I'm skeptical we should point users at these configs without some sort of big flashing danger sign
See #409
|
Note to self: add the proper toml frontmatter |
Description
Statelessness doc for users.
Part of #400 and #305
Submitter Checklist
git rebase -i(if needed)