Topic: configuration
-
Writing idempotent admin scripts: check-then-change, drop-in files and marker comments
An admin script an agent might re-run after a partial failure or a repeated schedule should leave the system in the same state whether it runs once or five times. Checking current state before changing it, writing separate drop-in files instead of editing shared ones, and marking any block a script owns are the three patterns that make that reliable.
-
Tracing a configuration value from declaration to effective runtime behavior
Explain why editing a configuration file did or did not change application behavior by tracing the value through its actual loading and override path.
-
ConfigMaps and Secrets in Kubernetes: size limits, update propagation and what a Secret does not protect
ConfigMaps and Secrets are both 1 MiB-capped key-value objects; volume-mounted keys refresh after a kubelet sync delay while environment variables never do, subPath mounts never update, and a Secret is only base64-encoded and stored unencrypted in etcd unless encryption at rest and RBAC are configured.
-
Promoting one build through environments: configuration promotion and dev-prod parity
Build an artifact once, give it an immutable identity, and promote that exact artifact from test to staging to production while only the environment-specific configuration changes; keep environments alike in backing services and topology so that a passed stage predicts the next one.
-
Testing configuration changes that alter another user’s authority
Identify configuration writes that indirectly grant permissions even when their endpoint looks like ordinary settings editing. This proposal follows the resulting authority change rather than judging risk from the route name.
-
The Object Data Manager: why AIX device and system configuration isn't in a file
AIX stores device definitions, SRC subsystem entries and many system attributes as objects in the Object Data Manager (ODM) database under /etc/objrepos and /usr/lib/objrepos, not in editable text files. lsattr, lsdev and chdev are the supported interface; chdev -P defers a change to the next reboot instead of applying it immediately.
-
Changing an SMF-managed service's configuration with svccfg instead of editing its config file
svccfg listprop/setprop read and write a service's persistent configuration in the SMF repository; svcadm refresh copies it into the running snapshot. Where SMF generates a service's config file (for example /etc/resolv.conf from network/dns/client), hand-editing that file is overwritten.
-
Docker Compose for local development: override files, profiles, healthy dependencies and watch
Keep one committed compose.yaml that mirrors production shape, add a compose.override.yaml for local ports and bind mounts, gate optional tooling behind profiles, make depends_on wait for service_healthy, and use develop.watch to sync or rebuild on file changes.
-
Managing secrets outside the repository
Credentials belong in protected configuration that is injected at runtime, never in version control, images, or logs. Each service gets its own narrowly scoped credentials, and rotation is a practiced procedure rather than an emergency. The steps follow the OWASP secrets management cheat sheet and the Twelve-Factor separation of config from code.
-
Secure defaults and fail-closed design
Saltzer and Schroeder's fail-safe defaults principle bases access on explicit permission, so that a mistake denies rather than grants; applied today it means deny-by-default authorisation, configuration that refuses to start when a security setting is missing, and error paths that close access instead of opening it.
-
YAML 1.1 vs 1.2 implicit typing: the Norway problem, octal numbers and which parsers use which
YAML 1.1's boolean type treats yes, no, on and off as booleans and a leading zero as octal; YAML 1.2's Core Schema narrows booleans to true/false and requires an explicit 0o prefix for octal — and PyYAML, js-yaml and gopkg.in/yaml.v3 each land in a different place between the two.
-
Setting Linux kernel parameters with sysctl: runtime changes versus /etc/sysctl.d
sysctl -w changes a kernel parameter until the next reboot; making it persistent means dropping a file into /etc/sysctl.d/ and understanding the load order across /usr/lib, /etc and /run. sysctl --system applies every configured file and reports which one wins on a conflict.
Machine-readable: JSON