Jaettujen kansioiden, yhteystietojen ja kalenterien täydellinen synkronointi hajautettujen Kerio Connect -palvelimien välillä

Hyvää iltapäivää, Habr!

Tehtävä

Organisaationi käyttää sähköpostipalvelinta Kerio Connect -alustalla, postipalvelimet on asennettu eri kaupunkeihin palvelemaan käyttäjiään. Aluksi ei ollut hajautettua rakennetta, koska verkkotunnukset eroavat kolmannella tasolla, mikä osoittaa sivuston kaupungin. Kaikki toimi ja kaikki olivat tyytyväisiä. Eräänä kauniina päivänä johto asetti tehtävän, yhteisen toimintakalenterin kaikkien kohteiden kesken!

esihistoria

Aluksi ajatuksena oli nostaa Kerio Distributed Mail Domain ja se tekisi kaiken itse. Heti kun on sanottu kuin tehty, hajautettu toimialue luotiin, mutta niin ei tapahtunut, palvelin oli valmis synkronoimaan kalentereita, kansioita, yhteystietoja - samalla palvelimella sijaitsevien verkkotunnusten välillä, mutta ei aikonut lainkaan synkronoida tietoja useiden välillä. palvelimia.

En tietenkään odottanut tällaista saalista enkä pitkään aikaan voinut uskoa, että tarvitsemani toiminnallisuus puuttui. Myöhemmin löysin asiakirjoja tästä tosiasiasta. Olin tästä hyvin hämmentynyt ja pettynyt.

Tehtävä muuttui sujuvasti ongelmaksi.

Mitä vaihtoehtoja oli?

• Luo kaksi asiakasta eri palvelimille, jotka vaihtavat tarvittavia tietoja joidenkin kolmannen osapuolen ohjelmistojen kanssa. Oli tarpeen löytää tämä kolmannen osapuolen ohjelmisto, joka toteuttaisi tämän toiminnon - en pidä sellaisesta rakeesta, mutta näytti siltä, ​​​​että tämä oli ainoa nopea ratkaisu.
• Kirjoita oma skripti tietojen synkronointia varten palvelimien välillä. Tosiasia on, että Kerio tallentaa jokaisen objektin erillisenä tiedostona, joten tiedostojen kanssa työskentelyä varten oli tarpeen kehittää skripti, mutta riittävän lähteiden määrän vuoksi tehtävä vaikutti melko monimutkaiselta, varsinkin kun oli tarpeen suorittaa useita tarkistaa tietojen oikeellisuuden, jos joku luo tehtävän samalla ajanjaksolla jne., jne.

Tulevaisuudessa sanon, että vaikka Kerio tallentaa objektin erillisenä tiedostona, se ei ole niin tyhmää, että kysyisi, kuinka tiedostojärjestelmä toimii joka kerta, kun käytät objektia.

Vietettyään paljon aikaa pohtiessani ja laatiessani nippu paperia, jossa oli suunnitelmia "vallankaa vihollisen alue", tein kello 6 kaksi oikeaa päätöstä:

• Ensimmäinen päätös on tehdä omia juttujasi eikä etsiä mitään ulkopuolelta.
• Toinen ratkaisu on mennä nukkumaan.

Jo aamulla heräsin yhteen ainoaan ja todelliseen ajatukseen, joka oli pelkistetty muutamaan kirjaimeen - DFS

päätös

Itse ratkaisu näytti tältä

• tuo kaikki synkronointiin osallistuvat palvelimet OS Windowsiin. (Osa siitä oli Linuxissa. Postitietojen siirtäminen toiseen käyttöjärjestelmään vaadittiin)
• Määritä synkronointiin osallistuvien hakemistojen rakenne - niiden on oltava identtisiä.
• Määritä kaikki yhden toimialueen sähköpostipalvelimet yhdellä DFS-tilalla.
• Luo edellä mainittu hajautettu Kerio-domain, koska minun tapauksessani vaaditaan tietojen synkronointia, ei vain palvelimien välillä, vaan myös verkkotunnusten välillä, toisen voi hoitaa Kerio-palvelin itsenäisesti. (toisin kuin ensimmäinen)
• Aseta synkronoidut hakemistot DFS-tilaan.
• Keksi jonkinlainen kainalosauva (et loppujen lopuksi voi elää ilman kainalosauvaa)

Реализация

Esimerkki kahdesta sähköpostipalvelimesta (ehkä useammasta)

1. Kerio Hajautettu verkkotunnus

Mestari ei osallistu synkronointiin, mutta tämä ei ole edellytys.

En kuvaile Kerio-hajautetun verkkotunnuksen kasvattamista, siinä ei ole mitään monimutkaista, voit tutkia virallista manul

Lopulta sinun pitäisi nähdä seuraava kuva hallintakonsolissa:

Seuraavaksi kiinnostuin jaetuista kansioista; pääpalvelimella voit määrittää seuraavat asetukset:

Jokaista verkkotunnusta varten - palvelin ei synkronoi julkisia kansioita verkkotunnusten välillä

Yhteinen kaikille verkkotunnuksille - Kaikki palvelimet hylkäävät olemassa olevat julkiset kansiot kussakin toimialueella ja luovat uusia yksittäisiä kansioita jokaiselle sähköpostipalvelimelle kaikille toimialueille.

Varoitus! Vaikka tämä vaihtoehto muuttaa kaikkien palvelimien määrityskäytäntöä, se synkronoituu erikseen jokaisesta palvelimesta (eli ilman yhtä yhteistä tilaa).

Järjestelmänvalvoja voi edelleen jakaa käyttöoikeudet käyttäjien kesken.
minun tapauksessani ne ovat kaikki minun ja tarvitsen täyden synkronoinnin (sinun tapauksessa ratkaisu voi olla erilainen) jokaiselle palvelimelle, sinun on luotava identtiset joukot toimialueita, jotka on synkronoitava.

2. Kerio-tietohakemistot

Nyt sinun on luotava identtiset jaetut hakemistot, jotka on synkronoitava jokaiselle palvelimelle. Kansiot, kalenterit, yhteystiedot.

Neuvonta - luo hakemistoja englanniksi, jos luot ne latinaksi, hakemistolla on nimi jossain käsittämättömässä koodauksessa, tämä on ainakin hankalaa.

Nyt sinun on löydettävä kunkin palvelimen postikansioiden fyysiset polut.

Yhteinen kaikille verkkotunnuksille ~DataMailmail#publicСинхронизируемый каталог#msgs
Jokaista verkkotunnusta varten ~DataMailmail**Domain**#publicСинхронизируемый каталог#msgs

Huomaa, että emme synkronoi koko hakemistoa, vaan vain säilön tietojen kanssa #viestit — itse objektit tallennetaan tähän, kaikkien muiden tietojen on oltava erillisiä jokaiselle palvelimelle.

3.DFS

En kuvaile yksityiskohtaisesti DFS:n määrittämistä, tästä ongelmasta on tarpeeksi tietoa.

DFS on Windows Serverin roolipalvelu, joka tarjoaa mahdollisuuden yhdistää eri palvelimilla sijaitsevia jaettuja kansioita
Linkki MS DFS -asiakirjaan

Ennen kuin määrität DFS:n, sinun on pysäytettävä kaikki sähköpostipalvelimet, jotka osallistuvat tietojen synkronointiin.

Kun asennus on valmis, sinun pitäisi saada seuraava kuva jokaisesta synkronoidusta kansiosta

Meidän ei tietenkään tarvitse julkaista kopioituja kansioita.

Replikoinnin jälkeen (eikä siellä ole mitään erityistä replikoitavaa - kansiot ovat tyhjiä), sähköpostipalvelimet voidaan käynnistää.

Seuraavaksi voit täyttää yhden sähköpostipalvelimista tiedoilla ja tarkistaa, että tiedot kopioidaan oikein.

4. Kaivosauva

Heijastuksen kuvaus

Kuten näet tietojen synkronoinnin (DFS) alkamisen jälkeen, jos loit jotain ensimmäiselle palvelimelle, jotenkin toisella palvelimella ei näy mitään, tai se näkyy, mutta jotenkin ei aina.

Älä vaivu epätoivoon; se tietysti näkyy siellä ennemmin tai myöhemmin, mutta parempi ennemmin tai myöhemmin. Koska on liian myöhäistä 6–12 tunnin kuluttua.

Asia on siinä, että heti kun olet luonut jotain ensimmäiselle palvelimelle, toisella ja sitä seuraavilla palvelimilla tiedosto tulee tietysti heti näkyviin DFS-järjestelmän ansiosta, mutta siinä tapauksessa, että joku on jo lukenut tämän postihakemiston ja sitä pyydetään uudelleen, palvelin ei lue #msgs-kansiota uudelleen, vaan sylkee tietoja omasta hakemistostaan, mikä ei ehkä enää vastaa todellisuuttamme.

Keriolla on mekanismi hakemiston uudelleenlukemiseen, mutta se voi toimia noin kuudessa tunnissa ja näiden 6 tunnin aikana tehtävän relevanssi kalenterissa saattaa kadota jonkin verran.
Testaaksesi synkronoinnin heti, voit poistaa tiedoston vastaavasta synkronoidusta hakemistosta index.fld, kun olet avannut uudelleen postipalvelimen kansioon ja jos tämä tiedosto puuttuu, Kerio lukee hakemiston ja tiedot uudelleen. ilmestyy. Näyttää siltä, ​​​​että tämä on ratkaisu, poista tiedosto tietojen muuttuessa, mutta tämä ei toimi joka kerta, vaan vain ensimmäisellä kerralla, jolloin Kerio menettää jostain syystä kaiken kiinnostuksensa index.fld
Se alkaa myös sylkeä ulos viestejä, jotka ovat käyttäjälle käsittämättömiä - jostain indeksistä ja siitä, että se jo tekee siellä jotain.

On toinenkin vaihtoehto, luoda jotain - uutta objektia luotaessa palvelin yhtäkkiä tajuaa, että tiedostonimi, jonka se halusi määrittää, on jo varattu, mutta se lumipalloja ja tämä on umpikujavaihtoehto.

Miten voi olla?

Jos kiinnitämme huomiota vielä kerran meille jo tuttuihin kuviin.

Mutta toisessa koneessa voit nähdä erittäin mielenkiintoisen painikkeen, jota tarvitsemme nyt - Indeksoi kansiot uudelleen

Ja todellakin. Jos napsautamme tätä painiketta sähköpostipalvelimella, joka ei tiedä, että jotain on jo muuttunut synkronoidussa #viesteissä, saamme vakaan, nopean tuloksen. Kaikki piilotettu tulee selväksi.

Lokista näet kuinka kauan tämä prosessi kestää; minun tapauksessani useiden tuhansien (15 tuhatta) tietueella se kestää noin 3-4 minuuttia.

Meidän tarvitsee vain selvittää, kuinka painaa tätä painiketta, kun tarvitsemme sitä.

Se käy ilmi Kerio on omat API

Kuvaus
Asiakirjat

Tehtävämme suorittava toiminto näyttää tältä:
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

Kaikesta yllä olevasta meidän on kirjoitettava komentosarja, joka tarkkailee kiinnostavien kansioiden tilaa ja jos jokin on muuttunut, suorittaa tarvitsemamme toiminnon.

Haluan sanoa, että kirjoitin useita eri versioita komentosarjoista, jotka suorittavat erilaisia ​​tarkistuksia, ja päädyin siihen, joka tekee kaikki johtopäätökset tiedostojen lukumäärän perusteella.

Skriptin toteutus

CMD-skriptiesimerkki ja kuvaus

Indeksoi uudelleen. 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

Skriptin kopio toimii jokaisella sähköpostipalvelimella (voidaan käyttää palveluna, Adm-oikeuksia ei vaadita)

Skripti lukee tiedoston Setup%Computername%.List

Missä %Computername% on nykyisen palvelimen nimi (hakemisto voi sisältää luettelot kaikista palvelimista kerralla.)

Tiedosto %Computername%.List – sisältää synkronoitujen hakemistojen täydelliset polut, jokainen polku kirjoitetaan uudelle riville, eikä se saa sisältää tyhjiä rivejä.

Ensimmäisen käynnistyksen jälkeen komentosarja suorittaa indeksoinnin riippumatta siitä, onko se tarpeen vai ei, ja komentosarja luo myös indeksin tiedostojen määrästä kussakin synkronoidussa hakemistossa.

Skriptin tarkoitus on laskea kaikki määritetyn hakemiston tiedostot.

Jos jokaisen hakemiston laskennan lopussa vähintään yhdessä hakemistossa tiedostojen nykyinen arvo ei vastaa edellistä, komentosarja poistaa tiedostot synkronoidun sähköpostihakemiston juurihakemistosta: index.fld, indexlog.fld, search.fld ja aloittaa jaettujen sähköpostikansioiden indeksointiprosessin.

Tehtävän suorittamista koskevat tiedot tallennetaan LOG-hakemistoon.

Indeksointiprosessi
Indeksointiprosessi rajoittuu Kerio API -toiminnon suorittamiseen
Istunto = callMethod("Domains.checkPublicFoldersIntegrity",{}, tunnus)

Esimerkkitoteutus on annettu pythonissa
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 voit jättää sen ennalleen, mutta jos tarvitset HTTPS:ää, pythonin on luotettava Kerio-varmenteeseen.

Myös tiedostossa on määritettävä tili, jolla on oikeudet suorittaa tämä toiminto (Adm - julkiset postikansiot) sähköpostipalvelimelle.

Toivon, että artikkelistani on hyötyä Kerio Connect -järjestelmänvalvojille.

Lähde: will.com