$ sudo vim /etc/nginx/nginx.conf
И внутрь блока http{} (допустим, под: access_log) добавляем:
client_max_body_size 50m;
И перезапускаем Nginx:
$ sudo service nginx restart
Правила iptables применяются сразу же после выполнения.
К примеру, если в терминале ввести:
$ iptables -A INPUT -p TCP --dport 22 -j DROP
то соединение по ssh сразу будет потеряно.
Создадим скрипт, который будет очищать все правила iptables:
# vim /etc/restore_iptables.sh #!/bin/sh IPT="/sbin/iptables" # Удаляем все правила $IPT -F $IPT -X # Разрешаем все подключения $IPT -P INPUT ACCEPT $IPT -P FORWARD ACCEPT $IPT -P OUTPUT ACCEPT
Также нужно сделать скрипт исполняемым:
# chmod +x /etc/restore_iptables.sh
В случае потери доступа к удаленному хосту в результате неправильной настройки iptables, мы восстановим рабочую конфигурацию из файла /etc/restore_iptables.sh, сбросив новые настройки к заведомо рабочим. Для этого добавим в cron периодический запуск /etc/restore_iptables.sh
crontab -e
# Сбрасывать iptables к рабочим настройкам каждые 5 минут
*/5 * * * * /etc/restore_iptables.sh
http://www.natalink.ru/articles/nastroyka_iptables_na_udalennom_hoste
Во процессе обслуживания высокого количества соединений (высокая нагрузка), в логе ошибок Вашего сервера могут появляться записи 24: Too Many Open Files. Происходит это потому что сервер nginx пытается открыть больше файловых дескрипторов чем ему позволено. Ограничение может быть наложено конфигурацией nginx сервера или конфигурацией операционной системы. На каждое соединение nginx открывает как минимум два дескриптора, один для соединения, второй для передаваемого файла.
Для выяснение причин проведем короткую диагностику. Прежде всего посмотрим конфигурационный файл nginx, обычно он расположен в
/etc/nginx/nginx.conf
Нас интерисуют следующие строки
user [xxx];
worker_processes [x];
worker_rlimit_nofile [xxx];
events {
worker_connections [xxxx];
}
user — от имени какого пользователя nginx работает в системе, нам необходимо будет проверить лимиты для данного пользователя.
worker_processes — кол-во процессов nginx работающих при запуске демона, так как лимит операционной системы общий для всех процессов, соответственно нам надо будет устанавливать лимиты исходя из кол-ва процессов.
worker_rlimit_nofile — максимальное кол-во файловых дескрипторов на один процесс.
worker_connections (может присутствовать только в контексте events) — максимальное кол-во соединений на один процесс.
Далее выясним лимиты установленные операционной системой, для этого перейдем под пользователя nginx
su nginx
Если получаем от OS сообщение вида
This account is currently not available.
Значит в файле /etc/passwd для нашего пользователя указана оболочка запрещающая вход в систему и работу с консолью, например /sbin/nologin
Отредактируем файл /etc/passwd, заменим строку
nginx:x:500:500:nginx user:/var/cache/nginx:/sbin/nologin
на строку
nginx:x:500:500:nginx user:/var/cache/nginx:/bin/bash
и вновь выполним su nginx.
Теперь посмотрим лимиты:
ulimit -Hn ulimit -Sn
-Hn — жесткий лимит максимального кол-ва открытых файловых дискрипторов
-Sn — мягкий лимит максимального кол-ва открытых файловых дискрипторов
Отличие между жестким и мягким лимитами в том, что жесткий может быть установлен только root пользователем, а мягкий может быть установлен пользователем на которого наложен лимит, но не больше чем жесткий лимит.
Теперь мы знаем текущие ограничения OS наложенные на пользователя nginx, можно выйти из под su
exit
Посмотрим глобальное ограничение на количество дескрипторов, для этого выполним команду
sysctl fs.file-max
Итак мы значем все ограничения, теперь попробуем сделать так чтобы наш nginx получил возможность открывать столько дескрипторов, сколько ему нужно.
Посчитаем сколько нам нужно дескрипторов для nginx
(worker_connections * 4 * worker_processes) + 100 = примерно нужное кол-во дескрипторов
Соответственно для будущего расширения это значение можно умножить еще на два и задавать лимиты.
Например, (1024 * 4 * 2) + 100 = 8292
Значение не большое, можно его свободно увеличить до 25000
Устанавливаем глобальные лимиты операционной системы, в файле /etc/sysctl.conf прописываем или изменяем строку:
fs.file-max = 203463
Устанавливаем лимиты на пользователя, в файле /etc/security/limits.conf прописываем или изменяем строки:
nginx soft nofile 25000 nginx hard nofile 50000
Применяем установленные лимиты к системе
sysctl -p
Проверяем что все применилось
sysctl fs.file-max
su nginx
ulimit -Hn
ulimit -Sn
exit
Устанавливаем лимиты для nginx
worker_rlimit_nofile 12500
Перезагружаем конфигурацию nginx
nginx -s reload
Ошибка более не должна повторяться.
Возвращаем shell для nginx в файле /etc/passwd в исходное состояние
nginx:x:500:500:nginx user:/var/cache/nginx:/sbin/nologin
https://devmems.wordpress.com/tag/nginx/
Имеем два жестких диска: /dev/sda и /dev/sdb. Из них созданы четыре программных RAID-массива:
/dev/sda1 + /dev/sdb1 - swap /dev/sda5 + /dev/sdb5 /dev/md126 - /boot /dev/sda2 + /dev/sdb2 /dev/md127 - / /dev/sda1 + /dev/sdb1 /dev/md125 - /home /dev/sda6 + /dev/sdb6 /dev/md124 - /var/www
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sdb6[1] sda6[0] 13590528 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sda1[0] sdb1[1] 26213376 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sda5[0] sdb5[1] 1047552 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sdb2[1] sda2[0] 10484736 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk
[root@cen753 svm]# ls -l /dev/sd* brw-rw----. 1 root disk 8, 0 Июн 17 13:40 /dev/sda brw-rw----. 1 root disk 8, 1 Июн 17 13:40 /dev/sda1 brw-rw----. 1 root disk 8, 2 Июн 17 13:40 /dev/sda2 brw-rw----. 1 root disk 8, 3 Июн 17 13:40 /dev/sda3 brw-rw----. 1 root disk 8, 4 Июн 17 13:40 /dev/sda4 brw-rw----. 1 root disk 8, 5 Июн 17 13:40 /dev/sda5 brw-rw----. 1 root disk 8, 6 Июн 17 13:40 /dev/sda6 brw-rw----. 1 root disk 8, 16 Июн 17 13:40 /dev/sdb brw-rw----. 1 root disk 8, 17 Июн 17 13:40 /dev/sdb1 brw-rw----. 1 root disk 8, 18 Июн 17 13:40 /dev/sdb2 brw-rw----. 1 root disk 8, 19 Июн 17 13:40 /dev/sdb3 brw-rw----. 1 root disk 8, 20 Июн 17 13:40 /dev/sdb4 brw-rw----. 1 root disk 8, 21 Июн 17 13:40 /dev/sdb5 brw-rw----. 1 root disk 8, 22 Июн 17 13:40 /dev/sdb6
[root@cen753 svm]# df -h Файловая система Размер Использовано Дост Использовано% Cмонтировано в /dev/md127 10G 1,1G 8,9G 11% / devtmpfs 484M 0 484M 0% /dev tmpfs 496M 0 496M 0% /dev/shm tmpfs 496M 6,8M 490M 2% /run tmpfs 496M 0 496M 0% /sys/fs/cgroup /dev/md126 1020M 160M 861M 16% /boot /dev/md124 13G 33M 13G 1% /var/www /dev/md125 25G 33M 25G 1% /home tmpfs 100M 0 100M 0% /run/user/1000 tmpfs 100M 0 100M 0% /run/user/0
[root@cen753 svm]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 50G 0 disk +-sda1 8:1 0 25G 0 part ¦ L-md125 9:125 0 25G 0 raid1 /home +-sda2 8:2 0 10G 0 part ¦ L-md127 9:127 0 10G 0 raid1 / +-sda3 8:3 0 1G 0 part ¦ L-centos-swap 253:0 0 2G 0 lvm [SWAP] +-sda4 8:4 0 1K 0 part +-sda5 8:5 0 1G 0 part ¦ L-md126 9:126 0 1023M 0 raid1 /boot L-sda6 8:6 0 13G 0 part L-md124 9:124 0 13G 0 raid1 /var/www sdb 8:16 0 50G 0 disk +-sdb1 8:17 0 25G 0 part ¦ L-md125 9:125 0 25G 0 raid1 /home +-sdb2 8:18 0 10G 0 part ¦ L-md127 9:127 0 10G 0 raid1 / +-sdb3 8:19 0 1G 0 part ¦ L-centos-swap 253:0 0 2G 0 lvm [SWAP] +-sdb4 8:20 0 1K 0 part +-sdb5 8:21 0 1G 0 part ¦ L-md126 9:126 0 1023M 0 raid1 /boot L-sdb6 8:22 0 13G 0 part L-md124 9:124 0 13G 0 raid1 /var/www sr0 11:0 1 1024M 0 rom
Пробуем удалить – не дает:
[root@cen753 svm]# mdadm /dev/md124 -r /dev/sdb6 mdadm: hot remove failed for /dev/sdb6: Device or resource busy
Помечаем раздел как сбойный, а потом удаляем из массива – получается:
[root@cen753 svm]# mdadm /dev/md124 -f /dev/sdb6 mdadm: set /dev/sdb6 faulty in /dev/md124
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sdb6[1](F) sda6[0] 13590528 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sda1[0] sdb1[1] 26213376 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sda5[0] sdb5[1] 1047552 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sdb2[1] sda2[0] 10484736 blocks super 1.2 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Повторяем для остальных разделов:
[root@cen753 svm]# mdadm /dev/md125 -f /dev/sdb1 mdadm: set /dev/sdb1 faulty in /dev/md125
[root@cen753 svm]# mdadm /dev/md126 -f /dev/sdb5 mdadm: set /dev/sdb5 faulty in /dev/md126
[root@cen753 svm]# mdadm /dev/md127 -f /dev/sdb2 mdadm: set /dev/sdb2 faulty in /dev/md127
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sdb6[1](F) sda6[0] 13590528 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sda1[0] sdb1[1](F) 26213376 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sda5[0] sdb5[1](F) 1047552 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sdb2[1](F) sda2[0] 10484736 blocks super 1.2 [2/1] [U_] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Удаляем оставшиеся разделы:
[root@cen753 svm]# mdadm /dev/md124 -r /dev/sdb6 mdadm: hot removed /dev/sdb6 from /dev/md124
[root@cen753 svm]# mdadm /dev/md125 -r /dev/sdb1 mdadm: hot removed /dev/sdb1 from /dev/md125
[root@cen753 svm]# mdadm /dev/md126 -r /dev/sdb5 mdadm: hot removed /dev/sdb5 from /dev/md126
[root@cen753 svm]# mdadm /dev/md127 -r /dev/sdb2 mdadm: hot removed /dev/sdb2 from /dev/md127
Смотрим:
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sda6[0] 13590528 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sda1[0] 26213376 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sda5[0] 1047552 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sda2[0] 10484736 blocks super 1.2 [2/1] [U_] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Смотрим таблицу разделов:
[root@cen753 svm]# parted -l Модель: ATA VBOX HARDDISK (scsi) Диск /dev/sda: 53,7GB Размер сектора (логич./физич.): 512B/512B Таблица разделов: msdos ....
Или сразу устройство:
[root@cen753 svm]# parted /dev/sda print Модель: ATA VBOX HARDDISK (scsi) Диск /dev/sda: 53,7GB Размер сектора (логич./физич.): 512B/512B Таблица разделов: msdos
Оба диска в массиве должны иметь абсолютно одинаковое разбиение. В зависимости от используемого типа таблицы разделов (MBR или GPT) необходимо использовать соответствующие утилиты для копирования таблицы разделов.
Для жесткого диска с MBR используем утилиту sfdisk:
# sfdisk -d /dev/sda | sfdisk --force /dev/sdb
где /dev/sda – диск источник, /dev/sdb – диск назначения.
Для жесткого диска с GPT используем утилиту sgdisk из GPT fdisk:
# sgdisk -R /dev/sdb /dev/sda # sgdisk -G /dev/sdb
где /dev/sda – диск источник, /dev/sdb – диск назначения. Вторая строка назначает новому жесткому диску случайный UUID.
Добавляем новый, размеченный жесткий диск в массивы и установить на нем загрузчик:
[root@cen753 svm]# mdadm /dev/md124 -a /dev/sdb6 mdadm: re-added /dev/sdb1
[root@cen753 svm]# mdadm /dev/md125 -a /dev/sdb1 mdadm: re-added /dev/sdb1
[root@cen753 svm]# mdadm /dev/md126 -a /dev/sdb5 mdadm: re-added /dev/sdb5
[root@cen753 svm]# mdadm /dev/md127 -a /dev/sdb2 mdadm: re-added /dev/sdb2
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sdb6[1] sda6[0] 13590528 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sdb1[1] sda1[0] 26213376 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sdb5[1] sda5[0] 1047552 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sdb2[1] sda2[0] 10484736 blocks super 1.2 [2/1] [U_] [>....................] recovery = 0.9% (102720/10484736) finish=6.7min speed=25680K/sec bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Проверяем:
[root@cen753 svm]# cat /proc/mdstat Personalities : [raid1] md124 : active raid1 sdb6[1] sda6[0] 13590528 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md125 : active raid1 sdb1[1] sda1[0] 26213376 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md126 : active raid1 sdb5[1] sda5[0] 1047552 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md127 : active raid1 sdb2[1] sda2[0] 10484736 blocks super 1.2 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none>
Если в системе используется загрузчик GRUB2 достаточно выполнить следующие команды (при этом нет необходимости дожидаться окончания процесса синхронизации):
# grub-install /dev/sdb # update-grub
http://www.sysadmin.in.ua/info/index/21/24/28
http://avreg.net/howto_software-raid-replacing-faulty-drive.html
http://avreg.net/howto_software-raid-remove.html
Cacti — open-source веб-приложение, система позволяет строить графики при помощи RRDtool. Cacti собирает статистические данные за определённые временные интервалы и позволяет отобразить их в графическом виде. Преимущественно используются стандартные шаблоны для отображения статистики по загрузке процессора, выделению оперативной памяти, количеству запущенных процессов, использованию входящего/исходящего трафика.
# yum update -y
# yum install cacti
Проверяем есть ли в системе пакет mysql-server/mariadb выполнив команду:
# rpm -q mariadb
Если нет – доустанавливаем
# mysql -u root -p MariaDB [(none)]> create database cacti; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> use cacti; Database changed MariaDB [cacti]> show tables; Empty set (0.00 sec) [root@cen752 svm]# mysql -u root -p < /usr/share/doc/cacti-1.1.37/cacti.sql
Если возникает ошибка вида:
ERROR 1046 (3D000) at line 12: No database selected
Правим файл добавляя в начало use cacti;
[root@cen752 svm]# nano /usr/share/doc/cacti-1.1.37/cacti.sql
Повторяем:
[root@cen752 svm]# mysql -u root -p < /usr/share/doc/cacti-1.1.37/cacti.sql
и проверяем:
MariaDB [cacti]> show tables;
Необходимо дать права на созданную БД пользователю, под которым cacti будет подключаться к серверу:
MariaDB [cacti]> grant all on cacti.* to cacti@localhost identified by 'pa33word111'; Query OK, 0 rows affected (0.07 sec) MariaDB [cacti]> flush privileges; Query OK, 0 rows affected (0.01 sec)
Правим конфигурационный файл:
cp /etc/cacti/db.php /etc/cacti/db.php_orig nano /etc/cacti/db.php /* make sure these values reflect your actual database/host/user/password */ $database_type = 'mysql'; $database_default = 'cacti'; $database_hostname = 'localhost'; $database_username = 'cacti'; $database_password = 'pa33word111'; $database_port = '3306'; $database_ssl = false;
Создадим для cron задачу:
echo "*/5 * * * * cacti /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1" >> /etc/cron.d/cacti
Создаем файлы логов:
mkdir /var/www/cacti && mkdir /var/www/cacti/log
touch /var/www/cacti/log/{access.log,error.log}
https://voipnotes.ru/install-cacti-on-centos-7/
Обновляем порты:
# portsnap fetch update
Устанавливаем и добавляем в автозагрузку:
# portmaster mail/postgrey # echo 'postgrey_enable="YES"' >> /etc/rc.conf
Стартуем и проверям:
# service postgrey start # service postgrey status
Редактируем конфигурационный файл Postfix, вставляя в секции smtpd_recipient_restrictions после параметра reject_unauth_destination:
# ee /usr/local/etc/postfix/main.cf
.....
smtpd_recipient_restrictions =
check_client_access hash:/usr/local/etc/postfix/blacklist-IP
permit_mynetworks
permit_sasl_authenticated
check_recipient_access hash:/usr/local/etc/postfix/recipient-list
reject_non_fqdn_recipient
reject_unauth_destination
check_policy_service inet:127.0.0.1:10023
reject_unknown_recipient_domain
reject_unverified_recipient
permit
.....
Перезапускаем Postfix:
# service postfix restart
Отправляем себе письмо и смотрим в логах примерно такой вывод:
...: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/tst-amo.net.ua.html (in reply to RCPT TO command))
In postgrey its possible to whitelist senders as well as recipients. All that needs doing in order to whitelist a host is to add its fully qualified domain name or its ip address to the /etc/postfix/postgrey_whitelist_clients.local file. eg:
192.168.1.10 mydesktop.office.mydomain.com
Now all email recieved from either 192.168.1.10 or mydesktop.office.mydomain.com will not be greylisted, it will be accepted immediately ( as long as its valid, and passes all postfix rules ). On the other hand if you want to whitelist a recipient you can add their username part of the email address to the /etc/postfix/postgrey_whitelist_recipients file. eg:
postmaster@ abuse@ theboss@
Now all emails being received for any of these email address’ wont be greylisted, and all email will be accepted right away. Note that postgrey already comes with whitelist setup for postmaster and abuse.
Postgrey includes a reporting tool call postgreyreport. Its installed by default when you install the postgrey rpm. Postgreyreport will parse a maillog ( read from STDIN ), compare it with the postgrey db and output details on all ‘fatal’ greylist entries. A host is considered to be ‘fatally’ greylisted when it does not retry within 300 seconds from its first attempt at email delivery for a specific destination. Postgreyreport uses the complete triple as a candidate. You can tune this delay of 300 seconds using the command line option –delay, however 300 is a good benchmark. Most mail servers will retry within 300 seconds.
Basic usage :
cat /var/log/maillog | postgreyreport --delay=300
Depending on how busy your server is, the report can get quite large. To get only the top 20 sources getting greylisted out – you can use something like this :
cat /var/log/maillog | postgreyreport | awk '{print $1}' | sort | uniq -c | sort -nr | head -n20
To get a list of the top 20 email address that the greylisted sources are sending email to :
cat /var/log/maillog | postgreyreport | awk '{print $4}' | sort | uniq -c | sort -nr | head -n20
To get a list of all options that postgreyreport supports and their functions:
postgreyreport -h
http://muff.kiev.ua/content/postgrey-serye-spiski-dlya-postfix
https://wiki.centos.org/HowTos/postgrey
Ошибка при импорте в БД.
php.ini
Find:
post_max_size = 8M upload_max_filesize = 2M max_execution_time = 30 max_input_time = 60 memory_limit = 8M
Change to:
post_max_size = 750M upload_max_filesize = 750M max_execution_time = 5000 max_input_time = 5000 memory_limit = 1000M
my.cnf (MySQL File)
Under mysqld add:
max_allowed_packet = 500M wait_timeout = 300
https://dba.stackexchange.com/questions/121032/phpmyadmin-import-error-mysql-server-has-gone-away-unrecognized-keyword
https://forum.sys-adm.in/index.php?topic=4204.0
1. Небуферизированная память. Обычная память для обычных настольных компьютеров, её ещё называют UDIMM. На планке памяти как правило имеется 2, 4, 8 или 16 микросхем памяти с одной или двух сторон. У такой памяти маркировка обычно заканчивается буквой U (Unbuffered) или вообще без буквы, например DDR2 PC-6400, DDR2 PC-6400U, DDR3 PC-8500U или DDR3 PC-10600. А у памяти для ноутбуков маркировка заканчивается буквой S, видимо это сокращение от SO-DIMM, например DDR2 PC-6400S. Фото небуферизированной памяти можно видеть ниже.
2. Память c коррекцией ошибок (Память с ECC). Обычная Небуферизованная память с коррекцией ошибок. Такая память ставится обычно в фирменные (брендовые) компьютеры продаваемые в Европе (НЕ СЕРВЕРА), плюсом этой памяти является её большая надёжность при работе. Большинство ошибок при работе памяти удаётся исправить во время работы, даже если они появляются, не теряя данные. Обычно на каждой планке такой памяти 9 или 18 микросхем памяти, добавляется одна или 2 микросхемы. Большинство обычных компьютеров (не серверов) и материнских плат могут работать с ECC памятью. У такой памяти маркировка как правило заканчивается буквой E (ECC), например DDR2 PC-4200E, DDR2 PC-6400E, DDR3 PC-8500E или DDR3 PC-10600E. Фото небуферизированной памяти c ECC можно видеть ниже.
Различие памяти с ECC и памяти без ECC можно видеть на фото:
Хоть большинство продаваемых плат и поддерживают эту память, но совместимость с конкретной платой и процессором лучше узнать заранее до покупки. Из личного опыта 90-95% материнских плат и процессоров могут работать с памятью ECC. Из тех, что НЕ могут работать: платы на чипсетах Intel G31, Intel G33, Intel G41, Intel G43, Intel 865PE. Все материнские платы и процессоры начиная с первого поколения Intel Core все могут работать с ECC памятью и от материнских плат это не зависит. Под AMD процессоры вообще практически все материнские платы могут работать с ECC памятью, за исключением случаев индивидуальной несовместимости (такое бывает в редчайших случаях).
3. Регистровая память (Registered). СЕРВЕРНЫЙ тип памяти. Обычно он всегда выпускается с ECC (коррекцией ошибок) и c микросхемой “Буфером”. Микросхема “буфер” позволяет увеличить максимальное количество планок памяти, которые можно подключить к шине не перегружая её, но это уже лишние данные, не будем углубляться в теорию. В последнее время понятия буферизованный и регистровый почти не различают. Если утрировать: регистровая память = буферизованная. Эта память работает ТОЛЬКО на серверных материнских платах способных работать с памятью черем микросхему “буфер”.
Обычно на планках регистровой памяти с ECC установлено 9, 18 или 36 микросхем памяти и ещё 1, 2 или 4 микросхемы “буфера” (они обычно в центре, отличаются по габаритам от микросхем памяти). У такой памяти маркировка как правило заканчивается буквой R (Registered), например DDR2 PC-4200R, DDR2 PC-6400R, DDR3 PC-8500R или DDR3 PC-10600R. Ещё в маркировке регистровой (серверной) (буферизированной) памяти обычно присутствует сокращение слова Registered – REG. Фото буферизированной (регистровой) памяти c ECC можно видеть ниже.
Помните! Регистровая память с ECC со 100% вероятностью НЕ РАБОТАЕТ на обычных материнских платах. Она работает только на серверах!
P.S.: В последнее время появился ещё один дешевый и интересный тип памяти – я её называю “Китайская Подделка”. Кто ещё не сталкивался – расскажу. Это такая память, которую можно всегда узнать по её контактам, обычно они окисленные и даже если их очистить, то за месяц-два они опять окисляются, становятся мутными, грязными и память при этом может сбоить или совсем не работать. Золотом на контактах этой памяти даже и не пахнет. Ещё одним отличием этой памяти от оригинальной является то, что она работает на определённых материнских платах или процессорах, например ТОЛЬКО на АМД, или только строго на каких-то чипсетах. Причём перечень этих чипсетов очень мал. В чём секрет этой “памяти” мне пока не ясно, но многие покупают – ведь она на 40-50% дешевле аналогичной. И что самое удивительное, новая “Китайская Подделка” обычно стоит дешевле оригинальной памяти Б/У 🙂 Надёжность и долговечность работы рассказывать не буду, тут и так всё ясно.
http://www.sector.biz.ua/docs/ecc_memory/ecc_memory.phtml
CentOS 7 / Red Hat:
yum install fail2ban
Ubuntu / Debian:
apt install fail2ban
CentOS 6:
Добавляем репозиторий:
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Устанавливаем пакет:
yum install fail2ban
Для запуска службы вводим следующие команды:
systemctl enable fail2ban
systemctl start fail2ban
* Для старых систем без systemd это будут команды
chkconfig fail2ban on update-rc.d fail2ban defaults service fail2ban start.
Процесс настройки fail2ban не зависит от дистрибутива Linux. Основной конфигурационный файл находится по пути /etc/fail2ban/jail.conf. Однако, его не рекомендуется менять и для настройки используют подключаемые файлы из каталога /etc/fail2ban/jail.d.
Для начала создаем первый файл, в котором будут храниться настройки по умолчанию:
nano /etc/fail2ban/jail.d/default.conf
Приведем его к виду:
[DEFAULT] maxretry = 4 findtime = 480 bantime = 720 action = firewallcmd-ipset ignoreip = 127.0.0.1/8
* где:
* В данном примере, если в течение 8 минут (480) будет найдено 5 строк (maxretry = 4), содержащих критерий фильтра, Fail2ban заблокирует IP-адрес, с которого идет подключение на 12 минут (720);
* В секции [DEFAULT] хранятся общие настройки для всех правил. Каждую из настроек можно переопределить при конфигурировании самого правила.
Для нового правила необходимо создать конфигурационный файл в каталоге /etc/fail2ban/jail.d, например:
nano /etc/fail2ban/jail.d/service.conf
[ssh] enabled = true port = ssh filter = sshd action = iptables[name=sshd, port=ssh, protocol=tcp] logpath = /var/log/auth.log maxretry = 10 findtime = 600
* где:
* обратите внимание, что мы переопределили параметры по умолчанию maxretry, findtime и action.
Чтобы изменения вступили в силу, перезапускаем сервис:
systemctl restart fail2ban
* в старых версиях
service fail2ban restart.
Файлы с настройкой действий находятся в каталоге /etc/fail2ban/action.d. Чтобы блокировать адрес, Fail2ban создает правило в брандмауэре netfilter. Для этого, чаще всего, используются утилиты iptables или firewall-cmd. Последняя применяется в последних версиях CentOS / Red Hat / Fedora. iptables более универсальная и может использоваться, почти, во всех системах Linux.
Остановимся на описании самых используемых действий:
Подробнее, как создаются правила в netfilter при помощи iptables и firewalld.
Фильтры, в основном, представляют набор регулярных выражений для поиска ключевых слов в log-файлах. Они находятся в каталоге /etc/fail2ban/filter.d.
Для создания и настройки своих фильтров, можно использовать имеющиеся файлы в качестве шпаргалки.
В данных примерах блокировка IP-адреса будет происходить на 12 минут после 4-х попыток ввода пароля в течение 8 минут. Эти параметры берутся из настроек [DEFAULT]. Если их нужно переопределить, просто добавляем их при описании правила.
vi /etc/fail2ban/jail.d/ssh.conf
[ssh] enabled = true port = ssh filter = sshd action = firewallcmd-new[name=sshd] logpath = /var/log/secure
vi /etc/fail2ban/jail.d/ssh.conf
[ssh] enabled = true port = ssh filter = sshd action = iptables[name=sshd] logpath = /var/log/auth.log
vi /etc/fail2ban/jail.d/asterisk.conf
[asterisk] enabled = true filter = asterisk action = iptables-allports[name=asterisk, protocol=all] logpath = /var/log/asterisk/messages
vi /etc/fail2ban/jail.d/nginx.conf
[nginx] enabled = true port = http,https filter = nginx-http-auth action = iptables-multiport[name=nginx, port="http,https", protocol=tcp] logpath = /var/log/nginx/error.log
Данное правило поможет защитить веб-сервер nginx от DDoS-атак. В некоторых сборках, для данного правило может не оказаться готового фильтра, поэтому в данном примере, мы его создадим вручную.
Создаем фильтр:
vi /etc/fail2ban/filter.d/nginx-limit-req.conf
[Definition] ngx_limit_req_zones = [^"]+ failregex = ^\s*\[error\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST> ignoreregex =
Создаем правило в Fail2ban:
vi /etc/fail2ban/jail.d/nginx-ddos.conf
[nginx-ddos] enabled = true port = http,https filter = nginx-limit-req action = iptables-multiport[name=nginxddos, port="http,https", protocol=tcp] logpath = /var/log/nginx/error.log
vi /etc/fail2ban/filter.d/owncloud.conf
[Definition]
failregex={.*Login failed: \'.*\' \(Remote IP: \'<HOST>\'\)"}
ignoreregex =
vi /etc/fail2ban/jail.d/owncloud.conf [owncloud] enabled = true filter = owncloud ignoreip = 127.0.0.1/8 192.168.1.47 194.44.219.161 194.44.219.163 194.44.219.164 #action = smeserver-iptables[port="$port",protocol=tcp,bantime=$bantime] logpath = /var/www/html/owncloud/data/owncloud.log maxretry = 3 port = 80,443 bantime = 10800 protocol = tcp
vi /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^<HOST> .* "POST .*wp-login.php
^<HOST> .* "POST .*xmlrpc.php
ignoreregex =
vi /etc/fail2ban/jail.d/wp-login.conf [wp-login] enabled = true ignoreip = 127.0.0.1/8 192.168.0.0/24 action = iptables-multiport[name=WP, port="http,https" protocol=tcp] # включаем отправку оповещения на почту, если вам это необходимо # sendmail[name=wp-login, dest=zeroxzed@gmail.com, sender=fail2ban@serveradmin.ru] filter = wp-login logpath = /var/log/nginx/access.log bantime = 10800 maxretry = 3
Проверяем:
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wp-login.conf
Results ======= Failregex: 4 total |- #) [# of hits] regular expression | 1) [3] ^<HOST> .* "POST .*wp-login.php | 2) [1] ^<HOST> .* "POST .*xmlrpc.php `- Ignoreregex: 0 total Date template hits: |- [# of hits] date format | [302] Day(?P<_sep>[-/])MON(?P=_sep)Year[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)? `- Lines: 302 lines, 0 ignored, 4 matched, 298 missed [processed in 0.06 sec]
После настройки не забываем перезапустить fail2ban:
systemctl restart fail2ban
# vi /etc/fail2ban/jail.d/seafile.conf # All standard jails are in the file configuration located # /etc/fail2ban/jail.conf # Warning you may override any other parameter (e.g. banaction, # action, port, logpath, etc) in that section within jail.local # Change logpath with your file log used by seafile (e.g. seahub.log) # Also you can change the max retry var (3 attemps = 1 line written in the # seafile log) # So with this maxrety to 1, the user can try 3 times before his IP is banned [seafile] enabled = true port = http,https filter = seafile-auth logpath = /home/www/seafile/logs/seahub.log maxretry = 3
# vi /etc/fail2ban/filter.d/seafile-auth.conf # Fail2Ban filter for seafile # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = seaf-server failregex = Login attempt limit reached.*, ip: <HOST> ignoreregex = # DEV Notes: # # pattern : 2015-10-20 15:20:32,402 [WARNING] seahub.auth.views:155 login Login attempt limit reached, username: <user>, ip: 1.2.3.4, attemps: 3 # 2015-10-20 17:04:32,235 [WARNING] seahub.auth.views:163 login Login attempt limit reached, ip: 1.2.3.4, attempts: 3
Перечитываем конфиг и проверяем:
# fail2ban-client reload # fail2ban-client status # fail2ban-regex /home/www/seafile/logs/seahub.log /etc/fail2ban/filter.d/seafile-auth.conf
Получить статистику заблокированных адресов можно следующей командой:
fail2ban-client status <имя правила>
Получить список правил можно командой:
fail2ban-client status
При наличие заблокированных IP-адресов мы увидим, примерно, следующее:
`- action |- Currently banned: 2 | `- IP list: 31.207.47.55 10.212.245.29
С помощью iptables:
iptables -L -n --line
С помощью firewall-cmd:
firewall-cmd --direct --get-all-rules
Средствами fail2ban:
Для удаление адреса из списка вводим:
fail2ban-client set <имя правила> unbanip <IP-адрес>
например:
fail2ban-client set ssh unbanip 31.207.47.55
С помощью iptables:
iptables -D <цепочка правил> -s IP-адрес
например:
iptables -D fail2ban-ssh -s 10.212.245.29
С помощью firewall-cmd:
firewall-cmd --direct --permanent --remove-rule <правило>
например:
firewall-cmd --direct --permanent --remove-rule ipv4 filter f2b-sshd 0 -s 188.134.7.221
После необходимо перечитать правила:
firewall-cmd --reload
https://www.dmosk.ru/instruktions.php?object=fail2ban
Проверим, запущен ли firewalld:
# systemctl status firewalld
Тут будет расширенная информация. Чтобы коротко, да (работает) или нет можно так:
# firewall-cmd --state running
Остановка firewalld:
# systemctl stop firewalld
Запрет автостарта:
# systemctl disable firewalld
Запуск firewalld:
# systemctl start firewalld
Включение автостарта:
# systemctl enable firewalld
В firewalld широко используется понятие зоны. Список всех допустимых зон по-умолчанию:
# firewall-cmd --get-zones block dmz drop external home internal public trusted work
Назначение зон (условно, конечно):
Список всех активных зон:
# firewall-cmd --get-active-zones public interfaces: enp1s0
Ага, зона public, к которой присоединен сетевой интерфейс enp1so. Дальше в зону public добавим новый порт, на котором будет висеть sshd.
Зная имя сетевого интерфейса (например, enp1s0), можно узнать, к какой зоне он принадлежит:
# firewall-cmd --get-zone-of-interface=enp1s0 public
А можно узнать, какие интерфейсы принадлежат конкретной зоне:
# firewall-cmd --zone=public --list-interfaces enp1s0
Давайте разрешим доступ к серверу по ssh на порте 2234/tcp, а не на 22/tcp, как по-умолчанию. Попутно чуть-чуть коснемся selinux.
Сначала посмотрим, что вообще разрешено постоянно на нашем сервере:
# firewall-cmd --permanent --list-all public (default) interfaces: sources: services: ssh dhcpv6-client masquerade: no forward-ports: icmp-blocks: rich rules:
Я не использую пока ipv6, поэтому сразу уберу соотв. правило из firewalld:
# firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client
Разрешим на постоянной основе (чтобы после перезагрузки не потерлось) соединение на порт 2234/tcp (на него повесим sshd):
# firewall-cmd --permanent --zone=public --add-port=2234/tcp
Перезагрузим правила:
# firewall-cmd --reload
Проверим:
# firewall-cmd --zone=public --list-ports 2234/tcp
Ок, порт открыт. Редактируем конфиг sshd:
# nano /etc/ssh/sshd_config ... port 2234 ... # systemctl restart sshd.service
Но SELinux, которую вы, надеюсь, не отключали, не даст подключиться к ssh на нестандартном порте (порт 2234/tcp для sshd – нестандартный). Вы можете этот шаг пропустить и проверить, как сработает защита SELinux, а можете сразу все настроить:
# yum provides semanage # yum install policycoreutils-python # semanage port -a -t ssh_port_t -p tcp 2234
Вот теперь все ок. Проверяем подключение по ssh на новом порте. Если все ок, закрываем доступ к порту 22:
# firewall-cmd --permanent --zone=public --remove-service=ssh # firewall-cmd --reload
Смотрим, что получилось:
# firewall-cmd --list-all public (default, active) interfaces: sources: services: ports: 2234/tcp masquerade: no forward-ports: icmp-blocks: rich rules:
Вот и все.
Включить режим блокировки всех исходящих и входящих пакетов:
# firewall-cmd --panic-on
Выключить режим блокировки всех исходящих и входящих пакетов:
# firewall-cmd --panic-off
Узнать, включен ли режим блокировки всех исходящих и входящих пакетов:
# firewall-cmd --query-panic
Перезагрузить правила firewalld без потери текущих соединений:
# firewall-cmd --reload
Перезагрузить правила firewalld и сбросить текущие соединения (рекомендуется только в случае проблем):
# firewall-cmd --complete-reload
Добавить к зоне сетевой интерфейс:
# firewall-cmd --zone=public --add-interface=em1
Добавить к зоне сетевой интерфейс (сохранится после перезагрузки firewall):
# firewall-cmd --zone=public --permanent --add-interface=em1
Можно в конфиге ifcfg-enp1s0 указать, какой зоне принадлежит этот интерфейс. Для этого добавим ZONE=work в файл /etc/sysconfig/network-scripts/ifcfg-enp1s0. Если параметр ZONE не указан, будет назначена зона по-умолчанию (параметр DefaultZone в файле /etc/firewalld/firewalld.conf.
Разрешить диапазон портов:
# firewall-cmd --zone=public --add-port=5059-5061/udp
Проверить статус:
# firewall-cmd --zone=external --query-masquerade
Включить:
# firewall-cmd --zone=external --add-masquerade
Здесь надо отметить, что вы можете включить masquerade и для зоны public, например.
Перенаправить входящие на 22 порт на другой хост:
# firewall-cmd --zone=external --add-forward-port=port=22:proto=tcp:toaddr=192.168.1.23
Перенаправить входящие на 22 порт на другой хост с изменением порта назначения (с 22 на 192.168.1.23:2055):
# firewall-cmd --zone=external / --add-forward-port=port=22:proto=tcp:toport=2055:toaddr=192.168.1.23
На этом закончу, т.к. примеров может быть бесконечно много. Добавлю только, что лично я не составил окончательно свое мнение по поводу нововведения firewalld, т.к. к синтаксису привыкаешь долго и если в вашем зоопарке встречаются разные OS Linux, то по первости могут быть проблемы именно с привычкой. Но освоив firewalld, вы расширите кругозор – чаще всего, это стоит затраченных усилий.
Если все же вы хотите вернуть прошлое и заменить firewalld на iptables, то сделать это совсем не трудно:
# systemctl disable firewalld # systemctl stop firewalld
Ставим старый добрый iptables:
# yum install iptables-services
Запускаем брандмауэр:
# systemctl start iptables # systemctl start ip6tables
Автозапуск при включении:
# systemctl enable iptables # systemctl enable ip6tables
Для сохранения правил iptables после перезагрузки:
# iptables-save > /etc/sysconfig/iptables # ip6tables-save > /etc/sysconfig/ip6tables
Или по-старинке:
# service iptables save
Для загрузки правил iptables после перезагрузки:
# iptables-restore < /etc/sysconfig/iptables # ip6tables-restore < /etc/sysconfig/ip6tables
Текущие правила находятся в файлах:
/etc/sysconfig/iptables /etc/sysconfig/ip6tables
Перезапуск iptables (например, после совершения каких-либо изменений):
# systemctl restart iptables.service
http://bozza.ru/art-259.html