Catégorie : Mémo
10 mars 2016 /

Désactiver IPV6 sur RedHat6

1) Désactivation du service ip6tables

service ip6tables stop

chkconfig ip6tables off

2) Édition du fichier /etc/modprobe.conf

Ajout des lignes « alias net-pf-10 off » et « alias ipv6 off » à la fin du fichier

3) Création du fichier /etc/modprobe.d/ipv6.conf

Ajout de la ligne « options ipv6 disable=1 »

4) Édition du fichier /etc/sysconfig/network-scripts/ifcfg-eth0 (peut changer suivant la carte eth1 ou eth2 par exemple):

Et on y ajoute/modifie ces deux paramètres « IPV6INIT=no » et « IPV6_AUTOCONF=no »

5) Redémarrage

reboot
7 mars 2016 /

Installation d’Apache SolR 5.4

Solr (prononcé « solar ») est une plateforme logicielle de moteur de recherche s’appuyant sur la bibliothèque de recherche Lucene, créée par la Fondation Apache et distribuée et conçue sous licence libre.

Solr utilise le langage Java et est exécuté par un conteneur de servlets, comme Tomcat. Il communique avec le client à l’aide d’une interface de programmation en XML et JSON, généralement via le protocole HTTP.

Récupérer l’URL des binaires à cette adresse:

http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

Téléchargement et extraction des binaires

wget http://apache.crihan.fr/dist/lucene/solr/5.4.0/solr-5.4.0.tgz
tar -xzvf solr-5.4.0.tgz

Installation des binaires (lien symbolique, utilisateur solr, service, etc..)

cd solr-5.4.0/bin
./install_solr_service.sh /opt/solr-5.4.0.tgz
chkconfig --add solr
service solr status

Création d’un CORE SolR (ici nommé pocefl):

/opt/solr/bin/solr create -c pocefl -d basic_configs

Si cela fonctionne, vous devriez voir apparaitre dans menu déroulant « CORE Selector » afficher l’entrée « pocefl »:

 

solr
5 mars 2016 /

Calculer le nombre de jours entre deux dates

Petit mémo pour moi même.

Nombre de jours écoulés entre la date actuelle et le 10 janvier 2016:

echo $(($((`date +%s`-`date +%s --date 01/10/2016`))/86400)) jours

55 jours

Nombre de jours écoulés entre et le 10 janvier 2016 et le 10 janvier 2015:

echo $(($((`date +%s --date 01/10/2016`-`date +%s --date 01/10/2015`))/86400)) jours

365 jours

Nombre de jours écoulés entre le 10 janvier 2016 et le 1er janvier 2000:

echo $(($((`date +%s --date 01/10/2016`-`date +%s --date 01/01/2000`))/86400)) jours

5853 jours
4 mars 2016 /

Rescanner le bus SCSI

Si vous avez ajouté un nouveau stockage à une machine virtuelle en cours d’exécution (à chaud), vous ne pourrez pas le voir sans faire quelques manipulations. Notamment parce que le bus SCSI à laquelle les périphériques de stockage sont connectés, a besoin d’être réanalysé pour le rendre visible. il faut donc forcer une réanalyse du bus SCSI à chaud.

La méthode sera différente si vous avez ajouté un nouveau disque, ou si vous avez augmenté la taille d’un disque existant.

Ajout d’un nouveau disque

D’abord il faut identifier le numéro du disque avec cette commande:

grep mpt /sys/class/scsi_host/host?/proc_name

Qui doit retourner une ligne comme (où host0 est le disque concerné):

/sys/class/scsi_host/host0/proc_name:mptspi

On peut maintenant réanalyser le bus:

echo "- - -" > /sys/class/scsi_host/host0/scan

Les tirets représente tous les contrôleurs, tous les canaux et tous les LUN pour qu’ils soient scannés.

Pour aller plus vite, voici une petite boucle qui fait tout le boulot:

for i in $(ls /sys/class/scsi_host/ | awk -F 'host' '{print $2}'); do echo "- - -" > /sys/class/scsi_host/host$i/scan ; done

Augmentation d’un disque existant

Si vous connaissez le nom du périphérique du disque que vous avez élargi (par exemple, /dev/sda), alors vous pouvez simplement lancer la commande suivante pour forcer un rescan du disque. Attention, cela n’est pas fiables à 100% sur LVM avec les noyaux anciens, mais devrait fonctionner avec les noyaux récents

On commence par récupérer la liste des disques existants:

ls /sys/class/scsi_device/

0:0:0:0 2:0:0:0

Puis on rescanne le tout (sauf si vous savez lequel c’est):

echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan
echo 1 > /sys/class/scsi_device/2\:0\:0\:0/device/rescan

Vous pouvez maintenant faire mumuse avec Fdisk.
3 mars 2016 /

Fonctionnement des Alternatives

Les alternatives viennent de Debian et ont été porté sur RedHat. Elles permettent de gérer plusieurs versions d’exécutables.
On notera que Debian utilise la commande update-alternatives alors que RedHat utilise la commande alternatives.

Voici comment cela fonctionne. Des liens sont posés dans /usr/bin/ qui pointent chacun vers un autre lien dans /etc/alternatives/ qui pointe pointe enfin vers l’exécutable sélectionné par le service.

Pour expliquer cela, on va se pencher sur java.

Tout d’abord, regardons la version actuelle de java:

java -version

java version "1.7.0_95"
OpenJDK Runtime Environment (rhel-2.6.4.0.el6_7-x86_64 u95-b00)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

Ici, on s’aperçoit que l’exécutable de java se trouve ici, /usr/bin/java :

which java

Il se trouve en faites que ce n’est qu’un lien symbolique pointant sur un autre point symbolique qui lui, pointera sur l’exécutable:

ls -l /usr/bin/java

lrwxrwxrwx. 1 root root 22  3 mars  10:16 /usr/bin/java -> /etc/alternatives/java

ls -l /etc/alternatives/java

lrwxrwxrwx. 1 root root 34  3 mars  10:16 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

Pour voir les alternatives présente pour la commande java:

alternatives --config java

Qui nous donne comme retour:

Il existe 2 programmes qui fournissent « java ».
Sélection Commande
-----------------------------------------------
*+1 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
2 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :

On peut voir que la commande java pointera sur l’exécutable « /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java » par le signe + devant, l’étoile correspond au choix par défaut (option –auto).

On va maintenant installer le JDK d’oracle pour modifier l’exécutable utilisé.
Maintenant que c’est installé on refait la commande suivante:

alternatives --config java

Et sur la sortie de la commande, on peut voir qu’il y a une nouvelle entrée:

Il existe 3 programmes qui fournissent « java ».
Sélection    Commande
-----------------------------------------------
*+ 1        /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
2           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
3           /usr/java/jdk1.8.0_72/jre/bin/java
Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :3

On tape 3 pour sélectionner le JDK oracle.

On refait cette commande pour vérifier que cela à bien été pris en compte par alternatives:

alternatives --config java

Il existe 3 programmes qui fournissent « java ».
Sélection    Commande
-----------------------------------------------
*  1        /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
2           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
+3           /usr/java/jdk1.8.0_72/jre/bin/java
Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :3

Et maintenant si on redemande à java sa version:

java -version

java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)

Il peut être aussi utile de spécifier toutes les dépendances (avec l’option —slave) lier à cette même commande.
Grâce à cela, si l’on change la version de la commande java, toutes les commandes slave seront changés également.

Syntaxe pour ajouter une dépendance:

alternatives --slave <lien de la commande alternatives> <nom> <chemin de l’exécutable souhaité>

Exemple pour ajouter une dépendance:

alternatives --slave /usr/bin/rmiregistry rmiregistry /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/rmiregistry

Pour valider tout cela, on termine par un export de la variable JAVA_HOME dans son PATH, via son .bashrc (ou celui de l’utilisateur qui utilisera la commande):

JAVA_HOME=/usr/java/jdk1.8.0_72
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH