3 ms·

Also, you shouldn't really be running sensitive commands on a production server ever. And if you are you really should clear the bash_history. Sensitive data le

Also, you shouldn't really be running sensitive commands on a production server ever. And if you are you really should clear the bash_history. Sensitive data leaks into that file and I don't see a clear argument that it really makes your life any faster. Use something like etckeeper and document the important stuff on an internal, authenticated, Wiki or some other more secure central note repository. Often you don't need the whole history for prod, but the few important commands. In a perfect world most things are done via config management, leaving only debugging to be done on prod servers, which should be transient in nature. In the real world, prod servers should still get treated as transiently as possible.

viraptor 9y ago
You shouldn't, but you will. Especially in small companies. The production with no access is a holy grail that is both a good idea and harder to achieve the bigger you get. Almost nobody starts a new service (unless you're already in a company where a framework for this exists) with "I'll use an immutable architecture with staging environment and simple traffic failover and database I can easily clone for debugging and...". They start with "I'll get a VM and put my app on it". Authenticated wiki or documentation repo is fine. Automation for tasks, external log shopping, error collection, separate db interface even better. Complete mirror of production in a separate, debuggable environment is the bees knees. But they all take time to achieve. In the meantime, with one or two VMs running your business, I bet you're glad to have a command history, especially if something's down at 3am :-) It all depends on your size and system.