One place for hosting & domains

      Configuration

      An Introduction to Configuration Management with Ansible


      Introduction

      Configuration management is the process of handling changes to a system in a way that assures integrity over time, typically involving tools and processes that facilitate automation and observability. Even though this concept didn’t originate in the IT industry, the term is broadly used to refer to server configuration management.

      In the context of servers, configuration management is also commonly referred to as IT Automation or Server Orchestration. Both terms highlight the practical aspects of configuration management and the ability to control multiple systems from a central server.

      This guide will walk you through the benefits of using a configuration management tool to automate your server infrastructure setup, and how one such tool, Ansible, can help you with that.

      There are a number of configuration management tools available on the market, with varying levels of complexity and diverse architectural styles. Although each of these tools have their own characteristics and work in slightly different ways, they all provide the same function: make sure a system’s state matches the state described by a set of provisioning scripts.

      Many of the benefits of configuration management for servers come from the ability to define your infrastructure as code. This enables you to:

      • Use a version control system to keep track of any changes in your infrastructure
      • Reuse provisioning scripts for multiple server environments, such as development, testing, and production
      • Share provisioning scripts between coworkers to facilitate collaboration in a standardised development environment
      • Streamline the process of replicating servers, which facilitates recovery from critical errors

      Additionally, configuration management tools offer you a way to control one to hundreds of servers from a centralized location, which can dramatically improve efficiency and integrity of your server infrastructure.

      Ansible Overview

      Ansible is a modern configuration management tool that facilitates the task of setting up and maintaining remote servers, with a minimalist design intended to get users up and running quickly.

      Users write Ansible provisioning scripts in YAML, a user-friendly data serialization standard that is not tied to any particular programming language. This enables users to create sophisticated provisioning scripts more intuitively compared to similar tools in the same category.

      Ansible doesn’t require any special software to be installed on the nodes that will be managed with this tool. A control machine is set up with the Ansible software, which then communicates with the nodes via standard SSH.

      As a configuration management tool and automation framework, Ansible encapsulates all of the common features present in other tools of the same category, while still maintaining a strong focus on simplicity and performance:

      Idempotent Behavior

      Ansible keeps track of the state of resources in managed systems in order to avoid repeating tasks that were executed before. If a package was already installed, it won’t try to install it again. The objective is that after each provisioning execution the system reaches (or keeps) the desired state, even if you run it multiple times. This is what characterizes Ansible and other configuration management tools as having an idempotent behavior. When running a playbook, you’ll see the status of each task being executed and whether or not the task performed a change in the system.

      Support to Variables, Conditionals, and Loops

      When writing Ansible automation scripts, you can use variables, conditionals, and loops in order to make your automation more versatile and efficient.

      System Facts

      Ansible collects a series of detailed information about the managed nodes, such as network interfaces and operating system, and provides it as global variables called system facts. Facts can be used within playbooks to make your automation more versatile and adaptive, behaving differently depending on the system being provisioned.

      Templating System

      Ansible uses the Jinja2 Python templating system to allow for dynamic expressions and access to variables. Templates can be used to facilitate setting up configuration files and services. For instance, you can use a template to set up a new virtual host within Apache, while reusing the same template for multiple server installations.

      Support for Extensions and Modules

      Ansible comes with hundreds of built-in modules to facilitate writing automation for common systems administration tasks, such as installing packages with apt and synchronizing files with rsync, and also for dealing with popular software such as database systems (like MySQL, PostgreSQL, MongoDB, and others) and dependency management tools (such as PHP’s composer, Ruby’s gem, Node’s npm, and others). Apart from that, there are various ways in which you can extend Ansible: plugins and modules are good options when you need a custom functionality that is not present by default.

      You can also find third-party modules and plugins in the Ansible Galaxy portal.

      Getting Familiar with Ansible Concepts

      We’ll now have a look at Ansible terminology and concepts to help familiarize you with these terms as they come up throughout this series.

      Control Node

      A control node is a system where Ansible is installed and set up to connect to your server. You can have multiple control nodes, and any system capable of running Ansible can be set up as a control node, including personal computers or laptops running a Linux or Unix based operating system. For the time being, Ansible can’t be installed on Windows hosts, but you can circumvent this limitation by setting up a virtual machine that runs Linux and running Ansible from there.

      Managed Nodes

      The systems you control using Ansible are called managed nodes. Ansible requires that managed nodes are reachable via SSH, and have Python 2 (version 2.6 or higher) or Python 3 (version 3.5 or higher) installed.

      Ansible supports a variety of operating systems including Windows servers as managed nodes.

      Inventory

      An inventory file contains a list of the hosts you’ll manage using Ansible. Although Ansible typically creates a default inventory file when installed, you can use per-project inventories to have a better separation of your infrastructure and avoid running commands or playbooks on the wrong server by mistake. Static inventories are usually created as .ini files, but you can also use dynamically generated inventories written in any programming language able to return JSON.

      Tasks

      In Ansible, a task is an individual unit of work to execute on a managed node. Each action to perform is defined as a task. Tasks can be executed as a one-off action via ad-hoc commands, or included in a playbook as part of an automation script.

      Playbook

      A playbook contains an ordered list of tasks, and a few other directives to indicate which hosts are the target of that automation, whether or not to use a privilege escalation system to run those tasks, and optional sections to define variables or include files. Ansible executes tasks sequentially, and a full playbook execution is called a play. Playbooks are written in YAML format.

      Handlers

      Handlers are used to perform actions on a service, such as restarting or stopping a service that is actively running on the managed node’s system. Handlers are typically triggered by tasks, and their execution happens at the end of a play, after all tasks are finished. This way, if more than one task triggers a restart to a service, for instance, the service will only be restarted once and after all tasks are executed. Although the default handler behavior is more efficient and overall a better practice, it is also possible to force immediate handler execution if that is required by a task.

      Roles

      A role is a set of playbooks and related files organized into a predefined structure that is known by Ansible. Roles facilitate reusing and repurposing playbooks into shareable packages of granular automation for specific goals, such as installing a web server, installing a PHP environment, or setting up a MySQL server.

      Conclusion

      Ansible is a minimalist IT automation tool that has a gentle learning curve, thanks in part to its use of YAML for its provisioning scripts. It has a great number of built-in modules that can be used to abstract tasks such as installing packages and working with templates. Its simplified infrastructure requirements and accessible syntax can be a good fit for those who are getting started with configuration management.

      In the next part of this series, we’ll see how to install and get started with Ansible on an Ubuntu 20.04 server.



      Source link

      Configuration initiale de serveur avec Ubuntu 20.04


      Introduction

      Lorsque vous créez un nouveau serveur Ubuntu 20.04, vous devez effectuer quelques étapes de configuration importantes dans le cadre de la configuration de base. Ces étapes augmenteront la sécurité et la convivialité de votre serveur, et vous donneront une base solide pour les actions ultérieures.

      Étape 1 – Connexion en tant que root

      Pour vous connecter à votre serveur, vous devez connaître l’adresse IP publique de votre serveur. Vous aurez également besoin du mot de passe ou – si vous avez installé une clé SSH pour l’authentification – de la clé privée du compte de l’utilisateur root. Si vous n’êtes pas encore connecté à votre serveur, vous pouvez suivre notre guide sur Comment vous connecter à votre Droplet avec SSH, qui couvre ce processus en détail.

      Si vous n’êtes pas encore connecté à votre serveur, connectez-vous maintenant en tant qu’utilisateur root en utilisant la commande suivante (remplacez la partie surlignée de la commande par l’adresse IP publique de votre serveur) :

      Acceptez l’avertissement concernant l’authenticité de l’hôte s’il apparaît. Si vous utilisez l’authentification par mot de passe, fournissez votre mot de passe root pour vous connecter. Si vous utilisez une clé SSH qui est protégée par une phrase de passe, il se peut que vous soyez invité à entrer la phrase de passe la première fois que vous utilisez la clé à chaque session. Si c’est la première fois que vous vous connectez au serveur avec un mot de passe, vous pouvez également être invité à changer le mot de passe root.

      À propos de Root

      L’utilisateur root est l’utilisateur administratif dans un environnement Linux qui dispose de privilèges très larges. En raison des privilèges accrus du compte root, il est déconseillé de l’utiliser régulièrement. En effet, une partie du pouvoir inhérent au compte root est sa capacité à effectuer des changements très destructeurs, même par accident.

      L’étape suivante consiste à mettre en place un nouveau compte d’utilisateur avec des privilèges réduits pour une utilisation quotidienne. Plus tard, nous vous apprendrons comment obtenir des privilèges accrus uniquement lorsque vous en avez besoin.

      Étape 2 – Création d’un nouvel utilisateur

      Une fois que vous êtes connecté en tant que root, nous sommes prêts à ajouter le nouveau compte d’utilisateur. Dans le futur, nous nous connecterons à ce nouveau compte au lieu de root.

      Cet exemple crée un nouvel utilisateur appelé sammy, mais vous devez le remplacer par le nom d’utilisateur qui vous convient :

      Quelques questions vous seront posées, en commençant par le mot de passe du compte.

      Saisissez un mot de passe fort et, éventuellement, remplissez les informations complémentaires si vous le souhaitez. Ce n’est pas obligatoire et vous pouvez juste appuyer sur ENTER dans n’importe quel champ que vous souhaitez ignorer.

      Étape 3 – Attribution des privilèges administratifs

      Maintenant, nous avons un nouveau compte utilisateur avec des privilèges de compte ordinaires. Cependant, nous devons parfois effectuer des tâches administratives.

      Pour éviter d’avoir à nous déconnecter de notre utilisateur normal et à nous reconnecter en tant que compte root, nous pouvons configurer ce que l’on appelle des privilèges de super-utilisateur ou de root pour notre compte ordinaire. Cela permettra à notre utilisateur normal d’exécuter des commandes avec des privilèges administratifs en plaçant le mot sudo avant chaque commande.

      Pour ajouter ces privilèges à notre nouvel utilisateur, nous devons ajouter l’utilisateur au groupe sudo. Par défaut, sur Ubuntu 20.04, les utilisateurs qui sont membres du groupe sudo sont autorisés à utiliser la commande sudo.

      En tant que root, exécutez cette commande pour ajouter votre nouvel utilisateur au groupe sudo (remplacez le nom d’utilisateur en surbrillance par celui de votre nouvel utilisateur) :

      Maintenant, lorsque vous êtes connecté en tant qu’utilisateur régulier, vous pouvez taper sudo avant les commandes pour effectuer des actions avec des privilèges de super-utilisateur.

      Étape 4 – Mise en place un pare-feu de base

      Les serveurs Ubuntu 20.04 peuvent utiliser le pare-feu UFW pour s’assurer que seules les connexions à certains services sont autorisées. Nous pouvons très facilement mettre place un pare-feu de base en utilisant cette application.

      Remarque : si vos serveurs tournent sur DigitalOcean, vous pouvez éventuellement utiliser les pare-feux Cloud de DigitalOcean au lieu du pare-feu UFW. Nous recommandons de n’utiliser qu’un seul pare-feu à la fois pour éviter les règles contradictoires qui peuvent être difficiles à déboguer.

      Les applications peuvent enregistrer leurs profils dans UFW lors de leur installation. Ces profils permettent à UFW de gérer ces applications par nom. OpenSSH, le service qui nous permet maintenant de nous connecter à notre serveur, dispose d’un profil enregistré avec UFW.

      Vous pouvez le voir en tapant :

      Output

      Available applications: OpenSSH

      Nous devons nous assurer que le pare-feu autorise les connexions SSH afin de pouvoir nous reconnecter la prochaine fois. Nous pouvons autoriser ces connexions en tapant :

      Après quoi, nous pouvons activer le pare-feu en tapant :

      Tapez y et appuyez sur ENTER pour continuer. Vous pouvez voir que les connexions SSH sont toujours autorisées en tapant :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      Comme le pare-feu bloque actuellement toutes les connexions, sauf les connexions SSH, si vous installez et configurez des services supplémentaires, vous devrez ajuster les paramètres de pare-feu pour autoriser le trafic. Vous pouvez apprendre quelques opérations courantes UFW dans notre guide des fondamentaux UFW.

      Étape 5 – Activation de l’accès externe pour votre utilisateur ordinaire

      Maintenant que nous avons un utilisateur régulier pour un usage quotidien, nous devons nous assurer que nous pouvons SSH directement dans le compte.

      Remarque : tant que vous n’avez pas vérifié que vous pouviez vous connecter et utiliser sudo avec votre nouvel utilisateur, nous vous recommandons de rester connecté en tant que root. De cette façon, si vous avez des problèmes, vous pouvez les résoudre et apporter les changements nécessaires en tant que root. Si vous utilisez une Droplet DigitalOcean et que vous rencontrez des problèmes avec votre connexion SSH root, vous pouvez vous connecter à la Droplet en utilisant la Console DigitalOcean.

      Le processus de configuration de l’accès SSH pour votre nouvel utilisateur dépend du fait que le compte root de votre serveur utilise un mot de passe ou des clés SSH pour l’authentification.

      Si le compte root utilise l’authentification par mot de passe

      Si vous vous êtes connecté à votre compte root à l’aide d’un mot de passe, l’authentification par mot de passe est alors activée pour SSH. Vous pouvez accéder à votre nouveau compte utilisateur en ouvrant une nouvelle session de terminal et en utilisant SSH avec votre nouveau nom d’utilisateur :

      Après avoir saisi votre mot de passe d’utilisateur habituel, vous serez connecté. N’oubliez pas que si vous devez gérer une commande avec des privilèges administratifs, tapez sudo devant comme ceci :

      Votre mot de passe d’utilisateur habituel vous sera demandé lors de la première utilisation de sudo à chaque session (et périodiquement par la suite).

      Pour renforcer la sécurité de votre serveur, nous vous recommandons vivement de configurer des clés SSH plutôt que d’utiliser une authentification par mot de passe. Suivez notre guide sur la Configuration des clés SSH sur Ubuntu 20.04 pour apprendre comment configurer l’authentification par clé.

      Si le compte root utilise l’authentification par clé SSH

      Si vous vous êtes connecté à votre compte root en utilisant des clés SSH, l’authentification par mot de passe est désactivée pour SSH. Vous devrez ajouter une copie de votre clé publique locale au fichier ~/.ssh/authorized_keys du nouvel utilisateur pour vous connecter avec succès.

      Comme votre clé publique se trouve déjà dans le fichier ~/.ssh/authorized_keys du compte root sur le serveur, nous pouvons copier ce fichier et la structure des répertoires sur notre nouveau compte utilisateur dans notre session existante.

      La commande rsync représente la façon la plus simple de copier les fichiers avec la propriété et les autorisations correctes. Cela permet de copier le répertoire .ssh de l’utilisateur root, de préserver les permissions et de modifier les propriétaires de fichiers, le tout en une seule commande. Veillez à modifier les parties surlignées de la commande ci-dessous pour qu’elles correspondent à votre nom d’utilisateur habituel :

      Remarque : la commande rsync traite différemment les sources et les destinations qui se terminent par une barre oblique et celles sans barre oblique. Lorsque vous utilisez rsync ci-dessous, assurez-vous que le répertoire source (~/.ssh) ne comporte pas de barre oblique (vérifiez que vous n’utilisez pas ~/.ssh/).

      Si vous ajoutez accidentellement une barre oblique à la fin de la commande, rsync copiera le contenu du répertoire ~/.ssh du compte root dans le répertoire personnel de l’utilisateur sudo au lieu de copier toute la structure du répertoire ~/.ssh. Les fichiers se trouveront au mauvais endroit et les SSH ne seront pas en mesure de les trouver et de les utiliser.

      • rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

      Maintenant, ouvrez une nouvelle session de terminal sur vous machine locale, et utilisez le SSH avec votre nouveau nom d’utilisateur :

      Vous devez être connecté au nouveau compte utilisateur sans utiliser de mot de passe. N’oubliez pas que si vous devez gérer une commande avec des privilèges administratifs, tapez sudo devant comme ceci :

      Votre mot de passe d’utilisateur habituel vous sera demandé lors de la première utilisation de sudo à chaque session (et périodiquement par la suite).

      Que faire maintenant ?

      À ce stade, vous disposez d’une base solide pour votre serveur. Vous pouvez désormais installer tous les logiciels dont vous avez besoin sur votre serveur.



      Source link

      How To Change Redis’s Configuration from the Command Line


      Introduction

      Redis is an open-source, in-memory key-value data store. Redis has several commands that allow you to make changes to the Redis server’s configuration settings on the fly. This tutorial will go over some of these commands, and also explain how to make these configuration changes permanent.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Be aware that managed Redis databases typically do not allow users to alter the configuration file. If you’re working with a Managed Database from DigitalOcean, the commands outlined in this guide will result in errors.

      Changing Redis’s Configuration

      The commands outlined in this section will only alter the Redis server’s behavior for the duration of the current session, or until you run config rewrite which will make them permanent. You can alter the Redis configuration file directly by opening and editing it with your preferred text editor. For example, you can use nano to do so:

      • sudo nano /etc/redis/redis.conf

      Warning: The config set command is considered dangerous. By changing your Redis configuration file, it’s possible that you will cause your Redis server to behave in unexpected or undesirable ways. We recommend that you only run the config set command if you are testing out its behavior or you’re absolutely certain that you want to make changes to your Redis configuration.

      It may be in your interest to rename this command to something with a lower likelihood of being run accidentally.

      config set allows you to reconfigure Redis at runtime without having to restart the service. It uses the following syntax:

      • config set parameter value

      For example, if you wanted to change the name of the database dump file Redis will produce after you run a save command, you might run a command like the following:

      • config set "dbfilename" "new_file.rdb"

      If the configuration change is valid, the command will return OK. Otherwise it will return an error.

      Note: Not every parameter in the redis.conf file can be changed with a config set operation. For example, you cannot change the authentication password defined by the requirepass parameter.

      Making Configuration Changes Permanent

      config set does not permanently alter the Redis instance’s configuration file; it only changes Redis’s behavior at runtime. To edit redis.conf after running a config-set command and make the current session’s configuration permanent, run config rewrite:

      This command does its best to preserve the comments and overall structure of the original redis.conf file, with only minimal changes to match the settings currently used by the server.

      Like config set, if the rewrite is successful config rewrite will return OK.

      Checking Redis’s Configuration

      To read the current configuration parameters of a Redis server, run the config get command. config get takes a single argument, which can be either an exact match of a parameter used in redis.conf or a glob pattern. For example:

      Depending on your Redis configuration, this command might return:

      Output

      1) "repl-ping-slave-period" 2) "10" 3) "repl-timeout" 4) "60" 5) "repl-backlog-size" 6) "1048576" 7) "repl-backlog-ttl" 8) "3600" 9) "repl-diskless-sync-delay" 10) "5" 11) "repl-disable-tcp-nodelay" 12) "no" 13) "repl-diskless-sync" 14) "no"

      You can also return all of the configuration parameters supported by config set by running config get *.

      Conclusion

      This guide details the redis-cli commands used to make changes to a Redis server’s configuration file on the fly. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link