Déploiement technique d’une VM AJLSM - Historique des versions

Jlarvers le 19 octobre 2026 à 07:35

2026-10-19T07:35:35Z

Voir les modifications

Jlarvers le 19 octobre 2026 à 07:35

2026-10-19T07:35:05Z

Voir les modifications

Jlarvers : /* 11.3. Page man */

2026-10-16T16:40:28Z

11.3. Page man

← Version précédente		Version du 16 octobre 2026 à 16:40
Ligne 455 :		Ligne 455 :

	Une page absente ne signifie pas que le script est absent : --help est l’aide intégrée de l’exécutable. Le manuel installé doit être réconcilié avec le cycle et l’assistant avant d’être considéré comme référence de cette version. En attendant, le présent guide et l’aide des fichiers du lot de recette décrivent le fonctionnement courant.		Une page absente ne signifie pas que le script est absent : --help est l’aide intégrée de l’exécutable. Le manuel installé doit être réconcilié avec le cycle et l’assistant avant d’être considéré comme référence de cette version. En attendant, le présent guide et l’aide des fichiers du lot de recette décrivent le fonctionnement courant.
	<syntaxhighlight lang="~~bash~~">
			Man le 16/10/2026
			<syntaxhighlight lang="text">
	AJLSM-DEPLOY(8) Administration système AJLSM-DEPLOY(8)		AJLSM-DEPLOY(8) Administration système AJLSM-DEPLOY(8)

Jlarvers : /* 11.3. Page man */

2026-10-16T16:39:39Z

11.3. Page man

Voir les modifications

Jlarvers : /* 11.3. Page man */

2026-10-16T16:38:39Z

11.3. Page man

Voir les modifications

Jlarvers : /* 11.3. Page man */

2026-10-16T16:37:31Z

11.3. Page man

Voir les modifications

Jlarvers : /* 5.2. Compléter le modèle vierge */

2026-10-16T16:21:51Z

5.2. Compléter le modèle vierge

← Version précédente		Version du 16 octobre 2026 à 16:21
Ligne 170 :		Ligne 170 :

	Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.		Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.
			<syntaxhighlight lang="yaml"># Préconfiguration AJLSM vierge : aucune valeur d’infrastructure préremplie.
			# Compléter avec ajlsm-deploy-yaml ; ne pas déployer ce modèle tel quel.
			# null = champ à renseigner, SAUF proxmox.vmid où null = attribution automatique.
			# Les crochets [à renseigner] sont interdits : ils représenteraient une liste YAML.
			# Deux interfaces sont proposées : adapter leur nombre avant la saisie.
			projet:
			code: null # Obligatoire : minuscules/chiffres, tiret et souligné ; ex. mercure3.
			nom: null # Obligatoire : nom lisible du projet.
			environnement: null # Liste fermée : interne, client, prod.

			proxmox:
			serveur: null # Obligatoire : nom du nœud Proxmox, ex. Saturne3.
			template_vmid: null # Obligatoire : entier positif, VM modèle existante et arrêtée.
			vmid: null # Automatique ; sinon entier positif différent de template_vmid.
			nom_vm: null # Obligatoire : nom de VM, lettres/chiffres/point/tiret.
			cpu:
			sockets: null # Obligatoire : entier positif.
			cores: null # Obligatoire : entier positif ; vCPU = sockets × cores.
			memoire:
			maximale_mib: null # Obligatoire : entier positif, en Mio.
			minimale_mib: null # Obligatoire : entier positif, inférieur ou égal au maximum.
			disque_systeme:
			stockage: null # Obligatoire : identifiant de stockage Proxmox existant.
			taille_gib: null # Obligatoire : entier positif en Gio ; aucune réduction de disque.
			etendre_volume_racine: null # Obligatoire : true ou false ; active la phase racine.
			demarrage_auto: null # Obligatoire : true ou false ; appliqué à l’activation réseau.
			tags: null # Obligatoire : liste ; interne/client/prod uniquement, sans doublons ; [] admis.

			systeme:
			hostname: null # Obligatoire : nom DNS en minuscules ; vérifier sa déclaration en amont.

			reseau:
			interfaces:
			- nom: null # Obligatoire : net suivi de chiffres, conforme à la VM modèle.
			bridge: null # Obligatoire : bridge existant, au plus 15 caractères.
			systeme: null # Obligatoire : ens suivi de chiffres, conforme au modèle actuel.
			ipv4: null # Obligatoire : IPv4/CIDR, ex. 10.0.0.43/24 ; adresse unique.
			- nom: null
			bridge: null
			systeme: null
			ipv4: null
			loopback:
			ipv4: null # Obligatoire : IPv4 avec préfixe /32, distincte des interfaces.
			passerelle:
			ipv4: null # Obligatoire : IPv4 seule, dans le sous-réseau de son interface.
			interface: null # Obligatoire : un des noms systeme déclarés ci-dessus.
			dns: null # Obligatoire : liste non vide d’IPv4 sans préfixe, ex. [10.0.0.4].
			</syntaxhighlight>

	=== 5.3. Créer sans modèle ===		=== 5.3. Créer sans modèle ===

Jlarvers : /* 5.1. Vérifier un fichier existant sans le modifier */

2026-10-16T16:21:09Z

5.1. Vérifier un fichier existant sans le modifier

← Version précédente		Version du 16 octobre 2026 à 16:21
Ligne 102 :		Ligne 102 :

	Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.		Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.

			Voici un exemple :
			<syntaxhighlight lang="yaml">projet:
			code: mercure3
			nom: MERCURE3
			environnement: interne

			proxmox:
			serveur: Saturne3
			template_vmid: 506
			vmid: null
			nom_vm: MERCURE3

			cpu:
			sockets: 1
			cores: 8

			memoire:
			maximale_mib: 24576
			minimale_mib: 16384

			disque_systeme:
			stockage: local-zfs
			taille_gib: 100
			etendre_volume_racine: true

			demarrage_auto: true

			tags:
			- interne

			systeme:
			hostname: mercure3.ajlsm.com

			reseau:
			interfaces:
			- nom: net0
			bridge: vmbr2
			systeme: ens18
			ipv4: 10.0.0.43/24

			- nom: net1
			bridge: vmbr1
			systeme: ens19
			ipv4: 192.168.123.27/24

			loopback:
			ipv4: 51.83.117.113/32

			passerelle:
			ipv4: 10.0.0.4
			interface: ens18

			dns:
			- 10.0.0.4
			</syntaxhighlight>

	=== 5.2. Compléter le modèle vierge ===		=== 5.2. Compléter le modèle vierge ===

Jlarvers le 16 octobre 2026 à 15:44

2026-10-16T15:44:55Z

Voir les modifications

Jlarvers : Page créée avec « = Déploiement technique d’une VM AJLSM = Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant ... »

2026-10-16T15:37:53Z

Page créée avec « = Déploiement technique d’une VM AJLSM = Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant ... »

Nouvelle page

= Déploiement technique d’une VM AJLSM =

Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant YAML.

== 1. Périmètre et résultat de la recette ==

Le cycle technique a été exécuté sur MERCURE3 sans erreur signalée. Les vérifications finales transmises confirment :
* connexion SSH avec le compte ajlsm ;
* élévation sudo avec le mot de passe défini pendant le cycle ;
* hostname mercure3.ajlsm.com ;
* volume racine ext4 de 97 Gio, dont 85 Gio disponibles lors du contrôle.

Le cycle couvre le clonage, les ressources, l’initialisation du clone, l’extension de la racine, l’identité système, le réseau, SSH, le mot de passe et le certificat TLS interne.

NFS, les configurations applicatives Apache2, Pleade, Drupal et Matomo ne font pas encore partie de ce cycle. Certains logiciels peuvent déjà être présents dans le modèle : leur présence ne constitue pas une configuration applicative du projet.

== 2. Où exécuter les commandes ==

{| class="wikitable"
! Machine !! Rôle !! Exemple d’invite
|-
| Mac de l’administrateur || Transfert des archives par scp || Invite locale du Mac
|-
| Saturne3 || Préparation YAML, scripts Proxmox et cycle || root@Saturne3
|-
| MERCURE3 || Vérifications dans la VM || ajlsm@mercure3 ou root@mercure3
|}

Les scripts de déploiement sont exécutés sur Saturne3, pas dans MERCURE3.
Après « ssh ajlsm@10.0.0.43 », attendre l’invite de la VM avant de saisir les commandes suivantes.
Pour revenir de root@mercure3 à Saturne3 : un exit quitte sudo, puis un second exit ferme SSH.

== 3. Organisation des fichiers ==

<syntaxhighlight lang="text">
/root/ajlsm-deploy/
archives/ Archives reçues, conservées comme références
recettes/20261016/
ajlsm-deploy-cycle/ Lot technique validé et assistant ajouté
ajlsm-deploy-assistant/ Distribution de l’assistant et tests
ajlsm-deploy-documentation/ Présent guide et modèles YAML

/etc/ajlsm/deploy/projets/mercure3.yaml Configuration actuellement utilisée
/usr/local/sbin/ Scripts installés antérieurement
</syntaxhighlight>

Le lot de recette contient ajlsm-deploy, ajlsm-deploy-check, ajlsm-deploy-resources, ajlsm-deploy-cycle et les modules ajlsm_deploy_common.py, ajlsm_deploy_rootgrow.py et ajlsm_deploy_postconfig.py. L’assistant ajlsm-deploy-yaml a été ajouté à ce même dossier.

Conserver exécutables et modules ensemble. Utiliser les chemins ./ depuis le dossier de recette pour ne pas appeler une ancienne version de /usr/local/sbin.
Les anciennes archives « ajlsm-deploy-revise » et « correction-suggestions » ne sont pas la référence courante : elles précèdent les phases supplémentaires reçues dans l’archive serveur.

Prérequis : Python 3.9 ou supérieur, PyYAML 6, outils Proxmox sur le nœud cible et prérequis du modèle AJLSM. Les phases invitées utilisent notamment l’agent QEMU, ajlsm-clone-init, Python, systemd et Netplan. L’extension actuelle cible ext4/LVM sur /dev/sda3, avec un seul PV et un seul LV.

== 4. Les deux fichiers de préconfiguration ==

=== 4.1. projet-vierge.yaml ===

Ce modèle reprend toute la structure actuelle sans valeur opérationnelle préremplie. Chaque champ doit être renseigné. Seul proxmox.vmid peut rester null : il signifie alors attribution automatique.

Le modèle comporte deux interfaces dont les valeurs sont null. Adapter le nombre d’interfaces avant la saisie si nécessaire. Pour déterminer ce nombre par les questions de l’assistant, utiliser plutôt le mode --new.

Un modèle vierge est volontairement refusé par --check. Il ne doit jamais être passé directement au lanceur du cycle.

=== 4.2. mercure3-reference.yaml ===

Ce fichier conserve les valeurs du projet validé : modèle 506 sur Saturne3, nom MERCURE3, 8 vCPU, 24576 Mio de RAM maximale, 16384 Mio minimale, disque 100 Gio, extension racine activée et paramètres réseau du projet.

Il permet de reconstruire une nouvelle VM avec la même configuration technique si le modèle, le stockage, les bridges et les préparatifs externes sont toujours disponibles. Il ne sauvegarde ni les données de l’ancienne VM, ni ses UUID, machine-id, clés hôte SSH ou mots de passe. Ces identités sont traitées par le cycle et ne sont pas à recopier.

Avec vmid: null, le VMID de remplacement peut différer de celui de l’ancienne VM. Le VMID 505 observé pendant la recette n’est pas une réservation permanente.

'''Ne pas lancer cette référence tant que MERCURE3 existe encore.''' Le clonage refuse un nom déjà présent. Pour tester une deuxième VM en parallèle, définir un autre nom, hostname, des IP distinctes et préparer DNS/OPNsense/Ansible en conséquence.

=== 4.3. Valeurs acceptées ===

* projet.environnement et tags : interne, client, prod. Les tags sont une liste sans doublons ; [] est admis.
* CPU, mémoire et taille du disque : entiers strictement positifs ; mémoire minimale inférieure ou égale à la maximale.
* Booléens : utiliser true ou false sans guillemets.
* Interfaces Proxmox : net suivi de chiffres ; interfaces invitées : ens suivi de chiffres.
* Adresses d’interfaces : IPv4/CIDR. Loopback : IPv4/32. Passerelle et DNS : IPv4 sans préfixe.
* Passerelle : interface déclarée et adresse appartenant à son sous-réseau, distincte des adresses de la VM.
* Hostname : nom DNS en minuscules.
* Serveur, bridge et stockage : valeurs adaptées à l’infrastructure ; aucune liste fermée inventée.

Les clés inconnues ou répétées sont refusées. Ne pas ajouter de sections applicatives avant l’évolution coordonnée du schéma et des scripts. Ne pas utiliser [à renseigner] : les crochets créent une liste YAML.

== 5. Préparer et valider le YAML ==

Sur Saturne3, se placer dans le lot de recette :

<syntaxhighlight lang="bash">
cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle
</syntaxhighlight>

=== 5.1. Vérifier un fichier existant sans le modifier ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --check
</syntaxhighlight>

Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.

=== 5.2. Compléter le modèle vierge ===

Après extraction du présent lot documentaire :

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml \
/root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-documentation/projet-vierge.yaml \
--output /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml
</syntaxhighlight>

Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.

=== 5.3. Créer sans modèle ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml --new
</syntaxhighlight>

Cette commande est une alternative à la précédente : le chemin doit être inexistant. L’assistant pose les questions, y compris le nombre d’interfaces, sans reprendre implicitement les valeurs de MERCURE3.

=== 5.4. Revoir un projet renseigné ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
--output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
</syntaxhighlight>

* Entrée conserve une valeur existante valide.
* ANNULER, Ctrl-C ou fin d’entrée abandonnent sans enregistrer.
* Tags et DNS sont saisis séparés par des virgules ; [] ou aucun signifie tags vides.
* Saisir auto ou null pour un VMID automatique.
* Après une incohérence, donner le chemin du champ à corriger ; ? affiche les chemins.
* Le résumé complet est présenté avant confirmation OUI/NON d’enregistrement.

L’original reste intact, avec ses commentaires. La copie est réécrite en YAML, sans reprise des commentaires. Aucun fichier existant n’est écrasé. Si une destination existe, choisir un nouveau nom avec --output.

=== 5.5. Préparatifs externes ===

Avant une création, vérifier séparément la réservation des IP, les déclarations DNS, les règles/routes/NAT nécessaires dans OPNsense et l’inventaire ou les préparatifs Ansible. Ne pas inscrire de mots de passe dans le YAML ; conserver les secrets dans le dispositif prévu pour leur gestion.

L’assistant actuel ne vérifie pas automatiquement ces services et ne marque pas un projet « prêt à déployer » sur cette seule base. Leur intégration reste à réaliser.

Le contrôle Proxmox autonome examine notamment le modèle, ses ressources, le stockage et les bridges. Il concerne une nouvelle création et peut refuser un projet déjà déployé :

<syntaxhighlight lang="bash">
./ajlsm-deploy-check /chemin/vers/projet.yaml
</syntaxhighlight>

== 6. Afficher le plan puis lancer le cycle ==

=== 6.1. Plan sans exécution ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --plan
</syntaxhighlight>

Le plan valide le YAML et affiche les commandes, sans exécuter les phases ni vérifier l’infrastructure. Il doit contenir les 11 étapes, toutes dans le dossier de recette.

=== 6.2. Cycle réel pour une nouvelle VM ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml
</syntaxhighlight>

Le lanceur exécute les phases réelles, sans simulation automatique. Il attend seulement les confirmations, les saisies nécessaires et la fin de chaque commande. Il s’arrête sur refus ou erreur. Il ne répond pas à la place de l’administrateur et ne capture pas les mots de passe.

{| class="wikitable"
! N° !! Étape !! Commande réelle !! Simulation facultative
|-
| 1 || Clonage || --clone || --dry-run
|-
| 2 || Ressources || --configure-resources || --resources-dry-run
|-
| 3 || Premier démarrage isolé || --first-boot-apply || --first-boot-dry-run
|-
| 4 || Extension partition/LVM/ext4 || --root-grow-apply || --root-grow-dry-run
|-
| 5 || Identité système || --system-apply || --system-dry-run
|-
| 6 || Préparation Netplan || --network-apply || --network-dry-run
|-
| 7 || Activation réseau || --network-enable || --network-enable-dry-run
|-
| 8 || Audit SSH || --ssh-audit || Aucune option dédiée
|-
| 9 || Sécurisation SSH || --ssh-secure || Aucune option dédiée
|-
| 10 || Mot de passe ajlsm || --password-ajlsm || Aucune option dédiée
|-
| 11 || Certificat TLS interne || --tls-apply || Aucune option dédiée
|}

L’extension racine est indispensable quand etendre_volume_racine vaut true. Agrandir le disque Proxmox ne suffit pas : la partition, le PV LVM, le LV et ext4 doivent aussi être étendus. Cette phase doit figurer après le premier démarrage, avant la personnalisation système. Avec false, la phase annonce sa désactivation.

Le démarrage et la personnalisation se font réseau isolé. Netplan est préparé avant activation des liens. La phase d’activation contrôle le réseau et applique demarrage_auto.

Le certificat TLS interne ne constitue pas, à lui seul, une configuration des applications du projet ou un certificat publiquement reconnu.

=== 6.3. Mode manuel ===

Chaque phase peut être lancée séparément avec ./ajlsm-deploy suivi du YAML et de son option. Après succès, le lot courant affiche deux lignes pour l’étape suivante : Simulation et Exécution. Si la simulation n’existe pas, il le signale. Aucune suggestion n’est exécutée automatiquement.

Les simulations peuvent consulter l’invité et émettre des sondes ARP selon la phase : elles ne sont pas toutes des contrôles hors ligne. L’absence de réponse ARP ne remplace pas la réservation des adresses dans l’inventaire réseau.

== 7. Erreur, annulation et reprise ==

Conserver la sortie complète et diagnostiquer la phase fautive avant de reprendre. Une phase peut être partiellement effectuée ; le lanceur n’effectue ni suppression de VM ni restauration globale automatique.

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --from extension-racine
</syntaxhighlight>

--from inclut l’étape indiquée et saute les précédentes à la demande de l’administrateur. Il ne certifie pas leur état. Les contrôles propres aux phases restent actifs. Le lanceur ne possède pas de journal persistant global de progression.

Ne pas relancer le cycle depuis le clonage sur une VM existante pour terminer une étape. Ne pas relancer des étapes déjà terminées uniquement parce qu’une commande manuelle les suggère. Les suggestions suivent l’ordre théorique et ne constituent pas un inventaire de l’état de la VM.

Codes de sortie : 0 succès, 1 annulation, 2 erreur. Le lanceur normalise les autres codes d’échec de ses sous-processus en erreur et ne poursuit pas.

== 8. Vérifications finales ==

Sur Saturne3, avec le VMID réellement annoncé au clonage :

<syntaxhighlight lang="bash">
qm list
qm status VMID
qm config VMID
</syntaxhighlight>

Remplacer VMID par l’identifiant vérifié. Contrôler le nom, les CPU, la RAM, le disque, les liens réseau et onboot selon le YAML.

Depuis Saturne3, ouvrir la connexion et attendre l’invite de la VM :

<syntaxhighlight lang="bash">
ssh ajlsm@10.0.0.43
</syntaxhighlight>

Dans MERCURE3, saisir sudo -i, attendre l’authentification et l’invite root, puis :

<syntaxhighlight lang="bash">
hostname
lsblk
df -hT /
ip -br addr
ip route
resolvectl status
</syntaxhighlight>

Résultat vérifié pendant la recette : hostname mercure3.ajlsm.com, racine ext4 97 Gio. Les tailles disponibles évoluent avec l’utilisation. Les commandes SSH et TLS du cycle vérifient leurs propres résultats ; compléter par les tests d’accès attendus dans le réseau cible.

== 9. Reconstruire MERCURE3 ultérieurement ==

# Conserver le fichier mercure3-reference.yaml, le lot de scripts validé et l’identification du modèle utilisé.
# Comparer la référence au YAML effectivement utilisé avant reconstruction ; actualiser les changements d’infrastructure.
# Identifier et sauvegarder les données à conserver : le YAML n’est pas une sauvegarde de VM.
# Vérifier explicitement l’identité de l’ancienne VM et traiter séparément son arrêt et sa suppression volontaire. Le cycle ne détruit jamais automatiquement une VM existante.
# Contrôler DNS, OPNsense, Ansible et les réservations d’IP. Ne pas laisser deux VM actives avec les mêmes adresses.
# Valider la référence avec --check, afficher le --plan, puis lancer le cycle sur la référence après libération de la cible.
# Relever le nouveau VMID et effectuer les vérifications finales.

On retrouve ainsi les paramètres de la VM, sans chercher à reproduire ses anciennes identités techniques.

== 10. Suites prévues ==

Prévoir les paramètres NFS, sites Apache2, Pleade, Drupal et Matomo dans le même YAML lorsque leurs exigences seront définies. Modifier ensemble le schéma, l’assistant, les modèles, les précontrôles, les phases et leur documentation. Documenter les références aux secrets plutôt que leurs valeurs.

L’intégration des contrôles DNS, OPNsense et Ansible précédera une déclaration automatisée de disponibilité du projet. Le modèle actuel ne contient pas encore ces nouvelles sections.

Déploiement technique d’une VM AJLSM - Historique des versions

Jlarvers le 19 octobre 2026 à 07:35

Jlarvers le 19 octobre 2026 à 07:35

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 5.2. Compléter le modèle vierge */

Jlarvers : /* 5.1. Vérifier un fichier existant sans le modifier */

Jlarvers le 16 octobre 2026 à 15:44

Jlarvers : Page créée avec « = Déploiement technique d’une VM AJLSM = Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant ... »

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 11.3. Page man */

Jlarvers : /* 5.2. Compléter le modèle vierge */

Jlarvers : /* 5.1. Vérifier un fichier existant sans le modifier */

Jlarvers : Page créée avec « = Déploiement technique d’une VM AJLSM = Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant ... »