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ésoudre les problèmes de la passerelle indépendante Tableau Server

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

Redémarrez le service tableau-tsig

Commencez (et terminez) systématiquement le dépannage en redémarrant le service tableau-tsig sur les ordinateurs des passerelles indépendantes. Le redémarrage de ce service est rapide et déclenche souvent une mise à jour de la configuration à partir de Tableau Server.

Exécutez les commandes suivantes sur l’ordinateur de la passerelle indépendante :

sudo su - tableau-tsig

systemctl --user restart tsig-httpd

exit

Trouver des chaînes de caractères incorrects

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

• Configuration de la pré-authentification Okta. Examinez attentivement les URL que vous avez définies. Vérifiez la présence de barres obliques. Vérifiez la présence de HTTP c. HTTPS.
• Historique des étagères pour la configuration SAML sur le nœud 1. Examinez 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. Lors de l’examen de l’historique des étagères à partir du nœud 1, vérifiez que les commandes tsm configuration set qui indiquent les chemins d’accès du fichier de configuration Mellon correspondent exactement aux chemins d’accès de fichier où vous avez copié les fichiers sur la passerelle indépendante.
• Configuration Mellon sur la passerelle indépendante. Examinez l’historique des étagères pour vérifier 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 le MellonCookieDomain est défini sur votre domaine racine, et non sur votre sous-domaine Tableau.

Rechercher les fichiers journaux pertinents

Si toutes les chaînes semblent être définies correctement, vous devez examiner les fichiers journaux à la recherche d’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’examiner ces fichiers journaux dans l’ordre suivant.

Fichiers journaux de la passerelle indépendante

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

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

Fichier journal tabadminagent de Tableau Server

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 dans quel emplacement les erreurs liées à la passerelle indépendante ont été consignées dans tabdminagent. Ces erreurs peuvent se trouver sur n’importe quel nœud, mais elles ne concernent qu’un seul nœud. Effectuez les étapes suivantes sur chaque nœud du groupement Tableau Server jusqu’à ce que vous trouviez la chaîne "independent" :

1. Trouvez 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 fichier journal le plus récent et vérifiez qu’il comporte :

   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 aucune correspondance, passez au nœud suivant et répétez les étapes 1 à 3.

4. Quand vous obtenez une correspondance : Shift + G pour défiler vers le bas et obtenir les messages d’erreur les plus récents.

Recharger le fichier de remplacement httpd

La passerelle indépendante gère la configuration du fichier de remplacement httpd pour Apache. Une opération générique pouvant aboutir à la réparation des erreurs temporaires consiste à recharger le fichier de remplacement httpd qui constitue la configuration sous-jacente d’Apache. Exécutez les commandes suivantes sur les deux instances de la passerelle indépendante.

1. Recopiez le fichier de remplacement 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 consigne tous les événements d’accès. Vous devrez gérer le stockage des fichiers journaux pour éviter de saturer l’espace disque. En cas d’encombrement de l’espace disque, la passerelle indépendante ne pourra pas écrire des événements d’accès, ce qui se traduira par un échec. Le message suivant sera consigné dans le fichier error.log de 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

Cette erreur se traduit par un état DEGRADED pour le nœud external lorsque vous exécutez tsm status -v sur le nœud 1 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 effacez les fichiers access.log du disque. Les fichiers access.log sont enregistrés sur /var/opt/tableau/tableau_tsig/logs. Une fois le disque effacé, redémarrez le service tableau-tsig.

Erreurs liées au 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 la présence d’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 saisi tous ces éléments sans aucune erreur.

Souvent le fichier error.log sur le serveur de la passerelle indépendante spécifiera quelle URL est à 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éversé 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 dépannage :

• 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épendante.
• Vérifiez que sudo apachectl configtest renvoie « Syntaxe 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 entre Tableau Server et 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 sont à l’origine de problèmes de connexion.

Par exemple, exécutez la commande suivante wget pour vérifier le protocole de gestion interne (HK) depuis Tableau Server :

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

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

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 est toujours possible que des erreurs liées au contenu se produisent, mais pas des 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 le protocole TCP 21319.