<story><title>Cockpit: Web-based graphical interface for servers</title><url>https://cockpit-project.org/</url></story><parent_chain><item><author>jameshart</author><text>People who decry graphical admin interfaces in favor of command line are missing the wood for the trees.&lt;p&gt;Sure, clickops is no way to run a server - but neither, if we’re honest, is ssh.&lt;p&gt;For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. If you’re going in with ssh or cockpit you’re just going to screw something up.&lt;p&gt;So the only reason you should be working on a server directly is because you’re doing something exploratory. And in that case gui vs command line isn’t as clearcut as people want to make it. GUIs emphasize discoverability and visibility which can be helpful in that experimental phase when you’re trying to figure out how to get something set up right.</text></item></parent_chain><comment><author>tremon</author><text>&lt;i&gt;clickops is no way to run a server&lt;/i&gt;&lt;p&gt;&lt;i&gt;server state should be reproducible from scratch&lt;/i&gt;&lt;p&gt;Why? I&amp;#x27;m not necessarily disagreeing, but too often are these kinds of statements thrown about without any qualification, as if they are self-evident truths. But they&amp;#x27;re not -- there are engineering trade-offs behind any choice, and it&amp;#x27;s no different here. So, in order to guide this discussion away from dogmatic platitudes: why should server state be reproducible from scratch? What does &amp;quot;from scratch&amp;quot; mean? Why is clickops no way to run a server?&lt;p&gt;&lt;i&gt;Install an OS, add software, apply configuration&lt;/i&gt;&lt;p&gt;Do you think this captures &amp;quot;server state&amp;quot; completely? Software patch levels are not part of server state? What about application data? User data?&lt;p&gt;So here&amp;#x27;s my counterstatement: for any working machine, I can reproduce the server state exactly by performing a restore from backup. Backup&amp;#x2F;restore is perfectly compatible with clickops, and it&amp;#x27;s faster and more reliable than reinstalling an OS, adding software and applying configuration -- even when the software and configuration are scripted. And if your server stores non-volatile data, as is often the case in clickops environments, you will need to have a backup system anyway to restore the user data after deploying a new server.</text></comment>
<story><title>Cockpit: Web-based graphical interface for servers</title><url>https://cockpit-project.org/</url></story><parent_chain><item><author>jameshart</author><text>People who decry graphical admin interfaces in favor of command line are missing the wood for the trees.&lt;p&gt;Sure, clickops is no way to run a server - but neither, if we’re honest, is ssh.&lt;p&gt;For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. If you’re going in with ssh or cockpit you’re just going to screw something up.&lt;p&gt;So the only reason you should be working on a server directly is because you’re doing something exploratory. And in that case gui vs command line isn’t as clearcut as people want to make it. GUIs emphasize discoverability and visibility which can be helpful in that experimental phase when you’re trying to figure out how to get something set up right.</text></item></parent_chain><comment><author>HankB99</author><text>&amp;gt; For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone.&lt;p&gt;I&amp;#x27;m curious if you have a specific tool or tools in mind. I&amp;#x27;ve been using Ansible in my home lab, particularly for configuring Raspberry Pis. The OS install part (only?) works because it involves a bitwise copy of the image to the boot media (and some optional configuration.)</text></comment>