problème d'authentification

[MaxiReglisse]

il n'est pas possible de s'authentifier :

http://localhost:8180/ Page Web inaccessible ERR_CONNECTION_REFUSED

une idée ?

[landryb]

Je l'ai vu une fois depuis le passage au https-only, redémarrer tomcat-proxycas avait suffi a faire disparaitre le probleme et je pouvais me logguer avec testadmin/testadmin.

[MaxiReglisse]

honte à moi, j'aurais dû commencer par ça... et effectivement, en redémarrant le serveur complet, c'est encore mieux. mais par contre, en me déconnectant et en me reconnectant juste après, on a encore des gags : "Nous vous redirigeons vers la page d'accueil dans une seconde..." et ça boucle sans arriver à la page d'accueil. je retape alors l'URL https://ansible/geoserver/web/, il y va ; je retente l'authentification et je retombe sur l'erreur : Firefox ne peut établir de connexion avec le serveur à l'adresse localhost:8180. idem avec Chrome.

[MaxiReglisse]

et le redémarrage du proxy-cas ne résoud pas le problème.

[MaxiReglisse]

et le redémarrage du serveur non plus. vidage du cache de navigateur compris. on revient à http://localhost:8180/

[fvanderbiest]

Je ne reproduis pas sur une box vagrant générée ce soir à partir de ce dépôt branche master, ni sur chromium ni sur firefox ...

[fvanderbiest]

Note que je n'accède pas au site via https://localhost:8180/ ... J'y accéde via le fqdn configuré dans le playbook, que j'ai pris soin de référencer dans mon /etc/hosts avec l'adresse IP de la VM sur mon réseau.

[MaxiReglisse]

ma VM est dans une infrastructure vmware, la même sur laquelle j'ai déjà 3 georchestra qui fonctionnenent très bien, et qui sont régilièrement réinstallées par Ansible. les différences : pas de certificat X509 pour celle-ci, pas d'adresse définie dans le DNS. seul mon /etc/hosts me permet d'y accéder. ce matin, j'ai complété le /etc/hosts de la VM. c'est pas mieux. la VM de base est une Debian 8.1, à jour...

je refais tourner le playbook ce matin, après restauration de la Debian 8.1 vierge...

[landryb]

Evidemment, ca serait beaucoup mieux avec un log complet de l'execution d'ansible posé qqpart, avec un git diff dans /etc/georchestra (particulièrement les sous-rept cas et security-proxy) permettrait d'y voir plus clair :) Aussi, regarder ce qui se passe au niveau des requetes réseau/redirections dans la console réseau du navigateur (ctrl-shift-Q sous firefox) De ce que je comprends de cas, après un login réussi, il redirige le navigateur vers l'url renseignée dans proxyCallback puis vers la page sur laquelle il était avant qu'on clique sur le bouton login.

[landryb]

Enfin la manifestement le pbm est au niveau de la conf apache car la redirection vers localhost:8180 n'est renseignée que dans apache.

[MaxiReglisse]

je suis en réunion ce matin à partir de 9h30, normalement jusqu'à midi...mais partaitement dispo cet après-midi. qu'entends-tu par git diff ? les différences entre les *.j2 de ansible et la conf réelle de la VM ?

[landryb]

qu'entends-tu par git diff ? les différences entre les *.j2 de ansible et la conf réelle de la VM ?

cd /etc/georchestra
git diff cas security-proxy

Il n'y a pas d'urgence non plus, le principe des tickets c'est que c'est asynchrone, et on les traite quand on est disponible/à le temps..

[MaxiReglisse]

git diff /etc/georchestra/cas ->http://pastebin.fr/45834 il y a un souci sur server.prefix : -server.name=https://georchestra.mydomain.org -server.prefix=https://georchestra.mydomain.org/cas +server.name=https://ansible.umrthema.univ-fcomte.fr:443 +server.prefix=${server.name}/cas

[MaxiReglisse]

git diff /etc/georchestra/security-proxy -> http://pastebin.fr/45835 il y a un souci sur public.host : -proxy.defaultTarget=http://georchestra.mydomain.org/ -public.host=https://georchestra.mydomain.org/ +proxy.defaultTarget=https://ansible.umrthema.univ-fcomte.fr +public.host=ansible.umrthema.univ-fcomte.fr

[MaxiReglisse]

la différence entre mon playbook et celui du dépôt : colordiff playbooks/test.yml playbooks/georchestra.yml -> http://pastebin.fr/45836

[landryb]

Pour moi, les différences sont normales... tu auras toujours les mêmes, et j'ai les mêmes (avec d'autres valeurs evidemment) sur mon instance de test.

[MaxiReglisse]

je sèche... rien dans /etc/georchestra ne fait référence au port 8180. seuls les fichiers apache utilisent ce port, dans /var/www/georchestra/conf/* et là, rien de différent par rapport aux instances de georchestra qui fonctionnent correctement.

[MaxiReglisse]

je me suis mis à vagrant, pour être dans une conf similaire à la votre. voir http://pastebin.fr/45866 mais j'observe le même phénomène, à savoir un retour à localhost:8180 juste après avoir renseigné login et mot de passe. je dois mal faire quelque chose, mais ça m'échappe complétement. merci d'avance pour votre regard inquisiteur sur les fichiers contenus dans "pastebin".

[MaxiReglisse]

nouvel essai ce matin, en utilisant le mode bridge de vagrant, de manière à attribuer à la VM une adresse du réseau local, comme je le fais habituellement avec vmware. il faut en particulier modifier deux lignes dans le Vagrantfile : config.vm.network "public_network", :bridge => "eth0", ip: "172.20.74.148" ansible.extra_vars = { ansible_ssh_host: '172.20.74.148', ansible_ssh_user: 'vagrant', ansible_ssh_port: 22 } mais j'arrive toujours sur la même page, après authentification : http://localhost:8180/

[MaxiReglisse]

bon, aujourd'hui ça marche... avec vagrant et également sur vmware !! la solution était dans une réponse de François : "J'y accéde via le fqdn configuré dans le playbook, que j'ai pris soin de référencer dans mon /etc/hosts avec l'adresse IP de la VM sur mon réseau." pour retrouver le problème, il suffit de se connecter sur https://server/geoserver/web où server est un alias défini dans /etc/hosts... et on tombe sur http://localhost:8180/, Page Web inaccessible. c'est aussi vrai pour les versions précédentes de georchestra. à noter qu'il n'est pas utile de redémarrer la VM après installation, elle fonctionne immédiatement. avec mes excuses pour ce bruit de fond... Ernest.

[landryb]

J'ai pas tout compris, mais tu peux fermer le ticket si c'est bon pour toi ?

[MaxiReglisse]

il manquait quelque chose dans mon commentaire. je reformule. il suffit de se connecter initialement sur https://geo/geoserver/web où geo est un alias défini dans /etc/hosts... et on tombe sur http://localhost:8180/ dès qu'on s'authentifie. pour celà, il faut évidemment que /etc/hosts contienne la ligne : xxx.xxx.xxx.xxx georchestra.myorganisation.org georchestra geo

[landryb]

il suffit de se connecter initialement sur https://geo/geoserver/web où geo est un alias défini dans /etc/hosts... et on tombe sur http://localhost:8180/ dès qu'on s'authentifie.

Oui, je pense que c'est normal, georchestra s'attend a ce qu'on y accède par le 'vrai' fqdn défini dans la config de cas/sec-proxy/partout via la valeur de georchestra_fqdn, quand on passe par de multiples alias, ca peut causer ce genre de gags.