Sincronització completa de carpetes compartides, contactes i calendaris entre servidors Kerio Connect distribuïts

Bona tarda, Habr!

Tasca

La meva organització utilitza un servidor de correu a la plataforma Kerio Connect; els servidors de correu s'instal·len a diferents ciutats per atendre els seus usuaris. Inicialment no hi havia una estructura distribuïda, ja que els dominis es diferencien en el tercer nivell, indicant la ciutat del jaciment. Tot va funcionar i tothom estava content. Un bon dia, la direcció va posar una tasca, un calendari d'activitats comú entre tots els llocs!

prehistòria

Inicialment, la idea era augmentar el domini de correu distribuït de Kerio i ho faria tot sol. Amb prou feines es va crear un domini distribuït, però no va ser així, el servidor estava preparat per sincronitzar calendaris, carpetes, contactes, entre dominis situats al mateix servidor, però no anava a sincronitzar dades entre diversos. servidors.

Per descomptat, no m'esperava tal captura i durant molt de temps no em podia creure que faltés la funcionalitat que necessitava. Més tard vaig trobar proves documentals d'aquest fet. Vaig quedar molt desconcertat i decebut per això.

La tasca es va convertir sense problemes en un problema.

Quines eren les opcions?

• Creeu dos clients en servidors diferents que intercanviïn les dades necessàries amb algun programari de tercers. Va ser necessari trobar aquest programari de tercers que implementés aquesta funcionalitat; no m'agrada aquest rastreig, però semblava que aquesta era l'única solució ràpida.
• Escriu el teu propi script per a la sincronització de dades entre servidors. El fet és que Kerio emmagatzema cada objecte com a fitxer independent, per la qual cosa va ser necessari desenvolupar un script per treballar amb fitxers, però tenint en compte el nombre suficient de fonts, la tasca semblava una mica complicada, sobretot perquè era necessari realitzar múltiples comprova la correcció de les dades, en cas que algú creï una tasca en el mateix període de temps, etc., etc.

De cara al futur, diré que, tot i que Kerio emmagatzema un objecte com a fitxer separat, no és tan estúpid com per preguntar-se com està el sistema de fitxers cada vegada que accediu a l'objecte.

Després d'haver passat molt de temps pensant, elaborant un munt de papers amb plans "per apoderar-se del territori enemic", a les 6 en punt vaig prendre dues decisions encertades:

• La primera decisió és fer el teu i no buscar res de fora.
• La segona solució és anar a dormir.

Ja al matí em vaig despertar amb un únic i veritable pensament, que es va reduir a unes poques lletres - DFS

decisió

La solució en si semblava així

• portar tots els servidors que participaran en la sincronització amb el sistema operatiu Windows. (Una part era a Linux. Es requeria la migració de dades de correu a un altre sistema operatiu)
• Determineu l'estructura dels directoris que participaran en la sincronització: han de ser idèntics.
• Definiu tots els servidors de correu sota un domini amb un únic espai DFS.
• Creeu el domini Kerio distribuït esmentat anteriorment, ja que en el meu cas és necessària la sincronització de dades, no només entre servidors sinó també entre dominis; el segon pot ser gestionat pel servidor Kerio de manera independent. (a diferència del primer)
• Estableix els directoris sincronitzats a l'espai DFS.
• Aconsegueix algun tipus de crossa (després de tot, no pots viure sense crossa)

Implementació

Exemple en dos servidors de correu (potser més)

1. Kerio Domini distribuït

El màster no participa en la sincronització, però això no és un requisit previ.

No descriuré com crear un domini distribuït de Kerio, no hi ha res complicat, podeu estudiar l'oficial manul

Finalment, hauríeu de veure la següent imatge a la consola d'administració:

A continuació, em van interessar les carpetes compartides; al servidor mestre podeu especificar les opcions següents:

Específic per a cada domini - el servidor no sincronitzarà carpetes públiques entre dominis

Comú a tots els dominis - tots els servidors abandonaran les carpetes públiques existents a cada domini i crearan carpetes úniques noves per a tots els dominis de cada servidor de correu.

Atenció! Tot i que aquesta opció canvia la política de configuració a tots els servidors, es sincronitza per separat de cada servidor (és a dir, sense un únic espai comú)

L'administrador encara tindrà la possibilitat de distribuir l'accés entre usuaris.
en el meu cas, són tots meus i necessito una sincronització completa (En el vostre cas, la solució pot ser diferent) a cada servidor cal crear conjunts idèntics de dominis que s'han de sincronitzar.

2. Directoris de dades de Kerio

Ara cal crear directoris compartits idèntics que s'han de sincronitzar a cadascun dels servidors. Carpetes, calendaris, contactes.

Consell: creeu directoris en anglès, si els creeu en llatí, el directori tindrà un nom en una codificació incomprensible, això és almenys un inconvenient.

Ara heu de trobar els camins físics de les carpetes de correu de cada servidor.

Comú a tots els dominis ~DataMailmail#publicСинхронизируемый каталог#msgs
Específic per a cada domini ~DataMailmail**Domain**#publicСинхронизируемый каталог#msgs

Tingueu en compte que no sincronitzarem tot el directori, sinó només el contenidor amb les dades #msgs — els objectes en si s'emmagatzemen aquí, totes les altres dades han d'estar separades per a cada servidor.

3.DFS

No descriuré en detall com configurar DFS, hi ha prou informació sobre aquest problema.

DFS és un servei de rol a Windows Server que ofereix la possibilitat de combinar carpetes compartides situades en diferents servidors
Enllaç al document MS DFS

Abans de configurar DFS, heu d'aturar tots els servidors de correu que participaran en la sincronització de dades.

Un cop finalitzada la configuració, hauríeu de rebre la imatge següent per a cadascuna de les carpetes sincronitzades

Naturalment, no cal que publiquem carpetes replicades.

Després que es produeixi la replicació (i no hi ha res especial per replicar-hi: les carpetes estan buides), es poden iniciar els servidors de correu.

A continuació, podeu omplir un dels servidors de correu amb dades i comprovar que les dades es repliquin correctament.

4. Muleta

Descripció de la reflexió

Com podeu veure després que les dades comencin a sincronitzar-se (DFS), si heu creat alguna cosa al primer servidor, d'alguna manera no apareix res al segon servidor, o apareix però d'alguna manera no sempre.

No et desesperis; és clar, hi apareixerà tard o d'hora, però millor més tard que d'hora. Perquè és massa tard en 6-12 hores.

El cas és que tan bon punt hagis creat alguna cosa al primer servidor, al segon i als següents servidors el fitxer apareixerà, per descomptat, de seguida gràcies al sistema DFS, però en el cas que aquest directori de correu ja hagi estat llegit per algú abans. i es demana de nou, el servidor no tornarà a llegir la carpeta #msgs sinó que escopirà dades del seu propi índex, que potser ja no corresponen a la nostra realitat.

Kerio té un mecanisme per tornar a llegir l'índex, però pot funcionar en unes sis hores, i durant aquestes 6 hores es pot perdre una mica la rellevància de la tasca en el calendari.
Per tal de provar la sincronització ara mateix, podeu esborrar el fitxer al directori sincronitzat corresponent index.fld, després d'accedir de nou a la carpeta del servidor de correu i si aquest fitxer falta, Kerio tornarà a llegir el directori i les dades. Apareixerà. Sembla que aquesta és la solució, suprimiu el fitxer quan les dades canvien, però això no funciona cada vegada, sinó només la primera vegada, llavors Kerio per algun motiu perd tot l'interès en index.fld
També comença a escopir missatges que són incomprensibles per a l'usuari: sobre algun tipus d'índex i que ja hi està fent alguna cosa.

Hi ha una altra opció, crear alguna cosa: en el moment de crear un objecte nou, el servidor s'adona de sobte que el nom del fitxer que volia assignar ja s'ha pres, però bola de neu i aquesta és una opció sense sortida.

Com ser?

Si tornem a prestar atenció a la imatge que ja ens és familiar.

Però en un altre avió, podeu veure un botó molt interessant que necessitem ara: Reindexar les carpetes

I de fet. Si fem clic en aquest botó en un servidor de correu que no sap que alguna cosa ja ha canviat als #msgs sincronitzats, obtindrem un resultat estable i ràpid. Tot el que s'amaga quedarà clar.

Al registre podeu veure quant de temps triga aquest procés; en el meu cas, amb diversos milers (15 mil) de registres triga uns 3-4 minuts.

Tot el que hem de fer és esbrinar com prémer aquest botó quan ho necessitem.

Resulta que Kerio tenen els seus API

Descripció
Registres

La funció que realitza la nostra tasca és la següent:
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

A partir de tot l'anterior, hem d'escriure un script que controli l'estat de les carpetes d'interès i, si alguna cosa ha canviat, realitzi la funció que necessitem.

Vull dir que vaig escriure diverses versions diferents de scripts que realitzen diferents comprovacions i em vaig decidir per la que extreu totes les conclusions en funció del nombre de fitxers.

Implementació del script

Exemple i descripció de l'script CMD

Torna a indexar.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 còpia de l'script s'executa a cada servidor de correu (es pot utilitzar com a servei, no calen drets d'administració)

L'script llegeix el fitxer Setup%Computername%.List

On %Computername% és el nom del servidor actual (El directori pot contenir llistes de tots els servidors alhora.)

El fitxer %Computername%.List: conté els camins complets dels directoris sincronitzats, cada camí s'escriu en una línia nova i no hauria de contenir línies buides.

Després del primer llançament, l'script realitza el procediment d'indexació, independentment de si és necessari o no, i l'script també crea un índex del nombre de fitxers de cada directori sincronitzat.

El propòsit de l'script és comptar tots els fitxers del directori especificat.

Al final del recompte de cada directori, si almenys en un directori el valor actual dels fitxers no coincideix amb l'anterior, l'script elimina els fitxers del directori arrel del directori de correu sincronitzat: index.fld, indexlog.fld, search.fld i inicia el procés d'indexació de les carpetes de correu compartides.

La informació sobre l'execució de la tasca s'aboca al directori LOG.

Procés d'indexació
El procés d'indexació es limita a executar una funció de l'API de Kerio
Sessió = callMethod("Domains.checkPublicFoldersIntegrity",{}, testimoni)

Un exemple d'implementació es dóna a – python
PublicFolders.py

import json
import urllib.request
import http.cookiejar
""" Cookie storage is necessary for session handling """
jar = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(jar))
urllib.request.install_opener(opener)
""" Hostname or ip address of your Kerio Control instance with protocol, port and credentials """

server = "http://127.0.0.1:4040"
username = "user"
password = "password"

def callMethod(method, params, token = None):
    """
    Remotely calls given method with given params.
    :param: method string with fully qualified method name
    :param: params dict with parameters of remotely called method
    :param: token CSRF token is always required except login method. Use method "Session.login" to obtain this 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)

http://127.0.0.1:4040 podeu deixar-lo tal qual, però si necessiteu HTTPS, Python ha de confiar en el certificat Kerio.

També a l'arxiu has d'especificar un compte amb drets per realitzar aquesta funció (Adm - carpetes de correu públic) del servidor de correu.

Espero que el meu article sigui útil als administradors de Kerio Connect.

Font: www.habr.com