Plena sinkronigo de komunaj dosierujoj, kontaktoj, kalendaroj inter distribuitaj Kerio Connect-serviloj

Bonan posttagmezon, Habr!

Objektivo

Mia organizo uzas poŝtservilon en la platformo Kerio Connect; poŝtserviloj estas instalitaj en malsamaj urboj por servi siajn uzantojn. Komence ne estis distribuita strukturo, ĉar la domajnoj malsamas je la tria nivelo, indikante la urbon de la retejo. Ĉio funkciis kaj ĉiuj estis feliĉaj. Unu belan tagon, la administrado starigis taskon, komunan kalendaron de agadoj inter ĉiuj retejoj!

antaŭhistorio

Komence, la ideo estis altigi la Kerio Distributed Mail Domain kaj ĝi farus ĉion mem. Apenaŭ dirite ol farite, distribuata domajno estis kreita, sed tio ne estis la kazo, la servilo estis preta sinkronigi kalendarojn, dosierujojn, kontaktojn - inter domajnoj situantaj sur la sama servilo, sed tute ne iris sinkronigi datumojn inter pluraj. serviloj.

Mi, kompreneble, ne atendis tian kapton kaj dum longa tempo ne povis kredi, ke mankas la funkcio, kiun mi bezonis. Poste mi trovis dokumentajn pruvojn pri tiu ĉi fakto. Mi estis tre konfuzita kaj seniluziigita de ĉi tio.

La tasko glate fariĝis problemo.

Kio estis la ebloj?

• Kreu du klientojn sur malsamaj serviloj, kiuj interŝanĝas la necesajn datumojn kun iu triaparta programaro. Necesis trovi ĉi tiun trian programon, kiu efektivigus ĉi tiun funkcion - mi ne ŝatas tian rastilon, sed ŝajnis, ke ĉi tio estas la sola rapida solvo.
• Skribu vian propran skripton por datumsinkronigado inter serviloj. Fakte, Kerio konservas ĉiun objekton kiel apartan dosieron, do necesis ellabori skripton por labori kun dosieroj, sed pro la sufiĉa nombro da fontoj, la tasko ŝajnis iom komplika, precipe ĉar necesis plenumi plurajn. kontrolas la ĝustecon de la datumoj, se iu kreas taskon en la sama tempodaŭro, ktp., ktp.

Rigardante antaŭen, mi diros, ke kvankam Kerio konservas objekton kiel apartan dosieron, ĝi ne estas tiom stulta por demandi kiel fartas la dosiersistemo ĉiufoje kiam vi aliras la objekton.

Pasiginte multan tempon pensante, ellaborante amason da paperoj kun planoj "kapti malamikan teritorion", je la 6-a mi faris du ĝustajn decidojn:

• La unua decido estas fari vian propran aferon kaj ne serĉi ion ajn el ekstere.
• La dua solvo estas iri dormi.

Jam matene mi vekiĝis kun unu sola kaj vera penso, kiu reduktiĝis al kelkaj literoj - DFS

decido

La solvo mem aspektis tiel

• alportu ĉiujn servilojn kiuj partoprenos en sinkronigado al OS Windows. (Parto de ĝi estis sur Linukso. Migrado de poŝtaj datumoj al alia OS estis postulata)
• Determinu la strukturon de la dosierujoj, kiuj partoprenos en sinkronigado - ili devas esti identaj.
• Difinu ĉiujn poŝtservilojn sub unu domajno kun ununura DFS-spaco.
• Kreu la supre menciitan distribuitan Kerio-domajnon, ĉar en mia kazo necesas sinkronigo de datumoj, ne nur inter serviloj sed ankaŭ inter domajnoj; la dua povas esti pritraktata de la Kerio-servilo sendepende. (male al la unua)
• Agordu sinkronigitajn dosierujojn al DFS-spaco.
• Elpensu ian lambastonon (finfine, vi ne povas vivi sen lambastono)

Реализация

Ekzemplo sur du poŝtserviloj (eble pli)

1. Kerio Distribuita domajno

La Majstro ne partoprenas en sinkronigado, sed ĉi tio ne estas antaŭkondiĉo.

Mi ne priskribos kiel levi distribuitan domajnon de Kerio, estas nenio komplika pri tio, vi povas studi la oficialan manul

Finfine, vi devus vidi la sekvan bildon en la administra konzolo:

Poste mi interesiĝis pri komunaj dosierujoj; en la Majstra servilo vi povas specifi la jenajn opciojn:

Specifa por ĉiu domajno - la servilo ne sinkronigos publikajn dosierujojn inter domajnoj

Komuna al ĉiuj domajnoj - ĉiuj serviloj forlasos ekzistantajn publikajn dosierujojn en ĉiu domajno kaj kreos novajn ununurajn dosierujojn por ĉiuj domajnoj sur ĉiu poŝtservilo.

Singardemo Kvankam ĉi tiu opcio ŝanĝas la agordan politikon en ĉiuj serviloj, ĝi sinkronigas aparte de ĉiu servilo (tio estas, sen ununura komuna spaco)

La administranto ankoraŭ havos la kapablon distribui aliron inter uzantoj.
en mia kazo, ili ĉiuj estas miaj kaj mi bezonas plenan sinkronigon (En via kazo, la solvo povas esti malsama) en ĉiu servilo vi devas krei identajn arojn de domajnoj, kiuj devas esti sinkronigitaj.

2. Kerio-datumdosierujoj

Nun vi devas krei identajn komunajn dosierujojn, kiuj devas esti sinkronigitaj en ĉiu el la serviloj. Dosierujoj, Kalendaroj, Kontaktoj.

Konsilo - kreu dosierujojn en la angla, se vi kreas ilin en la latina, la dosierujo havos nomon en iu nekomprenebla kodado, tio estas almenaŭ maloportuna.

Nun vi devas trovi la fizikajn vojojn de la poŝtaj dosierujoj sur ĉiu servilo.

Komuna al ĉiuj domajnoj ~DataMailmail#publicСинхронизируемый каталог#msgs
Specifa por ĉiu domajno ~DataMailmail**Domain**#publicСинхронизируемый каталог#msgs

Bonvolu noti, ke ni ne sinkronigos la tutan dosierujon, sed nur la ujon kun la datumoj #msgs — la objektoj mem estas konservitaj ĉi tie, ĉiuj aliaj datumoj devas esti apartaj por ĉiu servilo.

3.DFS

Mi ne detale priskribos kiel agordi DFS, estas sufiĉe da informoj pri ĉi tiu afero.

DFS estas rolservo en Windows Server kiu disponigas la kapablon kombini komunajn dosierujojn situantajn sur malsamaj serviloj
Ligo al MS DFS-dokumento

Antaŭ ol agordi DFS, vi devas haltigi ĉiujn poŝtservilojn, kiuj partoprenos en datumsinkronigado.

Fininte la aranĝon, vi devus ricevi la sekvan bildon por ĉiu el la sinkronigitaj dosierujoj

Nature, ni ne bezonas publikigi reproduktitajn dosierujojn.

Post kiam reproduktado okazas (kaj estas nenio speciala por reprodukti tie - la dosierujoj estas malplenaj), la poŝtserviloj povas esti komencitaj.

Poste, vi povas plenigi unu el la poŝtserviloj per datumoj kaj kontroli, ke la datumoj estas ĝuste kopiitaj.

4. Lambastono

Priskribo de reflektado

Kiel vi povas vidi post kiam la datumoj komencas sinkronigi (DFS), se vi aŭ kreis ion sur la unua servilo, iel nenio aperas sur la dua servilo, aŭ ĝi aperas sed iel ne ĉiam.

Ne malesperu; kompreneble, ĝi aperos tie frue aŭ malfrue, sed pli bone pli frue ol poste. Ĉar estas tro malfrue en 6 - 12 horoj.

La afero estas, ke tuj kiam vi kreis ion en la unua servilo, en la dua kaj postaj serviloj la dosiero kompreneble tuj aperos danke al la DFS-sistemo, sed en la okazo, ke tiu ĉi poŝta dosierujo jam estis legita de iu antaŭe. kaj denove estas petita, la servilo ne relegos la #msgs-dosierujon sed kraĉos datumojn el sia propra indekso, kiu eble ne plu respondas al nia realo.

Kerio havas mekanismon por relegi la indekson, sed ĝi povas funkcii en ĉirkaŭ ses horoj, kaj dum ĉi tiuj 6 horoj la graveco de la tasko en la kalendaro povas esti iom perdita.
Por testi la sinkronigon ĝuste nun, vi povas forigi la dosieron en la responda sinkronigita dosierujo index.fld, post realiro de la dosierujo sur la poŝtservilo kaj se ĉi tiu dosiero mankas, Kerio relegos la dosierujon kaj la datumojn. aperos. Ŝajnus, ke ĉi tio estas la solvo, forigu la dosieron kiam la datumoj ŝanĝiĝas, sed ĉi tio ne funkcias ĉiufoje, sed nur la unuan fojon, tiam Kerio ial perdas ĉian intereson pri index.fld
Ĝi ankaŭ komencas kraĉi mesaĝojn nekompreneblajn por la uzanto – pri ia indekso kaj ke ĝi jam faras ion tie.

Estas alia opcio, krei ion - en la momento de kreado de nova objekto, la servilo subite rimarkas, ke la dosiernomo, kiun ĝi volis asigni, jam estas prenita, sed neĝbuloj kaj ĉi tio estas senelirejo.

Kiel esti?

Se ni denove atentu la bildon, kiu jam estas konata al ni.

Sed en alia aviadilo, vi povas vidi tre interesan butonon, kiun ni bezonas nun - Reindeksigi dosierujojn

Kaj efektive. Se ni alklakas ĉi tiun butonon en poŝtservilo, kiu ne scias, ke io jam ŝanĝiĝis en la sinkronigitaj #msgs, ni ricevos stabilan, rapidan rezulton. Ĉio kaŝita fariĝos klara.

En la protokolo vi povas vidi kiom da tempo ĉi tiu procezo daŭras; en mia kazo kun pluraj miloj (15 mil) registroj ĝi daŭras ĉirkaŭ 3-4 minutojn.

Ĉio, kion ni devas fari, estas eltrovi kiel efektive premi ĉi tiun butonon kiam ni bezonas ĝin.

Ĝi rezultas Kerio havas sian propran API

Priskribo
Dokumentado

La funkcio kiu plenumas nian taskon aspektas jene:
session = callMethod("Domains.checkPublicFoldersIntegrity",{}, token)

El ĉio ĉi-supra, ni devas skribi skripton, kiu monitorus la staton de la interesaj dosierujoj kaj, se io ŝanĝiĝis, plenumi la funkcion, kiun ni bezonas.

Mi volas diri, ke mi skribis plurajn malsamajn versiojn de skriptoj, kiuj plenumas malsamajn kontrolojn, kaj decidiĝis je tiu, kiu eltiras ĉiujn konkludojn surbaze de la nombro da dosieroj.

Skripto efektivigo

Ekzemplo kaj priskribo de CMD-skripto

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

Kopio de la skripto funkcias en ĉiu poŝtservilo (povas esti uzata kiel servo, Adm-rajtoj ne estas bezonataj)

La skripto legas la dosieron Setup%Computername%.List

Kie %Computername% estas la nomo de la nuna servilo (La dosierujo povas enhavi listojn de ĉiuj serviloj samtempe.)

La dosiero %Computername%.List – enhavas la plenajn vojojn de la sinkronigitaj dosierujoj, ĉiu vojo estas skribita sur nova linio, kaj ne devus enhavi malplenajn liniojn.

Post la unua lanĉo, la skripto faras la indeksan proceduron, sendepende de ĉu ĝi estas necesa aŭ ne, kaj la skripto ankaŭ kreas indekson de la nombro da dosieroj en ĉiu sinkronigita dosierujo.

La celo de la skripto estas nombri ĉiujn dosierojn en la specifita dosierujo.

Ĉe la fino de kalkulado de ĉiu dosierujo, se en almenaŭ unu dosierujo la nuna valoro de dosieroj ne kongruas kun la antaŭa, la skripto forigas dosierojn el la radika dosierujo de la sinkronigita poŝta dosierujo: index.fld, indexlog.fld, search.fld kaj komencas la indeksan procezon de komunaj poŝtaj dosierujoj.

Informoj pri taska plenumo estas forĵetitaj en la dosierujon LOG.

Procezo de indeksado
La indeksadprocezo venas al ekzekuto de Kerio API-funkcio
Sesio = callMethod ("Domains.checkPublicFoldersIntegrity",{}, signo)

Ekzempla efektivigo estas donita 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 vi povas lasi ĝin tia, sed se vi postulas HTTPS, python devas fidi la Kerio-atestilon.

Ankaŭ en la dosiero vi devas specifi konton kun rajtoj por plenumi ĉi tiun funkcion (Adm - publikaj poŝtaj dosierujoj) de la poŝtservilo.

Mi esperas, ke mia artikolo estos utila al administrantoj de Kerio Connect.

fonto: www.habr.com