Septiembre 28

Creating and Using your own Repository

Custom repositories leverage package management solutions, which were designed to provide a convenient, efficient means to install software on many computers. This topic describes how to create a local package repository and then how to direct machines in your environment to use that repository.

To create a repository, you simply put the RPMs or DEBs you want to host in one directory. Then complete tasks with createrepo or reprepro, and then publish the resulting repository on a website.

Step 1: Download Installation Files

Creating a custom repository requires RPM or DEB files. If you already have these files, proceed to the next step. Otherwise, download the appropriate versions of Cloudera Manager. Available versions can be found at Cloudera Manager Version and Download Information.

Step 2: Prepare the RPM or DEB Files

Move the RPMs or DEBs to a directory that you will use for your repository. Suppose you have downloaded the Oracle JDK and want to host it internally to ease installation on various machines. After you have unpacked the RPMs or DEBs, you would have a collection of those files in your directory. For example, for a CentOS system, you might have:

$ls -l
total 79392
-rw-r--r-- 1 user group 70530937 Mar 13 14:42 jdk-6u24-linux-amd64.rpm
-rw-r--r-- 1 user group   499375 Mar 13 14:42 sun-javadb-client-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group    14627 Mar 13 14:42 sun-javadb-common-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4080625 Mar 13 14:42 sun-javadb-core-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   969861 Mar 13 14:42 sun-javadb-demo-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4865183 Mar 13 14:42 sun-javadb-docs-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   201273 Mar 13 14:42 sun-javadb-javadoc-10.6.2-1.1.i386.rpm

Step 3: Create a Repository

You can using createrepo or reprepro to create a repository. If you don’t have createrepo or reprepro installed, install it using the following command:

  • RedHat/CentOS: yum install createrepo
  • SLES: zypper install createrepo
  • Debian/Ubuntu: apt-get install reprepro

Creating a CentOS/RHEL/Oracle/SLES Repository

Having expanded the RPMs to a directory and ensured createrepo is installed, you can now create a repository. When you run createrepo in the directory that contains the files you will use to create a repo, the program creates an extra directory with some XML files that describing the repository. For example:

$ createrepo .
7/7 - sun-javadb-javadoc-10.6.2-1.1.i386.rpm                                    
Saving Primary metadata
Saving file lists metadata
Saving other metadata
$ ls -l
total 79400
-rw-r--r-- 1 user group 70530937 Mar 13 14:42 jdk-6u24-linux-amd64.rpm
drwxr-xr-x 2 user group     4096 Mar 13 14:45 repodata/
-rw-r--r-- 1 user group   499375 Mar 13 14:42 sun-javadb-client-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group    14627 Mar 13 14:42 sun-javadb-common-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4080625 Mar 13 14:42 sun-javadb-core-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   969861 Mar 13 14:42 sun-javadb-demo-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4865183 Mar 13 14:42 sun-javadb-docs-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   201273 Mar 13 14:42 sun-javadb-javadoc-10.6.2-1.1.i386.rpm
$ ls -l repodata/
total 64
-rw-r--r-- 1 user group 32997 Mar 13 14:45 filelists.xml.gz
-rw-r--r-- 1 user group   482 Mar 13 14:45 other.xml.gz
-rw-r--r-- 1 user group  2429 Mar 13 14:45 primary.xml.gz
-rw-r--r-- 1 user group   951 Mar 13 14:45 repomd.xml

After this command completes, the specified RPMs have been added to your private repository.

  Note:

Over time, you may need to install multiple versions Cloudera software. To achieve this, you may need to update repository information. Do not create a situation where there are multiple repo files that package management tools could use to install Cloudera software. Either overwrite existing repo files with the new information or create a new repo file and delete the old one. If your machines have multiple repo files, installations may not complete as expected.

Creating a Debian/Ubuntu Repository

Having expanded the DEBs to a directory and ensured reprepro is installed, you can now create a repository.

To create a Debian/Ubuntu repository:

Create a directory that will host the repository and creating a configuration directory and file. The repo directory can have any location and name. The configuration directory must be named conf and be at the root level of the repository directory you create. For example:

$ mkdir /tmp/repo
$ mkdir /tmp/repo/conf

Create a configuration file that contains basic information about the repository. For example, after creating such a file, you could check its contents as follows:

$ cat /tmp/repo/conf/distributions
Origin: Cloudera
Label: Cloudera
Suite: stable
Codename: cloudera
Version: 0.1
Architectures: i386 amd64 source
Components: contrib
Description: Cloudera

Run reprepro on DEB files. If you had expanded the DEBs to the /tmp/repo/ directory, you might use the following command:

$ find /tmp/repo -name \*.deb -exec reprepro -Vb repo includedeb cloudera {} \;

After this command completes, the specified DEBs have been added to your private repository.

Step 4: Install a Web Server

The repository is typically hosted using HTTP on a machine inside your network. If you already have a web server in your organization, you can move the repository directory, which will include both the RPMs and the repodata/ subdirectory, to some a location hosted by the web server. If you are able to use an existing web server, then note the URL and skip to Modifying Clients to Find Repos.

An easy web server to install is the Apache HTTPD.

To install Apache HTTPD:

Install Apache HTTPD. You may need to respond to some prompts to confirm you want to complete the installation. For RedHat/CentOS:

[root@localhost yum.repos.d]$ yum install httpd

For SLES:

[root@localhost zypp]$ zypper install httpd

For Debian/Ubuntu:

[root@localhost apt]$ apt-get install httpd

Start Apache HTTPD: For RedHat

[root@localhost tmp]$  service httpd start
Starting httpd:                                            [  OK  ]

For SLES

[root@localhost tmp]$ service apache2 start
Starting httpd:                                            [  OK  ]

For Debian/Ubuntu

[root@localhost tmp]$ service apache2 start
Starting httpd:                                            [  OK  ]

Step 5: Publish Repository Files

Move your files to the web server directory and modify file permissions. For example, you might use the following commands:

[root@localhost tmp]$ mv /tmp/repo /var/www/html
[root@localhost tmp]$ chmod -R ugo+rX /var/www/html/repo

After moving files and changing permissions, visit http://<hostname>:80/repo to verify that you see an index of files. Note that Apache may have been configured to not show indexes, which is also acceptable.

Modifying Clients to Find Repos

Having established the repository, modify the clients so they find the repository.

For RedHat/CentOS systems: Create files on client systems with the following information and format, where hostname is the name of the web server you created in the previous step:

[myrepo]
name=myrepo
baseurl=http://hostname/repo
enabled=1
gpgcheck=0

See man yum.conf for more details. Put that file into /etc/yum.repos.d/myrepo.repo on all of your host machines to enable them to find the packages that you are hosting.

For SLES systems: Use the zypper utility to update client system repo information by issuing the following command:

$ zypper addrepo http://hostname/repo alias

For Debian/Ubuntu systems: Add a new list file to /etc/apt/sources.list.d/ on client systems. For example, you might create the file /etc/apt/sources.list.d/my-private-cloudera-repo.list. In that file, create an entry to your newly created repository. For example:

$ cat /etc/apt/sources.list.d/my-private-cloudera-repo.list
deb http://hostname/repo cloudera

After adding your .list file, ensure apt-get uses the latest information by issuing the following command:

$ sudo apt-get update

After completing these steps, you have established the environment necessary to install a previous version of Cloudera Manager or install Cloudera Manager to machines that are not connected to the Internet. Proceed with the installation process, being sure to target the newly created repository with your package management tool.

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Creating and Using your own Repository
Septiembre 5

Centralisez vos logs avec Rsyslog

I. Présentation

La centralisation des logs de plusieurs serveurs sur un seul peut présenter un grand intérêt au niveau de la sécurité au sein d’un système d’information. En effet, il est plus facile pour des outils d’analyse de logs de comparer, lire et scanner des fichiers se situant sur un seul et unique serveur plutôt que de le faire à distance ou via des agents distants. De plus en cas de crash serveur, vous serez capable de récupérer les erreurs et actions menées sur votre serveur avant que celui-ci ne crash, facilitant ainsi la remise en activité de celui-ci et sa sécurisation future.

Par défaut sur la plupart des Linux modernes, l’outil de gestion des logs est Rsyslog, c’est celui-ci que nous allons utiliser dans ce tutoriel. Nous travaillerons sur deux machines sous Debian 7, l’un faisant office de serveur, l’autre de « client » qui enverra ses logs sur le serveur. Dans les deux cas, le fichier de configuration à modifier est toujours « /etc/rsyslog.conf« . On peut néanmoins  en mettre dans « /etc/rsyslog.d/ » puis faire un « include » dans le fichier de configuration principale pour importer.

 

II. Configuration du serveur

Pour le serveur, il faut simplement paramétrer le serveur pour qu’il accepte les logs venant de l’extérieur en ouvrant le port adéquate, on va pour l’instant par soucis de simplicité ouvrir le port UDP (514). Pour cela, on va décommenter les deux lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

On pourra alors redémarrer le service rsyslog :

service rsyslog restart

Pour vérifier que notre serveur est bien à l’écoute, on peut effectuer la commande suivante :

netstat -npul

On verra alors notre port 514 ouvert en UDP :

serveur rsyslog linux

Port 514 ouvert en UDP sur notre serveur Rsyslog

III. Configuration du client

Au niveau du client, il faut aller dans ce même fichier puis, pour rediriger tous les logs sur le serveur, ajouter cette ligne à la fin du fichier :

*.* @IP_SERVER:514

Note : Le « @ » doit figurer dans la ligne

On va alors redémarrer notre service rsyslog :

service rsyslog restart

Puis on pourra générer des logs (redémarrer un service quelconque par exemple) et aller voir s’ils figurent sur le serveur rsyslog. Par défaut comme nous l’avons fait, les logs des clients se situeront dans le même fichier que les logs du serveur donc par exemple dans le « /var/log/syslog » du serveur. Vous verrez simplement que le nom de l’hôte ayant généré la ligne de log n’est pas celui du serveur mais celui du client.

III TCP/UDP

Nous avons précédemment configuré notre client et notre serveur pour échanger en utilisant le protocole de transport (couche 4) UDP. Brièvement, UDP permet un échange unique pour transmettre un paquet, c’est un protocole qui ne cherche pas à se synchroniser, à suivre l’état des paquets ou des échanges entre deux éléments actifs. Au contraire, TCP va chercher à savoir pour chaque paquet si celui-ci a bien été reçu par le correspondant, ce qui engendre des paquets supplémentaires par rapport à UDP. TCP est ainsi capable de savoir si un échange ou une information n’a pas été reçu et de la retransmettre au besoin, ce que ne fait pas UDP.

Tout cela pour souligner que dans notre cas, les échanges TCP ont un désavantage qu’il faut prendre en compte par rapport à l’UDP. En effet, le TCP va générer plus d’échanges (et donc de consommation de ressource) par rapport à UDP mais va vous assurer que les informations reçu le sont dans le totalité. Il y a donc un choix à faire qui dépend de vos ressources disponibles et du nombre de client et d’informations gérées par votre serveur. Pour mettre les échanges en mode TCP, il faut recommenter ces lignes dans le fichier de configuration serveur, à noter que les deux méthodes peuvent cohabiter si on les met sur des ports différents, par exemple :

Serveur Rsyslog

Configuration du serveur Rsyslog pour recevoir les logs des clients en UDP sur le port 514 et en TCP sur le port 1514

Sinon, il faudra commenter les deux lignes supérieures. Côté client, il faut ajouter cette ligne dans la configuration pour que les échanges s’effectuent en TCP :

*.* @@IP_SERVEUR:1514

Note : Les @@ doivent figurer dans la ligne de commande, le fait qu’il y en ai deux indique que les échanges se feront en TCP.

On peut laisser également deux lignes pour indiquer que les logs seront envoyés une fois en TCP et une fois en UDP. Cela présente peu d’intérêt mais permet de comprendre que l’on peut également envoyer nos logs sur plusieurs serveurs différents si on change l’IP d’une des deux lignes. On va ensuite redémarrer le serveur ainsi que le client si besoin :

service rsyslog restart

 IV. Rediriger ou copier selon la facilitie ou la priorité

Sous Linux quand on parle de gestion de logs, les facilites sont des catégories dans lesquelles les logs vont se « ranger » afin de mieux les archiver et les trier. Parmi ces facilites, on retrouve par exemple :

  • auth : Utilisé pour des évènements concernant la sécurité ou l’authentification à travers des applications d’accès (type SSH)
  • authpriv : Utilisé pour les messages relatifs au contrôle d’accès
  • daemon : Utilisé par les différents processus systèmes et d’application
  • kern : Utilisé pour les messages concernant le kernel
  • mail :  Utilisé pour les évènements des services mail
  • user : Facilitie par défaut quand aucune n’est spécifiée
  • local7 : Utilisé pour les messages du boot
  • * : Désigne toutes les facilities, par soucis de simplicité c’est ce que nous avons spécifié lors de notre première règle de redirection des logs un peu plus haut
  • none : Désigne aucune facilites

En plus de ces facilites, nous retrouvons pour chaque facilities un niveau de gravité (appelé Priorité) qui va du plus grave à la simple information :

  • Emerg : Urgence, système inutilisable
  • Alert : Alerte. Intervention immédiate nécessaire
  • Crit : Erreur système critique
  • Err : Erreur de fonctionnement
  • Warning :  Avertissement
  • Notice : Évènement normaux devant être signalé
  • Info : Pour information
  • Debug : Message de debogage

On retrouve alors plusieurs façons de spécifier les logs qui nous intéressent et donc ceux que l’on va rediriger. Par exemple si l’on chercher à rediriger vers notre serveur de logs 192.168.19.145 uniquement les messages critiques et supérieurs concernant les mails sur le port UDP 514, on ajoutera la ligne suivante :

mail.err @192.168.19.145:514

On peut également rediriger tous les logs mails :

mail.* @192.168.19.145:514

On peut également saisir en une ligne plusieurs types de facilities et de priorité, on trouve pas exemple dans le fichier de configuration par défaut des lignes comme celles-ci :

*.=debug;\
       auth,authpriv.none;\
       news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       cron,daemon.none;\
       mail,news.none          -/var/log/messages

On voit ici que toutes les priorités debug sont redirigées vers le fichier « /var/log/debug » et que toutes les prioritésinfo,notice et warn seront dans « /var/log/messages« . Pour que ces filtres soient redirigés vers le serveur de logs, il suffit de spécifier l’IP du serveur ainsi que son port comme fait plus haut à la place du nom du fichier.

V. Rediriger les logs vers un dossier/fichier par host

On peut également, pour faciliter la hiérarchisation et l’archivage de nos logs lorsque l’on a un grand nombre de client Rsyslog utiliser une arborescence avec un dossier/fichier par hôte plutôt que de mettre tous les logs dans le même fichier que le serveur de logs. On va pour cela utiliser une template que nous mettrons après le bloc « RULES » dans le fichier de configuration du serveur :

$template syslog,"/var/log/clients/%fromhost%/syslog.log"

On va ensuite appliquer ce template à tous les logs entrants :

*.* ?syslog

Il nous suffira ensuite de redémarrer notre service rsyslog puis de générer des logs depuis les clients. On se retrouvera alors avec un dossier « /var/log/clients/ » contenant un dossier par IP/nom client et contenant respectivement un fichier « syslog.log » avec les logs de chaque client respectif, ce qui simplifie la recherche d’information dans les logs d’un client précis

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Centralisez vos logs avec Rsyslog