Publié le 12 janvier 2016 - par

systemd, tout nouveau tout beau ? ou pas …

tux_systemd_250pxsystemd est un démon destiné à remplacer l’ancien système de démarrage init. Il a pour but d’offrir un meilleur cadre pour la gestion des dépendances entre services, de permettre le chargement en parallèle des services au démarrage, et de réduire les appels aux scripts shell.
Il est mis en œuvre dans un certain nombre de distribution standard – Fedora, openSUSE, Arch, RHEL, CentOS, etc.

Cet article a pour base une publication de Carla Schroder sur linux.com

C’est quoi systemd ?

Un démon !

systemd est un démon de gestion système nommé conformément à la convention UNIX qui consiste à ajouter un «d» à la fin du nom du démon. Cela permet de les reconnaître facilement.

Initialement, il a été libéré sous la licence GNU General Public, Le projet a été lancé par Lennart Poettering en 2010 et publié sous licence GNU LGPL. Le nom de ce programme vient de « system daemon » : le daemon du système. Comme init, systemd est le parent de tous les autres processus, directement ou indirectement. Il est le premier processus lancé au démarrage donc il se voit généralement attribuer un « pid = 1″.

Comment démarre le système ?

d’après http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-libere – CC by SA

Lorsqu’un ordinateur démarre, il initialise les différents composants de l’ordinateur (processeur, mémoire vive, disque dur, carte graphique, etc.) et effectue quelques vérifications basiques, puis démarre le cœur du système d’exploitation : le noyau (ici, Linux). En effet, c’est la partie qui communique directement avec les périphériques comme le clavier, la souris, la mémoire ou l’écran et permet leur utilisation.

synoptique_600px

Lorsque le noyau est chargé, l’ordinateur n’est pas encore prêt à l’emploi. Le noyau délègue au système d’initialisation le lancement du reste du système, selon la configuration établie par l’administrateur. Il lance les services d’arrière-plan (montage des périphériques de stockage, configuration du réseau, messagerie…) et l’interface utilisateur, qu’elle soit graphique ou pas. Le système d’initialisation possède aussi une autre fonction : récupérer les processus qui sortent de leur session. En effet, dans tous les Unix-like—et cela inclut GNU/Linux—tous les processus doivent avoir au moins un processus père, sauf le tout premier processus lancé (PID 1). Si un processus renie son père (on dit qu’il est démonisé), le noyau le rattache alors au premier processus.

Hormis le noyau, il est donc le premier processus lancé sur la machine (ce qui explique l’appellation « PID 1 » — « processus n°1 ») et le dernier à s’arrêter, car il contrôle tous les autres. Par conséquent, le système d’initialisation est un composant critique du système car s’il ne fonctionne pas, la machine ne démarre pas. D’où sa robustesse requise.

systemd_600pxJusqu’à récemment ce programme était souvent SysVinit, mais des remplaçants, plus ou moins compatibles, se sont multipliés ces dernières années, comme Upstart qui est l’init par défaut d’Ubuntu. Un init de type SysV fonctionne comme suit : il lit le fichier /etc/inittab qui lui indique quoi faire à un niveau d’exécution (runlevel) particulier, puis il démarre, redémarre ou arrête automatiquement les services selon le niveau choisi par l’utilisateur.

La syntaxe de ce fichier n’étant pas turing complète, les administrateurs ont préféré déléguer l’essentiel du démarrage à des scripts rc nommés dans ce fichier et appelés par init.

Ces scripts sont aujourd’hui décriés à cause du travail dupliqué entre les distributions, de la difficulté réelle ou supposée de les maintenir et de leurs limites. Sont-elles supposées ou avérées ? Là est toute la question ! Quelques exemples :

  • tous ne sont pas, par exemple, forcément compatibles avec des composants tels que selinux (ou autre LSM à la mode) ;
  • il est difficile de lancer un service uniquement suite à un événement. Par exemple, lors du branchement d’une clé USB ;
  • il est difficile de s’assurer qu’un service (par exemple, sshd) sera relancé automatiquement en cas d’arrêt.

Le système d’init nécessite un travail d’intégration important dans la distribution ; il ne peut donc pas, la plupart du temps, être changé facilement par l’utilisateur.

Ca change quoi, systemd ?

Le projet systemd est écrit avec le langage de programmation C. Il s’agit d’une collection de logiciels sous forme de binaires. Le pilotage des services se fait grâce à des fichiers de configuration.

systemd_600pxÀ première vue, cela ressemble à SysV (écrit en C, formé de trois exécutables et configuré par le fichier « inittab »), mais la grande différence est que SysV suit une approche minimaliste qui déplace une grande partie de l’initialisation des services dans des programmes écrits en Shell et utilisant des bibliothèques externes (par exemple, « start-stop-daemon » pour l’init Debian). À contrario, systemd implémente un large éventail d’actions afin de décourager l’utilisation de scripts de lancement. En pratique, un service SysV pour sshd a pour élément central un script de quelques centaines de lignes (script Shell qui peut être utilisé indépendamment de l’init), alors que sous systemd le service sera généralement piloté par un fichier texte d’une dizaine de lignes (dans une syntaxe spécifique à systemd).

On vante souvent la simplicité des anciens systèmes d’init : en effet, quoi de plus simple que des fichiers textes exécutables dont on peut lire l’exécution ligne par ligne ?

En éditant ces fichiers, on a une maîtrise totale du démarrage de l’ordinateur (à partir du moment où l’on est capable de comprendre le code). Mais modifier le système d’init en lui-même peut poser problème lors de mises à jour ou simplement parce que ce code n’a pas été testé.

systemd remplit les mêmes fonctions que les précédents systèmes, mais il met l’accent sur la simplicité d’utilisation et sur une maîtrise du système plus poussée et moins éparpillée, ce qui est parfois vu comme l’opposé de la philosophie Unix.

Ainsi, beaucoup de choses qui nécessitaient auparavant de modifier des scripts Shell existent maintenant sous la forme d’un simple paramètre dans un fichier. Le comportement est codé dans systemd ce qui permet de mutualiser beaucoup de code et de rendre les fichiers souvent beaucoup plus courts.

Pour la plupart des gens, utiliser systemd ou SysVinit ne fait aucune différence, y compris pour la vitesse de démarrage ; pour bidouiller, tout dépend des outils que l’on maîtrise, soit les outils systemd et leur syntaxe de configuration, soit la programmation Shell, les outils de suivi de processus et la configuration SysV.

systemd en pratique

Un peu d’histoire

Qu’on le veuille ou non systemd est là. Et comme je l’ai souvent dit le rôle du technicien n’est pas de critiquer les choix qui ont été faits (même s’il a le droit de râler !) mais d’utiliser au mieux les outils mis à sa disposition. Et si ça ne lui plait vraiment pas, libre à lui de créer une nouvelle distribution ou une nouvelle carte mère qui fera ce qu’il souhaite… C’est d’ailleurs ce qu’on fait les dissidents de Debian qui ont créé Devuan (=Dev One), une Debian sans systemd.

systemd_pingouinsystemd est controversée pour plusieurs raisons : Il remplace quelque chose que beaucoup d’utilisateurs de Linux n’estiment pas devoir être remplacé, et le comportement des développeurs de systemd n’a pas conquis les cœurs et les esprits. c’est plutôt le contraire, comme en témoigne le fameux fil LKML dans lequel où Linus Torvalds interdit l’accès au noyau Linux à Kay Sievers, développeur de systemd.

Pendant des années Linux a fonctionné avec SysVInit et BSD init. Puis sont venus les add-on les gestionnaires de services, comme les commandes service et chkconfig qui étaient censées rendre la gestion des services plus aisée, mais qui n’étaient que des choses supplémentaires à maîtrisersans que cela ne rende la tâche plus facile, juste un peu plus complexe.

Ensuite vinrent Upstart et systemd avec toutes sortes d’extension alambiquées pour maintenir la compatibilité avec SysVInit. Ce qui part d’un bon sentiment… Mais bon courage pour comprendre comment ça fonctionne. Maintenant Upstart a pris sa retraite au profit de systemd, à partir d’Ubuntu 14.10.

evolution1Ca fait toujours peur quand les développeurs commencent à tritouiller les sous-systèmes clés dans Linux, parce que nous sommes un peu coincé avec tout ce qu’ils imposent. Si nous n’aimons pas une application particulière, ou un l’environnement de bureau, ou une commande il y a toujours plusieurs alternatives et il est facile à utiliser quelque chose d’autre. les-singes-de-la-sagesseMais les sous-systèmes essentiels ont des accroches profondes dans le noyau, un tas de scripts de gestion, et des dépendances de paquets logiciels, alors les remplacer n’est pas du tout facile.

La morale de cette histoire (larirette…) c’est que les choses changent, les ordinateurs deviennent inévitablement de plus en plus complexes, et finalement tout ça fonctionne… ou pas !  Mais nous devons nous habituer à ne pas pouvoir façonner les événements selon notre propre volonté.

Premiers pas avec systemd

Red_Hat_LinuxRed Hat est l’inventeur et le premier promoteur de systemd, donc les meilleures distributions pour jouer avec systemd sont Red Hat Enterprise Linux, ou les clones de RHEL comme CentOS et Scientific Linux, et bien sûr le bon vieux Fedora Linux, qui embarque toujours la dernière version.

Les utilisateurs expérimentés de RH peuvent toujours utiliser service et chkconfig en RH 7, mais il est grand temps de les remplacer par les services natifs. systemd les a remplacés, et service et chkconfig ne prennent pas en charge les services natifs de systemd.

Notre bien-aimé /etc/inittab n’est plus.
A la place, nous avons un répertoire /etc/systemd/system/ rempli de liens symboliques vers des fichiers situés dans /usr/lib/systemd/system/.

evolution3_600px

C’est ce répertoire qui contient les scripts d’initialisation : pour lancer un service au démarrage, il doit être lié à /etc/systemd/system/. La commande systemctl le fait pour vous lorsque vous activez un nouveau service, comme je le fais dans cet exemple pour tightvncserver :

Installer tightvncserver

On commence comme d’habitude par mettre à jour la distribution :

sudo apt-get update
sudo apt-get upgrade

On peut passer à l’installation de tightvncserver :

pi@raspberrypi:~ $ sudo apt-get install tightvncserver

Lancer tightvncserver pour vérifier qu’il est bien installé et fonctionne :


pi@raspberrypi:~ $ vncserver :1

You will require a password to access your desktops.

Password:
Warning: password truncated to the length of 8.
Verify:
Would you like to enter a view-only password (y/n)? n

New 'X' desktop is raspberrypi:1

Creating default startup script /home/pi/.vnc/xstartup
Starting applications specified in /home/pi/.vnc/xstartup
Log file is /home/pi/.vnc/raspberrypi:1.log

Voyons voir si ça marche

On peut maintenant lancer VNCviewer sur le PC pour voir si on se connecte bien au RasPi :

vnc_01

Cliquez sur Connexion

vnc_02Cliquez sur Continuer

vnc_03Tapez le mot de passe que vous aviez saisi sur le Raspberry Pi (pour faire original j’avais mis… raspberry 🙂 )

vnc_04_600pxBon… Jusque là tout va bien !

Créer le service sous systemd

Créez un fichier /etc/systemd/system/vncserver@.service

pi@raspberrypi:~ $ sudo nano /etc/systemd/system/vncserver@.service

avec le contenu suivant :

[Unit]
Description=Service de bureau à distance (VNC)
After=syslog.target network.target

[Service]
Type=forking
User=pi
PAMName=login
PIDFile=/home/pi/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

Modifiez éventuellement les paramètres dans le fichier. puis lancez l’installation du logiciel :

pi@raspberrypi:~ $ sudo systemctl daemon-reload && sudo systemctl enable vncserver@1.service
Created symlink from /etc/systemd/system/multi-user.target.wants/vncserver@1.service to /etc/systemd/system/vncserver@.service.

systemctl indique en retour qu’il a bien créé le lien symbolique.

Vous pouvez maintenant redémarrer le Raspberry Pi :

pi@raspberrypi:~ $ sudo reboot

On peut vérifier que tightvncserver a bien été lancé :

pi@raspberrypi:~ $ systemctl
UNIT&                   LOAD   ACTIVE SUB       DESCRIPTION
...
vncserver@1.service        loaded  active running  Service de bureau à distance (VNC)

Il reste un petit défaut : dans le fenêtre de VNCviewer, le curseur de souris prend la forme d’une croix noire. Une modification dans le fichier /home/pi/.vnc/xstartup permet de retrouver le curseur classique (une flèche orientée vers la gauche) :

Remplacez

xsetroot -solid grey 

par

xsetroot -solid grey -cursor_name left_ptr

et au prochain redémarrage, lorsque vous reconnecterez VNCviewer, vous retrouvez votre curseur habituel.

Tout ça c’est bien joli, mais tu nous explique un peu ?

Si vous voulez… On va faire ça ligne par ligne en prenant comme exemple le fichier vncserver@.service que nous avons créé ci-dessus. Je vous dis ce que j’en ai compris/trouvé sur les pages d’aide… N’hésitez pas à me reprendre ou à compléter :

[Unit]
Le fichier xxx@.service peut comporter cette section [Unit], qui contient l’information générique de l’unité et ne dépend pas du type d’unité.

Description=Service de bureau à distance (VNC)
Cette chaîne libre décrit l’unité. Cette ligne est destinée à fournir des informations décrivant l’unité. La description doit signifier quelque chose pour l’utilisateur final. « Serveur Web Apache 2 » est un bon exemple, « serveur HTTP léger haute performance » est mauvais : trop générique ou encore « Apache2 » trop spécifique et dénuée de sens pour les gens qui ne connaissent pas Apache.

After=syslog.target network.target
After indique que le service actuel VNCserver ne sera démarré qu’après le démarrage effectif des services listés (et séparés par un espace)

[Service]
les fichiers des services doivent inclure une section « [Service] », comportant des informations sur le service et le sur processus qu’il supervise. Ces options sont documentées dans systemd.exec (5) et systemd.kill (5).de service sont les suivantes:

Type=forking
Si Type est défini comme forking, le processus configuré avec ExecStart= (ci-dessous) fera un appel à la fonction fork () lors de son démarrage. Le processus parent se termine quand le démarrage est fini et que tous les canaux de communication sont établis. L’enfant continue de fonctionner en tant que processus démon principal. C’est le comportement des démons UNIX traditionnels. Si ce paramètre est utilisé, il est recommandé d’utiliser l’option PIDFile=  pour que systemd puisse identifier le processus principal du démon. systemd démarrera les unités suivantes dès l’arrêt du processus parent.

User=pi
Permet de désigner l’utilisateur qui lancera le processus

PAMName=login
Définit sous quel nom la session démarre. Si défini, le processus sera enregistré comme session PAM sous le nom de service spécifié. Ceci est utilisé en association avec l’option User= (ci-dessus).

PIDFile=/home/pi/.vnc/%H:%i.pid

Bon, ici la ligne est plus longue… Regardons en détail les différentes parties :
/home/pi/.vnc/ 
designe le chemin (l’endroit) où le fichier de PID sera enregistré.
%H:%i.pid est le nom du fichier avec %H le nom de la machine et %i le numéro de l’instance de l’unité.

Dans la pratique on trouve

pi@raspberrypi:~/.vnc $ ls
passwd raspberrypi:1.log raspberrypi:1.pid xstartup

et dans le fichier raspberrypi:1.pid

pi@raspberrypi:~/.vnc $ cat raspberrypi:1.pid
562

Avec 562 qui est l’ID du processus.

ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
Encore une ligne à rallonge !

ExecStartPre= c’est la commande qui sera exécutée avant ExecStart (on s’en serait douté !)
usr/bin/vncserver -kill:%i cette commande « tue » un bureau VNC qui aurait préalablement lancé par le serveur. Elle le fait en tuant le processus dont l’ID est stockée dans le fichier « /home/pi/.vnc/hôte: instance.pid » (voir ci-dessus)
/dev/null 2>&1 redirige toute sortie de cette commande vers un « trou noir » : Rien n’est affiché

ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280×800 :%i
Si le service est lancé avec start, cette ligne va lancer le serveur VNC avec une profondeur de couleur de 24 bits ( -depth 24), une taille d’écran de (-geometry 1280×800) sur l’instance :i%

ExecStop=/usr/bin/vncserver -kill :%i
Si le service est arrêté avec stop, cette ligne va « tuer » l’instance en cours

[Install]
WantedBy=multi-user.target
La section « [Install] » comporte des informations pour l‘installation de l’unité. Cette section n’est pas interprété par systemd lors de l’exécution. Elle est utilisée exclusivement par les commandes enable et disable de l’utilitaire systemctl lors de l’installation d’une unité.

WantedBy=multi-user.target
Les target de systemd ressemblent aux runlevel que nous avons connus précédemment. Ils portent un nom au lieu d’un numéro. Ici multi-user correspond au runlevel 3, c’est à dire le mode texte (non graphique) multi utilisateurs…  Un lien symbolique est créé dans le répertoire .wants/ de chacune des unités répertoriées lorsque cette unité est installé avec systemctl enable. Le résultat est que l’unité actuelle sera lancé lorsque l’unité indiquée après WantedBy sera lancée.

Vous trouverez ci-dessous tout un tas de liens plus intéressants les uns que  les autres si vous souhaitez aller plus loin dans la compréhension de systemd.

Et si je neveux plus utiliser VNCserver ?

Vous pouvez soit le dévalider

sudo systemctl disable vncserver@1.service

Soit l’enlever complètement

sudo systemctl remove vncserver@1.service

Et c’est tout ?

Non, bien sûr… systemd comprend bien d’autres options. Mais c’est peut être suffisant pour cet article, non?

Allez une dernière info : Comment faire pour démarrer, arrêter manuellement un service ?

# systemctl start [name.service]
# systemctl stop [nom.service]
# systemctl restart [nom.service]
# systemctl reload [nom.service]
$ systemctl status [nom.service]

Les quatre premières commandes fonctionnent avec root (en sudo), la dernière est accessible en utilisateur normal…

Par exemple si vous voulez arrêter le serveur VNC :

pi@raspberrypi:~ $ sudo systemctl stop vncserver@1.service

Vidéo

Fredi a réalisé une vidéo présentant l’installation de tightvncserver. Après avoir installé NOOBS et mis à jour Raspbian, il vous explique comment installer et paramétrer tightvncserver, puis comment configurer une FreeBox pour accéder au Raspberry Pi de l’extérieur de votre réseau.

Conclusion

La migration vers systemd ne va pas se faire sans grognements. Vous trouverez sur la toile autant d’arguments en sa faveur qu’en sa défaveur. A mon avis, il faudra s’habituer, oublier des années de pratique de sysV.
Un regret quand même, c’est que le Raspberry Pi est destiné pour beaucoup à des débutants et le passage (discret) à systemd ne me semble pas avoir été assez accompagné par la Fondation, laissant bon nombre d’utilisateurs perplexes… un peu comme le changement de gestion du réseau confié maintenant à dhcpcd. Combien d’entre nous se sont démenés avec le fichier interfaces avant de s’apercevoir du changement ?

Sources

 

 

 

 

 

Share Button

À propos François MOCQ

Électronicien d'origine, devenu informaticien, et passionné de nouvelles technologies, formateur en maintenance informatique puis en Réseau et Télécommunications. Dès son arrivée sur le marché, le potentiel offert par Raspberry Pi m’a enthousiasmé j'ai rapidement créé un blog dédié à ce nano-ordinateur (www.framboise314.fr) pour partager cette passion. .

45 réflexions au sujet de « systemd, tout nouveau tout beau ? ou pas … »

  1. Supoziitoire

    Bonjour , j’ai un soucis pour transmission il ne démarre plus automatiquement comme sur debian , et j’ai s’avoir quoi mettre dans

    pi@raspberrypi:~ $ sudo nano /etc/systemd/system/transmission.service

    Ps: Tokai (Daniel.F ) ma beaucoup parlé de vous 😀 mais il na pas voulu me prêté votre livre dédicacé

    Répondre
  2. Ping : Prenez la main à distance sur votre Raspberry Pi avec VNC | Framboise 314, le Raspberry Pi à la sauce française….

  3. xinu

    Merci beaucoup pour l’article.

    Pour information (au cas où cela intéresse également quelqu’un), j’ai pour ma part dû changer les ‘:%i’ du script /etc/systemd/system/vncserver@.service par des « :0 » pour que cela fonctionne sur mon Mac et l’application ‘partage d’écran’.

    Répondre
    1. Michael

      J’ai découvert hier systemd (comprendre que je suis face à un système qui utilise systemd et pas SysVinit comme j’était habitué jusque là) et me suis rappelé votre article.
      J’étais intrigué par le nom que vous donniez à votre service /etc/systemd/system/vncserver@.service et plus particulièrement le @
      systemd travaille sur mon système avec du nommage classique /etc/systemd/system/lcd.service par exemple pour la plupart des scripts. Du coups je me suis un peu plus penché sur cette histoire et il se trouve que le @ permet de créer un template pour plusieurs instances éventuelles.. ce qui au final était exactement ce dont j’avais besoin et que vous utilisez sans explicitement le mentionner il me semble.

      voir: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
      section
      Creating Instance Units from Template Unit Files

      example@instance1.service
      la valeur de l’instance, et c’est la le coté magique du truc c’est que cette valeur peut être récupérée au sein du scripte example@.service qui devient un template.
      J’étais parti pour créer plusieurs scripts avec des valeurs hardcodées style
      scan_satellite_S19E2.service, Scan_Satellite_S3E0.service avec les même contenu alors qu’un joli template devient un fichier unique
      scan_satellite@.service.
      et avec l’enregistrement :
      systemctl enable scan_satellite@S19E2.service
      systemctl enable scan_satellite@S3E0.service

      Dans le script les valeurs S19E2 ou S3E0 se récupèrent en utilisant le specifieur %i
      Spécifieur utilisé dans votre scripte et que notre ami Xinu (qui par définition récursive veut dire « Xinu is not unix » tout en étant presque un palindrome :-D) a dû remplacer par des :0. or il devrait plutôt installer le script sous une autre instance:
      sudo systemctl daemon-reload && sudo systemctl enable vncserver@0.service

      Répondre
  4. Ping : Accès à distance – Butler Pi

  5. max

    plus par amusement que par necessite, j’ai installe un pgm sur le pi depuis le pc grace a vnc;
    meci pour l’aide claire et precise , grace aux commandes completes disant sur quel appareil on doit taper la commande ce qui n’est pas toujours evident

    Répondre
  6. Alain

    Merci pour ce complément d’installation avec systemd. Je m’étais un peu fourvoyé avec les autres tutos d’installation de VNC sur les versions précédentes, et maintenant, ça marche !

    Répondre
  7. Benoit

    Bonjour,

    Merci pour le tuto pour l’installation de tightvnc, cependant je souhaite avoir un seul affichage (le rpi est relié à une TV). Quand je me connecte à distance, c’est un deuxième bureau qui s’ouvre et non celui affiché sur la TV.
    Quel est le réglage pour avoir un seul et unique affichage ?

    Merci 🙂

    Répondre
  8. Gregoire

    Bonjour,

    Quand je me conncete, VNC me reponds que l’hote refuse mon acces.
    Mais oou trouve t on le code à rentrer apres VNC server ?
    Est ce l’ip ?

    Répondre
  9. Alex

    Bonjour,
    Si par exemple;
    Je créer un programme en C et le compile avec gcc. Pour le lancer je passe par une commande sous le terminal de Debian. Et admettons, que je soit contraint de le lancer après que l’environnement graphique ce soit lancé.

    Comment faire pour que ce programme se lance tout seul? toujours dans l’environnement graphique?
    Faut’il dans mon cas, que je créer un service spécifique qui sera lancé grâce à systemd?

    Cordialement

    Répondre
  10. Sven

    Bonjour.
    Et merci pour ce tuto qui me sera très utile… quand j’arriverai à mettre en route ce service.

    J’ai réussi à mettre Tightvncserver en route sans souci particulier, sauf que pour m’y connecter via le Viewer c’est à l’adresse 192.168.1.15:2 que je dois envoyer ma requête.
    Comme un bourrin j’ai fait un copier/coller de ces fragments de code sans penser qu’il fallait l’adapter pour cette adresse (:2).
    Ça fait bien 2 heures que le noob que je suis s’essaie à reprendre ces fragments de code pour dire que c’est l’adresse du serveur 192.168.1.15:2 qui doit être prise en compte, mais nada, peanuts, ça marche pô.

    Pourrais-tu me dire ce que je dois changer pour ça marche ?
    Avec ma gratitude éternelle en retour, bien entendu.

    Répondre
  11. icare

    Bonsoir,
    Je souhaitais installer tightvncserver avec la méthode décrite dans cette article.
    J’ai fait les opérations suivantes :
    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get dist-upgrade
    sudo rpi-update
    sudo apt-get install tightvncserver
    vncserver :1
    Eh bien cela fonctionne.
    Après un reboot, je suis tombé sur la fenêtre suivante :

    Ecran de login avec le texte en français, clavier en qwerty pour la connexion identifiant pi et mot de passe raspberry ne fonctionnent pas.
    Je n’ai pas trouvé de solutions pour le login malgré toutes les permutations possibles entre pi, raspberry et rqspberry.
    Après de nombreuses ré-installations, j’ai réussi à faire fonctionner la RPI3 normalement (l’installation de tightvncserver n’y est pour rien).
    Il semblerais que la procédure suivante fonctionne :
    sudo apt-get update
    sudo apt-get upgrade
    sudo rpi-update
    sudo apt-get dist-upgrade
    Il faut faire rpi-update avant dist-upgrage.

    Répondre
    1. Laurent

      Bonjour,

      Attention avec ‘rpi-update’ pour ceux qui ont des images spécifiques, comme pour des écrans tactiles etc.
      Cette commande peut mettre à jour le firmware du RPI, et là il y a de grande chance que le périphérique ne plus fonctionne plus.
      Donc prudence.

      Répondre
  12. Laurent

    Bonjour,

    Merci François ça marche très bien, on peut tout faire avec VNC comme si on était sur la machine.
    J’ai même testé une prise de main distante depuis mon smartphone avec VNC, bon là c’est microscopique. Mais on interfère sur l’écran et c’est pas si mal, en tout cas ça marche. (oui je sais je suis un peu barge, mais j’aime bien l’invraisemblable)
    Une question à ce propos : la connexion n’est pas cryptée non plus, j’ai la fenêtre d’avertissement et là c’est chaud par le WEB. Est-ce qu’il y a quelque chose d’autre équivalent mais crypté comme le SSH ? Sinon bah ce sera SSH en texte 🙂

    C’est pas mal pour aider ceux qui ne sont pas linuxien pour 2 ronds, avec leur rasp.
    Argggg, non ça va pas le faire, VNC ne propose l’apéro quand c’est fini 😉

    En tout cas très bon tuto, clair, détaillé ça fait plaisir, merci pour ce partage.
    Laurent

    Répondre
    1. François MOCQ Auteur de l’article

      merci Laurent
      non ce n’est pas crypté
      on peut tuneliser une liaison VNC en SSH
      je verrai si je peux écrire quelque chose là dessus
      cordialement
      François

      Répondre
      1. Laurent

        Ah ok,
        Bon ce n’est pas non plus absolument indispensable au quotidien.
        La plupart du temps en distant on intervient en ligne de commande.

        Mais il est vrai que si c’est possible cela peut être intéressant.

        Et de rien 🙂
        Bonne journée.

        Répondre
  13. CDBI30

    un grand Merci François
    Je viens de me faire une SD avec JESSIE
    Pour SAMBA, pas eu trop de problèmes
    Pour VNC, sans ton aide, je n’y serais pas arrivé
    Une remarque:
    Avant avec VINO sous WHEEZY, l’écran du RasPi suivait l’écran du PC de commande
    Plus maintenant
    Quant à VLC, toujours aussi merdique…se lance mais ne lit rien

    Répondre
  14. Ping : Bureau à distance avec VNC – pi4you.fr

  15. Hubert

    Bonjour
    Merci François pour ce tuto.
    VNC fonctionne sous rasbian Jessie (Version 8) avec systemd.

    Seul bémol , le copie collé de Windows sur rasbian ne fonctionne pas.
    Aurai tu une solution

    Répondre
  16. Hubert

    Merci François pour cette réponse
    Depuis ma demande de 10h39mn j’ai réussi a faire le copie/collé mais je bute toujours sur le démarrage.
    Procédure dans un terminal :
    1ere installation de autocutsel (sudo apt-get install autocutsel)
    2eme lancement de la commande (autocutsel -fork)

    référence :
    http://raspberrypi.stackexchange.com/questions/4474/tightvnc-copy-paste-between-local-os-and-raspberry-pi

    Problème : je n’ai pas trouvé comment lancer (autocutsel -fork) automatiquement à la mise sous tension avec systemd
    Y a t’il une solution ?

    Répondre
  17. piloo54

    Bonjour et Merci pour le TUTO

    une petit question, quel paramétre dois je modifier pour obtenir un affichage cloné ? car quand je prends mon rasp en vnc je ne déplace par en direct la souris .

    Merci d’ avance !

    Répondre
  18. fahdyezz

    Bonjour François,
    Suite à des problèmes de DD Usb (bad sectors), j’ai réinstallé Raspbian en passant de Wheezy à Jessie.
    Oh! Surprise! Impossible d’automatiser tightvncserver.
    Je furète ici et là et trouve une solution qui fonctionne: déplacement du shebang #/bin/sh en première ligne du script vncboot dans /etc/init.d sans ajouter le script dans ~/.config/autostart. Et là, le service vnc se lance automatiquement au démarrage de la Rasp.
    Ne constatant qu’ultérieurement ton renvoi du précédent tuto pour arriver sur cette page, je me demande quels sont les inconvénients de la méthode que j’ai utilisée et les avantages de passer par systemd.
    Cordialement.

    Répondre
    1. François MOCQ Auteur de l’article

      bonjour
      bah l’adoption de systemd a provoqué des discussions qui ne sont d’ailleurs pas finies, en particulier sur la dérive par rapport à la philosophie Linux qui dit que tout est fichier – que une tache = un programme – avec systemd on est passé à un démarrage différent (plus complexe pour les anciens habitués à init…)
      Mais bon on ne choisit pas, faut faire avec. Je ne sais pas trop ce que tu as pu faire – ou ne pas faire mais si tu as lu cet article tu as vu qu’il faut créer un service pour que tightvncserver soit lancé… pas simple 🙂
      La version de Raspbian sortie ces jours ci intègre VNC et simplifie grandement la prise de main à distance car il n’y a qu’une cas à cocher dans la config pour l’activer 😀 et tu as la main en doublon sur la session ouverte.
      bonne continuation
      cordialement
      françois

      Répondre
  19. fahdyezz

    Merci pour ta réponse.
    En fait, en plaçant #/bin/sh à la première ligne du script /etc/init.d/vncboot, c’est-à-dire avant le LSB: ###BEGIN INIT INFO et pas après ### END INIT INFO , il n’y a pas besoin de créer un script dans ~/.config/autostart . L’automatisation de tightvncserver est opérationnelle directement.
    Maintenant, effectivement, comme il y a VNC dans raspi-config, pourquoi se casser la tête?
    Sinon, une étude plus approfondie de systemd me semble impérative pour comprendre les implications (avantages/inconvénients) dans cette démarche de Linux. Ça me fait plus penser, pour l’instant, à:
    « pourquoi faire simple quand on peut faire compliqué? »

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Complétez ce captcha SVP * Time limit is exhausted. Please reload CAPTCHA.