Slashdot Mirror
New Year's Resolutions For Linux Admins: Automate More, Learn New Languages (networkworld.com)
An anonymous reader writes:
A long-time Unix sys-admin is suggesting 18 different New Year's resolutions for Linux systems adminstrators. And #1 is to automate more of your boring stuff. "There are several good reasons to turn tedious tasks into scripts. The first is to make them less annoying. The second is to make them less error-prone. And the last is to make them easier to turn over to new team members who haven't been around long enough to be bored. Add a small dose of meaningful comments to your scripts and you have a better chance of passing on some of your wisdom about how things should be done."
Along with that, they suggest learning a new scripting language. "It's easy to keep using the same tools you've been using for decades (I should know), but you might have more fun and more relevance in the long run if you teach yourself a new scripting language. If you've got bash and Perl down pat, consider adding Python or Ruby or some other new language to your mix of skills."
Other suggestions include trying a new distro -- many of which can now be run in "live mode" on a USB drive -- and investigating the security procedures of cloud services (described in the article as "trusting an outside organization with our data").
"And don't forget... There are now only 20 years until 2038 -- The Unix/Linux clockpocalypse."
Along with that, they suggest learning a new scripting language. "It's easy to keep using the same tools you've been using for decades (I should know), but you might have more fun and more relevance in the long run if you teach yourself a new scripting language. If you've got bash and Perl down pat, consider adding Python or Ruby or some other new language to your mix of skills."
Other suggestions include trying a new distro -- many of which can now be run in "live mode" on a USB drive -- and investigating the security procedures of cloud services (described in the article as "trusting an outside organization with our data").
"And don't forget... There are now only 20 years until 2038 -- The Unix/Linux clockpocalypse."
that systemd has been purged from our infra. No more redhat derivatives.
This years looking like it's going to be a lot fun.
Above all learn that your job title should be sysadmin. Be aware that there are other kernels and indeed operating systems with merits.
You wonâ(TM)t learn much of value if you stick to Linux.
Or in other words, automate yourself out of your own job and get replaced by someone cheaper, using your scripts. Never make your job look easy.
Does shytstaind contain its own scripting language yet?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Whoah! Got to step 10 and stopped dead. Admittedly, windows 10 runs visual studio and *games*, but what slashdotter doesn't automatically disqualify operating systems that force ads in the start menu?
PS: Rogue One is by far the best star wars movie of all.
if we ( linux users ) are using 32 bit OS's in 20 years WE DESERVE it
the only 32 bit os i have is on a very old box from 2001 - that is on itt's last legs
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
Here's a new year's resolution for you: Strap yourself to a rocket and launch it to demonstrate that the Earth is flat.
The GP isn't wrong though. As part of pushing "DevOps" my company is pushing the Admins to become "real" programmers and as such is trying to shove Python down their throats.
While I'm a firm believer in fresh/relevant skills keeps the agism boogyman away, there is also a lot of risk in such a move. What I've seen:
I'm sure there are more if I put my mind to it too.
Yes you should always learn new skills and keep up with technology, but you should never do just to do.
A good [insert role here] knows that while they need to keep their tool box up to date they also need to use the right tool for the right job. Any one-size-fits-all approach is always doomed to problems that should never be.
Windows 10 is not better than Linux.
You can lead a man with reason but you can't make him think.
It is about making all bits equal regardless of the source without any policy or practice being allowed that would allow that to be interfered with by anyone for any purpose.
You can lead a man with reason but you can't make him think.
Learn something. Way too many of my peers thought that once college was done they were done learning. College got them the job and there was no reason to continue learning.
Learn something completely unrelated to your job and bridge the gap.
Right now I'm a mechanical engineer that is trying to play the job of IT DevOps. Because our IT department doesn't understand or want to understand the specific needs of what my group does. "Throw RAM and CPU" at it hasn't worked as our entire toolchain is single threaded and my 8600k beats the pants off of the 16 core dual socket Xeons they give us.
Learning another scripting language in order to do the exact same stuff.....
You're confusing the means and the end here. You don't learn a new scripting language to duplicate work, you duplicate work to learn a new scripting language.
The Daddy casts sleep on the Baby. The Baby resists!
I piped incoming user help messages to the emacs psychiatrist.
- BOFH.
Have gnu, will travel.
Why is too complicated to fit a Linux's LiveDVD to 4.7GB DVD instead of 2 GB?
Why is there not a Linux's LiveBD in a 50GB BD?
You live in the past. Newer systems don't come with shiny media readers, much like they haven't had tape stations for a while either.
Booting off a USB stick (or good old bootp for those who know how) is what's done these days. Then media size isn't much of a concern.
Why would you need to do exact same stuff ... with a new tool?
You don't. But it's useful to learn new scripting languages because some devop or other will surely use it, very badly, in an installer or maintenance script, which you will have to fix to get it working.
So that resolution isn't all bad. #16, on the other hand, truly is.
"It's hard to break old habits, but get used to the newer commands. Maybe it's time to use ip instead of ifconfig and ss instead of netstat. Look into the newer commands and try to roll them into your daily work."
No, no and no. Compatibility is key. You will still maintain 20 year old systems that cannot be upgraded, and needs more than your department's resources to replace. So you will be stuck using the old commands anyhow. Then what is better, to be able to use the same script snippets everywhere, and know what they do, or to use different commands, some of which change APIs more often than you change your underwear?
Learn the new commands, but don't use them. Much as you avoid bashisms when there's not a particular reason to use them, you also avoid new commands when there's not a particular reason to use them.
If you only have a homogenous set of servers, sure, do whatever you like, but then you're not much of a sysadmin either.
Python is from 1989, Ruby 1995.
if someone wants to learn a new language there are others like Rust, Go....though those might just be fads
hmmm, what does windows 10 do out of the box without spending additional money? can I harden a windows 10 system such that it could be directly connected to the internet without issue? unless explicitly configured, will it not send private information to 3rd party? Do I have a choice of scripting languages and can I access all system calls (subject to permissions of course) with them?
the point is sysadmins been using those for years
now call upstairs and have your mother order you some pizza so you can calm down
By that time they'll have moved on from system-d; they'll probably be up to about system-v or so.
Here's a new year's resolution for you: Strap yourself to a rocket and launch it to demonstrate that the Earth is flat.
Not really since "flat earthers" would not believe no matter what they were shown. However, it would be an excellent example of how the so-called "flat earther" could win a coveted Darwin Award .
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Offtopic, as no one would ever mistake apk for a Linux Admin.
You can potentially code solutions in fewer lines of Python compared to bash too
For complex things, certainly and at that point you should be using something more practical than BASH anyway.
If, however, I want to simply execute a shell command (that does not have a Python/Perl/whatever builtin analog), capture it's output to a variable, and check the exit status, BASH is pretty damn simple. Those last two requirements are the biggest killer of Python as that forces you to use subprocess which makes it much more complex than BASH (especially if you want to capture stdout and stderr).
It's not that things like that are hard or not well documented, but they are more complex to write and don't read as simply. Not only does simplicity serve when writing the code, it also serves when it has to be debugged at 4am due to a Production issue.
I've done my time as an Admin and much prefer writing real code (of which I happen to specialize in automation), but I recognize that the language I may choose to solve a problem might not really be the best option when all facets of it's deployment and support are taken into account.
Now what most admins leave out of their code which would do wonders regardless of the language is error checking. I've lost track of the number of messes I've had to cleanup that simply came down to scripts that blindly carry on assuming the world is perfect without bother to check... "if [ $? -ne 0 ] ; then" really isn't THAT complicated...
Python is from 1989, Ruby 1995.
All right then, I'm gonna learn COBOL!
#DeleteChrome
>If, however, I want to simply execute a shell command (that does not have a Python/Perl/whatever builtin analog), capture it's output to a variable, and check the exit status, BASH is pretty damn simple. Those last two requirements are the biggest killer of Python as that forces you to use subprocess which makes it much more complex than BASH (especially if you want to capture stdout and stderr).
I have a healthy dislike for subprocess in python, although my primary language has been python in the past few years because I find it productive for the work I do. Instead of subprocess, where interaction with bash is needed, I tend to write python to generate bash commands that write their results to a file which is then read by a python program. This leaves a record of the commands executed and the results, which turns out to be a heck of a lot simpler than wrestling with subprocess.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
...just learn how to do your job adequately? The Linux Administrator team at my work are largely a bunch of bullshit artists hacking through the forest.
We'll make great pets
Python is from 1989, Ruby 1995.
if someone wants to learn a new language there are others like Rust, Go....though those might just be fads
bash scripting + curl only gets you so far with REST...
We'll make great pets
Just a list of what it means to be a sys admin.
If you don't already do these things, you suck at your job.
On a long enough timeline, the survival rate for everyone drops to zero.
ifconfig has been depreceated, net-tools last release was 2001. I think it's time to update your skills.
Yeah, we all deal with old systems, but those should be the exception, not drive the rule.
Cheap storage VM.
Sometimes I surprise myself with what can be accomplished with a simple shell script. I was working on a program to copy pictures from an SD card (from a camera) to directories organized as ".../Pictures/yyyy/mm/dd/." The initial effort was in C# and .net. At the time I could not find a .net library that could extract EXIF tags from the image files. I ran into further troubles trying to port it to Linux. It eventually occurred to me that I could code it as a shell script using various commands to do things like extract and parse EXIF tags, create directories and copy files. The result is a 31 line script that copies all images from the current directory (that have not already been copied) to subdirectories under $HOME/Pictures by EXIF date or, barring that, file creation time.
I'm still using /bin/sh for scripts. I suppose it's time to move on to /bin/bash. ;)
I developed a set of BASH scripts to automate building a GNU/Linux distribution from scratch based on Linux From Scratch releases. After creating the package build definition files you can launch the build process by running a single master script. https://github.com/gdhorne/abs...
I know a guy that wrote a Puppet/Chef alternative in KSH. Complex stuff certainly can be done, but it is almost always more convoluted than using a better language for such tasks.
ifconfig has been depreceated
Many of us have to support operating systems that are still sold and supported, like Red Hat Enterprise Linux 6, where net-tools is still actively used and relied on by the system itself, or Red Hat Entprise Linux 7, where it is still provided and patched as needed.
If you have a choice to do otherwise, good for you, but in the mean time let us admins try to follow the Unix philosophies like multiple small tools that each do one thing well, have stable APIs, and provide the least amount of surprise.
So can Linux.
Granted, not as many, but it's amazing how many native Linux games there are now. I think we can thank Steam for that.
Take flight lessons. Own your own plane. They're only around $40K for a good entry level bird. I did that in 2005 and I still love it.
Maintenance can be a bummer. One year I spent around 12K. Most years it's more like 2K and that's for a 1950s era Beech aircraft V-Tail. I plan on 140 Kts and I get it most of the time. On a good day it'll do 150 Kts or 170 MPH.
A pilots license. Your license to learn.
Sufficient knowledge of ksh should make it pretty much the same as any other language. The only real difference is the lack of libraries to do all the work for you.
Granted, not as many
There's the rub. If the particular titles that your friends desire to play with you are unsupported, then Linux has no important games. Unlike non-game applications, most* games don't implement a common protocol to interoperate with other games by other publishers.
* The exception is computer ports of pre-1923 tabletop games, such as GNU XBoard that interoperates with other Chess software that speaks CECP 2.
Why is too complicated to fit a Linux's LiveDVD to 4.7GB DVD instead of 2 GB?
Because the wire protocol used by Secure Digital (SD) flash memory cards changed between 2 GB cards and Secure Digital High Capacity (SDHC) cards, which are 4 GB or larger. I imagine that the implementation of BIOS or UEFI on some PCs can boot from a 2 GB card but not from an SDHC card.
Python is from 1989, Ruby 1995.
if someone wants to learn a new language there are others like Rust, Go....though those might just be fads
I'm trying both those. While Golang is pretty easy, Rust is hurting my brain. The first few demo programs in Programming Rust leave (for me) a lot of questions. Those demos also have a high "punctuation character to alphabetical character" ratio. Or perhaps it's a low "alpha to punctuation" ratio. Admittedly that isn't a standard measurement and I'd never noticed it before, but man, there's a butt-load of colons in there.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
Let actual developers do it