Архив категорий Настройка Linux

Руководство по определению версии Linux

Каждый системный администратор должен уметь быстро и точно определять версию Linux-дистрибутива. Это важно для:

  • Обновления системы
  • Устранения неисправностей
  • Совместимости ПО
  • Документирования инфраструктуры

В этой статье разберём все основные команды, их различия и лучшие практики использования.


1. Стандартные команды для определения дистрибутива

1.1. hostnamectl (рекомендуемый способ)

Почему лучше?

  • Встроен в systemd (есть почти везде)
  • Показывает не только ОС, но и ядро, архитектуру, hostname

Пример:

hostnamectl

Вывод:

  Static hostname: server1  
       Operating System: Ubuntu 22.04.3 LTS  
            Kernel: Linux 5.15.0-78-generic  
      Architecture: x86-64

Фильтрация вывода:

hostnamectl | grep "Operating System" # Только ОС
hostnamectl | grep "Kernel"           # Только ядро

1.2. lsb_release (классический метод для Debian/Ubuntu)

Плюсы:

  • Чётко показывает дистрибутив и кодовое имя
  • Есть почти во всех Debian-based системах

Пример:

lsb_release -a

Вывод:

Distributor ID: Ubuntu  
Description:    Ubuntu 22.04.3 LTS  
Release:        22.04  
Codename:       jammy

Короткие варианты:

lsb_release -d # Только описание  
lsb_release -c   # Кодовое имя (jammy, focal, bullseye)

1.3. Чтение файлов /etc/*-release

Когда использовать?

  • Если hostnamectl и lsb_release недоступны (минимальные дистрибутивы)

Команды:

cat /etc/os-release # Самый информативный
cat /etc/lsb-release # Альтернатива для Ubuntu
cat /etc/redhat-release # Для RHEL/CentOS
cat /etc/issue # Простая версия  
 

Пример (/etc/os-release):

 
NAME="Ubuntu"  
VERSION="22.04.3 LTS (Jammy Jellyfish)"  
ID=ubuntu  
ID_LIKE=debian  
PRETTY_NAME="Ubuntu 22.04.3 LTS"

2. Дополнительные методы

2.1. uname – информация о ядре

uname -a

Вывод:

Linux server1 5.15.0-78-generic #85-Ubuntu SMP x86_64 GNU/Linux  

Опции:

  • uname -r – только версия ядра
  • uname -m – архитектура (x86_64, arm64)

2.2. neofetch (красивый вывод)

Установка:

sudo apt install neofetch # Ubuntu/Debian
sudo dnf install neofetch # RHEL/Fedora  

Запуск:

neofetch

Вывод (графический, с логотипом дистрибутива):

OS: Ubuntu 22.04.5 LTS x86_64
Host: KVM RHEL 7.6.0 PC (i440FX + PIIX, 1996)
Kernel: 5.15.0-136-generic
Uptime: 27 days, 18 hours, 26 mins
Packages: 634 (dpkg)
Shell: bash 5.1.16
Resolution: 1024×768
Terminal: /dev/pts/0
CPU: AMD EPYC 9454P (1) @ 2.749GHz
GPU: 00:02.0 Cirrus Logic GD 5446
Memory: 313MiB / 956MiB
 

3. Сравнение команд

Команда Лучше всего подходит для Показывает ядро? Требует установки?
hostnamectl Любой systemd-дистр. ✅ Да ❌ Нет (встроен)
lsb_release -a Debian/Ubuntu ❌ Нет ❌ Нет (обычно есть)
cat /etc/os-release Минимальные дистры ❌ Нет ❌ Нет
uname -a Проверка ядра ✅ Только ядро ❌ Нет
neofetch Красивый вывод ✅ Да ✅ Да (устанавливается)

Настройка базовой защиты сервера: iptables и Fail2Ban

В современной инфраструктуре безопасность сервера — критически важный аспект. Один из способов защиты — использование iptables для фильтрации сетевого трафика и Fail2Ban для автоматической блокировки подозрительных подключений. В этой статье разберём настройку этих инструментов для базовой защиты Linux-сервера.


1. Установка и настройка Fail2Ban

1.1. Установка и активация

Устанавливаем Fail2Ban из репозитория и включаем автозагрузку:

apt install fail2ban
systemctl enable --now fail2ban

1.2. Базовая конфигурация

Основные настройки хранятся в:

  • /etc/fail2ban/jail.conf — основной конфиг (лучше не редактировать напрямую)
  • /etc/fail2ban/jail.d/*.conf — кастомные настройки (предпочтительный способ)

Создаём или редактируем конфигурацию:

nano /etc/fail2ban/jail.d/custom.conf

Добавляем следующие параметры:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 217.25.227.207  # IP, которые не блокируются
bantime  = 30d                              # Время блокировки (30 дней)
findtime = 5m                               # Окно анализа попыток входа
maxretry = 3                                # Макс. число попыток до бана
banaction = iptables-multiport              # Действие при бане (по портам)
banaction_allports = iptables-allports      # Блокировка всех портов

1.3. Проверка работы Fail2Ban

Проверим статус защиты для SSH:

fail2ban-client status sshd

Посмотрим правила iptables, созданные Fail2Ban:

iptables -L -n -v | grep -A 10 "f2b-sshd"

2. Настройка iptables для базовой защиты

2.1. Основные правила

Перед применением политики DROP на INPUT разрешим необходимый трафик:

# Разрешаем ICMP (ping)
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Разрешаем порт для Zabbix-агента
iptables -A INPUT -p tcp --dport 10050 -j ACCEPT

# Разрешаем SSH (порт 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Разрешаем ответы на исходящие соединения
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Разрешаем локальный интерфейс (loopback)
iptables -A INPUT -i lo -j ACCEPT

# Запрещаем весь остальной входящий трафик
iptables -P INPUT DROP

# Сохраняем правила
iptables-save > /etc/iptables/rules.v4

2.2. Управление правилами iptables

Если нужно удалить правило:

iptables -L --line-numbers  # Просмотр правил с номерами
iptables -D INPUT 3         # Удаление правила №3 из цепочки INPUT

3. Что получаем на выходе всех настроек

Комбинация Fail2Ban и iptables даёт:
✅ Автоматическую защиту от брутфорса (Fail2Ban)
✅ Гибкую фильтрацию трафика (iptables)
✅ Контроль доступа к критическим сервисам (SSH, Zabbix)

Рекомендуется:
🔹 Регулярно проверять логи Fail2Ban (journalctl -u fail2ban -f)
🔹 Обновлять список ignoreip для доверенных IP
🔹 Тестировать правила iptables перед применением в production

Такая настройка обеспечит базовый уровень безопасности сервера, минимизируя риски несанкционированного доступа.

🔐 Дополнительные меры:

  • Настройка SSH-доступа по ключам вместо пароля
  • Использование UFW (если iptables кажется сложным)
  • Мониторинг с помощью Zabbix/Grafana для отслеживания атак

Как переезжал на диск с меньшим размером XFS

Все началось с жадности, провайдер VDS предложил цены ниже моего на 2$ с единственным неподходящим для меня параметром, меньшим объемом диска, на 10 Гб был меньше.

Перепробовав множество вариантов, все уперлось в файловую систему, которую мой провайдер да и по обычаю Centos ставил XFS. Я не фанат этой файловой системы, но минус для меня был громадным, изменить размер невозможно.

Для себя я четко решил что от такой FS надо избавляться, мало ли на какие размеры и серверы придется перекочёвывать. В качестве решения выбрал LVM, но в принципе она может быть любой, главное было перекопировать систему без потерь. Итак приступим.

Шаг 1. Разрешение удалённого доступа (опционально)

Загружаемся с Live образа на нашей новой машине или виртуалке.

https://buildlogs.centos.org/centos/7/isos/x86_64/CentOS-7-livecd-GNOME-x86_64.iso
Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон:

su

passwd

systemctl start sshd

Теперь можно подключиться к целевой машине вашим SSH клиентом (например, PuTTY).

Шаг 2. Разбивка диска на разделы

Вы можете использовать вашу любимую утилиту для этого. Например, в Gnome есть предустановленная утилита для управления дисками. Также в интернетах хвалят gparted, однако я намеренно использовал fdisk, т.к, например, gparted просто не распознавал мой NVMe SSD-диск.

Диск следует разбить по образу и подобию прежнего диска. Я не маньяк партиционирования, поэтому моя схема партиционирования была стандартной:

  • /boot— стандартный раздел размером 1GB;
  • swap раздел размером 4G;
  • /— корневой раздел, LVM volume group с наименованием «main», занимающий оставшееся пространство на диске.

 

lsblk # проверим какое наименование в системе получил новый диск, в моём случае это nvme0n1

fdisk /dev/nvme0n1

n # добавить новый раздел (для /boot)

p # primary partition

# оставляем по умолчанию (1-й раздел)

# оставляем по умолчанию (от начала диска)

+1G # размер для раздела /boot

# готово

n # добавить новый раздел (для новой LVM volume group)

p # primary partition

# оставляем по умолчанию (2-й раздел)

# оставляем по умолчанию (от начала предыдущего раздела)

# оставляем по умолчанию (100% оставшегося места)

# готово

a # установка флага «bootable»

1 # для 10го раздела

p # проверим, всё ли в порядке

w # записываем таблицу партиционирования на диск

 

Раздел /boot должен быть стандартным линукс-разделом, поэтому сразу создаём файловую систему на нём:

 

mkfs.xfs /dev/nvme0n1p1 -f

 

И теперь нам необходимо создать LVM-структуру для второго раздела на диске. Назовём новую LVM-группу newmain (впоследствии переименуем):

pvcreate /dev/nvme0n1p2 # создаем новый физический LVM-диск для раздела

vgcreate newmain /dev/nvme0n1p2 # создаем новую LVM-группу и добавляем в неё только что добавленный физический LVM-диск

lvcreate -L 4G -n swap newmain # создаем логический раздел размером 4 ГБ под swap

lvcreate -l 100%FREE -n root newmain # создаем логический раздел на всё оставшееся место под корень

 

Теперь мы готовы к созданию файловой системы на новых логических разделах:

 

mkfs.xfs /dev/newmain/root # создание файловой системы для корневого раздела

mkswap -L swap /dev/newmain/swap # создание swap на новом разделе

swapon /dev/newmain/swap

 

Шаг 3. Активная фаза

 

Прежде чем мы начнём, сделаем обе LVM-группы активными (т.к. мы работаем из под Live CD):

vgchange -a y main

vgchange -a y newmain

Создадим директории для точек монтирования, и примонтируем к системе старые и новые разделы наших дисков:

mkdir -p /mnt/old/boot

mkdir -p /mnt/old/root

mkdir -p /mnt/new/boot

mkdir -p /mnt/new/root

mount /dev/sda1 /mnt/old/boot

mount /dev/nvme0n1p1 /mnt/new/boot

mount /dev/main/root /mnt/old/root

mount /dev/newmain/root /mnt/new/root

Убедимся, что всё в порядке при помощи команды lsblk:

lsblk

NAME             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

sda                8:0    0 931.5G  0 disk

├─sda1             8:1    0     1G  0 part /mnt/old/boot

└─sda2             8:2    0 930.5G  0 part

  ├─main-swap    253:0    0   3.6G  0 lvm  [SWAP]

  └─main-root    253:1    0 926.9G  0 lvm  /mnt/old/root

nvme0n1          259:0    0 119.2G  0 disk

├─nvme0n1p1      259:3    0     1G  0 part /mnt/new/boot

└─nvme0n1p2      259:4    0 118.2G  0 part

  ├─newmain-swap 253:5    0     4G  0 lvm  [SWAP]

  └─newmain-root 253:6    0 114.2G  0 lvm  /mnt/new/root

 

Если вы видите что-то наподобие этого, вы всё сделали верно. И здесь начинается настоящая магия — мы собираемся использовать xfsdump для миграции наших данных. Эта утилита достаточно умная и знает о внутреннем устройстве файловой системы xfs, что позволяет ей копировать только занятые данными блоки, что, в свою очередь, во-первых, позволяет нам копировать данные на диск меньшего размера, а во-вторых сильно ускоряет процесс переноса. Итак, давайте сделаем дамп данных при помощи этой утилиты, и на лету развернём эти данные на новом месте:

 

xfsdump -l0 -J — /mnt/old/boot | xfsrestore -J — /mnt/new/boot

xfsdump -l0 -J — /mnt/old/root | xfsrestore -J — /mnt/new/root

В моем случае тип файловой системы ext4

Копирование с /boot на другой диск:

cp -p -r /boot/* /mnt/new/boot

 

Пару слов об использованных флагах:

  • -Jуменьшает размер фидбека;
  • -сообщает xfsdump и xfsrestore использовать стандартные потоки stdout и stdin соответственно вместо файлов.

Шаг 4. Делаем новый диск загрузочным

 

Первое, что нужно сделать, это узнать UUID для старого и нового загрузочных разделов (/boot) при помощи команды blkid:

blkid

/dev/nvme0n1p1: UUID=»3055d690-7b2d-4380-a3ed-4c78cd0456ba» TYPE=»xfs»

/dev/sda1: UUID=»809fd5ba-3754-4c2f-941a-ca0b6fb5c86e» TYPE=»xfs»

 

Предполагая, что sda1 — прежний раздел \boot, и nvme0n1p1 — новый, производим замену UUID в конфигурационных файлах на новой точке монтирования:

 

sed -i «s/809fd5ba-3754-4c2f-941a-ca0b6fb5c86e/3055d690-7b2d-4380-a3ed-4c78cd0456ba/g» /mnt/new/root/etc/fstab

sed -i «s/809fd5ba-3754-4c2f-941a-ca0b6fb5c86e/3055d690-7b2d-4380-a3ed-4c78cd0456ba/g» /mnt/new/boot/grub2/grub.cfg

 

Эти две команды подготовят ваши системные файлы конфигурации к новому диску.

 

Теперь самое время переименовать LVM-группы и отмонтировать диски:

 

umount /mnt/{old,new}/{boot,root}

vgrename -v {,old}main

vgrename -v {new,}main

 

Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chroot:

 

mount /dev/main/root /mnt

mkdir -p /mnt/boot

mount /dev/nvme0n1p1 /mnt/boot

mount -t devtmpfs /dev /mnt/dev

mount -t proc /proc /mnt/proc

mount -t sysfs /sys /mnt/sys

chroot /mnt/ grub2-install /dev/nvme0n1

 

Шаг 5. Последний штрих

 

На данном этапе все данные уже должны быть перенесены и новый диск должен стать загрузочным. Нужно только перезапуститься, вынуть Live CD из привода, и выбрать новый диск в BIOS для загрузки:

 

systemctl reboot -f

 

Если что-то пошло не так и система не загружается, вы всегда можете «откатиться» на старый диск, просто запустившись с Live CD повторно и переименовав LVM-группы обратно, выполнив vgrename -v {,new}main и vgrename -v {old,}main, и затем снова перезапуститься.

На этом обязательная часть программы окончена и мы успешно перенесли работающую систему на новый диск. Старый диск можно извлекать из компьютера.

 

 

 

запуск lsinitrd -m -k -p {file}  показывает, что внутри ramdisk нет модуля lvm

 

cp /etc/dracut.conf /etc/dracut.conf.bak

 

nano /etc/dracut.conf

Поправив следующие строки:

# dracut modules to add to the default

add_dracutmodules+=»lvm»

 

# install local /etc/mdadm.conf

mdadmconf=»yes»

 

# install local /etc/lvm/lvm.conf

lvmconf=»yes»

 

 

  • Монтируем корневой раздел

mount /dev/mapper/centos-root /mnt/sysimage

  • монтируем системные пути

mount -o bind /dev /mnt/sysimage/dev

mount -o bind /sys /mnt/sysimage/sys

mount -o bind /proc /mnt/sysimage/proc

mount /dev/sda1 /mnt/sysimage/boot

  • переходим в режим chroot и пересоздаем initfamfs для нужной версии ядра

chroot /mnt/sysimage

cd /boot
dracut -f initramfs-3.10.0-1160.11.1.el7.x86_64.img 3.10.0-1160.11.1.el7.x86_64

  • пересобираем конфигурацию загрузки GRUB2

grub2-mkconfig -o /boot/grub2/grub.cfg

  • После этого выходим из chroot и перезагружаемся

exit
shutdown -r now

Ссылки на истоки:

https://habr.com/ru/post/352400/

https://serverfault.com/questions/893721/centos7-dracut-lvm-command-not-found

https://xhop.ru/nix-sistemyi/centos-7-dracut-boot-recovery/ 

Программный RAID в Linux — работаем с mdadm

mdadm — утилита для работы с программными RAID-массивами различных уровней. В данной инструкции рассмотрим примеры ее использования.

Установка утилиты mdadm
Создание RAID
Файл mdadm.conf
Создание файловой системы и монтирование
Получение информации о RAID
Проверка целостности массива
Восстановление RAID
Заменой диска
Пересборка массива
Использование Hot Spare
Добавление диска к массиву
Удаление массива

Установка mdadm
Утилита mdadm может быть установлена одной командой.

Если используем CentOS / Red Hat:

yum install mdadm

Если используем Ubuntu / Debian:

apt-get install mdadm

Сборка RAID
Перед сборкой, стоит занулить суперблоки на дисках, которые мы будем использовать для построения RAID (если диски ранее использовались, их суперблоки могут содержать служебную информацию о других RAID):

mdadm —zero-superblock —force /dev/sd{b,c}

* в данном примере мы зануляем суперблоки для дисков sdb и sdc.

Если мы получили ответ:

mdadm: Unrecognised md component device — /dev/sdb
mdadm: Unrecognised md component device — /dev/sdc

… то значит, что диски не использовались ранее для RAID. Просто продолжаем настройку.

Для сборки избыточного массива применяем следующую команду:

mdadm —create —verbose /dev/md0 -l 1 -n 2 /dev/sd{b,c}

* где /dev/md0 — устройство RAID, которое появится после сборки; -l 1 — уровень RAID; -n 2 — количество дисков, из которых собирается массив; /dev/sd{b,c} — сборка выполняется из дисков sdb и sdc.

Мы должны увидеть что-то на подобие:

mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store ‘/boot’ on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
—metadata=0.90
mdadm: size set to 1046528K

Также система задаст контрольный вопрос, хотим ли мы продолжить и создать RAID — нужно ответить y:

Continue creating array? y

Создание файла mdadm.conf
В файле mdadm.conf находится информация о RAID-массивах и компонентах, которые в них входят. Для его создания выполняем следующие команды:

mkdir /etc/mdadm

echo «DEVICE partitions» > /etc/mdadm/mdadm.conf

mdadm —detail —scan —verbose | awk ‘/ARRAY/ {print}’ >> /etc/mdadm/mdadm.conf

Пример содержимого:

DEVICE partitions
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=proxy.dmosk.local:0 UUID=411f9848:0fae25f9:85736344:ff18e41d

* в данном примере хранится информация о массиве /dev/md0 — его уровень 1, он собирается из 2-х дисков.

Создание файловой системы и монтирование массива
Создание файловой системы для массива выполняется также, как для раздела:

mkfs.ext4 /dev/md0

* данной командой мы создаем на md0 файловую систему ext4.

Примонтировать раздел можно командой:

mount /dev/md0 /mnt

* в данном случае мы примонтировали наш массив в каталог /mnt.

Чтобы данный раздел также монтировался при загрузке системы, добавляем в fstab следующее:

vi /etc/fstab

/dev/md0 /mnt ext4 defaults 1 2

Для проверки правильности fstab, вводим:

umount /mnt

mount -a

Мы должны увидеть примонтированный раздел md, например:

df -h

/dev/md0 990M 2,6M 921M 1% /mnt

Информация о RAID
Посмотреть состояние всех RAID можно командой:

cat /proc/mdstat

В ответ мы получим что-то на подобие:

md0 : active raid1 sdc[1] sdb[0]
1046528 blocks super 1.2 [2/2] [UU]

* где md0 — имя RAID устройства; raid1 sdc[1] sdb[0] — уровень избыточности и из каких дисков собран; 1046528 blocks — размер массива; [2/2] [UU] — количество юнитов, которые на данный момент используются.
** мы можем увидеть строку md0 : active(auto-read-only) — это означает, что после монтирования массива, он не использовался для записи.

Подробную информацию о конкретном массиве можно посмотреть командой:

mdadm -D /dev/md0

* где /dev/md0 — имя RAID устройства.

Пример ответа:

Version : 1.2
Creation Time : Wed Mar 6 09:41:06 2019
Raid Level : raid1
Array Size : 1046528 (1022.00 MiB 1071.64 MB)
Used Dev Size : 1046528 (1022.00 MiB 1071.64 MB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Wed Mar 6 09:41:26 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

Name : proxy.dmosk.local:0 (local to host proxy.dmosk.local)
UUID : 304ad447:a04cda4a:90457d04:d9a4e884
Events : 17

Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc

* где:

Version — версия метаданных.
Creation Time — дата в время создания массива.
Raid Level — уровень RAID.
Array Size — объем дискового пространства для RAID.
Used Dev Size — используемый объем для устройств. Для каждого уровня будет индивидуальный расчет: RAID1 — равен половине общего размера дисков, RAID5 — равен размеру, используемому для контроля четности.
Raid Devices — количество используемых устройств для RAID.
Total Devices — количество добавленных в RAID устройств.
Update Time — дата и время последнего изменения массива.
State — текущее состояние. clean — все в порядке.
Active Devices — количество работающих в массиве устройств.
Working Devices — количество добавленных в массив устройств в рабочем состоянии.
Failed Devices — количество сбойных устройств.
Spare Devices — количество запасных устройств.
Consistency Policy — политика согласованности активного массива (при неожиданном сбое). По умолчанию используется resync — полная ресинхронизация после восстановления. Также могут быть bitmap, journal, ppl.
Name — имя компьютера.
UUID — идентификатор для массива.
Events — количество событий обновления.
Chunk Size (для RAID5) — размер блока в килобайтах, который пишется на разные диски.
Подробнее про каждый параметр можно прочитать в мануале для mdadm:

man mdadm

Также, информацию о разделах и дисковом пространстве массива можно посмотреть командой fdisk:

fdisk -l /dev/md0

Проверка целостности
Для проверки целостности вводим:

echo ‘check’ > /sys/block/md0/md/sync_action

Результат проверки смотрим командой:

cat /sys/block/md0/md/mismatch_cnt

* если команда возвращает 0, то с массивом все в порядке.

Остановка проверки:

echo ‘idle’ > /sys/block/md0/md/sync_action

Восстановление RAID
Рассмотрим два варианта восстановлении массива.

Замена диска
В случае выхода из строя одного из дисков массива, команда cat /proc/mdstat покажет следующее:

cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sdb[0]
1046528 blocks super 1.2 [2/1] [U_]

* о наличии проблемы нам говорит нижнее подчеркивание вместо U — [U_] вместо [UU].

Или:

mdadm -D /dev/md0


Update Time : Thu Mar 7 20:20:40 2019
State : clean, degraded

* статус degraded говорит о проблемах с RAID.

Для восстановления, сначала удалим сбойный диск, например:

mdadm /dev/md0 —remove /dev/sdc

Теперь добавим новый:

mdadm /dev/md0 —add /dev/sde

Смотрим состояние массива:

mdadm -D /dev/md0


Update Time : Thu Mar 7 20:57:13 2019
State : clean, degraded, recovering

Rebuild Status : 40% complete

* recovering говорит, что RAID восстанавливается; Rebuild Status — текущее состояние восстановления массива (в данном примере он восстановлен на 40%).

Если синхронизация выполняется слишком медленно, можно увеличить ее скорость. Для изменения скорости синхронизации вводим:

echo ‘10000’ > /proc/sys/dev/raid/speed_limit_min

* по умолчанию скорость speed_limit_min = 1000 Кб, speed_limit_max — 200000 Кб. Для изменения скорости, можно поменять только минимальную.

Пересборка массива
Если нам нужно вернуть ранее разобранный или развалившийся массив из дисков, которые уже входили в состав RAID, вводим:

mdadm —assemble —scan

* данная команда сама найдет необходимую конфигурацию и восстановит RAID.

Также, мы можем указать, из каких дисков пересобрать массив:

mdadm —assemble /dev/md0 /dev/sdb /dev/sdc

Запасной диск (Hot Spare)
Если в массиве будет запасной диск для горячей замены, при выходе из строя одного из основных дисков, его место займет запасной.

Диском Hot Spare станет тот, который просто будет добавлен к массиву:

mdadm /dev/md0 —add /dev/sdd

Информация о массиве изменится, например:

mdadm -D /dev/md0


Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
2 8 48 1 active sync /dev/sdc

3 8 32 — spare /dev/sdd

Проверить работоспособность резерва можно вручную, симулировав выход из строя одного из дисков:

mdadm /dev/md0 —fail /dev/sdb

И смотрим состояние:

mdadm -D /dev/md0


Rebuild Status : 37% complete

Number Major Minor RaidDevice State
3 8 32 0 spare rebuilding /dev/sdd
2 8 48 1 active sync /dev/sdc

0 8 16 — faulty /dev/sdb

* как видим, начинается ребилд. На замену вышедшему из строя sdb встал hot-spare sdd.

Добавить диск к массиву
В данном примере рассмотрим вариант добавления активного диска к RAID, который будет использоваться для работы, а не в качестве запасного.

Добавляем диск к массиву:

mdadm /dev/md0 —add /dev/sde

Новый диск мы увидим в качестве spare:

4 8 16 — spare /dev/sde

Теперь расширяем RAID:

mdadm -G /dev/md0 —raid-devices=3

* в данном примере подразумевается, что у нас RAID 1 и мы добавили к нему 3-й диск.

Удаление массива
Если нам нужно полностью разобрать RAID, сначала размонтируем и остановим его:

umount /mnt

* где /mnt — каталог монтирования нашего RAID.

mdadm -S /dev/md0

Затем очищаем суперблоки на всех дисках, из которых он был собран:

mdadm —zero-superblock /dev/sdb

mdadm —zero-superblock /dev/sdc

mdadm —zero-superblock /dev/sdd

 

Источник

Установка Zimbra 8.8.11

Скачивание https://www.zimbra.com/downloads/zimbra-collaboration-open-source/

Release Notes | 3rd Party Open Source Licenses | Windows Open Source Licenses

https://gita-dev.ru/blog/ustanovka-i-nastrojka-pochtovogo-servera-zimbra-chast-pervaja-osnovy-ustanovki-i-nastrojki/ 

https://4sg.ru/ustanovka-zimbra-collaboration-suite-8-7-0/


Патч http://ikhodin.com/notepad/46-zimbra-ispravlyaem-problemu-s-priemom-pochty

После установки почтового сервера Zimbra может возникнуть проблема с приемом почты, для внутренних получателей т.е., письмо отправляется, но не доходит до абонента не доходит. Данная проблема решается следующим способом — заходим на наш сервер по SSH, логинимся по учеткой zimbra:

[root@mail ~]# su zimbra

Далее вводим две команды: (вместо — mail.mailserver.com, вводим имя нашего сервера)

zmprov ms mail.mailserver.com zimbraMtaLmtpHostLookup native
zmprov mcf zimbraMtaLmtpHostLookup native

Пере запускаем службы zimbra

zmmtactl restart

Внутренняя должна заходить!


Ошибка при входе пользователя в почту

https://forums.zimbra.org/viewtopic.php?t=64064

SSL бесплатная https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate

Бэкап в облако mega.nz из консоли CentOS 7

При всём множестве облачных сервисов для хранения данных, лишь немногие позволяют обеспечить синхронизацию данных только в консольном режиме без привлечения GUI. Из того, что я нашёл и опробовал — Яндекс.Диск и MEGA.NZ.

Яндекс.Диск очень хорошо документирован, но единственный его недостаток — всего 10 Гб на бесплатном тарифе.
Mega.NZ также очень неплохо документирован, имеет консольную версию и предоставляет целых 50 Гб на бесплатном тарифе. Его консольный клиент называется MEGAcmd. Процесс его установки и настройки в CentOS 7 описан в этом посте.

Сразу оговорка. Все прелести сервиса (50 Гб и неограниченный трафик) доступны только тем, кто регистрировался на нём сразу после его запуска. Сейчас его монетизировали и оставили только 15 Гб. Кроме того, есть квота трафика на скачивание, на загрузку квоты нет. В принципе, если использовать сервис чисто для бэкапа и скачивать архивы оттуда только по необходимости, то сервис вполне можно использовать и на бесплатном аккаунте. В крайнем случае, Pro-аккаунт стоит совсем недорого.
  1. Переходим на страницу MEGAcmd, выбираем свой дистрибутив Linux и скачиваем готовый пакет для него. Я ставлю на CentOS 7 — выбираем CentOS 7.0 и скачиваем пакет. Прямой ссылки на него нет.
  2. Перемещаем любым доступным способом полученный пакет на сервер, например WinSCP
  3. Переходим в каталог, куда поместили пакет и устанавливаем его:
    yum install /home/megacmd-CentOS_7.x86_64.rpm
  4. Подключаем megacmd к сервису командой 
    mega-login <ваш_логин> <ваш_пароль>

    Логин и пароль указываем от заранее созданной учётной записи. Если её нет, то перед выполнением вышеуказанной команды создайте новую учётку.

  5. После успешного подключения к учётке (если не выскочило ошибок, значит всё ОК), можете проверить что всё работает командой
    mega-ls

    Она выведет список каталогов в облаке (если они там есть). Подключение автоматически восстанавливается после перезагрузки сервера. Для отключения от учётной записи используйте команду 

    mega-logout
  6. На сервере создаём каталог для синхронизации
    mkdir /mega
  7. Предположим, что в облаке у нас есть синхронизируемый каталог /linux_test и мы хотим синхронизировать его с локальным каталогом /mega. Тогда команда для выполнения синхронизации будет такой: 
    mega-sync /mega/ /linux_test/

    После этого локальный каталог /mega будет непрерывно синхронизироваться с облаком. После перезагрузки сервера все параметры синхронизации восстанавливаются и нет необходимости повторно давать эту команду.

  8. Для просмотра синхронизируемых каталогов нужно выполнить команду mega-sync без параметров
  9. Для прекращения синхронизации определённого каталога сначала даём команду mega-sync без параметров и смотрим его ID. Предположим, синхронизируемый в нашем примере каталог /mega имеет ID = 0. Тогда для прекращения его синхронизации команда будет такой: 
    mega-sync -d 0

    Также можно выполнить эту команду не с ID, а с именем локального каталога: 

    mega-sync -d /mega/
Это лишь основной функционал консольного клиента mega.nz. В реальности он обладает гораздо более широкими возможностями.
 

Настраиваем Apache. Защита от F5.

Нажав клавишу F5 в окне браузера и удерживая ее в течении нескольких минут вы можете устроить легкую DDOS атаку на сайт. Функциональная клавиша F5 дает команду браузеру перезагрузить страницу.

Если вы ее нажали и удерживаете длительное время, то ваш компьютер пытается загрузить ее (страницу) много и много раз, чем создает нагрузку на сервер в виде множественных запросов. А так как возможности любого сервера не безграничны, то от переизбытка «чувств» запросов он может перестать работать.
Зависнет сервер или нет зависит от технических характеристик и настроек самого сервера, сайта и используемой CMS. В этой статье я опишу как правильно настроить вэб-сервер Apache2 чтобы даже самый скромный сервер VDS с 512 МБ памяти справлялся с большим количеством запросов, в том числе вызванных клавишей F5.

 

Подготовка к настройке сервера

Определим какой модуль MPM использует Apache2. Для CentOS это выглядит так:

# httpd -V | grep MPM

Получаем ответ:

 
Server MPM:     Prefork
 -D APACHE_MPM_DIR="server/mpm/prefork"

Отлично, у нас Server MPM: Prefork

Настройка Apache, что бы не было проблем с жором памяти

В CentOS надо отредактировать файл /etc/httpd/conf/httpd.conf.
Который по-умолчанию может иметь следующее содержание:

    StartServers          8
    MinSpareServers       5
    MaxSpareServers      20
    ServerLimit         256
    MaxClients          200
    MaxRequestsPerChild 4000

Краткое описание параметров модуля Apache MPM Prefork

StartServers — число дочерних процессов, создаваемых при запуске сервера.
MinSpareServers — минимальное число неиспользуемых (запасных) дочерних процессов сервера, ожидающих потенциальные запросы.
MaxSpareServers — максимальное число запасных процессов, ожидающих потенциальные запросы. Если это число будет превышено, лишние процессы будут убиты.
MaxClients — самый важный параметр модуля MPM prefork, устанавливает верхний предел количества одновременно активных процессов. Именно от него зависит потребление памяти. Его значение перекрывает значение предыдущих параметров.
ServerLimit обычно равен MaxClients.
MaxRequestsPerChild — как часто сервер перерабатывает процессы, убивая старые и начиная (запуская) новые. Полезен при утечках памяти Apache и его библиотек.
KeepAlive — обеспечивает долгоживущие сессии HTTP, позволяющие отправлять несколько запросов через одно и то же соединение. Полезно включить, если страницы содержат много изображений. Но если используете NGINX как проксисервер, то оставьте значение OFF.

Рекомендую прочесть:  CentOS: проверка состояния жестких дисков и RAID контроллера на серверах HP

Самый важный параметр = MaxClients, он как раз и говорит о количестве одновременных процессов вебсервера Apache.

Как узнать значение MaxClients

Определить его значение не сложно. Расчет значения приведу для сервера с размером оперативной памяти 512 МБ. Решаем, что отдаем для ресурсов Apache 50% оперативной памяти, то есть в нашем случае 256 МБ.
Определяем сколько памяти отжирает один процесс:

# ps -ylC httpd | awk '{x += $8;y += 1} END {print "Average Proccess Size (MB): "x/((y-1)*1024)}'

Получаем следующие значения:

 
Average Proccess Size (MB): 21.5185

Получается, что в среднем один процесс Apache потребляет 21 МБ. Соответственно в отведенном объеме 256 МБ мы можем запустить 12 процессов.
Исправим файл конфигурации под новое значение:

    StartServers          3
    MinSpareServers       3
    MaxSpareServers       9
    ServerLimit         256
    MaxClients           12
    MaxRequestsPerChild 3000

Остальные параметры поправил исходя из рекомендаций в интернете для сервера с ОЗУ 512 МБ.
После внесения изменений в файл конфигурации не забудьте перезагрузить Appache:

# service httpd restart

Создание SWAP файла Linux

Создание SWAP файла

  1. Создаем файл необходимого размера для swap области, где /home/swap-tmp — это имя и путь файла, а count=1024K его размер, в данном случае — 1024 Мб):
    dd if=/dev/zero of=/home/swap-tmp bs=1024 count=1024K

    На экране получим:

    [user@localhost user]#sudo dd if=/dev/zero of=/home/swap-tmp bs=1024 count=1024K
    1048576+0 записей считано
    1048576+0 записей написано
    скопировано 1073741824 байта (1,1 GB), 137,509 c, 7,8 MB/c
  2. Далее производим запись в начало файла системную информацию, которая будет используется ядром системы для работы с файлом подкачки:
    mkswap /home/swap-tmp

    После окончания операции на экране появится:

    [user@localhost user]# sudo mkswap /home/swap-tmp
    Устанавливается пространство для свопинга версии 1, размер = 1073737 кБ
    без метки, UUID=54c60583-e61a-483a-a15c-2f1be966db85
  3. Следующим шагом активируем только что созданный SWAP файл:
    swapon /home/swap-tmp

    Для просмотра результата просматриваем все объекты, которые используются для размещения виртуальной памяти:

    cat /proc/swaps
  4. После перезагрузки системы SWAP файл необходимо активировать снова или добавить строчка для автоматической загрузки в файл fstab.Редактировать файл fstab можно самостоятельно или командой, которая добавляет в конец файла fstab строку /home/swap-tmp swap swap defaults 0 0:
    echo "/home/swap-tmp swap swap defaults 0 0" | sudo tee -a /etc/fstab

    Тоже самое действие но добовление через UUID, который присваивается в пункте 2:

    # echo «UUID=54c60583-e61a-483a-a15c-2f1be966db85 swap swap defaults 0 0» | sudo tee -a /etc/fstab

Удаление SWAP файла

  1. Просматриваем все объекты, которые используются для размещения виртуальной памяти
    # cat /proc/swaps

    Выбираем ненужный.

  2. Деактивируем, для примера, созданный выше SWAP файл:
    # sudo swapoff /home/swap-tmp
  3. Удаляем SWAP файл:
    # sudo rm /home/swap-tmp

Если Вы раньше добавляли строчку в fstab, для автоматической загрузки SWAP файла при старте операционной системы, то следует ее удалить. Выводим файл /etc/fstab для редактирования на экран:

# sudo gedit /etc/fstab

В нем удаляем строчку монтирования SWAP файла.

Редактирование размера SWAP файла

Действия по редактирование объема SWAP файла сводятся к удалению уже созданного файла SWAP и созданию нового файла требуемого размера. То есть нужно сначало сделать пункт 3, а после пункт 2.

Полезные команды для CentOS

  • Включает команду ifconfig
    yum install net-tools
  • srm — для надёжного удаления файлов и директорий

Создание и удаление SWAP файла

  1. Создаем файл необходимого размера для swap области, где /home/swap-tmp — это имя и путь файла, а count=1024K его размерв, в данном случае — 1024 Мб):
    # sudo dd if=/dev/zero of=/home/swap-tmp bs=1024 count=1024K

    [user@localhost user]#sudo dd if=/dev/zero of=/home/swap-tmp bs=1024 count=1024K

    1048576+0 записей считано
    1048576+0 записей написано
    скопировано 1073741824 байта (1,1 GB), 137,509 c, 7,8 MB/c
  2. Далее производим запись в начало файла системную информацию, которая будет используется ядром системы для работы с файлом подкачки:
    # sudo mkswap /home/swap-tmp

    После окончания операции на экране появится:

    [user@localhost user]# sudo mkswap /home/swap-tmp
    Устанавливается пространство для свопинга версии 1, размер = 1073737 кБ
    без метки, UUID=54c60583-e61a-483a-a15c-2f1be966db85
  3. Следующим шагом активируем только что созданный SWAP файл:
    # sudo swapon /home/swap-tmp

    Для просмотра результата просматриваем все объекты, которые используются для размещения виртуальной памяти:

    # cat /proc/swaps
  4. После перезагрузки системы SWAP файл необходимо активировать снова или добавить строчка для автоматической загрузки в файл fstab.Редактировать файл fstab можно самостоятельно или командой, которая добавляет в конец файла fstab строку /home/swap-tmp swap swap defaults 0 0:
    # echo «/home/swap-tmp swap swap defaults 0 0» | sudo tee -a /etc/fstab

    Тоже самое действие но добовление через UUID, который присваивается в пункте 2:

    # echo «UUID=54c60583-e61a-483a-a15c-2f1be966db85 swap swap defaults 0 0» | sudo tee -a /etc/fstab
3. Удаление SWAP файла
  1. Просматриваем все объекты, которые используются для размещения виртуальной памяти
    # cat /proc/swaps

    Выбираем ненужный.

  2. Деактивируем, для примера, созданный выше SWAP файл:
    # sudo swapoff /home/swap-tmp
  3. Удаляем SWAP файл:
    # sudo rm /home/swap-tmp

Если Вы раньше добавляли строчку в fstab, для автоматической загрузки SWAP файла при старте операционной системы, то следует ее удалить. Выводим файл /etc/fstab для редактирования на экран:

# sudo gedit /etc/fstab

В нем удаляем строчку монтирования SWAP файла.

4. Редактирование размера SWAP файла

Действия по редактирование объема SWAP файла сводятся к удалению уже созданного файла SWAP и созданию нового файла требуемого размера. То есть нужно сначала сделать пункт 3, а после пункт 2.

Источник