Obsolescence programmée par Microsoft.

Avec Windows 11, Microsoft s’apprête à rendre obsolètes des millions de PC. Soit parce que le processeur est d’une génération trop ancienne (même des processeurs i3, i5 ou i7), soit parce que pas équipé de la version 2 de la puce TPM (Trusted Platform Module). Même si Windows 10 restera supporté jusqu’en 2025 il s’agit bien d’une obsolescence programmée.

Plutôt que de jeter vos PC, jetez  Windows, et passez sous Linux.

L’interface graphique de Linux, bien que moins aboutie que Windows, a fait de gros progrès et est maintenant utilisable aussi bien à la maison qu’au bureau. Si vous cherchez une ergonomie tres proche de Windows 10 je vous recommande vivement le distribution Linux Zorin (version Core ou Lite. La version Pro, payante, est juste une version Core avec plus de logiciel installé par defaut)

Voici la liste des logiciels gratuits et open source que j’utilise et qui fonctionnent aussi bien sous Windows que Linux. Ils sont tous de qualité professionnelle.

Navigateur Internet

Sous Linux on retrouve Firefox et Chromium (la base de Google Chrome, de Microsoft Edge et aussi Opera). J'utilise Firefox dans 99% des cas.

Il y a aussi le navigateur Thor (basé sur Firefox) qui permet une navigation anonyme. (Non

Bureautique

Libre office Suite bureautique équivalente de Microsoft Office (Word, Excel, PowerPoint ...). Elle inclut donc un traitement de texte (Writer), un tableur (Calc), présentation (Impress), dessin (Draw), et un un gestionnaire de base de donnée (Base). Avec le plugin grammatical pour le français.

Si vous n'avez besoin que d'un traitement de texte il y a AbiWord.

PAO

Scribus équivalent de Adobe InDesign ou QuarkXPress ou Publishe.

Chat

Pindgin messagerie instantanée.

MULTIMÉDIA

Player audio vidéo

VLC Lecture audio, vidéo, cd, dvd.

Audio

Audacity Enregistrement et édition audio.

Photo/Image

Gimp édition et retouche d'image. L'équivalent de PhotoShop.

Darktable traitement d'image. L’équivalent de Lightroom.

Inkscape dessin vectoriel. L’équivalent de Illustrator

Animation

Synfig Animation d'images vectorielles 2D.
Blender Modélisation et animation 3D.

Vidéo

OBS Studio Capture et streaming vidéo.

ShotCut Montage vidéo. (il y aussi OpenShot mais je ne l'utilise pas, On peut aussi faire du montage avec Blender)

AviDemux Manipulation vidéo.

DÉVELOPPEMENT

Conception Électronique

KiCad Capture des schéma, Design du PCB, visualisation 3D, simulation avec ngspice.
GNU Radio Traitement du signal.

 Programmation

Qt IDE et librairie C++ (gratuit si utilisé pour developper des logiciel open source)
Code::Blocks C++ IDE (mises à jour rares)
Eclipse IDE multi langages (je ne l'utilise plus depuis très longtemps)

VSCodium C'est exactement VScode mais sans la telemetrie (espionage) de Microsoft.
C'est comme Chromium et Chrome.

 Maths

GeoGebra Géométrie 2D/3D
Octave en gros l'équivalent de MathLab

Pour être honnête l'editeur de texte Notepad++ est le seul logiciels Windows qui me manque sous Linux. Oui, je sais, il y a pléthore d'éditeurs sous Linux. (Note: Notepad++ fonctionne dans Wine, l'emulateur Windows sous Linux.)

Bien sur, tout le monde n'a pas les mêmes besoins que moi !
Voici donc quelques listes de logiciels libres pour Linux.

• Frama libre liste de logiciels libres.
• SILL Socle Interministériel de Logiciels Libres. (Liste (pdf) valide en decembre 2023)
  
• LinuxLink Le portail des applications Linux (anglais)
  

 

Restorer le boot de Windows après installation de CentOS

Il semble que dans certaines configurations RedHat et Centos n’aiment pas cohabiter sur la même machine avec Windows… En effet si sur une machine qui boote déjà sous Windows on installe en plus (Dual Boot) RH/Centos 7 ou 8 on risque de perdre l’option  pour booter sous Windows.

Heureusement il est facile de rattraper cela à la main.
Voici comment.

Depuis une session root exécuter ces 5 étapes:

1) Avec fdisk trouver la partition de boot

# fdisk -l
Device     Boot     Start        End   Sectors   Size Id Type
/dev/sda1  *         2048    1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2         1026048  501093039 500066992 238.5G  7 HPFS/NTFS/exFAT
/dev/sda3       501094400  503191551   2097152     1G 83 Linux
/dev/sda4       503191552 1000214527 497022976   237G  5 Extended
/dev/sda5       503193600 1000214527 497020928   237G 8e Linux LVM

(Il s'agit d'une table de partition  au format MBR)

Repérer la partition qui a une étoile (*) dans sa colonne Boot. Ici il s’agit de la partition mixte UEFI + CSM qui servait à booter  Windows, mais que RH/Centos a ignoré. (Il parait que Fedora n'a pas ce problème).

Ici c’est la partition sda1 (partition 1 du disque sda). Notez que cette partition est formatée en NTFS alors que pour du pur UEFI seul FAT32 est possible.

2) Avec blkid trouver l’identifiant de cette partition de boot

# blkid /dev/sda1
/dev/sda1: UUID="B4FC7F32FC7EEE4C" TYPE="ntfs" PARTUUID="646e83a4-01"

Noter la valeur de UUID (sans les quotes).  Ici c'est B4FC7F32FC7EEE4C

3) Modifier la configuration de grub2

# vim /etc/grub.d/grub40_custom

Ne surtout pas toucher aux 5 lignes déjà en place, et ajouter le menuentry comme indiqué ci-dessous.
Dans ce qui suit:
- hd0 c’est sda
- msdos1 c’est la partition 1
- Remplacer B4FC7F32FC7EEE4C  par le UUID de votre partition bootable affiché par blkid.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows 10" {
  insmod part_msdos
  insmod ntfs
  set root='(hd0,msdos1)'
  search --no-floppy --fs-uuid --set=root B4FC7F32FC7EEE4C
  chainloader +1
}


4) Re-construite la configuration de grub :

# grub2-mkconfig -o /boot/grub2/grub.cfg


5) Rebooter

 # reboot

Vous devriez avoir une option de menu « Windows 10 » et vous devriez pouvoir booter sur Windows.

IMPORTANT:

Bien souvent les problèmes de ce type (OS installé mais non bootable) viennent de l'inadéquation entre 

- la configuration de la procédure de boot utilisée par le bios (Legacy ou UEFI+CSM ou UEFI)

- le partitionnement du disque (MBR ou GPT)

- le mode d’installation du nouvel l'OS (Legacy, UEFI), qui découle souvent de comment l'installateur a été démarré.

Les live CD linux sont alors très utiles pour analyser la configuration du disque.

Débuter avec Windows Subsytem for Linux (WSL)

Débuter avec Windows Subsytem for Linux  (WSL)

Il faut bien comprendre que le but de Microsoft en proposant WSL est de faire bénéficier Windows des possibilités de Linux et non l’inverse. Il n’est pas question pour Microsoft d’aider les développeurs d’applications Linux mais seulement d’aider les développeurs d’applications Windows.

Au début WSL s’appelait  “Bash for Windows”. Tout est dit.

WSL n'est pas cygwin puisque pour qu'une application Linux fonctionne avec cygwin elle doit être re-compilée. Avec WSL c'est exactement l’application Linux, au bit prés, qui s’exécute sous Windows 10.

WSL est un simulateur du kernel Linux, pas un émulateur. Son impact cpu, mémoire et disque est bien plus faible qu'une machine virtuelle. Les deux systèmes partagent le même espace disque et les deux systèmes voient les fichiers de l'autres. Ceci permet à Windows d’exécuter les applications Linux, et a Linux de lire et écrire les fichiers Windows. Les réciproques ne sont pas vraies.
Voir les avertissements plus bas.

1) Activer WSL

Ouvrir une ligne de commande PowerShell en tant qu’administrateur (Run as administrator) et taper la commande :
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Ou bien, exécuter OptionalFeatures.exe et sélectionner "Windows Subsystem for Linux":

Dans tous le cas il faut rebooter pour que l’installation de WSL se fasse.

2) Installer l’application ‘Ubuntu’ depuis Microsoft Store.

Maintenant que l'on a le simulateur de kernel en place on peut installer des distributions linux adaptées à ce contexte. La plus aboutie de ces distributions est Ubuntu puisque Microsoft et Canonical ont travailler main dans la main pour concevoir WSL.

En prenant l’application nommée 'Ubuntu' vous aurez la version la plus récente. Il existe cependant des applications Ubuntu XX.Y pour des versions spécifiques de Ubuntu: 18.04 LTS et 16.04 LTS 

A la première exécution vous devez créer un utilisateur Linux. Il est sans lien avec l'utilisateur Windows.

Important: L'installation n'est valable que pour l'utilisateur courant. Cette installation n'est pas partagée.

3) Configurer

- Le fichier /etc/resolv.conf est un lien vers un fichier généré à chaque exécution de WLS. Si son contenu est vide ou ne vous convient pas il faut
  - Supprimer le fichier /etc/resolv.conf (le lien en fait)
  - Le re-créer en tant que fichier normal avec vos infos
nameserver 8.8.8.8

- Mettre à jour la distribution
$ sudo apt-get update
$ sudo apt-get upgrade

$ uname -a

Linux PCDEV09 4.4.0-17763-Microsoft #253-Microsoft Mon Dec 31 17:49:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

Un   top ou  ps faux vous montrera que l’environnement n'est pas réel.

- Pour pouvoir compiler du code C/C++ il faut installer la suite gcc:

$ sudo apt-get install build-essential

$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

- L’émulation de terminal peut poser des problèmes. Par défaut TERM=xterm-256color. En cas de problèmes essayer d’autres émulations comme TERM=vt100 ou TERM=screen

4) Fichiers Linux

- Le nom du répertoire où se trouvent les fichiers Linux est désigné par la clé de registre :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{xxxx-xxxx-xxxx-xx}\BasePath

Pour les versions de Windows 10 depuis 2018 ce chemin ressemble à: C:\Users\YourUserName\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs

Notez (à nouveau) que tout est dans le profils de l'utilisateur, ce n'est pas une installation partagée.

- En faisant shift + bouton droit sur un répertoire vous aurez l’option « Open Linux shell here »

- Depuis la ligne de commande Windows, grâce à wsl.exe, on peut exécuter des commandes Linux

5) AVERTISSEMENT

* Il ne faut pas éditer les fichiers Linux depuis une application Windows (comme notepad++).

Par contre l’inverse est possible : On peut manipuler les fichiers Windows depuis les applications Linux. Les disques Windows sont d’ailleurs automatiquement montés sur  /mnt/c  /mnt/d

* L’environnement fournit par Microsoft WSL (malgré son nom) N'EST PAS LINUX. Il n'y a pas de noyau Linux, mais seulement une simulation (pas une émulation) des appels systèmes Il est impératif d'effectuer des tests sur de véritables distrib Linux car il y a une foule de petites différences, de limitations et d’incompatibilités.

- Environ 30% des appels systèmes implémentés échouent.
- Plus de 150 appels systèmes ne sont pas implémentés.

Voir le détails des tests faits par Microsoft en avril 2017.

* La liste des problèmes montre bien que ce c'est un environnement de développement fragile et en aucun cas un environnement de production.

* D'un autre coté, des choses non supportées par Microsoft WSL fonctionnent pas trop mal. Par exemple, on peut faire fonctionner, tant bien que mal, des application graphiques comme Firefox, ou même Xfce avec, coté Windows, un serveur X comme VcXsrv. Le principaux problèmes viennent de D-Bus et des drivers vidéo et audio.

Plus d'info:
https://blogs.msdn.microsoft.com/wsl/ (n’est plus actif mais très intéressant)
https://blogs.msdn.microsoft.com/commandline/ (actif)
https://github.com/Microsoft/WSL (ce n'est pas le code)

Software Collections - SCLs

UPDATE 2020:

SCL n'est utilisé que pour RHEL/CentOS 5/6/7

Depuis la version 8 SCL est remplacé par les 'Modules Stream'. Un Stream étant une sorte de  dépôt virtuel dans le dépôt principal.

mod_perl 2.0.9

La version très attendue de mod_perl 2.0.9 fonctionnera avec pratiquement toutes les versions du serveur http 2.0.x, 2.2.x et 2.4.x d'Apache. C'est le support de 2.4.x qui est attendu depuis des années ! Ceci est d'autant plus important que CentOS 7 n'existe qu'en 64 bits et ne fournit que Apache 2.4. Pour utiliser mod_perl2 il fallait rester à Centos 6.x :-(

[ UPDATE: La version officielle de mod_perl 2.0.9 est disponible depuis le 18/juin/2015 ]
[ Mais en attendant les packages officiels la procédure ci-dessous reste valide ]

Steve Hay, le principal développer de mod_perl2, affirme que l'on est en phase de test ...
En attendant un package voici pour les impatients comment tester sous Linux (dans mon cas Centos 7) cette version bêta de mod_perl 2.0.9 (il y a encore quelques problèmes sous Windows, et Perl 5.22 n'est pas supporté).

# Il faut avoir de quoi compiler et bien-sur apache et ses fichiers de développement
yum group install "Development Tools"
yum install httpd httpd-devel

# Depuis le 19/juin/2015 on peut récupérer les sources ici
http://apache.org/dist/perl/

# Sinon on peut récupérer les source via SVN
svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/ mod_perl-2.0.9

# Il ne faut pas etre root sinon le 'make test' echoue
# On prepare un Makefile, on compile, on teste
# Vérifier que /usr/bin/apxs existe  (il vient du package httpd-devel)
# MP_TRACE=1 permet ensuite d'utiliser dans httpd.conf la directive PerlTrace
cd mod_perl-2.0.9
perl Makefile.PL MP_APXS=/usr/bin/apxs MP_TRACE=1
make
make test

# Si tout se passe bien on doit avoir une fin qui ressemble à
All tests successful.
Result: PASS

# Pour cette dernière commande il faut être root
su
make install

La commande suivante indique où sont les modules (mod_xxxxx.so) que Apache charge
/usr/bin/apxs -q LIBEXECDIR

C’est là que doit se trouver le nouveau module mod_perl.so qui est chargé dans la config du serveur web avec

LoadModule perl_module modules/mod_perl.so

Voir ce précédent ce post pour la configuration,

Repository EPEL & REMI

Les packages de certaines applications ne sont pas disponibles sur les repositories configurés par défaut avec la distribution. Il faut alors aller les cherche sur d'autres repositories qu'il faut configurer soit même.

Par exemple, avec Centos / EL, le repository "EPEL" (Extra Packages for Enterprise Linux) ou les repositories de Remi Collet ne sont pas connus. Pour les installer il y a deux méthodes :  la facile et la moins facile !

Version facile (que pour EPEL)
On va essayer de voir si dans les repositories déjà configurés il y en a un qui contient la définition du repository EPEL.
On tape la commande :   yum search epel
On regarde dans ce qui s'affiche si le package existe et si oui, son nom exact.
Si le package existe on l'installe en général avec :  yum install epel-release
Si rien n’est trouvé passer à la version moins facile.

Version moins facile
Si la définition de EPEL n'est pas dans un package disponible il faut la télécharger puis l'installer à la main.
On va sur http://dl.fedoraproject.org/pub/epel
On choisit la version centos/el : 4, 5, 6, 7
On choisit l'architecture : i386, x86_64, ppc64
Si une liste de répertoires (a, b, c…) se présente on va dans le répertoire "e"
On cherche un package avec un nom du type  epel-release-X-Y.noarch.rpm  (le X et le Y étant variables)
On le télécharge sur la machine à configurer avec une commande du type (ici pour centos 7, 64 bits)
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpmEnfin on l'installe avec la commande : yum install epel-release-X-Y.rpm


Pour les repositories de Remy Collet il n'y a que la version moins facile qui marche, sachant qu'avec centos il faut déjà avoir installer EPEL. Le processus reste le même :
- trouver le rpm d'auto configuration (détails pour centos, fedora ici: http://rpms.famillecollet.com/)
- le télécharger (wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm)
- l'installer (yum install remi-release-7.rpm)


ATTENTION: Quand on a beaucoup de repositories configurés il peut y avoir des conflits. Quand on fait un yum update ou un yum install il faut bien vérifier le repository source.

Par défaut les repositories de Remi sont désactivés. Deux méthodes pour les activer :

- Editer le fichier /etc/yum.repos.d/remi.repo et y mettre le/les "enable=0" à "enable=1".


- Activer le bon repository au cas par cas. Par exemple :

yum --enablerepo=remi install nom-du-package 

yum --enablerepo=remi update  nom-du-package 

Pour voir les repositories actifs : yum repolist
Pour voir les repositories desactivés : yum repolist disabled

mod_perl startup

Une fois que l'on a un couple {Apache2 + mod_perl2} adapté il faut faire une peu de configuration. Voici comment mettre en place mod_perl2  et verifier que tout marche.

Rappel: il faut au minimum mod_perl 2.0.9 pour Apache 2.4.x

1) Configurer Apache normalement pour qu'il affiche le fichier index.html de votre répertoire htdocs. Ceci est toujours utile de pouvoir servir des pages statiques sans faire appel à Perl.
NB: Inutile de configurer la partie cgi-bin, ou php ;-)


2) Quand l’étape #1 fonctionne ajouter cette simple ligne à la fin du fichier de configuration principale de apache (httpd.conf)

    Include conf/mod_perl2.conf

Ainsi on ne touchera plus au fichier de configuration principal, on travaillera sur mod_perl2.conf, dont voici le contenu de départ :

LoadModule perl_module modules/mod_perl.so

# la ligne suivante n'est utile que si on a installé le module
# Apache2::Request qui utilise APR::Request qui utilise libapreq2
#   yum install libapreq2
#   cpanm       APR::Request
#   cpanm       Apache2::Request
# (le but étant de ne plus utiliser CGI.pm)
LoadModule apreq_module modules/mod_apreq2.so

PerlPostConfigRequire /path/to/myCode/startup.pl
PerlOptions -SetupEnv
 
<Location /hello>
   SetHandler perl-script
   PerlResponseHandler Hello
   PerlOptions +ParseHeaders
</Location>

a) On charge le module mod_perl (c'est lui qui importe Perl dans Apache)
b) On désigne un script Perl à exécuter au démarrage de Perl (voir plus bas)
c) On désactive l'importation de l'environnement dans le contexte de chaque requête (plus sûr et plus rapide)
d) On annonce que l'url /hello sera traitée par le module Perl Hello.pm
Ce module gèrera lui-même les headers et il sera exécuté en tant que "perl-script" (bien que ce soit forcement un module)


3) Le module Hello.pm est très simple à écrire et à comprendre :

package Hello;
use strict;
use warnings;

sub handler {  # Le nom de la fonction est imposé
    print "Content-type: text/plain\n\n";
    print "Hello at : ". localtime . "\n";
    return Apache2::Const::OK;
}
1;

On le stocke dans /path/to/myCode/Hello.pm



4) Le script startup.pl ressemble à ceci

use lib qw(/path/to/myCode);   # voir "Attention #2" plus bas

use ModPerl::Util ();
use ModPerl::Registry ();
 
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile => ':common';

use APR::Table ();
use APR::Const -compile => ':common';

1;

Le plus important dans ce fichier est la première ligne car elle indique où seront vos modules Perl chargés de réponde aux requêtes. Les autres "use" préchargent des modules d'usage courant ce qui evitera de répéter ces "use" dans chaque module Perl.


Si vous devez ouvrir un accès à une base de donnée ce sera aussi dans ce script en utilisant Apache::DBI Exemple pour Postgresql

use Apache::DBI;
Apache::DBI->connect_on_init("dbi:Pg:dbname=myDB", 
  "myUSR", 
  "myPASS",
  {AutoCommit => 1, RaiseError => 1, PrintError => 1} 
);
Apache::DBI->setPingTimeOut("dbi:Pg:dbname=myDB", 30);

ATTENTION #1: Pour accéder à la base de donnée dans un module (handler) il faudra utiliser le classique $dbh = DBI->connect(...) Mais il faudra que tous les paramètres de connect() soit exactement les mêmes que ceux passé à connect_on_init();


ATTENTION #2: Dans le contexte de mod_perl2 "use FindBin;" ne marche pas comme espéré.

En effet $FindBin::Bin donne le point de démarrage du serveur Apache, pas celui de startup.pl.

A la place il faudra faire ce genre de gymnastique:

use File::Basename;
our $PERLBASE;
BEGIN {
  $PERLBASE = dirname( __FILE__ );
}
use lib $PERLBASE;


Dans tous les modules (handlers) vous pourrez accéder simplement à $::PERLBASE

proxy ssh

Il arrive souvent que les machines d’un réseau de développement  ne soit pas accessibles depuis l’extérieur à l’exception d’une machine jouant le rôle de porte d’entrée (frontdoor.mydomain.com).

Pour accéder depuis l’extérieur aux machines internes on établit depuis son poste externe une première connexion ssh avec  frontdoor.mydomain.com puis, de là, on établit une seconde connexion ssh vers la machine interne sur laquelle on veut travailler. Donc une opération en deux temps.

On peut simplifier ceci en établissant des ‘tunnels’ entre le frontdoor et les machines internes qui vont faire en sorte qu’une connexion sur le port 8001 du frontdoor donne directement accès à dev1, qu’une connexion sur le port 8002 du frontdoor donne directement accès à dev2 etc…

On établit donc un tunnel entre le port 8001 du frontdoor et le port 22 de dev,
puis un tunnel entre le port 8002 du frontdoor et le port 22 de dev2 etc…

Pour cela on se connecte sur le frontdoor et on exécute par exemple ces 2  commandes pour établir deux tunnels :

ssh -N -f -L 8001:localhost:22 devusr1@dev1.mydomain.com

ssh -N -f -L 8002:localhost:22 devusr2@dev2.mydomain.com

Chaque commande va  demander le mot passe pour se connecter  avec le user voulu à la machine interne qui sera l’extrémité ‘22’ du tunnel. Si la clé publique du user de frontdoor  est acceptée par le devusr coté machine de développement aucun mot de passe n’est demandé.  (Cette possibilité est très utilise si on veut automatiser l’établissement et la supervision de ces tunnels)

Ceci fait on peut fermer la session avec le frontdoor, les tunnels resteront actifs.

Maintenant, pour se connecter sur dev1 depuis l’extérieur on tape

    ssh –p 8001 usr@frontdoor.mydomaine.com

et bien sur la commande suivante vous loguera sur dev2

    ssh –p 8002 usr@frontdoor.mydomaine.com

La demande de mot de passe sera pour l'utilisateur 'usr' sur frontdoor. Là aussi on peut aussi utiliser un système de clés.

NOTE

Du point de vue de la machine interne (dev1 ou dev2) vous êtes un utilisateur connecté depuis 127.0.0.1 pas depuis frontdoor. Facile à vérifier avec la commande ‘who ‘

Il y a plein d'autre utilisations de cette technique du 'Local Port Forwarding'. Mais attention au firewall qui peut se trouver devant le frontdoor et qui pourrait bloquer l’accès aux ports d'entré du tunnel (8001, 8002 dans notre exemple)

Il y aussi des variantes de cette technique :

- Remote port forwarding (on établit le tunnel dans l'autre sens en utilisant ssh -R à la place de ssh -L)

- Dynamic port forwarding (plus complexe et nécessite la configuration SOCKS)

Postgresql 9 + Centos 7

Un rapide mémo sur l'installation de Postgresql 9.x sur centos7 avec un PGDATA personnalisé.

1: Installer postgresql

yum install postgresql postgresql-server

2: Créer le home directory de postgresql

mkdir /home/postgres
chown postgres:postgres /home/postgres

3: Initialiser le repertoire où postgresql va stocker ses bases de données et autres meta-data

su postgres
cd
initdb /home/postgres/data
exit

4: Configuration systemd

Ce qui suit a pour but de ne pas modifier la version d'origine de  /usr/lib/systemd/system/postgresql.service

La solution proposé par postgresql est d'utiliser .include mais il faut savoir que cette méthode  est obsolète (https://lists.fedoraproject.org/pipermail/devel/2014-July/200804.html)

Créer le fichier  /etc/systemd/system/postgresql.service
avec ces 3 lignes (respectez la case)

.include /usr/lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/home/postgres/data

Si nécessaire ajouter la ligne suivante pour aussi changer le port

Environment=PGPORT=2345

5: Démarrer le serveur postgresql à la main

systemctl daemon-reload                (important)

systemctl start postgresql

verifier les log

systemctl status postgresql

6: Si tout va bien activer le démarrage automatique

systemctl enable postgresql 

Reste à configurer /home/postgres/pg_hba.conf
Voir ces 3 posts:

• pg_hba (part1)  accès local avec/sans mot de passe
• pg_hba (part2)  accès via le réseau
• pg_hba + SSL   cryptage

7: Installer les extensions

yum install postgresql-contrib

Toutes les extensions vont dans /usr/share/pgsql/extension
Pour installer une extension (par exemple adminpack) dans une base il faut se se connecter à cette base avec le user postgres et taper

CREATE EXTENSION adminpack;



8: Installer les .h


yum install postgresql-devel

Necessaire si on veut compiler un driver pour perl php ruby etc...
Par exemple quand un programme d’installation a besoin de libpq-fe.h

APACHE 2.2 et Centos 7

Il y a de nombreuses raisons pour vouloir encore utiliser Apache 2.2 et de ne pas migrer vers Apache 2.4. L'une d'entre elles est l'utilisation de mod_perl2 qui ne fonctionne toujours pas correctement avec Apache 2.4.
Malheureusement l’installation d’Apache 2.2 sur centos 7 ne peut pas se faire avec yum car seule la version 2.4 est disponible. Voici comment procéder pour compiler Apache 2.2 et mod_perl2 sur centos 7 et mettre en place les fichiers nécessaires au  démarrage de httpd 2.2 avec systemctl (aka systemd).


1) Il faut avoir les outils de développements

yum group install "Development Tools"


2) Puis on va sur http://www.us.apache.org/dist/httpd/ et on repère la version la plus récente de httpd-2.2
puis on la télécharge et on la décompresse :

wget http://www.us.apache.org/dist/httpd/httpd-2.2.29.tar.gz
tar xvf httpd-2.2.29.tar.gz


On compile et installe apache 2.2.x
On utilise --prefix pour ne pas installer apache par dessus l’éventuelle version 'officielle'.

cd httpd-2.2.29
./configure --prefix=/path/to/apache22
make
make install

On démarre  apache (risque de conflit si une autre version utilise le port 80)

/path/to/apache22/bin/apachectl -k start

Et avec le browser ont doit avoir le classique « It works »


3) Pour compiler mod_perl et tester il y a plus de préparatifs ET une correction de bug:
(peut être certains des packages ci-dessous sont déjà sur votre machine)

yum install perl-ExtUtils-Embed
yum install perl-libwww-perl
yum install perl-CGI
yum install perl-Test-Simple
yum install perl-Linux-Pid
yum install expat
cd /usr/lib64
ln -s libexpat.so.1.x.0 libexpat.so.0

(Adaptez le version de libexpat à votre cas. Pour moi c'est 1.6.0)


4) On va sur http://apache.org/dist/perl/ repérer la dernière version de mod_perl2
puis on la télécharge et on la décompresse :

wget http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
tar xvf mod_perl-2.0.8.tar.gz
cd mod_perl-2.0.8

 
ATTENTION #1: Dans le fichier t/api/err_headers_out.t il faut remplacer à deux endroits:

     if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
  if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;

Enfin on peut exécuter la séquence standard :

perl Makefile.PL MP_APXS=/path/to/apache22/bin/apxs
make
make test
make install


NB: Le fait d'avoir installé apache 2.2.x dans un répertoire spécifique n'implique pas que toute la partie mod_perl aille aussi dans ce répertoire. Une partie ira dans apache/include et apache/module mais les modules perl iront dans /usr/local/lib64/perl5


5) Quand on compile soit même Apache on ne bénéficie pas des petits plus apportés par un package comme par exemple la mise en place du script de démarrage. Voici donc comment installer cela avec un Linux, comme centos os 7, qui utilise systemd (sytemctrl) à la place les scripts init.d. On va créer deux fichiers :

a) Le premier est /etc/sysconfig/httpd22 
Il sert à configurer l’environnement et les paramètres à passer au daemon httpd.

OPTIONS="-f /path/to/conf/httpd22.conf"
LANG=C


b) Le second /etc/systemd/system/httpd22.service
Il est utilisé par systemd pour exécuter les commandes start/reload/stop et il fait référence au fichier créé ci-dessus.

[Unit]
Description=The Apache HTTP Server 2.2.x
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
KillMode=none
PIDFile=/path/to/apache22/logs/httpd.pid


EnvironmentFile=/etc/sysconfig/httpd22

ExecStart=/path/to/apache22/bin/httpd  -DFOREGROUND  $OPTIONS
ExecStop=/path/to/apache22/bin/httpd   -k stop       $OPTIONS
ExecReload=/path/to/apache22/bin/httpd -k restart    $OPTIONS

[Install]
WantedBy=multi-user.target


NB: C'est apache qui gère le fichier .pid. Par défaut il est avec les logs de apache, mais on peut changer sa position avec la directive PidFile. Dans ce cas il faut adapter le PIDFile=... dans notre fichier httpd22.service


Après avoir créé ces deux fichiers (et avoir un fichier httpd.conf correct) faire

systemctl daemon-reload
systemctl start httpd22
systemctl status httpd22

Si tout est ok rendre le démarrage automatique

systemctl enable httpd22

Ces 2 fichiers cohabitent très bien avec ceux de httpd 2.4. Si les eux doivent s’exécuter en même temps il faut faire en sorte qu'ils n'utilisent pas le même port en changeant le paramètre "listen 80" dans la config de l'un ou de l'autre.

ATTENTION #2: Quand on se compile un programme (comme ici Apache 2.2) avec ses propres répertoires d'installation on se retrouve avec des fichiers .h ou des librairies à des endroits non standards. Ceci peut poser problèmes par la suite.

Par exemple, si pour utiliser mod_perl on veut installer la librairies Apache2::Request, qui utilise APR::Request, qui est une interface avec la librairie C libapreq2.so, il faudra que le programme d'installation de APR::Request trouve libapreq2.so dans le répertoire ou on a installé notre version d'Apache.

La solution la plus élégante est d'ajouter un fichier apache22.conf dans le répertoire /etc/ld.so.conf.d/ . Ce fichier contiendra juste une ligne du type:

/path/to/apache22/lib

Après quoi on exécute ldconfig pour que ce nouveau chemin soit pris en compte.


Enjoy  2.2 ;-)