PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

genma : Ubuntu - Déploiement de Libreoffice sur un parc Ubuntu avec ajout d'un icone de menu

jeudi 28 novembre 2019 à 09:00

Prérequis à ce tutoriel :
- Savoir qu'à partir de la version 18.04, c'est Gnome Shell qui est le bureau par défaut, avec un look rappelant celui de Unity (une barre de menu vertical sur le bord gauche de l'écran par défaut)
- Connaitre les bases d'Ansible et des playbook

Introduction - le besoin fonctionnel

Sur un ensemble de postes d'un parc informatique sous Ubuntu 18.04.03, comment ajouter un logiciel et ajouter un icône dans la barre des favoris pour ce logiciel ? On va faire ça via Ansible.

L'icône de raccourci ? Un fichier .desktop

Sous Ubuntu avec Gnome Shell, avec un look ressemblant / rappelant le bureau Unity utilisé dans les versions antérieures, dans la barre verticale de gauche, les icones sont des raccourcis ou des favoris vers des applications. A chacun de ces raccourcis /favoris est associé un fichier ayant pour extension .desktop, répondant à une structure particulière.

Dans la documentation développeur de Gnome Fichiers desktop : positionnement de votre application dans les menus du bureau, on trouve quelques explications et détails.

Les fichiers sont stockés das un dossier caché dans le home utilisateur :

/home/genma/.local/share/applications/

Ansible

Playbook d'installation de Libreoffice avec mise en place de l'icône de raccourci Libreoffice Writer dans la barre de favoris.

Prérequis un fichier libreoffice-writer.desktop est créé. Ce fichier contient :

[Desktop Entry]
Version=1.0
Terminal=false
Icon=libreoffice-writer
Type=Application
Categories=Office;WordProcessor;
Exec=libreoffice --writer %U
MimeType=application/vnd.oasis.opendocument.text;application/vnd.oasis.opendocument.text-template;application/vnd.oasis.opendocument.text-web;application/vnd.oasis.opendocument.text-master;application/vnd.oasis.opendocument.text-master-template;application/vnd.sun.xml.writer;application/vnd.sun.xml.writer.template;application/vnd.sun.xml.writer.global;application/msword;application/vnd.ms-word;application/x-doc;application/x-hwp;application/rtf;text/rtf;application/vnd.wordperfect;application/wordperfect;application/vnd.lotus-wordpro;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/vnd.ms-word.document.macroenabled.12;application/vnd.openxmlformats-officedocument.wordprocessingml.template;application/vnd.ms-word.template.macroenabled.12;application/vnd.ms-works;application/vnd.stardivision.writer-global;application/x-extension-txt;application/x-t602;text/plain;application/vnd.oasis.opendocument.text-flat-xml;application/x-fictionbook+xml;application/macwriteii;application/x-aportisdoc;application/prs.plucker;application/vnd.palm;application/clarisworks;application/x-sony-bbeb;application/x-abiword;application/x-iwork-pages-sffpages;application/x-mswrite;application/x-starwriter;
Name=LibreOffice Writer
GenericName=Word Processor
StartupNotify=true
X-GIO-NoFuse=true
Keywords=Text;Letter;Fax;Document;OpenDocument Text;Microsoft Word;Microsoft Works;Lotus WordPro;OpenOffice Writer;CV;odt;doc;docx;rtf;
InitialPreference=5
StartupWMClass=libreoffice-writer
X-KDE-Protocols=file,http,ftp,webdav
Actions=NewDocument;

[Desktop Action NewDocument]
Name=New Document
Exec=libreoffice --writer

Contenu du playbook qui va faire l'installation de Libreoffice et l'ajout de l'icone :

---
- hosts: pool_de_machines_cibles
remote_user: genma

tasks:
# Installation de Libreoffice
- name: install libreoffice
become: yes
apt:
update_cache=yes
state=latest
name=libreoffice
# Ajout de l'icone de Libreoffice-Writer dans la barre des favoris
- name: icone libreoffice writer
become: yes
copy:
src: /home/genma/Ansible/source/libreoffice-writer.desktop
dest: /home/genma/.local/share/applications/libreoffice-writer.desktop
owner: genma
group: genma
mode: 0644

Conclusion

Ce tutoriel est très simple et pourra être adapté à d'autre besoins. Je mets ça là, si ça peut être utile à d'autre.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Articles similaires

RaspbianFrance : Faîtes clignoter la LED verte embarquée de la Raspberry Pi.

mardi 26 novembre 2019 à 15:30
LEDs embarqués de la Raspberry Pi.

Vous avez probablement déjà vu que la Raspberry Pi possède deux LEDs directement soudées sur la carte, une rouge et une verte. Mais saviez-vous qu’il est possible de contrôler cette LED verte, et parfois même la rouge ?

Dans ce tutoriel, nous allons voir comment nous pouvons utiliser la LED verte de la Raspberry Pi en la faisant clignoter pour transmettre un message.

Le matériel nécessaire

Le point intéressant avec cette LED verte, c’est qu’elle est déjà embarquée sur la Raspberry Pi. Par conséquent, nous n’aurons besoin d’aucun matériel supplémentaire. Il nous suffit donc de :

Et comme (presque) à chaque fois, un moyen de contrôler la Raspberry Pi, par exemple en SSH.

À quoi servent les LEDs embarquées de la Raspberry Pi ?

Les Raspberry Pi possèdent deux LEDs (sauf les modèles Zéro qui n’ont que la verte), une rouge et une verte. Ces LEDs sont utilisées par la Raspberry Pi pour nous indiquer des informations sur son état de fonctionnement.

Ainsi, la LED rouge est directement reliée à l’alimentation électrique de la Raspberry Pi. Elle nous permet donc de savoir si oui ou non notre Raspberry Pi reçoit du courant.

La LED verte de son côté nous fournit des informations un peu plus complexes, essentiellement au moment du démarrage.

Led verte de la Pi qui clignote.
La façon dont la LED clignote donne des informations sur l’avancement du boot.

Je ne vais pas vous faire une retranscription complète du dictionnaire Raspberry Pi/Humains, mais sachez que selon la façon dont cette LED clignote, vous pouvez savoir si la Raspberry Pi boot correctement ou si elle rencontre une erreur, et le cas échéant le type de cette erreur.

Allumer la LED verte de la Raspberry Pi, c’est écrire dans un fichier !

Une fois la Pi allumée, la LED verte reste éteinte tant qu’il n’y a pas d’activité sur la carte SD.

Il est possible de modifier légèrement ce comportement et de contrôler nous même la façon dont la LED s’allume, simplement en écrivant dans un fichier !

Dans un premier temps, nous allons devoir modifier le comportement par défaut de la LED en écrivant none dans le fichier /sys/class/leds/led0/trigger avec la commande ci-dessous :

sudo sh -c "echo none > /sys/class/leds/led0/trigger"

Une fois cette commande passée, si vous ouvrez ce fichier vous verrez qu’il ne contient pas réellement none comme on pourrait s’y attendre, mais une ligne ou none est entre [] de façon à montrer que c’est le mode sélectionné.

Le comportement pas défaut étant écrasé, il ne nous reste plus qu’à contrôler nous même la LED. Et pour ça, rien de plus simple !

Pour allumer ou éteindre la LED, il nous suffit d’écrire dans le fichier /sys/class/leds/led0/brightness.

Si vous écrivez 1, la LED s’allume, si vous écrivez 0, elle s’éteint.

sudo sh -c "echo 1 > /sys/class/leds/led0/brightness" #allume la led
sudo sh -c "echo 0 > /sys/class/leds/led0/brightness" #éteins la led

Pour information, sur les modèles les plus récents vous pouvez gérer la LED rouge de la même façon, en remplaçant led0 par led1.

Contrôler les LEDs de la Raspberry Pi, à quoi ça sert ?

Mais au final, allumer ou éteindre les LEDs de la Raspberry Pi, à quoi ça peut bien servir ?

Déjà pour la LED rouge, pouvoir l’éteindre peut vous permettre de diminuer un peu le courant utilisé (c’est négligeable, évidemment) et de la rendre plus discrète.

Mais dans l’ensemble, cela va surtout vous permettre de donner des informations à un utilisateur sans avoir le moindre périphérique branché, ni écran, ni enceinte, rien !

Par exemple, vous voulez faire une badgeuse pour tag RFID. On pourrait imaginer un code couleur au moment d’ajouter un nouveau badge. La LED rouge clignote tant qu’on attend le badge, la LED verte s’allume quand le badge est allumé, la rouge reste fixe et la verte éteinte quand l’opération d’ajout se termine.

Autre exemple, nous pourrions faire un script permettant de lire l’adresse IP de la Raspberry Pi au démarrage en lisant le nombre de clignotement de la LED verte !

Finalement, il y a beaucoup d’informations que nous pouvons échanger directement depuis la Raspberry Pi, sans avoir besoin d’y brancher quoi que ce soit, juste en utilisant les LEDs embarquées !

Lire l'article complet : Faîtes clignoter la LED verte embarquée de la Raspberry Pi.

Gravatar de RaspbianFrance
Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.

genma : P2V avec Clonezilla ou comment convertir un serveur physique en machine virtuelle

lundi 25 novembre 2019 à 09:00

Introduction

J'avais abordé dans un billet assez ancien (il y a 3 ans, Wikipedia - Physical-to-Virtual

La première fois que j'ai découvert cette notion, c'était dans le cadre du passage d'un ensemble de serveurs physiques qui ont été virtualisés pour donner des machines virtuelles sur une plateforme VMWare, via un logiciel dédié.

Dans cet article, je voudrais présenter une façon de faire pour passer d'une machine physique à une machine virtuelle (la virtualisation se fera dans Virtualbox, du moins dans un premier temps).

Prérequis

- Connaitre Virtualbox, savoir créer une machine virtuelle
- Connaitre Clonezilla (du moins savoir à quoi ça sert)

Clonezilla ?

Procédure de création d'une image Clonezilla et procédure de restauration sont très bien décrites dans de nombreux tutoriaux sur Internet, je ne vais donc pas ré-aborder ça ici. (Un tutoriel parmi d'autre lecrabeinfo.net - Cloner son disque dur/SSD vers un autre disque avec Clonezilla

Création d'une image Clonezilla

La première étape est donc de créer une image Clonezilla du PC physique et de mettre cette image sur un support amovible (clef USB disque dur externe selon la taille du disque). L'image sera une image complète du disque (et non une image de partitions).

La taille de l'image Clonezilla dépend de la taille occupé sur le disque (et non de sa taille réelle). Par exemple un disque de 500go qui n'est occupé qu'à 16go donnera une image Clonezilla d'environ 16go.

Création d'une machine virtuelle dans Virtualbox

La seconde étape est de créer une machine virtuelle dans Virtualbox. La configuration matérielle peut être assez proche ou différente (quantité de mémoire vive, CPU et nombres de cœurs) : si c'est un OS Linux, il s'adaptera à la configuration matériel virtuelle. Par contre la taille du disque dur virtuelle de la machine virtuelle est important : ce disque doit avoir une taille équivalente (ou supérieure) à la taille du disque de la machine qui a été cloné en image Clonezilla. Le disque dur virtuel peut toutefois avoir une taille dynamique, évitant ainsi de mobiliser 500 giga pour un espace réellement occupé de 16 giga au final (l'espace disque occupé à la restauration de l'image Clonezilla correspondant à l'espace disque de la machine d'origine).

Virtualbox, les périphériques complémentaires

En plus du disque dur virtuel, il faut ajouter un lecteur CD-Rom /demander à la machine virtuelle de démarrer sur une iso de Clonezilla. Et ajouter le partage des ports USB de la machine physique faisant tourner Virtualbox, pour que la clef USB / disque dur externe contenant l'image crée via Clonezilla puisse être lu depuis la machine virtuelle.

On pourra regarder par exemple la documentation ici sur l'association des périphériques USB avec la machine virtuelle dans Virtualbox https://doc.ubuntu-fr.org/virtualbox#peripheriques_usb ou encore ici en images et détaillé Comment activer le support USB 2.0 ou 3.0 dans VirtualBox.

Restauration de l'image du serveur

Une fois les prérequis réunis, on boot / démarre la machine virtuelle sur l'ISO de Clonezilla et on suit la procédure de restauration. Au moment de la recherche de l'image Clonezilla à restaurer, on branche la clef USB / disque dur externe sur le port USB partagé avec la machine virtuelle, on appuie sur une touche et Clonezilla va détecter le branchement de ce périphérique USB, trouver le dossier et proposer de restaurer l'image Clonezilla, sur le disque dur de la machine virtuelle.

Une fois la restauration finie, on retire l'ISO et on démarre la machine virtuelle. On a une copie conforme de notre machine physique.

Migration de la machine virtuelle

L'avantage de Virtualbox est d'utiliser un format standard, qui peut être converti si besoin dans d'autres formats de machines virtuelles. On pourra donc migrer / exporter cette machine virtuelle qui tourne dans Virtualbox pour la faire tourner sur un serveur Proxomox, sur KEmu... Là encore, il existe de nombreux tutoriaux sur le sujet.

Conclusion

Avec un petite astuce, il est donc possible de virtualiser son serveur physique / son PC (pour en faire une machine virtuelle, donc). Le PC physique doit tourner sous Linux. Je n'ai pas testé avec Windows, car à la restauration de l'image Clonezilla, il se peut qu'il faille réactiver Windows (qui va détecter que le matériel est différent du matériel d'origine).

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Articles similaires

Journal du hacker : Liens intéressants Journal du hacker semaine #47

lundi 25 novembre 2019 à 00:01

Pour la 47ème semaine de l'année 2019, voici 12 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker :)

Gravatar de Journal du hacker
Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Articles similaires

Thuban : Syspatch : patch inteldrm, mesa - multi-arch - 6.5, 6.6

vendredi 22 novembre 2019 à 13:11

Hier soir, l'équipe OpenBSD nous a livré deux nouveaux correctifs, pour 6.5 et 6.6 :

Le premier correctif touchant au fonctionnement du noyau, il est nécessaire de redémarrer la machine !


Architectures concernées : hormis amd64, arm64 et i386 qui peuvent le faire par syspatch, toutes les autres architectures gérées par le projet OpenBSD doivent le faire par recompilation.

Lire la FAQ Administration Système pour savoir quoi faire : EN Official FAQ, FR.


Pour information :

 

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.