Mac OS X Server Servizi di posta e notifiche push ai dispositivi iOS

Naviga le tue risposte
7

  • Sto utilizzando OS X 10.9 con Server 3.0.1 su un Mac che risiede su una subnet privata posta dietro un router la cui porta WAN è collegata a un modem via cavo, quindi l'ISP è un noto servizio Internet via cavo fornitore.

  • Questo server ha il suo DNS configurato correttamente (ad esempio, il risultato di "sudo changeip -checkhostname" sul server tramite riga di comando produce risultati perfetti).

  • Questo server sta eseguendo un Open Directory Master.

  • Il DNS dinamico è configurato correttamente per il router e risolve l'indirizzo IP pubblico assegnato dal mio ISP allo stesso nome di dominio del server (inoltro eventuali porte richieste per i servizi che eseguo).

  • Questo server ha anche installato un certificato server firmato da una CA attendibile (ad esempio, Go Daddy) e funziona perfettamente per tutti i servizi di OS X Server, tra cui Open Directory.

  • Questo server ha anche il servizio di posta configurato (SMTP e IMAP) senza problemi (posso inviare e ricevere posta al / dal server.

  • Questo server server ha anche notifiche push abilitate e ha un certificato di notifica push installato perfettamente (ottenuto dal portale dei certificati di notifica push di Apple, appena rinnovato pochi giorni fa).

  • Ho alcuni dispositivi iOS con iOS 7.0.4. Ho configurato Mail su questi dispositivi iOS per inviare e ricevere posta da / verso il server sopra menzionato per alcuni account utente diversi sul server. Funziona bene (testato, può inviare e ricevere posta senza problemi).

  • Le suddette impostazioni della posta dei dispositivi iOS per il server sopra menzionato sono state configurate per ricevere notifiche push quando la posta viene ricevuta a detti account utente sul server.

Con tutto ciò detto, i dispositivi iOS sono a volte in grado di ricevere notifiche push da Servizio di notifica push Apple ("cloud" APNS) in situazioni in cui i dispositivi iOS risiedono nella stessa sottorete privata del server Mac (tramite Wi-Fi), e quando risiedono su Internet pubblica (tramite reti di dati cellulari o reti Wi-Fi pubbliche come le caffetterie).

Pertanto, le notifiche push do funzionano quando vengono ricevuti messaggi di posta elettronica sul server, ma non sempre. Dopo che è trascorso un certo periodo di tempo sul server in cui non sono stati ricevuti messaggi e-mail (sembra che siano passate diverse ore ma non sono ancora stato in grado di individuarlo con precisione), il server perde apparentemente quello che dovrebbe essere un persistente connessione con il gateway APNS. Sfortunatamente OS X Server non registra quando questa connessione viene persa. Quindi, quando un nuovo messaggio di posta elettronica arriva nuovamente dopo diverse ore e viene ricevuto dal server, i dispositivi iOS not ricevono le loro notifiche push previste e invece OS X Server registra in modo coerente un messaggio di errore come questo (le uniche differenze sono ovviamente l'ID del processo e l'ora / data): 

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 volta registrato il tipo di errore sopra riportato nei log, un successivo messaggio di posta elettronica inviato al server genera correttamente un messaggio di notifica push sui dispositivi iOS configurati a patto che il messaggio successivo venga inviato prima che sia trascorso il tempo minimo (cioè diversi ore). Non porto le porte 2195 o 2196 dal router al server Mac perché il documento di supporto di Apple implica che queste porte siano in uscita traffico (dal server al gateway APNS) a meno che non abbia frainteso.

Un estratto nella nota tecnica della libreria per sviluppatori Mac di Apple TN2265 ha attirato la mia attenzione su idle :

An occasional disconnect while your provider is idle is nothing to be concerned about; just re-establish the connection and carry on. If one of the push servers is down, the load balancing mechanism will transparently direct your new connection to another server assuming you connect by hostname and not by static IP address.

È OS X Server (il "provider" in questo contesto) essenzialmente "portare avanti" "ristabilendo" la connessione ad APNS dopo essere "inattivo" per diverse ore come indicato nei log per l'errore di flusso sopracitato ?

Qualcuno con cui ho parlato di questo problema potrebbe essere dovuto al fatto che alla porta WAN del router non è stato assegnato un indirizzo IP statico dal mio ISP, ma a tutti i documenti di documentazione e supporto degli sviluppatori Apple che ho visto sulle notifiche push con OS X Server non viene indicato un indirizzo IP statico.

nota: Ho anche provato questo con lo stesso hardware e le impostazioni, ma eseguendo OS X 10.8.5 Mountain Lion con Server App 2.2.1 con essenzialmente gli stessi risultati ma IMHO migliorava la verbosità del registro, come in: 

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

Qualsiasi aiuto o suggerimento per risolverlo sarebbe molto apprezzato, potrebbe essere qualcosa di semplice che ho trascurato.

    
posta user3051849 30.11.2013 - 12:30
fonte

4 risposte

0

Inizialmente abbiamo presentato una segnalazione di bug relativa a questo problema con Apple (al momento non eravamo determinati in modo deterministico che si trattava di un bug, ma considerando gli sforzi fatti per risolvere questo problema con il supporto di Apple Enterprise, sembrava essere un bug probabilistico ). Recentemente, l'ingegneria di Apple ci ha risposto affermando di aver tentato di correggere questo bug nella versione 4 del server. Il server 4 deve essere eseguito su OS X 10.10 Yosemite. Abbiamo testato con Server 4.0.3 su OS X 10.10.2 Yosemite con due iPhone ciascuno con iOS 8.1.3 e il nostro router rimane un Ubiquiti EdgeRouter (senza modifiche alla configurazione del router). Per le versioni precedenti di Server, supponendo che questo errore rimanga non fissato in tali versioni, la soluzione alternativa offerta da Josh potrebbe essere la migliore.

    
risposta data 08.02.2015 - 04:30
fonte
1

Questo problema è stato risolto. Il router ASUS "Dark Knight" che forniva la LAN privata (NAT) e il port forwarding su Mac con OS X Server ha un bug del firmware. Il bug si manifesta interrompendo la connessione TCP ESTABLISHED sulla porta 2195 tra il Mac che esegue OS X Server e APNS, dopo due ore di quiescenza. Il router non avrebbe dovuto abbandonare questa connessione, non esisteva alcuna regola del firewall che lo istruisse a farlo. La lezione appresa è di essere molto più selettivi e saggi in merito alla scelta dei router (in particolare varietà off-the-shelf dei consumatori) da utilizzare con i server anche per i server gestiti in un contesto di piccole imprese (come un Mac Mini Server).

Titolo

    
risposta data 21.04.2014 - 14:56
fonte
0

I miei primi passi nella diagnosi sarebbero di inoltrare entrambe le porte e vedere cosa succede (potrei persino mettere la macchina in una DMZ per un paio d'ore).

Quindi metterei uno sniffer di pacchetti sul blocco di indirizzi 17.0.0.0/8 e vedere quale traffico su quali porte stanno attraversando la rete quando funziona e quando non funziona.

    
risposta data 15.01.2014 - 08:51
fonte
0

Credo che @ user3051849 abbia la causa principale, ma nel mio caso non riesco a sostituire il router. Quindi, inclusi sono i miei due soluzioni alternative. A partire da OSX Server 3.1.2 questo problema rimane.

Usa il launchctl di Apple per creare un lavoro che viene eseguito ogni 2 ore per riavviare il server di posta. Quindi, questo dovrebbe essere usato solo su server di posta non occupati. Creare un file plist in /Library/LaunchDaemons/MailRestart.plist, il contenuto dovrebbe essere: 

<?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>

Nota che questo agente di lancio esegue lo script /etc/periodic/daily/500.restart-mail di Apple ogni 2 ore (7200 secondi). Nel caso in cui Apple rimuova lo script di riavvio della posta, ecco una copia per tua comodità.

Per inciso, sembra che Apple sia a conoscenza dei problemi di connessione con il loro servizio push, poiché hanno creato lo script periodico per riavviare il server di posta durante l'esecuzione giornaliera del servizio periodic . Tuttavia, la loro soluzione è piuttosto debole, perché nel mio caso il servizio periodico viene eseguito quotidianamente, ma la mia connessione al servizio push viene interrotta dopo 2 ore di inattività. Quindi, ho bisogno di qualcosa di più frequente di un riavvio giornaliero del server di posta.

Il prossimo da una shell chiama: 

sudo launchctl load /Library/LaunchDaemons/MailRestart.plist

Questo comando carica lo script nel servizio Launch Control facendo in modo che lo script venga eseguito ogni 2 ore, collegandosi a /var/log/daily.out (la stessa destinazione registrata anche dal servizio periodico). Nel mio caso ho dovuto cambiarlo in meno di un'ora, anziché ogni 2.

Un approccio migliore Una soluzione alternativa è lasciare il daemon della posta da solo e uccidere il processo che gestisce le notifiche push, es. push_notify. Questo ha l'ulteriore vantaggio di non uccidere i demoni della posta che possono interrompere le connessioni imap. Ad esempio, il comando: 

sudo launchctl stop com.apple.push_notify

Arresta il servizio push_notify, launchd riavvia immediatamente il servizio in seguito. Quindi, il nuovo processo avrà una nuova connessione con i server di notifica di Apple. Lascerò che sia un esercizio per il lettore avvolgere quanto sopra in uno script e invocarlo da un plist modificato come sopra.

    
risposta data 28.07.2014 - 16:56
fonte

Leggi altre domande sui tag

Restore ebooks (PDF) dal backup di iTunes? Il miglior approccio per l'integrazione aziendale