Host.Community | hcom.link

Здравствуйте!

Суть проблемы такая:

На сервере debian 7 (x64) установлен IspMgr, с панельки которого были установлены apache2 и nginx

Изначально apache2 висит на 81 порту
Nginx же, висит на 443

И это все на внешнем IP.

Так вот, как заставить работать apache2 на 127.0.0.1:8080 а nginx на 80 и при этом закрыть порт 81 и 443
И так же, когда добавлялись домены в IspMgr виртуальные хосты создаются не совсем корректно.

Конфиг apache2 стандартный как его установил IspMgr:# This is the main Apache server

# Include module configuration:
Include mods-enabled/*.load
Include mods-enabled/*.conf

Здравствуйте!
Подскажите как реализовать редирект, пробовал почему то не получается!
Вот пример, который пробовал:
RewriteRule ^index1.php?id=29 /model_a1_2/ [L,R=301]

и так пробовал:

RewriteRule ^index1.php\?id=29 /model_a1_2 [L,R=301]

Буду очень благодарен, если поможете!

Здравствуйте. Есть 2 сервера. Один в Германии, один в Казахстане. На обоих стоит Debian 7. Раз в 10 минут германский сервер бегает на казахстанский за данными и сохраняет их в Redis. Данные забираются через php + curl.

Все давно уже было настроено и работало, но в последнее время появилась проблема: примерно один раз из трех curl не может подключиться к серверу. Приходит ответ: «curl: (7) couldn't connect to host». При этом казахстанский сервер отлично пингуется как с домашней машины, так и с немецкого сервера. Никаких работ на серверах перед появлением ошибки не проводилось и новые пакеты не ставились, кроме обновлений.

Оба провайдера уверяют, что с их стороны проблем с сетью нет.
Подскажите, в какую сторону копать, чтобы найти причину?

Конфиг nginx-а
upstream backend { server 127.0.0.1:88; } ## # Virtual Host Configs ## server { listen ipaddress:80; server_name domain.kz; access_log /var/log/nginx/domain.access.log; server_name_in_redirect off; location ~ /\.ht { deny all; } location / { proxy_pass backend/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; proxy_connect_timeout 120; proxy_send_timeout 120; proxy_read_timeout 180; } location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|js)$ { root /var/www/domain.kz/www/; } }

Не могу никак решить вопрос настройки данного зверя.
Ubuntu 12.04 x64, nginx-1.4.5.
Конфиги:
nginx.conf
user www-data; worker_processes 2; pid /run/nginx.pid; events { worker_connections 1024; } http { sendfile on; keepalive_timeout 5 5; types_hash_max_size 2048; server_tokens off; limit_conn_zone $binary_remote_addr zone=one:3m; #include /etc/nginx/mime.types; #default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable «msie6»; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; server { if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; } if ($http_user_agent ~* LWP::Simple|BBBike|wget) { return 403; } if ($http_user_agent ~* msnbot|scrapbot) { return 403; } if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) ) { return 403; } limit_conn one 10; location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_ignore_client_abort off; include fastcgi_params; try_files $uri $uri/ $uri/index.php?q=$uri&$args $uri/index.php =405; } } }
конфиг хоста
server { listen 80; server_name site.ru; location / { rewrite ^/(.*)$ https://$host/$1 permanent; } } server { listen 443 ssl; server_name site.ru; client_body_buffer_size 1K; client_header_buffer_size 1k; client_max_body_size 1k; large_client_header_buffers 2 1k; client_body_timeout 10; client_header_timeout 10; keepalive_timeout 5 5; send_timeout 10; if ($host !~ ^(site.ru|www.site.ru)$ ) { return 444; } location / { index index.php index.html index.htm; gzip_static on; root /var/www/site; } location /images/ { valid_referers none blocked www.site.ru site.ru; if ($invalid_referer) { return 403; } } error_page 404 /404.html; location = /404.html { root /var/nginx/html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/nginx/html; } }

Имеется Ubuntu Server 12.10 (крутится на железе Intel Xeon E31235 @ 3.20GHz / 16 Gb RAM), раздающий пользователям интернет через прокси-сервер squid. При включении в конфиге squid'а шейпинга через delay_pools squid нагружает процессор до 100%. При выключенных delay_pools все нормально — загрузка не превышает 10-15% при общей ширине канала в 16 мбит/с, пользователей около 70-90 одновременно в сети.

Версия squid — 3.1.20 (amd64)
Ниже часть конфига:

acl adm src 192.168.2.99/32 acl users src 192.168.0.0/16 delay_pools 2 delay_class 1 1 delay_class 2 3 delay_access 1 allow adm delay_access 1 deny all delay_access 2 allow users delay_access 2 deny all http_access allow users http_access allow adm http_access deny all delay_parameters 1 -1/-1 delay_parameters 2 250000/250000 125000/125000 125000/125000

В чем может быть причина высокой загрузки CPU squid'ом?

Система ArchLinux, имеется минимальный конфиг:
[server@dga-serv ~]$ cat /etc/samba/smb.conf [global] workgroup = WORKGROUP security = user [Pomoika] path = /mnt/p1/ guest ok = yes read only = No

проверяем конфиг:
[server@dga-serv ~]$ testparm -s /etc/samba/smb.conf Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[Pomoika]" Loaded services file OK. Server role: ROLE_STANDALONE [global] idmap config *: backend = tdb [Pomoika] path = /mnt/p1/ read only = No guest ok = Yes

запускаем:
sudo systemctl start smbd nmbd

проверяем:

[server@dga-serv ~]$ ps -ef | grep smbd root 1485 1 0 17:38? 00:00:00 /usr/bin/smbd -D root 1488 1485 0 17:38? 00:00:00 /usr/bin/smbd -D server 1616 1150 0 17:58 pts/0 00:00:00 grep smbd [server@dga-serv ~]$ ps -ef | grep nmbd root 1483 1 0 17:38? 00:00:00 /usr/bin/nmbd -D server 1628 1150 0 17:59 pts/0 00:00:00 grep nmbd Проверяем Samba: [server@dga-serv ~]$ smbclient -L localhost -U% protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED

Пробую ставить на Freebsd 9.1 x32, PHP 5.4.15 (cli).
Ставлю v8 из портов, локейшн по умолчанию.
root@papi:/root # pkg_info v8-3.18.5 -L Information for v8-3.18.5: Files: /usr/local/bin/d8 /usr/local/include/v8.h /usr/local/include/v8-debug.h /usr/local/include/v8-preparser.h /usr/local/include/v8-profiler.h /usr/local/include/v8-testing.h /usr/local/include/v8stdint.h /usr/local/lib/libv8.so /usr/local/lib/libv8.so.1

Ставлю расширение
root@papi:/root # pecl install v8js-0.1.3

Получаю fail
downloading v8js-0.1.3.tar… Starting to download v8js-0.1.3.tar (Unknown size) ..................done: 80,896 bytes 8 source files, building running: phpize Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 Please provide the installation prefix of libv8 [autodetect]: /usr/local building in /tmp/pear/pear-build-root9uQTVr/v8js-0.1.3 running: /tmp/pear/v8js/configure --with-v8js=/usr/local checking for grep that handles long lines and -e… /usr/bin/grep checking for egrep… /usr/bin/grep -E checking for a sed that does not truncate output… /usr/bin/sed checking for cc… cc checking whether the C compiler works… yes checking for C compiler default output file name… a.out checking for suffix of executables… checking whether we are cross compiling… no checking for suffix of object files… o checking whether we are using the GNU C compiler… yes checking whether cc accepts -g… yes checking for cc option to accept ISO C89… none needed checking how to run the C

Дано:
nginx на фронтэнде в качестве балансировщика.
jetty на бэкэнде.

Пользователи должны приходить на sub.domain.ru.
И в строке браузера должно везде оставаться sub.domain.ru.
Однако к jetty уже должны приходить запросы вида domain.ru/sub/

Пока что допёр до такой конфигурации.
Для domain.ru отправляем запрос на прямую на бэкэнд
А для m.domain.ru переписываем поле заголовка Host в domain.ru, а запрос отправляем к бэкэнду переписывая URI как /m/{запрос}
И вроде бы даже все работает. Но дело в том, что в приложении все URL к статике прописаны как /public/mobile. Соответственно при заходе на m.domain.ru они преобразовываются в mobile.ru/m/public/mobile, и сервер их не находит. Написал workaround, но что-то он не работает. Не пойму что я делаю не так.

Может быть есть вообще более изящное решение этой проблемы?

server { listen 80; server_name m.domain.ru; root /path/to/jetty/webapps/; # все запросы к m.domain.ru переписываем отправляем к jetty как localhost:8080/m/, а поле заголовка Host переписываем на domain.ru location / { proxy_pass 127.0.0.1:8080/m$request_uri; proxy_set_header Host domain.ru; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_cache off; proxy_redirect off; } #но делаем исключение для статики location /public/mobile { proxy_pass localhost:8080/; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host domain.ru; proxy_cache off; proxy_redirect off; } } server { listen 80; server_name domain.ru; root /path/to/jetty/webapps/; location / { proxy_pass localhost:8080/; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_cache off; proxy_redirect off; } }

Имеется сервер на FreeBSD 8.0 с Apache 2.2.23, PHP 5.4.10 и nginx 1.2.6. Соответственно, сначала стоит nginx, за ним Apache. Проблема в том, что стабильно раз в несколько дней падает Apache после ротации логов. Ротация логов выполняется с помощью logrotate с примерно таким конфигом:
"/usr/home/mysite/logs/*.log" "/var/log/*-error.log" "/var/log/*-access.log" { su root www daily rotate 7 compress ifempty missingok nomail prerotate /usr/local/www/awstats/tools/awstats_updateall.pl now -awstatsprog=/usr/local/www/awstats/cgi-bin/awstats.pl endscript postrotate /usr/bin/killall -HUP httpd endscript sharedscripts }

После ротации в старом error.log:
[Mon May 13 00:01:03 2013] [notice] SIGHUP received. Attempting to restart

В новом:
[Mon May 13 00:01:03 2013] [notice] Digest: generating secret for digest authentication… [Mon May 13 00:01:03 2013] [notice] Digest: done [Mon May 13 00:01:05 2013] [notice] Apache/2.2.23 (FreeBSD) PHP/5.4.10 configured — resuming normal operations [Mon May 13 00:01:06 2013] [notice] child pid 88614 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:01:06 2013] [notice] child pid 88613 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:01:06 2013] [notice] child pid 88612 exit signal Segmentation fault (11), possible coredump in /usr/local… [Mon May 13 00:02:48 2013] [notice] child pid 88818 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:49 2013] [notice] child pid 88884 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:49 2013] [notice] child pid 88883 exit signal Segmentation fault (11), possible coredump in /usr/local [Mon May 13 00:02:50 2013] [notice] caught SIGTERM, shutting down

В /usr/local/ создается файл httpd.core весом около 16 мегабайт.

Если после этого просто запустить Apache — он начинает дико жрать оперативку и проц. Если перезагрузить весь сервер — все работает нормально.

Как это можно исправить? Куда вообще копать?

Здравствуйте, коллеги и товарищи.

Имеем веб-сервер на CentOS 6.3 для хостинга ряда сайтов на Drupal (в основном, седьмой версии), куда накатан традиционный LAMP + nginx в роли обратного прокси. В качестве прекомпилера для PHP использовался APC. На сервере порядка 100 живых сайтов, высокой нагрузки — нет.

Большинство сайтов на веб-сервере появилось недавно, до этого было 5-6 сайтов и всё работало хорошо (с тем же самым APC). Но когда пришло много сайтов (при этом все новички — слабые, по 100 хостов в сутки) мы начали замечать периодические тормоза: один и тот же сайт загружался то нормально, то с затупом (и однозначно затуп воспроизвести не удавалось). Но когда сайты начали выстреливать нотисами типа Unable to allocate memory for pool… — виноватого нашли, им оказался APC (т.е., наверное, не он сам, а наши несовершенные дефолтные конфиги, но тем не менее).

Ситуация развивалась вот так: