skeletor

Вот, обновил даже php до 5.3.18, но утечки продолжаются. Жду момента, когда будет КВМ и обновлю ядро. Можно и без КВМа, но всё равно стрёмновато.

Делал, но цифры не сходятся всё равно. имеется ввиду, из top/htop. Через /proc/meminfo - MemTotal: 16160948 kB MemFree: 502892 kB Buffers: 178412 kB Cached: 7436540 kB SwapCached: 0 kB Active: 1929572 kB Inactive: 6153940 kB Active(anon): 435528 kB Inactive(anon): 48180 kB Active(file): 1494044 kB Inactive(file): 6105760 kB Unevictable: 7269972 kB Mlocked: 7269972 kB SwapTotal: 33553328 kB SwapFree: 33553328 kB Dirty: 540 kB Writeback: 0 kB AnonPages: 7738528 kB Mapped: 27152 kB Shmem: 832 kB Slab: 196436 kB SReclaimable: 174656 kB SUnreclaim: 21780 kB KernelStack: 2288 kB PageTables: 29200 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 49714276 kB Committed_AS: 8025824 kB VmallocTotal: 34359738367 kB VmallocUsed: 122432 kB VmallocChunk: 34359610132 kB Смущает вот это Unevictable: 7269972 kB Mlocked: 7269972 kB

ps ничего необычного не выводит, top/htop показывает те же цифры, что и до. Даже рестарт указанных служб не освобождает память. Значит, дело скорее всего не в них. Касательно atop - идея хорошая, попробую.

Проблема оказалась в том, что изменения вносились в бинарную базу nsd. А в файлик с зоной - после команды nsdc patch. Я смотрел именно файлик, а вот просто отрезолвить - не делал. Оказалось всё работает, так как в бинарной базе изменения есть. Именно оттуда я взял параметры allow-notify/allow-notify.

Есть сервер Debian 6, ядро 2.6.32-5-amd64 . Параметры сервера CPU (Intel Core i7-3770 CPU @ 3.40GHz 8 ядер), Памяти 16 Гб, 2 Диска в RAID0 (2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (Software-RAID 1)) + swap 32 Gb Другими словами Dedicated Server EX 4 на http://www.hetzner.de На нём поднят nginx+php+mysql. Памяти (потребляется 7гб из 16), процессора и дисков хватает с лихвой. Но где-то через пару дней что-то выедает почти всю память (свободно остаётся где-то 500 мб). А ещё через некоторое время сервер просто уходит в себя: сеть недоступна, Cron-задания невыполняются, то есть наступает полный ступор. Перегрузить через панель управления - не получается. Только через тикет (они сами каким-то ручным образом его перегружают), при этом, в ребут по логам уходит вроде бы корректно. Поддержка в hetzner отвечает стандартными фразами - понятия не имеем, и можем взять сервер на диагностику на сутки. И им по-барабану, что сервер в продакшине. Поставил cacti, думал смогу уловить момент, но LA, mem - не скакали в тот момент. Хотя агент snmp мог это и не уловить. Отключил сейчас все изменения в sysct.conf, limit.conf и пока наблюдаю. Может кто с таким сталкивался? Остался ещё 1 вариант - обновить ядро до версии 3.2, если опять зависнет.

Есть проблемы с обновлением зон на slave: при обновлении зоны на master'e (номер Serial'a естественно увеличиваю при внесении изменений) зоны на slave не обновляются автоматически (после рестарта nsd изменения подтягиваются), при этом на том же сервере поднятый bind нормально подхватывает изменения. То есть дело не в файерволе, а в каких-то опциях автообновлений и автонотификации. QQ.QQ.QQ.QQ - мастер XX.XX.XX.XX; YY.YY.YY.YY; - слейвы Вот часть настроек: named.conf ... notify yes; allow-transfer {XX.XX.XX.XX; YY.YY.YY.YY;}; allow-notify {XX.XX.XX.XX; YY.YY.YY.YY;}; also-notify {XX.XX.XX.XX; YY.YY.YY.YY;}; ... nsd.conf ... zone: name: "domain.ua" zonefile: "domain.ua" allow-notify: QQ.QQ.QQ.QQ NOKEY request-xfr: QQ.QQ.QQ.QQ NOKEY allow-axfr-fallback: "yes" ...

Всем спасибо, разобрался. Код редиректа, приведённый здесь действительно рабочий. Проблема была в том, что хост с сайтом вообще не инклюдился в nginx. Теперь всё работает.

Наблюдаю такую картину: в Firefox'e лишних слешей нет, зато есть в Opera и Chrome. Не знаю с чем может быть связано.

pchol я пробовал, но к сожалению не получилось

Помогло, если добавить в apache такое RewriteEngine On RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC] RewriteRule ^(.*)$ http://domain.com$1 [R=301,L] То есть добавил только в апач. nginx без rewrite'ов. Но есть проблема - оно добавляет лишний слеш в конец, и в итоге становиться так: http://domain.com//menu.php. Как побороть ?

rewrite пока убрал. server { listen XX.XX.XX.XX; server_name domain.com; root /usr/local/www/domain.com; access_log off; location / { try_files $uri @backend; index index.html; } location ~ \.php$ { proxy_pass http://127.0.0.1:8080; proxy_redirect default; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; client_max_body_size 10m; client_body_buffer_size 128k; proxy_send_timeout 180s; proxy_read_timeout 180s; proxy_buffer_size 32k; proxy_buffers 16 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } location @backend { proxy_pass http://127.0.0.1:8080; proxy_redirect default; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; client_max_body_size 10m; client_body_buffer_size 128k; proxy_send_timeout 180s; proxy_read_timeout 180s; proxy_buffer_size 32k; proxy_buffers 16 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/local/www/nginx-dist; }

Нет.

Есть связка nginx+apache. Нужно сделать redirect с www.domain.com на domain.com. Пробовал делать rewrite только на nginx'e - не работает. Добавил ещё и на apache - и получаю зацикливание. Как правильно сделать редирект в моём случае?

Всем спасибо. С помощью проб причина была найдена - MTU. При использовании vlan'ов, MTU становится больше, чем 1500, а свитч не пропускал такие пакеты. Решение - включил jumbo frames и всё стало работать.

Есть такой коммутатор. Настроены вланы: 3 шт (1 для локалки, и 2 для внених каналов инета). Есть сервак (роутер) с одной сетевой и поднятыми вланами на ней так, что он маршрутизирует трафик. Канала инета вставлены в коммутатор. Проблема в следующем - один канал инета работает нормально, а второй - постоянно сбоит (работает, потом через 2 минуты отваливается, потом опять работает и потом опять повторяется). В среднем сбои составляют 50% (если брать промежуток сутки и больше). Если подключить сбоивший канал в обычный комп, то сбоев нету, всё работает. Если подключить другое прмежуточное устройство между копмом и каналом инет, то сбоев тоже нету. Сбои появляются только когда трафик проходит через свитч cisco. Смена номеров вланов, номеров портов, жёсткое прибитие 100FD ни к чему не приводят. При этом второй канал инета работает точно по такой же схеме, но без сбоев. У провайдера порт прибит 100FD, остальные параметры в auto, то есть ничего сверх естественного. На лицо явно проблема свича cisco. Может кто в курсе, что можно ещё покрутить, потюнить?

Никто не хочет платить (я со своего кармана тоже не хочу). Вот такой подход у фирмы.

Мешают деньги :)

Самоподписанный.

Подходит время на expire кореневого сертификата. Как можно безболезненно перегенерировать новый? Дело в том, что клиентов много, и всем заново генерировать новые - не выход. Сертификат используется для доступа к сайту.

Есть 2 сервера за NAT'ом с 1 внешним ИПом. Оба подключаются через authpf. Проблема в том, что активно только 1 соединение с 1-го внешнего ИПа, а второе отбрасывается. Как это исправить?

Всем привет. Есть связка ipfw+ipnat (используется только для NAT). Захотелось ввести ограничения на количество исходящих\входящих подключений в интернет. Собираю такую конструкцию: ipfw add check state ipfw add allow all from 10.10.10.15 to any limit dst-addr 20 ipfw add deny all from 10.10.10.15 to any По счётчикам ipfw show вижу, что правило срабатывает. Так же смотрю ipfw -d show и считаю, сколько динамических правил создалось для 10.10.10.15 и вижу, что их количество превышает 20. Так же смотрю сессии NAT через ipnat -l и тоже их количество превышает 20 для данного ИПа. Делаю заключение, что ограничение может и работает, но неправильно, так как у юзера более 1000 подключений. Поскольку фактически у меня 2 файервола (ipfw и ipfilter), то нужно смотреть ещё и порядок прохождения пакета через файерволы. Нашёл статью http://www.opennet.ru/tips/info/1431.shtml , если верить которой То есть иными словами подключения юзера 10.10.10.15 в инет НАТятся раньше, чем они доходят до правила ipfw add allow all from 10.10.10.15 to any limit dst-addr 20 ? Попробовал по другому (пробовал с in/out и без них): ipfw add check state ipfw add allow all from 10.10.10.15 to any via $int_if limit dst-addr 20 ipfw add deny all from 10.10.10.15 to any но ограничения так и не срабатывают. То есть по идее они хоть как должны сначала пройти через это правило, так как оно написано для внутреннего интерфейса, а потом уже будут НАТится на внешнем. Ещё как вариант - это писать ограничения непосредственно в ipfilter (не тестировал) Подскажите, где я ошибся и как всё-таки заставить работать ограничения? ПС. FreeBSD Release 8.1 amd64 Сейчас этот сервер в работе, поэтому что-то кардинальное смогу сделать только вечером. Заранее спасибо.

Провайдер заблокировал подключение на исход к 25-ому порту, но хочется, что бы сервер всё равно умел слать отчёты (periodic), к примеру подключался к порту 2525 моего почтового сервера. Где можно указать это? Может есть какие-то другие варианты? ПС. ОС FreeBSD.

Спасибо, попробую.

Есть Linux (Debian 5), iptables. Посоветуйте ПО, желательно web, что бы пользователь мог изменять, создавать правила для шейпера. Пользователь продвинутый, но научить пользоваться его tc это нереально, так как про линукс он только слышал. То есть желательно что-то не очень сложное. То есть в идеале, это обвёртка для tc. Заранее спасибо.

Нужно обязательно указывать rdr on, а не просто rdr (появляется ошибка). В этом-то и загвоздка.