TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: How do you document server installs

2 pointsby tonteldoosover 8 years ago
Good day HN,<p>I&#x27;m sure everyone here has set up many servers (or VPSs, VMs, etc) over the course of their work and&#x2F;or side-projects&#x2F;hobbies&#x2F;personal rigs. I do a little bit of both, and am struggling to find a consistent way to log or document the whole process.<p>What do you use to document these setups, specifically:<p><pre><code> * Versions of installed packages &#x2F; method of installation * Config file changes * Setup commands&#x2F;scripts run * Deployment commands * Custom scripts&#x2F;changes * Order of changes * Information from vendors&#x2F;maintainers covering niche cases&#x2F;installation issues </code></pre> Especially if it&#x27;s a non-trivial setup (or the first time you&#x27;re doing it), how do you keep track of what the final working approach was, the order of installation, etc?<p>Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it&#x27;s not a comprehensive solution, and possibly error-prone.<p>Bonus points if your system has a way to easily redo all the work you&#x27;ve done (puppet, chef?).<p>Thanks!

1 comment

shermanyoover 8 years ago
&gt; Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it&#x27;s not a comprehensive solution, and possibly error-prone.<p>I&#x27;ve done the same for far too many projects, both existing and green field, and always ran into the same issues:<p>- manual sync (even if reporting is scripted) of every detail, info always ends up stale and often causes more issues from someone inevitably following it as a reference.<p>- additional overhead and maintenance, tied closely to the point above.<p>- stale &#x2F; unaccessible links (file server accounts, etc...)<p>- change history and supporting multiple versions &#x2F; environments in parallel<p>I&#x27;ve come to the personal conclusion that it&#x27;s easier and faster to bite the bullet and spend the time on your build and deployment steps, with the points you listed in mind.<p>With a Jenkins server, you could create a project that simply watches your current build directory and creates a new Build with its own Version Number, and a single archive as a Build Artifact containing your changes, including the current versions of your config files, required packages, setup scripts, and possibly a current snapshot of any relevant documentation.<p>This gives you visibility of exactly what was contained and possibly run (if your setup&#x2F;update is scripted) for each deployment &#x2F; update you perform.<p>You can build on this over time until it contains all the info you require about a particular snapshot of your stack.<p>Next, you can build a list of your servers (and environments) and track which Build from Jenkins you&#x27;ve installed to each.<p>(I believe Jenkins has plugins for that, but could be tracked elsewhere)