Не е много голяма мистерията. Има списъци с цели блокове от адреси, които по подразбиране са си ги маркирали като динамични. И ако даден сървър ползва тези списъци, за да филтрира спам, то тогава твоите писма автоматично се маркират като такива ако адреса ти е част от списъка. За да може даден адрес да се премахне от техните списъци като динамичен, то много често се изисква собственика на адресите (на мрежата) да се свърже с тях и да потвърди, че наистина този адрес е статичен.

Поне преди няколко години, когато администрирах пощенски сървъри бях попаднал на такива списъци.

Здравейте,

до колкото съм чел и съм правил тестове, бих казал че XFS не се държи много добре при множество малки файлове, за сметка на това се държи много добре когато борави с големи по размери файлове. ext4 се държи по-добре с малки файлове, и що годе добре с големи файлове.

ext2, ext3, ext4, raiserfs, xfs, zfs всички си имат + и -. Няма идеална файлова система.

Разбира се това е лично наблюдение. 

Прегледах си топологията още веднъж и всъщност, това което правя не е правилно и причинявам зацикляне между сървърите.

Това, което в момента съм сетнал като upstreams на трите сървъра мисля, че е грешно.

На сървъра, който пряко получава трафика от клиентите трябва да ги има и 3-те upstream-а сетнати, но на останалите два сървъра трябва да има само по един, който е 127.0.0.1:8080, защото така иначе се получава зацикляне. Така или иначе тафика винаги минава през първия сървър. При евентуален проблем с връзката към сървър 1 или ако целия сървър падне, трябва само failover ip-to да се превключи към другия сървър (Сървър 2 или Сървър 3).

Друго решение да се предотврати зациклянето би било ако се сетва weight на 127.0.0.1:8080 upstream и нека ги има и 3-те upstream-а на трите сървъра или се спре round robin.

Какво е вашето мнение?

Изглежда улучвам същия този бъг или подобен: http://trac.nginx.org/nginx/ticket/142


anebi@gdo2 /etc/nginx/sites-enabled # lsb_release -a
No LSB modules are available.
Distributor ID:   Ubuntu
Description:   Ubuntu 12.04.1 LTS
Release:   12.04
Codename:   precise
anebi@gdo2 /etc/nginx/sites-enabled # uname -a
Linux gdo2 3.2.30custom #1 SMP Thu Nov 1 13:53:54 CET 2012 x86_64 x86_64 x86_64 GNU/Linux


anebi@gdo2 /etc/nginx/sites-enabled # dpkg -l | grep nginx
ii  nginx                            1.1.19-1ubuntu0.1                   small, but very powerful and efficient web server and mail proxy
ii  nginx-common                     1.1.19-1ubuntu0.1                   small, but very powerful and efficient web server (common files)
ii  nginx-full                       1.1.19-1ubuntu0.1                   nginx web server with full set of core modules
anebi@gdo2 /etc/nginx/sites-enabled # nginx -v
nginx version: nginx/1.1.19

Тъкмо това подготвях с малко инфо от логовете, изпревари ме

gdo1 с вътрешно ip: 10.10.10.1  (Сървър 1)
gdo2 с вътрешно ip: 10.10.10.2  (Сървър 2)
gdo3 с вътрешно ip: 10.10.10.3  (Сървър 3 - backup server)

Свързаността между сървърите е наред.

Сървър1:
nginx.conf

Код:

user www-data;
worker_processes 2;

# ulimit
worker_rlimit_nofile 65535;
pid /var/run/nginx.pid;

events {
        worker_connections  10240;
        use epoll;
        # multi_accept on;
}

http {

        # The Apache load balancing proxy targets for port 80 traffic
        upstream gdo_lb {
                server 127.0.0.1:8080;
                server gdo2;
                server gdo3 backup;
        }

        # Proxies for port 443 traffic
        upstream gdo_slb {
                server 127.0.0.1:10443;
                server gdo2;
                server gdo3 backup;
        }

        ##
        # Basic Settings
        ##

        sendfile on;
        #tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 10;
        types_hash_max_size 2048;
        server_tokens off;

        client_max_body_size 40M;
        client_body_buffer_size 128k;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

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

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        # gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 2;
        # gzip_buffers 16 8k;

        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

proxy_params еднакъв на всички сървъри

Код:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 90;
proxy_send_timeout 300;
proxy_read_timeout 300;
proxy_buffer_size 16k;
proxy_buffers 32 64k;
proxy_busy_buffers_size 128k;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

Сървър 2

nginx.conf - различава се само частта, която е за upstream от Сървър 1

Код:

        # The Apache load balancing proxy targets for port 80 traffic
        upstream gdo_lb {
                server 127.0.0.1:8080;
                server gdo1;
                server gdo3 backup;
        }

        # Proxies for port 443 traffic
        upstream gdo_slb {
                server 127.0.0.1:10443;
                server gdo1;
                server gdo3 backup;
        }

Сървър 3:

nginx.conf - различава се само частта, която е за upstream от Сървър 1

Код:

        # The Apache load balancing proxy targets for port 80 traffic
        upstream gdo_lb {
                server 127.0.0.1:8080;
                server gdo1;
                server gdo2;
        }

        # Proxies for port 443 traffic
        upstream gdo_slb {
                server 127.0.0.1:10443;
                server gdo1;
                server gdo2;
        }

nginx vhost на всички сървъри

Код:

server {
    listen 80;
    server_name mydomain.tld;
    access_log /var/log/nginx/mydomain.tld.access.log;
    error_log /var/log/nginx/mydomain.tld.error.log;

    location / {
        proxy_pass   http://gdo_lb;
        include /etc/nginx/proxy_params;
    }
}

Това, което виждам в логовете:

Сървър1:

Код:

2012/11/05 23:00:00 [error] 17941#0: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 10.10.10.2, server: mydomain.tld, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:8080/", host: "mydomain.tld"
2012/11/05 23:00:31 [error] 17941#0: *3413 connect() failed (111: Connection refused) while connecting to upstream, client: 89.215.8.109, server: mydomain.tld, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "mydomain.tld"
2012/11/05 23:00:42 [error] 17941#0: *3413 connect() failed (111: Connection refused) while connecting to upstream, client: 89.215.8.109, server: mydomain.tld, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "mydomain.tld"

Сървър 2 logs:

Код:

2012/11/05 23:00:31 [error] 6613#0: *3413 connect() failed (111: Connection refused) while connecting to upstream, client: 10.10.10.1, server: mydomain.tld, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:8080/", host: "mydomain.tld"
2012/11/05 23:00:42 [error] 6613#0: *4778 connect() failed (111: Connection refused) while connecting to upstream, client: 10.10.10.1, server: mydomain.tld, request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:8080/", host: "mydomain.tld"

П.С. Това, което виждам сега като пуснах дебъга на nginx е че се 10.10.10.1 и 10.10.10.2 зациклят помежду си някак и X-Forwarded-For хедъра става по-голям и по-голям, докато не достигне лимита си. Ето парче от лога:

Код:

X-Real-IP: 10.10.10.2
X-Forwarded-For: 89.215.8.109, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2, 10.10.10.1, 10.10.10.2
Connection: close

П.С.2 Ако съм пропуснал нещо само кажете

Здравейте,

Правя едни тестове с nginx свързани с load balancing и прокси към апаче. Имам следната конфигурация:

server 1

nginx load balancing:

upstreams:
127.0.0.1:8080;   ( proxy to apache installed on same server)
server2;          (nginx on server2)
server3 backup;          (nginx on server 3)

server2:

nginx load balancing:

upstreams:
127.0.0.1:8080;   (apache installed on same server)
server1;          (nginx on server1)
server3 backup;          (nginx on server 3)

Server 3 (Backup server - да поеме трафика, единствено ако Сървър 1 и 2 не работят): 

Load balancing:

upstreams:
127.0.0.1:8080;   (apache installed on same server)
server1;          (nginx on server 1)
server2;          (nginx on server 2)



Теста, който правя е следния:

1. На Сървър1 оставям работещ nginx и спирам апаче там
2. На Сървър2 оставям работещ nginx и спирам апаче там
3. На Сървър3 оставям работищи и nginx и апаче.

Очакван резултат - сайта да се покаже без проблем, като се обслужи от Сървър 3.

Това, което се случва обаче е, че вместо сайта, получава 400 Bad Request Request Header Or Cookie Too Large

Опитвам се да разбера защо това се случва, защото ако на Сървър 2 апаче е пуснат, то Сървър 2 обслужва сайта и си работи без проблеми.

Ще се радвам ако ми дадете някакви идеи и насоки как да реша въпросния проблем.

Ако имате нужда от конфигурациите, мога да ги постна.

Благодаря Ви предварително.

Здравей,

не е добра идея да сменяш главния потребител на апаче в httpd.conf. Ще имаш проблеми със всичко, което се  опитва да пише в директории, които имат сетнати като owner и group апаче потребителя.

Затова е по-добре да оставиш апаче да се пуска с apache, www-data, etc. потребител и ползвай модули като mod_fcgid, mod_suphp, mod_itk, etc., за да си пускаш виртуалните хостове да работят под друг потребител, който ти искаш. Така е най-безопасно и имаш контрал над нещата.

Доколкото до SELinux, ако нямаш познания за него, то е подобре да го пуснеш в permissive mode или да го спреш изцяло, защото ще ти създава проблеми ако контекста на файловете и директориите не е правилен. SELinux на production само за хора, които имат добри познания за него. Поне така си мисля аз.

Надявам се да съм бил полезен.

Здравей,

Така обяснено нищо не става ясно и само ще гадаем.

И изникват въпроси като:
 - Има ли други процеси, които товарят?
 - Какви приложения имаш отворени?
 - Какво правиш като се натоварва?
 - Провери ли логовете?
 - Сигурен ли си, че не страдаш от наскоро открития бъг в ядрото, обяснено тук: http://www.linux-bg.org/cgi-bin/y/index.pl?page=news&key=447072434?

Дай малко повече информация, за да може да помагаме, иначе гадаем и си губим времето със задаване на излишни въпроси

Поздрави :

Изглежда проблема ти е с ключовете/сертификатите или пътищата до тях. Провери си пътищата и имената на файловете, както и какво си задал в конфигурационния файл.

Или както е казал колегата по-горе, задай пълен път.

Здравей,

опиши какво искаш да се получи, какво си направил, какво не работи, дай-конфигурации, логове и после ще помагаме.

Ако искаш всички файлове под дадена директория да бъдат с myuser:http защо просто не направиш?

chown -R myuser:http /path/to/dir

Отделно, за да може да се явиш на техен изпит, може да го направиш в чужбина. Скоро ги питах дали имат център в България, където може да се яви човек, но отговора беше "не".

Да, май така изглежда

Благодаря за отговора.

Здравейте,

ползвам Debian sqeeze и се опитвам да накарам системата да зареди nf_contrack_ftp по време boot. За целта съм добавил следния ред в /etc/modprobe.d/contrack.conf

Код:

options nf_conntrack_ftp ports=21,49152-65534

Знам, че мога да дефинирам ports така и ще работи: ports=21,49152, но не съм сигурен дали мога да задам цял диапазон от портове.

Въпросът ми е дали е възможно да се задава диапазон от портове по начина по който съм го направил или трябва да ползвам друг начин?

Идеята е да се зареди модула, за да обслужва FTP Passive портовете.

Благодаря предварително!

Здравей,

ако се съмняваш в mysql, направи това и виж какво ще излезе като резултат:

Код:

du -chs /var/lib/mysql/*

Друго, което може да направиш е:

Код:

du -chs /*

и така, докато не намериш какво ти заема най-много от диска.