Buongiorno, Habr!
Compito
Nella mia organizzazione utilizziamo un server di posta sulla piattaforma Kerio Connect, con server di posta installati in diverse città che servono i propri utenti. Inizialmente non c'era una struttura distribuita, poiché i domini differivano al terzo livello con l'indicazione della città della sede. Tutto funzionava e andava bene per tutti. Un bel giorno — la dirigenza ha posto il compito di creare un calendario condiviso tra tutte le sedi!
Contesto
Inizialmente l'idea era di attivare un dominio di posta distribuito Kerio e che questo si occupasse di tutto. Detto, fatto: il dominio distribuito è stato creato, ma non è andata così. Il server era pronto a sincronizzare calendari, cartelle, contatti — tra i domini presenti su uno stesso server, ma non si è mai deciso a sincronizzare i dati tra più server.
Una sorpresa del genere non me l'aspettavo affatto e ho impiegato molto tempo a credere all'assenza della funzionalità che mi serviva. In seguito ho trovato una documentazione che confermava questo fatto, il che mi ha lasciato molto perplesso e deluso.
Il compito si è trasformato gradualmente in un problema.
Quali erano le opzioni
- Creare due clienti su server diversi che scambiassero i dati necessari tramite un software di terze parti. Dovevo trovare quel software di terze parti che realizzasse questa funzionalità – non mi piacciono queste complicazioni, ma sembrava che fosse l'unica soluzione rapida.
- Scrivere il proprio script di sincronizzazione dei dati tra i server. Il fatto è che Kerio memorizza ogni oggetto come un file separato, pertanto era necessario sviluppare uno script per gestire i file, ma a causa del numero considerevole di fonti la cosa sembrava un po' complicata, soprattutto considerando che era necessario eseguire molteplici verifiche sulla correttezza dei dati, nel caso in cui qualcuno createsse un evento nello stesso intervallo di tempo, e così via.
Per anticipare le cose, dirò che Kerio, anche se memorizza l'oggetto come un file separato, non è così stupido da chiedere ogni volta che accedo a un oggetto: come sta il sistema file.
Trascorrendo molto tempo a riflettere, riempiendo una miriade di fogli con piani "per la conquista del territorio nemico", alle sei di sera ho preso due decisioni sagge:
- La prima decisione – fare da solo e non cercare nulla di esterno.
- La seconda soluzione è andare a dormire.
Questa mattina mi sono svegliato con un pensiero chiaro e semplice, ridotto a poche lettere – DFS
Soluzione
La soluzione in sé si presentava nel seguente modo
- portare tutti i server che parteciperanno alla sincronizzazione a OS Windows. (Parte di essi era su Linux. era necessaria la migrazione dei dati e-mail su un altro OS)
- Stabilire la struttura delle directory che parteciperanno alla sincronizzazione — devono essere identiche.
- Determinare tutti i server di posta sotto un unico dominio con uno spazio DFS comune.
- Creare il dominio distribuito Kerio sopra menzionato, poiché nel mio caso è necessaria la sincronizzazione dei dati non solo tra i server ma anche tra i domini, il secondo può occuparsene autonomamente il server Kerio. (a differenza del primo)
- Collegare le directory sincronizzate allo spazio DFS.
- Inventare qualche escamotage (del resto, senza un escamotage non si può fare)
Implementazione
Esempio su due server di posta (potrebbero essere di più)
1. Dominio distribuito Kerio
Il Master non partecipa alla sincronizzazione, ma non è un prerequisito.
Non entrerò nei dettagli su come creare un dominio distribuito Kerio, non è nulla di complicato, puoi consultare la guida ufficiale
In definitiva, nel pannello di amministrazione dovresti vedere la seguente immagine:
In seguito, ero interessato alle cartelle condivise, sul server Master è possibile specificare le seguenti opzioni:
Speciale per ogni dominio — il server non sincronizzerà le cartelle pubbliche tra i domini
Condivise per tutti i domini — tutti i server rinunceranno alle esistenti cartelle condivise in ogni dominio e creeranno nuove cartelle unificate per tutti i domini su ciascun server di posta.
Attenzione! Questa opzione, anche se cambia la politica di configurazione su tutti i server, esegue la sincronizzazione separatamente per ciascun server (ossia — senza uno spazio comune unico)
L'amministratore avrà ancora la possibilità di distribuire gli accessi tra gli utenti.
nel mio caso — tutte le mie cartelle e ho bisogno di una sincronizzazione completa (Nel tuo caso, la soluzione potrebbe essere diversa) su ciascun server è necessario creare set identici di domini da sincronizzare.
2. Directory dei dati Kerio
Ora è necessario creare delle directory condivise identiche che devono essere sincronizzate su ciascun server. Cartelle, Calendari, Contatti.
Consiglio: crea cataloghi in inglese, perché se li crei in caratteri latini, il catalogo avrà un nome in una codifica incomprensibile, il che è perlomeno scomodo.
Ora è necessario trovare i percorsi fisici delle cartelle di posta su ciascun server.
Condivise per tutti i domini ~DataMailmail#publicCatalogo sincronizzato#msgs
Speciale per ogni dominio ~DataMailmail**Domain**#publicCatalogo sincronizzato#msgs
Si prega di notare che sincronizzeremo non l'intero catalogo, ma solo il contenitore con i dati. #msgs — qui vengono memorizzati gli oggetti stessi, mentre tutti gli altri dati per ciascun server devono essere specifici.
3. DFS
Non fornirò ulteriori dettagli su come configurare DFS, poiché ci sono già sufficienti informazioni a riguardo.
DFS è un servizio di ruolo in Windows Server che consente di unire le cartelle condivise su diversi server.
Prima di configurare DFS, è necessario fermare tutti i server di posta che parteciperanno alla sincronizzazione dei dati.
Al termine della configurazione, dovresti ottenere l'immagine seguente per ciascuna delle cartelle sincronizzate.
Naturalmente, non è necessario pubblicare le cartelle replicate.
Dopo che la replicazione è avvenuta (e in realtà non c'è molto da replicare - le cartelle sono vuote), i server di posta possono essere avviati.
Successivamente, è possibile riempire uno dei server di posta con dati e verificare che vengano replicati correttamente.
4. Soluzione temporanea
Descrizione della riflessione
Come potete vedere, dopo che i dati hanno iniziato a sincronizzarsi (DFS), nel caso in cui abbiate creato qualcosa sul primo server, sul secondo server non appare nulla, oppure appare ma non sempre.
Non vale la pena disperarsi, ovviamente, prima o poi apparirà, ma è meglio prima che dopo. Perché dopo significa tra 6-12 ore.
Il fatto è che non appena create qualcosa sul primo server, sul secondo e sugli ulteriori file appariranno immediatamente grazie al sistema DFS; tuttavia, se questa cartella di posta è già stata letta da qualcuno in precedenza e viene richiesta di nuovo, il server non leggerà di nuovo la cartella #msgs, ma restituirà i dati dal proprio indice, che potrebbe non corrispondere alla nostra realtà da tempo.
Kerio ha un meccanismo di rielaborazione dell'indice, ma può richiedere circa sei ore; in questo lasso di tempo, la rilevanza del compito nel calendario potrebbe andare persa.
Per controllare il funzionamento della sincronizzazione in questo momento, è possibile eliminare il file nella cartella sincronizzata index.fld; dopo aver riacceduto alla cartella sul server di posta e in assenza di questo file, Kerio rielaborerà la cartella e i dati appariranno. Sembra una soluzione: elimina il file quando i dati cambiano, ma questo funziona solo la prima volta; poi Kerio sembra perdere interesse per index.fld.
Inizia anche a restituire messaggi incomprensibili per l'utente riguardo a un certo indice e a cosa stia facendo.
C'è anche la possibilità che qualcosa venga creato: nel momento della creazione di un nuovo oggetto, il server potrebbe rendersi conto che il nome del file che voleva assegnare è già occupato, ma qui si tratta di un vicolo cieco.
E quindi, cosa si può fare?
Se si presta ancora attenzione all'immagine già nota.
Ma in un'altra dimensione, si può notare un pulsante molto interessante e utile per noi in questo momento— Reindicizzare le cartelle
E davvero. Se si preme questo pulsante su un server di posta che non sa che qualcosa è già cambiato nei #msgs sincronizzati, otterremo un risultato stabile e veloce. Tutto ciò che è nascosto diventerà evidente.
Nel registro è possibile vedere quanto tempo impiega questo processo; nel mio caso, con diverse migliaia (15.000) di registrazioni, ci vogliono circa 3-4 minuti.
Resta solo da trovare un modo per premere questo pulsante quando ne abbiamo bisogno.
A quanto pare, Kerio ha la sua API
Funzione, che svolge il nostro compito, ed è così che appare –
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)
Di tutto quanto sopra, abbiamo bisogno di scrivere uno script che monitori lo stato delle cartelle di nostro interesse e, nel caso in cui qualcosa sia cambiato, esegua la funzione di cui abbiamo bisogno.
Voglio dire che ho scritto diverse versioni di script che eseguono controlli diversi, ma mi sono fermato a quello che costruisce tutti i risultati basandosi sul numero di file.
Implementazione dello script
Esempio di script CMD e descrizione
Re-index.bat
@echo off
set dir=%~dp0
%dir:~0,2%
CD "%~dp0"
md "%CD%LOG"
md "%CD%Setup"
ECHO -Start- >> "%CD%LOG%Computername%.log"
ECHO Start -> %Computername% %Date% %Time% >> "%CD%LOG%Computername%.log"
SetLocal EnableDelayedExpansion
for /f "UseBackQ Delims=" %%A IN ("%CD%Setup%Computername%.List") do (
set /a c+=1
set "m!c!=%%A"
)
set d=%c%
Echo Folder = %c%
ECHO Folder = %c% >> "%CD%LOG%Computername%.log"
ECHO.
ECHO. >> "%CD%LOG%Computername%.log"
:start
cls
if %c% LSS 1 exit
set /a id=1
set R=0
:Find
REM PF-Start
if "%id%" gtr "%c%" if %R% == 1 Goto Reindex
if "%id%" gtr "%c%" timeout 60 && Goto start
For /F "tokens=1-3" %%a IN ('Dir "!m%id%!#msgs" /-C/S/A:-D') Do Set 2DirSize!id!=!DS!& Set DS=%%c
if "2DirSize!id!" == "" set 1DirSize!id!=!2DirSize%id%!
echo %id%
ECHO !m%id%!
echo Count [ !1DirSize%id%! -- !2DirSize%id%! ]
if "!1DirSize%id%!" == "!2DirSize%id%!" ECHO Synk
REM DEL index.fld
if "!1DirSize%id%!" NEQ "!2DirSize%id%!" del /f /q !m%id%!index.fld && del /f /q !m%id%!indexlog.fld && del /f /q !m%id%!search.fld && set R=1 && ECHO RE-index Count && ECHO RE-index Count %Date% %Time% - Delete !m%id%! >> "%CD%LOG%Computername%.log"
set 1DirSize!id!=!2DirSize%id%!
ECHO.
ECHO.
set /a id+=1
goto Find
:Reindex
ECHO. >> "%CD%LOG%Computername%.log"
ECHO --- RE-INDEX - Start - %Date% %Time% --- >> "%CD%LOG%Computername%.log"
ECHO. >> ----------------------------------- >> "%CD%LOG%Computername%.log"
call PublicFolders.py
timeout 60
goto start
exit
Una copia dello script viene eseguita su ogni server di posta (può essere eseguita come servizio, non sono necessari diritti di amministratore)
Lo script legge il file Setup%Computername%.List
Dove %Computername% è il nome del server attuale (La directory può contenere elenchi di tutti i server.)
Il file %Computername%.List contiene i percorsi completi delle directory sincronizzate, ogni percorso è registrato su una nuova riga e non deve contenere righe vuote.
Dopo il primo avvio, lo script esegue la procedura di indicizzazione, indipendentemente dal fatto che sia necessaria o meno, e crea anche un indice del numero di file in ciascuna delle directory sincronizzate.
Lo scopo dello script è contare tutti i file nella directory specificata.
Al termine del conteggio di ciascuna directory, se almeno in una directory il valore attuale dei file non coincide con il precedente, lo script rimuove i file dalla directory radice della cartella email sincronizzata: index.fld, indexlog.fld, search.fld e avvia il processo di indicizzazione delle cartelle email comuni.
Nella directory LOG viene registrata l'informazione sull'esecuzione delle attività.
Processo di indicizzazione
Il processo di indicizzazione consiste nell'esecuzione della funzione API Kerio
Session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)
Un esempio di esecuzione è fornito in – python
PublicFolders.py
import json
import urllib.request
import http.cookiejar
""" La gestione dei cookie è necessaria per la gestione delle sessioni """
jar = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(jar))
urllib.request.install_opener(opener)
""" Nome host o indirizzo IP della tua istanza Kerio Control con protocollo, porta e credenziali """
server = "http://127.0.0.1:4040"
username = "user"
password = "password"
def callMethod(method, params, token = None):
"""
Chiama a distanza il metodo specificato con i parametri forniti.
:param: method string con il nome completo del metodo
:param: params dict con i parametri del metodo chiamato a distanza
:param: token Il token CSRF è sempre richiesto tranne per il metodo di login. Usa il metodo "Session.login" per ottenere questo token.
"""
data = {"method": method ,"id":1, "jsonrpc":"2.0", "params": params}
req = urllib.request.Request(url = server + '/admin/api/jsonrpc/')
req.add_header('Content-Type', 'application/json')
if (token is not None):
req.add_header('X-Token', token)
httpResponse = urllib.request.urlopen(req, json.dumps(data).encode())
if (httpResponse.status == 200):
body = httpResponse.read().decode()
return json.loads(body)
session = callMethod("Session.login", {"userName":username, "password":password, "application":{"vendor":"Kerio", "name":"Control Api-Local", "version":"Python"}})
token = session["result"]["token"]
print (session)
session = callMethod("Domains.checkPublicFoldersIntegrity",{"domainId": "test2.local"}, token)
print (session)
callMethod("Session.logout",{}, token)
puoi lasciarlo così com'è, ma se hai bisogno di HTTPS — python deve fidarsi del certificato Kerio.
È necessario indicare anche un account con i diritti per eseguire questa funzione (Amministratore – cartelle di posta condivise) del server di posta.
Spero che il mio articolo sia utile agli amministratori di Kerio Connect.
Fonte: habr.com
