Do folks managing servers mainly do so via command-line interfaces?
Or is that more of a stereotype, and there are some (maybe more?) out there using some form of graphical interfaces/web dashboards/etc.?
It’s struck me as interesting how when you look up info about managing servers that they primarily go through command-line interfaces/terminals/etc. It’s made me wonder how much of that’s preference and how much of it’s an absence of graphical interfaces.
I’m a mix of each. If i can do it faster via a gui then i do the gui. if it’s faster via command line then i use that. Those hardcore command line guys can enjoy typing 20 commands in which 4 button clicks can achieve the same thing 🤷
Yeah but usually those 4 buttons are running 20 command lines in the background so it takes just as long; may as well customize any of the commands to your liking while you’re taking the same amount of time.
I think you kind of missed the forest for the trees here. Those 20 command lines that run in the background will take the same amount of time to complete each task as manually entering them, sure. But the benefit is that you take less time to overall because I don't care how fast you are with typing, you still have to enter 20 commands instead of just the 4 buttons.
The main reason why I prefer to take the time to write the commands is so I can save a note of what commands I ran to get it working. Being able to say tthese are the commands" is much easier when I'm either helping someone repeat my work or auditing to figure out what I broke
If its an operation that is done even semi-regularly then an admin will have a script for it, and possibly even an alias. Scripts take a couple minutes to write (perhaps a bit more for nice error handling/warn). What takes loading up the interface and clicking four buttons in a gui equates to ' ./doTheThing.sh ', on a cli; for more regular things you might even have it aliased so it could look like ' $> doTheThing \n are you sure you want to do this thing? \n y '.
Hell, I've written scripts that just hook gui elements for things that essentially can't be done from a remote cli without sessions. Essentially using the GUI without having to keep it loaded in a browser.
I support a large number of windows servers, and the answer is it largely depends on what i’m doing, like if i’m doing a file restore i find navigating folder structures a pain in the ass from a CLI, so i’ll just use GUI.
If i’m doing something a bit more complicated like running AD reports, easier to just use powershell.
Yes I personally find it much quicker running a few commands via SSH and editing Docker compose files in a text editor than clicking around in some kind of web interface. It’s also much easier asking for help or helping someone else I you can just send commands to execute instead of explaining different menus and buttons they need to go into.
Personally, it’s the power of powershell that I use for the hundreds of windows servers. Otherwise it’s the power of Linux bash shell scripts for the dozens of Linux servers. None of the Linux servers run a gui so there’s no options there. Tbh for me, self documenting gui is the slowest way to do work. Configuring hundreds at once with peer reviewed scripts and change control is much more effective since the peer review and change control will be needed either way.
Oh though I use fortimanager a lot of configuring dozens of Fortigates. Only have a few scripts on it though.
You can’t really do configuration management with a GUI. Or version control. Everything I do I manage with Ansible as much as possible. YAML is self-documenting as well. How much effort is ‘run command with parameter’ documentation vs explaining how to navigate a GUI?
How much effort is ‘run command with parameter’ documentation […]
Tbh it’s less so the effort and moreso, how understandable is the documentation? A good GUI has the benefit of visual design explaining without words what may take a lot of documentation that may or may not be easily understood depending on the writer, which in many technical situations is someone deep in the jargon that has forgotten the way back to more accessible language.
Once you’re familiar with the commands, no doubt as many others have said it’s more efficient (especially once you’re knowledgeable enough to write scripts for frequent sets of commands), but there is a learning curve at play as one muddles through documentation in a similar way to an unfamiliar GUI.
No, any documentation >>> GUI. GUI relies on your previous experience with similar environments. Just jump into a GUI of Visual Studio (not code) project configuration and see for yourself.
If you understand that the terminal is better in the long run then you answered your own question, most people who fiddle with servers do so for a long time so the time investment is worth it. A similar analogy is learning knife skills, if you just cook for yourself being able to chop an onion in seconds saves you a minute a day from the one onion you used, not really worth outside being a neat party trick. But if you work in a kitchen that’s mandatory, chopping an onion in seconds means you save an hour for the 60 onions you chop in preparation for the service. Same idea for GUIs/terminal, it has a higher learning curve but if you try to avoid the curve you’ll never be able to do it fast, so the time investment is worth it if you’re going to be doing this daily (like most server admins do)
Same idea for GUIs/terminal, it has a higher learning curve but if you try to avoid the curve you’ll never be able to do it fast, so the time investment is worth it if you’re going to be doing this daily (like most server admins do)
Yeah, part of the thinking behind this question was with those doing this more as a hobby in mind (e.g. self-hosters) where it’s sort of a limbo. You may be doing it daily as part of your hobby, but also never on the level that really demands the degree of proficiency or efficiency you describe as you’re not going to be casually handling a large network of servers (probably), so on one hand learning the CLI may simply be part of the fun, but on the other, it may also lean into overkill depending on what you’re aiming to do.
I think it’s still worth learning it as a hobbitst, same thing as the knife skills for someone who likes to cook, you don’t need to be super proficient with a knife, but the basics of knife skills will up your cooking by a lot, at some point you’ll reach diminishing returns and you’ll stop learning, but the basic is almost essential. Same thing for CLI, you don’t need to become a master in the command line, but being comfortable around it will help you a lot. In other words, trying to run a server without CLI is like trying to cook without a knife, is it possible? Depending on what you’re trying to do yes but in general you’re shooting yourself in the foot, just because a blender can replace a knife in some instances doesn’t mean you can use it for all of the same things you would use a knife, a GUI is the blender of servers, it makes some things easier but is not as versatile.
GUIs are very limiting. You’re only able to do what the designer wants you to be able to. By using the terminal it’s much simpler to do more complicated tasks (once you’ve gotten past the learning curve).
Also since so many servers are headless (no display outputs) they’ll be remotely logged into, meaning there’s only a terminal to interface with the machine.
This can be true. Part of the reason I ask is that as more data is visual in nature, it seems like it might make it more difficult to manage strictly via CLI, especially since metadata is likely to be lacking in description and even with a descriptive filename and details, it’s a picture/video for a reason.
I’m sure there are existing arrangements to handle that though, like web GUIs for any visual media review as needed.
Can you give me an example? Sure graphs are quick to spot spikes and such, but outside a webui like you mentioned servers also usually have warning triggers, you know what’s better than staring at a graph looking for a spike? Getting paged once a spike happens with information on possible causes and the state of the server. That’s very difficult to setup using GUIs, but almost trivial to do if your okay with CLIs.
It’s more on the hobbyist end of things, but as an example I was thinking like if you had a server you’re using to back up or store photos on, trying to parse it strictly via CLI doesn’t seem like it’d be terribly useful.
You’d also want to view the images directly, I’d think, but I’m guessing in that situation you’d just use whatever web UI the software you’re using might provide.
I have a server I use among other things to backup my photos, I don’t understand what you mean by “parse”, but I administer my photos through my file explorer as if they were on my computer, because I configured the server to expose a samba share on the folder that I have the pictures.
You got the gist enough despite the term I used & answered what I was wondering about (as did the other person replying), so I appreciate it! Parse was just another way of trying to say see the file in full, filename, additional metadata, & content. With visual media I’d think you’d have to do like you (& they) said, configure it to be opened via something else for a comprehensive review.
I tend to work with visual media more, so for me a CLI feels like more of a backwards approach to navigation & data management.
Yeah, makes sense, however to setup good structure for being able to do that you’ll need CLI, e.g. if you want programs that administer photos and allow you to create albums and set tags, I personally don’t need that level of organisation, but if this is your main use you might want to invest the time to setup something like Lychee or piwigo, which are easily setup through docker (which if you’re into self hosting you should learn).
Viewing the images directly sounds to me like a different context. Browsing the images is more akin to end user activity, i.e. using the server for its intended purpose. Managing the server is more like making sure it’s running, that there is enough space allocated, security holes are plugged, software is up-to-date, etc. Administrative tasks. When wearing the admin hat, there wouldn’t usually be much of a need to actually look at the photos - you’d be more concerned with file names and metadata, not contents. In that context, the GUI becomes less important. And if you ever do need to see them, you can always fire up the GUI software for that occasional situation.
I’m running Debian on my home server and I do a lot via SSH from my desktop. I used to host a Minecraft server back when it was alpha so I learned a lot about cli. I do have xfce setup in case of an “Oh shit” moment though because I tend to do stupid shit.
You can accomplish a lot through scripting - light programming. Anything you can type into a command line can also be executed by a script. This is the power of them. So when managing large arrays of resources, the potential for automation and scaling effort is big.
I don’t think all of that can be replaced with GUIs. When you consider that sysadmins are working with tons of different software from many different providers and trying to make it all work together, the command line interface is really the common language they all share - even the bulllshit legacy products that are still hanging around after 15 years of being outdated. You’d need extremely sophisticated GUI tools to be able to do everything, across all these products, at scale.
There are of course GUI tools for specific tasks, but the command line is the foundational tool.
Disclaimer: I know fuck all about Microsoft things. Only have some experienc with *nix
My personal servers are a mix of the two. I have a Synology NAS that I manage through a web-based GUI. Sometimes I’ll dip into command line via SSH, but not very often.
I have two more lower-power Linux servers that I manage through command-line primarily. They don’t have many system resources, so I want them to have as much available as possible to serve things.
Windows servers I use GUI management most of the time
As others mentioned, it depends on the details. But anything routine should be done with CLI or code, because then it can be scripted/automated. The time savings for that adds up surprisingly quickly, especially when you consider the human errors that are avoided.
What? no. Automation automation automation. Have your ansible, chef, or puppet ready. Where possible, have your terraform or equiv. ready. Python and bash scripts. Only use web portals where no automation solution exists.
Depends on what I’m doing with it. I usually don’t really need to do anything particularly specific or complicated, so running everything off of a command line works for me. It’s more lightweight, and is less fiddly than having to set up a graphical remote desktop.
If it’s something more complicated, or more difficult to automate, then not using the command line would make more sense.
Depends on the kind of server - Linux, yes, command line all the way. Windows (and Active Directory and other Microsoft stuff) you use GUI mostly in combination with some PowerShell scripts (often running on the “command line”).
Add comment