IT should always be that easy ...

Blog - page 2

Get to know your linux-system - Step 1

In this lesson I wanna show you a command, that gives you with just two keystrokes a load of useful information about a linux system.

What you can expect

In this lessen I will talk about

  • The one command I always type in at first after logging in into a system.
  • The current time and the timezone your system is configured with
  • How to find out, if your system is currently overloaded or not
  • If there are other users active on the system and what they are doing

(Yes - linux is a multi-user environment. And therefore it’s often very useful to see, what other users are doing on the system at the time you are working there.)

read more »

What the heck are they using xargs for?

You know how to connect two tools via stdin and stdout? Great!

  • But how about the commands that don’t read from it’s input-datastream?
  • How to interconnect commands together, that naturally won’t fit?

This is, where xargs comes into play.

And because I know your time is precious - I’ve created this really short video-training … only 7:32 min :-)

In this video you will also discover …

  • the one big philosophy you can expect from most linux-tools

  • which commands can be interconnected directly

  • and the only two parameters you need for controlling the behavior of xargs most of the time.

So sit back, watch and enjoy …

If your shell always get’s you wrong - quote the right way

Here is another question that often comes up by my students and clients:

” … how can I solve the problem with these special-characters? The shell always gets me wrong …”

The fast and simple answer to this is: You have to quote!

… and you have to to it the right way.

But let’s start from the beginning:

As you know, there are characters at the command line, that simply has special meanings for the shell.

You use them for instance, for referencing the content of a variable (“$”)

robert@demo:~$ echo Hello $NAME

… or for redirecting a datatream to a file (“>”):

robert@demo:~$ ls -l /etc > $TEMPFILE

But everytime you wanna use these special characters without their special meaning for the shell, you have to take special care about it.

(huh - three times “special” in one sentence. this must be really special ;-) )

So instead of writing

robert@demo:~$ echo Buy this book for $9 now
Buy this book for now

you have to write something like

robert@demo:~$ echo 'Buy this book for $9 now'
Buy this book for $9 now

In this way, the shell won’t try to interprete $9 as a variable. Instead it would take the “$”-sign just like what it is: a $-sign.

This mechanism is called “quoting” and technically explained for instance in depth in the Bash-Documentation.

Let me show you, how the quoting works. And your shell never gets you wrong again … ;-)

read more »

SSH port-forwarding from within the Google Cloud Shell

Google provides a very useful tool especially for those I’m calling “cloud workers”: the Cloud Shell. This gives you access to a linux-shell for just whatever you do usually in a linux shell - directly from your browser.

From time to time I use the cloud shell as a starting-point to connect via ssh to other systems. Recently I noticed that tcp-port-forwarding via the outgoing ssh-connections doesn’t work out of the box: When trying to establish a port-forwarding (ssh user@targethost -L 8080:127.0.0.1:8080) the following error occurs:

bind: Cannot assign requested address

… and the port-forwarding doesn’t work.

The reason for this is simple - as always as you know it: The ssh-client tries to bind to the local ipv6-port. This is not supported in the cloud shell and therefore fails.

read more »

How to delete command lines from the bash history

And suddenly it happened again: I’ve typed sensitive information (at this time it was a password) into the command line.

And the shell kindly saved the typed commandline into its history. This way it wants to help me if I need the same command line later again. Great!

But what happens, if the system I’m working on isn’t under my full control? Imagine I’ve worked on a customer system …

Or what if someone later looks over my shoulder while I’m searching through my history?

The sensitive line needs to be removed!

  • What’s the best way for doing this?
  • How do we protect ourselves from this happening again later?

Generally speaking: You have two options to remove command lines from the bash history: first, by using the history command and second, by editing ~/.bash_history directly.

read more »
×