PDA

Voir la version complète : Installation d'asterisk-odbc



guiguizmo
02/02/2016, 15h52
Bonjour,

J'ai installé asterisk sur un serveur distant OVH (CentOS 6.6) grâce au RPM asterisknow-version. Tout s'est déroulé correctement et facilement et mon serveur tourne nickel.

Aujourd'hui je voudrais installer asterisk-odbc afin d'enregistrer mes CDR en base de donnée.

La commande yum install asterisk-odbc me permet de faire cela, sauf que des dépendances doivent être mises à jour :

asterisk
asterisk-configs
asterisk-core
asterisk-dahdi
asterisk-doc
asterisk-voicemail

Ça ne me pose pas de problème de mettre à jour tout ça pour avoir odbc, le seul problème, c'est que je ne sais pas si cela va avoir pour effet de supprimer ma config actuelle. En effet je vois que dans le package asterisk par exemple, il y a, parmi d'autres, un fichier extensions.conf ...

Ma question est donc : Est ce que cette installation d'asterisk-odbc, suivie de la mise à jour de toutes ces dépendances va remplacer mes fichiers de config actuelle, et est ce que je dois faire un backup avant de lancer la machine (et si oui, quels fichiers sont à sauvegarder) ?

D'avance merci

olppp
02/02/2016, 16h31
Bonjour,

Une sauvegarde avant tout installation/mise à jour s'impose. Il faut à minima sauvegarder le dossier /et/asterisk, ensuite /var/spool/asterisk /var/lib/asterisk/astdb ou /var/lib/asterisk/astdb.sqlite3. Sous Debian, la configuration par défaut fait aussi partie des dépendances. L'outils de mise à jour demande confirmation avant d'écraser un fichier modifié par l'utilisateur. Pour Yum, je ne connais pas sont comportement par défaut.

guiguizmo
02/02/2016, 16h38
Merci.

C'est bien ce que j'avais commencer à sauvegarder.

Par contre, est ce que lorsque la mise à jour aura été faite, mon serveur continuera de tourner correctement si je ne reload pas asterisk ? En gros, si tous mes fichiers de config, toutes mes extensions, sont supprimées par la mise a jour, est ce que je pourrais tout remettre d'aplomb tranquillement pendant que mon serveur tournera avec son ancienne config ?

Autre question : à quoi sert le fichier /var/lib/asterisk/astdb.sqlite3 ?

Merci.

olppp
02/02/2016, 16h51
astdb.sqlite3 est une base "interne" à Asterisk ou il stocke des données sur les comptes enregistrés, les souscription mwi, les souscriptions de supervision, ...
consultable dans le CLI par la commande : database show.
Pour le redémarrage, je ne connais pas le comportement de yum.

guiguizmo
02/02/2016, 16h58
Je ne pense pas que yum, une fois l'installation d'odbc et la mise a jour des dépendances, lance automatiquement un reload d'asterisk ... mais une confirmation de la part d'un expert serait la bienvenue ^^

jean
02/02/2016, 17h52
essaie de voir avec yum quelle version d'asterisk il te propose, et laquelle tu fais tourner... si les versions sont très différentes, il faut voir

accessoirement, je viens juste d'installer odbc (pour accéder à une base perso), et c'est pas bien compliqué:
yum install unixODBC unixODBC-devel libtool-ltdl libtool-ltdl-devel
yum install mysql-connector-odbc

ensuite, configurer le connector dans /etc/odbcinst.ini
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/libmyodbc5.so
Setup = /usr/lib/libodbcmyS.so
Driver64 = /usr/lib64/libmyodbc5.so
Setup64 = /usr/lib64/libodbcmyS.so
FileUsage = 1

et /etc/odbc.ini
[asterisk-connector]
Description = MySQL connection to 'asterisk' database
Driver = Mysqldb
Database = asterisk
Server = localhost
UserName = root
Password = password
Port = 3306
Socket = /var/lib/mysql/mysql.sock


(il faut bien sur dans ce cas avoir une base mysql asterisk, avec et mettre à jour le passe root)

guiguizmo
02/02/2016, 18h03
J'ai moi aussi installé odbc, mais la je parle d'installer asterisk-odbc (le module asterisk qui permet de gérer odbc avec asterisk).

La version d'asterisk qu'il me propose est différente (13.3.2-1, moi je suis en 13.3.0-1), après je ne connais pas les détails sur ces différences ...

jean
02/02/2016, 22h18
en fait, quand on compile, on récupères les modules res_odbc et func-odbc, voire cdr_odbc, qui sont je pense dans ce package


le changement de sous-sous version me parait pas bien genant, ca doit essentiellement inclure des security fixes.... normalement, en cas de conflit, le gestionnaire de paquet propose le choix ou renome les nouveaux fichiers en .rpmnew

pour être tranquille lors de l'upgrade, il suffit de sauver /etc/asterisk, eventuellement /var/lib/asterisk/sounds (si tu as des fichiers audio à toi), /var/spool/asterisk (enregistrements) et /var/log/asterisk (essentiellement, les sous répertoires contiennent les cdr)

cdlt
j.

guiguizmo
04/02/2016, 11h58
Pour info, j'ai exécuté mon installation (yum install asterisk-odbc) et du coup la mise a jour d'asterisk ... sans aucun problème, pas d'écrasement de fichier, je n'ai rien eu a faire.

Donc j'arrive bien a stocker les CDR dans une base de donnée grâce a ODBC, par contre, j'ai les colonnes answer et end (toutes les 2 en DATETIME) qui ne se remplissent pas, pourtant lorsque je regarde les CDR csv, je vois bien ces 2 valeurs :

"","+33XXXXXXXXX","s","ivr","""+33XXXXXXXXX"" <+33XXXXXXXXX>","SIP/XXX.XXX.XXX.XXX-0000000","","WaitExten","","2016-02-04 09:17:54","2016-02-04 09:17:54","2016-02-04 09:18:24",30,30,"ANSWERED","DOCUMENTATION","1454577474.16",""

La première date est le start ou calldate, ensuite il y a le answer et enfin le end, et donc ces valeurs ne sont pas enregistrées dans ma base de données, j'ai toujours 0000-00-00 00:00:00 ...

Une idée ?

Merci.

olppp
04/02/2016, 12h04
Vérifies dans le schéma de ta base si les champs contenant des dates sont avec ou sans "timezone" et regardes dans les logs de la base.

guiguizmo
04/02/2016, 12h07
Comme expliqué dans mon précédent message, dans ma base, les champs answer et end sont en DATETIME

olppp
04/02/2016, 12h15
j'ai modifié ma réponse, je pensais à l'attribut timezone. As-tu des erreurs dans le CLI Asterisk lors des transactions ?

olppp
04/02/2016, 12h20
Pourquoi ne pas utiliser directement cdr_mysql ?

guiguizmo
04/02/2016, 12h22
Non pas d'erreur dans la CLI. De toute façon je ne vois pas dans la CLI les commandes qui enregistrent en BDD les CDR.

guiguizmo
04/02/2016, 12h41
Je viens de comprendre pourquoi les champs answer et end ne se remplissaient pas en examinant les logs mysql :

La requête ne prend pas en compte ces 2 champs, du coup est il possible de modifier ça ?

olppp
04/02/2016, 12h57
Tu dois avoir des champs duration et billsec qui te donne les mêmes informations.