Run docker without sudo in Fedora 25

Sometimes things get weird. One could imagine that the documentation on docker ( could be up to date. And when it comes to installation itself, it actually is.

The problem is/was that I was forced to run the docker with sudo (reasons are explained on both pages linked here, I’m not going to repeat them), and while both sites gave a solution, the -instructions did not actually work. So I googled a bit more:

According to, you’ll have to run the following two commands in order to get docker executed without sudoing.
Basically you’ll add a docker -group and add yourself to it.

$ sudo groupadd docker && sudo gpasswd -a ${USER} docker && sudo systemctl restart docker
 $ newgrp docker

What is a test tool?

KuvaIn order to really discuss something worthwhile at this blog, I’d need to know what actually is a test tool? To gather information and thoughts about the test tools will be way easier if I know what to investigate.

As I mentioned before there is bunch of text editors, as well as internal/external blogs (such as this?) that could be used as test journals, test data editors and for interpreting test data. As an addition to that post I’d really like to see a tool that combines the journaling possibility seamlessly and easily to the test tools used.

Which brings us to the variety of the tools. There is scripting tools for running and automating test cases. Formost you can use the OS -native tools to automate some part of the test process.

For example there’s shell -scripting possibilities in Windows -machines. You can easily edit the scripts that can be used in command prompt by using the notepad or whatever editor there is. The problem that I see nowadays is more or less the fact that there’s not much you can do from Windows -shell. The command variety is limited and as stated, most of the stuff you want to get done requires the actual GUI. You can, however, automate some tool -usage, e.g. java-, ant-, cvs/svn/git -commands in order to proceed with the normal, and boring, repetitious steps on testing process. You could also use Perl and Python from the prompt. 

That is much less than what linux -shell can do. Bash -scripting (ok, there’s other command line interpreters than just the bash, I know ;)) with whatever linux/unix -distribution is more simple to get done and is way much effective due to the fact that the interpreters can execute a huge variety of their own functions plus call system applications, perl– & python -interpreters etc.

I will return to both of these interfaces later on as separate blog entries (one or more per interface). They certainly deserve it. The question still remains: Can the command prompts and their interpreters be referred as test tools?

I myself think so. The thing that remains to figure out is how much we can rely on the software and tool provided by the vendor of the OS (or a GNU -cult for that matter) and how much we need to take in consideration that they have their limits and defects, too. And last, but not least, when should we start using some other test tool as the ones provided by the OS we are using when testing. And yes, there’s a slight difference if you’re testing  the software and using it’s OS provided client interface on the test target than on your workstation. Depending on how heavy processes you use on test scripting you need to consider the effect to the test target and taken measurements (CPU & memory usage, thread usage on linux etc.)