Just another WordPress website

Ever fancied a Nagios plugin to check all the sensors on the host without any hassle? Try this one, it collects all the sensors’ input values, compares it to their thresholds (the script collects threshold values from the system by itself). Then the plugin throws a warning when the rate of input value to the threshold value is 0.8 or more (actually you can change it by the -w option), also it yells about the critical state if the rate is equal or greater than 1 (of course, you can change it too by the -c option, although I wouldn’t suggest you to do that).

Oh, I almost forgot to add: you need to have lm_sensors utiluity installed.

check_all_sensors.sh
This command will check each sensor on each chip. It will raise the critical status when the input value is equal or greater than 100% of the threshold value. If the input value is greater or equal to 80% of the threshold value, the warning state will be raised. All threshold values are being got from the system.

check_all_sensors.sh -c 90% -w 50%
It’s almost the same, but the critical rate is 90% and the warning rate is 50%.

check_all_sensors.sh -C zaloopa -S '/^Temperature [0-9]+$/' -c 90 -w 75
Only temperature sensors on the zaloopa chip will be checked. The critical status will be raised when the absolute input value is greater or equal to 90 degrees. If it’s equal or greater than 75 degrees, the warning state will be thrown.

Here’s a short and pretty self-desctriptive recipe to make your Postfix to send outgoing messages from different IP-addresses switching them on a round-robin basis.

First of all, we’ll need the list of IP-addresses in our roundabout, let’s put them to the /etc/postfix/roundabout file:

1

2

3

4

172.16.13.1

172.16.13.2

172.16.13.3

172.16.13.4

Then we’ll need the script to add IP-address aliases to our network interface. Surely, you can add them to the operating system configuration, but I’d suggest you to keep them all to the same /etc/postfix/roundabout file, so let’s put it to the /root/bin/roundabout_aliases.sh file:

If we want this script to be invoked automatically when the network interface starts, let’s create or modify the /sbin/ifup-local script (if we have a CentOS/RedHat-based system):

Shell

1

2

3

4

5

#!/bin/sh

if["$1"-eq"eth0"];then

/root/bin/roundabout_aliases.sh

fi

And now, the last, but not ever least, let’s implement the little script to change the smtp_bind_address value in our /etc/postfix/postfix.conf configuration. Let’s call it /root/bin/roundabout-postfix.sh:

You can run this script by cron or when certain event happens (e.g., when the current IP-address has been blacklisted).

And don’t forget to add something like smtp_bind_address = 0.0.0.0 to the /etc/postfix/main.cf file before to run this script for the first time, in other case it won’t find the IP-address to be changed! 🙂

At some point you may start to realize that you had foreseen all your furure life and all future events in the world around you quite a long time ago. Were there some dreams or some unexpected thoughts, even some past things that you could now consider as pretty obvious signs – all these things were quite obvious, so you somehow knew that your life will go this way or that one.

]Are you familiar with that feeling? If yes – what do you think, doesn’t that mean that you’ve made the world around you by your imagination?

I really love music! I love to listen music, to feel it, to compose my tunes and to play them. I’m pretty sure that principles of musical harmonies, chords and progressions can be applied to varions things in the universe, because the world itself seem to be organized by the same rules. Surely, I’m not an expert in physics and mathematics, but you don’t need to be a PhD to see the obvious. 🙂

I decided to try an odd experiment. I’ve divided the week to 12 equal chunks complied to 12 halftones, so one week is treated as a full octave. It could look like that:

Then I’m going to “play” various chords progressions, just by doing certain things at certain hours corresponding to certain tones. For example, “playing” a C-chord means doing some things in the following periods:

from 00:00 till 14:00 of Monday,

from 08:00 till 22:00 of Wednesday,

from 02:00 till 16:00 of Friday.

On the next week I’ll “play” some other chord, for example, an Am-chord. Then goes an F-chord. And then – a G-chord. So, some progression will be “played”.

What it gives? I don’t know yet! 🙂 I need to try and then I could tell about results.

What exactly I’ll do at these hours? I’m going to decide it. But, just kind of wondering, what would YOU do at some *magic* time periods if you knew they’re *magic*?

To be honest, I’m not keen on drawing diagrams, but today I had to spend a couple of hours to sketch this one. It was needed to illustrate Ethernet-links between elements of customer’s physical infrastructure (we’re building a virtualization cluster for them).

As you might know, Apache CloudStack can help you to build a redundant cluster, it means that you can run your virtual instances on 2 virtualization hosts, and when one host needs to be shutdown all virtual instances migrates to another host.

I hope, this chart could be helpful to people who’re going to set up a networking environment for Apache CloudStack-driven cloud. This drawing seems to be pretty self-descriptive, but feel free to ask any questions if you have some. 🙂

Sometimes you need to shut some web-services down for a while to do some maintenance works. Of course, you have warned all users about the scheduled downtime period, but what if it’s just impossible to inform all potential victims, e.g. every potential visitor of some web-site that won’t be working? It’s a good idea to take care of those people (or bots) and to let them know what’s going on and when their websites is up. It’s easy to make a web-server showing some maintenance notice, but what if you need to shut the server down completely? If it’s a single server, not a cluster, what visitors will see when you shut it down? They will wait for the page to be loaded, but a message saying that the connection is timed out will be the only reward for their patience. It would be much better to let them know that you’re apologizing for inconveniences, working hard to fix the issue and have some prognosis on when it’ll be okay.

So, let’s involve some spare web-server (supposedly, you have some, don’t you?) and make it showing some calming message for users and visitors of their web-sites. It’s quite easy when you have a spare web-server connected to the same network or vlan, there are just few simple steps that needed to be performed.

Step 1: creating the announcement page

Maybe one of your colleagues has already wrote an announcement and published it where your users can read it, didn’t they? If yes – let’s take the text for the notice from there, if not – let’s write the message by ourselves. Of course, as we need it to be formatted properly, we should add some HTML-tags.

XHTML

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

<!doctype html>

<title>Site Maintenance</title>

<style>

body {text-align:center;padding:150px;}

h1 {font-size:50px;}

body {font:20pxHelvetica,sans-serif;color:#333;}

article {display:block;text-align:left;width:650px;margin:0auto;}

a{color:#dc8100;text-decoration:none;}

a:hover {color:#333;text-decoration:none;}

</style>

<article>

<h1>We&rsquo;ll be back soon!</h1>

<div>

<p>Sorry for the inconvenience but we&rsquo;re performing some planned maintenance at the moment. If you need to you can always contact our support team by sending a message to <a href="mailto:support@tuchacloud.com"></a> or dialing +380445835583.</p>

<p>Works can take some time, but we’ll bring this website up before 4:20 of April 20th, 2015 (GMT)!</p>

<p>&mdash; The Team of <a href="https://tuchacloud.com/">TuchaCloud</a></p>

Now let’s put this page somewhere, for example to /var/www/vhosts/13.13.13.13/maintenance.html.

Step 2: configuring nginx

No, I won’t believe you don’t know how to install nginx on your operating system. So let’s suppose you’ve done it already and we only need to add the following server stanza to its configuration:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

server{

listen13.13.13.13:80default_server;

access_log/var/log/nginx/13.13.13.13-maintenance-access.log;

error_log/var/log/nginx/13.13.13.13-maintenance-error.log;

location~.*{

return503;

}

error_page503/maintenance.html;

location=/maintenance.html{

charset utf-8;# in case you'd like to use it

root/var/www/vhosts/13.13.13.13/;

break;

}

}

Step 3: interception

If the spare server is in the same IP-network with our 13.13.13.13, it’s easy to make it receive all requests intended for 13.13.13.13, just add an according alias to the network interface, for example:

1

ifconfig eth0:013.13.13.13/24

Well, that’s all! Just don’t forget to update the information on the maintenance page when you realize you won’t bring the service up in time you’ve promised! 🙂

Sometimes you have to check if some host replies on ARP “who-has” requests instead of simply pinging it. You probably need it when the host has its firewall configured to deny ICMP “echo” request (as you have probably noticed, most of hosts running Microsoft Windows Server are configured to ignore these requests) to check if the host is up. So, arping really helps, but to use it you have to look up the network interface on which you shall call for this host.

This simple script does it for you: it looks up for the corresponding network interface and calls the arping utility.