Aki úgy érzi, hogy kedve van hozzá, kérem, mondja el, hogy miért, vagy miért nem használ(na) Exchange-t a nyílt forrású, saját maga által összerakott rendszer helyett.
Az Exchange-ről nagyon keveset tudok. Tényleg annyira jók és szükségesek és kihasználtak az "alap" levelzőkön felüli képességei (teremfoglalás, metting request, ilyesmi - nem tudom, mi van még, ami tényleg ér valamit)?
Sziasztok,
Zarafaval játszok, amit OpenLDAP modullal használnék. Kerestem leírást arra, hogy egy aliast/levelezőlistát hogyan tudnék benne létrehozni. Az tiszta, hogy van zarafa-group, de hogy ezen belül milyen attribútumokat kellene belőni hozzá és hogy ezt a csoportot a hierarchiában hol helyezem el, az már nem teljesen (kb. 6 éve kellett utoljára OpenLDAP-hoz nyúlnom komolyabban).
Nagyon hálás volnék, ha valaki Zarafa expert kisegítene egy kis iránymutatással, vagy akár egy erről szóló tutorial linkkel (amiket találtam, egyik sem volt egyértelmű sajnos).
Előre is köszönöm a segítséget!
Valoszinuleg trivialis a problemam megoldasa, de nem jovok ra.
Elorebocsatom, nginx - try_files nem jatszik.
Adott egy httpd 2.4, ProxyPassMatch direktivaval hivja a php fileokra a php-fpm-et
ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9001//var/www/html/www/$1
teljesen jol mukodik, amig egy nemletezo php filet nem hivnak meg:
ilyenkor a php-fpm dob egy "file not found" uzenetet
Barmilyen mas file eseten (vagy dir) az apache 404 jon (vagy ami helyette van). Tehat ez ok
http://xy.hu/xy.html
http://xy.hu/xy
Szepen az apache dob hibat. De PHP filenal nem kezeli le....
Lehet valahol allitani, hogy az apache megnezze, letezik-e a file es csak akkor adja at a proxynak, ha az letezik ?
Sziasztok!
Adott egy Debian 8-on futó perlben megírt video archív kereső rendszer ami idáig tökéletesen működött. Az utóbbi napokban jelentősebb mennyiségű adatot kapott ami miatt lelassult a kesesés kb 5-6 másodpercre. Ezzel nincs is gond mert várható volt. Viszont amíg az egyik gépen egy adott keresés folyik, addig a többin nem indul el semmilyen CGI-t futtató oldal (beleértve az archiv keresőt is). Helyette csak várakozik, és csak akkor indul el ha a másik gépen megjelent a keresés eredménye.
Jelenleg ezek az ide vonatkozó beállítások:
/etc/init.d/fcgiwrap:
.
.
# FCGI_APP Variables
FCGI_CHILDREN="10"
FCGI_MAX_REQUESTS="100"
.
.
DAEMON_OPTS="-c 10"
.
.
Az Nginx ide vonatkozó része (fastcgi.conf):
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REMOTE_USER $remote_user;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
#fastcgi_param REDIRECT_STATUS 200;
Mit kell még beállítani, hogy valóban működjön a párhuzamosság?
Sziasztok,
Próbálnék egy levél küldő szervert készíteni, ami képes SPF, DKIM kezelésre és mellette real time logol adatbázisba. De szerintem bátran mondhatom, hogy már az elején elakadtam.
Tehát a cél:
- Nem túl nagy terhelésű levél küldő készítése, napi maximum 1000 mail kiküldése. Vannak erősebb és gyenégg napok, de átlagnak vehető az 1000 / nap. Ebből 0db hírlevél, vagy SPAM levél, csak fontos céges, web alkalmazás levelek (regisztráció megerősítés..stb.), automatizált értesítők éjszakánként (pl, meg nem erősített regisztrációk, újboli kiértesítése).
- A lehető legmagasabb fokú SPAM elleni küzdelem beállítható legyen rajta, úgy mint SPF, DKIM
- Csak leveleket kell tudjon küldeni, fogadni nem kell neki semmit. Fogadni egy másik szerver fogadja a leveleket, ez csak kiküld.
- Egy nagyon fontos, ha nem a legfontosabb tulajdonság, pedig, hogy real time tudja naplózni mysql-be a rendszer, hogy ki, kinek mikor mit küldött ki és arra mi volt a címzett szerver válasza. Tehát kb: timestamp, from, to, subject, remote answer... A REAL TIME itt nagyon fontos.
Az elképzelés a következő volt:
- Postfix, mert levél küldésre kiválóan konfigurálható. Bár nagyon sok mást is tud, amire itt nincs szükség, de hát enni nem kér.
- Postfix a SPAM elleni harc esetén is jó választásnak tűnt, mivel SPF, DKIM, mind megoldható nála.
- Majd jött a loggolás... Nah itt megakadtam.
-- Volt a rsyslog, ami tud adatbázisba logolni, de az csak fájl helyett DB-be ír mindent ömlesztve. Ugyan az, mint a syslog-ng, csak nem fájlba ment.
-- Tudnék írni egy scriptet, ami a mail.log fájlt felparsolja, de real time nem tudom, hogyan oldjam meg. Ha a logrotate átfordítja a log fájlt két script futás között, akkor kiesig a köztes esemény a logokból. Illetve, ha nagy, akkor amíg lockolom a fájlt (értsd parsolom), nem tudom, hogy a syslog-ng mit csinál, mert hogy nem vár rám, az biztos.
-- Aztán persze megoldható úgy is, hogy folyamatosan nyitva a fájl, de csak olvasásra, vagyis nincs lock, és figyeli a scipt az új sorokat és logol. De mi van, ha lehal a script, akkor újraindulásig, független, hogy kézi, vagy automatizált, a köztes idő elvész.
-- Köztes megoldás, hogy rsyslog ment adatbázisba és ami a levelezéssel kapcsolatos, azt parsolgatja egy script és kigyűjti belőle, ami nekem kell és a felparsolt sorokat megjelöli egy flaggel, hogy azzal már végzett. De mivel scriptről beszélünk, az sem real time, mert percenként fut a script.
A legjobb az lenne, hogyha lehetne olyat csinálni, hogy a postfix minden levél küldés esetén meghívna egy scriptet, ami a paraméterekből, vagy a postfix által átadott adatok alapján insertálgatná az adatbázis sorokat. A script nem figyel folyamatosan, így nem tud lehalni... A postfix régi motoros, nem hibázik, tehát minden script hívás megtörténne, idővel a script bug mentes lenne, tehát adat vesztés gyakorlatilag 0-ra redukálódna.
Vagy... és most jön az, amiről én nem tudok. Lehet, hogy létezik erre egy tök egyszerű megoldás, csak én még nem hallottam róla.
Bármilyen építő jellegű választ és ötletet szívesen fogadnék.
Köszönettel...
olyan idonyilvantarto kell nekem, ami:
-crossplatform, elsodleges OSX es Win, de nem bannam ha android/ios kliens is lenne,
-lehessen projekt hierarchiat csinalni benne, kb. projekt/alatta taskok pl. doc/kodolas/support,
-okos legyen, ha elnditok egy timert 1 taskon, akkor az addig futo timert allitsa le automatikusan,
-lehessen belole ertelmes statisztikat kinyerni
Preferalt egyeb, nem kizaro ok, ha nem tudja:
-ne nekem kelljen hostolni
ingyenes a preferalt, de ha eleg jo, akkor kis penzert johet a fizetos is,
-multiuser is tudjon lenni, ua. prj-ken tobb user is tudjon dolgozni,
a mindenfele "beirom egy tablazatba" tipusu megoldasok nem erdekelnek, metr idorablo/kenyelmetlen/stb.
Ubuntu + Firefox alatt küzdök a munkahelyi belső hálózattal, SPS-el (SharePoint 2013, nemrég állt lábra).
Maga az SPS webhely bejön, de a fájlok letöltése (nálam) akadályba ütközik.
Előjön egy efféle hibaüzenet: (képernyőkép)
A kapcsolat nem biztonságos
A youtyuk.cegem.intra tulajdonosa a weboldalát helytelenül állította be. Az Ön adatainak ellopását megakadályozandó a Firefox nem csatlakozott ehhez a weboldalhoz.
youtyuk.cegem.intra uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER
És nincs hová kattintani, hogy "nekem mégiscsak jó lesz az a (kevéssé megbízható) tanúsítvány".
Meg eleve bizarr, hogy maga a webhely (és a fájlok nevei) hogyhogy látszanak, ha valami hiányosság van?
Lehet, hogy az about:config-ban kell valamit hackelnem? Valami ntlm vagy auth vagy hasonlót?
(Chrome-ban is bejön az SPS oldal, de a fájlokra kattintva csak 
ez. És efféléket jelez, ha megnyitom a DevTools-t: Tanúsítványhiba. Gond van a webhely tanúsítványláncával (net::ERR_CERT_AUTHORITY_INVALID). )
Volt korábban egy hasonló helyzet: http://hup.hu/node/134248
Szerk: a komoly megoldás abban áll, hogy a kívánt fájl linkjét kimásolom, beragasztom egy új böngészőfülre, majd törlöm az URL végéről a ?Web=1 részt. Így már engedi letölteni a fájlt. :-)
Sziasztok!
A Firefox 45.00 jelzi, hogy frissíteni kellene a 45.01 verzióra.
A letöltés ismeretlen hiba miatt sikertelen.
Kézzel letöltve - belekukkantva 43.01 verzió látszik.
Igaz Windowson, de zavar az erőben?
Ki látott ilyet?
Sziasztok
Egy ismerősnek keresek ticket rendszert. A következő feltételeket támasztotta:
+ Az userek "ismeretlenek", nem lesznek előre rögzítve a rendszerben
- Az ügyfélnek csak e-mailben kelljen visszairni, ne kelljen a felületre feljönnie
+ Függetlenűl attól, hogy weben vagy mailen keresztül válaszolok, weben megjelenjen ugyanabban a ticketben
+ Világos felületen lehessen visszakövetni minden egyes tickethez tartozó beszélgetést
+ A könnyű kezelhetőség fontos, létfontosságú
+ Hozzáférés és jogosultság kezelés felületről normális, érthető legyen
+ Saját szerveren lehessen futtatni
+ Legyen ingyenes, és lehetőleg php, hogy bele tudjunk nyúlni szükség esetén
+ A válaszidők mérve legyenek
+ lehetőség szerint legyen valamilyen szintű statisztika (vagy a lehetőség adott legyen ennek belefejlesztésére)
- Nem kell hibakezelés, és projektkezelés, tehát nem kell redmine, bugzilla, mantis
- Ne legyenek buta reklám láblécek az e-mailben.
Anélkül, hogy több tucatot végignézne, meg fél évente váltogatná, tudnátok pár befutót javasolni?
Köszönöm!
update: cél, hogy minden ügyfélszolgálatra beeső mailnek nyoma legyen. Visszakövethető legyen. Azonos témában való levélváltás 1 ticketben legyen weben. Ha a beszéd tárgya megoldódott, akkor a ticket zárható legyen + megnézve, hogy mennyi ideig tartott a megoldás (ha több hét, akkor fejrekoppintás van).
Sziasztok!
Láttam hogy van pár hasonló topic, de mivel úgy láttam másabb a problémám ezért nyitottam egy újat.
Adott egy újonnan beállított szerver (teszt üzemben) amiről emailezni szeretnének. Nem hírlevél, reklám, stb. a cég levelezése menne róla. A küldés fogadás működik is. A probléma a következő: ha gmail-es címre küldenek levelet az automatikusan a spam mappába landol. Beállítottam az SPF, DKIM, DMARC rekordokat, reverse DNS passzol.
mail-tester 10/10: http://www.mail-tester.com/web-vBvtRB
mxtoolbox:
Result
SMTP Transaction Time : 9.845 seconds - Not good! on Transaction Time
SMTP Reverse DNS Mismatch : OK - 95.210.117.110 resolves to mail.inna.hu
SMTP Valid Hostname : OK - Reverse DNS is a valid Hostname
SMTP Banner Check : OK - Reverse DNS matches SMTP Banner
SMTP TLS : OK - Supports TLS.
SMTP Connection Time : 4.579 seconds - Good on Connection time
SMTP Open Relay : OK - Not an open relay.
Ezek alapján azt gondolnám hogy nem kéne a spam mappába kerülnie a leveleknek. Van valakinek ötlete, hogy mi hiányozhat még? Előre is köszi a tippeket.
Üdv:
Zsolti
Update:
Köszi a tippeket, mivel zentyalon fut, ami amúgy sem áll a helyzet magaslatán eddigi tapasztalatom szerint, google apps for work-be költöztetik a levelezést.
