:::: MENU ::::

BG Go Further

DevOps – Systems/Network

Home

  • Jul 25 / 2018
  • 0
Linux

Automate apt update and keep current config files

When doing update on a Debian/Ubuntu server, if a package is trying to modify a config file, it’s asking for a manual choice. If you’re trying to try to automate the process, you’d probably like to get rid of that ask and keep the current config file by default.

For that, you can use that script:

The multiple options will enforce the update to keep current config and not overwrite it with the package default one.

  • Jun 04 / 2018
  • 0
Linux

Installing Oracle JRE using command line (no repo)

There is no way to easily automate deployment of Oracle JRE since there is no official repository for most of the linux distros. But there’s still a workaround to automatically download the JRE and install it locally on a server by using command lines.

Here is an example of how you can download the JRE 1.8u172 from official website for a CentOS server. You’ll have to grab the URL of the package you want to download from the website http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

First, download the package from the website by accepting the license automatically:

Then, install the package you downloaded on the server:

  • Apr 01 / 2018
  • 0
Linux, Python

Using procmail with custom python script

If you want to execute some special commands, log or make an API call when you’re receiving an email onto your server, you can easily set up this by using procmail. Procmail is designed to filter and sort emails but can make any call you want.

Here, as an example, we will set up a simple call to a python script that will read the content of the mail (headers and body) and put the information into a log file.

1. Install procmail

Depending on the OS you’re using, you should find a package pre-compiled in the common repositories.

For example, on a Debian-based:

or on a CentOS-based:

2. Build the python script you want to call to analyze the message

You now have to prepare your script you will execute when receiving an email, that will read and parse the content to log interesting information in a file.

Let’s create a script called procmail_script.py

3. Configure your user to pass the mail to your script

So that you can pass rules you want to execute when receiving an email, you need to create a file (hidden) called .procmailrc that will take place in the home directory of the user you want to use.

For example, for executing rules when receiving email to [email protected], you will have to put that file into the home dir like /home/mailuser/.procmailrc

This will perform multiple steps:

  1. Check that the mail recipient is [email protected] or [email protected]
  2. Put a copy of the email into the procmail-dir directory
  3. Pass the message to our python script procmail_script.py
  4. Discard the message if the script succeeds (remove from queue) or copy it to procmail-failed-dir if failed (so you can process it later)

4. Prepare an email and perform a testing locally

First, create a sample mail that you will use for testing in a file called procmail_test.txt:

Then, you can test it by executing procmail manually:

Now, open the file /opt/mailAnalysis.log and you should have something like:

  • Feb 12 / 2018
  • 0
Linux

Execute cron on a specific day of the month (e.g. second monday)

How to execute a cron on a specific day of the week once in the month?

This could look simple as we could think that this line in cron would do the trick:

But this would not work as the ‘2’ for checking the Tuesday will come as a OR condition, and the command would be executed from day 8 to day 14 and on every Tuesday of the month.

As a workaround for that, you can use that command:

Here is the explanation of this cron line:

Doing this check will allow to verify first that we are on the second tuesday before to execute the command. Don’t forget to add a backslash before the ‘%’ character to escape it.

  • Dec 21 / 2017
  • 0
Linux

Control services on Linux (systemV, systemd, initctl…)

On Linux, there’s many ways to control services that can run on your system. Here are the main and most known init systems that you can find on the common distros, depending on their version.

SystemV

That system is one of the oldest and one of the most common. Its init scripts are stored in /etc/init.d/

To list all the available services, you have to use that command:

To perform an action on one of those services, you will be using:

Upstart (initctl)

Upstart is a successor of SystemV scripts. It works asynchronously, and its scripts are stored in /etc/init/

To list all the available scripts, you have to use that command:

To perform an action on one of those services, you will be using:

SystemD

Its name SystemD means System Daemon. It manages daemons that can be running on a system. It’s a successor of upstart and allows a more flexible management for the services. Init scripts are stored in /etc/systemd/system/

To list all the available scripts, you have to use that command:

To perform an action on one of those services, you will be using:

SupervisorD

Finally, SupervisorD is a supervisor focusing mainly on the applications more than the system. It allows management of applications execution and control their life like you could do with system services.

To display all the applications managed by supervisord:

To control those processes, you will be using:

Pages:1234567...17›
Question ? Contact