Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Script to run esxcli unmap on all datastores attached to an ESXi host

It’s a good idea to periodically run the UNMAP command on all your thin-provisioned LUNs. This allows the storage system to reclaim deleted blocks. (What is SCSI UNMAP?)

The format of the command is:

I wanted to make a script to run this on all attached datastores so here’s what I came up with:

The esxcli storage filesystem list command outputs a list of datastores attached to the system. The second column is what I am interested in, so that’s what awk takes care for me. I don’t want to target any local datastores, so I use grep to filter out  the ones I am interested in. 

Next step would be to add this to a cron job. Got to follow the instructions here, it looks like. 

[Aside] Inside Shellshock

CloudFlare makes great technical posts and this one on how the Shellshock bug can be exploited is no exception. Go read it!

[Aside] Shellshock – Stop blaming Bash!

Am sure everyone’s heard of the Bash Shellshock bug by now. Basically, Bash (like most other shells) has environment variables. When launching Bash you can set an environment variable too, and the newly launched Bash process will inherit that variable. So far so good, but what researchers discovered is that due to the bug you can also set environment variables such that you sneak in some commands into them; and the resulting Bash process will execute these commands for you. That’s wicked because you (the admin) might not want users to run such commands, or worse the Bash process might be running with additional rights in which case the sneaked in commands too will run with these additional rights.

There’s a lot of hue and cry over this and blame assigned to the GNU project and its creator Richard Stallman, but I liked this post by Andrew Auernheimer. The whole post is a must read but here’s the bit I would like to highlight (emphasis mine):

Shellshock is not a critical failure in bash. It is a critical failure in thousands of people who knew a tool so useful that they decided to deploy it far beyond its scope. A tool so resilient that it it did not fall over when everyone deployed against best practices. Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. Anyone that has untrusted input embedded within a shell script does not know what they are doing. The fact that there is a way to get bash to execute untrusted code is unsurprising. The thing that surprises me is the sheer number of developers who thought it would be otherwise in complete contrast to UNIX parables and common sense.

Spot on!

Here’s a blog post on clearing the environmental variables. More techniques are in this StackOverflow post. (I haven’t made Bash scripts for a long time now, so I just got these via a quick DuckDuckGo search. There might be other/ better techniques around!)

ps. Since posting this I came across a post on the bad code state of Bash. It doesn’t take away the fact that Bash isn’t solely to be blamed for Shellshock but I thought to mention it because I found it an interesting read.