Nous chez Veeam adorons les logs. Étant donné que la plupart de nos solutions sont modulaires, elles génèrent un grand nombre de logs. Puisque notre domaine d'activité est d'assurer la protection de vos données (c'est-à-dire votre tranquillité d'esprit), les logs doivent non seulement enregistrer chaque détail, mais aussi le faire de manière assez précise. Cela est nécessaire pour qu'en cas de problème, il soit clair comment cela s'est produit, qui est responsable et quelles actions doivent être prises par la suite. C'est un peu comme en criminologie : on ne sait jamais quel petit détail peut aider à retrouver le coupable de l'affaire de Laura Palmer.
C'est pourquoi j'ai décidé de me lancer dans une série d'articles où je vais expliquer progressivement ce que nous écrivons dans les logs, où nous les stockons, comment ne pas perdre la tête face à leur structure et ce qu'il faut chercher à l'intérieur.
Pourquoi une série d'articles et pourquoi ne pas tout décrire d'un coup ?
Il serait assez laborieux de simplement énumérer quel log se trouve où et ce qu'il contient. De plus, il est effrayant de penser à maintenir cette information à jour. Dresser une liste de tous les types de logs dans Veeam Backup & Replication serait un tableau de plusieurs pages en petits caractères. Et même alors, cette liste ne serait pertinente que le jour de la publication, car avec la sortie d'un nouveau patch, de nouveaux logs peuvent apparaître, la logique des informations stockées dans les anciens peut changer, etc. Il serait donc beaucoup plus bénéfique d'expliquer leur structure et la nature des informations qu'ils contiennent. Cela permettra de mieux s'orienter sur le terrain que de mémoriser bêtement des noms.
Donc, pour ne pas plonger tête la première dans un océan de textes, faisons un travail préparatoire dans cet article. Aujourd'hui, nous n'allons pas entrer dans les logs eux-mêmes, mais aborder les choses de loin : nous allons établir un glossaire et discuter un peu de la structure de Veeam en ce qui concerne la génération de logs.
Glossaire et jargon
Ici, je tiens tout d'abord à m'excuser auprès des défenseurs de la pureté de la langue russe et des témoins du dictionnaire d'Ojégov. Nous aimons tous notre langue maternelle, mais l'industrie informatique maudite fonctionne en anglais. Nous n'avons pas inventé cela, c'est ainsi que l'histoire s'est déroulée. Je ne suis pas coupable, c'est lui qui est venu (c)
Dans notre domaine, le problème des anglicismes (et du jargon) présente des spécificités. Lorsque des mots innocents comme « hôte » ou « invité » désignent des choses très concrètes pour le reste du monde, une partie du globe continue à se débattre héroïquement, cherchant dans les dictionnaires. Et l'argument strictement obligatoire « Eh bien, au travail... ».
De plus, il y a notre propre terminologie qui est propre aux produits Veeam, même si certains mots ont fait leur chemin dans le langage courant. Il est donc important que nous convenions de ce que signifie chaque terme, et à l'avenir, par le mot « invité », j’entends exactement ce qui est écrit dans ce chapitre, et non ce à quoi vous êtes habitué au travail. Et oui, ce n'est pas un caprice personnel, ce sont des termes établis dans l'industrie. Il est un peu vain de s'y opposer. Bien que je sois toujours pour des discussions dans les commentaires.
Malheureusement, il y a énormément de termes dans notre travail et nos produits, donc je ne vais pas essayer de tous les énumérer. Juste les plus basiques et nécessaires pour survivre dans cet océan d'informations sur les sauvegardes et les journaux. Pour ceux qui sont intéressés, je peux aussi d'un collègue sur les bandes, où il a également dressé une liste de termes relatifs à cette partie de la fonctionnalité.
Hôte : Dans le monde de la virtualisation, c'est une machine avec un hyperviseur. Physique, virtuel, cloud — peu importe. Si quelque chose exécute un hyperviseur (ESXi, Hyper-V, KVM, etc.), alors ce « quelque chose » est appelé un hôte. Que ce soit un cluster de dix racks ou votre ordinateur portable avec une lab sur une petite demi-douzaine de machines virtuelles — si vous avez lancé un hyperviseur, alors vous êtes devenu un hôte. Parce qu'un hyperviseur héberge des machines virtuelles. Il existe même une légende selon laquelle VMware a voulu établir une solide association du mot hôte précisément avec ESXi, mais elle n'a pas pu y parvenir.
Dans le monde moderne, le concept d'« hôte » s'est pratiquement amalgamé avec celui de « serveur », ce qui complique la communication, notamment dans le cadre de l'infrastructure Windows. Ainsi, toute machine sur laquelle se trouve un service intéressant pour nous peut être qualifiée d'hôte. Par exemple, dans les journaux WinSock, le mot hôte est utilisé pour désigner tout et n'importe quoi. Le classique « Hôte non trouvé » en est un exemple. Ainsi, nous devons nous baser sur le contexte, mais rappelons-nous — dans le monde de la virtualisation, un hôte est celui qui héberge des invités (à ce sujet, deux lignes plus bas).
Parmi les jargons locaux (plutôt des acronymes, dans ce cas), on se souvient que VMware c'est VI, vSphere c'est VC, et Hyper-V c'est HV.
Invité : Une machine virtuelle fonctionnant sur un hôte. Il n'est même pas nécessaire d'expliquer, tout est tellement logique et simple. Cependant, beaucoup essaient d'y apporter d'autres significations.
Pourquoi ? Je ne sais pas.
OS invité, donc, le système d'exploitation de la machine virtuelle. Et ainsi de suite.
Job de Sauvegarde/Réplication : C'est un jargon purement VMware désignant l'une des tâches. Backup job == Job de Sauvegarde. Comment le traduire élégamment en français ? Personne n'a trouvé, donc tout le monde dit « job ». En mettant l'accent sur la dernière syllabe.
Oui, il en est ainsi, ils disent simplement « job ». Même dans les e-mails, ils l'écrivent comme cela, et tout va bien.
Des travaux de sauvegarde, des tâches de sauvegarde, etc., merci, mais non. Juste « job », et vous serez compris. L'essentiel est de mettre l'accent sur la dernière syllabe.
Sauvegarde (backup, bécape. Pour les puristes, on peut dire bakup) : Au-delà de l'évident (une copie de sauvegarde de données quelque part), cela signifie aussi la tâche elle-même (les trois lignes ci-dessus, au cas où vous auriez déjà oublié), qui résulte du fichier de sauvegarde. Probablement, les anglophones sont trop paresseux pour dire chaque fois I ran my backup job, donc ils disent simplement I ran my backup, et tout le monde se comprend parfaitement. Je propose de soutenir cette belle initiative.
Consolidation : Un terme apparu dans ESXi 5.0. Option dans le menu de gestion des snapshots, lancé pour supprimer ce qu'on appelle les snapshots orphelins. C'est-à-dire des snapshots qui existent physiquement, mais qui ont disparu de la structure logique affichée. Théoriquement, ce processus ne devrait pas affecter les fichiers affichés dans le gestionnaire de snapshots, mais il arrive que cela se produise. L'essence du processus de consolidation est que les données du snapshot (disque enfant) sont écrites dans le disque principal (disque parent). Le processus de fusion des disques s'appelle un merge. Si une commande de consolidation a été donnée, l'entrée du snapshot peut être supprimée de la base avant que le snapshot ne soit fusionné et supprimé. Et si le snapshot n'a pas pu être supprimé pour une raison quelconque, ces fameux snapshots orphelins apparaissent. VMware a un Et nous avons également écrit à leur sujet .
Datastore : C'est un concept très large, mais dans le monde de la virtualisation, il désigne l'endroit où sont stockés les fichiers des machines virtuelles. Cependant, il est crucial de bien comprendre le contexte et, en cas de moindre doute, de préciser ce que votre interlocuteur entend exactement.
Proxy : Il est important de comprendre dès le départ que Veeam Proxy n'est pas tout à fait la même chose que ce à quoi nous sommes habitués sur le web. Dans le cadre des produits Veeam, c'est une entité qui s'occupe de transférer des données d'un endroit à un autre. En termes simples, VBR est le serveur principal, tandis que le proxy agit comme ses « chevaux de travail ». En d'autres termes, le proxy est une machine à travers laquelle passe le trafic et sur laquelle sont installés les composants VBR qui aident à gérer ce trafic. Par exemple, cela peut être le transfert de données d'un canal à un autre ou simplement connecter des disques (mode HotAdd).
Repository : Techniquement, il s'agit simplement d'un enregistrement dans la base VBR indiquant l'endroit où sont stockées les sauvegardes et comment se connecter à cet endroit. En pratique, cela peut être un simple partage CIFS, un disque séparé, un serveur ou un bucket dans le cloud. Encore une fois, nous restons dans le contexte, mais comprenons que le repository est simplement l'endroit où se trouvent vos sauvegardes.
Snapshot : Les amateurs de grammaire oxfordienne préfèrent dire snÉpshot ou snEépShot, mais la majorité non instruite l'emporte grâce à un plus grand nombre. Pour ceux qui ne le savent pas, c'est une technologie qui permet de restaurer l'état d'un disque à un moment donné. Cela se fait soit par un redirigement temporaire des opérations I/O loin du disque principal, ce qui sera alors appelé un snapshot RoW (Redirect on Write), soit en déplaçant les blocs réécrits de votre disque vers un autre, ce qui sera alors appelé un snapshot CoW (Copy on Write). C'est grâce aux larges possibilités d'application de ces fonctions que Veeam peut réaliser sa magie de sauvegarde. Strictement parlant, ce n'est pas le seul, mais cela fait partie des prochaines versions.
Dans la documentation et les journaux d'ESXi, ce terme est chaotique, et dans le contexte des snapshots, on peut rencontrer à la fois les snapshots eux-mêmes, le redo log et même le delta disk. Dans la documentation de Veeam, il n'y a pas ce désordre, et un snapshot est un snapshot, tandis que le redo log est précisément le fichier REDO, créé par un disque non persistant. Les fichiers REDO sont supprimés lors de l'arrêt de la machine virtuelle, il est donc erroné de les confondre avec des snapshots, ce qui mène à l'échec.
Synthétique : Les sauvegardes synthétiques se rapportent aux sauvegardes incrémentales inversées et aux sauvegardes forever forward. Si vous n'avez jamais rencontré ce terme, c'est simplement un des mécanismes utilisés pour construire une chaîne de sauvegarde. Cependant, dans les journaux, on peut également rencontrer la notion de Transform, qui est utilisée dans le cadre de la création de copies complètes à partir d'incréments (synthetic full).
Tâche : C'est le processus de traitement de chaque machine individuelle dans le cadre d'un job. Autrement dit : si vous avez un job de sauvegarde qui inclut trois machines, alors chaque machine sera traitée dans le cadre d'une tâche individuelle. En tout, il y aura quatre journaux : un principal pour le job et trois pour les tâches. Cependant, il y a un important nuance : avec le temps, le mot « tâche » est devenu trop polysémique. Lorsque nous parlons de journaux généraux, nous entendons que la tâche est précisément une VM. Mais il y a aussi des « tâches » sur le proxy et le dépôt. Là, cela peut signifier un disque virtuel, une machine virtuelle ou l'ensemble du job. Il est donc important de ne pas perdre le contexte.
Veeam %name% Service: Au service de sauvegardes réussies travaille plusieurs services, dont la liste peut être trouvée dans le module standard. Leurs noms reflètent assez clairement leur essence, mais parmi les égaux, il y en a un qui est le plus important — Veeam Backup Service, sans lequel les autres ne fonctionneront pas.
VSS : Techniquement, VSS doit toujours désigner le Microsoft Volume Shadow Copy Service. En fait, beaucoup l'utilisent comme synonyme de Application-Aware Image Processing. Ce qui est, bien sûr, catégoriquement incorrect, mais c'est une histoire du genre « tout véhicule tout terrain peut être appelé un Jeep et on vous comprendra ».
Des journaux fantastiques et les lieux où ils résident
Je veux commencer ce chapitre par la révélation d'un grand secret — quelle heure est affichée dans les journaux ?
Retenez :
- ESXi écrit toujours les journaux en UTC+0.
- vCenter tient les journaux selon l'heure de son fuseau horaire.
- Veeam tient les journaux selon l'heure et le fuseau horaire du serveur sur lequel il est installé.
- Et seule la journalisation Windows au format EVTX n'est liée à rien. Lors de l'ouverture, l'heure est recalculée en fonction de la machine sur laquelle elles sont ouvertes. C'est l'option la plus pratique, bien qu'il puisse y avoir des difficultés même avec cela. La seule difficulté tangible est la différence de locales. C'est pratiquement un chemin garanti vers des journaux illisibles. Oui, il existe des moyens de résoudre cela, mais ne nous disputons pas sur le fait que tout dans l'informatique fonctionne en anglais, et convenons de toujours définir la locale anglaise sur les serveurs. S'il vous plaît.
Maintenant, parlons des endroits où résident les journaux et comment les obtenir. Dans le cas de VBR, il existe deux approches.
La première option convient si vous n'avez pas envie de fouiller dans le tas de fichiers liés à votre problème. Pour cela, nous avons un assistant séparé, auquel vous pouvez indiquer un travail spécifique et une période précise pour laquelle vous avez besoin des journaux. Ensuite, il parcourra les dossiers et rassemblera tout le nécessaire dans une seule archive. Les détails sur où le chercher et comment l'utiliser sont décrits dans .
Cependant, l'assistant ne collecte pas les journaux de toutes les tâches et, par exemple, si vous avez besoin d'examiner les journaux du restaurant, du failover ou du failback, votre chemin mène au dossier %ProgramData%/Veeam/Backup. C'est le principal stockage de journaux VBR, et %ProgramData% est un dossier caché, ce qui est normal. D'ailleurs, l'emplacement par défaut peut être redéfini à l'aide d'une clé de registre de type REG_SZ : LogDirectory dans la branche HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Sur les machines Linux, les journaux des agents de travail doivent être recherchés dans /var/log/VeeamBackup/, si un compte root ou sudo est utilisé. Si vous n'avez pas de telles autorisations, recherchez les journaux dans /tmp/VeeamBackup.
Pour l'agent Veeam pour %OS_name%, les journaux doivent être recherchés dans %ProgramData%/Veeam/Endpoint ou %ProgramData%/Veeam/Backup/EndpointDeep Speech /var/log/veeam respectivement.
Si vous utilisez le traitement d'image sensible aux applications (et il y a de fortes chances que vous l'utilisiez), la situation est un peu plus compliquée. Vous aurez besoin des journaux de notre helper, qui sont stockés à l'intérieur de la machine virtuelle elle-même, ainsi que des journaux VSS. Les détails sur comment et où obtenir ce bonheur sont décrits dans . Et, bien sûr, il y a sur la collecte des journaux système nécessaires.
Les événements Windows peuvent être collectés selon . Si vous utilisez Hyper-V, cela se complique car vous aurez également besoin de tous ses journaux dans la branche Applications and Service Logs > Microsoft > Windows. Bien qu'il soit toujours possible de suivre une voie plus crue en prenant simplement tous les objets dans %SystemRoot%System32winevtLogs.
Si quelque chose se casse pendant l'installation ou la mise à niveau, tout ce dont vous avez besoin se trouve dans le dossier %ProgramData%/Veeam/Setup/Temp. Bien que je ne cache pas que dans les événements du système d'exploitation, vous pouvez trouver des informations plus utiles que dans ces journaux. Les éléments intéressants restants se trouvent dans %Temp%, mais là-bas, ce sont principalement des journaux d'installation de logiciels associés, tels que la base de données, des bibliothèques .Net, etc. Sachez que Veeam s'installe à partir d'un msi, et tous ses composants sont également installés en tant que paquets msi séparés, même si cela n'a pas été affiché dans l'interface graphique. Par conséquent, si l'installation de l'un des composants échoue, toute l'installation de VBR sera arrêtée. Il faut donc se rendre dans les journaux et vérifier ce qui a exactement échoué et à quel moment.
Et un dernier conseil : si vous obtenez une erreur lors de l'installation, ne vous précipitez pas pour appuyer sur OK. Prenez d'abord les journaux, puis appuyez sur OK. Ainsi, vous obtiendrez un journal se terminant au moment de l'erreur, sans les éléments indésirables à la fin.
Il arrive aussi que vous deviez plonger dans les journaux vSphere. C'est une tâche peu gratifiante, mais, en retroussant vos manches, il faut bien le faire. Dans le cas le plus simple, nous aurons besoin des journaux d'événements de la machine virtuelle vmware.log, qui se trouvent à côté de son fichier .vmx. Dans un cas plus compliqué, ouvrez Google et demandez où se trouvent les journaux pour votre version d'hôte, car VMware aime changer cet emplacement d'une version à l'autre. Voici, par exemple, , et voici pour . Pour les journaux vCenter, répétez la procédure . Mais en général, nous serons intéressés par les journaux d'événements de l'hôte hostd.log, les événements des hôtes gérés par vCenter vpxa.log, les journaux du noyau vmkernel.log et les journaux d'authentification auth.log. Et dans les cas les plus avancés, un journal SSO pourrait être utile, qui se trouve dans le dossier SSO.
C'est encombrant ? Confus ? Effrayant ? Et pourtant, ce n'est même pas la moitié des informations avec lesquelles notre support travaille au quotidien. Ils sont donc vraiment très impressionnants.
Composants Veeam
Et en guise de conclusion de cet article introductif, parlons un peu des composants de Veeam Backup & Replication. Car lorsque vous cherchez la raison des problèmes, il est bon de comprendre comment est constitué le patient.
Ainsi, comme tout le monde le sait sûrement, Veeam Backup est une application basée sur SQL. Cela signifie que tous les paramètres, toutes les informations et tout ce qui est nécessaire au bon fonctionnement se trouve dans sa base de données. À vrai dire, dans deux bases, si nous parlons de la liaison entre VBR et EM : VeeamBackup et VeeamBackupReporting, respectivement. C'est ainsi que cela fonctionne : chaque fois que nous installons une nouvelle application, une nouvelle base apparaît. Pour ne pas mettre tous nos œufs dans le même panier.
Mais pour que tout cela fonctionne harmonieusement, nous aurons besoin d'un ensemble de services et d'applications qui relieront tous les composants. À titre d'exemple, voici à quoi cela ressemble dans l'un de mes laboratoires :
En tant que chef d'orchestre principal, Veeam Backup Service. C'est lui qui est responsable des échanges d'informations avec les bases. Il est également chargé de démarrer toutes les tâches, de gérer l'orchestration des ressources allouées et fonctionne comme un centre de communication pour diverses consoles, agents et autres. En gros, sans lui, rien ne fonctionnerait, mais cela ne signifie pas qu'il fait tout tout seul.
L'exécution de ses idées est assistée par Veeam Backup Manager. Ce n'est pas un service, mais une entité qui lance les tâches et surveille le processus de leur exécution. Ce sont les bras du service de sauvegarde qui se connectent aux hôtes, créent des clichés, surveillent la rétention, etc.
Mais revenons à la liste des services. Veeam Broker Service. Il est apparu dans la v9.5 (et ce n'est pas un mineur de crypto, comme certains l'ont pensé à l'époque). Il collecte des informations sur les hôtes VMware et maintient leur actualité. Mais ne vous précipitez pas à écrire des commentaires en colère disant que nous vous espionnons et que nous divulguons tous vos identifiants de connexion. C'est en réalité un peu plus simple. Lorsque vous lancez une sauvegarde, la première étape consiste à se connecter à l'hôte et à mettre à jour toutes les informations sur sa structure. C'est un processus assez lent et fastidieux. Rappelez-vous combien de temps cela prend pour se connecter via l'interface web, en gardant à l'esprit que seule la couche supérieure est prise en compte. Ensuite, il faut aussi développer toute la hiérarchie jusqu'à l'endroit voulu, d'ailleurs. En un mot, c'est horrible. Si vous lancez une dizaine de sauvegardes, cela signifie que chaque tâche doit passer par cette procédure. Dans le cas de grandes infrastructures, ce processus peut prendre dix minutes ou plus. C'est pourquoi il a été décidé de créer un service distinct pour cela, permettant d'obtenir toujours des informations à jour. Lors de son démarrage, il vérifie et scanne toute l'infrastructure ajoutée, puis tente de fonctionner uniquement au niveau des changements incrémentaux. Ainsi, même si vous lancez simultanément cent sauvegardes, elles demanderont toutes des informations à notre courtier, au lieu de déranger les hôtes avec leurs requêtes. Si vous vous inquiétez pour les ressources, selon nos calculs, il ne faut qu'environ 100 Mo de mémoire pour 5000 machines virtuelles.
Ensuite, nous avons Veeam Console. Également connue sous le nom de Veeam Remote Console, ou Veeam.Backup.Shell. C'est cette interface graphique que nous voyons sur les captures d'écran. C'est simple et évident : la console peut être lancée de n'importe où, tant que c'est sous Windows et qu'il y a une connexion au serveur VBR. La seule chose que l'on peut dire : le processus FLR va monter les points localement (c'est-à-dire sur la machine où la console est lancée). Eh bien, et les différents Veeam Explorers seront également lancés localement, car ils font partie de la console. Mais ça, c'est déjà un autre sujet…
Le prochain service intéressant est Veeam Backup Catalog Data Service. Dans la liste des services, connu sous le nom de Veeam Guest Catalog Service. Il est chargé d'indexer les systèmes de fichiers sur les machines invitées et remplit le dossier VBRCatalog de ces connaissances. Utilisé uniquement là où l'option d'indexation est activée. Et il est judicieux de l'activer seulement si vous disposez de l'Enterprise Manager. Donc, un conseil bienveillant : ne déclenchez pas l'indexation simplement comme ça, si vous n'avez pas d'EM. Préservez vos nerfs et le temps du support.
On peut également noter parmi d'autres services importants Veeam Installer Service, qui permet la livraison et l'installation des composants nécessaires sur les proxys, les dépôts et d'autres passerelles. En fait, il transporte les paquets .msi nécessaires vers les serveurs et en effectue l'installation.
Veeam Data Mover — grâce à des agents auxiliaires exécutés sur les proxys (et pas seulement) il s'occupe du transfert des données. Par exemple, lors d'une sauvegarde, un agent lira les fichiers depuis le datastore de l'hôte, tandis qu'un autre les enregistrera soigneusement dans la sauvegarde.
Il est important de souligner un point souvent soulevé par les clients — la différence entre les versions des services et les informations dans l'outil Programmes et fonctionnalités. Oui, la liste sera identique, mais les versions peuvent être complètement différentes. Cela ne semble pas très sain d'un point de vue visuel, mais c'est tout à fait normal si tout fonctionne correctement. Par exemple, la version du service Installer est largement en retard par rapport aux autres. Une horreur et un cauchemar ? Non, car il ne se réinstalle pas complètement, mais se contente de mettre à jour son DLL. Dans le patch v9.5 U4, un cauchemar s’est produit pour le support technique : lors de la mise à jour, tous les services ont reçu de nouvelles versions, sauf le plus important. Dans le patch U4b, le service de transport a devancé tous les autres de deux versions (selon les chiffres). Et c'est aussi normal — une sérieuse faille a été trouvée, donc il a reçu une mise à jour supplémentaire par rapport aux autres. En résumé : la différence de versions PEUT poser problème, mais si une différence est présente et que tout fonctionne correctement, alors c'est probablement normal. Mais personne ne vous interdit de clarifier cela auprès du support technique.
Ce sont les soi-disant services obligatoires ou Mandatory services. Mais il y a aussi une série de services auxiliaires, comme le Tape Service, le Mount Service, le vPowerNFS Service, etc.
Pour Hyper-V, c'est tout pareil, sauf qu'il y a un spécifique Veeam Backup Hyper-V Integration Service et son propre pilote pour travailler avec le CBT.
Et à la fin, parlons de ceux qui travaillent sur des machines virtuelles pendant la sauvegarde. Pour l'exécution des scripts pre- et post-freeze, pour la création de copies instantanées, la collecte de métadonnées, le traitement des journaux des transactions SQL et d'autres tâches, on utilise Veeam Guest Helper. Et si une indexation des systèmes de fichiers se produit, Veeam Guest Indexer . Ce sont des services temporaires déployés pendant la sauvegarde et supprimés après.
Dans le cas des machines Linux, tout est beaucoup plus simple grâce à la richesse des bibliothèques intégrées et des possibilités offertes par le système lui-même. Par exemple, l'indexation se fait via mlocate.
C'est tout pour l'instant.
Je ne veux pas vous accabler davantage et je considère cette brève introduction à l'univers de Veeam comme terminée. Oui, nous n’avons pas encore abordé les journaux, mais croyez-moi, pour que les informations qu'ils contiennent ne ressemblent pas à un flot de conscience déconnecté, une telle introduction est absolument nécessaire. Je prévois de passer aux journaux eux-mêmes seulement dans le troisième article, et le sujet du prochain sera d'expliquer qui génère les journaux, ce qui est exactement affiché dans ceux-ci et pourquoi de cette manière et non d'une autre.
Source : habr.com
