Test based work

I tried out KodeKloud Engineer this morning, and I was favorably impressed. This is a good tool for practicing real world skills. And I, like many others it seems, stumbled at the first challenge of making a script executable.

The challenge seemed simple enough, and I, like many others, fulfilled the task to the letter; But I failed. Why? Because the script wasn’t “executable to all users”. That was the key instruction. How to make it executable to all users? I wasn’t sure, so I had to try several solutions and test them by trying to execute as the logged in user.

This got me thinking, the evidence that I had succeeded at the task was the simple test of trying to execute the script. But this highlights that what is needed to ensure that pretty much any DevOps work is done is a test. Usually this testing is ad-hoc, answering the question: “Does it look right?” or “Does it solve this one narrow use-case that I have in mind now?”. This skill of “test-driven-DevOps” doesn’t seem to be acknowledged or taught commonly. Going back to the example of execution of a script, if I were to make a more elaborate test, I might do something like this (in pseudocode):

For all the users on the system, attempt to execute the script.

You could easily make a test like this in Python; Simply read out the users from configuration files on the system, and attempt to execute the script in a sandboxed shell as each user.

So seemingly, finishing this task or any task, would benefit from submitting a test that my supervisor (or any other person) might use to verify my work. This also has the advantage of documenting what was done, and what was expected; Similar to how development tests are documentation.

This might be an interesting method of training going forward: Not only completing what appears to be a task with some piece of software, but also generating a test that can be used to verify the task is complete; and provide evidence for the same.

Hi @peter.mattingly

Making a script executable to all users is simply this

chmod +x 

followed by the filename

If you (the logged in user) own the file, it will be executable to all users. If you don’t own it then use sudo.

There’s no need to have a script to test for all users on the system, it’s simply understanding how the permissions work

The available permissions are a bitmask

  • r - read
  • w - write
  • x - execute

and there are 3 permission groups assigned to each file

  • owner
  • group
  • all (i.e. any user known to the system)

So, if you do ls -l on the file and you see 3 occurrences of x in the left column, then anyone can execute.

Caveat: To truly be able to execute a file, read permission is also required, otherwise you can’t actually read the file from disk in the first place to execute it.

Please see the documentation for chmod for a fuller explanation.