Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reclaiming the lost art of Linux server administration

pietrorea.com

Post reply on HN
Print view View original

11–20 of 485 posts

Re: Reclaiming the lost art of Linux server administration

#11

Post by johnchristopher »

chasil wrote: post #3

-"As for scripting, commit to getting good at Bash." That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. This is also an issue on systems using Busybox. A useful approach to scripting is to grasp the POSIX shell first, then facets of bash and Korn as they are needed. -"As a practi…

I settled with using /bin/sh for portability. If there is something that can't be done with sh but can be done with bash then it means a python script is better anyway. I don't want to deal with bashism and ksh and deb/ub/rh different takes on bash.

It's frustrating that most google search results and shell script search results on SO almost always mean bash and sh.

Re: Reclaiming the lost art of Linux server administration

#12

Post by VWWHFSfQ »

Regular SA and DBA jobs will be almost completely gone within a decade or so. Same as there are hardly any auto mechanics anymore because nobody can fix any of the new cars but the manufacturer.

You'll only find those jobs at one of the handful of cloud companies. Nobody will know how to do anything for themselves anymore and all this experience and knowledge will be lost.

There are no more actual administrators. Just users paying rent.

Re: Reclaiming the lost art of Linux server administration

#13

Post by candiddevmike »

Blame the folks demonizing/shaming having "pet" servers and pushing immutable infrastructure. Linux server administration is quite enjoyable, and with how well apps these days can scale vertically, it really takes a special kind of workload to need (and actually saturate) fleets of servers.

Re: Reclaiming the lost art of Linux server administration

#14

Post by NexRebular »

zokier wrote: post #5
chasil wrote: post #3

-"As for scripting, commit to getting good at Bash." That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. This is also an issue on systems using Busybox. A useful approach to scripting is to grasp the POSIX shell first, then facets of bash and Korn as they are needed. -"As a practi…

> That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. That's not really a problem as long as you use #!/bin/bash shebang, and there is nothing wrong in doing that.

Unless bash lives in /usr/local/bin/bash

Re: Reclaiming the lost art of Linux server administration

#15

Post by ericbarrett »

chasil wrote: post #6
cure wrote: post #4

Earlier quoted context omitted.

> That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. This is also an issue on systems using Busybox. At least for Debian and Ubuntu, that's why we start bash scripts with #!/bin/bash, of course. Your point is valid for Busybox, though.

> that's why we start bash scripts with #!/bin/bash That will also fail spectacularly, as bash does not behave the same when called as /bin/bash as it does when it is /bin/sh. I have principally noticed that aliases are not expanded in scripts unless a shopt is issued, which violates POSIX. Forcing POSIXLY_CORRECT might also help.

Not sure what you are saying, bash behaves as bash when invoked as /bin/bash, and Bourne-shell-ish when invoked as /bin/sh. Lots more detail in the man page.

I've never seen use of aliases in a bash script...? They are generally for CLI convenience.

Re: Reclaiming the lost art of Linux server administration

#16

Post by SkipperCat »

invokestatic wrote: post #8

I used to reach for shell scripts to configure servers, then Puppet, then Salt, and then finally to Ansible. Configuring servers declaratively is such a massive improvement over shell scripts. The fact that Ansible is agentless is also very nice and works very well for when you only have a handful of servers. Only thing I dislike is YML, which I think is yucky!

We took the same path, using config management tools to automate our deployments. But after a while, we realized that the servers only existed to run apps, and those apps could be declaratively described as containers and the whole thing pushed to Kubernetes.

That was our 'perfect world'. Reality was different and we still have a lot of servers running stuff, but what we did push into K8s really reduced our operations workload and we're pretty happy about that.

Re: Reclaiming the lost art of Linux server administration

#17

Post by cure »

netr0ute wrote: post #9
cure wrote: post #4

Earlier quoted context omitted.

> That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. This is also an issue on systems using Busybox. At least for Debian and Ubuntu, that's why we start bash scripts with #!/bin/bash, of course. Your point is valid for Busybox, though.

Why would anyone want to target bash specifically which doesn't exist in all systems instead of just sticking to what's implemented in /bin/sh?

Because you're not going to have a great time with /bin/sh (i.e. dash or the like) if you want to do anything more than very, very basic scripts.

Re: Reclaiming the lost art of Linux server administration

#18

Post by chasil »

gh02t wrote: post #10
chasil wrote: post #6

Earlier quoted context omitted.

> that's why we start bash scripts with #!/bin/bash That will also fail spectacularly, as bash does not behave the same when called as /bin/bash as it does when it is /bin/sh. I have principally noticed that aliases are not expanded in scripts unless a shopt is issued, which violates POSIX. Forcing POSIXLY_CORRECT might also help.

I would assume if you put /bin/bash as your shebang that you're expecting to get bash-isms. I think the problem you're complaining about (which is a real one) is people putting /bin/sh and expecting bashisms. Debuntu being problematic here is more a side effect of bad practice.

Bash has a POSIX mode.

Knowing when to switch into and out of this mode, and what impact it has, is a more advanced subject that should not burden those learning the Borne family.

It is better to start with Almquist, or another pure POSIX implementation, with documentation specific to standard adherence.

More advanced shell features should wait.

Re: Reclaiming the lost art of Linux server administration

#19

Post by trabant00 »

VWWHFSfQ wrote: post #12

Regular SA and DBA jobs will be almost completely gone within a decade or so. Same as there are hardly any auto mechanics anymore because nobody can fix any of the new cars but the manufacturer. You'll only find those jobs at one of the handful of cloud companies. Nobody will know how to do anything for themselves anymore and all this experience and knowledge will be lost. There are no more actual administrators. Jus…

I've been hearing this for the past 20 years. And now my sysadmin skills are more and more in demand. For the past 5 years or so I started making more money than a dev because of supply and demand.

Rent to AWS actually drives demand up quite a lot since the bills are huge and very few people understand what is under the hood and how it can be optimized.

I doubt very much things will change in the near future. In the far one... who knows.

Edit: car mechanics with their own shop make significantly more money than me and it seems to only get better for them as cars become more complex.

Re: Reclaiming the lost art of Linux server administration

#20

Post by jvalencia »

Having scaled up various business initiatives, and working through countless scaling issues, I would recommend managed services like anyone else with experience...

However! When I spin up my own side projects. It is sooo much easier to just go into the command line and spin something up directly --- it does make me wonder whether some small amount of expertise can really change things. By the time your orchestrating AWS services, docker containers, kubernetes and more --- Would it have been so bad to run a 10 line bash script on few cheap VMs to set yourself up?

Even typing that, I realize how much time managed services saves you when you need it. Change management is really what those services offer you - even if a momentary setup is easier by hand.

Post reply on HN