Tuesday, November 29, 2016

CentOS - 15 : système de fichiers - arborescence

Je ne savais pas comment titrer ce billet de blogue...

Il s'agit de présenter la hiérarchie du système de fichiers qui se ramifie à partir de root ou "/".

Voici une liste des répertoires qui se trouvent à la racine de l'arborescence :



Dans les paragraphes suivants, je veux présenter chacun avec une description plus ou moins concise.


bin

Ce répertoire contient des binaires importants comme :

  • cat
  • cp (copier fichiers ou répertoires)
  • date (afficher la date et l'heure)
  • hostname (afficher le nom d'hôte de la machine)
  • ls (afficher le contenu d'un répertoire)
  • mkdir (créer un répertoire)
  • mount (monter un système de fichiers)
  • mv (déplacer ou renommer un fichier)
  • pwd (afficher l'emplacement dans l'arborescence où l'utilisateur se trouve)
  • rm (supprimer un fichier)
  • rmdir (supprimer un répertoire)
  • su (changer l'identité de l'utilisateur)
  • umount (démonter un système de fichier)

Les noyaux (shells) comme bash s'y trouvent aussi.


boot

Ce répertoire contient des fichiers nécessaires pour le démarrage. Cependant, les fichiers de configuration pour les chargeurs de démarrage (boot loaders - comme GRUB) résident dans le répertoire /etc. Qui plus est, d'autres fichiers, dont certains servant à faire démarrer ou éteindre la machine, se trouvent dans le répertoire /sbin (présenté plus bas).

Le noyau système se trouve ici.


dev

Ce répertoire contient les fichiers représentant les périphériques branchés à la machine : les disques durs, les lecteurs de CD/DVD/disquettes, carte son, clavier et souris. Le premier disque dur de type SCSCI sera /dev/sda et le second /dev/sdb, par exemple.

Ces fichiers se créent de manière dynamique lors du démarrage du système d'exploitation et au fur et à mesure que les périphériques sont détectés. C'est le service udev qui s'en occupe.


etc

Ce répertoire contient tous les fichiers de configuration du système. Ce ne sont pas des fichiers binaires qui se trouvent ailleurs, dans /bin, ou dans /sbin par exemple.

Note : le répertoire /etc/sysconfig est spécifique à RHEL/CentOS.

Quelques exemples :

/etc/hosts

C'est un fichier qui associe un nom d'hôte à une adresse IP.

/etc/httpd

Ce sont des fichiers pour le serveur web Apache.

/etc/services



home

Ce répertoire contient les répertoires personnels des utilisateurs, donc un sous-répertoire pour chaque utilisateur. Ce répertoire peut devenir assez grand si on y entrepose des images ou des extraits vidéos.


lib et lib64

Ces répertoires contiennent des "bibliothèques" que le système utilise en exécutant les programmes dans /bin et /sbin. S'il s'agit d'un système à 32 bits, il utilise /lib mais /lib64 pour les systèmes à 64 bits. Ce sont les équivalents des .dll dans le monde de Windows.



media et mnt

C'est le point de montage par défaut où nous pouvons monter des systèmes de fichiers ou des périphériques, /mnt/floppy ou mnt/cdrom par exemple. /media est pour les lecteurs de CD/DVD et USB. /mnt est plutôt pour les systèmes de fichiers.


opt

C'est pour les logiciels qui ne font pas partie du système d'exploitation, des programmes de bureautique (traitement de texte, etc.) de tierce partie par exemple.


proc

Ce répertoire contient ce qu'on a décrit comme des "pseudo-fichiers" qui montrent l'état du noyau (shell).


root

C'est le répertoire "personnel" de root. Il s'agit, paraît-il, de garder tous les éléments de root dans un répertoire plutôt que de les voir s'accumuler à la racine proprement dite, soit "/".


sbin

Ce répertoire contient des programmes (ou "binaires") pour la gestion du système d'exploitation, et en particulier pour le démarrage, la fermeture, et l'administration des disques. Parmi ces binaires, nous comptons :

  • fdisk
  • fsck.* (vérification des disques)
  • grub
  • ifconfig
  • mkfs.* (remplacer l'astérique par les différents systèmes de fichiers : ext3, ext4, xfs, par exemple).
  • reboot
  • shutdown


En effet, Linux distingue les binaires en général et les binaires pour l'administration du système, les premiers se trouvant sous /bin et les seconds sous /sbin.

sbin signifie "system binaries".

Mais ce n'est pas tout...


usr

D'autres binaires peuvent se trouver sous /usr/bin et /usr/sbin ou encore /usr/local/sbin.

Voici quelques exemples :

  • ftp
  • telnet

Ce sont donc des binaires pour les utilisateurs à la différence des binaires pour le système, même si la distinction n'est toujours évidente.

Autrefois, il paraît que /usr contenait tous les objets associés à l'utilisateur y compris ceux qu'on mettrait plutôt dans /home aujourd'hui.


tmp

C'est ici que CentOS enregistre les fichiers temporaires. De temps en temps, le contenu de ce répertoire est effacé (Je ne sais pas à quelle fréquence). Ce répertoire peut se trouver sur un système de fichier spécial nommé tmpfs (encore une différence avec Windows).

Note : oui, je sais que l'ordre alphabétique n'a pas été respecté parce que je voulais faire mettre /sbin et /usr l'un après l'autre, s'agissant tous deux de répertoires de fichiers binaires, et seulement ensuite /tmp.


var

Le répertoire /var contient des fichiers de taille "variable" d'où son nom. Il s'agit, par exemple, de fichiers associés à l'impression (le fichier "spool"), à la journalisation, et apparemment de fichiers temporaires qui ne résident pas dans /tmp.



Saturday, November 12, 2016

CentOS - 14 : systèmes de fichiers

Les systèmes de fichiers servent à organiser le stockage des données sur un support comme les disques durs ou les médias amovibles (disquette, clé USB) et à présenter ces données à l'utilisateur.

CentOS 7 est capable d'utiliser divers systèmes, comme, par exemple :
  • ext3
  • ext4
  • XFS
  • GFS2
  • swap

En ce moment, XFS constitue le système de fichiers par défaut de CentOS 7. Il possède toutes les qualités d'un système de fichiers moderne : journalisation, défragmentation et optimisation pour les fichiers de grande taille.

Autrefois, ext3 et ext4 étaient les choix préférés, et encore aujourd'hui ext4 reste une option tout à fait sérieuse. Comme XFS, il offre les fonctions de journalisation et de défragmentation (ce qui manque à ext3).

GFS2 est pour le stockage SAN.

Le système de fichiers swap est adapté spécialement pour les partitions swap dont le rôle correspond au fichier de pagination sous Windows. Dans le monde de Linux, cependant, il ne s'agit pas d'un simple fichier de pagination mais d'une partition de disque avec un système de fichiers conçu exprès pour cette fonction.

Note: il est possible d'utiliser un simple fichier sous Linux aussi mais cette solution serait moins efficace.

A ce sujet, il est recommandé d'avoir une taille de partition swap 2 fois la quantité de mémoire vive pour une quantité de mémoire vive jusqu'à 2 Go. Au-delà, la recommandation est d'égaler la quantité de mémoire vive plus 2 Go.


Comment créer un système de fichiers ?

Avec la commande mkfs

Nous ajoutons un point (.) suivi par le type de système de fichiers souhaité, et puis, la partition où nous voulons créer le système, par exemple :

mkfs.xfs /dev/sdb1

mkfs.ext4 /dev/sdb2

Nous pouvons donner une étiquette avec le paramètre -L :

mkfs.ext4 -L /databases /dev/sdb2

Et voilà, les partitions sdb1 et sdb2 ont désormais un système de fichiers.

Mais dans le monde de Linux, cela n'accomplit pas grand chose en soi.

Encore faut-il créer un "point de montage" (mount point), c'est-à-dire un répertoire dans lequel la partition sera montée.

Au fond, il s'agit d'inscrire le nouveau système de fichiers parmi les autres fichiers de l'arborescence. Nous pouvons bien dire "fichiers", car les répertoires, chez Linux, sont simplement des fichiers capables de contenir d'autres fichiers.

Quand nous naviguons dans l'arborescence et entrons dans ce répertoire (le point de montage), nous accédons, en fait, à la partition que nous avons montée (et aux fichiers qui s'y trouvent).

A retenir : c'est le système de fichiers choisi pour la partition qui permet d'y organiser les fichiers et aussi, qui nous permet de les voir et de les manipuler.

A retenir : le répertoire donnant accès au nouveau système de fichiers s'appelle le "point de montage".



Comment monter le système de fichiers ?

D'abord, je crée un répertoire à la racine (root) que je nomme "vol" (ce n'est qu'un exemple - nous sommes libres de choisir le nom qui nous convient) :

mkdir /vol

Les concepts de "partition" et de "volume" sont comparables et, en faisant des recherches sur l'emplacement préféré pour ces points de montage, j'ai lu que certains suivent une norme Macintosh et les mettent dans un répertoire avec ce nom (/vol ou /volume). Ce choix me convient. En fait, nous pourrions nommer le répertoire ce que nous voudrions et le créer ailleurs du reste. On pourrait utiliser le répertoire /mnt mais j'ai compris que certains préfèrent que ce soit réservé aux montages temporaires (?).

Ensuite, je monte le système de fichiers dans notre point de montage (le répertoire /vol) :

mount /dev/sdb2 /vol

Allons voir ce que cela donne.

Nous pouvons observer les systèmes de fichiers montés avec la commande "df". Je vais exécuter la commande avec le paramètre "h" qui signifie, en substance, "humain" ou plus précisément "human readable".

Voici le statut quo avant que j'exécute la commande mount ci-dessus :


Il n'y a que la partition /dev/sda1, montée dans le répertoire /boot.

Note : la partition /dev/sda1 a pour système de fichiers xfs, ce que nous pourrions voir avec le paramètre "T", soit "df -T" :



Et voici ce que nous voyons après :


Nous avons donc monté une nouvelle partition / nouveau système de fichiers : /dev/sdb2 monté dans le répertoire /vol.

Nous pouvons obtenir d'autres renseignements avec la commande mount, sans paramètres mais avec grep pour limiter la sortie aux systèmes de fichiers associé avec (dans notre cas) le répertoire /vol :





Comment éditer le fichier fstab

(Afin que notre système de fichiers soit monté automatiquement à chaque démarrage)

En pratique, nous voudrions le plus souvent que le système d'exploitation monte notre nouveau système de fichiers à chaque démarrage sans intervention manuelle. Cela peut s'accomplir par la modification du fichier fstab auquel le système d'exploitation a recours pour gérer le montage des systèmes de fichiers.

Voici le contenu de ce fichier par défaut (du moins dans mon installation de CentOS 7) :


Note : c'est la commande suivante qui affiche le contenu de fstab:

cat /etc/fstab

Nous devons ajouter notre nouveau système de fichiers en le désignant par un des moyens suivants :

  • le chemin de la partition, par exemples : /dev/sdb2
  • l'UUID de la partition (universally unique identifier - nous le verrons plus bas)
  • l'étiquette (le cas échéant), par exemple : "/databases"

L'UUID est le meilleur choix.

L'étiquette (ou "label") n'est pas obligatoire, n'est donc pas nécessairement présente, et rien n'empêcherait un administrateur inattentif de désigner deux systèmes de fichiers avec la même étiquette.

Quant au chemin de la partition, il pourrait changer si un nouveau disque était branché sur la machine. Supposons, par exemple, que la partition que nous voulons monter soit désignée par le nom /dev/sdb1. Si un nouveau disque était branché, le système d'exploitation pourrait le détecter le premier et lui donner le nom "sdb". Le disque que nous avons connu sous le nom de "sdb" serait désornais "sdc" et la première partition "sdc1". 

Mais comment trouver l'UUID de la partition ?

Avec la commande blkid :



Veuillez vous reporter à la capture d'écran suivant. Nous avons ouvert le fichier fstab avec l'éditeur de texte de notre choix et nous ajoutons l'UUID, le point de montage (/vol), le type de système de fichiers (ext4), certaines options ou le simple mot "defaults" si les valeurs par défaut nous conviennent, et puis (le plus souvent) deux 0 :



  • Il est facultatif d'entourer l'UUID de guillemets.
  • Nous pouvons mettre soit un espace, soit une tabulation entre les éléments de chaque ligne.
La configuration ci-dessous fonctionnerait tout aussi bien :




Après avoir examiné les différentes options fstab, j'en ai conclu que les valeurs par défaut me conviendraient parfaitement bien la plupart du temps et je ne vais pas présenter les autres dans ce billet de blogue. Pour en savoir plus, vous pourriez faire une recherche sur ces termes :

options fstab

Et voici une ressource pour commencer :



Mais qu'en est-il des deux zéros ?
  • Le premier zéro réglait l'archivage de la partition effectué par la programme "dump" et ne sert plus.
  • Le second zéro concerne les système ext* (ext3, ext4), et quelques autres, mais non pas xfs. Il établit l'ordre de la vérification des systèmes de fichiers au démarrage.

Quoi qu'il en soit, quand nous faisons redémarrer la machine, le système de fichiers devrait être monté sans intervention manuelle de notre part, ce qui nous pouvons vérifier avec la commande suivante :



 




Sunday, November 6, 2016

Office 365 / Exchange Online: management with PowerShell - review of some basic concepts

Preface: I'm taking a break from my recent Linux CentOS 7 posts. While working on an Office 365 problem, I was asked to retrieve some information about my Office 365 tenant using various PowerShell cmdlets. I don't often connect to Office 365 with PowerShell so I thought I would take this opportunity to review some of the basic concepts here.

***

We can manage our Office 365 subscription with the Office 365 Admin Center and Exchange Online with the Exchange Admin Center.

Note: I will concentrate on Exchange Online. There may be other Admin Centers available depending on your subscription.

Most administrators are probably familiar with the graphic interfaces below.

For example, after connecting to the Office 365 portal, I find myself in the Office 365 Admin Center:




If I go to the icon designated by the red dot in the screenshot (above), I can select Exchange...




And then find myself in the Exchange Admin Center where I can manage the Exchange aspects of my Office 365 subscription :




We can also manage both our Office 365 tenant and Exchange Online in particular via a remote PowerShell connection.

In the lines that follow, we'll see how to establish connections to Office 365 / Exchange Online.


***


First, I'm going to use a Windows 7 SP1 machine with .Net 4.5.2 and PowerShell version 4:

PS C:\> $PSVersionTable.PsVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1


But that is not enough.

Normally, I would enter the following cmdlets:

Import-Module MSOnline

And then...

Connect-MsolService

I would then see the following prompt for credentials:





But this is what I see instead:


Note: click to enlarge.

What is missing?

We need to install the "Microsoft Azure Active Directory module for Windows PowerShell" or simply, the "Azure Active Directory PowerShell Module" (yes, it's the same thing).

Since links may change, I would perform an online search for the module, download it and then install it.

The file was named "AdministrationConfig.msi" when I downloaded it for the last time.

After installation, we may see an icon for "Microsoft Azure Active Directory module for Windows PowerShell". However, once the module is installed, we can use the regular icon for PowerShell also. Both have the Azure Active Directory cmdlets.





We can now connect (we should see the prompt for credentials shown earlier) and can execute Azure Active Directory cmdlets to obtain information about our Office 365 tenant.


Among some of the more useful informational cmdlets (Get-*) are:
  • Get-MsolCompanyInformation
  • Get-MsolDomain 
  • Get-MsolSubscription

I will not post the output here as there is too much information about my tenant.

We can view other MS Online cmdlets with this command:

Get-Command *msol*

or (aliased)

gcm *msol*


For example, we can see users and groups in our Azure Active Directory with these cmdlets:
  • Get-MsolUser
  • Get-MsolGroup
These may be users / groups created in our O365 tenant or synced from on-premises.

We can act on Azure Active Directory objects with the Add-*, New-*, Remove-*, Reset-*, Restore-*, Set-* and other cmdlets.


***


But what about managing Exchange Online with remote PowerShell?

First, we must set the execution policy to "RemoteSigned" if it is not already.

We verify with this cmdlet:

Get-ExecutionPolicy

We set the policy with this cmdlet:

Set-ExecutionPolicy RemoteSigned

If you do not set the policy to RemoteSigned, you will encounter this error:



Otherwise, the set of cmdlets below should allow us to access Exchange Online via remote PowerShell and manage objects (mailboxes, etc.) as needed:

$Cred = Get-credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic 
-AllowRedirection

Import-PSSession $Session -DisableNameChecking -AllowClobber

Note: in the link referenced at the end of this post, the parameters -DisableNameChecking and -AllowClobber are not used. It was someone from Microsoft technical support that suggested them to me. I've included a second link below so the reader can see what these parameters do.


Below is an example of a cmdlet we could run, showing some O365 characteristics such as the database (a reference to "db109"), the server name, the organizational unit and the various Office 365 quotas, notably the 50 GB mailbox size:




It is best practice to close Exchange Online sessions with the cmdlet Remove-PSSession, for example:

Remove-PSSession $Session

Note: we have a limit of three remote sessions.

We can see the number of sessions with this cmdlet:

Get-PSSession

This would close all active sessions:

Get-PSSession | Remove-PSSession


For more information: