Duda con en el envío de .call files a través de servidor NFS

[Miguel Alberto Sanz Pardo]

Hola  buenas tardes,

Quería compartir con vosotros un problema que estoy teniendo con el envío de .call files a través de un servidor NFS.

Dispongo de un sistema con este esquema:

SERVIDOR WEB    <----> SERVIDOR NFS   <-----> SERVIDOR ASTERISK

El servidor Asterisk tiene mapeados los directorios:

/var/spool/asterisk/voicemail/default

/var/spool/asterisk/outgoing 

en el sevidor NFS en los directorios

/home/voicemail

/home/outgoing/

A su vez el servidor web tiene mapeados los directorios:

/home/voicemail

/home/outgoing/

en el sevidor NFS en los directorios

/home/voicemail

/home/outgoing/

En lo que respecta a la carpeta voicemail no estoy teniendo ningún problema, los audios son compartidos entre el server web y el server Asterisk sin problemas a través del server NFS

Sin embargo en lo que respecta a la carpeta outgoing estoy teniendo un problema:

- Si creo el .call en el server Asterisk en una carpeta temporal y hago un mv a la carpeta /var/spool/asterisk/outgoing se genera una llamada de manera automática hacia un teléfono sin ningún problema (eso sí,, si dicho .call file es enviado desde el user "root" da un warning en el utime, y si es enviado desde el user "asterisk" no aparece dicho error, debido a que la instancia de asterisk pertenece al user llamado asterisk y no al root)

- Si creo el .call ya sea en el server NFS o en el server web y lo muevo a la carpeta /home/outgoing la llamada no se genera de manera automática y se genera de forma aleatoria al cabo de un tiempo indeterminado

¿Alguna idea de por qué puede estar pasando esto? ¿Acaso la centralita Asterisk solo permite usar call files de manera "interna"? Si fuera problema de permisos entiendo que ni siquiera debería de ejecutarse el call, pero sin embargo se ejecuta al cabo de un tiempo indeterminado.

Se me ocurre como alternativa tener mapeada una carpeta temporal donde se guarden los .call y que cada vez que se quiera generar una llamada desde el interfaz web, se realice una conexión mediante ssh a la centralita Asterisk y se le envie el comando mv correspondiente., pero no se si es lo más correcto.

un saludo

Miguel Sanz

[Raúl Alexis Betancor Santana]

Es un problema de opciones de montaje de el NFS ... cuidadito con las opciones noatime para esos volúmenes.

---

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Miguel Alberto Sanz Pardo]

Hola Raúl, ¿A qué te refieres exactamente?

IP servidor NFS: 192.168.1.88

IP servidor Asterisk: 192.68.1.90

En el servidor NFS hago algo de este estilo:

# yum install nfs-utils nfs-utils-lib

# chkconfig nfs on

# service rpcbind start

# service nfs start

# vi /etc/exports

/home 192.168.1.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)

# exportfs -a

En el cliente NFS(En este caso mi centralita Asterisk) hago algo de este estilo:

# yum install nfs-utils nfs-utils-lib

# mount 192.168.1.88:/home/voicemail /var/spool/asterisk/voicemail/default

# mount 192.168.1.88:/home/outgoing /var/spool/asterisk/outgoing

# df -h

# mount

# vi /etc/fstab

192.168.1.88:/home/voicemail /var/spool/asterisk/voicemail/default nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0

192.168.1.88:/home/outgoing /var/spool/asterisk/outgoing nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0

#mount -a

#df -h

En el fstab configuré esas opciones, ¿me recomiendas que varíe algo en la configuración?

un saludo y gracias por tu ayuda

Miguel Sanz

[Raúl Alexis Betancor Santana]

# vi /etc/fstab

192.168.1.88:/home/voicemail /var/spool/asterisk/voicemail/default nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0

192.168.1.88:/home/outgoing /var/spool/asterisk/outgoing nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0

#mount -a

#df -h

En el fstab configuré esas opciones, ¿me recomiendas que varíe algo en la configuración?

Te recomiendo que leas el man de mount.nfs y veas lo que significan las opciones que has puesto en el fstab, sobre todo la de noatime y luego pienses que consecuencias puede tener para un proceso que se basa en eso para saber cuando una carpeta se ha modificado ... ;)

Por cierto ... para el voicemail-notify de Asterisk, si es que lo usáis ... también te dará por donde amargan los pepinos.

[Miguel Alberto Sanz Pardo]

Acabo de revisar el comando mount: http://linux.die.net/man/8/mount

Y acabo de ver que la option --> noatime en teoría lo que hace es que no se actualicen los "Access timestamps" cuando un archivo es leído.

¿Debería desactivarla para que el daemon de asterisk que mira en el /var/spool/asterisk/outgoing vea que ha habido una actualización en los "acces timestamps" y "chupe" el .call de manera instantánea?

[Miguel Alberto Sanz Pardo]

La verdad es que seguí un par de tutos para montar un server NFS y un cliente NFS y aparecían dichas options en la configuración del fstab y lo seguí al pie de la letra. Revisando todos los parámetros:

 nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0

http://linux.die.net/man/5/nfs

http://linux.die.net/man/8/mount

auto

Can be mounted with the -a option.

noatime

Do not update inode access times on this filesystem (e.g, for faster access on the news spool to speed up news servers).

lock / nolock

Selects whether to use the NLM sideband protocol to lock files on the server. If neither option is specified (or if lock is specified), NLM locking is used for this mount point. When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client. Remote applications are not affected by these locks.

NLM locking must be disabled with the nolock option when using NFS to mount /var because /var contains files used by the NLM implementation on Linux. Using the nolock option is also required when mounting exports on NFS servers that do not support the NLM protocol.

bg/fg

Determines how the mount(8) command behaves if an attempt to mount an export fails. The fg option causes mount(8) to exit with an error status if any part of the mount request times out or fails outright. This is called a "foreground" mount, and is the default behavior if neither the fg nor bg mount option is specified.

If the bg option is specified, a timeout or failure causes the mount(8) command to fork a child which continues to attempt to mount the export. The parent immediately returns with a zero exit code. This is known as a "background" mount.

If the local mount point directory is missing, the mount(8) command acts as if the mount request timed out. This permits nested NFS mounts specified in /etc/fstab to proceed in any order during system initialization, even if some NFS servers are not yet available. Alternatively these issues can be addressed using an automounter (refer to automount(8) for details).

nfsvers=n

The NFS protocol version number used to contact the server's NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.

intr / nointr

Selects whether to allow signals to interrupt file operations on this mount point. If neither option is specified (or if nointr is specified), signals do not interrupt NFS file operations. If intr is specified, system calls return EINTR if an in-progress NFS operation is interrupted by a signal.

Using the intr option is preferred to using the soft option because it is significantly less likely to result in data corruption.

The intr / nointr mount option is deprecated after kernel 2.6.25. Only SIGKILL can interrupt a pending NFS operation on these kernels, and if specified, this mount option is ignored to provide backwards compatibility with older kernels.

tcp

The tcp option is an alternative to specifying proto=tcp. It is included for compatibility with other operating systems.

actimeo=n

Using actimeo sets all of acregmin, acregmax, acdirmin, and acdirmax to the same value. If this option is not specified, the NFS client uses the defaults for each of these options listed above.

Entiendo que la única option que podría estar fastidiándome es noatime, diría que el resto de las options no me afectan para mal.

He estado revisando las options con respecto al parámetro "atime" y he visto estas posibilidades:

- diratime

Update directory inode access times on this filesystem. This is the default.

- nodiratime

Do not update directory inode access times on this filesystem.

- atime

Do not use noatime feature, then the inode access time is controlled by kernel defaults. See also the description for strictatime and relatime mount options.

- noatime

Do not update inode access times on this filesystem (e.g, for faster access on the news spool to speed up news servers).

- relatime

Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.)

- norelatime

Do not use relatime feature. See also the strictatime mount option.

- strictatime

Allows to explicitly requesting full atime updates. This makes it possible for kernel to defaults to relatime or noatime but still allow userspace to override it. For more details about the default system mount options see /proc/mounts.

- nostrictatime

Use the kernel's default behaviour for inode access time updates.

Con usar atime en vez de noatime entiendo que sería más que suficiente ¿No?

[Miguel Alberto Sanz Pardo]

He probado a usar los parámetros:

atime y nostrictatime de manera separada y conjunta pero el .call sigue sin enviar la llamada de manera instantánea. ¿No deberían ser estos los parámetros a usar al montar la unidad desde el cliente para que el timestamp se actualice de manera instantánea?

[Miguel Alberto Sanz Pardo]

En las pruebas que estoy realizando el timestamp de los archivos que envío por NFS es más antiguo que la fecha actual del server donde está instalada la centralita. ¿No debería de funcionar de esta manera?

En https://wiki.asterisk.org/wiki/display/AST/Asterisk+Call+Files comentan esto:

NFS Considerations

By default, Asterisk will prefer to use inotify or kqueue where available. When the spooling directory is on a remote server and is mounted via NFS, the inotify method will fail to work. You can force Asterisk to use the older polling method by passing the --without-inotify flag to configure during compilation (e.g. ./configure --without-inotify).

No sé si irán por ahí los tiros.

[Miguel Alberto Sanz Pardo]

Acabo de echar un vistazo a los users y groups que hay en el server Asterisk:

# cat /etc/passwd

asterisk:x:499:498::...

saslauth:x:498:76:...

# cat /etc/group

asterisk:x:498:prosody

# groups asterisk

asterisk

# groups prosody

prosody asterisk

Y en el server NFS:

# cat /etc/passwd

saslauth:x:499:76...

Y en el client NFS:

saslauth:x:499:76...

¿Podría haber algún problema debido a que la UID del usuario saslauth en el NFS server sea igual a la UID del usuario asterisk en el server Asterisk?

¿Podría haber algún problema debido a que la UID del usuario saslauth en el server Asterisk sea igual a la GID del grupo asterisk en el server Asterisk?

un saludo

Miguel Sanz

[Miguel Alberto Sanz Pardo]

Actualmente la única forma de la que he conseguido hacer funcionar el envío de call files desde el Servidor Web hacia el server Asterisk a través de un server NFS ha sido:

- Compartir una carpeta temporal entre servidor web, servidor NFS y server Asterisk

- Disponer de un cron en el server Asterisk que cada X segundos mire dicha carpeta y si encuentra algún .call que lo envíe a /var/spool/asterisk/outgoing

Tiene que haber alguna manera de hacer que esto funcione de manera directa mediante NFS mapeando la carpeta /var/spool/asterisk/outgoing pero no acabo de ver como lograr hacer que funcione, si alguien tiene una idea de cómo poder solucionar esto de manera correcta se lo agradecería de corazón que me ayudara.

un saludo

Miguel Sanz

[Raúl Alexis Betancor Santana]

Los UID dan igual ... siempre y cuando el Asterisk lo vea como asterisk.asterisk ... sino ... mecccccc!

---

De: "miguelsanzpardo" <miguels...@gmail.com>
Para: "asterisk-es" <aster...@googlegroups.com>

--

[Miguel Alberto Sanz Pardo]

Hola Raúl,

Creé tanto en el server NFS como en el server web un user/group --> asterisk/asterisk

# cat /etc/passwd

asterisk:x:500:100::/home/asterisk:/bin/bash

# cat /etc/group

asterisk:x:500:asterisk

Si a las carpetas que están en el NFS server y en el WEB server (/home/voicemail/ y /home/outgoing) les doy permisos de esta manera:

# chown -R asterisk /home/voicemail

# chgrp -R asterisk /home/voicemail

# chown -R asterisk /home/outgoing

# chgrp -R asterisk /home/outgoing

En tal caso, si hacemos un ls -l desde /var/spool/asterisk/:

# ls -l

drwxrwxrwx  2      500      500 4096 Nov 30 16:36 outgoing

Podemos ver que no existe un usuario:grupo asterisk:asterisk asociado a dicho directorio, sino que aparece un usuario:grupo 500:500.

Si guardamos un archivo .call en el directorio /tmp del web server y le damos permisos de usuario:grupo asterisk:asterisk y a continuación hacemos un mv de dicho archivo hacia el directorio /home/outgoing, en el directorio /var/spool/asterisk/outgoing de la centralita Asterisk podemos ver dicho archivo .call cuyo usuario:grupo es 500:500. De tal manera, el archivo .call no efectúa la llamada de forma automática.

Si como alternativa

- Creamos un directorio /home/tmp (en el server WEB y en el server NFS) y lo mapeamos en /var/spool/asterisk/tmp

- Creamos un archivo .call en /home/tmp en el server WEB de manera que aparezca mapeado en /var/spool/asterisk/tmp

- Movemos dicho .call desde /var/spool/asterisk/tmp hacia /var/spool/asterisk/outgoing se genera la llamada de forma automática

No soy capaz de ver qué estoy haciendo mal, pero el caso es que no está funcionando de manera directa como entiendo que debería de funcionar.

[Miguel Alberto Sanz Pardo]

Otras alternativas que se me ocurren son:

- hacer un scp del fichero .call desde el server Web hacia la carpeta /var/spool/asterisk/outgoing del server Asterisk directamente (aunque se recomiendo hacer mv en vez de cp si mal no recuerdo)

o

- hacer un scp del fichero .call desde el server Web hacia la carpeta /var/spool/asterisk/tmp del server Asterisk y a continuación establecer una conexión ssh y hacer un mv hacia la carpeta /var/spool/asterisk/outgoing

[Miguel Alberto Sanz Pardo]

Por cierto, el problema de que no haga caso a los .call que comparto mediante NFS¿Podría ser debido a esto?

[Elio Rojano]

El directorio /var/spool/asterisk/outgoing es "parseado" unas 2000 veces por segundo, lo que significa que si "copias" un archivo, es probable que el parseo ocurra MIENTRAS el archivo está siendo grabado y no haya finalizado, por lo que Asterisk se encontrará con un .call a medio hacer.

Por esta razón, lo mejor es copiar de NFS a un directorio temporal y de ahí "moverlo" al directorio "spool".

Imaginate la carga de red que puede significar acceder 2000 veces por segundo a un directorio NFS...

--

Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Página web: http://www.sinologic.net/

Twitter: http://twitter.com/hellc2

LinkedIn: http://es.linkedin.com/in/rojano

[Raúl Alexis Betancor Santana]

Lo que estás haciendo mal es que no tienes en los servers el mismo uid/gid para ese usuario.

Osea .. si en el servidor Asterisk, el uid/gid es 500:500 ... TE IMPORTA UN CARAJO que sean esos IDs en el NFS y el webserver, cuando crees el fichero desde el webserver en el NFS, HAZLO con esos uid:gid ... que son los que necesita el server Asterisk.

Además ... crear el fichero directamente y escribir en él ... no es buena idea.

Yo crearía el fichero en un /tmp del webserver y después de cambiarle el uid:gid por los que necesite el server asterisk, lo movería a la carpeta del NFS, listo. Sin más complicaciones.

---

De: "miguelsanzpardo" <miguels...@gmail.com>
Para: "asterisk-es" <aster...@googlegroups.com>

--

[Miguel Alberto Sanz Pardo]

Muchas gracias por la info. Elio ;) , 

Como verás me estoy peleando (y dando de cabezazos contra un muro) con el envío de .call files mediante NFS. Por lo que me comentas entiendo que tratar de compartir archivos .call mediante NFS mapeando directamente contra la carpeta /var/spool/asterisk/outgoing es una mala idea ¿No?

No sé si además de problemas por el parseo podría haber algún otro problema más debido a una configuración incorrecta de algún parámetro por mi parte en lo que respecta a NFS. A la hora de compartir los ficheros de audio del voicemail mediante NFS (/var/spool/asterisk7voicemail) por ahora no he tenido problemas.

Mediante las pruebas que he realizado lo que he notado es que:

- Cuando copio un .call a un directorio que está mapeado mediante NFS contra /var/spool/asterisk/outgoing la llamada de genera al cabo de un tiempo indeterminado o incluso no se ejecuta

- Cuando copio un .call a un directorio que está mapeado mediante NFS contra /var/spool/asterisk/outgoing si paro el servicio asterisk y lo vuelvo a arrancar entonces SI lee el .call y genera la llamada de manera automática.

un saludo y gracias a todos por vuestra ayuda

[Gaston Draque]

Miguel,

   1ro. creo que haces bien en compartir lo que haces y postear como vas elaborando las cosas, eso tiene valor en si mismo para ti, y para quien venga detras.

   2do. dependiendo de la aplicacion que estes desarrollando, puede que te sea mas sensillo usar AMI para iniciar las llamadas. Nuevamente, no se como es tu aplicacion, pero AMI es muy simple de implementar y facil de programar.

Saludos y suerte!

Gaston//

[Miguel Alberto Sanz Pardo]

Hola Raúl, como de costumbre muchas gracias por tu ayuda

Entonces ¿Moverías el .call directamente a la carpeta del Web Server que mapea /var/spool/asterisk/outgoing ?

¿No podría haber problemas con el parseo tal y como comentaba Elio?

En el servidor Asterik el uid:gid si no me confundo es: 

# cat /etc/passwd | grep asterisk

asterisk:x:499:498::/home/asterisk:/bin/bash

Entonces el fichero que cree en el Sever Web debería tener como uid/gid 499:498 ¿No?

[Miguel Alberto Sanz Pardo]

Hola Gastón muchas gracias por el apunte,

Tendré en cuenta dicha opción(AMI), no obstante para enviarle comandos a la centralita mediante AMI, la conexión de manera remota se realiza mediante Telnet ¿Verdad? En tal caso entiendo que podría haber algún problema de seguridad , ya me corregirás si me confundo

un saludo

Miguel Sanz

[Miguel Alberto Sanz Pardo]

Por cierto, he probado a re-compilar asterisk de esta manera:

$ ./configure --libdir=/usr/lib64 --without-inotify

$ contrib/scripts/get_mp3_source.sh

$ make menuconfig

$ make

$ make install

Y de esta manera incluso sin modificar el UID/GID de los archivos .call,  al copiar dichos .call mediante NFS en el directorio que mapea /var/spool/asterisk/outgoing se genera la llamada de manera automática

¿Alguna idea de por qué quitando el inotify también se consigue evitar este problema?

[Miguel Alberto Sanz Pardo]

Hola Raúl, 

Probé la alternativa que me comentas para comprobar que también funcionaba, pero al mover el archivo a la carpeta mapeada en el NFS server asociada a  /var/spool/asterisk/outgoing no se ejecuta la llamada de manera automática.

Creé el fichero en un /tmp del webserver y después de cambiarle el uid:gid por los que necesita mi server asterisk(499 user, 498 grupo), lo moví a la carpeta mapeada de /var/spool/asterisk/outgoing que está en el NFS y no reaccionó.

Desde Asterisk si voy al directorio: /var/spool/asterisk/outgoing 

puedo ver un archivo con estos permisos:

-rwxrwxrwx 1 asterisk asterisk 129 Nov 30  2015 1001.call

y sin embargo no se genera la llamada.

Voy a implementar lo que me dijo Elio; es decir:

1º) Crear el .call en un directorio temporal que es compartido mediante NFS entre el server Asterisk y el server web,

2º) Copiar dicho archivo desde dicho directorio temporal (NFS) a un directorio temporal que esté en la centralita Asterisk

3º) Mover dicho archivo que está en un directorio temporal de la centralita Asterisk al directorio /var/spool/asterisk/outgoing.

un saludo y gracias por tu ayuda

Miguel Sanz

El martes, 1 de diciembre de 2015, 13:29:20 (UTC+1), Latino escribió: