Blog

The terraform import command allows you to import into HashiCorp Terraform resources that already existed previously in the provider we are working with, in this case AWS. However, it only allows you to import those records one by one, with one run of terraform import at a time. This, apart from being extremely tedious, in some situations becomes impractical. This is the case for the records of a Route53 DNS zone. The task can become unmanageable if we have multiple DNS zones, each one with tens or hundreds of records. In this article I offer you a bash script that will allow you to import in Terraform all the records of a Route53 DNS zone in a matter of seconds or a few minutes.

The .xsession-errors file is where the X Window system logs all errors that occur within the Linux graphical environment. All desktop environments, whether Gnome, KDE, Cinnamon, XFCE, LXDE, etc., and all lighter window managers like FVWM, IceWM or Window Maker make use of the X Window system. Therefore any graphical application running on your computer can cause that error messages are written to the .xsession-errors file, reason why it can grow wildly until reaching very big sizes of tens of GB or even hundreds if your disk capacity allows it.

It is usually easy to know which process or processes are writing to a given file in Linux, since we either know its origin and its nature beforehand (for example the Apache access_log), or we can easily find it out with the fuser or lsof commands. However, sometimes it will happen that although we know the role and purpose of a file, there are so many applications accesing it simultaneously that it is very difficult to know which of them is the one that reads/writes the most or does so in a precise moment. Knowing this would be very useful to learn for example why a log file is growing excessively or which application is making an abusive use of system resources, either by mistake or intentionally.

Since the key combination Control+s is widely used as a shortcut to save files in GUI applications such as text editors, image editors, web browsers, etc. sometimes you are betrayed by your subconscious when you are working from the Linux command line and you use that same key combination when you are for example editing a Vim document when trying to save it. Then you notice that no key answers, the shell is locked and you can no longer do anything else in it.  Even worse, you get a cold sweat because you can’t continue editing your document and you can’t save the changes.

One of the most common and tedious tasks of a sysadmin is to prevent file systems become completely full, because when a server runs out of space the consequences are unpredictable. Depending on how you structured the root file system and if it is divided into different partitions or volumes, those consequences will be more or less severe, but in any case undesirable.

In any case it is always better to be safe than sorry, so use tools that perform automatic log rotation as logrotate and custom scripts to monitor and conduct periodic emptying actions to prevent file systems to get full. However, still using these prevention methods it is for sure it will be many times when you will have to act manually to troubleshoot problems.

Less than two days after it was detected a vulnerability (CVE-2014-6271) that affects the Bash shell on Linux, Unix and Mac OS X, a patch was released that solves this issue only partially, which forced to report a new vulnerability (CVE-2014-7169) still pending. This issue has quickly gained a simple name by which it will be remembered for a long time: Shellshock or Shell Shock.

The bug was detected by Stephane Chazelas, a Unix and Linux system administrator from Akamai when he found out that Bash erroneously interpreted as a command wich only was data within a variable when entering a specially crafted string in the command line. As a result, everything coming after that string was executed as a command or function by Bash. This allows any attacker to execute commands on your server arbitrarily. It’s true that this can not be done as root, but there are many harmful actions that can be done without root privileges.

The simplest and shortest method to measure the number of processors present on a Linux box, which is also widely extended as it’s part of coreutils is:

Another way to get the same result which also allows us to obtain additional information from our processor are the lscpu command:

Or we can examine the cpuinfo file from /proc filesystem:

There are many additional details about these processors in /proc/cpuinfo file, including the CPU model and number of cores: