Pour fournir plus de visibilité sur la façon dont les clusters Qumulo sont utilisés et gérés, nous avons récemment introduit un journal d'audit. Tout ce dont vous avez besoin pour l'utiliser est un serveur exécutant un syslog distant, que de nombreuses plates-formes de surveillance et d'alerte ont prêt à l'emploi. Une fois pointé sur un serveur de journaux, chaque nœud envoie des enregistrements de tout ce qui se passe, comme qui a fait quoi et si cela a fonctionné ou non. Lorsque les utilisateurs interagissent directement avec le cluster, comme via l'API, le journal signale simplement chaque action de l'utilisateur.
Les requêtes adressées à la plupart des points de terminaison d'API écriront des entrées simples et uniques dans le journal d'audit. Par exemple, si j'utilisais notre CLI pour exécuter qq restart_cluster, le journal d'audit montrerait ceci:
[box]2019-11-08T15:31:40 Blog-1 qumulo ::1,”Colin”,api,cluster_restart,ok,,””,””[/box]
Décomposons cela.
[box]2019-11-08T15:31:40 Blog-1 qumulo[/box]
Les trois premiers champs sont l'en-tête syslog standard. Ils incluent l'heure à laquelle l'opération s'est terminée, le nom du nœud qui a effectué l'opération (Blog-1) et «qumulo». La mise en forme de ceux-ci peut être facilement modifiée par le programme recevant vos journaux, pour rendre le journal d'audit CSV par exemple. Ils seront laissés de côté à partir d'ici.
[boite]::1,"Colin"[/boite]
Vient ensuite l'utilisateur qui a effectué l'opération. «Colin» est mon nom d'utilisateur local et «:: 1» est mon IP. Il s'agit de la version IPv6 de localhost, car j'utilise un «simcluster» pour les tests. Plus à ce sujet ici:
[boîte]api, cluster_restart, ok, "," ", ""[/box]
La dernière est l'opération qui a été exécutée. Les outils CLI Qumulo sont construits sur l'API, donc cette opération est étiquetée avec «api». D'autres opérations pourraient avoir «smb2» ou «nfs3» à cet endroit. "Cluster_restart" est la commande que j'ai exécutée. Si l'opération avait échoué, «ok» afficherait à la place l'erreur comme «api_permission_denied_error». Les autres sont des champs vides utilisés par les opérations qui nécessitent plus de détails.
Exemples de systèmes de fichiers
La même action du système de fichiers sur n'importe quel protocole devrait être presque identique dans le journal d'audit. Par exemple, voici le journal de moi créant un fichier sur NFS et un sur SMB:
… "1001",nfs3,fs_create_file,ok,3,"/nfs_file","" … "1001",nfs3,fs_write_metadata,ok,3,"/nfs_file","" … "Colin",smb2,fs_create_file,ok,4,"/smb_file","" … "Colin",smb2,fs_write_metadata,ok,4,"/smb_file",""
Les seules différences sont le fichier, le protocole et l'utilisateur, qui affiche 1001 car sur NFS, les seules identités d'utilisateur sont les UID. Les deux fois, il écrit les métadonnées séparément. L'avantage de cette approche est que la recherche dans le journal ne nécessite pas de connaître le protocole de l'opération que vous recherchez. Pour trouver les suppressions, il suffit de rechercher «supprimer», pas besoin de savoir que SMB l'appelle «délier».
Plongée
Jusqu'ici tout va bien. Si je monte à nouveau l'exportation NFS «/», quelles opérations seront enregistrées?
… "0",nfs3,nfs_mount,ok,,"","" … "0",nfs3,fs_read_metadata,ok,2,"/","" … "1001",nfs3,fs_read_metadata,ok,2,"/","" … "1001",nfs3,fs_read_metadata,fs_no_such_entry_error,,"/.Trash","" … "1001",nfs3,fs_read_metadata,fs_no_such_entry_error,,"/.Trash-1001",""
C'est surprenant! Je n'ai monté que l'exportation, je n'ai touché à aucun de ces autres fichiers. Il est logique que le système d'exploitation veuille vérifier les autorisations sur le répertoire que nous venons de monter, et sur les deuxième et troisième lignes, nous le faisons d'abord en tant que root (UID 0), puis avec mon UID, 1001. Le 2, "/" À la fin de la ligne signifie que nous avons regardé le répertoire racine, qui a l'ID de fichier 2. Les deux dernières lignes sont plus surprenantes, mais il s'avère qu'elles sont une vérification pour un type Unix-y de poubelle récupérable, un pour tout le monde et un pour mon UID spécifiquement. https://specifications.freedesktop.org/trash-spec/trashspec-1.0.html
Il existe toutes sortes de bizarreries comme celle-ci que le journal d'audit révèle. Voici un montage SMB du partage par défaut «Fichiers» de macOS 10.
… "Colin", smb2, smb_login, ok ,, "", ""… "Colin", smb2, share_connect, ok, 2, "\\ Blog-1 \ FILES", ""… "Colin", smb2, fs_fsstat , ok, 2, "/", ""… "Colin", smb2, fs_read_metadata, ok, 2, "/", ""… "Colin", smb2, fs_list_directory, ok, 2, "/", ""… "Colin", smb2, share_connect, ok, 0, "\\ Blog-1 \ IPC $", ""… "Colin", smb2, fs_open, fs_no_such_entry_error ,, "/. Hidden", ""
D'accord, nous nous connectons, nous connectons au partage, examinons son utilisation de l'espace (fsstat), puis vérifions les autorisations et le contenu du répertoire, très bien. Mais ensuite, il essaie de monter un partage que je n'ai même pas, «IPC $».
Et ça réussit! J'en ai trouvé Documentation, mais j'ai dû parcourir les anciennes notes de publication pour découvrir qu'il s'agit d'un partage caché spécial permettant aux programmes de communiquer via des canaux nommés. Enfin, il ne parvient pas à ouvrir le fichier «/.hidden», apparemment «l'une des trois façons dont un fichier peut être rendu invisible sous OS X. Ce fichier est semi-obsolète.» (La source: http://www.westwind.com/reference/OS-X/invisibles.html)
Déduplication
Il y a en fait encore plus de ces opérations étranges que le journal d'audit ne le montre. Par exemple, si je crée deux répertoires en utilisant mkdir dans le partage SMB…
… "Colin",smb2,fs_read_metadata,ok,2,"/","" … "Colin",smb2,fs_list_directory,ok,2,"/","" … "Colin",smb2,fs_create_directory,ok,5,"/dir1/","" … "Colin",smb2,fs_open,fs_no_such_entry_error,,"/","" … "Colin",smb2,fs_create_directory,ok,6,"/dir2/",""
Lorsque je crée le premier répertoire, il semble que le système d'exploitation vérifie de manière proactive que nous n'écrasons rien, mais cela ne semble pas le faire pour le deuxième répertoire. En fait, le journal d'audit dédoublonne les opérations du système de fichiers identiques en une minute, donc celles-ci se produisent toujours, nous ne les voyons tout simplement pas. Cela présente le plus d'avantages lors de la lecture et de l'écriture de fichiers volumineux, qui sont généralement lus et écrits en morceaux d'environ un mégaoctet. Non seulement cela réduit considérablement la taille du journal pour le stockage, mais il libère également la bande passante du réseau pour des choses plus importantes.
Ce sont tous des exemples simples; J'ai essayé d'auditer le processus d'ouverture d'un projet dans mon IDE et il en résulte des pages d'actions de lecture et d'ouverture qui ont échoué sur des fichiers de configuration dont je n'ai jamais entendu parler. Pour l'utilisateur final, c'est rapide et ça marche. Mais le cluster Qumulo ne peut pas dire quelle est l'action sous-jacente que l'utilisateur essaie de prendre, donc tout finit dans le journal d'audit. Et c'est la raison pour laquelle le journal d'audit est si bruyant: il enregistre ce que l'ordinateur fait, pas l'utilisateur.
Je vous laisse avec un dernier mystère. L'avant-dernière ligne du dernier exemple:
[boîte]… "Colin", smb2, fs_open, fs_no_such_entry_error,, "/",""[/box]
Il ne parvient pas à ouvrir le répertoire que nous venons d'ajouter, donc je suppose qu'il doit l'ouvrir en tant que fichier ou lien symbolique ou quelque chose. Mais pourquoi? N'est-ce évidemment pas encore un répertoire?
À moins que quelqu'un veuille parcourir des couches de code OS X, le monde ne le saura peut-être jamais.
