everything is a web app and i want to die

[-]

Key_Way_2537@reddit

Man i was on board until you mentioned vSphere client. That was gone like a decade ago. Same for iDRAC. You’re a decade out of touch it seems.

You also lost me at ‘server is fine, uptime is 400 days’. Patching and security updates would like a word with you.

[-]

tose123@reddit (OP)

400-day uptime means no patches? My kernels are patched. kexec exists.

[-]

GroteGlon@reddit

So you're running an old-ass kernel with a load of live patches... great. And what about your drivers and subsystems?

So, right answer, wrong formula?

I'm getting tons of reasons on why rebooting is a good idea, and pretty much no reasons other than "rah you don't have to, dumb windows admin >:(" to not reboot.

[-]

djfdhigkgfIaruflg@reddit

Rebooting every day or after every update won't benefit you much.

But a weekly reboot will help you immensely

[-]

GroteGlon@reddit

I'd say bi-weekly or monthly?

[-]

djfdhigkgfIaruflg@reddit

Whatever

[-]

GroteGlon@reddit

... useful answer...

[-]

djfdhigkgfIaruflg@reddit

*Whatever float your boat

Not everything is people attacking you

[-]

ka-splam@reddit

Uptime is dick-waving for nerds.

Part of the history is with the 1950s and 1960s computers, writing code for them and making it work without bugs and without crashing, was surprisingly hard. Whole lots of research into programming languages and programming methods tried to make better quality software. Otherwise, you spend ages writing a program on punched cards, feed it into a computer, let it run overnight, and in the morning you find it crashed and you have to start again.

Part is Unix - which ran on massive expensive mainframes - was multi-user with lots of terminals connected to one core, and it was designed with programs in separate processes so one could crash without taking the whole system down. It also couldn't do much - there was no MP3 playing or video or whatever.

Part is that the 1980s and 1990s of consumer hardware - Atari, Amiga, early Macintosh, IBM PC - was much cheaper, slower, less capable. These and MS DOS and Windows 3.1 weren't like Unix, they did co-operative multitasking where the OS handed over control of the hardware to the program which was running. If any of it went wrong, the whole thing crashed.

Windows 95 and 98 and ME were like that too, only they were getting used on all kinds of random sound cards, video controllers, CD ROM drives, gaming, 3dFX cards, desktop publishing software, printers, with all kinds of drivers and quality of code from random companies around the world. Cheap hardware, cheap software, lots of users, lots of combinations, they were very crashy.

Unixes were also used on things like SGI Workstations, expensive, controlled hardware environments.

Linux copied the Unix design and isolated things into separate processes. It generally didn't crash. And few people were using it, and they were doing less with it because it didn't have the drivers or as much software to do fancy things.

Linux users latched onto this as one of the few things which was unarguably better than Windows, most other things being matters of taste or cost or effort, and it became Proof Of Engineering Superiority and therefore Proof Of User Superiority.

Rebooting took time. It wasn't as fast as today, especially on bigger machines it could be many minutes from usable to usable.

Windows NT, 2000, 2003, and XP, 7, 8, had the isolated processes design, Microsoft started Windows Hardware Quality Labs testing, "Designed for Windows" labels, for more reliable suppliers to earn, and the uptime wars moved from "My system can run without crashing" to "My system can run without M$ FORCING me to reboot".

However, Microsoft got a lot of flack for early Windows having no firewall, being easily rooted when exposed to the internet, and then joining botnets and making everyone else's lives worse. MS took responsibility for pushing patches to hundreds of millions of Windows machines every month and that made the internet safer for ordinary people and somewhat less busy with attacks for everyone else - but it means rebooting. Everyone says they don't want to be forced to reboot, but people just don't do it otherwise, so it's the least worst option overall.

It is a good idea to reboot for patching because if you patch a shared library, you can get one version loaded in memory from before a patch, and then a new version loaded in memory after a patch, and the two copies of a program could be running slightly different versions but trying to work with each other. The easiest way to restart everything is a reboot, and on a VM or modern hardware that only takes a few seconds.

Computers have a ton of state - 1GB of RAM can be in a lot of different states - and the state that's tested most intensely by most people is the "just after a reboot" state. The state of "I loaded this program, then that program, then poked this driver, then did 100 days of other random things which changed hardware and driver state and interactions, then patched these files, then did days of other things, then patched these things, now exactly how well is everything working?" is vanishingly unlikely to be a state anyone else has ever been in, let alone one that manufacturers have tested carefully. The easiest way to get into a likely-good state is rebooting. Joe Armstrong, "The Mess We're In" is a good talk around this idea. ("I started OpenOffice and I got a little prompt 'there's a new version of OpenOffice' and I thought 'oh good, that'll be better'" audience laughs.)

Still though, if you are a company with millions of dollars a minute going through a server, or running air traffic control with no backup and no failover, it is probably worth paying an admin to hand-patch one thing at a time, sign off on some audit and compliance forms, restart one service, run tests, sign off on more forms, and keep uptime high and unnecesary changes and reboots low.

Otherwise, why even are people caring? Run servers like cattle not pets, have them automated, run things in containers, design with high availability, servers should be able to reboot without anyone even noticing. Let alone "rah you don't have to, dumb windows admin", why would you spend any time or effort setting up something to not-reboot unless you absolutely had to for life and death business reasons?

[-]

FarmboyJustice@reddit

Overall I heartily agree, but I'm getting tired of this whole pets vs cattle analogy. It's useful for explaining things to non-technical people in an overly simplistic way, but it's not really an accurate description of the difference.

It's based on the assumption that there's no middle ground, and you're either buying expensive food for Pookie the Pomeranian or you're sending dairy cow #7498 to be slaughtered, when in reality there's a huge range in between.

[-]

ka-splam@reddit

What's an example of middle ground?

I think of it as whether the scale of a thing is linked to the number of employees, or it isn't. If there is any task where people have to work on each server by hand, then more servers requires more employees. Double the server count, double the employee effort required and the cost of employee time spent. With everything automated, the same number of employees can deal with 2x, 10x, 50x the servers. Either the employee effort required is independent of the number of servers, or it isn't, I don't see much room for middle ground there.

Google tells me that Facebook had 30,000 servers in 2009 and 60,000 in June 2010. There's no way they had people looking up free IP addresses in a spreadsheet, sending hand IPMI commands, then logging on by SSH, configuring Apache by hand following a checklist. Google is estimated to have 2.5 million servers in 2025, what would a middle ground be at that scale - partial automation would be as useless as no automation?

I'm guessing most of us, most companies, most employees, are not near the scale where 'cattle' is absolutely needed, but the thinking of a farm of easy to wipe and redeploy laptops or remote desktop sessions is common.

[-]

FarmboyJustice@reddit

You're assuming that it's either all manual or all automation, but really automation exists at every scale.

The pets versus cattle analogy creates a dividing line between a big rancher with a million head of cattle and Aunt Edna with her household pets with names like Mr. Whiskers and Pooksie that she feeds expensive catfood to and posts pictures of.

Using the actual cattle analogy, you've got huge corporate farms and ranches where each animal has an RFID tag and QR code, they're dosed with antibiotics in bulk to prevent diseases before they happen, they're fed by robots, and they are constantly monitored for health, weight, etc. Then you've got Aunt Edna's cats.

In reality you have a whole lot of people with smaller herds of cattle who can't afford robots and GPS monitoring of every animal, but still need to take care of their cows.

Businesses generally don't keep pets. Businesses that do have animals usually have working animals. A barnyard cat catching rats. A sheepdog herding the sheep. A horse that pulls a plow. And so forth. These are not "pets" but they are also not "cattle."

This is why I hate the pets vs cattle analogy, because it's overly simplistic and generally gets trotted out by people who want to dismiss anything other than full-blown IAC for even the most simple of purposes.

There is no actual clear line between these two scenarios. Instead there is actually a continuum, and most businesses (statistically speaking almost all businesses) are towards the lower end of that continuum. Most businesses don't have cattle, they've got a few cows, some chickens, and maybe a goat or two.

[-]

ka-splam@reddit

You seem to be saying that most businesses have pets not cattle? Which I agree with, but isn't an example of a middle ground.

In this analogy, the sheepdog and the horse are treated like pets - the sheepdog lies by the fire in the farmhouse at night, the farmer would miss walking the fields with the sheepdog if it died; if it was ill the farmer would call the vet and spend what they could to help it. The horse gets brushed and the stable cleaned by a farmhand who pats it and feeds it a sugarlump and recognises when it's tired or stressed out, and would miss it. If you have servers which you tend by name, they're not cattle - and that's not to say they should be cattle.

[-]

FarmboyJustice@reddit

Again you're making that arbitrary hard-line divide between pets and cattle, ignoring the middle ground.

My point is the pets vs cattle analogy is a poor analogy because it creates this arbitrary dividing line between factory farmed cattle and household pets, ignoring the huge range of intermediate farming in between.

Horses and working dogs on a small farm are NOT treated like pets. They must earn their keep, and they can be terminated for failing to perform. Humans may be kind to them, but being kind to animals is not a weakness to be looked down on, it's a sign that you're not a psychopath. (Seriously, cruelty to animals is one of the childhood indications of psychopathy.)

Cattle are a commodity sold for profit.

Another way the pets vs cattle analogy fails, btw. Cattle are a commodity that is grown and sold for profit, virtual machines are not. If you're terminating and restarting your cattle all the time, you're a failure as a rancher.)

Horses get brushed because you damn well brush your horses, it's an obligation of owning them, not because you're such a kind and loving pet owner. Working dogs like sheepdogs and hunting hounds don't just sit around the fire, they work hard, and ones that don't perform well are generally sold or sometimes just shot. And if you think factory farms don't provide veterinary care to livestock, then that's just one more example of why the pets vs cattle analogy fails. They do. And not because they love each individual animal, but because they are legally and ethically obligated to, and because it doesn't make sense not to.

The biggest problem with the pets vs cattle analogy is the fact that it assumes cattle are disposable assets. They're not. Each individual animal is an investment with a cash value, and in order to achieve return on that investment they must be treated with a certain minimum level of care. The fact that that care is delivered in a more automated way doesn't mean there's no care.

Finally, with regard to naming things. If you call your server BDS821092-HDZ_3123 and I call mine FRED, there's really no difference. Excel doesn't care which value shows up in a cell. Software doesn't care. They're both names. As long as they're unique and serve their purpose, what purpose is served by denigrating someone for not using GUIDs to name their handful of local devices?

If some small company wants to name their servers after rock bands or constellations or whatever, get over it. It doesn't mean they are feeding sugar cubes to their servers and it doesn't mean they're not doing useful productive work that contributes to the economy.

[-]

ka-splam@reddit

The distinction is hard-line but not arbitrary. You've argued that it's unfair to call working horses pets because they do work, but you haven't shown that individually brushing a working horse is meaningfully different from individually brushing a pet horse and so it deserves a separate category of "middle ground".

You've argued that a herd of cows get antibiotics in their feed and therefore they are getting "veterinary care" and therefore they are not "cattle" but you haven't shown why that addition of "care" deserves a separate middle ground category separate from "cattle".

If you call your server BDS821092-HDZ_3123 and I call mine FRED, there's really no difference.

The difference is not in the name, it's in what the name says about the scale. A small team with 800 servers to manage are not going to bother calling one of them FRED, they will call it site1-rack8-web14. A team who hears that FRED has failed and half their customer orders are failing needs to fix it now. A team who hears that site1-rack8-web14 has failed can mark it so the next person working in that rack can swap the hardware in a week or two and meanwhile their webserving capacity is down ~5% and the other servers will handle it.

There's "we care about it individually" and "we don't care about it individually". Where's room for a middle ground and what does it look like?

what purpose is served by denigrating someone for not using GUIDs to name their handful of local devices?

It's evidence that the someone is managing pets, not cattle, and that's not denigratory.

The fact that that care is delivered in a more automated way doesn't mean there's no care.

The more automated way is the point of the distinction. If the small farm's horse has a limp, the farmer calls the blacksmith to look at the horse's shoe. With the herd of cattle the corporate owner adds antibiotics to the feed whether they need it or not and if one cow is limping, the cow limps the next few months until the abbotoir because that's more profitable than getting a vet to treat it. There's "we care about it individually" and "we don't care about it individually". Where's room for a middle ground and what does it look like?

The analogy (pets) vs (cattle) was popularised by Jeffrey Snover, creator of PowerShell and not a farmer, to talk to Windows Click-Admins who RDP into individual servers to make changes, and to suggest a way of thinking where it makes sense to Invoke-Command -ComputerName $allMyWebServers -ScriptBlock { MyChanges } all at once. There's "running IISCrypto GUI on each webserver" and "changing all our webservers at once". Where's room for a middle ground and what does it look like?

it assumes cattle are disposable assets. They're not. Each individual animal is an investment with a cash value

New Zealand government and farming sector leaders agree to kill 126,000 cows. Cows are culled in bulk to stem the spread of disease all the time, in the way working sheepdogs and plough horses and pets just aren't.

[-]

FarmboyJustice@reddit

Jesus Christ you are incapable of any sort of nuance.

This is exactly the same reason why only making a backup is wrong. You must do regular restores to verify the backup and hardware integrity

[-]

spacelama@reddit

Of course, to extend the "premise is flawed" premise - such problems in restart are irrelevant in a modern CI/CD controlled IaC environment - such failures would have been picked up in dev/test.

So now you can have 2 year uptimes if you've got an environment with no bugs nor security flaws!

(people who say "blah needs to be rebooted monthly for " (fix the frickin memory leaks then!) equally annoy me to "we can't patch anything, because it works now!". I've usually worked with both types at the same time)

[-]

FarmboyJustice@reddit

When we pointed out we had it first, they literally said flat-out that it didn't matter, because they would just drag it out for years and cost us millions in legal fees if we didn't give it up. It wasn't even subtle, they just came right out and said they would ruin us.

I think they meant that being angry about iDRAC being a thing instead of patching in physically is 'gone a decade ago'.

iDRAC is very much not 'gone' in any other sense of the word. Lol.

[-]

lexbuck@reddit

Ah gotcha. I got worried I was becoming and old head using something that went out of style a decade ago 😂

[-]

viral-architect@reddit

iDRAC is still a thing. Physical servers still need lights-out management cards. RMM / IMM / ILO / IDRAC -whatever the vendor calls it.

https://www.dell.com/en-us/lp/dt/open-manage-idrac

vSphere is still a thing for the big boys that have the money to pay the ransom that Broadcom charges now.

Last update was 8/28/2025 (3 days ago)

tose123@reddit (OP)

No, I didn't read it, not to be impolite, I just have no time to read so much text outside of my garbage code I have to write.

There are two aspects of IaC, one is deployment, the other being maintenance. Seems where OP works they don’t have the maintenance side working optimally. SSH/RDP are still needed to debug and fix issues that occur. You can do RBC with SSH/RDP you just need to setup appropriate system security levels and have some type of Privileged Access Management system in place, preferably tied in to a change management system, so roles can be granted based on changes/fixes/diagnostics that need to occur.

Karen from compliance says we need "audit trails" and "role-based access control."

I get the need for it, but I fucking hate RBAC. Being as sysadmin and having to request permission for the rights to do an integral part of my job feels like being an adult and having to ask for permission to go take a piss.

[-]

maaz@reddit

you missed the zero-trust train. real admins dont need sudo to do their job but a well defined privilege escalation path. its the concept of sudo, you dont always need root, but if you do you have to consciously add a sudo, enter your password, and be auditable.

[-]

rsysadminthrowaway@reddit

I'm not even talking about sudo, I mean, I have to do shit in Intune, but first gotta go log in and ask for the permissions to do shit in Intune every few days. Now I need a machine's LAPS password, now I gotta log back in and ask for the permissions to view LAPS passwords. It just grates on me. They already make me use a completely separate account with a password length requirement twice as long as that of my normal user account. Where does it fucking end?

[-]

agent-squirrel@reddit

It doesn’t help that things like PIM suck so much. A solid minute to activate a role is ridiculous.

[-]

ansibleloop@reddit

Oh it can be worse than that

Want to activate Exchange admin? Cool! You'll have your permissions somewhere in the next 4 hours

TeamDman@reddit

I made a cli for Azure that can activate pim stuff, makes it slightly less annoying than having to open the portal every time.

[-]

RobZilla10001@reddit

This. RBAC isn't a bad idea, but it's implemented so poorly, especially by Microsoft.

[-]

Reetpeteet@reddit

but I fucking hate RBAC. Being a sysadmin and having to request permission for the rights to do an integral part of my job

That's not RBAC, that's PAM: privileged access management.

RBAC is about defining roles which people in your org perform and grouping authorizations and permissions in those roles. Prevents you from having to dole out hundreds of authorizations on a personal, individual level.

[-]

SpecificDebate9108@reddit

I’m struggling accepting the risk associated with intune + autopilot + azure join. We are fully locked in now, in my head when something isn’t working my pragmatic side says, this isn’t your fault, but I go to work feeling quite anxious constantly.

[-]

ZantetsukenX@reddit

"But it's user-friendly!" For whom? Users who shouldn't have access to servers? If you need a GUI to manage a server, you shouldn't be managing servers.

Reminds me of when Windows 8? (Maybe 10?) came out with a bunch of settings missing from the control panel and they were like "Look, the average user doesn't need these things. It's built with them in mind, not the power user." And then the newest version of Windows Server came out and had all the same missing settings and more. Like if Windows Server isn't for power users, then it's basically for no one. So clearly the initial response was pure bullshit.

[-]

Aerwidh@reddit

Getting flashbacks to them removing the ability to edit saved Wifi network profiles from the control panel in Windows 8 so you could only edit said profiles if you were in range of the network and could right-click it from the list of currently available networks.

Then, in 8.1, they removed even that functionality. For example, if a student needed to access eduroam at a college/university but had an incorrect config on their personal laptop you could no longer show them how to change the eduroam network profile settings but instead they had to run some command in cmd to remove the correct profile entirely and then start from scratch and hope they got every setting correct this time.

So much time wasted before Windows 10 came along and finally had the functionality implemented in the Settings app.

[-]

goingslowfast@reddit

I’m also an old hat, but I don’t want to slide backwards on any of these. You know what sucked more? Carrying around a bundle of vendor specific serial cables, Windows only thick clients, crash carts, driving to data centers and remote sites, and managing VPN tunnels and/or MPLS for simple management and monitoring.

Look into IaC, APIs, automation. These all massively reduce the need to connect to a single box.

vCenter, iDRAC, iLO, and IPMI are all the best they’ve ever been. Especially if you pair them with your vendors enterprise management tools.

Your web based terminal emulator is likely connecting via a far more secure and easily deployed option than what we did in the past with just port forwarding ssh with a firewall whitelist.

And MFA? Do it better. It’s a necessary security precaution from both a real risk and a compliance perspective.

The fact you brag that the server is up for 400 days makes me really question the health of your environment and SMS being the MFA factor is another red flag.

[-]

LoveCyberSecs@reddit

I feel like there should easily be a middle ground where you can peak under the hood but you don't need to be super inconvenienced for doing so.

[-]

What is the worst: old Java clients and Java applets or maybe even ActiveX to manage some server system.

[-]

heapsp@reddit

The reason you completely missed the point on this one is because you have never worked in a larger company before.

Wait til a SOC audit comes along and wants to know a full inventory of your stuff in every cloud and you have 160 subscriptions and 8 aws orgs and a vmware environment...

You need these solutions or you'd have an entire engineering department to respond to 1 soc control.

You need ONE PANE OF GLASS, COMPLIANT, MULTICLOUD SOLUTIONS THAT ARE CONSISENTENT REGARDLESS OF TECH.

Example, yeah you use SSH great. Now how are you logging into windows? RDP? Oh then you need network line of site, just VPN all of these environments together right? Open your IP to the server so you can RDP? NO

A solution like beyondtrust or another solution to allow all servers linux / windows under one pane of glass with an audit trail to allow you to get into every one of these servers is the only option.

Oh you want to run a simple script to set up a server in azure through azure shell?

NO, because then its not the same process as AWS so you have three different deployment scenarios with inconsistency between each, thats why they are requiring terraform.

You start to think about things differently at scale once you mature.

[-]

tose123@reddit (OP)

160 subscriptions and 8 AWS orgs? That's not scale. That's poor architecture.

You know what we had before "multi-cloud"? One datacenter that worked. You've created complexity by spreading across providers, then need tools to manage the complexity you created.

SOC audit wants inventory?

for dc in $(cat datacenters.txt); do
  ssh $dc "hostname; dpkg -l" >> inventory.txt
done

There's your inventory. In a text file. Searchable. Grepable. Done.

"ONE PANE OF GLASS" - every vendor promises this. You end up with 17 panes of glass, none showing what you need. BeyondTrust is just SSH/RDP with a web UI and a $500k license.

Windows? I don't run Windows servers since 1998 IIRC. That's your first mistake. But if forced: WinRM exists. PowerShell remoting exists. Same patterns, different syntax.

"Different deployment scenarios" - no, it's all just API calls. AWS, Azure, GCP - they all create VMs the same way: POST request with parameters. Your Terraform just abstracts this into HCL that nobody understands.

"You start to think differently at scale" - I've run actual scale. One system, 10,000 nodes, same image, same config. Not 160 different subscriptions because nobody knows what's running where.

Your "maturity" is complexity. Real maturity is simplicity.

But keep paying for "compliance solutions" that are just SSH with audit logs. I'll keep using script and rsyslog. Same result, $500k cheaper.

[-]

heapsp@reddit

This isnt realistic at all. Nowadays companies are tens of acquisitions and different architectures and you almost never have networking line of site to ssh into every server in your environment from one, or even ten, or maybe even hundreds of different isolated networks.

[-]

mro21@reddit

If your magic GUI's backend is allowed to do it, then so can OP from a terminal.

[-]

heapsp@reddit

Its not true at all, but this is probably why no one here gets promoted beyond sysadmin to engineers or leaders in the industry and complain every so often that their job is going no-where or was outsourced.

Super smart people 10 years ago who die on a hill with their 'knowledge' but don't realize their industry of flat networks with thousands of VMs is dead for a reason.

[-]

mro21@reddit

You don't even get the point.

If you can connect with your "orchestration" tools to the "isolated" networks then so can OP using his tools.

Feel free to let us know what you do not understand.

[-]

heapsp@reddit

Nope you still don't get it.

Some tools like visibility tools for vuln remediation or misconfiguration checks for example use the cloud and RBAC. They don't touch the resources themselves at all. They look at the disks through the cloud platforms or vmware as an example. This is how you can get a full inventory of every vulnerability or misconfiguration in an environment with thousands of resources under one pane of glass without any need for configurations. This is accomplished in like 15 minutes with just an app registration in azure and RBAC.

So, where now you have a security team deploying vulnerability scanning VMs and networking them, and missing because of credentials or network line of sight, you have 100% coverage and now can check that box for auditors.

You simply don't understand the benefit.

[-]

mro21@reddit

Oh so you just have a big flat network hovering above everything else with lots of tools leveraging it and somehow try to make sense of all the blocks (of storage). Nice, that must be very secure.

And in the other case you have "outbound" (lacks definition) connections, from prod to your management platforms I guess. Security however would dictate connections from high to low security zones only, i.e. from mgmt to prod and not the other way round.

[-]

heapsp@reddit

Oh so you just have a big flat network hovering above everything else with lots of tools leveraging it and somehow try to make sense of all the blocks (of storage). Nice, that must be very secure.

Huh? Elaborate? The more you dive into this discussion the less confident I am that I'm talking to someone with senior level knowledge. What big flat network hovering above everything else? Do you mean the microsoft or amazon cloud network backbones? Or are you misunderstanding how any of this works?

Outbound doesn't lack definition, It is your compute initiating a network connection to the outside of your network. I could use the term with juniors and they would understand it. You know, like your EDR / MDR solution does when it reaches back home? Do you also think crowdstrike or sentinelone are an issue? Or are you still using symantec endpoint protection manager servers on premise- lol.

[-]

mro21@reddit

"Backbone", huh? Read that someone when researching what a network is? I'm talking about management networks, IP adresses you know? You know you have to connect to some instance like the hypervisor to do what you are saying. But I'm sure that's well hidden away behind some shitty API.

Further, it would be no trouble at all for the management solution to connect to its clients, keep that connection persistent, and have the client report back ad-hoc over that connection, instead of allowing everyone to connect back to mgmt. But yeah who still comprehends these details.. Apparently not the people implementing or designing these solutions.

I'm sure the juniors "understand" it if understanding means repeating what they heard before and just believing (hoping) it makes sense.

Oh and finally for the stuff we still have on-prem I can at least show you the disks where it's stored and I know exactly what's happening to it. Nowadays the trend is just uploading it somewhere and wearing a nice suit sitting in some conference room while negotiating a contract. Oh, wait, they don't negotiate anything, you can just accept their terms or not, hahaha. And still, when the data is gone it's gone, bc no one knows what they're doing, you get reimbursed the monthly fee and that's it hahaha

[-]

heapsp@reddit

ChatGPT said:

When people talk about the cloud’s “backbone network”, they’re usually referring to the high-capacity, private global network infrastructure that cloud providers (like Microsoft, Amazon, Google, Oracle, etc.) operate to connect their data centers and regions together.

Today, according to social media, everything is always dead. X11 is dead, C is dead, flat networks are dead. Everything dead or dying. Yet half the internet runs on "dead" tech from the 90s.

You'd be surprised how much legacy shit is still running, will always run. This isn't due to incompetence of the Engineer/Sysadmin/DevOps-Cloud-Architect-or-whatever-trendy-title-is-today, but because it works.

[-]

No_Promotion451@reddit

You want to leave for the nether realm? Gotta log on to that SaaS web app to register your interest.

When Ansible runs, you know what actually happens? Python opens a socket. Calls connect(). The kernel handles the TCP handshake. Python calls fork(). The kernel creates a process. Python calls exec(). The kernel loads SSH. SSH calls write(). The kernel sends packets.

It's the kernel. It's always the kernel. Everything else is just userspace fluff deciding which syscalls to make.

My for loop? Makes the same syscalls. Directly. No Python interpreter. No YAML parser. No Jinja2 templates. Just:

fork()
exec()
connect()
write()
select()

But you don't know that because you've never read socket(2). You've never traced the syscalls. You just trust the magic.

[-]

Reetpeteet@reddit

You just trust the magic.

I trust a solution where I can define a desired outcome, without having to write the shell code for it myself and then make sure the shell code is compatible with every single variation of the OSes and versions that I may run in my data center.

Ansible: make sure that httpd starts at boot and is up and running.
Shell: if it's this Linux run these systemctl commands, if it's that linux run the OpenRC commands, if it's so-and-so ... you get the picture.

I don't want to maintain shell code, I want to maintain configuration and state.

[-]

mro21@reddit

What do you do if it doesn't do what you want on any of the variations of OSes you use? Why do you even need that many OSes? Is everyone managing a thousand servers with a hundred different OSes? My bet is only the most common OSes actually result in a reproducible result. And if it doesn't work who do you call?

[-]

Reetpeteet@reddit

What do you do if it doesn't do what you want on any of the variations of OSes you use?
... And if it doesn't work who do you call?

Then I submit a project proposal to my boss, asking if I can put in the time to help expand the functionality of the open source module(s) in question so it will be compatible. And if things are broken, I turn to open source community around that module, to get help in troubleshooting (if I can't fix it myself).

Why do you even need that many OSes? Is everyone managing a thousand servers with a hundred different OSes?

In the large corporate enterprises I've worked at, you will generally find two different distributions and two to three versions of either one throughout the whole DTAP environment. Less egregious than my initial example, but still.

My bet is only the most common OSes actually result in a reproducible result.

You're right, if BieberOS or Miley Cyrus Linux have decided to go a complete own way of doing things and they diverge wildly from their upstream distributions, not all of Ansible will properly work on there.

[-]

mro21@reddit

Uh, oh, you don't even buy support for it?

[-]

Mephistobachles@reddit

Translation: I never heard of POSIX portability and think shell means copy-pasting Bash from StackOverflow. Or “I know about only Bash without even knowing Bash”. Writing portable scripts solves the exact mess you whine about. “I dont want to” wouldnt pass in any human labor driven economy or civilization. Its also just is cop-out for “I dont know how”

[-]

Reetpeteet@reddit

With your tone, I hope you're never in front of a classroom or in charge of coaching junior colleagues.

I never heard of POSIX portability ... I know about only Bash without even knowing Bash

I will readily admit that my Bash knowledge is limited; I've never read the Bash manuals and docs cover-to-cover, but I certainly get by well enough.

But what you're saying just doesn't seem to apply to the example I gave.

How do "POSIX portability" and Bash help you, when the process to control a daemon varies per distribution? The commands to use are inherently different, which is what I was trying to illustrate.

[-]

Mephistobachles@reddit

You do it the same way its always been done, write portable POSIX shell that detects what its running on and branches accordingly. Daemon control differs per init system so you check for systemctl, check for rc.d, check for whatever, then run the proper command. One script, portable, predictable, zero YAML tetris. Thats what POSIX portability is. Most basic logic imaginable. Its really not quantum physics. What do you think Ansible and all shiny toys are wrapping? Again talking to daemon by magic? Whole industry has been detecting it for decades. configurescripts in C projects probe the system, figure out what libs or init system exist, and adapt. Half of GNU toolchain is basically a giant set of detection scripts written in plain shell. You struggle with this like its some kind of sorcery.

Also, you shouldnt put POSIX portability in quotes like I'm making it up, its a real standard, not fairy tale. The whole point is there are plenty of POSIX compliant shells that arent Bash at all. You admitted you never even learned Bash properly, so it all seems like some unsolved riddle.

Look, you cant have it both ways. First you said "I trust a solution where I can define a desired outcome without having to write shell code (or any equivalent) myself". So you are outsourcing understanding from the start, which means you are literally trusting magic and calling it "solution".

It doesnt matter if its RedHat, BlueHat, or YellowHat making it "not a black box". If you dont read or understand why it exists, what problems does it solve or not, then you are invoking authority. This is called faith. Ultimate trust is building your own tool or making contribution, or you are then just a user. If you dont know how, fine, but then dont pretend you transcend shell thus creating issues where there should be none.

I know the level of arguments or lack thereof that get dragged into this subject because I've seen it all. I once saw someone, when being questioned on similar subject, define shell as "well, shell is a shell". Thats where magical thinking is we're pointing to. You dont have to understand every line of 2 decade production OS codebase, but if you never read OS code at all, you are not qualified to criticize shell or spread misinformation about what it can or cannot do.

[-]

mro21@reddit

You won't convince them. It's all they have ever seen or known. Their entire life and career depends on hoping their "state" files do what they want. So they'll defend it to the end. With no possibility (or knowledge) to check or debug (outside of the box). Being completely dependent on someone else who actually implements the lower layers and is the actual genius.

Now before someone claims what I wrote before applies to me as well. Partly yes, because there is always a lower layer. But I would be able to learn an upper layer in no time. The inverse is not true: trusting solely in some high level automation is like Karen pushing buttons on her new shiny Android phone and complaining when it "doesn't work". Or working all your life in sales and then be good in tech. It just doesn't work that way.

[-]

Reetpeteet@reddit

You do it the same way its always been done, write portable POSIX shell that detects what its running on and branches accordingly. Daemon control differs per init system so you check for systemctl, check for rc.d, check for whatever, then run the proper command

Right, so you do exactly what I said is a downside for many and which Ansible sidesteps for us. I don't want to manage code, I want to manage configuration.

Your reaction to my earlier post suggested that I might be overlooking something important, but basically you're saying I was right in my initial assessment and that I just need to grin-and-bear-it.

Half of GNU toolchain is basically a giant set of detection scripts written in plain shell. You struggle with this like its some kind of sorcery.

I don't struggle with it, I've been using it for 20+ years and I teach Linux to students at school. But I also know that with many organisation they'll quote that ol' meme that goes "ain't nobody got time fo' that!".

[-]

Mephistobachles@reddit

You dont manually churn for 500 VMs, you write once, detect once, and it runs everywhere. If you know what you're doing, its far less hassle than Ansible weird ass abstractions

[-]

Reetpeteet@reddit

The daemons themselves dont "vary per distribution" in some chaotic way. What varies is init system interface

I know. That's why 24 hours ago I wrote the post clearly mentioning init vs Systemd vs OpenRC and others, in the post you first responded to 4h ago.

I didn't say the daemons differ, I was saying the init systems differ and I don't want to write convoluted case statements to deal with every one of them.

[-]

Mephistobachles@reddit

Jesus, we get it, you dont feel like doing it. Thats not technical argument, you're just whining and yapping. You literally asked how do POSIX portability and SH help when daemon control differs per distro, well thats the whole point of detection logic. Its not convoluted, just a case statement with few branches. One case statement, done. Stop circling back to "I don’t wanna".

[-]

Mephistobachles@reddit

So go, manage your configurations, but what I was calling you out on was that there is no downside you speak of, and those who did native configuration management without someone elses "magic", since forever dont need no Ansible. There is just nothing to say here, in the sense that we are not talking about same thing, and this is now off topic. Title is about everything being a web app. I think I've been clear I don't need any weird ass web apps. At all.

[-]

Mephistobachles@reddit

Jesus, we get it, you dont feel like doing it. Thats not technical argument, you're just whining and yapping. You literally asked wow do POSIX portability and SH help when daemon control differs per distro, well thats the whole point of detection logic. Its not convoluted, just a case statement with few branches. One case statement, done. Stop circling back to "I don’t wanna".

[-]

trullaDE@reddit

I feel a bit mixed about your rant, but in parts, I agree, with this

You just trust the magic.

being the main issue.

I fully get plumbing analogy, at the same time knowing its not actually worthy of plumber status. Same with electricians. You dont need to be electrical engineer, but you do need to know standards, codes, schematics. If you fuck up you get electrocuted. But get this... most electricians I met are genuinely interested in EE, at least in basics. EE degrees and hence jobs are highly gatekept, but you can still study. They didnt whim in into their trade, be it high voltage power systems or DC circuits, they are generally interested to the point of even creating some of their patented circuits. That does NOT happen in so called IT. They just go "no, no, why would I know or care about that? I have a web browser and docker which I dont even know internal workings of, let alone porting it to the OS I like when I whine about it. Why would I need to know Ohm's law, bro? By that logic I’d have to become a physicist just to churn out some dark theme code". And, "muh source code I trust". How much should we bet these people can or cannot read some mid complex C project and use classic build systems?

Btw engineering title is in many countries legally protected, requiring accredited education, licensing, and professional accountability.

Its also like classical music, imagine thinking you could write sonatas on pure vibe, skipping scales, arpeggios, theory, and knowledge of instrument. "dont even need to read sheet music, I just bang out compositions on vibe nights and use synthesia".

[-]

tose123@reddit (OP)

right. In Germany, you can't call yourself an engineer without the degree. In Silicon Valley, you're a "prompt engineer" for typing questions into ChatGPT.

"IT professionals" don't even know what happens when they type ls. Fork, exec, syscall, context switch? Mystery. But they'll debate React vs Vue for hours.

"Muh source code I trust" - they can't read it. But they "trust" 50,000 npm packages from anonymous accounts.

Classic build systems? They can't even write a Makefile. Three variables, five rules, done. But no, they need Webpack, 2000 lines of config, and a PhD in bundling. when something actually breaks, they can't fix it. Network packet drops? "Must be AWS." Memory leak? "Just restart the container." Race condition? "Works on my machine."

[-]

Mephistobachles@reddit

Touche, all of it, 100%.

Not to mention, it was solved better back then, with 10x less resources, less code, and quality so high it would be science fiction for todays definitions still. Lets take for example operating system namespaces back in the late 80s, and now, endless hacks of chroot with Docker, then hacking Docker with "containers", then hacking containers with Kubernetes. UNIX had it solved since its own inventors decided to even go next step further.

Today your average "tool" is fatter than an entire operating system which came straight out of Bell Labs, and even modern GPU limit pushing games take less of resources like RAM than Electron garbage or Next.js app.

[-]

tose123@reddit (OP)

Ken Thompson wrote grep in one night to solve a real problem - searching through text. One night. The entire program was under 500 lines. It's still the fastest text search tool we have, 50 years later.

Today they'd form a committee, debate microservices vs monoliths, implement it in Node with a React frontend, containerize it, deploy it on Kubernetes, and after six months and 50,000 lines of code, it would be slower than Ken's version from 1973.

The fundamental UNIX philosophy is lost: Make it work, make it right, make it fast - in that order. Now it's: make it complex, make it "scalable," make it someone else's problem when it breaks.

We can't even find the others anymore. The signal-to-noise ratio is approaching zero. For every person who understands why Plan 9 was better, there's 10,000 who think Docker invented containers.

[-]

Mephistobachles@reddit

Yes, and I've come to think that sometimes, besides just incompetence, its deliberate trick. Create problems, then invent solutions to those problems, then bill for the "innovation". Something like fashion industry, where theres always something new to sell.

[-]

Bladelink@reddit

Even that argument is kind of disingenuous, because it's abstraction all the way down. You trust the kernel process scheduler... how come that? Do you trust a container to run? A container is a simple abstraction that we've then layered other tools on top of.

If OP wants to "super understand all the low level stuff, how it all really works under the hood", good fucking luck with that. I like to think that I know A LOT compared to most folks, in terms of CPU architecture, memory virtualization, concurrency and process scheduling, eetc. Learning that is a lot of work and a lot of time. Is most of that relevant in the day to day process of producing whatever results we need in our environment? No. And it's not possible to learn everything these days, because computers and software are simply too complex. OP is being stubborn and also naive.

[-]

JohnnyricoMC@reddit

This. How far down do you go? Down to the assembler, learn the whole x86_64 instruction set, or stay with i586? Do you study electrical engineering to perfectly know how each CPU works? Knowing how things work under the hood is valuable but there is a limit to what's a sensible depth. Not all Linux distros are POSIX compliant so it's risky to make such assumptions.

Very few companies will be interested in hiring someone who's gonna be spending most of the time reinventing wheels on a lower level because of stubbornness dressed up as wanting efficiency, when someone else will build a working solution much faster with modern industry standards, in a format someone else can easily continue working on.

Frankly, the demonstrated attitude is a ticking time bomb of Dunning-Kruger effect. If/when they retire or god-forbid something happens to them, someone else will have to pick it all up and maintain the shell scripts they made for their employer. And it's somewhat arrogant to believe you considered every possibility and write more robust solutions than ones that are extensively peer-reviewed and has large industry backing. Wouldn't surprise me if OP also despises Lennart Poettering for systemd.

[-]

pdp10@reddit

when asking what their code is actually trying to do at point X, they only say "it's using library A, but I don't know what that does, I just use it".

Humans are exceptionally good at optimizing away things that they don't much need to know about, in favor of knowing other things.

I think Ops is going down that path as well.

It always has been, just differently and less apparent.

[-]

Bladelink@reddit

I trust the open-sourced, well-tested ansible collections to function correctly and in a predictable way. I have absolutely no trust whatsoever in whatever janky shell script you'd use instead. Have you tested that script on 10000 different hosts for every distribution? On 20 different python versions?

Oh also, I need you to update 1000 servers today, can you knock that out for me? Should only take you like half an hour.

[-]

Mephistobachles@reddit

So you missed the point and just listed your preferred flavors of magic. Cool story

[-]

tose123@reddit (OP)

"Tested on 10000 hosts?" My scripts run on any POSIX system since 1989. That's the point of POSIX - Portable Operating System Interface. Write once, run everywhere that matters.

Ansible's "well-tested collections"? You mean the Python scripts that break when Python updates? My shell scripts from 1992 still run because /bin/sh hasn't changed. POSIX hasn't changed. Pipes haven't changed.

"20 different Python versions?" That's the problem. Shell doesn't have versions. It has standards. My scripts work on sh, bash, dash, ksh, zsh. Because I use POSIX. Not bashisms. Not zshisms. Standard shell.

[-]

rvf@reddit

"Why are you pussies running vi when ed is the standard text editor?"

[-]

Reetpeteet@reddit

And are you gonna run kilometers of serial cables from the data center to your office?

Nah, use a port concentrator / serial console server. Gosh, I do miss the old Cyclades boxes; they were cute.

Your points are valid, I just wanted to wax nostalgic on Cyclades.

[-]

pdp10@reddit

I do miss the old Cyclades boxes

Cyclades specialized in serial solutions, but there were plenty of others. We used a lot of Xyplex. Cisco 2511 was common for a long time. I think I still have one of the octopus cables for one of those, but no 2511 to go with it.

I mean i get it... but no one manages kuberentes from a gui and is serious about it.

grafana

Is literally an insight and visualization tool... Not sure what you expected here.

[-]

Inside-Age-1030@reddit

Man, I feel this in my soul. Half the time it feels like we’ve just taken something fast and reliable and wrapped it in 12 layers of slow JavaScript just so it looks “modern”

I still do 90% of my admin stuff over SSH because it’s faster, less crashy, and doesn’t need a 400MB browser tab just to restart a service.

Guess we’ll be the grumpy old terminal people yelling at clouds while everyone else drags boxes around in their firewall GUI

gif

[-]

Emi_Be@reddit

Being on call now means fighting bloated web UIs instead of using fast, reliable SSH. Need to reboot a server? First it’s “loading dashboard…,” then cookies, 2FA and endless clicks - all while alerts are firing. The box itself is fine, but the management console crashes, lags or times out.

[-]

mrtuna@reddit

"Server's fine. Running for 400 days."

In some cases though, network infra like routers and switches can theoretically run for years without so much as thinking about them. I once decommissioned a Cisco switch that had been happily chugging away in a network closet, up since 1998. (Manufacturing plant, they had automatic backup generators that would keep everything going for weeks if the power went out). Only bothered to check the uptime because I was logged into the console to pull configs and thought "Hey, why not".

[-]

spin81@reddit

Then you'll absolutely have to restart applications at some point to make sure they're using the latest packages, so there will be some downtime for the applications.

Or you can make them HA/redundant/[insert different term here].

[-]

bbbbbthatsfivebees@reddit

True, but not all applications can be made HA.

[-]

spin81@reddit

It depends what you mean by making an application HA which for you and me in this discussion right now might be two different things. What I think you might mean is that if you are given an existing application to host and asked to make it HA, and in that case I agree.

But from a software development/architecture point of view I don't agree. I am convinced that any decent architect can make any conceivable application HA if they want to as long as they keep it in mind when designing it.

My background is as a PHP web dev and then a DevOps person, and I think if you cluster your database you can probably make most if not all PHP applications HA if you put in the time, effort, and money. The thing is most people don't want to, don't know how, or don't consider it when designing their application. Which is understandable, but I do feel it can be done more often than many devs might think.

[-]

bbbbbthatsfivebees@reddit

Absolutely! I'd totally prefer if all apps were written with HA in mind, especially because downtime sucks. BUT as a sysadmin I have to deal with what I'm given most of the time, and that sometimes involves restarting apps via scheduled jobs that pop at 3AM as to not disrupt any users.

[-]

segagamer@reddit

Windows OSes? No way, reboots at least every two weeks or you're not getting patches

What? Windows patches that require a reboot are monthly.

[-]

spin81@reddit

If you live patch your Linux kernels, you really still shouldn't be wanting to have your servers online for a year plus. Kernels can be live patched but they're not designed to and you should still reboot your machines once in a while. I don't have this experience myself, but from what I hear if you livepatch upon livepatch you can get stability issues.

Also if you'll indulge me on this here soapbox, here's the thing: there's been no need for any Linux machine to be online that long for at least a decade now but probably longer. Your services, if they are important, should not rely on a SPOF and procedures should be in place to patch/update/whatever those with zero downtime. And they can be.

[-]

Ah...Netware 3.12. So many floppies.

[-]

pdp10@reddit

16 bit interface and management software that ran better on Windows.

You're showing your bias, because that wasn't a "16-bit interface", it was a TUI using 8-bit ASCII from the ROM codepage, and everything in 3.x up was 32-bit.

It's the PC equivalent of calling something "green-screen", meaning, unfashionable.

[-]

poleethman@reddit

The cloud is the problem.

[-]

TechPir8@reddit

1000% this.

[-]

satireplusplus@reddit

Web apps are usually shitty though, change year to year and vendor to vendor. Command line interfaces tend to last way longer. Also configuring a firewall through iptables, ufw and the like can be a breeze in 2025 since you can get help with the commands from chatgpt et al.

[-]

1776-2001@reddit

Old man yells at cloud

Take a step back and consider how you're thinking of your servers. Now: think cattle, not pets.

A lot of these newer approaches are geared around managing a lot of systems and taking advantage of automation.

Shell scripts may assist and support Infrastructure as Code, but they are not IaC (unless you've spent a lot of time reinventing the wheel for some reason in your own way, instead of taking advantage of Ansible, Terraform, etc).

[-]

evangelism2@reddit

Docker Portainer. Kubernetes Dashboard. Grafana. Prometheus. All web apps to manage things that should be text files. Your monitoring system needs monitoring. Your dashboard needs a dashboard.

someone needs to learn about IaC

[-]

maxlan@reddit

I think you miss the point.

Too many people are deploying these kind of enterprise level monitoring applications which are so big, they need their own monitoring.

Doesn't matter if it's IaC or not, your solutions to manage your solution require more management than managing your solution.

[-]

evangelism2@reddit

Thats not your job, thats the vendor selling it.

[-]

Ssakaa@reddit

I'm as much "old man yells at cloud" as the next guy, but you completely missed the bus somewhere along the way... and your org even moreso. While you're trying to fix "one host" by hand, your org's trying to move forward... but listening to vendors since you're still in "manage a pet at a time" land.

Ansible and Terraform are and have been a thing for a while. Idrac/ipmi are still controllable without ever opening a browser. VMware can either be managed with those or with PowerCLI just fine.

Kubernetes IS managed with text files. Your choice to use some godawful dashboard is completely separate. Kubectl does go through RBAC, so make sure it's logging and use it. Portainer's rather nice for docker swarm in a homelab, but I wouldn't deploy docker swarm to a business. Too many halfway there gotchas that don't quite behave like normal docker compose, but look just fine in the config. If you need a cluster of container hosts... run kubernetes. Your devs will love you for it. If they don't, get better devs.

Grafana and prometheus don't do management, they do metrics. Metrics on a CLI suck, and they're ugly. Metrics in a nice grafana dashboard are pretty, and can tell whatever tale you need them to in order to justify your budget next cycle. Embrace the pretty for what it's meant for.

[-]

eNomineZerum@reddit

Lol, I work at a smaller place, they brag about their 15+ year average tenure. I get laughed at for mentioning "pets vs cattle". I'm in cybersecurity, not even specialized in sysadmin stuff, and still lay out architecture and code/automation-first solutions to help us scale in ways that aren't "dog pile all available hands until the work is done". My favorite was a dude of 25 years telling me "you gonna have to fight me if you want to do any ITIL shit" when I simply asked if there was a RACI or documentation for a solution my newly stood up team was taking over.

Place wonders why I am so efficient and successful with the newest team and a bunch of juniors. We automate like crazy and move on to solving the next problem INTELLIGENTLY.

[-]

Horrified_Tech@reddit

That was, no- is, Time Inc.... dog-pile on anything.

[-]

NUTTA_BUSTAH@reddit

I would have never expected to hear this from a SOC manager. Keep on rocking and fix the SOC space, it's crazier than ever from the sidelines.

[-]

myguyshy@reddit

ngl, sounds pretty sus bro

[-]

n4ke@reddit

I agree with everything you say but even when provisioning and managing in bulk (we use both Ansible and Terraform) the ability to drill down and inspect in case of issues is worth a lot.

We have devices we provision automatically but they're very finnicky with their failover config. Luckily, they still offer a CLI because their web UI is absolute trash and crashes constantly.

[-]

spacelama@reddit

We had a monitoring tool that was sold to management on the basis of it being autodiscovering and a single plane of glass.

It used IP address as unique index, so it would autodiscover that failover service (A,B,C,D,E,F) were running on servers (a,a,a,b,c,d), and then server a would be offlined and service (A,B,C)'s ip addresses would head on over to (b,c,d), and the monitoring solution would crap itself. You'd read up on the API documentation and discover that there was no way possible to monitor just the actual services provided by A - it would insist on autodetecting all the IP addresses associated with that service at the time it was onboarded. You could disable the other services it would also associate with the service you're monitoring, but at next failover, it would autodetect all the new pairings of services now running alongside them, and you couldn't turn off the autodetection.

And my immediate management didn't understand that when an edict is handed down from above about what we must present externally doesn't then mean we also have to rely on that as our own dogfood. "No /u/spacelama, you can't go set up a competent monitoring system alongside this one that actually warns us about actual fault conditions, because that would be duplicating effort. We have this single plane of glass that does it for us!"

[-]

I should've added the point that I'm definitely against OP's org's decision to go anti-SSH altogether.

Yeah; this idea seems to be gaining ground. Several of my IT-colleagues are very happy with terribly written web applications seem to think it's a giant security risk even though one is available to the outside world and one only after authenticating/stepping up/down almost half a dozen times in our specific case.

And especially tech-adjacent people, like former techs who've been doing non tech stuff for the past 10 years like writing policy and managing people and projects seem to hate SSH.

[-]

katbyte@reddit

no matter how much better it is many SMBs gonna default to pet over cattle

trying to convince them otherwise just ends up with them going with someone else

heck even personally i go with pets because its a homelab - something goes wrong i restore a backup. i don't need to expend the mental energy on doing it "right" and neither do many businesses

[-]

ycnz@reddit

Everyone has pets somewhere - try asking a devops kid how long it'll take to migrate them to a new laptop :)

[-]

phrstbrn@reddit

Cattle doesn't even work in large business environment either. They all have various COTS apps they need to support with varying requirements. Those shops will standardize the baseline image and provisioning, but what goes on top are all pets and managed by whatever team is responsible for those apps. So many apps are just "single server with COTS software on top". And a large company will have hundreds, possibly thousands of those apps.

but listening to vendors pitching their "single pane of glass" solutions (to manage all their other "single pane of glass" solutions) since you're still in "manage a pet at a time" land.

Valid hot take, but youu're missing that this is completely overkill or maladapted to some orgs. There is a "bad spot" somewhere between mid and medium org where managing the management takes more time than managing the machines.

And then, there are nightmares like my current org which is a MSP that has zero standardization across the board and all customers have slighltly different setups and requirements, and they all want their cows to be treated as pets not cattle, and management/sales can't say no despite us marketing ourselves as a "cloud" shop.

I agree that the solution to this is "change your paradigm" but techs don't get to choose their IT directors...

[-]

Ssakaa@reddit

roboto404@reddit

Things change, is the way I look at it. I might not like it but it is what it is. We work in a field that’s constantly changing/evolving. Adapting is something we need to be capable of.

[-]

mro21@reddit

I prefer adapting when I understand why I am doing it and what for.

Here we do it bc the industry has decided it needs to earn more money. Everything works so we make it broken again and sell new solutions.

[-]

roboto404@reddit

Yeah, I get it, it fucking sucks. I’m not trying to justify the changes, or disagreeing with any fellow techs, i’m just saying, it’s just the reality of things.

[-]

GroundbreakingCrow80@reddit

A lot of these are either features businesses wanted or consequences of things businesses wanted.

Now a lot of these can be managed by a system administrator who had very little experience or training. You don't have to learn the CLI.

[-]

mro21@reddit

Such a person is not a system administrator. It's at most a helpdesk guy

[-]

Hausmannlife_Schweiz@reddit

All done so that companies can sane money because Joe can do it. We don’t need to pay for a real expert.

[-]

mro21@reddit

Try to get a devops Joe (or whatever you call those playbook sysadmins) doing it for free 🤣

[-]

Infinite-Put-5352@reddit

I'm not an old hat by any stretch of the imagination. I only started using technology about 2 years ago. But I totally understand the pain of having to deal with 500,000 different fragmented dashboards. People say "SSH isn't secure". WDYM? What's wrong with SSH?? Set up key authentication, disable password auth, drop the SSH key on your YubiKey and you're done. What's not secure is a badly maintained webapp.

Terminal emulators in a browser. I swear, the only time I've ever touched those is when I was messing with my home server from school on a Chromebook. That's the only point of them. I haven't touched my Webmin in a year now.

Audit trails? Use auditd. Not the big new buzzword control panel. If you REALLY want, send all commands run on the system off-device using a simple systemd service.

Firewalls. I personally find NFTables far easier than IPTables(maybe because I'm very new to tech), but both of them are better than that GUI hell you described. My last resort is the Firewall module in Webmin, but that's really a LAST resort.

Infrastructure as code. I had to look this one up. So apparently it means using configuration to provision compute. That's most likely a cloud computing concept. But why? Just make a VPS. If you need a lambda or something, that's when it comes into play, in which case, you caIl an API. Not go click-click-ooo-flashy-lights.

Modern. From what I've heard about companies' security and end-user experience, this must be a joke. I'm sure there are some companies who are still sitting on MD5 or SHA1, mark my words. Or they'll be sitting with a 512 bit RSA key - and the only reason it hasn't been pwned into oblivion yet is because no one knows it exists. And the end user experience runs off of 500 layers of translation, jank, and "please don't let it break".

Accessible. Hmmm, what's more accessible. Text that can be read? Or a GUI? You get my point.

Cloud-native. OK. Or you can . . . put literally anything else on the cloud? Put in, say, a shell script? Still cloud native. Why a GUI?

User-friendly. Hmmmmm . . . this one is a good argument. But if your sysadmins are competent enough, you don't need it to be user-friendly, just documented and organized.

Just my take.

[-]

DarkAlman@reddit

The industry has moved towards web UI for everything to eliminate the need to maintain old thick clients, and to ensure compatibility across platforms.

All this extra .net, Java, and web browser code in between you and the hardware slows everything down and it's often buggy as hell.

I can't help but feel that we've sacrificed productivity and performance so that our manager can open the console on his iPad once a year.

Ultimately there's good UI and there's bad UI.

Unfortunately there's far too much bad UI.

Companies like MS making change for the sake of change, and chance trends like flat design instead of making things easy and efficient to use.

The Server Manager in Windows can kiss my a$$.

The old Control panel and mgmt apps were far better, and back then they didn't hide basic settings behind Powershell. Powershell is great but you shouldn't need it to set basic settings.

That VMware web client never really got better. In the rare cases I still get to use the old C# web client on old ass servers, I still miss it. It was a lot better.

But GUI's for Firewalls?

The GUI for many devices is far better than cmdline. I remember trying to program VPNs and NAT changes on ASA's back in the day on console and it was a nightmare. The web gui on my new firewalls is orders of magnitude better.

Switches?

I love using cssh during teams screen sharing sessions and getting all those gasps when I simultaneously check say FS layouts across 16 servers. Simple, done literally within seconds, as we speak, in front of everyone.

So I am with you on this one. Hard to do via GUI as quickly.

[-]

mro21@reddit

They hoped you'd keep them busy for hours so they have sth to note on their timesheets 😁

[-]

RealAnigai@reddit

Learn Infrastructure As A Service. Something like Terraform will pretty much render you complaints moot as the lines between sysadmin and developer blur and get filled in by devops.

mro21@reddit

1) Those web-based tools are probably there bc they need to give some limited administrative access to some dev or user. Of course the web tools are what they are and they never really do what you wanted them to do exactly, unless you'd develop it on your own. But the user will calm down when you tell them the tool is very expensive and from a company high up in Gartner terms and an industry standard.

But his solution was compliant and he is an EXPERT.

[-]

Environmental-Ad8402@reddit

What?

Who in 2025 manually runs commands via ssh to configure servers?

Sure if you manage 2 servers, fine. But most admins I know manage hundreds or thousands of servers. You're telling me you manage that kind of workload by hand with ssh commands?

Our grafana, Prometheus, and awx is managed by code, stored in gitlab, pushed automatically to our kuberentes cluster using FluxCD. Everything else that is not hosted in Kuberentes is done through Ansible via awx. Imo, running commands manually is worse than using a web UI. You are far more prone to error than using a standardized automation tool.

[-]

Fratil@reddit

But most admins I know manage hundreds or thousands of servers.

Coming from a small-medium business background I seriously feel like I'm living in a different world than you guys in terms of those "Who is still doing X?" questions on here.

Don't get me wrong I think you're objectively right in a lot of ways for where IT should be, but having recently worked for multiple MSPs and having seen hundreds of businesses across them almost none of them are even close to utilizing that level of automation and containerization. I feel like people on are here are just optimistically pretending it's already common practice just because it's best practice.

[-]

Environmental-Ad8402@reddit

I don't think it's common practice, especially in small-medium business. But you kinda hint at the reason why. Big businesses can afford the people that are able to do this. I've consulted medium businesses in the past, and helped the adminis on staff set up some automation.

What I have seen, and this is by no means a generalization, only an observation, the adminis I've worked with in SMBs don't have those skills because it's not required for them. Those that do, know they're worth more. They do things how it's been for 20-30 years, because it works, they understand it, and it's familiar to them. Often times I've seen admins run expensive proprietary software simply because it gives them peace of mind that they can always open a support ticket. I've seen that being that support and specializing in a practice can earn you a better salary. So that's what I decided to specialize in.

[-]

mro21@reddit

They can't "afford" it? How condescending. Why would they need it in the first place? Bc some industry is trying to push it hard? Essentially making you feel bad if you don't use it? With people who would never have gotten a job now they have a new market if it only is for playing with their playbooks, while hoping the result is what they want?

If these small companies have any decent IT person they would be getting hands-on with this stuff in no time. But maybe they choose not to because they simply don't need it. Or would want the same raise in pay than those newly designated "experts".

[-]

Adures_@reddit

Not only that. For IaaS to work you need Infrastructure to have infrastructure.

For small and medium business which usually require only handful of servers (and they need less over time as they move to SaaS), doing IaaS and building full automation with something like ansible and terraform is more work and ands more complexity than simply logging into the serwer and doing the change.

When you have thousands of VMs and containers, It absolutely makes sense for big business to increase complexity by introducing IaaS and all automation with ansible. When you have dozen of VMs, that hardly change + backups and snapshots, there is really hardly any reason to waste time on increasing complexity. Not everyone needs to be hyperscaler.

[-]

Environmental-Ad8402@reddit

doing IaaS and building full automation with something like ansible and terraform is more work and adds more complexity than simply logging into the serwer and doing the change.

I disagree vehemently with the assertion that at least ansible adds more work and complexity as compared to doing things manually.

I've worked with SMBs before. I've seen the endless complaints of "why isn't this domain controller configured the same way as this other one". Or "Why is one of the 2 load balancers missing options".

In my experience, I have never once in my career seen any business regardless of size be able to consistently configure a service WITHOUT a properly automated configuration management.

When you have dozen of VMs, that hardly change + backups and snapshots, there is really hardly any reason to waste time on increasing complexity

How do you.manage config drift? Or how to do you manage misconfiguration? Or how to do you justify the time wasted in finding out why X doesn't work the same as Y that are supposed to be the same. Ansible is not a huge time investment. In fact, the time you invest in it, brings lots more value that sitting there on a Friday night trying to figure out why 2 nginx servers that are supposed to do the same job return different results.

I think you are right only in the extreme of your case. Only if you manage 2 or 3 machines. Any more than 10, you'd be surprised how much added value a tiny investment in automation with ansible can bring. Not to mention, make your job as the sysadmin much easier.

[-]

th3groveman@reddit

Thank you. My nearly 15 year career is in small business barely able to be proactive and I sometimes feel so unqualified to be a sysadmin when reading these posts from high end infrastructure people.

My question is how can I even start to learn some of this stuff to level up my career? It’s overwhelming.

[-]

SilentLennie@reddit

I tried to automate stuff when working at a MSP and it's hard to get people to adopt even using it.

[-]

Thy_OSRS@reddit

I find this is one of the most sensible comments here tbh. Everyone who is acting like IaC is everything and everyone else is a fossil is either under 25 and naive or have only just gotten into the field in the last 5 years.

There’s going to be so many companies who still do things the “old fashioned” way.

And even if they wanted to move to the more modern way of working, they’re hampered by “legacy” services that just work and no one wants to pay to update.

It really shows their naivety and immaturity to assume everything should be a certain way and that doing things manually is outdated

[-]

No_Investigator3369@reddit

Who in 2025 manually runs commands via ssh to configure servers?

What I can't stand about some of my peers. They think anything with a GUI is trash and despise not doing anything in CLI. It really can get to be annoying and to me a form of legacy thinking as well.

[-]

tose123@reddit (OP)

"Who manually runs SSH commands?"

Nobody said manually. Maybe this?

for host in $(cat servers.txt); do 
  ssh $host "command" 
done

Your AWX runs Ansible which runs SSH. You built a k8s cluster to run a web UI to run a tool that runs SSH.

I just run SSH.

Same result. Mine uses 4KB of RAM. Yours needs a cluster.

[-]

ansibleloop@reddit

And yours is a bash script with no idempotentcy

My Ansible playbooks can be ran over and over and only change something when it needs changing

[-]

Yup that's exactly how I envision my Ansible usage: a shell script wrapper with QOL improvements (idempotentcy mainly).

[-]

ansibleloop@reddit

That's it - once I learned how to make Ansible modules and use them in a playbook, it all clicked for me

Now I have simple modules to configure a specific thing, in a playbook for host X that auto runs using Git actions

It's fantastic - it's so easy to keep all of my config in sync and stand up a new system in no time

[-]

I use a cluster for high availability. Mine uses the same resources in the cluster as yours does locally. Except mine as traceability through AWX and forces a strict standard.

I built a k8s cluster to run multiple different tools that are needed in my org, conserve resources, and to manage my deployments using a single standardized method.

You're reinventing the wheel with scripts that run ssh host command.

[-]

juicetoon@reddit

“To run multiple different tools”

You may know sysadmins who manage hundreds or thousands of servers, but what you have explained seems to be ridiculously in unnecessary overkill for your environment. Feel free to hit back though.

[-]

Environmental-Ad8402@reddit

I'm not going to explain every single last thing in my environment. I named enough generic examples that most people in the industry use without talking about any of the proprietary stuff we also run. I'm not about to dox myself or lose my job for Internet points.

You're free to believe whatever you want. I know my shit works and is cheaper for my environment. You do you 👍.

You may know sysadmins who manage hundreds or thousands of servers

gif

[-]

praetorfenix@reddit

People get so excited about the stupidest shit that ends up another uselessly complex way to not have to type commands.

“Sysadmins were so preoccupied with whether or not they could, they didn't stop to think if they should.”

[-]

Environmental-Ad8402@reddit

I'd rather spend time automating my infrastructure I'm in charge of than typing commands. Manually typing commands IS error prone whether you agree with it or not. If you don't believe me, that's fine, you're free to do whatever you want. I know my shit works, and I don't get called in the middle of the night because today I didn't sleep well and forgot to run a command on a specific server.

Native tools on bare OS can of course access the filesystem, thats the whole point of being native. Difference is, on iOS, macOS App Store, or Android, apps cant just poke into root or your files and go through review and ask for permissions. Web apps dont. Not that complicated. Calling ad blockers security model is laughable, come on. And show me this mythical native phone app that needs photo roll access to reserve an IP.

Or I have a better idea, just spare me the lectures.

[-]

mro21@reddit

Did you ask for a filesystem check? :)

[-]

VeryRareHuman@reddit

I say " Adapt or be irrelevant".

It is not snarky or making fun of you. It is what it is in IT world. Keep adapting to the technology (and the culture).

I live in PowerShell all day long. Love how easy it is. But some products are all GUI, we have to deal with it.

[-]

mro21@reddit

I-Need-To-Run-This-Simple-Thing-Using-An-Awkwardly-Long-Command-I-Will-Never-Remember

[-]

VeryRareHuman@reddit

Right. Are you talking about coworker? He does that. There is NO pride in running a command or small script against a few clicks.

[-]

shellymcshellerson@reddit

ITT: people conflating old == bad and old == not automated.

In my experience, I’ve had bits of shell that does meaningful work and has worked without change for more than two decades. That kind of longevity doesn’t exist in many other tools.

I also use ancient Tcl scripts at work that template Apache configuration, manage passwords, and other things that existed long before Ansible did.

In my experience, people that don’t believe simple tools and text work are either A: ignorant or B: trying to sell you something.

It’s not that Ansible doesn’t work or isn’t good, I’ve used it a lot myself, it’s just not as good as a shell script in some cases, just like a shell script isn’t as good as Ansible in some cases.

[-]

_oohshiny@reddit

In my experience, people that don’t believe simple tools and text work are either A: ignorant or B: trying to sell you something.

The concise form of the Unix philosophy states as much:

Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.

[-]

mro21@reddit

*systemd enters the room*

[-]

mro21@reddit

I wonder why anyone worrying about your opinion is also preoccupied by you apparently never rebooting anything. Maybe you should adopt the modern way: 1) create sloppy apps that crash on their own all the time 2) put everything in containers 3) create another "orchestration" layer above that in order to finally 4) just kill them and create new ones every five minutes.

Seems like nowadays that awards you a gold medal for some reason.

[-]

olinwalnut@reddit

I was joking around with our one (young) firewall guy yesterday when they were managing a firewall through the web app and I saw how long it was taking to type everything in and just the response time…I went “well maybe someday you’ll be able to SSH into something as an adult and be able to get things done in seconds.”

He was like “you and your command line stuff” and I went “buddy once you grasp that, you’ll never go back.”

Don’t get me wrong: I don’t mind GUIs. I’m a big fan of Cockpit (web app) for accessing KVM VMs on a Linux box. But if I can do it through a terminal and even better I can script what I want done…why not do it that way?

[-]

FarmboyJustice@reddit

Sounds like a dinosaur who is going to get smoked soon. Clicking in GUIs isn't scalable beyond a few sites

[-]

n4ke@reddit

Yea but that's my point. So many things are GUI first these days, which is usually a barely stable >5MB webapp.

I prefer command line first with GUI built on top so it is optional to use and automated implementations and scripting are first class citizens.

The examples OP mentions are out of date but I strongly agree with the "everything is a webapp and I want to die" part.

[-]

pdp10@reddit

I prefer command line first with GUI built on top

You want a library/API/protocol at the bottom, performing all of the non-UI actions, then different UI apps on top to interface with that.

It's better than literally driving a CLI from a GUI, like cdrecord.

[-]

Dushenka@reddit

Curious, why shouldn't ssh automation be scalable? I found it's the one interface most things still have.

[-]

FarmboyJustice@reddit

Wait, so you're using the "GUI isn't scalable" argument against someone who specifically complains about GUIs?

All your layers of abstraction and deployable infrastructure ultimately depend on running shell commands at some point, and not know how that works cripples you when something goes wrong.

[-]

lemaymayguy@reddit

or running ssh commands

Dog he's arguing against using an API, you really think he's scaling his deployments with the CLI? He's sshing into them like a gui. All configuration needs to be stored in code so it can be automated repeatedly

I thought I was the only person using the concept of a "User" as derogatory.

Why would you possibly think that? I'd bet every dollar I'll ever make in this life that "just a user" has been around (and in common use) for 50 years or more.

[-]

Smoking-Posing@reddit

Definitely since Tron premiered

[-]

pdp10@reddit

My SSH from 1987 still works.

Your telnet from 1987 still works, and so does your SSH from 1995.

Your API version changed three times while I typed this.

Feature flags beats versioning.

[-]

DasToastbrot@reddit

i love and cheer for everything you say and stand for in this thread mate! its so funny seeing people defend how stuff evolved.

like yeah i could use ansible running on python fetching an api doing stuff. or i could write a bash script doing the same via ssh like everyone did back then.

funniest thing is people saying just do iac. like they fkin trooblehoot a device via ansible when it behaves funny.

[-]

tose123@reddit (OP)

The focusing on wrong details (APIs! APIs! IaC...) is defensive deflection.

They grab onto technical minutiae to avoid confronting the bigger picture: that they're doing simple things in complicated ways. It's easier to argue about whether Ansible is "just SSH" than to admit you built your career on unnecessary complexity.

Make it complex enough that you need professional services. Change it often enough that you need subscriptions. Add enough features that migration becomes impossible. Then call it "enterprise ready." Meanwhile, that shell script from 1992 still runs. Because /bin/sh hasn't changed. Because pipes haven't changed. Because text hasn't changed.

[-]

mirrax@reddit

Pfft, this is romanticizing an unromantic past.

The auth headache for ssh is just hidden. Managing non-centralized individuals keys at scale or dealing with enterprise identity system. Are hardly more palpable to a centralized authority plus OAuth. The nightmare is just either already pre-baked or hidden upstream with ssh.

Likely that content header isn't needed. But I am going to send a structured text file with the configuration parameters. To an structured set of endpoints is hardly much better than I need to have either have memorized alphabet soup switches or read the man file to know if I need the -r or -R flag on whatever bespoke crappy fooctl.

And the the output being returned in object oriented json rather than output to the terminal or some obscure text file that needs to get processed with cut/sed/awk/tail.

[-]

Yuugian@reddit

The auth headache for SSH was solved with LDAP. Store your keys there

Memorizing flags is, imo, easier than memorizing n-depth menus. And man pages are faster than the 300 page JavaScript enabled user manual

And awk is still faster than jq

[-]

agent-squirrel@reddit

Or Kerberos.

[-]

stiffgerman@reddit

When you really think about it, bash over a serial line is also an API. We've had automation layered over that for DECADES. All of this REST stuff is fine, but at the very bottom of it all is something shoveling bytes around.

[-]

Bladelink@reddit

Yeah, his conclusion of his argument is fallacious basically. I can use an API to do X. He wants to "just SSH to the thing"... And then do what? Run your jank bash script to do the same thing, but in a nonstandardized, undocumented, unpredictable way.

I'm a Linux admin and all I do is live in SSH sessions. But that's basically just my IDE for writing manifest files and ansible roles.

[-]

gafftapes20@reddit

Until you start working with Microsoft graph apis and there are functions that literally are only available in the ui. I can script about 90 percent of it, but two little toggles are not exposed as parameters.

[-]

Exciting-Act5922@reddit

Yeah but you can upload a manifest file for that.

[-]

Time_Turner@reddit

Can you explain briefly how to do that?

[-]

Exciting-Act5922@reddit

That is a sad joke, by me and Microsoft. Some data, like specific app registration details, can only be edited by uploading a manifest/json file that includes all the data. They often give you aUI for that upload, and when there is a UI, there must be an API.

Eg https://learn.microsoft.com/en-us/entra/identity-platform/reference-app-manifest

"However, there are some scenarios where you need to edit the app manifest to configure an app's attribute. These scenarios include [..]"

[-]

Time_Turner@reddit

Ah, this is good. Aren't there some M365 products which are only manageable via non-rest API means? Like only via powershell and ui (which seems to just be a wrapper for powershell)?

[-]

mro21@reddit

For a long time it has been about creating new needs that no one knew they had before. The young buy it. The older ones see it with a grain of salt. It's done in order to keep the industry going 🤑

[-]

DonkeyTron42@reddit

Most of this stuff usually has an API so you don’t have to use the web app.

[-]

changework@reddit

I’m with you OP.

Browser terminal windows

"Oops, the browser caught that keystroke combination and I lost my window".

[-]

BlackGuyver78@reddit

I completely understand but...

All I heard was "You damn sites get off my server."

Insert picture of an elder sitting in a rocking chair in their homelab.

[-]

istredd@reddit

Can't disagree more. Well, sure there are some Windows based apps which still are UI mode only, but as Linux Admin and Cloud Engineer I do everything through APIs, Ansible, Terraform and bash or python scripts (which usually overlaps Ansible). I do really complex setups like Panorama firewalls, Aruba switches, net servers, web servers, building cloud infrastructure and I can do everything from the console. Literally I didn't see any UI (except for some checks) for years now. You probably need to adapt into new ways of management like APIs which are really useful even if it requires a few words more to add. But hey Ansible and python will help you!

[-]

MegaThot2023@reddit

I'm a network guy, and Ansible has honestly been more of a time sink than a simple Linux server with bash scripts and cron jobs.

Basically, by the time I've put together a playbook that does what I want to do, pushed it to GitLab, synced AAP with Git, created the job template, and then ran it, it's like twice as much work as just dumping the commands into a shell script and using another script to run it on the applicable switches/routers. For smaller tasks on just a single switch or two, it is 100% faster to just SSH into the switch and edit the config right there. That doesn't even get into the other faff like building custom execution environments to use the community collections for specific devices, etc.

My Wendy's put out Kiosks that you have to order at, but moved the self server drinks back behind the counter.

[-]

Alexis_Evo@reddit

but moved the Coke Freestyle machine behind the counter.

I actually prefer kiosks but this would lose my business.

At a prior workplace the CEO somehow managed to convince Coke into leasing us a Freestyle machine for the breakroom. It was a glorious one way ticket to diabetes.

[-]

pdp10@reddit

diabetes.

[-]

1776-2001@reddit

SIR! THIS IS A WENDY'S!

Try Taco Bell, they are next door.

In the future, all restaurants will be Taco Bell.

gif

[-]

vogelke@reddit

find out why they have concerns, and then (if their reasoning has merit) look at options to mitigate that and reach an agreement that satisfies both parties.

Unfortunately, the reasoning is usually "It's in the regs" or "It's our policy" and the agreement is "Be reasonable. Do it our way."

Source: 35 years working with the US Air Force.

[-]

cpz_77@reddit

Not sure about the govt sector as I haven’t worked in that, but at a for-profit company if the security team is not letting you use tools that you need to do your job efficiently, they’re costing the company money. If there’s no solid , valid justification for said restrictions, that is something that needs to be discussed with management. Their job is not to create roadblocks for employees, it’s to help them do things securely (among other things of course). Sysadmins should have a good working relationship with them to be able to work together to get a solution when things like this come up.

Them simply saying you can’t use any CLI tools is completely unreasonable, and sounds like someone who just read about some method of exploiting some CLI tool and now thinks they need to eliminate all CLI use to secure the environment. In other words, someone who doesn’t know wtf they are doing. But I know a lot of them will do things exactly like this.

That aside, I’m not sure why using the GUI would be more secure anyway considering those have had plenty of their own vulnerabilities over the years. But regardless, almost any legitimate tools can be misused by a bad actor. And they’ve almost all had some vulnerability at some point or another. That doesn’t mean shit. There are a ton of angles to consider on both sides when evaluating a potential vulnerability against your specific environment (including having a thorough understanding of the environment itself to begin with) to determine whether the risk even applies to your scenario, and if so, whether it is enough of a risk to warrant taking any action , and if so, what action to take.

[-]

Pelatov@reddit

We’ve gone from native ssh/shell sessions to API’s. The point of everything being a web app is so they don’t have to make a version of the thick client for windows, another version for OS X, and another for Linux, and god help you if you want to integrate with a package manager.

Web is for quick and simple tasks (even if an scp could be quicker to get the file there) API’s are for remote calls, en mass, automation in python, bash, or powershell, etc….

Learn the vendor API, write a simple script that takes 1-3 inputs and then gives you what you’re looking for.

I deal mostly with AWS these days, and can say I prefer the CLI over the console. In the last 6 months I’ve written over 2 dozen different scripts that pull the info I’m looking for, all I need to do is give it an input of a host name/instance ID, a region, and a profile. Which I’ve also reduced the input so I don’t have to put “superawesomeprofile” or us-east-2. I can put “sap” as shorthand for the profile and us2 for the region.

.\getinfo.sh i- sap us2

Bam! Got all the info i need in a nice json export so i can jquery on it and do what i need.

[-]

Computers were a mistake, lets go back to pre-fire humanity.

[-]

Smoking-Posing@reddit

"SSH?!? Dawg, we need to take it back to Morse code..."

"Morse code?!? Bro, we need to take it back to Pigeon Mail..."

I understand your sadness.

Just to comment on one point. Most firewalls, still have SSH pure terminal access, which simplifies most things.

May be off in some by default but should be able to be turned on?

[-]

riazzzz@reddit

Gotta move with it and embrace, fighting will just leave you further behind my dude.

You have a massive advantage in life just because of when you were born, you understand how things work and what they were built on. It will always be a fundamental skill which gets increasingly harder for new generations to learn as they get further and further hidden away by gui's.

Take that and embrace the new way where you don't need to learn and remember archaic commands and syntax, yeah some things will take longer to configure but in many ways it will add additional features or options.

tose123@reddit (OP)

"Don't want SSH key on my computer because security"

So instead you type your credentials into a web browser. Through JavaScript. Which has access to your clipboard, keystrokes, and DOM. Running arbitrary code from CDNs. With tracking pixels. And analytics scripts. And ads.

Your SSH key has a passphrase and permissions 600. Your browser has 47 extensions and executes whatever code any website sends it.

"Audit trail is important" - SSH logs every connection to auth.log. Has since forever. With IP, timestamp, and key fingerprint. Without needing a web app.

Shell scripts aren't infrastructure as code? They're literally code that manages infrastructure. They're in git. They have version history. They're testable. They're reproducible. What else do you want? YAML?

The security incident will be when your browser executes malicious JS from a compromised CDN while you're logged into your "secure" web terminal.

Meanwhile my SSH key is encrypted, local, and has never touched a browser.

[-]

ArchusKanzaki@reddit

And are you sure your SSH key can't be exfiltrated too? And the server is unhackable through your SSH key? I mean, if you practice PAW, and have 2 computers between normal work computer and protected access workstation, power to you I guess. You just need to carry 2 laptops anywhere. The point is not exactly the SSH itself, but the fact that you are SSH from potentially unclean computer. It can also be solved if you do VDI too though, or PAM.

Also, audit trail does not just include login and IP. It can also contains whatever you are doing after you login. And the purpose is not for yourself but for Security team to put into big data blender to find pattern and pinpoint cause for security incident. But I guess if you want to periodically upload your ssh logs, then go ask for exemption then.

As for other thing I will need from your script as an infrastructure as a code.... Do drift detection, make sure there is some kind of automatically updated documentation on what your script is doing and what it is creating probably as json format so other people can read it, and also create automated scripts when you need to decommission systems. Sure, Terraform is essentially just a wrapper for bunch of SDKs and APIs, but the neat thing is that its also declarative language. You just declare on what you want to create and what a system should contain, and the terraform will automatically create it for you. If you need to delete parts of system, just delete part of the code. It also kinda doubles as documentation that other people can easily read too. But hey, I guess it counts as lazy to you since I don't create my scripts from scratch.

[-]

tose123@reddit (OP)

"Can SSH keys be exfiltrated?" Of course they can. So can your browser cookies, saved passwords, and that web terminal's session token. The difference? My SSH key needs my passphrase to use. Your browser token works immediately.

You're carrying two laptops for PAW? I use one machine that doesn't run JavaScript. Simpler solution.

"Audit trail of what you're doing after login" - It's called .bash_history and script. Been recording sessions since before you were born. Your "Security team's big data blender" is grep with extra steps and a Splunk license.

Drift detection? diff. Documentation? Comments and man pages. Decommission scripts? rm -rf. You've renamed basic operations and convinced yourself they're innovations.

"Terraform is declarative" - So is make. From 1976. Targets are what you want. Rules are how to create them. Delete a target from the Makefile, it gets removed. Except make doesn't need a state file that corrupts every third Tuesday.

Your "neat" declarative language that "automatically creates" things? It's running the same API calls my shell script runs. It just hides what it's doing behind abstractions so when it fails, you can't fix it. "Error refreshing state" ring a bell?

The problem isn't that you don't write scripts from scratch. The problem is you don't understand what your tools are doing. You're trusting magic. When the magic breaks, you're helpless.

My shell scripts are readable by anyone who knows shell. Your Terraform requires knowing HCL, provider documentation, state file structure, and praying the provider didn't change their API this week.

But keep believing your complexity is necessary. I'll be over here with systems that actually work.

[-]

ArchusKanzaki@reddit

Oh sure Mr. Wizard. What we will do when you eventually leave this world? The secrets of the world of IT will forever be in darkness.

The 2 laptops thing is more about.... you know, you carry 2 laptops so you can use for work and one for accessing server? You don't need to do Zoom call or make some documents or do mundane work things? Or you just do both things in same laptop? I mean, keylogger does not just exist for browser.

Also, you said Terraform requires knowing HCL and provider documentation.... and you think that Shell does not need documentation too on how to do some things? The help command is not everything. And it's not like your shell can be completely free of API too so you still need to read documentations on that.

"error refreshing state" sure rings a bell.... but since I can do Terraform via CLI too and also read statefile, I can still troubleshoot things. What? Do you think since I do abstraction, I don't need to do CLI stuffs too? Terraform is not really magic. Its just wrapper for bunch of SDKs and APIs that your scripts are also calling to do same thing. The main point is that it's easier to read and easier to maintain, for person that is not me. Comments and man pages may not be understandable for the person after me, since even the way of thinking might be different. You never got handed a source code on different language than usual, with little or weird documentation and got asked to "understand" it? I think it will be much easier to understand scripts if specs are written in bullet points instead of long single-line shell script. Imo, the main point is that some "complexity" is needed not exactly for me, but for other people. Sure, you can do shell wizardry, but how about others?

Lastly, I don't thinkdiff is exactly drift detection that I have in mind, since the point of it is to check what is the difference between expected template and what the managed target currently have....

[-]

babuloseo@reddit

He is right web apps have a huge attack surface and ai is making it is worse as people are continuously churning out dashboards and web apps without proper security setup or context for the llms, most people that are building these web apps don't even know what an API is or how to use the api themselves to make sure they are making correct prompts they don't know OpenAI has a playground or google ai studio it's actually crazy, it's the Wild West right now for people that are in web app penetration testing and related. Gitleaks is picking up more secrets than usual as well.

[-]

FullPoet@reddit

The obsession with buzzwords like "Infrastructure as Code" while dismissing shell scripts (which are literally code managing infrastructure) shows people value labels over understanding.

I think you fundamentally misunderstand this. No one (who knows what theyre doing) is dismissing shell scripts.

IaC is code like you said, but its specifically avoiding just doing:

scp config.conf server:/etc/

Randomly. And also using specific DSL / language / scripting languages.

[-]

FiredFox@reddit

This guy is acting like we didn't have to spend the last 15+ years having to install, update, remove, install and update Java just to use an IPMI session on a browser...

[-]

synkrox@reddit

I honestly don't mind it for system admin stuff and the web gui is often much nicer than trying to remember all the commands for everything through the cli. (I'm a generalist and float across many systems)

For software generally though.... When did we decide we were going to be happy with a 3 second delay after clicking something while the command is sent and the next page computed and rendered?

Computers are faster than ever but web based software means a Chromebook will perform as well as the latest Macbook pro.

[-]

uf5izxZEIW@reddit

web based software means a Chromebook will perform as well as the latest Macbook pro.

That's if they compile the Electron shell for native M chips... Looking at you, Steam

[-]

Better-Memory-6796@reddit

You sir, could not be more right……..think I’m in love with you (……..or maybe it’s just seeing my, nay, our own reflection in the mirror but damn we’re pretty ;)

[-]

rehab212@reddit

Windows server still has sconfig.cmd and MMC, just sayin’

[-]

lungbong@reddit

We have a rule in our change process that says you must be able to fully document the exact steps in your rollout and rollback.

That means if you're using a Web GUI you can't just say "click Interface 0/0 and follow the shutdown instructions". This has forced a mindset where changes either need to copy/paste into the command line or you create an Ansible playbook.

[-]

iduzinternet@reddit

This feels so 2010… we are getting to the next phase where everything has MCP servers and you chat with the firewall AI to convince it your idea is better lol.

[-]

tom-slacker@reddit

??? I understand some of your grievance but html5 web apps is a plus in general, not minus.

It means less dependency on the need to install a native client on the endpoint client and thus another less point of failure.

And it being html5 means no weird addon or plugin shenanigans.

Moving vsphere client to html5 is a good thing in my book and I'm seeing mostly good performance on interface vis a vis the old native client (we don't talk about the flash based web client though)....

[-]

ballz-in-our-mouths@reddit

Huh, I find it takes me a lot less time to do these tasks.

But I have moved most of my skill set away from traditional sysadmin to a more IaC approach. So more of a focus on automating deployments, and pushing configs and apps via ansible, and leveraging apis.

[-]

Desol_8@reddit

Honestly would like to get into this but the automation I do the more I fear costing the help desk guys a job lol

[-]

Ok-Two-8217@reddit

Then you have to be willing to train them up to do the jobs that are available.

1a2b3c4d_1a2b3c4d@reddit

shows people value labels over understanding.

Not average people, executive leadership. These execs believe that the gui is best and easier, and plan to hire interns and recent college grads to use them. No senior level experience (or costs) required.

Seriously. I've spoken to many of them over my 30 years of IT.

A close friend and CIO just told me she plans to only hire interns and recent college grads to use Copilot and other AIs to run her IT Department in a Fortune 1000 company. She firmly believes this BS.

[-]

MonkyDeathRocket@reddit

Best part: the web UI crashes.

^^ this will fill a person with an indescribable rage immediately.

[-]

TheDawiWhisperer@reddit

old man shouts at cloud

[-]

j9wxmwsujrmtxk8vcyte@reddit

You know what was intuitive? iptables.

How I knew this entire rant was bullshit. There is nothing intuitive about iptables. You can of course learn it, it can become second nature but it is not fucking "intuitive".

Maybe it's time for you to rest, oldtimer.

[-]

Ok-Juggernaut-4698@reddit

My director can't function without the Meraki dashboard. Thinks parts of the network that aren't Meraki are broken.

[-]

PositiveBubbles@reddit

I know how you feel our horizon VDI environment is not managed by my team, and we only get 6GB and can't get the tools we need on the gold image and fslogix doesn't keep settings for everything we need :(

[-]

Bill_Guarnere@reddit

I totally agree with you, but all this phenomenon imho can be described as a progressive departure from the KISS principle, which always been the pillar of the IT since its early days.

On top of that there's the progressive misconception of people working in the IT, that think of themself as they are some tech gurus working for Google or some other big IT names.

Think about all this infrastructure as code BS, or scalability BS, 99% of the companies in the world DO NOT NEED these things, because 99% of the companies in the world are small and they don't need to spawn hundreds of hosts every day, and do not need to scale their services to sustain the load of Amazon or Google or Microsoft services.

People talking about reproducibility are talking about nothing, because even 25 years ago when I started my career in the IT with the first migrations of services from Windows NT or Windows 2000 to RedHat 7.1 everything was extremely easy to reproduce.

I could clone a host in no time with tar of the entire filesystem, I could reproduce a Tomcat or JBoss or Apache or WebSphere or whatever service in no time.

Probably it was not the same for people working on Windows with their stupid GUI, but in Linux it always been so easy, even cloning an entire server was a matter of tar/rsync and a couple of commands for installing the boot manager, nothing too fancy.

What I see now is people with no experience or skills in system administration messing around with manifests, ignoring the basic principles of system administration, spawning instances, pods, containers everywhere, skyrocketing costs for infrastructure (and companies go bankrupt for this kind of things) and creating incredibly compicated solutions for simple problems.

Consider for example three basic things: monitoring, logging and backups.

When I work on some project where people use BS as IaC I usually found: * a logging infrastructure which is way way way way more complicated than the services they are hosting and they are collecting logs for * a monitoring infrastructure which is way way way way more complicated than the services they are hosting and they are monitoring * backups not done (usual scenario I found when people use K8s) or took for granted (because we're in cloud), or done in the worst possible way (for example dbms backups done via volume snapshots).

All this complexity has consequences, and when shit hits the fan it's really painful. I lost count on how many K8s clusters I recovered which were in a complete abandoned state, with persistent volumes completely filled since years, pods in restarting loops for years, ingresses exposing services with nobody aware of them, dead nodes because of some failed upgrade and so on, or some stupid CD/CI pipeline going crazy resulting in huge bills on their cloud provider.

[-]

tose123@reddit (OP)

"Persistent volumes completely filled since years" - this is the reality of "cloud native." Nobody knows what's running. Nobody knows what it costs. Nobody knows where the data is. But hey, it's "scalable."

You know what's really scalable? A properly configured PostgreSQL on bare metal. Handles 10,000 connections without breaking a sweat. But no, let's run 50 microservices each with their own database, each in their own container, each with their own overhead.

The CD/CI pipeline going crazy and bankrupting companies? Seen it. GitHub Actions burning $10k/month because someone set up matrix builds for every commit. Meanwhile, make and cron have been doing continuous integration since before it had a name.

Dev here woeking on ASP.NET applications. I too hate web apps and dedicate a load of time into making them feel "right" because nothing about web apps ever feels solid, grounded or natural in any way. I always say a desktop app would be better for this, to which I'm told deploying desktop apps is an absolute pain..

I say it's self inflicted as I've seen many easy desktop app deployment solutions but hey ho we're still working on .Net framework so what can you do

[-]

Awkward-Candle-4977@reddit

how come you have 400 days uptime?
did you not install security patches?

[-]

tose123@reddit (OP)

Since when does a software patch need a hardware reboot? Am I missing something?

[-]

Awkward-Candle-4977@reddit

linux kernel updates happens like every month.
most distros doesnt use live patching so youll need os reboot.
windows server monthly updates include security patches and need os reboot.

Karen from compliance says we need "audit trails" and "role-based access control."

Sorry not sorry - I am that Karen. Information security is a rapidly changing field, especially in regulated industries such as payment cards (PCI-DSS) and we have to make our systems secure. Suck it up.

[-]

FarmboyJustice@reddit

Disregard the okayboomerkinder, I get what you're saying.

There's nothing wrong with fondly remembering when computers actually had to be efficient in their use of resources. The young sysadmins genuinely have not the slightest clue how completely off the mark they are, because they've lived their entire lives in a world that simply doesn't care about such things.

RAM is measured in gigabytes now, instead of kilobytes. They genuinely cannot grasp how big a deal that is. They literally can't comprehend it, it's beyond their ken.

Efficiency in software used to mean making the most effective use of very limited resources to accomplish amazing things.

Now the hardware is so fast and powerful that even shitty coders can write software that really flies.

Software efficiency today means being fast to market and fast to iterate and fast to "innovate" which is the word people use to mean "move shit around to make it look like we're actually making progress."

Big corps churn features and branding to improve shareholder value.

Startup folks dash to be first with an idea that goes viral so they can sell to big corps and retire.

Small businesses, the ones who actually drive the entire economy, are just trying to get shit done and stay afloat while being at the mercy of platforms and systems they have less and less control over.

[-]

mahsab@reddit

Small businesses, the ones who actually drive the entire economy, are just trying to get shit done and stay afloat while being at the mercy of platforms and systems they have less and less control over.

Too many people don't understand that small businesses can't just churn features.

One of my clients is a sheet metal factory. IT is there to support them efficiently organizing their work, but ultimately, their products are what their clients order and their speed is ultimately limited by how fast the laser can cut the metal. There's not many new features they can deliver, there's no hyper scalability or anything like that.

[-]

Imd1rtybutn0twr0ng@reddit

Most important line these days, "What about the shareholders?" Means more than service, employee satisfaction, or logical means to do business. Take a turd, wrap that smelly thing in gold, put "Bill" from marketing on it, and watch the shareholders go, "oooooh, $$$$."

Pretty sad. I'll see myself out. ᕕ( ᐛ )ᕗ

[-]

MairusuPawa@reddit

We put a terminal... in a web page... to connect to a server... to avoid using an actual terminal.

Yep, that's your brain on Windows and cmd.exe, it's so shit that people needed such a crutch. At least the new Windows Terminal is a much better improvement but there are still MSPs out there stuck with the dumbest possible OS and dumbest possible tools, and a severe lack of computer literacy overall…

[-]

SharpNShiney@reddit

Yup. Takes me longer to find the "solution" in the UI than it does to just SSH in and do it. Old woman here, yelling and cloud too.

[-]

TipIll3652@reddit

And then you find the solution... But forget where it was the next day. At least with a terminal I can go through the history when I forget the command.

[-]

eXtc_be@reddit

or you remember where it was, but they moved it

[-]

NUTTA_BUSTAH@reddit

Jira intensifies

[-]

dustojnikhummer@reddit

iDRAC, iLO, IPMI - all web interfaces now. Used to be serial console

They also used to be Java and ActiveX apps. So yeah, it could be worse.

[-]

NUTTA_BUSTAH@reddit

Those fucking Java apps. Jesus they suck

[-]

natefrogg1@reddit

Man that reminded me of seeing macromedia flash with some network scanner or something

[-]

GroteGlon@reddit

You're talking about tech that was phased out a decade ago. Have you just been managing some ancient environment for the last 10 years??

Also, 400 days uptime? Reboot your servers every now and again dude.

[-]

He's very upset for some reason.

[-]

Ok-Double-7982@reddit

This is the second time I saw someone mention 400 days uptime. He must have edited it out, as I don't see it in the OP anymore lol

[-]

spin81@reddit

VMware vSphere? Web app.

A web app, and an API and a CLI tool and a Terraform provider. I used the CLI a few weeks ago and we built a pipeline around the TF provider.

I don't mind hating that things are "the web" now but if your favorite client breaks you could learn the new one, instead of switching to the web view and then complaining about it, conveniently ignoring that other options are in fact out there, actually.

The console,lol... It's literally just text! But no, needs WebSocket, Canvas rendering, 400MB of JS just to show me a kernel panic.

More nonsense: first of all you can use the console desktop app, and second, it's not "just text" it's VGA output as anyone who actually knows anything about this stuff can tell you.

The new firewall has a "beautiful intuitive web interface." You know what was intuitive? iptables. One line. Done.

Yes and it hasn't fucking gone anywhere. If you want to you can have your whole org's firewall in one mess of iptables on a box somewhere. This is a choice you made and other choices are in fact out there.

Meanwhile, SSH still works. But no, that's "legacy." That's "insecure." Karen from compliance says we need "audit trails" and "role-based access control." So now everything goes through a web app that logs every click to a database that fills up every week.

Yes but you can have audit trails and RBAC and also have old school terminal based SSH access. The fact that you think you need a web app for that is a skill issue.

Grafana. Prometheus. [...] "But it's user-friendly!" For whom? Users who shouldn't have access to servers? If you need a GUI to manage a server, you shouldn't be managing servers.

Sometimes I want to see a graph that's not a few blocky characters in my terminal.

We put a terminal... in a web page... to connect to a server... to avoid using an actual terminal. It's SSH with extra steps and input lag.

Yes, and you don't have to.

[-]

Hewlett-PackHard@reddit

Peak stupidity: terminal emulators in the browser.

Uh... no, fuck you, you can have my Proxmox web shell when you pry it from my cold dead hands.

[-]

bukkithedd@reddit

Adapt or be left behind. It's been this way since the inception of our field.

We don't have to like it, but we can't do much about it. Spending energy on it is as pointless as complaining that you're wet and cold after pissing in your pants in winter to keep warm.

[-]

Stringsandattractors@reddit

I don’t miss maintaining and installing specific apps.

[-]

MrDToTheIzzle@reddit

gif

[-]

xxbiohazrdxx@reddit

Yeah man totally want that thick vsphere windows only client back

gif

PREACH BROTHER!

I miss simpler times. The consolidation of the industry annoying too. I LOVE chef. But progress software fucked the whole thing up. Then cinc showed promise as a rebuild, then progress software rolls the product into another one and sticks a new license on it.
There goes our rebuild.

IBM buys RedHat, and hashicorp. Broadcom buys VMware. And while they havent fucked it up yet, Microsoft bought fucking github!
So many core pieces of what used to be the defacto standard in tech.

[-]

Bromlife@reddit

Sure. But how will you feel when AI is Frankensteined into every piece of software you use? The future is here!!!

[-]

nut-sack@reddit

They are definitely taking it a bit too far. Like customer service is just going to turn to shit. It already has been with the automated support chats.
But I certainly like using Amazon Bedrock to make my work a bit easier.

[-]

AggravatingPin2753@reddit

I’ll take one web app to update over 3000 endpoints everyday.

[-]

yaboiWillyNilly@reddit

You can spend 99% of your time in some sort of terminal or IDE if you’re serious enough about preferring that. The world evolves, tech gets more complex on the backend to seem more intuitive on the front end. The reality is that companies want IT jobs to be easier to learn so they can offer less for them, and (shocker) people are scared of terminals. If you want to stay in a terminal, then do that. It’s not hard to find the documentation for it.

I’m just lost because you’re bitching about something that you don’t even need to use if you don’t want to. Not only that, but you’re putting the icing on the cake trying to bring up containerization (never have to touch a web interface, and most of us who work with it daily don’t)

Even if you’re just a server admin, you can do almost your entire job in PowerShell or terminal. Give me 3 things you do every single day and I can almost guarantee someone else has done that exact thing in a terminal or PowerShell, which ever.

Idk, to me it sounds like you’re tired of being a sysad. Go do something else. Try engineering, like real, actual engineering. Not azure sysad dressed up as a cloud engineer.

Go find a platform engineer or devops engineer role and start enjoying your work.

[-]

AHrubik@reddit

Remember when server administration meant SSH? Terminal? Actual commands?

I got three words for you, homie: A P I

Post was entertaining though, because despite being wrong you're also right.

[-]

Mrhiddenlotus@reddit

I wanted to be against you because your tone is annoying and it sounds like your company has poorly implemented software, but also there's a lot of Windows admins in here who would be way better teammates if they would bother to learn some Powershell.

You know what was intuitive? iptables. One line. Done.

LOL

Server's fine. Running for 400 days.

Yikes, even if you use kexec. Work on your HA and DR. Are you not doing firmware upgrades?

Karen from compliance says we need "audit trails" and "role-based access control." So now everything goes through a web app that logs every click to a database that fills up every week.

Oh no... basic modern security and GRC, how terrible.

If you need a GUI to manage a server, you shouldn't be managing servers.

Kinda agree tbh

[-]

Nevafazeme@reddit

This is one of the funniest rants I’ve read it awhile 🤣 crazy thing is, it wasn’t even that long ago that all of these things were pretty standard practice.

[-]

This is exactly his point though. You use a GUI because you learned it that way. But it is undeniably slower. And rather than the world make you learn commands which are faster, it's gone to him having to use a GUI which is slower.

And his bigger issue is that you don't really automate things with GUI, you need commands/apis for that anyways. Except now instead of them being native, snappy, local shells, it's going through a GUI to load a GUI version of a shell, complete with input lag inherent to all webpages. And rather than a basic protocol, it has to keep up with ever changing webpage protocols which in the instance of you needing a drac to fix something is wasting time (and we don't really regularly access dracs..you do when something is non responsive).

iDRAC, iLO, IPMI - all web interfaces now. Used to be serial console. 9600 baud.
"Please enable JavaScript."

Please grandpa, I am fine with console cable if its a network switch , not a server.

And JavaScript ? you running DL380 gen 6 , its HTML5 isnt it?

[-]

jrcomputing@reddit

Literally the only time I even use a console cable on my switches is when I am doing an initial provision of a new switch. Once I get past the initial config, I've got Ansible to do the rest via SSH. I even do all of their firmware updates via Ansible.

[-]

VTi-R@reddit

Yes the HTML5 interfaces all need JavaScript. Html doesn't have code execution.

That html iDRAC or iLO is just a streamed image with JavaScript managing clicks and keystrokes, which is why half the time they don't work that well. One of my current customers has iLO in a browser, within AVD, which then runs in another browser.

Two out of five times the keyboard just won't work, seemingly due to focus issues. Yeah great work you muppets, this is definitely progress it's just no-one told you it's the wrong direction.

That’s tech. I feel this is a skill issue mixed with corporate culture. The tech industry constantly changes, and you have to change with it.

[-]

t_whales@reddit

Sounds like a you problem. Adapt and grow. Stop wasting your time bitching into the abyss.

[-]

Alzzary@reddit

I find Web UI vastly superior to anything else. The thing you're missing is how hard it is to add features and maintain a non Web UI in a way that makes people want to use your software. Take PDQ for instance. I absolutely love their UI but it's very slow to load and you need an installer on every computer you use, you also need to allow multiple protocols from your client to the server most of the time, and there is no simple way to use the software in two windows at the same time. A Web UI works around all that effortlessly. Go use some of the legacy stuff where to look something, you have to choose the window you're working on, or there's no Linux version for what you want to do, and do on. 10 years ago I was angry about ditching the vsphere client, but nowadays I would never bother install it, especially since it's so easy to use.

[-]

pdp10@reddit

Most of ours is scripted already.

VMware vSphere? Web app.

We migrated off of ESXi/vSphere many years ago to a thinner, more flexible, QEMU that didn't only run on baremetal but also on workstations.

The new firewall has a "beautiful intuitive web interface." You know what was intuitive? iptables.

Our firewall policies are all text based.

iDRAC, iLO, IPMI - all web interfaces now. Used to be serial console. 9600 baud. Worked during a nuclear war.

We're overdue to update from IPMI to newer options like Redfish, but our IPMI is text/API/CLI based. SSH is still an option on them, but hardly used.

Meanwhile, SSH still works. But no, that's "legacy." That's "insecure." Karen from compliance says we need "audit trails" and "role-based access control." So now everything goes through a web app that logs every click to a database that fills up every week.

Just log your non-web management. One very basic way is to run things through jumpboxes that uses script(1) to make a non-optional log of each session.

My shell scripts are infrastructure as code. They just don't need a venture-funded company and 400MB of Go binaries to run.

Mine, neither.

[-]

CatsAreMajorAssholes@reddit

We’re a full cloud based company and no physical servers unless we acquire another business and migrate their machines to the cloud.

I get the ironic humor but times are changing and we need to be able to move with it.

[-]

sy5tem@reddit

no now you HAVE to manage all trought web with a god darn web interface that changes every month... so much fun

[-]

The-Jesus_Christ@reddit

"Remember when life was more difficult? I miss those days”

[-]

Helpdesk512@reddit

Adding 1% failure for 1000% accessibility is generally a worthwhile trade off except a few key industries. I’m here for the GUI

[-]

UffTaTa123@reddit

Remeembers me when a support guy could not work because Netscaler did not opened the port for him to manage the SAPInstaller. I then introduced him to ssh-portforwarding, bypassing all those shit and he was just baffled.

a IT tech service guy, that do not knew ssh port-forwarding. Oh my god ....

[-]