UNIX haladó

Sziasztok!

Egy levelezőszerverrel kapcsolatban szeretném a segítségeteket kérni.
Jelenleg van egy szerver, amin postfix, cyrus imap működik. A leveleket egy távoli kiszolgálóról tölöm le fetchmail programmal. Minden nagyon jól működik, de sajnos a szolgáltató akinek a levelek befutnak visszautasítja az EXE fájlok kézbesítését. Ez nekünk igen nagy gond...
Szóval a kérdés: mit kellene tenni, hogy a mi szerverünk legyen a levelek közvetlen fogadója? Elég ha a domain mx rekordjait ráállítjuk a mi IP-nkre? Sajnos ilyent még nem csináltam, így annek a beállításához szeretném a segítségeteket kérni!

Előre is megköszönve minden hozzászólást!

KissAG

olyat szeretnék, hogy a C fordító elé egy wrappert, ami azt tudja, hogy beledudál egy démonba IPC-n bizonyos feltételek teljesülése esetén, pl. elindult egy CC példány, A démon meg csinál valamit TCP/UDP-n. Cél, hogy a unix szerű rendszerek közül minél többöbön tudjon futni extra ráfordítás/portolás nélkül. Jellemző célplatform a jelentős CC erőforrást használók, *BSD, Linux. OSX nem cél kimondottan, mert nem túl jellemző a tömeges C fordítás.
Felmerült lehetőségek:

C nyelvű démon:
+tömör, lehet binárisban terjeszteni néhány platformra
-relatív lassan lehet fejleszteni benne.

Valmi szkriptnyelv:
+gyorsan lehet haladni vele,
+transzparens, módosítható=többen érdekeltté tehetők

Perl (+ezt tudnám máshol is hasznosítani? -20 éve volt népszerű) vs. Python (+modern, divatos, van jövője)

Magam a szkriptnyelvű megoldások felé hajladozok, de érdekelnek további aspektusok/vélemények.

Sziasztok,

Néhány gondolat, tapasztalat a Repcache, Couchbase kapcsán.

A webszervereink működése során eljutottunk arra a pontra, hogy szükségessé vált a PHP sessionok alternatív módon történő kezelése.
Alapesetben fontos, hogy a jelenlegi két szerver közötti PHP sessionok mindkét szerver által "láthatóak" legyenek, ezt OCFS2-vel oldottuk meg.
Majd jött egy érdekes probléma, a sessionok nagy száma miatt az OCFS2 elérése finoman szólva is problémás volt, 200+ os load-ról beszélünk és álló
szolgáltatásokról, mivel szerencsétlen nem tudta elérni a session fileokat, jobban mondva elérte egy idő után, de ki akarja ezt kivárni?!

Szóval volt vala ez

Tudni kell, hogy a szerverek egy haproxy mögött helyezkednek el, a fenti problémára az ideiglenes megoldás a saját EXT4-es filerendszer használatával
küszöböltük ki, na bumm oda a session redundancia.

Majd lett belőle ez

Sebaj, van egy csodálatos szolgáltatás...Memcache, beállítottuk (persze a tesztrendsezren :) ) - igazából a repcache-t - boldogok voltunk, odasüss, szinkronizál, működik!

A sok transzformáció után lett belőle ez

Aztán jöttek a tesztek és az anomáliák, szerverek közötti váltásoknál nem minden esetben volt sikeres a session file-ok használata, ott volt, de mégsem tudta/akarta olvasni, esetleg a kliens oldalon tűnt el a sessionID, így már esélytelen volt, hogy bármilyen szolgáltatás működjön újbóli bejelentkezés nélkül.
És egy apró, de nem elhanyagolható probléma, ServerA meghal, nem baj, hiszen ServerB tartalmazza az elhalásig szinkronizált összes adatot, de mint fentebb írtam ez nem volt 100%-osan működőképes.
De a fő probléma ott van, hogy ServerA egyszer csak beleordít az éterbe, hogy "DRÁGÁM, MEGJÖTTEM", ServerB erre annyit mond, hogy "ÉS?", nesze itt van 1-2 session, most generálták nálam őket. Na mármost itt van egy kis probléma, ServerB rendelkezik mondjuk 6000 sessional, ServerA pedig 1-2-vel, és nem, nem fogják szinkronizálni, hiszen a repcache ezt nem tudja, ő azt tudja, hogy ha keletkezik egy session ServerA-n vagy ServerB-n azt leszinkronizálja oda-vissza.
Sebaj, erre is van megoldás, egy gyönyörű phpscript amit mondjuk induláskor lefuttatva leszinkronizálhatja az éppen feléledő szerverre a párja tartalmát. Kicsit buhera, nemde?
Aztán képbe került, hogy lesz egy harmadik szerver is, na ekkor vetettük el a repcache-t, egyszerűen erre totálisan alkalmatlan.

Képbe került a Couchbase.
Akkor ugorjunk neki felkiáltással ment is fel a tesztrendszerre, itt már a majdani három szerveres megoldással futottunk neki a beállításnak.
Első körben csináltunk egy Clustert (memcached bucket-el, de ezt hamar elvetettük és a Couchbase bucket-et használjuk), amelyben benne volt mindhárom szerver, be lett állítva a replikáció, csodás ServerA tartalma replikálódik ServerB-re és ServerC-re és ServerB pedig ServerA-ra és ServerC-re és így tovább.
Aztán jött a fekete leves, szerencsétlen PHP ha így van beállítva:

 
session.save_handler = memcached
session.save_path = '172.18.99.1:11211, 172.18.99.2:11211, 172.18.99.3:11211'

minden gyönyörűen működik amíg az összes szerver elérhető, de a szerverek közötti mozgás továbbra sem tökéletes, megy is meg nem is, leginkább nem.
A másik probléma, hogy a PHP nem igazán tolerálja, ha valamelyik megadott save_path nem elérhető, ha kiesett akkor az eredmény, oldal nem működik, mindenféle config problémákkal dobálózik a logokban, hogy ő bizony nem éri el ServerB-t pedig ez van beállítva.
Itt jogosan kérdezed, hogy akkor miért nem localhost?
Igazából az, de nem a fenti megoldással, emlékszel, replikálódik de az átjárás a szerverek között nem működik rendesen, álló szolgáltatások, ismételt bejelentkezés...nightmare.

A másik megoldás pedig a Couchbase XDCR (Cross DataCenter Replication) szolgáltatása a php.ini localhost-os beállításásval.
Ebben az esetben nem húzod be az összes szerveredet egy Clusterbe ahol ugye egy bazinagy vödörbe kerül a szervereken beállított memóriamennyiség, hanem mindenki a saját kis kiosztott memóriájával gazdálkodhat.
Ha mindegyik kis clusteredet (valójában egy nyamvadt szerver fut a clusterban, de ha a Couchbase clusternek hívja, legyen az) felkonfiguráltad, elindultak mehet a replikáció beállítása az XDCR fülön, itt is a hasonlóan kell beállítani, mint ahogy az egy clusterben történt, csak ez nem automatikus, hanem kézzel történik.

Tehát valahogy így néz ki a kapcsolati ábra most

Tehát fogjuk ServerA-t és felvisszük ServerB-t és ServerC-t az XDCR Remote Clusterek közé, majd a Create Replication gombbal beállítjuk, hogy ezen a szerveren melyik "bucket-et" fogja szinkronizálni a másik cluster melyik bucketjébe. Pl: ServerA default bucket megy ServerB default bucket-be és ServerC default bucket-be. A többi szerveren hasonló séma szerint kell beállítani.
Csak azért default, mert ezt nem lehet változtatni, egyébként is, nekünk tökéletesen megfelel.

Maga a szinkronizálás változásra történik meg, és ami csodálatos, ha bármelyik szerver nem elérhető...nem történik semmi, megy minden tovább a maga útján, a haproxy nem fog odadobni kérést, hiszen azt mondja, hogy hohóó, nálad nem működik a Couchbase, nem kapsz semmit, majd odaadom ServerX-nek a session-t.
De mi történik, ha teszem azt, - maradva az előző példánál - ServerA feladja a harcot és eltűnik az éterből? Semmi, majd ServerB és ServerC dolgozik helyette, a HAProxy megoldja.
Majd később eljön a várva várt pillanat: ServerA egyszer csak azt mondja: "DRÁGÁM, MEGJÖTTEM", erre azt kiáltja ServerB és ServerC, hogy "ÖRÜLÖK, HOGY ITTHON VAGY" nesze itt vannak az adatok, cserélgessünk egymás között, majd kis idő múlva tadaaa az összes session megjelenik ServerA-n is, mindenki boldog, leginkább a felhasználó, nincs kiesés, gyors.

Jelenleg itt állunk, a rendszer tesztelési fázisban van, de a tapasztalatok eddig biztatóak, remélem segítettem, hogy ne kelljen másnak is végigjárnia ezeket a hosszadalmas tesztelési köröket. És ofc szívesen várom az építő jellegű hozzászólásokat :)

A végére néhány unalmas beállítás:

(Rep)Memcache esetében:

php.ini
Memcached: (php5-memecached)

session.save_handler = memcached
session.save_path = '172.18.99.1:11211, 172.18.99.2:11211, 172.18.99.3:11211'

Memcache (php5-memcache)

session.save_handler = memcache
session.save_path = 'tcp://172.18.99.1:11211, tcp://172.18.99.2:11211, tcp://172.18.99.3:11211'" 

memcached.ini, letölthető innen: http://sourceforge.net/projects/repcached/files/

extension=memcached.so
[memcached]
memcached.sess_locking = 1
memcached.sess_consistent_hash = 1
memcached.sess_binary = 1
memcached.sess_lock_wait = 150000
memcached.sess_prefix = "memc.sess.key."
memcached.sess_number_of_replicas = 2
memcached.sess_randomize_replica_read = 0
memcached.sess_remove_failed = 0
memcached.compression_type = fastlz
memcached.compression_factor = 1.3
memcached.compression_threshold = 2000
memcached.serializer = php
memcached.use_sasl = 0

memcache.ini:

extension=memcache.so
[memcache]
memcache.dbpath="/var/lib/memcache"
memcache.maxreclevel=0
memcache.maxfiles=0
memcache.archivememlim=0
memcache.maxfilesize=0
memcache.maxratio=0
memcache.allow_failover=1
memcache.max_failover_attempts=2
memcache.session_redundancy=2
memcache.default_timeout_ms=1000
memcache.hash_strategy=consistent

A couchbase esetében, nem tudok config file-okkal szolgálni, lényegében a webes felületen beállíthatóak a szükséges dolgok.
Letölthető innen: http://www.couchbase.com/nosql-databases/downloads
Az install tulajdonképpen next -> next -> finish

dpkg -i couchbase-server-community_3.0.1-ubuntu12.04_amd64.deb

Majd a http://server_ip:8091 -es porton lehet elérni a böngészőben.

Üdv, Thunder

A segítségeteket kérném:
van egy Ubuntu 14.04 alapú szerverem, benne két LXC-vel. Mindkét LXC-ből szolgáltatások futnak. Az egyik kifelé, dedikált interfészen, a másik pedig csak belső használatra.
A "kifelé futó" LXC ma reggel óta furcsa dolgokat produkál: egy folyamat mindig 100%-on terhel egy magot a processzorban.
A folyamat a konténer újraindításával együtt változik, számomra összefüggéstelenül, de mindig marad a terhelés.
Jelenleg a /usr/sbin/cron, előtte a /usr/sbin/httpd.
A szerveren Apache, PHP és MySQL fut.
Lehet, hogy nem összefüggő a két dolog, de a hoston az rkhunter a "Performing file properties checks" részben elég sok Warning-ot dob, illetve a "Checking for passwd file changes" és "Checking for group file changes" részek is "Warning" feliratot kaptak, ezeket előtte nem vettem észre.
Nagy változás nem volt a szerveren az utóbbi időben, csak plusz RAM került bele.
Mi okozhatja ezt a jelenséget, illetve mit lehet ilyenkor tenni?

Sziasztok,

olyanba futottam bele, hogy egy (már megtelt) snapshot-t töröltem (volna), és ez a mutatvány magával vitte az egész rendszert...
A felállás a következő:
-LVM-en egy volume drb_vm néven
--a fenti volume-on aktív drbd sync egy másik géppel (ez volt a (pri)/sec)
--a fenti volume-ról egy snapshot vm_snapshot néven

a vm_snapshot-t lvremove-oltam, erre olyan szinten berágott, hogy
1) megállt a drbd és a VM
2) lv* toolok nem adtak visszajelzést
3) folyamatosan nőtt a load
3) reboot oldott meg a problémát

Én rontottam el valamit? Rosszul gondoltam, h a snapshot-t büntetlenül lehet törölni?
(nyilván a snapshot nem volt sem mount-olva, sem egyéb módon használva)

Sziasztok!

Nagy méretű PST file-kat kell átemelnem postfix-dovecot-openchange-sogo mail szerverre.
A readpst nevű progival átkonvertálom MBOX formátummá, ez így emészthetővé is teszi csak az így kapott könyvtárakat egy az egyben nem tudom átemelni, mert minden egyes könyvtár neve előtt szerepleni kell a "."-nak a könyvtárakon belül létre kellene hozni egy cur, new, tmp mappát, és a persze a leveleknek szerepelni kell a cur mappában.

Van valakinek egyszerűbb megoldása, vagy scriptel kell megoldanom, ami nagyon nagy lemezműveletbe torkolna.

Köszönöm a válaszokat.

-----
Elnézést kérek először rossz helyre került.

Sziasztok
Az a problémám:

Adott egy Windows addc (alma.hu) és mellette még teszt fázisban lévő samba4-openchange-sogo szerver (barack.hu) .
Az a gondom, hogy két domain lévén az outlook klienseken még egyszer megkell adni a barack domain user jelszót.
Meg szeretném kímélni a felhasználókat, hogy meg kelljen nekik jegyezni még egy jelszót.
Sajnos az openchange-t nem tudom úgy megcsinált, hogy az alma.hu domain része legyen. Mert akkor vadul kiabál, hogy nem elsődleges addc.(sajnos nem cserélhető le a Windows addc-t)
Tudom-e a Windows addc (alma.hu) lévő felhasználók jelszavát szinkronizálni a barack.hu domaiben lévő felhasználóként?
A két domaiben ugyanazok a felhasználók lesznek.

Ötletekket előre is köszönöm.

Az nginx LXC-ben nem indul el, mint szerviz, de manuálisan elindítva fut CentOS 7-en.

systemctl status nginx.service -l

nginx.service - nginx - high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
Active: activating (start) since Wed 2014-10-01 22:10:27 UTC; 19s ago
Docs: http://nginx.org/en/docs/
Process: 2365 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Process: 2364 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
CGroup: /machine.slice/machine-lxc\x2dcentos\x2d7\x2dx86_64.scope/system.slice/nginx.service
├─2366 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
└─2367 nginx: worker process

Oct 01 22:10:27 nginx.teszt nginx[2364]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Oct 01 22:10:27 nginx.teszt nginx[2364]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Oct 01 22:10:27 nginx.teszt systemd[1]: PID file /run/nginx.pid not readable (yet?) after start.

/etc/nginx/nginx.conf tartalma:

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
worker_connections 128;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;
}

Honnan veszi a systemd, hogy a PID a /run/nginx.pid -ben van?
Pedig a conf-ban helyesen a /var/run/nginx.pid szerepel.

nginx

után szépen fut:

ps ax|grep nginx
2383 ? Ss 0:00 nginx: master process nginx
2384 ? S 0:00 nginx: worker process

De nem tudom systemctl -en keresztül kezelni.

Ez alapján raktam fel:

https://www.digitalocean.com/community/tutorials/how-to-install-nginx-o…

De már itt sem működött a konténerben:

systemctl start nginx.service

Mit nem veszek észre?

UPDATE 1:

/usr/lib/systemd/system/nginx.service állományban hibás az alap beállítás, át kell írni a PID-et...

Sziasztok,

Némi információra van szükségem. Egy adatbázist beakarok tölteni a memóriába és szeretnék onnan dolgozni, hogy még gyorsabb legyen. Ezt a cat paranccsal szépen be is tudom tölteni és látom, is hogy bekerült. Ugyan akkor én úgy érzem, hogy nem onnan dolgozik az adatbázis, hanem csak betöltöttem az adatbázis fájlokat és ott vannak, de az adatbázis továbbra is a diszken lévő fájlokat használja.
Nem tudok konkrét adatbáziskezelőt mondani, mert független.
A kérdésem igazából, csak annyi, hogy ha cat-el valamit beteszek a /dev/null-ba akkor az csak ott van, de nem történik vele semmi. Jól sejtem?

Van egy PC-m, amin Ubuntu fut. Az ubuntu egy SSD-re van telepítve. Mivel az SSD kapacitása kicsi, ezért a /home könyvtár tartalma egy régi HDD-n van.
Ez eddig oké, de lesz itthon egy saját építésű home server, aminek a kapacitása jóval nagyobb lesz, mint a régi HDD-m kapacitása. Arra gondoltam, hogy a /home tartalmát cakk-pakk átteszem a NAS-ra mondjuk (valahogy) seafile-on keresztül, és aztán beállítom az fstab-ban hogy webdav fájlrendszerként csatolja fel.

Tudom, talán egyszerűbb lenne NFS-el megoldani, de azért megpróbálnám a webdav-ot munkára fogni ha lehet.
- Az ok: tetszik a mostani telefonos webdav kliensem. :)

Problémák amik felmerülnek:
- Nem tudom, a webdavon keresztül, mennyire kezelhetők a linuxos userek, csoportok, jogok?
- Valszeg lassabb lesz mint a régi HDD-m.

A kérdésem az lenne, van e tapasztalat a fenti témával kapcsoltban? Vagy teljesen életképtelen ötletet találtam ki?