One to read: Top 15 Docker Commands – Docker Commands Tutorial
This is more of a reminder to myself, but I’m starting to do some work with some Docker containers, and struggled to work out how to get into a running container. This post basically gave me the one-liner I needed:
docker exec -it [container id|name] bash
Found this over the past week trying to find somewhere to ship some logs to raise a bug on Vagrant (which I then couldn’t duplicate…. anyway!)
On Ubuntu, make sure you have ruby installed
sudo apt install ruby
Then install the gem package
sudo -H gem install gist
Once this is done, you can then call it like this
YourCommand | gist # Put the output of your command into a new anonymous gist YourCommand | gist -f output.log # Name the file you uploaded "output.log" YourCommand | gist -d 'Your Desc'# Set a description on the gist gist yourscript.sh -p # Upload yourscript.sh to gist, mark it "private"
You can also login, and all the commands above then get put in your gist tree (mine is https://gist.github.com/jontheniceguy) instead of an anonymous path. To login, do this:
gist --login
If you want to force the fact your gist will be anonymous once you’ve logged in? Do this:
gist -a yourscript.sh
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!
http://www.radiolab.org/story/null-and-void/
This podcast from Radiolab is intriguing. The first half had me hoping for the underdog, then there’s an interview with a very cross older gentleman, who’s clearly had enough of not having his voice heard…. At which point, I realise what is proposed could “burn it [American Civilisation] all down”… And suddenly I don’t want the underdog to win.
And the reason I think this is “one to listen to” is because of that guy. Basically, if you fight so passionately about something that you’re ready to hurt someone over that thing, you need to take a step back and check it’s the right thing to be fighting for. Chances are, it probably isn’t.
This podcast talks about a concept in US (and probably UK) law called “Jury Nullification”, where even if the law clearly defines some act or inaction to be prohibited, the Jury can express their distaste about that law by deciding “Not Guilty”. If that verdict comes down often enough, it “might” send a message to the law makers that there’s something wrong with that particular law, and perhaps it will be re-written.
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.
I’m catching up on the fabulous Devops Weekly mailing list, so some of these blog posts might be relatively old. The first post I’m picking out as interesting is Don’t build private clouds.
This post is interesting, because the role I’ve *literally* just accepted relates to building Private Cloud infrastructure, so… yehr. That was a great indicator :)
That said, the firm I work for falls solidly in the realms of “Actually, might be useful for you to build your own private cloud” so, not that bad really :D
And if you’re not in the range of people who the article claims should be building your own private cloud, give me a shout, and I’ll point you at some pre-sales people for building with *our* private cloud platform!
Anyone who uses curl | bash needs to take a look at pipethis. A simple GoLang program to use instead of curl | bash, used like this: pipethis http://install.example.com
To install under Ubuntu, you need to do: sudo apt install -y golang-go && sudo GOPATH=/usr go get github.com/ellotheth/pipethis
Other Linux distributions will vary!