Fullständig synkronisering av delade mappar, kontakter, kalendrar mellan distribuerade Kerio Connect-servrar

God eftermiddag, Habr!

Uppgift

Min organisation använder en e-postserver på Kerio Connect-plattformen, e-postservrar installeras i olika städer för att betjäna sina användare. Ursprungligen fanns det ingen distribuerad struktur, eftersom domänerna skiljer sig åt på den tredje nivån, vilket indikerar platsen för platsen. Allt fungerade och alla var nöjda. En vacker dag satte ledningen en uppgift, en gemensam aktivitetskalender mellan alla sajter!

förhistoria

Från början var tanken att höja Kerio Distributed Mail Domain och den skulle göra allt själv. Inte förr sagt än gjort, en distribuerad domän skapades, men så var inte fallet, servern var redo att synkronisera kalendrar, mappar, kontakter - mellan domäner som ligger på samma server, men skulle inte alls synkronisera data mellan flera servrar.

Jag förväntade mig naturligtvis inte en sådan fångst och kunde länge inte tro att den funktionalitet jag behövde saknades. Senare hittade jag dokumentära bevis på detta faktum. Jag blev väldigt förbryllad och besviken över detta.

Uppgiften förvandlades smidigt till ett problem.

Vilka var alternativen?

• Skapa två klienter på olika servrar som utbyter nödvändiga data med programvara från tredje part. Det var nödvändigt att hitta denna tredjepartsprogramvara som skulle implementera denna funktionalitet - jag gillar inte sådan rake, men det verkade som att detta var den enda snabba lösningen.
• Skriv ditt eget skript för datasynkronisering mellan servrar. Faktum är att Kerio lagrar varje objekt som en separat fil, så det var nödvändigt att utveckla ett skript för att arbeta med filer, men med tanke på det tillräckliga antalet källor verkade uppgiften något komplicerad, särskilt eftersom det var nödvändigt att utföra flera kontrollerar uppgifternas riktighet, ifall någon skapar en uppgift under samma tidsperiod, etc., etc.

Framöver kommer jag att säga att även om Kerio lagrar ett objekt som en separat fil, så är det inte så dumt att fråga hur filsystemet mår varje gång du kommer åt objektet.

Efter att ha ägnat mycket tid åt att tänka, rita upp ett gäng papper med planer "att ta fiendens territorium", vid 6-tiden tog jag två rätta beslut:

• Det första beslutet är att göra din egen grej och inte leta efter något utifrån.
• Den andra lösningen är att gå och lägga sig.

Redan på morgonen vaknade jag med en enda och sann tanke, som reducerades till några bokstäver - DFS

beslutet

Själva lösningen såg ut så här

• föra alla servrar som kommer att delta i synkroniseringen till OS Windows. (En del av det var på Linux. Migrering av e-postdata till ett annat operativsystem krävdes)
• Bestäm strukturen för katalogerna som ska delta i synkroniseringen - de måste vara identiska.
• Definiera alla e-postservrar under en domän med ett enda DFS-utrymme.
• Skapa den ovan nämnda distribuerade Kerio-domänen, eftersom i mitt fall datasynkronisering krävs, inte bara mellan servrar utan även mellan domäner, den andra kan hanteras av Kerio-servern oberoende. (till skillnad från den första)
• Ställ in synkroniserade kataloger till DFS-utrymme.
• Kom på någon form av krycka (du kan trots allt inte leva utan en krycka)

genomförande

Exempel på två e-postservrar (kanske fler)

1. Kerio Distribuerad domän

Mästaren deltar inte i synkroniseringen, men detta är inte en förutsättning.

Jag kommer inte att beskriva hur man skapar en Kerio distribuerad domän, det är inget komplicerat med det, du kan studera den officiella manul

I slutändan bör du se följande bild i administrationskonsolen:

Därefter var jag intresserad av delade mappar; på masterservern kan du ange följande alternativ:

Specifik för varje domän - Servern kommer inte att synkronisera publika mappar mellan domäner

Gemensamt för alla domäner - alla servrar kommer att överge befintliga publika mappar i varje domän och skapa nya enskilda mappar för alla domäner på varje e-postserver.

Varning! Även om det här alternativet ändrar konfigurationspolicyn på alla servrar, synkroniseras det separat från varje server (det vill säga utan ett gemensamt utrymme)

Administratören kommer fortfarande att ha möjlighet att distribuera åtkomst mellan användare.
i mitt fall är de alla mina och jag behöver full synkronisering (I ditt fall kan lösningen vara annorlunda) på varje server behöver du skapa identiska uppsättningar av domäner som behöver synkroniseras.

2. Kerio datakataloger

Nu måste du skapa identiska delade kataloger som måste synkroniseras på var och en av servrarna. Mappar, kalendrar, kontakter.

Råd – skapa kataloger på engelska, om du skapar dem på latin kommer katalogen att ha ett namn i någon obegriplig kodning, detta är åtminstone obekvämt.

Nu måste du hitta de fysiska sökvägarna till e-postmapparna på varje server.

Gemensamt för alla domäner ~DataMailmail#publicСинхронизируемый каталог#msgs
Specifik för varje domän ~DataMailmail**Domain**#publicСинхронизируемый каталог#msgs

Observera att vi inte kommer att synkronisera hela katalogen, utan endast behållaren med data #medd — själva objekten lagras här, all annan data måste vara separat för varje server.

3.DFS

Jag kommer inte att beskriva i detalj hur man konfigurerar DFS, det finns tillräckligt med information om det här problemet.

DFS är en rolltjänst i Windows Server som ger möjlighet att kombinera delade mappar som finns på olika servrar
Länk till MS DFS-dokument

Innan du ställer in DFS måste du stoppa alla e-postservrar som kommer att delta i datasynkronisering.

När installationen är klar bör du få följande bild för var och en av de synkroniserade mapparna

Naturligtvis behöver vi inte publicera replikerade mappar.

Efter replikering inträffar (och det finns inget speciellt att replikera där - mapparna är tomma), kan e-postservrarna startas.

Därefter kan du fylla en av e-postservrarna med data och kontrollera att data replikeras korrekt.

4. Krycka

Beskrivning av reflektion

Som du kan se efter att data börjar synkroniseras (DFS), om du antingen skapade något på den första servern, visas ingenting på den andra servern, eller så visas det men på något sätt inte alltid.

Misströsta inte; självklart kommer det att dyka upp där förr eller senare, men bättre förr än senare. För det är för sent på 6-12 timmar.

Saken är den att så fort du har skapat något på den första servern, på den andra och efterföljande servern kommer filen givetvis omedelbart att dyka upp tack vare DFS-systemet, men i händelse av att denna mailkatalog redan har lästs av någon tidigare och efterfrågas igen, kommer servern inte att läsa #msgs-mappen igen utan spottar ut data från sitt eget index, vilket kanske inte längre motsvarar vår verklighet.

Kerio har en mekanism för att läsa om indexet, men den kan fungera på cirka sex timmar, och under dessa 6 timmar kan relevansen av uppgiften i kalendern försvinna något.
För att testa synkroniseringen just nu, kan du radera filen i motsvarande synkroniserade katalog index.fld, efter att du återåtkomst till mappen på e-postservern och om denna fil saknas, kommer Kerio att läsa katalogen och data igen. Kommer komma. Det verkar som att detta är lösningen, radera filen när data ändras, men detta fungerar inte varje gång, utan bara första gången, då tappar Kerio av någon anledning allt intresse för index.fld
Den börjar också spotta ur sig meddelanden som är obegripliga för användaren – om någon form av index och att den redan gör något där.

Det finns ett annat alternativ, att skapa något - i ögonblicket för att skapa ett nytt objekt inser servern plötsligt att filnamnet som den ville tilldela redan är upptaget, men det snöar och detta är ett återvändsgränd alternativ.

Hur kan det vara?

Om vi ​​återigen uppmärksammar bilden som redan är bekant för oss.

Men på ett annat plan kan du se en mycket intressant knapp som vi behöver nu - Indexera om mappar

Och verkligen. Om vi ​​klickar på den här knappen på en e-postserver som inte vet att något redan har ändrats i den synkroniserade #msgs, får vi ett stabilt, snabbt resultat. Allt gömt kommer att bli klart.

I loggen kan du se hur lång tid denna process tar, i mitt fall med flera tusen (15 tusen) poster tar det cirka 3-4 minuter.

Allt vi behöver göra är att ta reda på hur man faktiskt trycker på den här knappen när vi behöver den.

Det visar sig Kerio ha din egen API

beskrivning
Документация

Funktionen som utför vår uppgift ser ut så här:
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

Från allt ovanstående måste vi skriva ett skript som övervakar tillståndet för mapparna av intresse och, om något har förändrats, utföra den funktion vi behöver.

Jag vill säga att jag skrev flera olika versioner av skript som utför olika kontroller, och slog mig på den som drar alla slutsatser utifrån antalet filer.

Skriptimplementering

CMD-skriptexempel och beskrivning

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

En kopia av skriptet körs på varje e-postserver (kan användas som en tjänst, Adm-rättigheter krävs inte)

Skriptet läser filen Setup%Computername%.List

Där %Computername% är namnet på den aktuella servern (katalogen kan innehålla listor över alla servrar samtidigt.)

Filen %Computername%.List – innehåller de fullständiga sökvägarna till de synkroniserade katalogerna, varje sökväg skrivs på en ny rad och bör inte innehålla tomma rader.

Efter den första lanseringen utför skriptet indexeringsproceduren, oavsett om det är nödvändigt eller inte, och skriptet skapar även ett index över antalet filer i varje synkroniserad katalog.

Syftet med skriptet är att räkna alla filer i den angivna katalogen.

I slutet av räkningen av varje katalog, om det aktuella värdet på filerna i minst en katalog inte matchar den föregående, tar skriptet bort filer från rotkatalogen i den synkroniserade e-postkatalogen: index.fld, indexlog.fld, search.fld och startar indexeringsprocessen för delade e-postmappar.

Information om aktivitetskörning dumpas i LOG-katalogen.

Indexeringsprocess
Indexeringsprocessen handlar om att köra en Kerio API-funktion
Session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

Ett exempel på implementering ges i – 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 du kan lämna det som det är, men om du behöver HTTPS måste python lita på Kerio-certifikatet.

Även i filen måste du ange ett konto med rättigheter för att utföra denna funktion (Adm - offentliga e-postmappar) för e-postservern.

Jag hoppas att min artikel kommer att vara användbar för Kerio Connect-administratörer.

Källa: will.com