Choix socket PostgreSQL

Lorsque le client Postgresql se trouve sur la même machine que le serveur, les communications entre le client et le serveur s'effectuent soit via la boucle locale, soit le plus souvent à travers un fichier de type spécial appelé socket.
L'emplacement du socket peut se choisir au niveau du fichier postgresql.conf. Supposons que ce fichier contienne la sentence
unix_socket_directory='/run/postgresql'
Vérifions quel est alors le contenu du dossier /run/postgresql:

Nous constatons que le dossier /run/postgresql possède les droits rwxrwsr-x (2775 en octal).
Il s'y trouve un fichier caché de type socket: celui avec la lettre s figurant en tête de la ligne le concernant.
Le choix de l'emplacement du socket tel que formulé dans le fichier postgresql.conf est inopérant pour une connexion vers le serveur postgresql depuis libreoffice base à l'aide du pilote natif sdbc.
Ainsi il se peut que la tentative de connexion échoue avec un message du genre:

could not connect to server: Aucun fichier ou dossier de ce type 
Is the server running locally and accepting 
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Ici le fichier socket est recherché dans /tmp alors qu'il se trouve dans /run/postgresql.
Une solution consite à modifier postgresql.conf de manière à ce que le socket soit effectivement dans /tmp.
Cependant il ne s'agit pas vraiment d'une bonne idée: en effet /tmp jouit de droits particuliers de type rwxrwxrwt (1777 en octal):

La lettre t qui figure en dernière position dans la chaîne des droits indique que le sticky bit est sur on, ce qui signifie que si chacun peut écrire dans le dossier, il ne peut modifier que les fichiers qui lui appartiennent.
Or il arrive que si postgresql.conf demande que le socket se trouve dans /tmp, alors les droits de /tmp soient modifiés de manière inopportune.
Une meilleure solution consiste à utiliser la variable d'environnement PGHOST.
Celle-ci peut avoir deux significations.
La plus évidente est que PGHOST contienne le nom du host, comme ici:

Du fait que le nom du host est précisé, psql se connecte non pas à l'aide du fichier socket, mais via la boucle locale:

Mais si la valeur de PGHOST commence par une barre oblique (/), elle indique alors l'emplacement du socket:

Voilà la solution: il suffit de s'arranger pour que PGHOST existe et contienne la bonne valeur, par exemple en plaçant dans /etc/profile.d un fichier postgresql.sh contenant:

export PGHOST=/run/postgresql

Ubuntu 12.10 et libreoffice base

La version 12.10 d'Ubuntu souffre du même mal que la version précédente: impossible dans libreoffice base d'exécuter un rapport réalisé avec ORB (Oracle Report Builder).
Rien de changé. On tombe sur le même message d'erreur que précédemment:

Mais cette fois la solution présentée dans ce billet conduit tout droit au crash.

Nous allons passer au plan B: ne plus utiliser la version packagée par Ubuntu et la remplacer par celle téléchargeable sur le site de libreoffice. 

EDIT : voir une autre solution en fin de billet

Donc nous téléchargeons les fichiers:

LibO_3.6.3_Linux_x86-64_install-deb_en-US.tar.gz

LibO_3.6.3_Linux_x86-64_langpack-deb_fr.tar.gz

LibO_3.6.3_Linux_x86-64_helppack-deb_fr.tar.gz

correspondant à notre architecture.

Et puis nous procédons depuis le dossier de téléchargement:

toto@rigel:~/Downloads$ sudo apt-get remove libreoffice* 

toto@rigel:~/Downloads$ tar xzvf LibO_3.6.3_Linux_x86-64_install-deb_en-US.tar.gz 
toto@rigel:~/Downloads$ tar xzvf LibO_3.6.3_Linux_x86-64_langpack-deb_fr.tar.gz 
toto@rigel:~/Downloads$ tar xzvf LibO_3.6.3_Linux_x86-64_helppack-deb_fr.tar.gz 
toto@rigel:~/Downloads$ cd LibO_3.6.3.2_Linux_x86-64_install-deb_en-US/DEBS/ 
toto@rigel:~/Downloads$ sudo dpkg -i *.deb 
toto@rigel:~/Downloads$ cd desktop-integration/ 
toto@rigel:~/Downloads$ sudo dpkg -i *.deb 
toto@rigel:~/Downloads$ cd ../../../LibO_3.6.3.2_Linux_x86-64_langpack-deb_fr/DEBS/ 
toto@rigel:~/Downloads$ sudo dpkg -i *.deb 
toto@rigel:~/Downloads$ cd ../../LibO_3.6.3.2_Linux_x86-64_helppack-deb_fr/DEBS 
toto@rigel:~/Downloads$ sudo dpkg -i *.deb

Et voilà!
L'extension ORB est déjà installée avec le paquet
libobasis3.6-extension-report-builder_3.6.3.2-2_amd64.deb
de même que le pilote sdbc pour une connexion à postgresql
libobasis3.6-postgresql-sdbc_3.6.3.2-2_amd64.deb
On ne doit plus s'occuper de rien de ce côté là: cool!
Il ne reste plus qu'à tenter l'exécution du fameux rapport.
Si nous travaillons avec la base de données intégrée à libreoffice, tout est OK.
Essayons maintenant avec une base de données postgresql.
Tout d'abord se connecter.
Aie:

Ça commence bien!

La réponse à la question posée

Is the server running locally and accepting

connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

est nécessairement positive puisque avec la version Ubuntu de libreoffice la connexion s'effectuait sans problèmes.

Du moins c'est ce que nous pensions mais avec la version Ubuntu de libreoffice le message en cas de problème aurait été:

Is the server running locally and accepting

connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Et donc en fait la réponse est négative.

Pour que le socket qui convient soit utilisé, il suffit de remplacer dans le fichier /etc/postgresql/9.1/main/postgresql.conf

unix_socket_directory = '/var/run/postgresql'  

par

unix_socket_directory = '/tmp'  

et puis de redémarrer le serveur.

De la sorte tout est OK et le rapport s'exécute sans problèmes.

(EDIT: voir une meilleure solution ici.)

Il se peut que l'on ne souhaite pas changer l'emplacement du socket. Dans ce cas,  une façon de contourner le problème consiste à modifier les paramètres de connexion en ajoutant host=rigel à l'URL de la base de données (alors que ce n'est pas nécessaire puisque nous sommes sur la machine où tourne le serveur) de manière à forcer le passage par la boucle locale:

Cette fois nous recevons le message:

C'est normal car nous ne passons plus par le Unix domain socket et d'après le contenu du fichier /etc/postgresql/9.1/main/pg_hba.conf un mot de passe est nécessaire pour une connexion via la boucle locale:

# "local" is for Unix domain socket connections only
local   all             titine                                  peer map=map01
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5

Pour avoir l'opportunité de fournir un mot de passe, il suffit de cocher "Mot de passe requis".
Attention, il s'agit d'un mot de passe postgresql et non pas d'un mot de passe système.
Bien évidement, de nouveau tout fonctionne nickel et nous avons le plaisir de voir s'afficher à l'écran un magnifique rapport.

EDIT:
Une autre possibilité consiste à installer le dépôt 'libreoffice' qui permet actuellement d'avoir directement une solution fonctionnelle sans qu'il soit nécessaire de télécharger les paquets depuis le site de libreoffice.
Les commandes à exécuter sont:

toto@rigel:~$ sudo add-apt-repository ppa:libreoffice/ppa

toto@rigel:~$ sudo apt-get update

toto@rigel:~$ sudo apt-get dist-upgrade

Les fichiers dont l'absence rendait impossible la lecture des rapports, à savoir les fichiers

.../program/librptlo.so
.../program/librptuilo.so
.../program/librptxmllo.so

sont fournis avec le paquet libreoffice-report-builder-bin qui devra donc être installé avec le paquet libreoffice-report-builder.

Clef de secours (seconde partie)

Suivant les indications figurant dans le billet Clef de secours, nous avons rendu une clef usb bootable en installant dans son secteur d'amorce un chargeur grub qui pointe vers un dossier grub situé sur cette même clef.

Dans ce dossier se trouve un fichier de configuration grub.cfg contenant par exemple:

search --no-floppy --label --set=root Ubuntu 
chainloader +1 
boot

Si tout fonctionne bien, booter via la clef est transparent et le menu qui surgit est celui du fichier de configuration utilisé par le chargeur grub dont la partie initiale se trouve sur le VBR (Volume Boot Record) de la première partition trouvée dont le label est "Ubuntu".
Dans le cas contraire, si cela se passe mal, il existe diverses possibilités. L'une d'elles consiste à ce que l'on atterrisse directement dans un shell grub.
Nous sommes alors à la tête d'un mini-système d'exploitation et nous pouvons lancer au niveau de ce shell grub un certain nombre de commandes, dont la commande set qui renvoie la liste de différentes variables d'environnement avec leur valeur.
Examinant l'output de cette commande nous y trouvons quelque chose comme:

prefix=(hd0,msdos1)/grub
root=hd1,msdos3

Cela montre que l'exécution de la commande search a été couronnée de succès car au démarrage la valeur de la variable root est fixée à partir de celle de la valeur prefix.
En fait la variable prefix indique à grub où se trouvent les modules et les fichiers images (*.img) dont il a besoin pour fonctionner: dans le dossier grub de la partition 1 de la clef usb (qui est considérée comme hd0 puisqu'on a booté dessus).
Puisque search a bien fonctionné, la raison de l'échec du lancement du système linux est a chercher ailleurs: le VBR désigné par la commande chainloader ne contient pas de grub, ou celui-ci est inopérant.
Sans doute grub n'a-t-il jamais été installé sur ce VBR?

La commande multiboot.
Mais pas de problèmes: il n'est pas nécessaire de procéder à cette installation. Pour charger le grub du système linux que nous souhaitons démarrer, il suffit de saisir dans notre shell grub les commandes:

grub> multiboot /grub/i386-pc/core.img 
grub> boot

Ceci implique bien sûr que le label Ubuntu désigne une partition qui sera montée en /boot.
Si Ubuntu désigne la partition racine et qu'aucune partition n'est montée en /boot les commandes à saisir sont:

grub> multiboot /boot/grub/i386-pc/core.img 
grub> boot

Dans les deux cas, le chemin vers core.img n'est pas nécessairement celui indiqué ici. Mais comme la complétion fonctionne très bien, il est aisé de vérifier si on est sur la bonne voie où pas.
Une autre possibilité si cela se passe mal dès le départ est que l'on soit finalement renvoyé vers le chargeur principal. Mais normalement si nous utilisons la clef de secours c'est justement parce que le chargeur principal ne nous permet plus d'amorcer notre système linux. Le désastre étant provoqué par la commande boot figurant dans le grub.cfg de la clef, nous la supprimons avant une nouvelle tentative. Nous atterrissons cette fois dans un shell grub.
L'output de la commande set donne:

prefix=(hd0,msdos1)/grub 
root=hd0,msdos0

La variable root est restée inchangée! La commande search n'a rien donné: aucune partition trouvée avec le label indiqué (Ubuntu dans notre exemple). Il importe avant de poursuivre de donner à la variable root la valeur qui convient, soit directement, par exemple:

grub> set root=(hd1,3)

soit en lançant une nouvelle commande search adaptée.
Évidemment pour savoir quelle est la valeur à attribuer à root, il faut avoir un minimum de connaissance sur la structure du système linux que l'on veut amorcer: quelles sont les partitions utilisées?
Si nous fixons nous-même directement la valeur de root, il peut être utile de vérifier que nous sommes au bon endroit  à l'aide de la commande

grub> ls /

Ici nous vérifions que nous sommes bien sur la partition /boot d'un système Fedora 17 avant de saisir les commandes permettant de charger le grub de ce système:

Si la commande ls / retourne des choses du genre etc/ boot/ home/ ..., cela signifie que nous sommes sur la partition racine d'un système.
Il convient alors d'exécuter la commande ls /boot. Si cette dernière commande ne retourne rien, cela signifie que notre système fonctionne avec en plus de la partition racine, une partition à monter en /boot.

Notons que l'emploi de la commande multiboot n'est pas réservé à une utilisation dans un shell grub: elle peut aussi être utilisée dans un fichier grub.cfg.

La commande configfile.
Une alternative à la commande multiboot est l'utilisation de la commande configfile:

grub> configfile /grub/grub.cfg

Cette commande provoque l'affichage du même menu que celui obtenu avec la commande multiboot. La différence est que cette fois le grub du système linux (dont les fichiers img et mod se trouvent sur le disque dur) n'est pas chargé. On reste dans le même grub (celui de la clef), mais on lui demande d'utiliser le fichier de configuration dont le nom absolu est (hd1,3)/boot/grub (si la variable root vaut hd1,3)

Amorçage en ligne de commande.
Supposons maintenant que notre système linux ne comprenne aucun chargeur où que celui-ci est inopérant.
Impossible d'utiliser la commande multiboot (ou configfile).
Mais rien n'est perdu.
Quelques commandes tapées dans notre shell grub (où placées dans le grub.cfg) suffisent à amorcer le système:

grub> set root=(hd1,3) 
grub> linux /vmlinuz-3.5.0-17-generic root=LABEL=u-root ro
grub> initrd /initrd-3.5.0-generic 
grub> boot

Il est important de ne pas confondre la variable root de la ligne 1 qui se rapporte à la partition où se trouve le noyau (ici vmlinuz-3.5.0-17-generic) avec l'option root de la commande linux qui indique au noyau quelle est la partition racine.

Notons que grâce à la complétion il n'est pas nécessaire de connaître de connaître le nom exact des fichiers vmlinuz et initrd.
Il est cependant utile de connaître le label de la partition racine.
Rappelons que la commande blkid exécutée en root (par exemple depuis un live CD)  fournit tous les renseignements nécessaires.
Signalons enfin que si aucune partition n'est à monter dans /boot, la variable root désigne alors la partition racine puisque c'est elle qui contient le noyau. Mais malgré tout il faut encore indiquer au noyau quelle est la partition racine.
Dans ce cas les commandes à saisir seraient par exemple:

grub> set root=(hd1,3)
grub> linux /boot/vmlinuz-3.5.0-17-generic root=LABEL=Ubuntu ro
grub> initrd /boot/initrd-3.5.0-generic
grub> boot

Linux sans angoisse

Au moment de passer à l'acte, une angoisse insoutenable étreint soudain le néophyte.

Comme à chaque tentative, la même question lancinante assaille son esprit, encore et encore:

« Et si je perdais mon accès à windows? »

Mais cette fois, il ne renoncera pas!

Non, il ne renoncera pas à installer linux à côté de windows, sur le même disque dur.

Il ne renoncera pas car il a déjà tout préparé.

Dans windows, il a libéré de l'espace, plus précisément créé de l'espace non alloué pour pouvoir installer linux.

De plus, comme il est super angoissé, il a décidé de ne pas écraser le chargeur de windows. Il a déjà tout prévu pour pouvoir amorcer linux avec ce chargeur.

Il se souvient de chaque étape.

Tout d'abord, ouvrir l'invite de commande windows en mode Administrateur.

Ensuite sauvegarder le fichier bcd d'origine avec la commande:

bcdedit /export C:\bcdorig

De la sorte on peut facilement revenir à la situation antérieure avec:

bcdedit /import C:\bcdorig

L'étape suivante consiste à créer une entrée dans bcd:

bcdedit /create /d "[Linux]" /application BOOTSECTOR

La commande envoie en retour (avec un message de réussite) l'identifiant de l'entrée nouvellement créée.
En effectuer une copie de manière à pouvoir l'utiliser pour la suite.

Étape suivante: indiquer au système sur quelle partition va se trouver le code servant à amorcer linux en donnant comme argument de la commande l'identifiant de l'entrée:

bcdedit /set {299c4c80-0a1b-11e2-ab33-f46d04d5218a} device partition=C:

Ensuite il faut préciser le chemin vers ce code:

bcdedit /set {299c4c80-0a1b-11e2-ab33-f46d04d5218a} path \linux.bin

Ajouter l'entrée au menu qui sera affiché:

bcdedit /displayorder {299c4c80-0a1b-11e2-ab33-f46d04d5218a} /addlast

Préciser le délai d'attente en secondes:

bcdedit /timeout 5

Tout ça a déjà été fait: maintenant quand il démarre son ordinateur, il tombe sur un menu qui ne lui sert à rien puisque linux n'est pas installé.
Ce serait stupide de reculer encore.
D'autant plus qu'il connait exactement ce qui lui reste à faire. Bootant sur le live cd, il a déjà repéré la partition que windows appelle C:

Facile: c'est celle qui contient à la racine le fichier bcdorig.
Il a appris à ouvrir un terminal: appuyer sur la touche windows et taper "te" fait apparaître son icône. Il ne reste plus qu'à cliquer dessus:

Ensuite pour faire passer le terminal en mode Administrateur, il suffit d'y taper la commande

sudo -s

Pour se déplacer dans le terminal vers la partition C de windows, le plus facile consiste à taper la commande cd suivie d'un espace puis de faire un glisser-déposer de l'icône de la partition sur le curseur du terminal.

Ensuite: appuyer sur 'Enter ', et voilà: on y est!

Il sait faire tout cela. Il s'est souvent entraîné: c'est devenu un expert.
Avant même d'avoir installé quoique ce soit!

A la fin de l'installation, avant de quitter le live cd, il pourra facilement refaire toutes ces manipulations. Puis lui restera à créer le fichier linux.bin en exécutant la commande:

dd if=/dev/sda7 of=linux.bin bs=512 count=1

/dev/sda7 désignant la partition sur laquelle le chargeur linux sera installé.

Clef de secours

Ce sujet ne traitera pas de la constitution d'une clef usb permettant de réparer windows.
Pour ceux qui seraient intéressés, ce lien devrait les combler.
Nous allons ici parler ici d'une clef permettant de démarrer linux lorsque cette possibilité a été perdue suite par exemple à l'utilisation d'une clef usb (ou d'un cd) de réparation de windows.
Bien sûr, il y a toujours moyen de s'en sortir via l'utilisation d'un Live cd, mais la procédure est beaucoup plus lourde.
Le mieux est d'être prévoyant.
Donc, supposons que nous pouvons accéder sans problèmes à notre système linux.
Déterminons quelles sont les partitions utilisées par notre système à l'aide la commande df:

La partition racine de notre système est /dev/sda7.
Nous constatons la présence d'une clef usb reconnue en tant que /dev/sdc et dont l'unique partition 1 est montée en /media/KINGSTON.
La première opération, consiste, si ce n'est déjà fait, à installer grub (acronyme de Grand Unified Bootloader) sur le secteur d'amorce (VBR) de la partition racine. En effet, rien n'empêche d'installer grub à la fois sur /dev/sda (donc sur le MBR) et sur le VBR de /dev/sda7. On dispose ainsi de deux portes d'entrée pour lancer notre système linux.
Procédons à l'aide de la commande:

# grub-install --force /dev/sda7

L'option --force n'est tellement appréciée par le système et il nous le fait savoir.
Le grub installé sur /dev/sda7 ne peut être utilisé qu'en tant que chargeur secondaire.
Nous verrons dans un autre billet comment il peut être initié par le chargeur de windows. Dans ce billet nous allons montrer comment procéder en bootant sur une clef usb (ceci a déjà été évoqué dans ce billet).
Tout d'abord, il convient d'installer grub sur le secteur d'amorce de la clef usb et le faire pointer vers des fichiers qui seront enregistrés sur la clef:

# grub-install --boot-directory=/media/KINGSTON /dev/sdc

Il est à remarquer que les données présentes sur la clef (par exemple formatée en FAT32) ne sont absolument pas impactées par l'opération: elle peut donc continuer à être utilisée de manière classique.
Simplement il y a apparition d'un dossier grub contenant tous les fichiers liés à ce chargeur. Il y manque le fichier de configuration grub.cfg.

Afin de pouvoir le constituer, il serait utile d'avoir quelques informations complémentaires sur /dev/sda7:

Constatant que la partition n'avait pas de label, nous lui en avons attribué un (en rapport évidemment avec le système linux installé)
Nous pouvons créer un fichier de configuration utilisant l'UUID de /dev/sda7, et contenant:

search --no-floppy --fs-uuid --set=root 5eba7617-afd6-4480-9b65-fb4e48de3d3c
chainloader +1
boot

On peut aussi fonctionner avec le label:

search --no-floppy --label --set=root Ubuntu
chainloader +1
boot

L'avantage de cette dernière solution est que la clef peut être utilisée sur différentes machines à condition que les partitions utilisées pour booter aient toutes le même label (à savoir Ubuntu dans cet exemple).

Et voilà: pourvu que le bios soit configuré pour booter en priorité sur l'usb, il suffit de démarrer avec une clef insérée pour amorcer linux sans utiliser le MBR

Pour avoir l'opportunité de choisir le système à amorcer, il faut évidemment une étape supplémentaire, à savoir afficher un menu, ce qui s'obtient par exemple avec un fichier de configuration tel que celui-ci:

menuentry "Ubuntu" { 
search --no-floppy --label --set=root Ubuntu 
chainloader +1
} 
menuentry "Linux Mint" { 
search --no-floppy --label --set=root Mint 
chainloader +1
}

Erreur grubby

Description du problème: lors d'une mise à jour nécessitant une adaptation du menu de grub, on reçoit (travaillant en ligne de commande) le message:

grubby fatal error: unable to find a suitable template

Cela se produit lorsque suite à une ou plusieurs mises à niveau, on passe d'un système utilisant grub (legacy) à un système utilisant grub2.

En effet, grubby découvrant la présence d'un fichier menu de grub legacy (/boot/grub/grub.conf ou /boot/grub/menu.lst) essaie de le mettre à jour. Or les éléments nécessaires pour ce faire ne sont plus présents dans le système, ce qui engendre le message d'erreur en question.

Dans le cas de Fedora 17 par exemple, ce qui concerne grub legacy se trouve dans /boot/grub alors que les fichiers relatifs à grub2 ont été placés dans /boot/grub2. Recherchons quels sont les paquetages dont dépendent ces deux dossiers:

[toto@rigel ~]$ rpm -qf /boot/grub
le fichier /boot/grub n'appartient à aucun paquetage
[toto@rigel ~]$ rpm -qf /boot/grub2
grub2-tools-2.0-0.37.beta6.fc17.x86_64

/boot/grub n'appartient plus à aucun paquetage et pour résoudre le problème nous pourrions donc envisager de le supprimer purement et simplement.
Auparavant, vérifions ce qu'il en est en ce qui concerne les fichiers contenus dans /boot/grub:

[toto@rigel ~]$ cd /boot/grub
[toto@rigel grub]$ rpm -qf * |grep -v 'le fichier' | sort | uniq | xargs -t -n 1 rpm -ql 2>&1 | grep "$PWD/\|rpm -ql"
rpm -ql fedora-logos-17.0.2-1.fc17.noarch
/boot/grub/splash.xpm.gz

Pas de chance; le fichier splash.xpm.gz appartient au paquetage fedora-logos.
Il est donc préférable de ne pas supprimer /boot/grub.
En fait il suffit de renommer (ou supprimer) le fichier menu de grub et d'adapter en conséquence (ou supprimer) les liens pointant vers ce fichier:

[root@rigel ~]# cd /boot/grub
[root@rigel grub]# mv grub.conf grub.conf.unused
[root@rigel grub]# ln -sf ./grub.conf.unused menu.lst

Il existe encore dans /etc un lien vers /boot/grub/grub.conf. Supprimons le et si nous avons renommé /boot/grub/grub.conf, créons le lien adéquat:

[root@rigel grub]# cd /etc
[root@rigel etc]# rm grub.conf
rm : supprimer lien symbolique « grub.conf » ?
[root@rigel etc]# ln -s ../boot/grub/grub.conf.unused .

Et voila: grubby n'affichera plus de message d'erreur lors des mises à jour.

Ubuntu 12.04 et libreoffice base

Il est actuellement impossible sous Ubuntu 12.04 d'ouvrir un rapport développé précédemment dans libreoffice base et utilisant Oracle Report Builder. Un message d'erreur signale l'absence du fichier:

/usr/lib/libreoffice/program/librptlo.so

Par contre ce fichier est bel et bien présent dans la version de libreoffice téléchargeable sur le site de libreoffice.

La version de libreoffice dans Ubuntu 12.04 étant 3.5.3, nous téléchargeons donc le fichier:

LibO_3.5.3_Linux_x86-64_install-deb_en-US.tar.gz
(Nous sommes en 64 bits)
On le décompresse et on se rend là où il convient:

[toto@rigel Téléchargements]$ tar xzf LibO_3.5.3_Linux_x86-64_install-deb_en-US.tar.gz 
[toto@rigel Téléchargements]$ cd LibO_3.5.3rc2_Linux_x86-64_install-deb_en-US/DEBS/

Nous pourrions installer libreoffice à partir de ce tar.gz et l'utiliser à la place de la version packagée par Ubuntu.

Mais nous choisissons une voie intermédiaire.
Afin de travailler proprement, nous créons un dossier work dans lequel nous copions le paquet qui nous intéresse et nous nous y rendons:

[toto@rigel DEBS]$ mkdir work
[toto@rigel DEBS]$ cp libobasis3.5-base_3.5.3-2_amd64.deb work
[toto@rigel DEBS]$ cd work

Le paquet deb est une archive ar que nous décompressons de manière volubile (option v), ce qui permet de constater directement que le fichier data obtenu est un tar.gz (ce n'est pas toujours le cas, on pourrait avoir un tar.lzma):

[toto@rigel work]$ ar -xv libobasis3.5-base_3.5.3-2_amd64.deb
x - debian-binary
x - control.tar.gz
x - data.tar.gz
[toto@rigel work]$

Il reste à décompresser ce fichier data et à copier les fichiers manquants (ceux dont le nom commence par librpt) là où il faut:

[toto@rigel work]$ tar xzvf data.tar.gz
./
./opt/
./opt/libreoffice3.5/
./opt/libreoffice3.5/program/
./opt/libreoffice3.5/program/libabplo.so
./opt/libreoffice3.5/program/libadabasuilo.so
./opt/libreoffice3.5/program/libdbplo.so
./opt/libreoffice3.5/program/libdbulo.so
./opt/libreoffice3.5/program/librptlo.so
./opt/libreoffice3.5/program/librptuilo.so
./opt/libreoffice3.5/program/librptxmllo.so
./opt/libreoffice3.5/share/
./opt/libreoffice3.5/share/registry/
./opt/libreoffice3.5/share/registry/base.xcd
[toto@rigel work]$ sudo cp -i opt/libreoffice3.5/program/librpt* /usr/lib/libreoffice/program/

Améliorer l'output de df

La commande df nous renseigne sur la taille, l'occupation et le le point de montage des partitions montées.
Malheureusement le formatage du résultat est déficient en ce sens que les titres des colonnes sont mal disposés:

Ce dysfonctionnement ne se produit pas dans un environnement de langue anglaise.

Nous aimerions obtenir un résultat satisfaisant sans pour autant modifier notre environnement.

Avant de donner la solution au problème, procédons à une petite expérience.

Plaçons dans ~/bin le script quisuisje:

#!/bin/bash
echo $moi

que nous avons rendu exécutable (chmod +x ~/bin/quisuisje)
Si ~/bin n'existe pas, il convient auparavant de le créer:
mkdir ~/bin
et de le placer dans le PATH:
PATH="$HOME/bin:$PATH".
Nous sommes maintenant prêt à réaliser l'expérience:

La variable moi est d'abord initialisée en tant que variable d'environnement avec la valeur 'toto' (contenue dans USER).
Ensuite elle prend la valeur 'riri' mais uniquement au niveau du processus dans lequel tourne quisuisje. Au niveau du shell bash la valeur est inchangée.
Nous avons donc notre solution:

Bien sûr les titres des colonnes sont en anglais, mais c'est quand même largement compréhensible
Nous pouvons même utiliser un alias:

Cette alias sera défini de manière permanente si la définition en est placée dans le fichier ~/.bashrc

Rapports dans libreoffice base

Nous allons montrer, sur un exemple, comment dans libreoffice base réaliser un rapport contenant des sous-totaux et un grand total. Pour ce faire nous aurons besoin de l'extension "Oracle Report Builder". De nombreuses distributions fournissent un paquet qui installe cette extension, paquet le plus souvent appelé libreoffice-report-builder. A défaut de paquet, on peut également trouver cette extension ici. Notre rapport sera basé sur les données de la table PostgreSQL "opération" appartenant à bdtest, notre base de données de test, et qui a été introduite dans ce billet.
Pour faciliter notre travail, crééons une vue avec cette instruction exécutée dans un terminal psql connecté à bdtest:

CREATE VIEW opérationv2
AS
SELECT jour, seq, 
CASE  
 WHEN montant > 0 THEN
 montant 
ELSE 0
END AS crédit,
CASE  
 WHEN montant < 0 THEN
 -montant 
ELSE 0
END AS débit,
montant AS solde
FROM opération

Après avoir connecté libreoffice à bdtest, cliquons sur "Créer un rapport en mode Ébauche".
La première étape consiste à choisir la source des données, à savoir la vue opérationv2 (qui est considérée comme une table par libreoffice):

Par défaut, le rapport contient 3 sections dont seule la section "Détail" est prévue pour accueillir des données. Il est clair que nous aurons besoin de davantage de sections (pour les sous-totaux notamment). Heureusement celles-ci vont se créer automatiquement dans la suite.
Cliquons sur l'icône "Tri et groupement" de la barre d'outils standard:

et choisissons de grouper nos données par jour:

Nous n'oublions pas de sélectionner "Présent" pour "Grouper le pied de page" afin de disposer d'une section pour les sous-totaux.

Demandons également que tout le groupe soit conservé ensemble.

Enfin, ajoutons seq comme groupe afin de pouvoir définir un tri, mais nous ne voulons pas cette fois de section supplémentaire (il ne s'agit pas vraiment d'un groupe):

Nous pouvons commencer à disposer les différents champs et étiquettes sur le rapport. Procédons en premier, comme montré sur l'image ci-dessous, avec le champ "jour" qui se placera, précédé de son étiquette, dans la section "jour En-tête" préalablement sélectionnée:

Pour les données de la zone détail nous allons procéder autrement car nous ne voulons pas placer les étiquettes dans cette zone, mais bien dans la zone en-tête de groupe.

Sélectionnons "zone de texte" dans la barre d'outils "Contrôles de rapport" et déployons le champ à l'endroit qui convient:

La donnée à placer dans ce champ peut être choisie dans le panneau latéral droit des propriétés, onglet données:

Nous avons placé le champ de données seq. Procédons de même avec les champs débit, crédit et solde.

Tous les champs de la zone détail étant sélectionnés, nous fixons via l'onglet "Général" du panneau des propriétés les alignements et le formatage:

(il faudra plus tard mettre un formatage sans décimales pour seq)

Ensuite, nous cliquons sur les icônes "Aligner en haut de la section":

et "Réduire à partir du bas":

Cliquant sur l'icône "Champ d'étiquette"

déployons en dessous du champ seq,  et donc forcément dans la section "jour Pied de page", une étiquette avec la mention "total jour". De même plaçons en dessous des champs débit, crédit et solde, des zones de texte. Mais cette fois, au niveau des propriétés, "Type de champs de données", nous choisissons "Fonction", ensuite le Champ de données et comme fonction "Accumulation" :

Sélectionnant ensemble les trois champs de données, fixons comme auparavant les alignements (horizontal à droite, vertical au milieu) ainsi que le formatage (numérique avec décimales et séparateur de milliers). Ensuite nous alignons l'ensemble des champs en haut de la section et puis nous réduisons celle-ci.

Très bien. Mais où placer la ligne "Grand total" ? Nous avons besoin d'une section supplémentaire. Il nous faudrait un pied de page pour l'ensemble du rapport. Nous pouvons l'obtenir via le menu "Edition":

Reproduisons dans ce nouveau pied de page ce qui se trouve dans le pied de page de groupe, mis à part que l'étiquette contiendra la mention "TOTAL" et que pour les 3 champs de données la fonction accumulation sera étendue à l'ensemble du rapport:

Disposons maintenant dans la section en-tête du groupe jour, les étiquettes correspondant aux données figurant dans la section détails. Laissons un espace entre ces étiquettes et la limite inférieure de la section afin de pouvoir souligner l'ensemble. Au besoin, nous pouvons les aligner via l'icône "En haut" de la barre d'outils "Aligner":

Pour souligner l'ensemble de ces étiquettes, on s'attend à pouvoir utiliser l'icône "Ligne horizontale" de la barre d'outils "Contrôles de rapport":

Malheureusement les lignes obtenues en utilisant cet outil sont invisibles lorsque le rapport est exécuté.

Comment procéder? Utiliser la forme rectangle?

Toute tentative de redimensionner l'objet (pour le faire ressembler à une ligne) entraîne un plantage immédiat.

La solution consiste à placer un champ d'étiquette, sans libellé, avec une couleur d'arrière blanc et dont on contrôle la hauteur via le panneau propriété:

Nous soulignons également (en rouge cette fois) le champ "jour" précédé de son étiquette.

Dans la section "En-tête de rapport", déployons une étiquette contenant le titre du rapport (sur fond jaune pâle).

Dans la section "En-tête", plaçons via le menu insertion date et numéros de page.

Le résultat aura plus belle allure si nous adaptons la couleur du texte qui surmonte un trait à la couleur de ce trait:

Pour améliorer la présentation, donnons également une couleur de fond à l'ensemble formé par le champ jour et son libellé: nous choisissons "gris bleu".

D'autre part, il est préférable de garder l'ensemble de l'en-tête de groupe sur une même page:

(Ceci est inutile si auparavant il a été demandé de conserver ensemble tout le groupe.)

En ce qui concerne la section "Pied de groupe", nous lui attribuons la couleur d'arrière plan "gris clair".

Il reste à séparer le total général du reste du rapport par un trait.

Et voici le résultat:

EDIT: voir deux autres exemples de rapport dans ce billet