Forums » Discussions & Questions »
XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'"
Ajouté par Nicolas E il y a presque 4 ans
Bonjour,
En Freya (2020.18.02), j'ai installé un 2ème serveur pour faire des stats, mais dans l'asterisk central, je vois dans rasterisk qu'un message d'erreur indique que l'ip 172.18.0.200 n'a pas les droits pour se connecter.
Traduction : le container xuc du xivocc n'a pas le droit d'accéder au manager d'asterisk car les acl de serveur_xivo:/etc/asterisk/manager.d/02-xivocc.conf ne contiennent que l'ip du serveur xivocc lui-même, mais pas l'ip du container.
J'ai manuellement rajouté une ligne permit=172.18.0.200/255.255.255.255 , effectué un manager reload dans rasterisk, et je n'ai plus d'erreur d'ACL.
Maintenant, j'ai l'erreur suivante :
NOTICE[9824]: manager.c:3570 authenticate: 172.18.0.200 failed to authenticate as 'xuc'
Or, quand je compare le "secret=..." de serveur_xivo:/etc/asterisk/manager.d/02-xivocc.conf avec serveur_xivocc:/etc/docker/compose/custom.env , j'ai bien la même valeur.
Et je retrouve bien ce mot de passe dans serveur_xivocc:/etc/docker/compose/.env
Là, j'ai fait mon maximum, je ne sais pas comment débugger le XIVO_AMI_SECRET qui est envoyé par le container xuc.
Donnez-moi une piste ?
Réponses (5)
RE: XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'" - Ajouté par Laurent MEILLER il y a presque 4 ans
Bonjour, en effet cela semble être bon au niveau secret.
Ce qui est dans le .env est en effet ce qui est réellement utilisé par le XUC pour sa connexion à l'AMI.
Cependant je trouve bizarre que vous utilisiez les ip privés docker, pouvez vous copier coller votre fichier custom.env du cc, par exemple voici un extrait de ma maquette :
XIVO_HOST=192.168.56.3 XUC_HOST=192.168.56.4
où
root@xivocc:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:95:02:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.27/24 brd 192.168.1.255 scope global dynamic eth0 valid_lft 86187sec preferred_lft 86187sec inet6 2a01:cb14:eb2:8700:a00:27ff:fe95:27a/64 scope global dynamic mngtmpaddr valid_lft 1778sec preferred_lft 578sec inet6 fe80::a00:27ff:fe95:27a/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:6b:62:b5 brd ff:ff:ff:ff:ff:ff inet 192.168.56.4/24 brd 192.168.56.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe6b:62b5/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:56:c1:52 brd ff:ff:ff:ff:ff:ff inet 10.53.1.2/16 brd 10.53.255.255 scope global eth2 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe56:c152/64 scope link valid_lft forever preferred_lft forever 5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:f8:a8:e1:75 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever
eth0 : bridge accès web
eth1: mon réseau privé partagé entre les différentes VM
eth2: mon VLAN voix
RE: XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'" - Ajouté par Nicolas E il y a presque 4 ans
Bonjour Laurent,
Sur mon cc, voici :
cat /etc/docker/compose/custom.env
XIVO_HOST=10.32.0.84
XUC_HOST=10.32.0.85
CONFIG_MGT_HOST=10.32.0.84
CONFIG_MGT_PORT=9100
XUC_PORT=8090
WEEKS_TO_KEEP=52
RECORDING_WEEKS_TO_KEEP=1
XIVO_AMI_SECRET=xxx
APPLICATION_SECRET=yyy
ELASTICSEARCH_HOST=10.32.0.85
10.32.0/24 étant le réseau partagé entre mes VM.
Le CC est en 10.32.0.85, le xivo en .84
J'ai du rajouter une ligne permit avec l'ip privée du containeur, car c'est de cette ip que asterisk voyait arriver les requêtes de connexion.
RE: XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'" - Ajouté par Laurent MEILLER il y a presque 4 ans
c'est étrange, sur mon xivo, voici le fichier pour la connexion AMI (/etc/asterisk/manager.d/02-xivocc.conf
)
[xuc] secret = xxx deny=0.0.0.0/0.0.0.0 permit=192.168.56.0/255.255.255.0 permit=10.53.1.0/255.255.0.0 read = system,call,log,verbose,command,agent,user,dtmf,originate,dialplan write = system,call,log,verbose,command,agent,user,dtmf,originate,dialplan
Aucune ip docker, que mon vlan voix et mon vlan data. Auriez vous pas un autre fixhier XX-yyyy.conf dans ce dossier qui pourrait surcharger la conf du secret ?)
Sur la webi :
et également pour que le CC soit fonctionnel, ne pas oublier de définir un utilisateur (par exemple xivows, mais je crois que le nom importe peu) qui aura le droit de se connecter au xivo avec l'ip du CC.
Sur mon CC, le réseau docker est bien visible, mais ce n'est pas l'ip qui est présenté au xivo :
root@xivocc:~# docker network ls NETWORK ID NAME DRIVER SCOPE 5xxxxxxxx1 bridge bridge local 4xxxxxxxx8 host host local 8xxxxxxxx2 none null local 9xxxxxxxx7 xivocc_default bridge local root@xivocc:~# docker network inspect xivocc_default [ { "Name": "xivocc_default", "Id": "xxx", "Created": "2019-10-03T14:05:27.684335716+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.18.0.0/16", "Gateway": "172.18.0.1" } ] },
Et avec le custom.env cité au dessus, je ne crois pas qu'il y'ait d'autre configuration à faire pour que le CC s'identifie correctement au XIVO.
picture899-1.png (47,5 ko) picture899-1.png | |||
picture899-2.png (70,8 ko) picture899-2.png |
RE: XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'" - Ajouté par Nicolas E il y a presque 4 ans
Bonjour Laurent,
Merci pour votre réponse.
Elle m'a permis de re-re-vérifier mes configs, mes actions, relire les docs pour la 23ème fois, et je me pose certaines questions.
Grace à docker container inspect, je découvre que l'ip qui est à la source des erreurs dans asterisk ne vient pas d'un des containers de mon xivocc, mais d'un container de mon xivo, et que le fautif se nomme xivocc_xuc_1.
Là, je suis perplexe car d'après ce que j'avais compris, ce container doit se trouver dans le serveur xivoCC.
Je vérifie, et oui, il s'y trouve également !
Vu que j'ignore comment est arrivé ce xivocc_xuc du côté xivo, je constate que le fichier xivo:/etc/docker/compose/docker-xivocc.yml provient du package "xivouc".
En effet, à l'époque (septembre 2020 environ), j'avais suivi la doc https://documentation.xivo.solutions/en/latest/installation/xivo/xivouc/xivouc.html dans laquelle on lit :
This page describes how to install XiVO UC on the XiVO PBX server...
Donc c'est en installant ce package que ce docker compose file s'est retrouvé du côté xivo, et a suivit le déploiement d'un container avec cette fameuse ip par laquelle survienne les requêtes refusée par l'asterisk.
A ce point, ce serait vraiment une bonne chose que l'un des devs Avencall prenne la parole pour commenter tout ça.
- Dois-je désinstaller le package xivouc côté xivo ?
- Que se cache-t-il derrière la page web de doc sus-citée, au paragraphe : ~~~ Warning By default XiVO-UC installation will pre-empt network subnets 172.17.0.0/16 and 172.18.0.0/24. If these subnets are already used, some manual steps will be needed to be able to install XiVO-UC. These steps are not described here. ~~~
- Si le bon container qui doit faire tourner xivouc doit se trouver côté xivocc, comment le paramétrer correctement ? (AMI, adressage...)
RE: XIVO_AMI_SECRET correct et pourtant "failed to authenticate as 'xuc'" - Ajouté par Laurent MEILLER il y a presque 4 ans
Bonjour Nicolas,
Je suis développeur de la solution, plus coté logiciel, mais je pense pouvoir vous aider, pas de soucis là dessus :)
Bon pas de panique, en effet, d'avoir installé un xivo-uc sur XiVO puis un xivo-cc dédié à coté, tout devient plus clair pourquoi les services se cannibalisent.
Le XiVO-UC n'est rien de plus qu'un sous-ensemble de XIVO-CC, donc ça ne sert à rien de garder les deux, à part avoir des conflits... car ce n'est pas un déploiement qu'on a prévu.
Le plus simple pour moi c'est de désinstaller le XiVO-UC et ne garder que le CC dédié.
Pour désinstaller l'uc addon rien de plus simple il suffit de suivre cette doc : https://documentation.xivo.solutions/en/2020.18/installation/xivo/xivouc/xivouc.html#uninstallation
Dites moi si ça solutionne le problème ou pas