Vállalati XMPP szerver telepítés

Web, mail, IRC, IM, hálózatok

Sziasztok!

Adott egy közepes méretű cég, ahol szeretnék egy stabil és működőképes XMPP alapú céges Chat-et bevezetni.
Kb. 20 kliensről lenne szó. Jelenleg működik, és használnak is egy OpenFire szerver (fél, egy éve), és az alap funkciók működőképesek is, viszont eléggé instabilnak érzem. Ez abban nyilvánul meg, hogy nem tudom frissíteni normálisan, mert teljesen összeomlik, vagy ha megpróbálok feltenni egy kiegészítőt a szerverre, akkor az előzőhöz hasonló viselkedést vált ki. És akárhogy patkoltam, mindig csak a teljes mentés visszaállítása volt a mentsváram.

Ennek okán, szeretnék egy olyan (lehetőleg free) linuxos XMPP szervert telepíteni, ami megfelelő stabilitással működik, esetleg fejlődőképes. De első sorban a stabilitásra mennék rá. Lehetőleg CentOS-re szeretném telepíteni, de ha csak Debian, Ubuntu kompatibilis sem jelent problémát.

A felhasználók migrálásával nem kell foglalkozni, ezt könnyen megtudom oldani.

Előre is köszönöm a javaslatokat!

  • 5178 megtekintés

( dap | 2017. 12. 17., v – 15:01 )

A Prosody nálunk nagyon jól működik és tök egyszerű konfigurálni.

( kisg v | 2017. 12. 17., v – 19:23 )

Mi Mattermost-ot használunk, jobban bevált mint bármi előtte. Ez egy open source Slack alternatíva.

Kopano Webmeetings-et most rakta bele a Kopano csapat.
Még nem próbáltuk ki, de demot már láttunk működni, teljesen jó.

Innen tudod letölteni: https://download.kopano.io/community/mattermost-plugin-kopanowebmeeting…
Docs: https://github.com/Kopano-dev/mattermost-plugin-kopanowebmeetings

Igyekszem mindig a latest verziot futtatni kb. 1-1,5 het csuszassal, ami jelenleg nekunk a 4.9.2
Ebben ha jol ertelmezem (nalunk erre nincs igeny, igy se research, se test nem tortent) ket fele mod van ra:
- Official plugin a Zoom-hoz (https://zoom.us/) latszolag stable a plugin, se beta, se experimental flag nincs rajta
- WebRTC (ez meg beta-ra van flagelve) a leiras alapjan elegge kerek es szep implementacionak tunik.
Docker-bol kvazi off-the-shelf modon megy a backend deployment, 2 perces konfig heggesztes es szerintem kesz.
Link: https://docs.mattermost.com/deployment/webrtc.html

A hetvegen kivancsisagbol lehet, h ranezek.

-------------------------
Roses are red
Violets are blue
Unexpected '}' on line 32

( wladek1 | 2017. 12. 17., v – 21:13 )

ejabberd jo lehet esetleg. 2012 ota ~0 hibaval hasznaljuk.

( Fisher v | 2017. 12. 18., h – 08:21 )

Hasonló dolgon töprengek már egy ideje, de annyi csavar van a dologban, hogy nálunk úgy kéne megcsinálni, hogy az irodai forgalom az irodai hálózatban maradjon, a külsősök forgalma a külső hálózatban, és csak az menjen át a dróton, ami muszáj.

Ahogy olvasgattam, az ejabberd elvileg képes ilyenre, de írták, hogy alacsony késleltetésű hálózatot szeretne. Namost nekünk az úgy van, hogy az iroda egy 30 megabites vonallal csatlakozik a világra (szerencsére ez szimmetrikus vonal), amin nyugis időben 3 msec alatt van a ping a külső szerverre, de ez természetesen elég hamar megváltozhat, sőt meg is szakadhat a vonal. Plusz nem biztos hogy két gépből érdemes clustert csinálni (nem ismerem az ejabberd megoldásait).

Esetleg a fentiekkel kiegészítve, van valakinek jó tanácsa?

Ezt az XMPP alapból biztosítja, mivel ez egy federated protokoll. Nem kell hozzá semmiféle cluster, egyszerűen telepítessz két független jabber szervert és egyiken lesz jid:encike@kulsosok.acme.hu, a másikon jid:pistike@belsosok.acme.hu aztán tudnak egymással kommunikálni (vagy akárkivel akinek van jabber címe a világban) és a szerverek között csak az megy át ami a másik domainre van címezve.

Oké, de az hogy ki a külsős és ki a belsős az akár naponta többször is változhat. A kollégák hol bent dolgoznak az irodában, hol meg másik irodában (vagy akár országban). Ez csak azért lenne érdekes, mert tuti rá fognak szokni hogy relatíve nagy fájlokat dobáljanak egymásnak, és ha lehet, akkor nem ezzel terhelném a vonalat, no meg gyorsabb is, ha nem kell körbemennie mondjuk 300 megának.

( gattila | 2017. 12. 18., h – 11:24 )

Mi Rocket Chat-et használtunk a régi cégemnél. Webes, asztali és mobilkliens is van. Nagy fájlokat is meg lehet osztani. A felülete is elég modern.

( junior013 | 2018. 05. 04., p – 10:05 )

Kicsit feléleszteném a témát - én most állok neki a dolognak.

Legtöbb helyen azt látom, manapság már jobban terjednek az "egyszerűen csak használható" külső szolgáltatások, de nálunk cél lenne:
- saját, zárt rendszer
- AD integráció (authentikációra és csoport-/partnerlistákra egyaránt)
- Kerberos SSO
- Magyar nyelvű, lehetőleg portable kliens

Amire eddig jutottam:
1., ejabberd server:
+ robosztus, stabil, kis erőforrásigényű
- csak "klasszikus" LDAP-ként kezeli az AD-t, az auto_roster_ldap modul-t nem sikerült rávennem, hogy a több OU-ba szervezett usereket és group-okat normálisan kezelje

2., openfire server:
+ webfelületről nagyon kényelmesen konfigurálható, az AD-t jól kezeli, usereket, groupokat szépen felolvassa
- java miatt kissé erőforrás-igényes

A., Spark kliens (szintén az Ignite által, gyakorlatilag az Openfire-höz szánt kliens)
+ jól átlátható, kényelmesen használható, egyszerű, DNS alapú szerver-felderítést és Kerberos SSO-t támogat
- java-s, nem tud magyarul, nem portable, így minden egyes user-nek telepíteni és konfigurálni kell, a Kerberos csak a jelszót váltja ki, a user-t mindenkinek be kell állítgatni

B., Pidgin
+ kisebb, kevesebb erőforrást zabál, mint a Spark, tud magyarul
- csak full manuálisan konfigolható, service discovery-t, SSO-t nem támogat

Tényleg nincs ehhez az - elvileg - elterjedt protokollhoz egy bot egyszerű kliens, ami Windows-os klienseken elindítható úgy, hogy az aktuális user-el automatikusan bejelentkezzen, ne kelljen minden user-nek egyenként felkonfigurálni? :(

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Ránéztem, egyelőre odáig jutottam, hogy igen, sajnos AD integrációt csak az enterspájz tud, az meg őszintén szólva ahhoz drága, hogy ez nem production tool, csak egy kényelmi kiegészítő.

De később szerintem csinálok egy demo rendszert belőle.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

A kódba még nem néztem bele, csak a file-okból: Jól sejtem, hogy PHP script-el matatja hátulról a Mattermost adatbázisát az LDAP alapján?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nem. Az open source Mattermost kizárólag Gitlab-hoz tartalmaz Single Sign-On plugint. Ezért a kolléga írt egy proxyt PHP-ban (nyilván ezt a nyelvet ismeri), ami úgy tesz a Mattermost felé, mintha egy Gitlab lenne (OAuth provider), és közben a megadott LDAP-ból authol.

Ez az egész korlátozás eleve röhejes a Mattermost részéről, a korrekt megoldás nyilván az lenne, ha írna valaki egy generikus oauth plugint Mattermosthoz a Gitlab alapján.

- Csak chat, vagy privát videókonferencia / screen sharing is (Jitsi Video Gateway) is?

- 50 userrel milyen erőforrásigénye van?

- Használjátok a publikus weboldalba integrálható chat funkcióját? Mi a tapasztalatotok vele? Megbízhatóan működik?

- Integráció más rendszerekkel (GitHub, Gerrit, Redmine érdekel főleg)?

- Milyen authentikációs megoldással használjátok?

Ide én is válaszolok, mi is használjuk, bár az átlagos aktív felhasználószám csak olyan 25 körüli:
- Jitsi-n többnyire elég frankón meg a group video call, kényelmetlenség most, hogy a nemrég frissült androidos klienseken (váltottak electronról natívra) nem jelenik meg a video hívás a csatornában. Desktopon ok. Screen sharing vicces, az csak browserből megy, a desktop kliensből nem (electron rulz). WebRTC call még bugzik, de azért szokott menni - de ez béta dolog is még, alapban nincs is engedélyezve.
- Nálunk egy core i5-ös gépen megy, dockerben, és más is terheli azt a gépet, de nem szokott vele teljesítmény gond lenni.
- Weboldal integrációt nem használjuk, erről nem tudok nyilatkozni
- Nekünk Gitlabbal és Redmine-al van összekötve, az patent.
- LDAP auth van nálunk
Összességében a cél az volt, hogy a bugos skype (group call) és a slack (channels) helyett egyben egy self-hosted megoldást találjunk, nekünk amire kellett, eddig bevált. Nézegettünk többmindent is, de vagy nem tudott olyan funkciót ami mindenképp kellett, vagy bugos volt, vagy nem volt mobil kliens pl.

Egyelőre csak chat. Screen sharinget nézegetjük, eddig az éppen működik kategóriának tűnik.

Mi szétdobáltuk 5 szerverre (2 app + 3 db), de nincs látható terhelés. Igaázból, ha kap annyi memóriát, hogy amongo beférjen, akkor simán elszalad kb bármilyen vason.

Nem használjuk az integrált web funkciót.

JIRA integrációt csináltunk, azt könnyen össze tudtuk lőni.

LDAP auth-ot használunk.

Ami negatívum volt slackhez képest, hogy a mobil kliensek elég gyenge minőségüek.

Szerettem volna egy demo keretében kipróbálni. Így frissen feldobtam egy Centos 7-et és az install doksit követve telepítettem a Rocket Chatet is. Viszont indulás után látszólag minden oké, mégsem érhető el a webes felülete. Keresgéltem kicsit, de nem találtam megoldást? Nálatok volt példa ilyenre?

Közben kiderült, hogy iptables-be nem árt egy szabály felvenni. Bár a tutorialból ez kimaradt mint 'jó ha tudod' szekció.

Ami kicsit érdekes volt számomra, hogy a telepítési folyamat 3-4 alkalmából mindegyiknél más volt a warning/és vagy error. Szerencsére mások is jártak már így. Gyorsan megvolt a megoldás. Amúgy elsőre szimpatikus.

Kipróbáltam Dockerben is. Az majdnem ment elsőre. Ott meg elfelejtettem mongo konténert mellé pakolni. :D

Most egy kicsit még gondolkodom rajta, hogy mi legyen. Ez a CentOS eleve egy VM és elsősorban önálló gépben gondolkodom. Viszont a meglévő Xpenology-s Docker-be is működne a dolog, viszont ott meg kicsit nyűgös hálózati rész... De akár lehetne a CentOS-ből egy Docker központ...más szolgáltatások is képben vannak még...Egyelőre nem látom az előnyöket és a hátrányokat.

Köszi, pikk-pakk feldobtam snap-el Ubuntu-ra, LDAP auth is megy simán, jó kis rendszernek tűnik.
DE a mi r=1 user-einknek sajnos ez űrtudomány. Nem hogy csökkentené a feladataimat, de supportálhatom még a chat szoftvert is, mert valamit tuti elbarmolnak a millió beállítása között :( Szóval, ilyen szempontból sajnos bukta. Szakmai környezetbe valóban jobb lehet, mint egy sima XMPP.
Ja, de a magyarítása... :D - GoogleTranslate Kínairól :D

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Sziasztok!

Van egy teljesen új termékünk, ami egy XMPP-alapú, teljesen end-to-end titkosított, házon belül hosztolt WhatsApp/Viber alternatíva:
https://yellowcube.eu/hu/babelnet/

Nem ingyenes, viszont elég feature gazdag, jól támogatott, auditált, ellenőrizhető és sok fontos ügyfél használja már különböző szolgálatoktól, fegyveres testületektől és külügy/honvédelmi minisztériumtól is. Ha érdekel, keressetek bátran, beszéljünk róla, próbáljátok ki, szívesen küldünk bárkinek egy accountot a saját demó szerverhez játszani. Ami pedig az árat illeti, reális, tárgyalható és minden bizonnyal olcsóbb lesz bármilyen potenciális ügyfélnek mint sajátot fejleszteni vagy összerakni.

üdv,
Bódis Ákos és a Yellow Cube csapata