Guide de déploiement de Tableau Server en entreprise

switchto

Le script switchto est un script conçu par Tim qui permet de passer facilement d’une fenêtre à l’autre.

1. Copiez le code suivant dans un fichier appelé switchto dans le répertoire de base de votre hôte Bastion.

#!/bin/bash
#-------------------------------------------------------------------
# switchto
#
# Helper function to simplify SSH into the various AWS hosts when
# following the Tableau Server Enterprise Deployment Guide (EDG).
#
# Place this file on your bastion host and provide your AWS hosts' 
# internal ip addresses or machine names here.
# Example: readonly NODE1="10.0.3.187"
#
readonly NODE1=""
readonly NODE2=""
readonly NODE3=""
readonly NODE4=""
readonly PGSQL=""
readonly PROXY1=""
readonly PROXY2=""
				
usage() {
echo "Usage: switchto.sh [ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 ]"
}


ip=""

case $1 in
	node1)
		ip="$NODE1"
		;;
	node2)
		ip="$NODE2"
		;;
	node3)
		ip="$NODE3"
		;;
	node4)
		ip="$NODE4"
		;;
	pgsql)
		ip="$PGSQL"
		;;
	proxy1)
		ip="$PROXY1"
		;;
	proxy2)
		ip="$PROXY2"
		;;
	?)
		usage
		exit 0
		;;
	*)
		echo "Unkown option $1."
		usage
		exit 1
		;;
esac

if [[ -z $ip ]]; then
echo "You must first edit this file to provide the ip addresses of your AWS hosts."
exit 1
fi

ssh -A ec2-user@$ip

2. Mettez à jour les adresses IP dans le script pour les mapper à vos instances EC2, puis enregistrez le fichier.
3. Appliquez les autorisations au fichier de script :

sudo chmod +x switchto

Utilisation :

Pour passer à un hôte, exécutez la commande suivante :

./switchto <target>

Par exemple, pour passer au Nœud 1, exécutez la commande suivante :

./switchto node1

Résolution des problèmes Tableau Server Independent Gateway

La configuration de la passerelle indépendante, d’Okta, de Mellon et de SAML sur Tableau Server peut être un processus sujet aux erreurs. La cause première la plus courante des échecs est une erreur de chaîne. Par exemple, une barre oblique finale (/ ) sur les URL Okta spécifiées lors de la configuration peut provoquer une erreur de non-concordance liée à l’assertion SAML. Ceci n’est qu’un exemple. Lors de la configuration, il existe de nombreuses occasions de saisir une chaîne incorrecte dans l’une des applications.

Redémarrer le service tableau-tsig

Commencez (et terminez) toujours le dépannage en redémarrant le service tableau-tsig sur les ordinateurs de la passerelle indépendante. Le redémarrage de ce service est rapide et déclenche souvent le chargement de la configuration mise à jour à partir de Tableau Server.

Exécutez les commandes suivantes pour mettre à jour l’ordinateur de la passerelle indépendante :

sudo su - tableau-tsig

systemctl --user restart tsig-httpd

exit

Trouver les chaînes incorrectes

Si vous avez fait une erreur de chaîne (erreur de copier/coller, chaîne tronquée, etc.), prenez le temps de parcourir chacun des paramètres que vous avez configurés :

• Configuration de pré-authentification Okta. Examinez attentivement les URL que vous avez définies. Recherchez les barres obliques finales. Vérifiez HTTP versus HTTPS.
• Historique du shell pour la configuration SAML sur le Nœud 1. Vérifiez la commande tsm authentication saml configure que vous avez exécutée. Vérifiez que toutes les URL correspondent à celles que vous avez configurées dans Okta. Pendant que vous examinez l’historique du shell à partir du Nœud 1, vérifiez que les commandes tsm configuration set qui spécifient les chemins d’accès aux fichiers de configuration Mellon correspondent exactement aux chemins d’accès des fichiers où vous avez copié les fichiers sur la passerelle indépendante.
• Configuration de Mellon sur la passerelle indépendante. Dans l’historique du shell, vérifiez que vous avez créé les métadonnées avec la même chaîne d’URL que celle que vous avez configurée dans Okta et Tableau SAML. Vérifiez que tous les chemins spécifiés dans/etc/mellon/conf.d/global.conf sont corrects et que MellonCookieDomain est défini sur votre domaine racine, et non sur votre sous-domaine Tableau.

Recherche dans les journaux pertinents

Si toutes les chaînes semblent correctement définies, vous devez inspecter les journaux pour détecter les erreurs.

Tableau Server consigne les erreurs et les événements dans des dizaines de fichiers journaux différents. La passerelle indépendante se connecte également à un ensemble de fichiers locaux. Nous vous recommandons d’inspecter ces journaux dans l’ordre suivant.

Fichiers journaux de la passerelle indépendante

L’emplacement par défaut des journaux de la passerelle indépendante est /var/opt/tableau/tableau_tsig/logs

• access.log : ce journal est utile dans la mesure où il contient des entrées qui affichent les connexions à partir des nœuds Tableau Server. Si vous obtenez des erreurs de passerelle (ne démarre pas) lorsque vous essayez de démarrer TSM et qu’il n’y a aucune entrée dans le fichier access.log, il y a un problème de connectivité de base. Vérifiez toujours la configuration du groupe de sécurité AWS dans un premier temps. Un autre problème courant est une faute de frappe dans tsig.json. Si vous effectuez une mise à jour de tsig.json, exécutez tsm stop avant d’exécuter tsm topology external-services gateway update -c tsig.json. Une fois tsig.json mis à jour, exécutez tsm start.
• error.log : entre autres entrées, ce journal inclut les erreurs SAML et Mellon.

Fichier journal de Tableau Server tabadminagent

L’ensemble de fichiers tabadminagent (et non tabadmincontroller) inclut les seuls fichiers journaux pertinents pour le dépannage des erreurs liées à la passerelle indépendante.

Vous devez trouver où les erreurs de passerelle indépendante ont été consignées dans tabdminagent. Ces erreurs peuvent se trouver sur n’importe quel nœud, mais elles ne se trouvent que sur un seul nœud. Effectuez les étapes suivantes sur chaque nœud du cluster Tableau Server jusqu’à ce que vous trouviez la chaîne « independent » :

1. Localisez l’emplacement du fichier journal tabadminagent sur les nœuds 1 à 4 de Tableau Server dans la configuration EDG :

   cd /data/tableau_data/data/tabsvc/logs/tabadminagent

2. Ouvrez le dernier journal pour lire :

   less tabadminagent_nodeN.log

   (remplacez N par le numéro de nœud)

3. Recherchez toutes les instances de « Independent » et « independent » en utilisant la chaîne de recherche suivante :

   /ndependent

   S’il n’y a pas de correspondance, passez au nœud suivant et répétez les étapes 1 à 3.

4. Lorsque vous obtenez une correspondance : Shift + G pour déplacer vers le bas et obtenir les derniers messages d’erreur.

Recharger le fichier stub httpd

La passerelle indépendante gère la configuration du protocole httpd pour Apache. Une opération générique qui résout souvent les problèmes transitoires consiste à recharger le fichier stub httpd qui amorce la configuration Apache sous-jacente. Exécutez les commandes suivantes sur les deux instances de Ia passerelle indépendante.

1. Copiez le fichier stub dans httpd.conf :

   cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf

2. Redémarrez le service de passerelle indépendante :

   sudo su - tableau-tsig
   systemctl --user restart tsig-httpd
   exit

Supprimer ou déplacer des fichiers journaux

La passerelle indépendante enregistre tous les événements d’accès. Vous devrez gérer le stockage des fichiers journaux pour éviter de remplir l’espace disque. Si votre disque est plein, la passerelle indépendante ne pourra pas écrire d’événements d’accès et le service échouera. Le message suivant sera consigné dans error.log sur la passerelle indépendante :

(28)No space left on device: [client 10.0.2.209:54332] AH00646: Error writing to /var/opt/tableau/tableau_tsig/logs/access.%Y_%m_%d_%H_%M_%S.log

Cet échec se traduira par un état DEGRADED pour le nœud external lorsque vous exécutez tsm status -v sur le Nœud 1 de Tableau. Le nœud external dans la sortie d’état fait référence à la passerelle indépendante.

Pour résoudre ce problème, supprimez ou déplacez les fichiers access.log hors du disque. Les fichiers access.log sont enregistrés sur /var/opt/tableau/tableau_tsig/logs. Après avoir effacé le disque, redémarrez le service tableau-tsig.

Erreurs de navigateur

Requête incorrecte : une erreur courante pour ce scénario est une erreur « Bad Request » (Requête incorrecte) d’Okta. Ce problème se produit souvent lorsque le navigateur met en cache les données de la session Okta précédente. Par exemple, si vous gérez les applications Okta en tant qu’administrateur Okta, puis tenez d’accéder à Tableau à l’aide d’un autre compte compatible Okta, les données de session provenant des données de l’administrateur peuvent provoquer l’erreur « Bad Request ». Si cette erreur persiste même après la suppression du cache du navigateur local, essayez de valider le scénario Tableau en vous connectant avec un autre navigateur.

Une autre cause de l’erreur « Bad Request » est une faute de frappe dans l’une des nombreuses URL que vous entrez lors des processus de configuration Okta, Mellon et SAML. Vérifiez que vous avez entré tous ces éléments sans erreur.

Souvent le fichier error.log sur le serveur de la passerelle indépendante spécifie l’URL à l’origine de l’erreur.

Introuvable - L’URL demandée était introuvable sur ce serveur : cette erreur indique l’une des nombreuses erreurs de configuration possibles.

Si l’utilisateur est authentifié avec Okta, puis reçoit cette erreur, il est probable que vous ayez téléchargé l’application de pré-authentification Okta sur Tableau Server lorsque vous avez configuré SAML. Vérifiez que vous avez configuré les métadonnées de l’application Okta Tableau Server sur Tableau Server, et non pas les métadonnées de l’application de pré-authentification Okta

Autres étapes de résolution des problèmes :

• Passez en revue les paramètres de l’application de pré-authentification Okta. Assurez-vous que les protocoles HTTP vs HTTPS sont définis comme spécifié dans cette rubrique.
• Redémarrez tsig-httpd sur les deux serveurs de passerelle indépendants.
• Vérifiez que sudo apachectl configtest renvoie « Syntax OK » sur les deux passerelles indépendantes.
• Vérifiez que l’utilisateur test est affecté aux deux applications dans Okta.
• Vérifiez que l’adhérence est activée sur l’équilibreur de charge et les groupes cibles associés

Vérifier la connexion TLS de Tableau Server à la passerelle indépendante

Utilisez la commande wget pour vérifier la connectivité et l’accès de Tableau Server à la passerelle indépendante. Des variantes de cette commande peuvent vous aider à comprendre si des problèmes de certificat causent des problèmes de connexion.

Par exemple, lancez la commande wget pour vérifier le protocole de maintenance (HK) à partir de Tableau Server ;

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319

Créez l’URL avec la même adresse d’hôte que celle que vous avez incluse pour l’option d’hôte du fichier tsig.json. Spécifiez le protocole https et ajoutez l’URL avec le port HK 21319.

Pour vérifier la connectivité et ignorer la vérification du certificat :

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate

Pour vérifier que le certificat CA racine pour TSIG est valide :

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem

Si Tableau est capable de communiquer, il peut y avoir des erreurs liées au contenu, mais il n’y aura pas d’erreurs liées à la connexion. Si Tableau ne parvient pas du tout à se connecter, commencez par vérifier la configuration du protocole dans les groupes de pare-feu/sécurité. Par exemple, les règles entrantes du groupe de sécurité où réside la passerelle indépendante doivent autoriser TCP 21319.