7 votos

Mac OS X Server, servicios de Correo y Notificaciones Push a los dispositivos iOS

  • Estoy ejecutando OS X 10.9 con el Servidor 3.0.1 en un Mac que residen en una subred privada sentado detrás de un router cuya puerto WAN está conectado a un módem de cable, por lo tanto el ISP es un conocido de cable de proveedor de servicios de internet.

  • Este servidor tiene sus DNS configurado correctamente (es decir, el resultado de "sudo changeip -checkhostname" en el servidor a través de la línea de comandos proporciona resultados perfectos).

  • Este servidor se está ejecutando un Open Directory Maestro.

  • Dynamic DNS está configurado correctamente para el router, y resuelve la dirección IP pública asignada por mi ISP para el mismo dominio que el servidor (me adelante cualquier puertos necesarios para los servicios de I run).

  • Este servidor también se ha instalado un servidor de certificado firmado por una CA de confianza (es decir, Go Daddy) y funciona a la perfección para todas las versiones de OS X Server de servicios, incluyendo servicios de Directorio Abierto.

  • Este servidor también tiene el servicio de Correo configurado (SMTP e IMAP) sin problemas (me pueden enviar y recibir correo desde el servidor.

  • Este servidor también tiene notificaciones push activado y tiene una notificación de inserción certificado instalado perfectamente (obtenido a partir de notificación push de Apple certificado portal, acaba de ser renovada hace un par de días).

  • Tengo algunos dispositivos iOS con iOS 7.0.4. He configurado el Correo en estos dispositivos iOS para enviar y recibir correo desde el mencionado servidor para un par de diferentes cuentas de usuario en el servidor. Esto funciona bien (probado, puede enviar y recibir correo sin problemas).

  • Los mencionados dispositivos iOS opciones de configuración de correo para el mencionado servidor ha sido configurado para recibir notificaciones push cuando se recibe el correo, dijo que las cuentas de usuario en el servidor.

Con todo eso dicho, los dispositivos iOS son a veces capaces de recibir notificaciones push desde el Servicio de Notificación Push de Apple (APNS "en la nube") en situaciones en las que los dispositivos iOS residen en la misma subred que el servidor Mac (a través de Wi-Fi), y cuando se encuentren en el público a Internet (a través de redes de datos celulares o redes Wi-Fi públicas, tales como tiendas de café).

Por lo tanto, las notificaciones push hacer el trabajo cuando los mensajes de correo en el servidor son recibidos, pero no siempre. Después de un período de tiempo que ha transcurrido en el servidor en el cual no hay mensajes de correo electrónico, han sido recibidos (que parece ser de varias horas, pero todavía no he sido capaz de localizar exactamente), el servidor aparentemente pierde lo que se supone que es un persistente conexión con el APN de la puerta de enlace. OS X Server lamentablemente no registra cuando esta conexión se pierde. Entonces, cuando un nuevo mensaje de correo electrónico, finalmente, llega de nuevo después de varias horas y es recibido por el servidor, los dispositivos iOS hacen que no reciben su esperado notificaciones push y en lugar de OS X Server constantemente registra un mensaje de error como este (la única diferencia es, por supuesto, el proceso de IDENTIFICACIÓN y marca de fecha/hora):

11/26/13 5:48:11.762 AM push_notify[181]: stream: received error: The operation couldn't be completed. Connection reset by peer on: incoming stream: APN to host: gateway.push.apple.com:2195

Una vez que el tipo de error se registran en los registros, un posterior mensaje de correo electrónico enviado al servidor correctamente, se genera una notificación de inserción de mensajes en la configuración de los dispositivos iOS tan larga como el mensaje es enviado antes de tiempo mínimo ha transcurrido (es decir, varias horas). Yo no port forward de puertos 2195 o 2196 desde el router a la Mac del servidor debido a que Apple documento de soporte implica que estos puertos son para el tráfico de salida (desde el servidor a los APN de la puerta de enlace) a menos que yo lo he entendido mal.

Un extracto de Apple Mac Desarrollador Técnico de la Biblioteca de la Nota TN2265 me llamó la atención con respecto a la inactividad:

Un ocasional desconecte mientras que su proveedor está inactiva es nada preocupa; volver a establecer la conexión y llevar a cabo. Si uno de la inserción de los servidores de abajo, el mecanismo de equilibrio de carga se de forma transparente directo su nueva conexión a otro servidor, asumiendo se conecta por el nombre de host y no por dirección IP estática.

Se OS X Server (el "proveedor" en este contexto), básicamente, "llevar" por el de "re-crear" la conexión APN después de ser "inactivo" por varias horas, como se observó en los registros por el error de secuencia citado?

Alguien me habló acerca de este postulado los problemas mencionados, puede ser debido a que el puerto WAN del router no se les ha asignado una dirección IP estática por mi ISP, pero de toda la documentación para desarrolladores de Apple y el apoyo docs he investigado acerca de las notificaciones push con OS X Server no indique una dirección IP estática es necesaria.

nota: también he probado con el mismo hardware y la configuración, pero el sistema operativo OS X Mountain Lion 10.8.5 con el Servidor de la aplicación 2.2.1 con esencialmente los mismos resultados pero en mi humilde opinión mejor registro de verbosidad, como en:

11/29/13 11:16:55.713 PM push_notify[11951]: stream: received error: The operation couldn't be completed. Connection reset by peer on: incoming stream: APN to host: gateway.push.apple.com:2195

11/29/13 11:16:55.722 PM push_notify[11951]: Disconnected from apn server gateway.push.apple.com for topic com.apple.mail.XServer.2a132c32-dda4-45a1-68e1-b3cca3865c12: error Connection reset by peer

11/29/13 11:16:55.722 PM push_notify[11951]: will attempt to reconnect stream APN to host gateway.push.apple.com:2195 in 15 seconds

Cualquier ayuda o sugerencia resolver esto sería muy apreciado, puede ser algo simple que he pasado por alto.

1voto

Cameron Puntos 1371

Este problema se ha resuelto. El ASUS "el Caballero Oscuro" router que estaba prestando a la LAN privada (NAT) y reenvío de puerto para el Mac con OS X Server tiene un error de firmware. El error manifiesto con una CAÍDA de la conexión TCP ESTABLECIDA en el puerto 2195 entre el Mac con OS X Server y APN, después de dos horas de quietud. El router no debe haber caído de esta conexión, no había ninguna regla de firewall instruye a hacerlo. La lección que hemos aprendido es a ser mucho más selectivo y sabio con respecto a la elección de los routers (especialmente de los consumidores off-the-shelf variedad) para su uso con servidores, incluso para los servidores se ejecutan en una pequeña empresa de contexto (como un Mac Mini Server).

Título

0voto

Tony Williams Puntos 4903

Mis primeros pasos en el diagnóstico sería adelante tanto a los puertos y a ver qué pasa (yo incluso podría poner la máquina en una DMZ para un par de horas).

Me gustaría a continuación, poner un sniffer de paquetes en el 17.0.0.0/8 bloque de direcciones y ver lo que el tráfico en los puertos va a través de la red cuando funciona y cuando no.

0voto

Dom Puntos 646

Yo creo que @user3051849 tiene la root de la causa, pero en mi caso yo no puedo cambiar el router. Así, le adjunto mis dos soluciones. Como de OSX Server 3.1.2 este problema permanece.

El uso de Apple launchctl para crear un trabajo que se ejecuta cada 2 horas para reiniciar el servidor de correo. Así, esto sólo debe ser usado en los servidores de correo que no están ocupados. Crear un archivo plist en /Library/LaunchDaemons/MailRestart.plist, el contenido debe ser:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>mailrestart</string>
    <key>ProgramArguments</key>
    <array>
        <string>/etc/periodic/daily/500.restart-mail</string>
    </array>
    <key>StartInterval</key>
    <integer>7200</integer> <!-- Every 2 hours -->
    <key>StandardOutPath</key>
    <string>/var/log/daily.out</string>
</dict>
</plist>

Tenga en cuenta que este lanzamiento se ejecuta el agente de Apple /etc/periodic/daily/500.restart-mail script cada 2 horas (7200 segundos). En el caso de Apple elimina al reiniciar el correo de secuencia de comandos, aquí está una copia para su comodidad.

Como un aparte, parece que Apple es consciente de los problemas de conexión con su servicio push, ya que creó el periódico de secuencia de comandos para reiniciar el servidor de correo durante la ejecución diaria de la periodic de servicio. Sin embargo, su corrección es más bien débil, porque en mi caso el periódico el servicio funciona todos los días, pero mi conexión con el servicio push se coloca después de 2 horas de inactividad. Por lo tanto, necesito algo más frecuente de lo que un diario correo de reiniciar el servidor.

Desde un shell invocar:

sudo launchctl load /Library/LaunchDaemons/MailRestart.plist

Este comando carga el script en la puesta en marcha del servicio de Control causando que el script se ejecute cada 2 horas, registro en /var/log/día.(el mismo destino que el periódico de los registros de servicio). En mi caso necesitaba cambiar esto a menos de una hora, en lugar de cada 2.

Un Mejor Enfoque Una solución alternativa es dejar el demonio de correo solo y matar el proceso que se encarga de las notificaciones push, es decir,. push_notify. Esto tiene el beneficio añadido de no matar el correo demonios que puede interrumpir las conexiones imap. Por ejemplo, el comando:

sudo launchctl stop com.apple.push_notify

Detiene el push_notify servicio, launchd inmediatamente se reinicia el servicio después. Así, el nuevo proceso tendrá una conexión fresca para Apple servidores de notificación. Se los dejo como ejercicio para el lector para envolver el anterior en un script y ejecutarlo desde un modificado plist como el anterior.

0voto

Cameron Puntos 1371

Lo que originalmente se presentó un informe de error con respecto a este problema con Apple (en el momento en que no estábamos de forma determinista seguro de que era un error, pero teniendo en cuenta los esfuerzos que hemos hecho para resolver este con Apple de apoyo a las empresas, parecía probabilísticamente a ser un error). Recientemente Apple ingeniería nos respondió diciendo que ellos han tratado de solucionar este bug en la app Server versión 4. Server 4 requiere que se ejecute en OS X 10.10 Yosemite. Hemos probado con el Servidor 4.0.3 que se ejecuta en OS X 10.10.2 Yosemite con dos iPhones cada uno con iOS 8.1.3 y nuestro router sigue siendo un Ubiquiti EdgeRouter (con cambios a la configuración del router). Para versiones anteriores de Servidor, suponiendo que este error sigue siendo fijadas en esas versiones, la solución ofrecida por Josh puede ser su mejor mejor.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by: