Всё, спасибо, понял.
Извините что вероятно вас оскорбил, или вы так подумали что я этого хотел.
А вы не разу не гуглили пока отвечали? Всегда бывают сомнения особенно если они появляются от других. Если что, у меня тоже были поводы не писать про string, чтобы не исключать другие возможные варианты решения задачи. А вы же сразу написали что таких возможностей в iptables нет, ещё непонятно кто больше гуглит из нас.
В результате знаете что получается, вы подробно узнали о задаче, и попытались помочь найти решение, показали как вы умеете делать запросы почтовым серверам. Правда я действительно не узнал ничего нового, но всё равно спасибо Вам.
PS> я не согласен что проблема алогична, просто решение её очень сложное или практически невозможное.
bugsmoran
iowait прыгает, и без скачки бекапов он конечно меньше, при скачивании прагает до 40%.
на единичку я могу нажать, но суть в том что этот скачёк как правило при начале скачивания и всего пару минут, но систему ложит...
Лучше прочитать первый пост...
Почему нагружен диск где система, в то время как начинается скачивание с другого диска sdb?
Нам приходит только если пропускаем, проверьте может в спам идут нужные письма.
Andreyka мы вообще не о том, и не поймёте, вы видимо не разрешаете запуск демонов, а соответственно левых MTA серверов, и наконец соответственно у вас небыло таких случаев никогда. И если что, спаму у меня нет, вопрос в другом.
bugsmoran, да я именно об этом, -m string, странно что вы об этом не знали, много где используется. Вот только сработает ли ваш пример? указанная вами строка это ответ маил сервера, нам это мало что даст, фильтр по исходящему соединению, и поэтому нужно смотреть на
AUTH LOGIN
или модуль string всё фильтрирует что происходит между клиентами в оба направления?
php от разных пользователей.
Дак именно это и нужно, для php он должен быть только
Сервер1 PHP => Сервер2 MSA ->Сервер2 MTA.
КОРОЧЕ, наверное надо забить и пусть юзают локальный MTA, крыша едет уже)
Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 955431692 90919056 815979492 11% / tmpfs 4095576 0 4095576 0% /lib/init/rw proc 0 0 0 - /proc sysfs 0 0 0 - /sys udev 4090644 140 4090504 1% /dev tmpfs 4095576 0 4095576 0% /dev/shm devpts 0 0 0 - /dev/pts /dev/sda2 91159 15144 71151 18% /boot /dev/sda6 1967440 35888 1831612 2% /tmp /dev/sdb1 961432072 290984744 621609328 32% /backups
tmp разделом, хотя обычно на других серверах у меня просто папкой.
Мои действия, очистил свап полностью, LA упал до 1, включаю выкачивание бекапа, нагрузки как ранее не поступило, LA прыгнул до 12 максимум:
top - 15:06:44 up 214 days, 1:08, 2 users, load average: 12.49, 4.83, 3.11 Tasks: 394 total, 1 running, 393 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 4.6%sy, 10.7%ni, 57.0%id, 21.2%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 8191156k total, 7587896k used, 603260k free, 213216k buffers Swap: 3998712k total, 2952k used, 3995760k free, 5517564k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ UID COMMAND 12240 mysql 20 0 1615m 927m 4544 S 54 11.6 7046:08 107 mysqld 7924 www 20 0 44116 15m 1512 D 1 0.2 3:36.00 1001 nginx 7925 www 20 0 44380 16m 1504 D 1 0.2 3:51.72 1001 nginx 7923 www 20 0 44380 16m 1492 S 1 0.2 3:34.29 1001 nginx 7926 www 20 0 44380 16m 1572 D 1 0.2 3:43.47 1001 nginx 10537 root 20 0 19340 1656 1032 R 1 0.0 0:02.79 0 top 7191 root 20 0 653m 11m 656 S 0 0.1 0:00.23 0 apache2 22570 root 20 0 653m 11m 652 S 0 0.1 0:00.05 0 apache2 23267 backups 20 0 190m 3684 1876 S 0 0.0 0:00.75 1002 proftpd 28363 power 30 10 656m 18m 5016 D 0 0.2 0:00.01 1005 apache2 1 root 20 0 8356 668 552 S 0 0.0 1:48.76 0 init 2 root 20 0 0 0 0 S 0 0.0 0:00.01 0 kthreadd 3 root RT 0 0 0 0 S 0 0.0 0:50.08 0 migration/0
Ниже atop, тут меня смущает иногда появляющщийся красный параметр:
PAG | scan 6842 | stall 0 | | swin 1 | swout 0 |
нагрузка на sda от обычной до 50%, стала прыгать до 100%, но опятьже не всегда...
ATOP - s10 2012/09/23 15:08:04 3 seconds elapsed PRC | sys 0.65s | user 2.04s | #proc 397 | #zombie 0 | #exit 47 | CPU | sys 27% | user 74% | irq 1% | idle 578% | wait 122% | cpu | sys 7% | user 21% | irq 0% | idle 48% | cpu000 w 25% | cpu | sys 5% | user 13% | irq 0% | idle 23% | cpu004 w 58% | cpu | sys 3% | user 13% | irq 1% | idle 59% | cpu005 w 24% | cpu | sys 3% | user 11% | irq 0% | idle 81% | cpu001 w 5% | cpu | sys 2% | user 3% | irq 0% | idle 89% | cpu003 w 6% | cpu | sys 3% | user 7% | irq 0% | idle 90% | cpu002 w 0% | cpu | sys 2% | user 3% | irq 0% | idle 95% | cpu006 w 0% | cpu | sys 1% | user 1% | irq 0% | idle 94% | cpu007 w 3% | CPL | avg1 8.95 | avg5 5.39 | avg15 3.43 | csw 5165 | intr 7354 | MEM | tot 7.8G | free 241.0M | cache 5.7G | buff 207.0M | slab 301.4M | SWP | tot 3.8G | free 3.8G | | vmcom 6.5G | vmlim 7.7G | DSK | sda | busy 83% | read 235 | write 26 | avio 9 ms | DSK | sdb | busy 6% | read 138 | write 0 | avio 1 ms | NET | transport | tcpi 2600 | tcpo 2298 | udpi 8 | udpo 8 | NET | network | ipi 2627 | ipo 2394 | ipfrw 0 | deliv 2610 | NET | eth0 64% | pcki 2135 | pcko 16441 | si 728 Kbps | so 64 Mbps | NET | lo ---- | pcki 530 | pcko 530 | si 4900 Kbps | so 4900 Kbps | PID RDDSK WRDSK WRDSK_CANCEL DSK CMD 1/10 23267 18816K 0K 0K 64% proftpd 12240 796K 7976K 7920K 30% mysqld 17972 0K 880K 0K 3% php 1724 268K 64K 0K 1% cron 7925 72K 68K 0K 0% nginx 7923 124K 16K 0K 0% nginx
В iotop ничего необычного, наверху либо база либо журнал.
Total DISK READ: 374.25 K/s | Total DISK WRITE: 793.81 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 333 be/3 root 0.00 B/s 70.91 K/s 0.00 % 47.19 % [jbd2/sda3-8] 31073 be/4 mysql 256.07 K/s 19.70 K/s 0.00 % 9.13 % mysqld --basedir=/usr --datadir=/v~/run/mysqld/mysqld.sock --port=3306 668 be/4 mysql 35.46 K/s 2017.02 B/s 0.00 % 5.93 % mysqld --basedir=/usr --datadir=/v~/run/mysqld/mysqld.sock --port=3306 7923 be/4 www 7.88 K/s 23.64 K/s 0.00 % 5.39 % nginx: worker process 32291 be/6 power 0.00 B/s 7.88 K/s 0.00 % 2.46 % apache2 -k start 7925 be/4 www 27.58 K/s 29.55 K/s 0.00 % 2.37 % nginx: worker process 32046 be/4 mysql 11.82 K/s 0.00 B/s 0.00 % 1.55 % mysqld --basedir=/usr --datadir=/v~/run/mysqld/mysqld.sock --port=3306 7924 be/4 www 7.88 K/s 9.85 K/s 0.00 % 1.21 % nginx: worker process
Свап так и не заюзался, с ним думаю было бы всё хуже.
Надеюсь теперь танцы с бубном станут более понятными 😂
Но не для меня..
Logger я подумал над правилами, они идентичны моим, да, спаму нет как и у меня сейчас, но проблема описанная мной в первом сообщении никак добавлением server_ip не решается...
bugsmoran, да, вы всё верно пишите, и я это на удивление процентов на 95% это всё и так знаю))
Могу ответить на ваши вопросы.
a) Всё просто, куча клиентов, у некоторых скрипты которые используют отправку писем с авторизацией на стороннем почтовике, mail.ru и т.д. И почему то в этих скрпитах не предусмотрена отправка письма с помощью простейшего mail().
Только для этой цели и требуется.
б) тут нет причин разбираться, возможно вы правы, и достаточно будет запрещать только 25й порт(для тупых скрпитов), а 587 оставить открытым для всех и всях) Но я не могу так рисковать! Не исключено что отправка неавторизованного спама будет также и через 587 порт и возможно даже через 465.
Например у меня, без лишнего головняка так настроено (никаких отличий), и я думаю это у большинства так)
daemon_smtp_ports = 25 : 587 : 465
tls_on_connect_ports = 465
Ещё раз всё проанализировав, я понимаю что вероятно единственное решение это фильтровать все пакеты через iptables и при наличии удачной авторизации пропускать далее, или это уже перебор?)
+1, все панели глючные и недоработанные для эфективного безбажного использования, сколько бы они не стоили.
Логи ротируются, файлики новые открываются, поэтому не может лежать на битых секторах, здоровье по смарту нормальное, но мысль была уже просто сменить сервер.
Также сейчас подозрение на то что proftpd при начале отдачи большого архивчика, пытается не малую часть засунуть в память, память и так всегда почти занята, отсюда вероятно идёт в swap. Сейчас пробовал, вроде как скушало дополнительные 200мб, опять же кто скушал не понять, может это апачи которые подвисли в ожидании и им потребовалось больше памяти... вообще лажа полная и проблема эта уже около года надоедает 😒
Там правила такие же как у меня, только добавлены условия -s server-ip -d ! server-ip
Надо подумать может ли это решить проблему не навредив, пока на вскидку кажется что нет. ---------- Добавлено 23.09.2012 в 13:23 ---------- bugsmoran у меня запрещены все порты, 25, 465, 587 ...
Historically, port 25 has acted as both an MTA and MSA port in sendmail
Также возможно и обратное, или вы уверены что 587 это только MSA и для MSA он всегда используется?
Собственно читайте: http://en.wikipedia.org/wiki/Mail_submission_agent
Нет, вы не правы, со спамом я борюсь на 5+, локального исходящего спама нет, отсекается перл скриптами, лимитами и уведомлениями. (99% случаев без моего участия) А вот если у вас не было исходящего спама от какого нибуть готового запущенного MTA-скрипта демона который шифруется под exim, то вам очень повезло, либо вы пока не так много встречали хакнутых сайтов и зловредителей. 🍿 Там где я работаю, также полно клиентов которые сами загружают и запускают подобные красивые штуки :) Моя задача полностью автоматизировать решение всевозможных проблем на вебсервере, чтобы сис-админы вообще не требовались. Вопрос в силе...
