Reclaiming the lost art of Linux server administration
1–10 of 485 posts
Re: Reclaiming the lost art of Linux server administration
#2Time is money, and the more time I spend on infrastructure, the less time I spend on product. And thus is born the incredible demand of infrastructure as a service.
Thankfully one person's cloud is another person's on prem infrastructure so sysadmin skills will always be in demand.
From my perspective in enterprise computing, I now see people taking 2 paths. One where they become super deep sysadmins and work on infra teams supporting large scale deployments (cloud or not) and the other being folks who write code and think of infra as an abstraction upon which they can request services for their code.
Both are noble paths and I just hope folks find the path which brings them the most joy.
Re: Reclaiming the lost art of Linux server administration
#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 practical goal, you should be able to recreate your host with a single Bash script."
This already exists as a portable package:
https://relax-and-recover.org/
-"For my default database, I picked MySQL."
SQLite appears to have a better SQL implementation, and is far easer in quickly creating a schema (set of tables and indexes).
Re: Reclaiming the lost art of Linux server administration
#4-"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. 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.
Re: Reclaiming the lost art of Linux server administration
#5-"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.
Re: Reclaiming the lost art of Linux server administration
#6-"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. 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.
Re: Reclaiming the lost art of Linux server administration
#7Time is money, and the more time I spend on infrastructure, the less time I spend on product. And thus is born the incredible demand of infrastructure as a service. Thankfully one person's cloud is another person's on prem infrastructure so sysadmin skills will always be in demand. From my perspective in enterprise computing, I now see people taking 2 paths. One where they become super deep sysadmins and work on infr…
That's when it clicked for me.. comparing my hourly salary rate vs. the cost of running these services "in the cloud." Entirely eliminating "system administration" from my duties was absolutely a net win for me and our team.
Re: Reclaiming the lost art of Linux server administration
#8I 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!
Re: Reclaiming the lost art of Linux server administration
#9-"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. 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?
Re: Reclaiming the lost art of Linux server administration
#10Earlier 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.
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.