XMPP (Jabber) szerver - melyiket?

Debian GNU/Linux

Szeretnék a céges szerverre (Debian stable), XMPP szervert tenni.
Elsősorban belső hálózaton kommunikációra, de a jövőben esetleg az internet felől is, pl. mobil eszközökkel elérni.

Nem telepítettem saját jabber / XMPP szervert az utóbbi 10 évben, és korábban is csak játszadoztam vele, nem volt komolyan használva.

Úgy látom, van egy csomó különféle implementáció, javaslatokat kérnék, hogy melyiket válasszam.

Előny, ha a Debian része, de azzal is kiegyezek, ha valahonnan deb csomag letölthető, a hely sources.list-be konfigurálható és ha bug- vagy security fix van, akkor az aptitude lehúzza a frissítést. Nem szeretnék kézzel letöltött kézzel fordított szervert, aminek aztán fél szemmel figyelnem kell, hogy van-e új verzió. De ha valami miatt megéri, akkor hajlandó vagyok erre, de akkor nyomós indokot szeretnék látni.

Szempontok fontossági sorrendben:
- megbízhatóság (stabilitás leginkább)
- biztonság (ne tudják ezen keresztül felnyomni a szervert a netről, titkosítsa az üzeneteket a hálózaton)
- üzenetváltás sebessége
- rendszerterhelés

Minden segítő szándékú kommentért előre is köszönet.

  • 2890 megtekintés

Pedig alapvetően mind2 elég jó nyelv. Amúgy gondolom azért írják pl. Erlangban, mert az egy funkcionális nyelv, amit pont arra a feladatra terveztek, amit a Jabber/XMPP ellát.

És azon kívül, hogy funkcionális semmi elvarázsolt nincs benne.

Mondjuk a Lua már más tészta, azt én sem biztos, hogy erőltetném.

FathoM

A lehallgatás problémája egy dolog, a biztonság kérdése egy másik. Minden internet felől elérhető szolgáltatás egy támadási felület. TLS arra jó, hogy ne hallgassanak le. De ha van valamilyen kihasználható biztonsági hibája az ejabbered-nek akkor azon keresztül felnyomhatják a szervered. Ha csak VPN-en érhető el az ejabbered, akkor kívülről nem támadható. Persze az OpenVPN is támadható, de jobban is figyelnek a biztonságára és általában hamar kijönnek a javítások hozzá.

( gee v | 2015. 02. 24., k – 16:37 )

Az vajon miért van, hogy ami szerver a Debianban elérhető, az mind valami egzotikus nyelven készült?

Pl. ez az ejabberd magával hozza az erlang nyelvet, amit semmi más nem használt eddig a szerveren.
Vagy a Prosody az meg Lua nyelven van, és hozná magával a senki más által eddig nem használt lua csomagokat.

A neten láttam egy openfire nevűt, az meg java, bizonyára ahhoz meg egy teljes java runtime környezet kéne.

Van ennek valami oka, vagy ez csak így sikerült?
Ha én állnék neki valami szerveralkalmazás készítésének, bizonyára valami olyan eszközt használnék, ami vagy binárissá fordul, mint mondjuk C++ vagy C, vagy ha fontos, hogy mindenhol menjen, akkor megpróbálnék valami olyasmire építkezni, ami nagy eséllyel fent van sok szerveren, pl. perl.
Pl. nem választanék ruby-t (ami egyébként nálam egy darab program miatt most épp fent van) vagy pythont (amitől egyébként ebben a Debian GNU/Linux telepítésben elég sok (6+) csomag függ).

Ezt en sem ertem. Jelenleg a Prosody-t hasznalom OpenWRT-n egy TP-Link routeren amiben sajnos csak 32MB ram van.

Mar legyilkoltam rola szinte mindent, a Prosody-n kivul semmi szolgaltatas nem megy (na jo, ssh), de igy is csak kb. 10MB marad a Prosody-nak. Elindul, de idonkent ez nem eleg es jon az OOM killer - mi mast enne meg mint a Prosody (mondjuk inkabb azt mint mast, mert a tobbi meg fontosabb). Most epp egy while [ 1 ] -ben fut, csunya, idonkent ujraindul, de megy.

Eleg sokat keresgeltem (itt a HUP-on is nyitottam ezzel kapcsolatban egy topikot (http://hup.hu/node/119237)), de nem sok sikerrel.

/sza2

"A neten láttam egy openfire nevűt, az meg java, bizonyára ahhoz meg egy teljes java runtime környezet kéne."

Openfire-t használtam pár éven át, teljesen jól és stabilan működött, szinte mindenféle környezetbe van beállítási lehetősége... és ne tegyünk úgy, mintha az az 50-100M túl sok volna.

"vagy ha fontos, hogy mindenhol menjen, akkor megpróbálnék valami olyasmire építkezni, ami nagy eséllyel fent van sok szerveren, pl. perl"

Perl sok mindenre jó, de alapvetően nem erre találták ki és sok dolgot csak kínkeserversen lehet megoldani, amire például Java esetén van out-of-the-box támogatás vagy egy kész könnyen használható és mindennel kompatibilis megoldás... nem egy súlycsoport.

Nem az 50-100M a bajom, hanem ha nem muszáj, nem telepítek semmi plusz csomagot, mert csak annyival több a hibalehetőség.

Ezért nem szeretem a pici programokat, amik magukkal hoznak egy csomó másik csomagot.

Nem azt mondtam, hogy perl-ben kéne elkészíteni (én biztos nem állnék neki semmi perl program elkészítésének), csak az egész megközelítés, amire gondoltam.

"Ezért nem szeretem a pici programokat, amik magukkal hoznak egy csomó másik csomagot."

Egy szimpla munin-node-hoz felszalad ~50 darab különféle perl csomag... pedig a perl elvileg ugye része az alaptelepítésnek... erre találták ki a csomagkezelőt emlékeim szerint... :)

"Nem az 50-100M a bajom, hanem ha nem muszáj, nem telepítek semmi plusz csomagot, mert csak annyival több a hibalehetőség."

Ez pusztán a plusz csomagtól függ? Ha egy darab "mindent-bele" csomag lenne az oprendszer, akkor az mennyivel több hibalehetőség ahhoz képest, hogy most akár 2000 csomag is felszalad?

Jogos.

Inkább arra gondoltam, hogy ha van két program, ami ugyanazt csinálja, és az egyik olyan libeket használ, amik már úgyis fent vannak a rendszeren és egy csomó program használja őket, abban jobban megbízom, mint a másik programban, ami miatt felkerül egy halom új lib, olyanok, amiket senki más nem használ.

Azt feltételezem, hogy a sokak által használt libekben megbújó hibák hamarabb kiütköznek és javítódnak, mint a másik, kevesek által használt libekben lévők.

( cheeky v | 2015. 02. 24., k – 17:16 )

Mi a baj a jabberd-vel vagy a jabberd2-vel?

( bAndie9100 | 2015. 02. 27., p – 14:05 )

ejabberd-t használok mint a legelterjedtebb xmpp daemon, de nem vagyok vele megelégedve.
a legapróbb config módosításhoz újra kell indítani, olyankor persze vinyognak a userek, hogy kidobja őket;
funkciódús ugyan de se a default webfelületéről, se a cli-jéből se lehet elérni azokat;
sztem logikai hibái is vannak (nincsenek globális chat szobák, hanem vhost-onként vannak, így nem tud egy szobába lépni aladar-kukac-egyikceg.hu és bela-kukac-masikceg.hu)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack