Sincronización total de cartafoles compartidos, contactos e calendarios entre servidores Kerio Connect distribuídos

Boas tardes, Habr!

Tarefa

A miña organización usa un servidor de correo na plataforma Kerio Connect; os servidores de correo están instalados en diferentes cidades para servir aos seus usuarios. Inicialmente non había unha estrutura distribuída, xa que os dominios difiren no terceiro nivel, indicando a cidade do xacemento. Todo funcionou e todos estaban contentos. Un bo día, a dirección púxose unha tarefa, un calendario común de actividades entre todos os sitios!

prehistoria

Inicialmente, a idea era elevar o dominio de correo distribuído de Kerio e facelo todo por si mesmo. Nada máis dicir que feito, creouse un dominio distribuído, pero non foi así, o servidor estaba preparado para sincronizar calendarios, cartafoles, contactos - entre dominios situados no mesmo servidor, pero non ía en absoluto sincronizar datos entre varios servidores.

Eu, por suposto, non esperaba tal captura e durante moito tempo non podía crer que faltase a funcionalidade que necesitaba. Máis tarde atopei constancia documental deste feito. Quedei moi perplexo e decepcionado por isto.

A tarefa converteuse sen problemas nun problema.

Cales eran as opcións?

• Crea dous clientes en servidores diferentes que intercambian os datos necesarios con algún software de terceiros. Era necesario atopar este software de terceiros que implementara esta funcionalidade; non me gusta tal rastrillo, pero parecía que esta era a única solución rápida.
• Escribe o teu propio script para a sincronización de datos entre servidores. O caso é que Kerio almacena cada obxecto como un ficheiro separado, polo que foi necesario desenvolver un script para traballar con ficheiros, pero á vista do número suficiente de fontes, a tarefa parecía algo complicada, sobre todo porque era necesario realizar múltiples comproba a corrección dos datos, no caso de que alguén crea unha tarefa no mesmo período de tempo, etc., etc.

Mirando cara adiante, direi que aínda que Kerio almacena un obxecto como un ficheiro separado, non é tan estúpido como para preguntar como está o sistema de ficheiros cada vez que accede ao obxecto.

Despois de pasar moito tempo pensando, elaborando un montón de papeis cos plans de "apoderarse do territorio inimigo", ás 6 en punto tomei dúas decisións correctas:

• A primeira decisión é facer o teu e non buscar nada de fóra.
• A segunda solución é ir durmir.

Xa pola mañá espertei cun único e verdadeiro pensamento, que se reduciu a unhas poucas letras - DFS

decisión

A solución en si parecía así

• trae todos os servidores que participarán na sincronización ao sistema operativo Windows. (Parte foi en Linux. Era necesaria a migración dos datos de correo a outro sistema operativo)
• Determine a estrutura dos directorios que participarán na sincronización: deben ser idénticos.
• Defina todos os servidores de correo nun mesmo dominio cun único espazo DFS.
• Crea o dominio Kerio distribuído mencionado anteriormente, xa que no meu caso é necesaria a sincronización de datos, non só entre servidores senón tamén entre dominios; o segundo pode ser xestionado polo servidor Kerio de forma independente. (a diferenza do primeiro)
• Establecer directorios sincronizados no espazo DFS.
• Crea algún tipo de muleta (despois de todo, non podes vivir sen unha muleta)

Implantación

Exemplo en dous servidores de correo (quizais máis)

1. Kerio Dominio distribuído

O Mestre non participa na sincronización, pero este non é un requisito previo.

Non vou describir como crear un dominio distribuído Kerio, non hai nada complicado, podes estudar o oficial manul

En definitiva, deberías ver a seguinte imaxe na consola de administración:

A continuación interesábanme os cartafoles compartidos; no servidor mestre podes especificar as seguintes opcións:

Específico para cada dominio - o servidor non sincronizará cartafoles públicos entre dominios

Común a todos os dominios - Todos os servidores abandonarán os cartafoles públicos existentes en cada dominio e crearán novos cartafoles únicos para todos os dominios en cada servidor de correo.

Atención! Aínda que esta opción cambia a política de configuración en todos os servidores, sincronízase por separado de cada servidor (é dicir, sen un único espazo común)

O administrador aínda terá a posibilidade de distribuír o acceso entre usuarios.
no meu caso, son todos meus e necesito unha sincronización total (No teu caso, a solución pode ser diferente) en cada servidor necesitas crear conxuntos idénticos de dominios que hai que sincronizar.

2. Directorios de datos de Kerio

Agora cómpre crear directorios compartidos idénticos que deben sincronizarse en cada un dos servidores. Cartafoles, calendarios, contactos.

Consello: cree directorios en inglés, se os crea en latín, o directorio terá un nome nunha codificación incomprensible, polo menos é un inconveniente.

Agora cómpre atopar os camiños físicos dos cartafoles de correo en cada servidor.

Común a todos os dominios ~DataMailmail#publicСинхронизируемый каталог#msgs
Específico para cada dominio ~DataMailmail**Domain**#publicСинхронизируемый каталог#msgs

Teña en conta que non sincronizaremos todo o directorio, senón só o contedor cos datos #msgs — aquí almacénanse os propios obxectos, todos os demais datos deben estar separados para cada servidor.

3.DFS

Non vou describir en detalle como configurar DFS, hai información suficiente sobre este problema.

DFS é un servizo de rol en Windows Server que ofrece a posibilidade de combinar cartafoles compartidos situados en diferentes servidores
Ligazón ao documento MS DFS

Antes de configurar DFS, debe deter todos os servidores de correo que participarán na sincronización de datos.

Despois de completar a configuración, debería recibir a seguinte imaxe para cada un dos cartafoles sincronizados

Por suposto, non necesitamos publicar cartafoles replicados.

Despois de que se produza a replicación (e non hai nada especial que replicar alí: os cartafoles están baleiros), pódense iniciar os servidores de correo.

A continuación, pode encher un dos servidores de correo con datos e comprobar que os datos se replican correctamente.

4. Muleta

Descrición da reflexión

Como podes ver despois de que os datos comezan a sincronizarse (DFS), se creaches algo no primeiro servidor, dalgún xeito non aparece nada no segundo servidor, ou aparece, pero non sempre.

Non te desesperes; por suposto, aparecerá alí tarde ou cedo, pero mellor máis cedo que tarde. Porque é demasiado tarde en 6-12 horas.

O caso é que en canto creas algo no primeiro servidor, no segundo e nos seguintes servidores o ficheiro aparecerá, por suposto, inmediatamente grazas ao sistema DFS, pero no caso de que este directorio de correo xa fose lido por alguén antes. e se solicita de novo, o servidor non volverá ler o cartafol #msgs senón que cuspir datos do seu propio índice, que poden deixar de corresponder á nosa realidade.

Kerio ten un mecanismo para reler o índice, pero pode funcionar nunhas seis horas, e durante estas 6 horas pode perderse algo a relevancia da tarefa no calendario.
Para probar a sincronización agora mesmo, pode eliminar o ficheiro no directorio sincronizado correspondente index.fld, despois de acceder de novo ao cartafol no servidor de correo e se falta este ficheiro, Kerio volverá ler o directorio e os datos. aparecerá. Parece que esta é a solución, elimina o ficheiro cando os datos cambian, pero isto non funciona cada vez, senón só a primeira vez, entón Kerio por algún motivo perde todo o interese en index.fld
Tamén comeza a cuspir mensaxes que son incomprensibles para o usuario -sobre algún tipo de índice e que xa está facendo algo alí.

Hai outra opción, crear algo: no momento de crear un novo obxecto, o servidor dáse conta de súpeto de que o nome do ficheiro que quería asignar xa está tomado, pero fai bola de neve e esta é unha opción sen saída.

Como pode ser iso?

Se volvemos a prestar atención á imaxe que xa nos resulta familiar.

Pero noutro avión, podes ver un botón moi interesante que necesitamos agora: Reindexar cartafoles

E de feito. Se facemos clic neste botón nun servidor de correo que non sabe que algo xa cambiou nos #msgs sincronizados, obteremos un resultado estable e rápido. Todo o que está oculto quedará claro.

No rexistro podes ver canto tempo leva este proceso; no meu caso, con varios miles (15 mil) de rexistros, leva uns 3-4 minutos.

Todo o que temos que facer é descubrir como premer realmente este botón cando o necesitemos.

Acontece Kerio teñen os seus API

Descrición
Documentación

A función que realiza a nosa tarefa é a seguinte:
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

De todo o anterior, cómpre escribir un script que permita supervisar o estado dos cartafoles de interese e, se algo cambiou, realizar a función que necesitamos.

Quero dicir que escribín varias versións diferentes de guións que realizan diferentes comprobacións e decidín aquela que saca todas as conclusións en función do número de ficheiros.

Implementación de scripts

Exemplo e descrición do script CMD

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

Unha copia do script execútase en cada servidor de correo (pódese usar como servizo, non son necesarios dereitos de administrador)

O script le o ficheiro Setup%Computername%.List

Onde %Computername% é o nome do servidor actual (O directorio pode conter listas de todos os servidores á vez.)

O ficheiro %Computername%.List – contén as rutas completas dos directorios sincronizados, cada ruta está escrita nunha nova liña e non debe conter liñas baleiras.

Despois do primeiro lanzamento, o script realiza o procedemento de indexación, independentemente de se é necesario ou non, e o script tamén crea un índice do número de ficheiros en cada directorio sincronizado.

O propósito do script é contar todos os ficheiros do directorio especificado.

Ao final do reconto de cada directorio, se en polo menos un directorio o valor actual dos ficheiros non coincide co anterior, o script elimina os ficheiros do directorio raíz do directorio de correo sincronizado: index.fld, indexlog.fld, search.fld e inicia o proceso de indexación dos cartafoles de correo compartido.

A información sobre a execución da tarefa bótase no directorio LOG.

Proceso de indexación
O proceso de indexación redúcese a executar unha función da API de Kerio
Sesión = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

Un exemplo de implementación dáse en – 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 podes deixalo como está, pero se precisas HTTPS, python debe confiar no certificado de Kerio.

Tamén no ficheiro debes especificar unha conta con dereitos para realizar esta función (Adm - cartafoles de correo público) do servidor de correo.

Espero que o meu artigo sexa útil para os administradores de Kerio Connect.

Fonte: www.habr.com