One to read: “Tyblog | Systemd for (Impatient) Sysadmins”
The two parts about this post which interest me the most are about timers (a replacement for Cron, perhaps?) and User Instances (likewise, a replacement for how I use Cron :) ). There’s other interesting stuff here, but this is the crux of it for me!
This blog post was found via cron.weekly #89.
One to read: “It’s Time to Retire “RTFM” – Compassionate Coding – Medium”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “Interns with toasters: how I taught people about load balancers”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “How to undo (almost) anything with Git | The GitHub Blog”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “Debian & Ubuntu Equivalents of ‘yum whatprovides’”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
One to read: “Export Check Point firewall logs to a readable format”
This was automatically posted from my RSS Reader, and may be edited later to add commentary.
Do you use this pattern in your sh/bash/zsh/etc-sh scripts?
cat somefile | grep 'some string' | awk '{print $2}'
If so, you can replace that as follows:
cat somefile | awk '/some string/ {print $2}'
Or how about this?
grep -v 'something' < somefile | awk '{print $0}'
Try this:
awk '! /something/ {print $0}' < somefile
Ooo OK, how about if you want to get all actions performed by users when the ISO formatted dates (Y-m-d) match the first day of the month, but where you don’t want to also match January (unless you’re talking about the first of January)…
# echo 'BLOGGSF 2001-01-23 SOME_ACTION' | awk '$2 ~ /-01$/ {print $1, $3}'
(EMPTY LINE)
# echo 'BLOGGSF 2002-02-01 SOME_ACTION' | awk '$2 ~ /-01$/ {print $1, $3}'
BLOGGSF SOME_ACTION
This is so cool! Thanks to the tutorials “SKIP grep, use AWK” and the follow-up tutorials starting here…
Thanks to my colleague Simon (@sipart on Twitter), I spotted this post (and it’s companion Github Repository) which explains how to do test-driven development in Ansible.
Essentially, you create two roles – test (the author referred to it as “validate”) and one to actually do the thing you want it to do (in the author’s case “add_vlan”).
In the testing role, you’d have the following layout:
/path/to/roles/testing/tasks/main.yml
/path/to/roles/testing/tasks/SOMEFEATUREtest.yml
In the main.yml file, you have a simple stanza:
---
- name: Include all the test files
include: "{{ outer_item }}"
with_fileglob:"/path/to/roles/validate/tasks/*test.yml"
loop_control: loop_var=outer_item
I’m sure that “with_fileglob” line could be improved to not actually need a full path… anyway
Then in your YourFeature_test.yml file, you do things like this:
---
- name: "Pseudocode in here. Use real modules for your testing!!"
get_vlan_config: filter_for=needle_vlan
register:haystack_var
- assert: that=" {{ needle_item }} in haystack_var "
When you run the play of the role the first time, the response will be “failed” (because “needle_vlan” doesn’t exist). Next do the “real” play of the role (so, in the author’s case, add_vlan) which creates the vlan. Then re-run the test role, your response should now be “ok”.
I’d probably script this so that it goes:
The benefit to doing it that way is that you “know” your tests aren’t running if the environment doesn’t have the “set_testing” thing in place, you get to run all your tests in a “clean room”, and then you clear it back down again afterwards, leaving it clear for the next pass of your automated testing suite.
Fun!
Here is a transcript of a talk by Allison Parrish at the Open Hardware Summit in Portland, OR. The talk “Programming is Forgetting: Toward a New Hacker Ethic” is a discussion about the failings of the book “Hackers” by Steven Levy. Essentially, that book proposed (in the 80’s) a set of ethics for Hackers (which is to say, creative programmers or engineers, not malicious operators). Allison suggests that many of the parables in the book do not truly reflect the “Hacker Ethic”, and revises them for today’s world.
Her new questions (not statements) are as follows:
This is a significant re-work of the original “Hacker Ethic“, and you should really either watch or read the talk to see how she got to these from the original, especially as it’s not as punchy as the original.
I’d like to think I was thinking of things like these questions when I wrote CampFireManager and CCHits.