UNIX haladó

Sziasztok,

Kérném a segítségeteket, mert nekem már minden ötletem elfogyott a következőben:

Adott egy Win2012R2 Active Directory pár userrel. Bizonyos okokból kifolyólag a levelező szerver egy Debian Cyrus+Postfix párossal. Az autentikáció ldap-on keresztül menne. Ez a levelezőszerver eredetileg local linux userek mailboxait kezelte és most szeretném, ha ldap-ra menne át. A proxyaddresses mező lenne a filter.
Sikerült felvenni cyradm-el a teszt user mail fiókját, de mikor a levelező kliensbe felakarom venni a mail fiókot, akkor a következő hibaüzenetet látok:

Apr 18 16:09:46 octopus cyrus/master[4264]: about to exec /usr/lib/cyrus/bin/imapd
Apr 18 16:09:46 octopus cyrus/imap[4264]: executed
Apr 18 16:09:46 octopus cyrus/imap[4264]: accepted connection
Apr 18 16:09:46 octopus cyrus/imap[4264]: imapd:Loading hard-coded DH parameters
Apr 18 16:09:46 octopus cyrus/imap[4264]: SSL_accept() incomplete -> wait
Apr 18 16:09:46 octopus cyrus/imap[4264]: SSL_accept() succeeded -> done
Apr 18 16:09:46 octopus cyrus/imap[4264]: starttls: TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits new) no authentication
Apr 18 16:09:46 octopus cyrus/imap[4264]: badlogin: [192.168.0.52] CRAM-MD5 [SASL(-13): authentication failure: incorrect digest response]
Apr 18 16:09:49 octopus cyrus/master[4265]: about to exec /usr/lib/cyrus/bin/imapd
Apr 18 16:09:49 octopus cyrus/imap[4264]: accepted connection
Apr 18 16:09:49 octopus cyrus/imap[4265]: executed
Apr 18 16:09:49 octopus cyrus/imap[4264]: SSL_accept() incomplete -> wait
Apr 18 16:09:49 octopus cyrus/imap[4264]: SSL_accept() succeeded -> done
Apr 18 16:09:49 octopus cyrus/imap[4264]: starttls: TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits new) no authentication
Apr 18 16:09:49 octopus cyrus/imap[4264]: badlogin: [192.168.0.52] CRAM-MD5 [SASL(-13): user not found: user: user@kulso.domain.com property: cmusaslsecretCRAM-MD5 not found in sasldb]

Azt sejtem,. hogy még mindig a local userek között keresné, de már az saslauthd-t, a cyrus-t is meg a postfix-et is átállítottam (valószínüleg nem jól) ldap-ra...

root@octopus:~# imtest -a user -l0 -m login 192.168.0.16
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN SASL-IR] octopus Cyrus IMAP v2.4.16-Debian-2.4.16-4+deb7u2 server ready
Please enter your password:
C: L01 LOGIN user {8}
S: + go ahead
C:
S: L01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY LOGINDISABLED COMPRESS=DEFLATE IDLE] User logged in SESSIONID=
Authenticated.
Security strength factor: 0

* BAD Invalid tag
^CC: Q01 LOGOUT
Connection closed.
root@octopus:~# testsaslauthd -u user -p Pass123 -s smtp
0: OK "Success."
root@octopus:~# testsaslauthd -u user -p Pass123 -s imap
0: OK "Success."

A következők lennének a confi fájlok:

root@octopus:/# cat /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS Information
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/ssl/certs/newkey.pem
smtpd_tls_cert_file = /etc/ssl/certs/newcert.pem
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = kulso.domain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = kulso.domain.com, octopus, localhost.localdomain, localhost
relayhost = mail.t-online.hu
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# SASL Auth Settings
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
#smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

# Authentication on smarthost
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/client_passwords

#mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
mailbox_transport = cyrus

alias_maps = ldap:/etc/postfix/ldap_aliases.cf
virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
local_recipient_maps = ldap:/etc/postfix/ldap_aliases.cf
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

root@octopus:/# cat /etc/postfix/ldap_aliases.cf
server_host = neptunus
search_base = ou=home,dc=belsodomain,dc=com
bind=yes
bind_dn=CN=Rendszergazda,CN=Users,DC=belsodomain,DC=com
bind_pw=Pass123
scope=sub
query_filter = (proxyAddresses=%s)
result_attribute = sAMAccountName

root@octopus:/# grep -v '^$\|^\s*\#' /etc/default/saslauthd
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="ldap"
MECH_OPTIONS=""
THREADS=5
PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
OPTIONS="-c -m /var/run/saslauthd"

root@octopus:~# grep -v '^$\|^\s*\#' /etc/imapd.conf
configdirectory: /var/lib/cyrus
proc_path: /run/cyrus/proc
mboxname_lockpath: /run/cyrus/lock
defaultpartition: default
partition-default: /var/spool/cyrus/mail
partition-news: /var/spool/cyrus/news
newsspool: /var/spool/news
altnamespace: no
unixhierarchysep: no
lmtp_downcase_rcpt: yes
admins: cyrus kronosz
sieve_admins: cyrus
allowanonymouslogin: no
popminpoll: 1
autocreatequota: 0
umask: 077
sieveusehomedir: false
sievedir: /var/spool/sieve
hashimapspool: true
allowplaintext: yes
sasl_mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
loginrealms: belso.domain.com
sasl_pwcheck_method: saslauthd
sasl_auto_transition: no
tls_ca_path: /etc/ssl/certs
tls_session_timeout: 1440
tls_cipher_list: TLSv1+HIGH:!aNULL:@STRENGTH
lmtpsocket: /var/run/cyrus/socket/lmtp
idlesocket: /var/run/cyrus/socket/idle
notifysocket: /var/run/cyrus/socket/notify
syslog_prefix: cyrus
tls_cert_file: /etc/ssl/certs/newcert.pem
tls_key_file: /etc/ssl/certs/newkey.pem
tls_ca_file: /etc/ssl/certs/cacert.pem

Van valamilyen tippetek, hogy mit néztem be? Szét túrtam a guglit, de semmi használhatót nem találtam, hátha majd most!

Köszi szépen!

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.

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?