При установке kleopatra в Antix Linux выдается ошибка

$sudo apt install kleopatra
...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 kleopatra : Depends: libkf5kcmutils5 (>= 5.2.0+git20141003) but it is not going to be installed
             Depends: libkf5notifications5 (>= 5.12.0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

последовательные попытки ручной установки пакетов по цепочке приводят к

$sudo apt install libpulse-mainloop-glib0
....
The following packages have unmet dependencies:
 libpulse-mainloop-glib0 : Depends: libpulse0 (= 10.0-1+deb9u1) but 10.0-1.0nosystemd1 is to be installed

опции -f, -m, --ignore-missing не помогают

Ручная установка

apt-get download  libpulse-mainloop-glib0
sudo dpkg -i --force-all libpulse-mainloop-glib0_10.0-1+deb9u1_i386.deb
sudo vim /var/lib/dpkg/status
# Находим зависимости для libpulse-mainloop-glib0
# и удаляем libpulse0
sudo apt-get install kleopatra

Утилита управления пакетами dpkg используется в дистрибутиве Debian, а так же в Ubuntu и многих других. Файлы пакетов имеют расширение .deb

Самые важные опции

dpkg -i mc-3.14.deb - установка пакета

dpkg -r mc - удаление пакета с сохранением файлов конфигурации

dpkg --purge mc -полное удаление пакета

dpkg -V mc - проверка целостности установленного пакета

Поисковые запросы

dpkg-query -L mc- список файлов в пакете

dpkg-query -S /etc/mc.ini - поиск пакета, которому принадлежит файл или каталог

Манипуляции с файлом .deb

dpkg-deb --contents mc-3.14.deb - просмотр содержимого

dpkg-deb -x mc-3.14.deb /tmp - извлечение файлов из архива

Для установки, удаления и обновления программ в дистрибутивах RHEL, Fedora, Mandriva, AltLinux и некоторых других используется менеджер пакетов rpm. Менеджер пакетов rpm позволяет устанавливать, удалять, верифицировать пакеты соответствующего формата, но не имеет средств для автоматического разрешения зависимостей и поиска в репозиториях. Для автоматизации установки пакетов можно воспользоваться программой yum (Yellowdog Update Manager), которая автоматически разрешает зависимости между пакетами и подгружает необходимые файлы. При необходимости собрать пакет с программой из исходных текстов можно воспользоваться rpmbuild. Для этого необходимо подготовить пакет в формате .src.rpm, включающий исходные тексты программы и .spec файл, описывающий процесс сборки.

Структура пакета

Пакеты именуются по следующей схеме: имя-версия-сборка. Распространяются пакеты в виде файлов, в название которых добавляется .архитектура.rpm. Например, squid-2.5.STABLE8–1.FC3.1.i386.rpm расшифровывается так: программа squid, версия 2.5.STABLE8, сборка 1.FC3.1, архитектура i386 (неоптимизированное приложение под i386 совместимые процессоры). Номер сборки может включать название дистрибутива (FC3 в данном случае, а может и не включать). Архитектура noarch означает скрипты, независимые от архитектуры процессора. Файлы .src.rpm содержат исходные тексты программ и устанавливаются особым образом.

Каждый пакет содержит файлы программ, библиотек, конфигурации, документации и пр., упакованные архиватором cpio. Также пакет содержит дополнительные секции:

• PROVIDE – предоставляемая функциональность (например, “mail server”) плюс файлы пакета;
• REQUIRENAME – необходимые для корректной работы пакеты, файлы и т.п. (то, что требуется в REQUIRENAME, должно присутствовать в PROVIDE ранее установленных пакетов);
• OBSOLETES – список пакетов, которые могут быть удалены т.к. их функциональность и/или файлы заменяютя данным пакетом;
• PREIN, POSTIN – скрипты, выполняемые до установки (например, остановка обновляемого демона), и скрипты, выполняемые после установки (например, правка конфигурационных файлов под конкретную машину);
• PREUN, POSTUN – скрипты, выполняемые при удалении;
• SUMMARY – краткое описание пакета;
• DESCRIPTION – подробное описание.

и т.д.

Кроме того, каждый пакет принадлежит к некоторой группе Интернет, Разработка Программ, Развлечения и т.п. Просмотреть секции rpm файла можно в mc.

В дальнейших описаниях <пакет> означает имя пакета без i386.rpm (если установлена одна версия программы, то номер версии и сборки тоже можно опустить), а <файл> означает имя файла .rpm. В качестве файла можно указывать его URL, например, http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/yum-2.2.0-0.fc3.noarch.rpm

Установка, удаление, обновление программ

Вспомогательные опции: -v – подробный вывод сообщений, -h – показ индикатора прогресса установки.

rpm -ivh <файл>... – установить пакет(ы)
rpm -Uvh <файл>... – обновить пакет(ы), если не установлены – установить
rpm -Fvh <файл>... – обновить уже установленный(е) пакет(ы)
rpm -e <пакет>... – удалить пакет(ы)

Просмотр информации об установленных пакетах или файлах rpm

Вспомогательные опции: -a – все установленные пакеты, -p – информация о файле rpm (в примерах будут приведены не везде).

rpm -q <пакет>... – проверка на наличие установленного пакета и его версии
rpm -qa - список всех пакетов
rpm -qi <пакет>... – DESCRIPTION пакета
rpm -qip <файл>... – DESCRIPTION файла
rpm -qR <пакет>... – REQUIERS пакета
rpm -ql <пакет>... – список файлов пакета
rpm -qf <файл_в_файловой_системе>... – определение принадлежности произвольного файла к одному из установленных пакетов

Проверка целостности rpm пакета

Файлы, размещенные в rpm пакете, сопровождаются вычисленной контрольной суммой и, как правило, подписаны цифровой подписью сборщика пакета. После установки пакета контрольные суммы и подписи сохраняются в базе установленных пакетов. Эти вспомогательные данные позволяют выполнить несколько проверок, например, можно проверить, что пакет создан доверенным издателем и что файлы пакета не были подменены после установки.

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

Публичные ключи для проверки подписи автоматически устанавливаются при установке из дистрибутива, а также полуавтоматически добавляются при установке rpm пакетов для подключения репозиториев yum. Файлы с ключами в CentOS устанавливаются в каталог /etc/pki/rpm-gpg/. Можно добавить ключ вручную, указав путь к локальному файлу или его url. Файл с ключем должен иметь текстовый формат 'ASCII armored'

 rpm --import PUBKEY-file

После инсталляции к ключам применимы те же команды, что и к установленным пакетам

rpm -qa gpg-pubkey* – список всех ключей
rpm -qi gpg-pubkey-db42a60e – информация (в том числе имя хозяина) о конкретном ключе
rpm -e gpg-pubkey-db42a60e – удаление ключа

Проверка файла пакета на целостность

rpm --checksig <файл>

Проверка установленного пакета на целостность

rpm --verify <пакет>

После выполнения этой команды будет выдан список изменившихся файлов с указанием, что именно в них поменялось. Информация о типе изменений состоит из строки аббревиатур, включающих:

• S – размер (Size)
• M – тип файла или права доступа (Mode)
• 5 – контрольная сумма (MD5)
• D – мажор или минор устройства устройства (Device)
• L – содержимое символической ссылки (Link)
• U – владелец (User)
• G – группа (Group)
• T – время модификации (mTime)
• P – капабилити (caPabilities)

Извлечение и упаковка файлов rpm пакета

Программа rpm2cpio извлекает файлы из RPM пакета в формате архива cpio. Для распаковки файлов вместе со структурой каталогов используется команда cpio с опциями -i – распаковать и -d – создать каталоги:

rpm2cpio <файл.rpm> | cpio -i -d

Если необходимо сохранить установленный пакет в файл, то можно воспользоваться программой rpmrebuild:

rpmrebuild <package>

Особые случаи

Eсли пакет уже установлен и его надо переустановить или необходимо понизить версию пакета, то можно к командам инсталяции или обновления добавить опцию --force.

Если установка или удаление пакета формально нарушает зависимости, но известно, что все будет хорошо, то используется опция --nodeps.

Менеджер пакетов Apt (Advanced Package Tool) надстроен над утилитой dpkg и предназначен для кэширования списков пакетов из локальных и сетевых репозиториев, вычисления зависимостей между пакетами и автоматизированных скачивания и установки пакетов.

Функциональность менеджера пакетов распределена между несколькими командами (apt-get, apt-cache и др.).

Информационные запросы apt-cache

apt-cache search Midnight - поиск пакета по регулярному выражению в названии или кратком описании

apt-cache show pkg - основные сведения о пакете

Обновление кэша, установка/обновление/удаление пакетов apt-get

apt-get update - обновление кэша

apt-get upgrade - обновление установленных пакетов до последней версии

apt-get install pkg - установка пакета

apt-get remove pkg - удаление пакета

Управление репозиториями

apt-cdrom add - добавить репозиторий на смонтированном CD

Основные операции с yum

yum search <строка> – поиск текстовой строки в названиях пакетов и комментариях

yum install <пакет>... – установка пакетов и всего для них необходимого
yum install <файл.rpm> – установка из локального файла
yum upgrade <пакет>... – обновление пакетов до самой последней версии
yum downgrade <пакет-версия>... – откат обновления до определённой версии
yum remove <пакет>... – удаление пакета. Если этот пакет необходим другим, то будут удалены все

yum list z\* – список пакетов на букву z. Пакеты разбиты на установленные и доступные.
yum info <пакет> – просмотр информации о пакете
yum repolist – список всех репозиториев

yum clean – очистка кэша

Описания репозиториев для yum

Описания репозиториев находятся в каталоге /etc/yum.repos.d/ в файлах с расширением .repo.

Формат файла

#в одном файле могут быть описаны несколько репозиториев, каждый  размещается в своей секции  
[epel]  

# человекочитаемое имя. $basearch - архитектура процессора, $releasever - версия дистрибутива
name=Extra Packages for Enterprise Linux $releasever - $basearch

#местоположение репозитория; если репозиторий локальный, то url может иметь вид
#baseurl=file:///var/repos/myrepo
baseurl=http://download.fedoraproject.org/pub/epel/$releasever/$basearch

#если у проекта есть несколько зеркал, то baseurl может быть заменен на путь к списку зеркал в формате xml
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

#репозиторий можно отключить, поставив enabled=0
enabled=1

#надо ли проверять цифровую подпись пакетов и путь к файлу ключа
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

#если мы предпочитаем получать определённые пакеты из другого репозитория,
# то можем выборочно отключить их в этом
exclude=nagios*

Подготовка локального репозитория для программы yum

1. Скопировать rpm пакеты своего репозитория в каталог <dir>

2. Проверить, что установлен пакет createrepo, и установить, если необходимо

        rpm -q createrepo
        sudo yum install createrepo
   

3. Создать XML данные репозитория

         createrepo <dir>
   

Для загрузки через EFI к ядру Linux добавляется заголовок исполняемого файла в формате PE/COFF, что позволяет использовать EFI для загрузки. Часть ядра, связанная с этим заголовком и кодом, на который передаётся управление называется EFI Stub — заглушка для EFI. Исходный код заглушки для архитектуры x86 находится в файлах arch/x86/boot/header.S и arch/x86/boot/compressed/eboot.c.

В x86 используется bzImage, в arm — zImage в arm64 — неупакованное ядро.

Для загрузки ядра файл bzImage, расположенный в arch/x86/boot/bzImage, необходимо скопировать в системный раздел EFI (ESP) на диске и переименовать с расширением .efi. Без расширения загрузчик EFI откажется его выполнить. Запуск bzImage.efi из файловых систем Linux загрузчиком EFI не поддерживается. Для архитектур arm и arm64 ядро также нужно скопировать в системный раздел, но можно не переименовывать.

Аргументы ядра в командной строке EFI указываются после bzImage.efi, например:

fs0:\Linux> bzImage.efi console=ttyS0 root=/dev/sda4 initrd=\Kernels\initrd-large.img

Параметр initrd= обрабатывается в заглушке, остальные передаются в ядро. Путь к initrd записывается как абсолютный путь от корня ESP. В качестве разделителя каталогов используется обратный слеш.

Для записи строки загрузки Linux в меню EFI можно воспользоваться efibootmgr:

efibootmgr --create \
--disk /dev/sda1 \
--label 'Linux 5.9.1 i915' \ # Строка в меню загрузки
--loader '\EFI\Boot\5.9.1.efi' \ # Образ для загрузки
'initrd=\EFI\gentoo\initramfs.img' \
'root=/dev/sda1 pcie_aspm=off'

GRUB (GRand Unified Boot Loader) – Великий унифицированный загрузчик. Разработан в рамках проекта GNU как образцовая реализация мультизагрузчика, способного загружать различные ОС с различных разделов одного диска или различные версии одной ОС в рамках одного раздела.

В настоящий момент под названием GRUB известны две существенно отличающиеся версии программы. Версия 0.97 – "старый" или "legacy" GRUB – используется в RHEL до версии 6 включительно. В этой статье речь именно о нём. GRUB версии > 1.0 – это почти полностью переписанный вариант программы, используемый в Ubuntu, Fedora и многих других дистрибутивах.

Поскольку в MBR есть только 384 байт для размещения загрузчика – GRUB поделен на две части stage1 и stage2. Размер stage1 равен одному сектору на диске – 512 байт. При этом реально используется только 384, а остальное зарезервировано. Stage2 – довольно крупная программа, содержащая драйверы нескольких ФС, интерпретатор командной строки и несколько вспомогательных функций. Её размер составляет примерно 124 КБ. При инсталляции GRUB компонент stage2 должен быть размещён в последовательных секторах на диске, а адрес первого сектора и количество секторов должны быть прописаны в секторе, содержащем stage1. Если носитель не позволяет разместить stage2 в фиксированных секторах, то применяется промежуточный загрузчик stage1.5, поддерживающий одну конкретную ФС и занимающий менее 16 КБ.

Список ФС, поддерживаемых stage2/1.5 (ls /boot/grub/*1_5)

• e2fs_stage1_5
• fat_stage1_5
• ffs_stage1_5
• iso9660_stage1_5
• jfs_stage1_5
• minix_stage1_5
• reiserfs_stage1_5
• ufs2_stage1_5
• vstafs_stage1_5
• xfs_stage1_5

Иногда хочется сделать в initrd что-то нестандартное, что не предусмотрено стандартным скриптом (mkinitrd, mkinitramfs, dracut и т.п.). В этом случае можно распаковать существующий образ, поправить его руками и снова запаковать. Формат файла - архив cpio сжатый gzip. Единственная тонкость - для cpio надо указывать опцию, задающую внутренний формат архива -H newc

mkdir initrd; cd initrd
gunzip -c /boot/initramfs-2.6.32.158.img | cpio -i --make-directories 
#внесение правок
find . | cpio -o -H newc | gzip > /boot/myinitrd.img

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

#Упаковка (фрагмент из dracut CentOS 6)
find . |cpio -R root:root -H newc -o --quiet|  $gzip -9 > "$outfile"

В CentOS7 структура файла изменилась. В начало приклеен ещё один маленький несжатый архив cpio "early_initramfs" он же "microcode blob" (необязательный). Программа skipcpio ищет в полученном файле признак конца архива (строку "TRAILER!!!") и выдает хвост. Для сжатия можно использовать различные программы (gzip,bzip2, xz). По умолчанию используется gzip.

#Распаковка:
/usr/lib/dracut/skipcpio /boot/initramfs-3.10.0-957.el7.x86_64.img | zcat | cpio -i  --make-directories 
#Упаковка
find . |cpio -c -o |xz -z -9 -C crc32 -F xz > /boot/myinitrd.img

Иногда возникает ситуация, при которой загрузка Linux невозможна из за неправильно собранного образа диска initrd. Возникает ситуация курицы и яйца: чтобы исправить initrd необходимо загрузить Linux, чтобы загрузить Linux нужен исправленный initrd.

В CentOS и аналогичных системах последовательность действий такова:

Загрузиться с установочного диска в режим восстановления - Rescue mode. Для этого в момент загрузки на приглашение boot: необходимо ввести linux rescue

Если всё пойдёт нормально, то корневой каталог основной системы будет смонтирован в /mnt/sysimage, загрузочный каталог в /mnt/sysimage/boot. Кроме того текущие каталоги /proc, /sys и /dev будут смонтированы в соответствующие подкаталоги /mnt/sysimage. Если это не случится, то придётся проделать эти операции вручную.

Когда все каталоги смонтированы, можно сменить корневой каталог

#если выяснится, что вы что-то забыли смонтировать, то можно выйти по ^D
chroot /mnt/sysimage

и пересобрать initrd

В CentOS 6

#копируем старый файл
cp -p /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
#создаём новый
dracut -f 
#если версия ядра в основной системе отличается от версии на установочном диске, указываем её явно
dracut -f /boot/initramfs-2.6.32-358.el6.x86_64.img 2.6.32-358.el6.x86_64

В CentOS 5

#копируем старый файл
cp -p /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img.bak
#создаём новый
mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r)
#если версия ядра в основной системе отличается от версии на установочном диске, указываем её явно
mkinitrd -f -v /boot/initrd-2.6.18-371.el5.img 2.6.18-371.el5

Перезагрузка

cd /
sync
telinit 6

Полный пример с драйвером i2o_block (SCSI адаптер Adaptec 2010S), который не загружается автоматически. Пример выполняется в CentOS 5, поскольку в стандартном ядре CentOS 6 поддержка этого драйвера отключена.

После загрузки с CD в Rescue mode выдаётся сообщение, что Linux разделы не найдены и их надо монтировать самостоятельно.

#Загружаем драйвер
insmod i2o_block

#Проверяем, что всё сработало
lsmod
....
dmesg
...

#Создаём файлы устройств на основе информации в dmesg
mkdir /dev/i2o
mknod /dev/i2o/hda b 80 0
mknod /dev/i2o/hda1 b 80 1
mknod /dev/i2o/hda2 b 80 2

#Активируем VolumeGroup
lvm vgchange -a y

#Монтируем тома
mkdir /mnt/sysimage
mount /dev/mapper/VolGroup00-LogVol00 /mnt/sysimage
mount /dev/i2o/hda1 /mnt/sysimage/boot

#Монтируем спецкаталоги
mount --bind /proc /mnt/sysimage/proc
mount --bind /dev /mnt/sysimage/dev
mount --bind /sys /mnt/sysimage/sys

Далее по инструкции, только при создании образа диска надо указать программе mkinitrd дополнительную опцию --preload=i2o_block и отключить сервисы readahead, поскольку они приводят к зависанию драйвера i2o_block:

chkconfig early-readahead off
chkconfig later-readahead off

Можно посмотреть видео https://youtu.be/QlLwJhKrMGA.

В прошлый раз мы говорили о том, что происходит при загрузке Linux: вначале стартует загрузчик, он загружает ядро и развертывает временный диск в оперативной памяти, ядро запускает процесс init, init находит настоящий корневой диск, производит такой хитрый переворот - вместо временного виртуального диска на это же самое место в корневой каталог монтируется реальный диск, с этого реального дисков процесс init загружает в себя другой init, который есть на этом реальном диске. После всех этих операций UNIX переходит в состояние обычной работы.

В этой лекции я расскажу, что делает классическая программа init в сочетании со скриптами rc.d в стиле System V (Систем пять). System V - это классическая версия UNIX на которой построены коммерческие UNIX.

Судя по названию, rc.d это некий каталог. Есть такая традиция UNIX - если вся конфигурация чего-либо умещается в один файл, и он называет config, то при разбиении его на отдельные файлы, которые подключаются к основному, создают каталог с аналогичным именем и добавляют к имени .d – config.d. Буква d означает, что это директория и там лежат вспомогательные части конфигурационного файла. У формата конфигурационных файлов программы init есть две традиции: вариант System V, в котором каждая деталь конфигурации держится в отдельном файле в каталоге rc.d, и традиция BSD систем, в которой есть один файл /etc/rc, содержащий много скриптов и переменных, которые отвечают за поведение системы.

В любом случае, при старте системы у нас создается процесс с PID=1, в котором запущена программа, которая называется init. Как вы видели в прошлый раз, если программу init убить, то ядро впадает в панику и прекращает всяческую работу.

Классический System V init читает файл /etc/inittab и выполняет ряд предписаний, которые прописаны в этом файле. Inittab этот текстовый файл каждая строка которого, это, по сути дела, одна команда или какое-то правило поведения. Inittab выглядит так:

id:3:initdefault:

si::sysinit:/etc/rc.d/rc.sysinit

l3:3:wait:/etc/rc.d/rc 3

1:2345:respawn:/sbin/mingetty tty1

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Вначале строки стоит метка. В чем большой смысл этой метки я не очень понимаю. Можно считать, что это простой текст и все. Вторым пунктом стоит либо так называемый уровень загрузки, либо пустое значение. Уровень загрузки — это либо одно число от 0 до 6, либо список чисел через запятую. Дальше идет некое действие. Действия бывают следующие: wait, respawn, sysinit, ctrlaltdel. Есть и другие действия, но это самые используемые. Наконец, в конце строки написана некая команда с именем исполняемого файла и аргументов, которые этой команде надо передать.

Действие sysinit выполняется однократно при старте системы.

Действие ctrlaltdel это на самом деле не совсем действие – это обработчик сочетания клавиш control alt del. Само нажатие перехватывается ядром системы, и информация об этом пересылается в процесс init, который должен выполнить определенную команду. Например, может быть выполнена команда shutdown, которая выполнит выключение компьютера. В принципе сюда можно прописать любую другую программу, например, echo, которая после нажатия control alt del будет выдавать на все терминалы системы какое-нибудь сообщение. камина консолью так

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

Действие respawn означает, что надо запустить программу и не дожидаясь ее завершения, перейти в дальнейшем действиям. Если эта программа в последующем завершится, то необходимо ее рестартовать.

Итак, есть однократное выполнение с ожиданием результатов и многократное выполнение в асинхронном режиме – запустились, дождались пока закончить, запустили слова.

Уровни загрузки — это некая условность, которая позволяет управлять загружаемыми службами. Ближайший аналог в windows – это загрузка в безопасном режиме, когда грузится только ограниченное число драйверов и стартует минимальное количество служб, загрузка с отладкой, когда каждое действие дополнительно протоколируются и обычная полноценная загрузка.

В Linux по традиции выделяется 6 вариантов загрузки. Это деление довольно условно.

0 и 6 это выключение. 0 - полное выключение электричество, а 6 - режим перезагрузки.

4 в Linux вообще пропущен

Остаются четыре уровня загрузки:

1 - однопользовательский режим. Если передать загрузчику ключевое слово single, то мы окажемся в однопользовательском режиме, где запущен только один процесса и это шелл администратора системы. Этот режим используется для восстановления системы.

3 - нормальный многопользовательский текстовый режим, когда запущены все службы, работает сеть, работают все драйверы.

2 - тоже текстовый режим, но без подключения сетевых дисков. Дело в том, что традиционные сетевая файловая система nfs, которая используется в UNIX, чрезвычайно устойчива к повреждениям сети. Если мы выключили файловый сервер или обрезали сетевой кабель, то сетевая файловая система nfs будет предпринимать многочисленные попытки восстановиться и эти попытки настолько длительны, что я ни разу не смог дождаться времени, когда же наконец появится сообщение об ошибке. Возможно это произойдёт через час, а может и через 6 часов. Всё это время драйвер nfs будет держать компьютер, не давая ничего сделать. Поэтому, если у нас упала сеть или файловый сервер в настройках написано, что при старте необходимо подмонтировать внешние диски, то попытка загрузится в полноценный режим приведёт к тому, что у вас все зависнет. Для этого случая и предусмотрен второй вариант загрузки - все как в третьем, только сетевые диски не подключаются. Сам сетевой адаптер работает, IP адрес назначается, интернет доступен.

5 - то же самое что и 3, но с запуском x window - графического интерфейса.

Можно считать, что между уровнями есть некоторая последовательность переходов:

режим 2 включает себя 1 + многопользовательский режим. 3 включает 2 + монтирование сетевых файловых систем. Наконец, 5 включает в себя 3 + запуск графической подсистемы. Будет ли это реализовано последовательно или нет - это проблема дистрибутива. Вообще говоря, администраторы могут самостоятельно настроить файл inittab так, чтобы эти режимы запускались последовательно, а можно сделать так чтобы все было абсолютно независимо - переключаясь в очередной режим, убираем все что было сделано на предыдущем шаге, и настраиваем все с нуля.

Рассмотрим строки реального файла. Они очень просты.

l3:3:wait:/etc/rc.d/rc 3

Запускается какая-то программа, которая должна выполнить все необходимые действия, которые ожидаются на третьем уровне. Наверно, на третьем уровне нужно настроить сетевые интерфейсы, запустить драйвер терминалов, стартовать какие-то службы. Только после того, как всё этого завершится мы сможем работать в системе. Поскольку надо дождаться завершения запуска, мы выбираем действие wait.

Программа запуска называется rc и запускается с номером уровня в качестве параметра. Сама программа init достаточно простая. Она умеет построчно читать свой файл с простым синтаксисом и стартовать новые процессы, запуская какие-то вспомогательные программы. Вся логика уровней загрузки спрятана в скрипте rc. Запустив rc с параметром 3 мы перейдем на третий уровень, с параметром 5 - на пятый.

Программа rc тоже очень простая. Это скрипт который выполняет все файлы в каталогах, соответствующих уровню загрузки, например, /etc/rc3.d/. В этих каталогах находятся исполняемые файлы, которые принимают один параметр - либо start, либо stop. Если файл запущен с параметром start, то он стартует службу, если с параметром stop, то останавливает её. Например, network start будет настраивать сетевые интерфейсы, а network stop будет переводить интерфейсы в выключенное состояние. Кроме сетевых интерфейсов есть скрипты подключения/отключение сетевых файловых систем, запуска/остановки сервисов и т.д.

Имена файлов в каталогах построенным по определенным правилам. Они начинаются либо с буквы K либо с буквы S, за которыми идет число и имя службы.

Скрипт rc просматриваем содержимого каталога rc3 и выбирает оттуда все файлы которые начинаются с буквы K (kill). Файлы упорядочиваются в порядке возрастания номера и выполняются с параметром stop. Потом те же действия выполняются с файлами на букву S (start), которые запускаются с параметром start. Вот в общем и вся процедура перехода на определенный уровень.

Можно предположить, что в каталоге /etc/rc0.d/ лежат только файлы, начинающиеся на букву K, поскольку при выключении надо все остановить, а в каталоге /etc/rc1.d/ будет один файл на буку S для запуска консоли администратора.

Для простоты программирования есть отдельный каталог /etc/init.d/, в котором лежат те же самые файлы только без буквы цифр в начале имени. На самом деле, файлы в каталогах уровней это просто символические ссылки на основные файлы. Так /etc/rc3.d/S10apache это ссылка на файл /etc/init.d/apache. Буквы и цифры в названии ссылок нужны для того, чтобы скрипт rc вызвал их в нужном порядке и с нужными аргументами.

В системах, которые построены по такому принципу, чтобы стартовать или остановить какую-либо службу в каталоге /etc/init.d/ надо найти файл который, который ей соответствует, и запустить его с параметром start или stop. Чем не нравится запускать службы именно таким способом - явно вызывая скрипты. Дело в том, что в командной строке linux замечательно работает автодополнение. С его помощью очень быстро можно ввести путь до файла запуска.

Чтобы спрятать от пользователя конкретную реализацию поверх системы скриптов и символических ссылок написаны две вспомогательные программы.

Программа chkconfig позволяет манипулировать символическими ссылками на соответствующие скрипты. Чтобы посмотреть, что стартует, а что останавливаться на каждом из уровней можно воспользоваться командой ls и выдать список скриптов в соответствующем каталоге, но проще воспользоваться командой chkconfig –list. Программа chkconfig пробегает по всем каталогам rc и выдает список того что стартует, а что останавливается на каждом уровне. Если мы хотим, чтобы при старте системы у нас что-то автоматически стартовала определенная службу мы выполняем chkconfig <имя службы> on и скрипт создает ссылку для запуска в нужном каталоге и с правильным именем. Запуск chkconfig <имя службы> off приводит к удалению ссылки для запуска и созданию ссылки для остановки. Таким образом программа chkconfig позволяет управлять списком служб, которые стартуют в момент старта системы.

Ещё одна программа - service используется для ручного запуска и остановки служб. Service это обертка, которая позволяет не обращаться напрямую к скрипту, а указать имя службы и сказать хотим мы ее стартовать или остановить. В bash, который я использую, нет автодополнения для команды service, поэтому мне проще набрать путь к скриптам.

В стартовых скриптах аргументы start и stop должны обрабатываться обязательно. Кроме того, можно придумать какие-то свои аргументы, которые будут делать что-то полезное.

В большинстве скриптов реализована опция status, которая показывает запущена служба или нет. Когда мы выполняем start, то скрипт после успешного запуска службы получает ее идентификатор PID и записывать его в определенный файл. По команде stop файл удаляется. Обычно такие файлы создаются в каталоге /var/run/. Команда status проверяет есть ли такой файл. Его нет, то сообщает, что служба не запущена. Если файл есть, то она извлекает из него идентификатор процесса и проверяет текущий список процессов. Если этот идентификатор присутствует все запущено, если программа по каким-то причинам поломалась, то статус выдаёт, что была сделана попытка запустить эту службу - файл существует, но сама служба не запущена.

Опция restart последовательно выполняет внутри скрипта две команды – сначала stop, а потом старт. Это совершенно необязательная команда - просто удобная. Наконец, есть службы, которые позволяет на ходу перечитать какие-то конфигурационные файлы. Для них добавляют команду reload, задачей которой является отправка службе сигнала о том, что конфигурация изменилась. Отдельный случай, команды save и load для сохранения конфигурации брандмауэра.

Если администратор системы вместо остановки или старта отдельных службы хочет всю систему перевести на определенный уровень, то этого можно достичь одним из двух способов. Можно вызвать прямо программу /sbin/init. Если ее вызвать с определенным числом в качестве параметра, то она выполнит все инструкцию из файла inittab, для которых прописывал соответствующий уровень. Если запустить, например, /sbin/init 1, то init найдет в своем конфигурационном файле все строчки, в которых есть уровень 1 и выполнит их. В некоторых системах команда shutdown реализована как /sbin/init 0, поскольку нулевой уровень соответствует остановке системы. В последнее время для перехода между уровнями появилась специальная программа под названием telinit, которая является ссылкой на init. Её задача – переслать процессу init сигнал о том, что администратор желает перейти на определенный уровень. telinit q сообщает init о том, что надо перечитать файл inittab. В старых системах это достигалось посылкой сигнала SIGHUP процессу с PID=1 (kill –HUP 1).

Ещё несколько строк в inittab, это запуск терминалов

1:2345:respawn:/sbin/mingetty tty1

Для того, чтобы обеспечить диалоговую доступ к системе, вы inittabе может присутствовать некоторое количество строчек такого рода. 2345 это уровни, на которых надо запускать команду, respawn означает, что программу надо перезапускать в случае завершения. Программа getty – это программа управления терминалом. Традиционно терминал в UNIX называется телетайпом, поскольку первыми терминалами были электрические пишущие машинка. Соответственно, tty это сокращение от телетайпа. Mingetty – программа, которая умеет работать с виртуальными терминалами на персональном компьютере. Она умеет настраивать драйвер терминала, а в качестве параметров получает имя устройства терминала, который надо настроить. В каталоге /dev/ есть файл устройства tty1, который соответствует первому виртуальному терминалу. Если бы у нас был модем и мы хотели бы инициализировать его момент загрузки, то могли бы вызвать getty с параметром ttyS0, который соответствует порту COM1. При инициализации модема можно было бы задать дополнительные параметры: скорость соединения 19200 бод, 7 или 8 бит в байте, четность, количество стоп-битов.

S0:2345:respawn:/sbin/getty ttyS0 19200 8 n 1

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

Текстовые пользовательские сеансы устроены на таких цепочках: сначала init делает свою копию и запускает в ней программу mingetty. Mingetty инициализирует терминал и клавиатуру, а потом запускает в том же процессе программу login. Login выводит на экран приглашения на ввод имени и пароля и, если все прошло успешно то назначает себе привилегии пользователя и в том же процессе, затирая самого себя, запускает интерпретатор пользователя, например, bash. Когда пользователь набирает команду exit, то интерпретатор завершает жизненный путь этого процесса. Когда процесс завершается, init получает об этом сигнал. Init смотрит, что полагается делать, видит действие respawn, снова запускает программу mingetty, которая заново инициализирует терминал и все повторяется. Таким образом каждый сеанс находится внутри одного процесса. Как только мы вышли из сеанса наш процесс закончился и тотчас же запустилась программа, которая почистит за нами терминал и восстановит все настройки по умолчанию.

В файле inittab есть есть ещё одно специальное ключевое слово initdefault - уровень по умолчанию. Если через ядро init получил параметр single, то мы загрузимся на уровень 1. Если через загрузчик ничего не передали, то используется значение по умолчанию. Если после установки графической оболочки оказалось, что наш компьютер слабоват для графики, то можно установит уровень по умолчанию на 3, и после следующей перезагрузки мы попадаем на третий уровень - то есть в текстовый режим. Установили систему без графического режима, потом доустановили все пакеты для x window, поменяли уровень по умолчанию на 5 и после следующей перезагрузки попали сразу в графический режим.

В этой системе скриптов иногда хочется сделать что-то свое, например, при старте удалить все файлы в каталоге /tmp/. Для этого есть отдельный файл под названием /etc/rc.local, который запускается после всех остальных. Это просто скрипт без параметров, в который можно прописать всё, что угодно. Например, на одном из моих роутеров в момент старта системы в этом файле прописываются таблицы маршрутизации. Мне было лень искать где находятся соответствующие стандартные скрипты из дистрибутива и проще оказалось прописать команды в rc.local.

firewalld позволяет описывать брандмауэр в терминах зон, сервисов и т.д. Конфигурация firewalld компилируется в правила iptables или nftables.

Список стандартных сервисов

firewall-cmd --get-services

Добавление разрешения на сервис или порт

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-port=4444/tcp

Удаление разрешения

firewall-cmd --permanent --remove-service=ssh

Список установленных разрешений

firewall-cmd --permanent --list-all

После всех установок необходимо их применить

firewall-cmd --reload

Для запуска сетевой службы в стиле inetd, но через systemd необходимо создать два файла:

1. Файл, описывающий сокет, на котором ожидается соединение;
2. Файл, описывающий сервис - программу, которую надо запустить после подключения клиента к сокету.

В файле сокета ListenStream - указывает на протокол TCP (для UDP используется параметр ListenDatagram=). В качестве значения ListenStream может быть указан номер порта или пара IP:Port. Параметр Accept=yes указывает на то, что для каждого подключения надо стартовать отдельный экземпляр программы. Чтобы проинформировать приложение о свойствах соединения, ему передаются переменные окружения REMOTE_ADDR и REMOTE_PORT.

/etc/systemd/system/baz.socket:

[Unit]
Description=Baz Socket

[Socket]
ListenStream=127.0.0.1:9999
Accept=yes

[Install]
WantedBy=sockets.target

Имя файла сервиса должно заканчиваться на @, чтобы указать, что одновременно может быть запущено много экземпляров данной программы. В данной конфигурации стандартный ввод программы будет назначен на /dev/null, стандартный вывод будет перенаправлен в сокет, сообщения об ошибках будут сохранены в логах journald. Программа может быть написана на чем угодно. Переменным окружения VAR1 и VAR2 будут назначены значения "word1 word2" и 'word3" соответственно, текущий каталог будет изменен на /tmp, вместо %i будет подставлено имя экземпляра программы, которое также будет видно в списке запущенных сервисов между @ и .service.

/etc/systemd/system/baz@.service:

[Unit]
Description=Baz Service
Requires=baz.socket

[Service]
Type=simple
Environment="VAR1=word1 word2" VAR2=word3
ExecStart=/usr/local/baz %i
WorkingDirectory=/tmp
StandardInput=socket
StandardOutput=socket
StandardError=journal
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

/usr/local/bin/baz:

#!/bin/bash
pwd
echo ${VAR1}
echo ${VAR2}
echo $1

Отключение IPv6 в ядре

Добавляем в файл /etc/sysctl.conf (или куда-нибудь в /etc/sysctl.d/50-noipv6.conf) строки

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Обновляем текущую конфигурацию ядра sysctl -p.

Применяем настройки к сетевым интерфейсам systemctl restart network

Проверяем адреса на сетевых интерфейсах ip addr

Отключение IPv6 в Apache

В конфигурации исправляем директиву Listen 80 на

Listen 0.0.0.0:80

Отключение IPv6 в Squid

Добавляем в squid.conf

dns_v4_first on

Отключение IPv6 в Postfix

В main.cf

inet_protocols = ipv4

Отключение IPv6 в BIND

Для того, чтобы сам BIND не использовал IPv6 при запуске надо указать опцию -4. В CentOS это делается строчкой в файле /etc/sysconfig/named

OPTIONS="-4"

Дополнительно можно добавить в named.conf опцию

listen-on-v6 port 53 { none; };

Для того, чтобы BIND не выдавал записи AAAA (адреса IPv6) клиентам, подключенным по IPv4 необходимо добавить в файл named.conf опцию

filter-aaaa-on-v4 yes;

Для доступа к сетевым картам в Linux используются так называемые интерфейсы. Интерфейсы это не файлы устройств и их нет в каталоге /dev. Интерфейсы создаются динамически и не всегда связаны с сетевыми картами. Например интерфейс ppp0 - это интерфейс VPNа, организованного по протоколу PPTP, а интерфейс lo это виртуальная сетевая карта с адресом localhost (127.0.0.1). В Linux имена интерфейсов традиционно состоят из мнемонического типа интерфейса и его порядкового номера. Карты ethernet доступны через интерфейсы eth0, eth1 и т.д. В системах, использующих systemd способ именования другой - интерфейсы имеют имена вида enp2s0 (en -Ethernet, p - PCI, 2 - номер на шине) Список всех интерфейсов можно посмотреть командой ifconfig -a или ip link.

Привязка интерфейса к карте

При наличии нескольких сетевых карт возникает вопрос о порядке их нумерации. В CentOS 6 эта задача возложена на подсистему обнаружения и конфигурации устройств - udev. В системах с systemd правила именования встроены в udev, но могот быть переопределены, как написано ниже.

Конфигурационный файл переименования интерфейсов обновляется автоматически при первом обнаружении очередной сетевой карты и находится в файле /etc/udev/rules.d/70-persistent-net.rules. Файл состоит из строк такого содержания:

# PCI device 0x1af4:0x1000 (virtio-pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:29:24:1e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Видно, что нумерация опирается на аппаратный (MAC) адрес карты. Если в компьютере заменить карту, то интерфейс eth0 станет недоступным, а новая карта получит имя eth1. Если есть желание вручную назначить имена картам, то можно отредактировать этот файл, выставив желаемые соответствия между MAC адресами именами интерфейсов (возможно потребуется перезагрузка).

ifcfg

Классическая утилита конфигурации сетевых интерфейсов ifcfg

#просмотр списка активных интерфейсов
ifcfg

#просмотр конфигурации конкретного интерфейса
ifcfg eth0

#просмотр списка доступных интерфейсов
ifcfg -a

#настройка ip адреса и активация интерфейса
ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up 

#деактивация интерфейса
ifconfig eth0 down

route

Настройка таблицы маршрутизации route

#добавление шлюза по умолчанию
route add default gw 192.168.0.1

#добавление маршрута в локальную сеть
 route add -net 192.56.76.0 netmask 255.255.255.0 dev eth0

#добавление маршрута в удаленную сеть
route add -net 192.57.66.0 netmask 255.255.255.0 gw 192.168.0.2

#удаление маршрута
route del -net 192.57.66.0 netmask 255.255.255.0 gw 192.168.0.2

#просмотр таблицы маршрутизации
route
#или
netstat -r

ip

В современных дистрибутивах линукса на смену ifconfig и route приходит универсальная утилита ip

#просмотр списка доступных интерфейсов
ip link

#просмотр статистики по интерфейсам
ip -s link

#просмотр ip адресов
ip addr

#просмотр таблицы маршрутизации
ip route

DNS

Адреса серверов DNS и имя локального домена вписываются в файл /etc/resolv.conf

search example.com
nameserver 8.8.8.8

Для написания сетевой службы в Linux не обязательно уметь программировать сокеты. Сокет, с точки зрения прикладной программы, выглядит как обычный файловый дескриптор, из которого можно читать и в который можно писать любыми стандартными функциями ввода/вывода. Поэтому появляется возможность перенаправить стандартный ввод/вывод любой программы в заранее подготовленный сокет. Для такого перенаправления служит программа xinetd.

Конфигурация xinetd, как правило, разделяется на две части: значения по умолчанию – /etc/xinetd.conf и настройки для отдельных служб, по одному файлу в каталоге /etc/xinetd.d/ на службу.

Чтобы запустить свою сетевую службу, необходимо создать ещё один файл в /etc/xinetd.d/. Имя файла особого значения не имеет, но обычно выбирается по имени службы. Предположим, что служба называется mynetd, запускается от имени пользователя user1 и выполняет команду sleep 10. Служба должна ожидать TCP соединение на порту 8888.

Конфигурационный файл /etc/xinetd.d/mynetd будет выглядеть так:

service mynetd
{
    disable = no
    # Если не написать UNLISTED, то xinetd будет искать имя службы и номер порта
    # в файле /etc/services
     type = UNLISTED

    # stream = TCP, datagram = UDP
    socket_type = stream
    port = 8888
    # Можно считать, что для протокола TCP wait всегда равен 'no',
    # а для протокола UDP – всегда 'yes'
    wait = no

    user = user1
    # При считывании конфигурации файл службы должен существовать и заданный пользователь
    # должен иметь право на его выполнение
      server = /bin/sleep
      server_args = 10
}

Параметр wait интерпретируется следующим образом: если socket_type = datagram и wait = yes, то при появлении на порту данных стартует новый процесс со входом/выходом, перенаправленным в сокет. Пока этот процесс не завершится, xinetd не контролирует наличие новых данных на порту, оставляя их запущенной программе. Если поставить wait = no, то на каждую дейтаграмму будет запускаться новый процесс, разделяющий со своими предшественниками общий сокет. В такой ситуации невозможно предсказать, какой копии программы достанутся входные данные из сокета. В принципе, такой подход возможен, если обработка дейтаграммы идёт долго, а писать многопоточный сервис лень. Для TCP ситуация обратная, wait = yes имеет смысл только для многопоточных программ, иначе первый процесс захватит сокет и не отдаст его, пока программа не завершится.

TCP Wrappers – изначально набор вспомогательных программ 'запускалок' (tcpd, miscd и вспомогательные программы), для контроля за IP адресами клиентов, стартующих сетевые сервисы через inetd. Основная функция, управляющая проверкой правил, hosts_access(request) была в последующем выделена в отдельную библиотеку libwrap. В настоящее время эту библиотеку используют самые разнообразные сервисы, такие как xinetd, sshd, rsyncs и т.п. Полный список программ, использующих TCP Wrappers, можно получить, выполнив следующую команду:

strings -f  /usr/sbin/* /usr/local/sbin/* |  grep hosts_access

Функция hosts_access использует два конфигурационных файла /etc/hosts.allow и /etc/hosts.deny (в FreeBSD только /etc/hosts.allow), которые могут иметь классический или расширенный синтаксис.

Классический вариант

В классическом варианте вначале проверяются все правила из hosts.allow. Если хоть одно правило применимо к паре сервис-клиент, то соединение устанавливается. Затем проверяются все правила из hosts.deny. При нахождении соответствия соединение отклоняется. Если правила нет, то соединение устанавливается. Чтобы явно разрешить доступ только по правилам из hosts.allow, необходимо добавить в hosts.deny правило ALL:ALL.

Классический синтаксис описан в man странице HOSTS_ACCESS(5). Файлы состоят из строк вида

daemon_list : client_list [ : shell_command ]

где

• daemon_list – список имён сервисов (в xinetd имена прописываются явно в конфигурации службы, для остальных программ они совпадают с именем исполняемого файла) или ключевое слово ALL;
• client_list – список имён/адресов клиентов;
• shell_command – вспомогательная команда, например, для логирования событий. В современном варианте это поле имеет другой формат.

Современный вариант

Файлы /etc/hosts.allow и /etc/hosts.deny эквивалентны по своему назначению. Каждое правило может содержать результат – allow или deny. Если в правиле результат не прописан явно, то он вычисляется по правилу классического варианта. Можно считать, что все правила находятся hosts.allow, а hosts.deny остается пустым. Выполняется первое найденное правило.

Синтаксис правил описан в man странице HOSTS_OPTIONS(5). Файлы состоят из строк вида

daemon_list : client_list : option [: option ...]

daemon_list, client_list полностью совместимы с классическим синтаксисом, а опции позволяют понизить привилегии, запустить дополнительную программу параллельно с сервисом или вместо него, и, наконец, принять решение allow или deny. Опции выполняются слева направо. Опция allow/deny должна стоять последней, поскольку после неё произойдёт запуск сервиса или прекращение работы.

Для запуска дополнительных программ используются две опции: spawn shell_command – запуск программы в параллельном процессе одновременно с сетевым сервисом, и twist shell_command – запуск программы в текущем процессе вместо сервиса. Командам в качестве параметров можно передать некоторую информацию о соединении. spawn не влияет на запуск основного сервиса, поэтому за ней должна следовать опция allow или deny. twist затирает текущий процесс и, соответственно, дальнейшие проверки опций. Однако, через параметры в twist можно передать имя исполняемого файла сервиса, чтобы выполнить его после дополнительных проверок.

Кроме опций запуска программ, существуют опции смены владельца, установки маски создаваемых файлов, понижение приоритета и т.п.

В конце списка правил можно добавить правило по умолчанию ALL:ALL:deny, иначе подразумевается наличие ALL:ALL:allow.

Формат списка client_list

Список состоит из полей, разделённых пробелами и/или запятыми. Список может состоять из основной части и исключений, следующих за ключевым словом EXCEPT. Возможна группировка списков и исключений с помощью круглых скобок. В списке могут присутствовать IP адреса, имена хостов, ключевые слова и шаблоны.

Ключевые слова (часть опущена):

• ALL – все хосты
• PARANOID – хосты, у которых цепочка преобразований IP->Имя->IP даёт адрес, отличный от исходного.

Шаблоны (часть опущена):

• .example.org – все имена из домена
• 192.168.1. – все IP адреса подсети
• 192.168.132.0/255.255.254.0 – IP адреса по маске
• /etc/deny.list – текстовый файл, состоящий из строк, содержащих списки хостов в любой описанной выше форме
• www.*.ru - подстановка вместо звёздочки любого количества символов. Не может быть частью предыдущих шаблонов.

Подстановки при запуске внешних команд

• %a (%A) Адрес клиента (сервера)
• %h (%H) Имя клиента (сервера)
• %d Имя сервиса
• %p Идентификатор процесса (PID)

Примеры

#классический стиль
sshd : .example.com
vsftpd : 192.168. 
ALL : 192.168.1.0/255.255.255


# Разрешаем подключение из домена .example.com
# кроме station15.example.com
sshd : station15.example.com : deny
sshd : .example.com : allow
#Дополнительно запрещаем всем кроме домена *.hacker.org
sshd : ALL EXCEPT *.hacker.org:twist /bin/echo "Reject - bad host name %h"
# Фактически разрешаем *.hacker.org (остальные уже заблокированы)
# с логированием соединений в файл /tmp/sshd.connections
sshd : ALL:spawn /bin/echo "%d at %I connected from %i" > /tmp/sshd.connections: allow
# Запрещаем остальные соединения
ALL:ALL:deny

Ограничение трафика на маршрутизаторе делается в два этапа:
1. Классификация пакетов с помощью netfilter или фильтров iproute2
2. Создание нескольких очередей пакетов с помощью iproute2

Пакеты распределяются в зависимости от класса на несколько очередей в которых ждут своей очереди на отправку. Каждая очередь имеет ограничения на полосу пропускания, приоритет и еще некоторые параметры. При переполнения очереди пакеты соответствующего класса начинают отбрасываться.
Очереди организованы в древовидную иерархию. Каждая очередь может быть разбита на более мелкие. Корневые очереди, связанные непосредственно с «хэндлером» интерфейса имеют абсолютные ограничения по пропускной способности. Дочерние очереди могут «заимствовать» друг у друга неиспользуемую полосу пропускания.

Классификация пакетов с iptables

Первый этап выполняется с помощью программы /sbin/iptables.

Маркируем пакеты в зависимости от каких либо параметров, например по размеру, номеру порта, ip адресу. Для специфических случаев можно дописывать свои модули для netfilter. Например модуль IP2P http://www.ipp2p.org позволяет выбирать пакеты p2p сетей.

Приписываем класс пакета в соответствии с проставленными меткам

Вообще говоря, можно было бы классифицировать пакеты сразу. Например выделим входящий HTTP трафик в отдельный класс

iptables -t mangle -A POSTROUTING -o eth0 -s 0/0 --source-port 80 -j CLASSIFY --set-class 1:10

Маркировка позволяет проверять только несколько первых пакетов в соединении. Для того, чтобы не исследовать каждый пакет используется модуль CONNMARK который позволяет маркировать все пакеты принадлежащие соединению.

Пример классификации P2P трафика. Классы для различных интерфейсов определяются независимо, что позволило использовать класс 1:20 для входящего и для исходящего трафика.

iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark

iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:20
iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 1 -j CLASSIFY --set-class 1:20

Создание очередей пакетов

Этап второй выполняется с помощью /sbin/tc.

Создаем связанную с интерфейсом очередь исходящих пакетов, указываем класс по умолчанию. Создаем корневой класс, назначаем лимит. Создаем дочерние классы, указываем лимиты для них (Обязательно должен быть создан класс используемый по умолчанию).

Теперь каждый пакет попадает в свою очередь. Если очередь переполняется, пакеты отбрасываются не доходя до аппаратного уровня.
Пример: Общая пропускная способность канала 10 Мбит/с. Внешний интерфейс eth0, внутренний eth1. Ограничиваем исходящий трафик P2P сетей из предыдущего примера полосой 32 Кбит/с, входящий 256 Кбит/с.

/sbin/tc qdisc add dev eth0 root handle 1: htb default 10
/sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit
/sbin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit
/sbin/tc class add dev eth0 parent 1:1 classid 1:20 htb rate 32kbit

/sbin/tc qdisc add dev eth1 root handle 1: htb default 10
/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit
/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10mbit
/sbin/tc class add dev eth1 parent 1:1 classid 1:20 htb rate 256kbit

Пример стартового скрипта /etc/init.d/shaper (написан не мною и не связан с примером iptables)

#!/bin/sh
# init script written by shane at knowplace dot org
# this script only creates the qdiscs and classes required for shaping, it
# does NOT create the necessary filters

INTERFACE='eth0'
rc_done=" done"
rc_failed=" failed"

return=$rc_done

TC='/sbin/tc'

tc_reset ()
{
# Reset everything to a known state (cleared)
$TC qdisc del dev $INTERFACE root 2> /dev/null > /dev/null
}

tc_status ()
{
echo "[qdisc - $INTERFACE]"
$TC -s qdisc show dev $INTERFACE
echo "------------------------"
echo
echo "[class - $INTERFACE]"
$TC -s class show dev $INTERFACE
}

tc_showfilter ()
{
echo "[filter - $INTERFACE]"
$TC -s filter show dev $INTERFACE
}

case "$1" in

start)
echo -n "Starting traffic shaping"
tc_reset
U320="$TC filter add dev $INTERFACE protocol ip parent 1:0 prio 0 u32"
#
# dev eth0 - creating qdiscs & classes
#
$TC qdisc add dev $INTERFACE root handle 1: htb default 60
$TC class add dev $INTERFACE parent 1: classid 1:1 htb rate 116kbit
$TC class add dev $INTERFACE parent 1:1 classid 1:10 htb rate 32kbit ceil 116kbit prio 0
$TC class add dev $INTERFACE parent 1:1 classid 1:20 htb rate 22kbit ceil 116kbit prio 1
$TC class add dev $INTERFACE parent 1:1 classid 1:30 htb rate 22kbit ceil 116kbit prio 2
$TC class add dev $INTERFACE parent 1:1 classid 1:40 htb rate 20kbit ceil 116kbit prio 3
$TC class add dev $INTERFACE parent 1:1 classid 1:50 htb rate 18kbit ceil 116kbit prio 4
$TC class add dev $INTERFACE parent 1:1 classid 1:60 htb rate 2kbit ceil 116kbit prio 5
$TC qdisc add dev $INTERFACE parent 1:10 handle 10: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:20 handle 20: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:30 handle 30: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:40 handle 40: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:50 handle 50: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:60 handle 60: sfq perturb 10
tc_status
;;

stop)
echo -n "Stopping traffic shaper"
tc_reset || return=$rc_failed
echo -e "$return"
;;

restart|reload)
$0 stop && $0 start || return=$rc_failed
;;

stats|status)
tc_status
;;

filter)
tc_showfilter
;;

*)
echo "Usage: $0 {start|stop|restart|stats|filter}"
exit 1

esac
test "$return" = "$rc_done" || exit 1
##################################

Примечания.

В параметрах iptables цель CLASSIFY в iptables может использоваться только в таблице mangle и только в цепочке POSTROUTING.

В параметрах tc встречаются сокращения:
qdisc – Classful Queuing Disciplines – базовый объект связанный с сетевым интерфейсом и обеспечивающий управление очередями
htb – Hierarchical Token Bucket – имя собственное одного из планировщиков очередей пакетов в ядре Linux

Имена классов имеют вид M:N. M: эквивалентно M:0 и используется для создания общего корня очередей (хэндлера) связанного напрямую с интерфейсом.

Набор скриптов Logwatch предназначен для выделения из логов наиболее значимой информации.

Структура пакета практически не зависит от используемой операционной системы и ориентирована на популярные сервисы, такие как веб-сервер apache, почтовый сервер sendmail, антивирус clamav и т.п. Благодаря этому всегда можно обновить версию Logwatch, взяв tar-архив прямо с сайта проекта http://www.logwatch.org. Тонкие отличия для системных модулей, таких как pam_unix, учтены в самих скриптах.

Основные скрипты располагаются в каталоге /usr/share/logwatch При необходимости тонких настроек или внесения изменений в скрипты, необходимо скопировать соответствующие файлы в каталог /etc/logwatch с сохранением вложенной структуры каталогов.
При загрузке logwatch вначале просматривает /etc/logwatch, а затем /usr/share/logwatch. При этом скрипты с совпадающими именами берутся только из /etc/logwatch, а переменные конфигурации, описанные в /etc/logwatch либо перекрывают описанные /usr/share/logwatch, либо, в случаях когда формируется список значений, добавляются к описанным в /usr/share/logwatch.

Если у вас выдаются избыточные безвредные сообщения, нераспознанные модулями Logwatch, то в /etc/logwatch/conf/ignore.conf можно прописать набор регулярных выражений, которые будут отфильтровывать лишние строки. При настройке этого фильтра следует соблюдать осторожность, чтобы не заблокировать оповещение о важных событиях в системе.

Запись логов ведётся специальным приложением syslogd или его современной версией rsyslogd. Для отправки сообщений демону используется сетевой протокол, который может использовать либо TCP/IP, либо Unix сокет /dev/log. Программист на Си может воспользоваться для записи в лог стандартной функцией syslog(3), а разработчик скриптов или обычный пользователь – утилитой logger.

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

Сообщение, передаваемое в syslogd, содержит класс сообщения, состоящий из категории и важности, идентификатор (имя программы) и произвольный текст. syslogd на основе класса сообщения выбирает файл для записи и сохраняет в этот файл время получения сообщения, идентификатор и текст.

Классы сообщений

По категориям: authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0...local7

authpriv – данные могут содержать приватную информацию, например пароли при логировании процесса аутенификации. Такие данные должны сохраняться в файле, недоступном на чтение для обычных пользователей.
cron, ftp, lpr, mail, news, uucp – различные службы (в том числе устаревшие), которые генерируют большой поток сообщений. В CentOS отдельно настроены mail и cron
daemon – любая служба
user – обычный пользователь
syslog – сообщения самого syslogd
local0...local7 – отданы на усмотрение местного администратора. В CentOS local7 используется для записи сообщений во время загрузки

По важности: emerg, alert, crit, err, warning, notice, info, debug

emerg – критическая ошибка, затрагивающая всю систему (отказ диска, отключение электропитания и т.п.)
alert, crit – проблемы различной степени тяжести. Используются редко
err, warning, notice, info – диапазон, обычно используемый приложениями
debug – отладочные сообщения. Обычно нигде не сохраняются

Конфигурационные файлы syslogd/rsyslogd

В зависимости от используемого демона конфигурация может находиться в /etc/syslog.conf или /etc/rsyslog.conf. rsyslog.conf имеет более развитый синтаксис, однако правила, описывающие сортировку сообщений по категориям, имеют одинаковый формат. Эти правила состоят из строк вида:

фильтр действие

фильтр – описывает класс сообщений, для которых будет выполняться действие, и состоит из шаблонов, разделённых точкой с запятой. Каждый шаблон состоит из полей категории и важности, разделённых точкой. Фильтр выбирает те сообщения, категория и важность которых соответствуют всем шаблонам фильтра. Т.е. условия-шаблоны объединяются логическим оператором И.

Примеры фильтров:
mail.info – категория mail, важность info и выше
*.=debug – любая категория, важность – только debug
*.* – все сообщения
*.*;authpriv.none – все, кроме категории authpriv

действие – имя файла, FIFO, программы или IP адрес удаленного компьютера.

Формат записи действий:
/var/log/messages – файл
/dev/console – консоль (root'а?)
/dev/ttyS0 – последовательный порт
|/tmp/debug-log – FIFO. Удобно для отладки
@192.168.1.0 – IP адрес
* – сообщение всем залогированным пользователям

Пример из реального файла syslog.conf

# Всё  (кроме mail и cron) важности info и выше
# Прячем сведения об аутенификации пользователей!
*.info;mail.none;authpriv.none;cron.none    /var/log/messages

# authpriv в отдельный файл с ограниченным доступом
authpriv.*                                  /var/log/secure

# Все сообщения почты в отдельный файл
mail.*                                      /var/log/maillog
# то же с сообщениями от crond
cron.*                                      /var/log/cron

# Сообщения уровня emerg рассылаются всем
*.emerg                                     *

Программа logger

logger -t идентификатор -p категория.важность текст

По умолчанию logger подставляет в качестве идентификатора имя пользователя, а в качестве класса сообщения user.notice, однако любой, даже непривилегированный, пользователь может изменить эти значения с помощью соответствующих опций.

В 1991г в США Филом Циммерманом были опубликованы исходные текстов программы PGP (Pretty Good Privacy – замечательная приватность). Эта программа выводила на гражданский рынок самые современные на тот момент алгоритмы шифрования с ассиметричными ключами RSA, ВSA и ElGamal (расширение Diffi-Helman). На тот момент в США действовали довольно жёсткие законы в отношении экспорта криптографических программ и Фил в течении трёх лет подвергался судебному преследованию, но был оправдан, поскольку удалось убедить судей, что исходные тексты программы, это литературное произведение, попадающее под первую поправку к конституции США.

Права на программу PGP несколько раз переходили от одной компании к другой. С начала 2000-х и по настоящее время программой владеет компания Symantec, которая закрыла доступ к исходным кодам программы.

В 1997 году на основе реализации PGP v.5 была разработана группа стандартов OpenPGP. Стандарты описывает требования к алгоритмам шифрования, форматы хранения данных, взаимодействие с почтовыми программами и т.п.

В 1999 в рамках проекта GNU и при финансировании правительства Германии была разработана свободно распространяемая программа шифрования совместимая с OpenPGP – GnuPG версии 1, а в 2006 году - GnuPG версии 2.

В 2014 году вышла версия GnuPG 2.1.0, которая значительно отличается от предшественников (включая версии 2.0.x) по формату файлов. Миграция с 2.0.x на 2.1.x происходит автоматически, обратное преобразование потребует ручного выполнения экспорта-импорта ключей. Кроме того, начиная с версии 2.1.0 прекращена поддержка исторического формата ключей PGP-2. Тем не менее, GnuPG всех версий совместима с классической программой PGP версии 5 и старше.

В 2017 вышла версия GnuPG 2.2.0, которая не сильно отличается о 2.1.x. До этой версии команда gpg означала GnuPG 1.x, а для новых версий GnuPG использовалась команда gpg2. Начиная с версии 2.2 во всех новых дистрибутивах команда gpg означает GnuPG 2.2 и старше.

Реализации GnuPG существуют для всех популярных ОС. Реализация GnuPG для Linux включена во все дистрибутивы, реализация GnuPG для Windows - Gpg4win, для Android OpenKeychain.

Документацию и последние версии GnuPG можно получить на http://www.gnupg.org. На русском языке подробную информацию можно получить на сайте http://www.pgpru.com.

Для интеграции PGP в почтовые программы можно воспользоваться следующими продуктами: Linux, Windows, OS X - плагин для почтового клиента Thunderbird - Enigmail; Android - K9 mail + OpenKeychain; Серверное web-приложение Roundcubemail (ver.>1.2); Gmail и т.п. - расширение для браузеров Mailvelop.

Если не вдаваться в подробности (которые очень важны, если криптография используется по назначению, а не в качестве игрушки), то процесс работы с GnuPG делится на следующие этапы:

• Генерация ключей для подписи и шифрования, а также сертификата для отзыва ключа
• Экспорт публичного ключа в файл, который затем передается всем желающим
• Импорт публичных ключей полученных от партнеров в личную «связку ключей»
• Шифрование и проверка цифровой подписи публичными ключами партнеров
• Дешифрование и цифровая подпись документов личными секретным ключами
• При необходимости - отзыв ключей

История

В 1988 году Международный союз электросвязи (International Telecommunication Union - ITU) опубликовал рекомендации по методам аутенификации в протоколе доступа к службе каталогов (Direcrotry access protocol - DAP). Все рекомендации союза по компьютерным сетям (реализация модели ISO/OSI) маркировались буквой "X" и номером. Серия посвященная службе каталогов получила номера с X.500 и далее. Система аутенификации на основе публичных ключей и сертификатов получила название X.509. В дальнейшем, часть рекомендаций X.500 была реализована в протоколе LDAP, а фреймворк предложенный в X.509 была использована в вебе для реализации протокола SSL и связанной с ним иерархией отношений доверия (RFC 5280).

В частности, X.509 ввёл понятия:

• сертификат пользователя (сертификат): открытые ключи пользователя вместе с другой вспомогательной информацией, подписанные с помощью секретного ключа, выдавшего его органа по сертификации;
• центр сертификации (certification authority - CA): орган, которому пользователи доверяют создание и подпись сертификатов. Опционально центр сертификации может создавать и ключи пользователя;
• путь сертификации: упорядоченная последовательность сертификатов объекта, которая вместе с публичным ключом начального объекта в пути, может быть использована для проверки публичного ключа конечного объекта в пути;
• доверие: ключевая роль доверия в структуре аутентификации заключается в отношениях между объектом аутентификации и центром сертификации; аутентифицирующий должна быть уверен, что центр сертификации создаёт только действительные и надежные сертификаты.

Для реализации стандарта X.509 и связанных с ним стандартов (алгоритмы шифрования, форматы хранения даннных и т.п.) была разработана библиотека OpenSSL, которая поставляется с утилитой командной строки openssl, и позволяет выполнять все основные криптографические операции. Библиотека Openssl реализована для всех основных ОС, в том числе Linux, Windows, Mac OS, Android и т.д.

И SSH и OpenPGP используют(могут использовать) алгоритм RSA для аутенификации/шифрования. Соответственно, пары открытый/секретный ключ могут использоваться совместно в двух программах, поскольку это просто числа, соответствующие некой формуле. Основное отличие между ключами в OpenPGP и SSH - это инфраструктура и формат хранения.

Импорт ключа SSH в GPG

Не совсем понятно, зачем это надо, поскольку публичные ключи SSH (обычно) распространяются без какой либо верификации, а сами ключи (обычно) не содержат никакой информации о владельце. Соответственно, цифровая подпись, сделанная ключом SSH, не может считаться хоть сколько-нибудь значимой, поскольку невозможно удостовериться в принадлежности открытого ключа автору подписи.

Для конвертации потребуются скрипты от monkeysphere. Процедура импорта описана ЗДЕСЬ.

Использование GPG для аутенификации в SSH

В gpg-agent встроена поддержка протокола ssh-agent. Соответственно, можно сгенерировать ключи средствами GPG и поместить их в gpg-agent, затем импортировать публичный ключ стандартным образом через ssh-add -L.

Процедура генерации ключа описана ЗДЕСЬ Примерно то же самое + использование ybkey- ССЫЛКА.

GPG4Win и putty

GPG4Win совместим с pagent. ИНСТРУКЦИИ.

Подготовка

Генерация ключей SSH и сохранение их в пару файлов (mykey,mykey.pub)

ssh-keygen -t rsa -b 4096 -f mykey 

Приватные ключи по умолчанию сохраняются в формате PEM PKCS#1. Ключи, созданные в "новом" формате OpenSSH (опция -o) не совместимы с другими криптографическими системами.

Формат PEM можно отличить по строкам

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

в файле приватного ключа. В новом формате они заменены на строки

-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----

Публичный ключ так же нужно сконвертировать в формат PEM PKCS#8 (Можно это будет сделать на лету в момент шифрования):

ssh-keygen -f mykey.pub -e -m pkcs8 > mykey.pkcs8.pub
#или
openssl rsa -in mykey -pubout -outform PKCS8 > mykey.pkcs8.pub

Обмениваемся публичными ключами с партнёрами. Чтобы это подчеркнуть, при шифровании я буду использовать чужой публичный ключ anotherkey.pub.

Шифрование

Генерируем одноразовый сеансовый ключ (32 байта):

openssl rand -base64 32 -out key.bin

Шифруем передаваемые данные симметричным ключом:

openssl enc -aes-256-cbc -salt -in bigdata.dat -out bigdata.dat.enc  -pass file:./key.bin

Шифруем сеансовый ключ публичным ключом в формате PKCS#8:

openssl rsautl -encrypt -pubin -inkey anotherkey.pkcs8.pub -in key.bin -out key.bin.enc
# возможна конвертация на лету
openssl rsautl -encrypt -pubin -inkey <(ssh-keygen -e -m PKCS8 -f anotherkey.pub) -in key.bin -out key.bin.enc

Удаляем одноразовый ключ:

rm key.bin

Обмен файлами

По открытому каналу пересылаем bigdata.dat.enc и key.bin.enc.

Расшифровка

Расшифровываем секретным ключом сеансовый ключ. В реальной жизни вместо специально сгенерированного ключа mykey надо будет использовать стандартный ключ ~/.ssh/id_rsa:

openssl rsautl -decrypt -inkey mykey -in key.bin.enc -out key.bin

Расшифровываем данные:

openssl enc -d -aes-256-cbc -in bigdata.dat.enc -out bigdata.dat -pass file:./key.bin

Асимметричное шифрование маленьких файлов

Для передачи файлов в несколько байт или килобайт можно сразу зашифровать их асимметричным алгоритмом.

# Encrypt openssl rsautl -encrypt -inkey <(ssh-keygen -e -m PKCS8 -f ~/.ssh/id_rsa.pub) -pubin -in small.dat -out small.dat.enc # Decrypt openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in small.dat.enc -out small.dat

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

Команда вычисления хэша:ssh-keygen -l -f имя_файла

Можно передавать как имя файла секретного ключа, так и имя файла публичного ключа. В любом случае будет выдан хэш от публичного ключа. Например: ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key. Если в файле много ключей (например в ~/.ssh/authorized_keys), то ssh-keygen посчитает все хэши.

В зависимости от версии OpenSSH хэш может считаться по алгоритму MD5 и выдаваться в восьмеричной записи (старые версии), либо считаться по алгоритму SHA256 и выдаваться в кодировке BASE64 (новые версии). Для того, чтобы новая версия ssh-keygen выдала хэш в старом формате необходимо добавить опцию -E md5. Дополнительная опция -v генерирует представление хэша в ASCII-арт.

Примеры:

#Старая версия
ssh-keygen -l -f ~/.ssh/id_rsa
2048 19:c3:6f:d8:48:88:5d:97:44:56:3e:75:5e:e0:f5:fa /home/user/.ssh/id_rsa.pub (RSA)

#Новая версия
ssh-keygen -l -f ~/.ssh/id_rsa
3072 SHA256:6jpGLR7o7uutwXjYzIJE/6eQK9rMbwmjSU+BPEMBlnk user@example.com (RSA)

ssh-keygen -l -E md5 -v-f ~/.ssh/id_rsa
3072 MD5:00:a6:22:39:bb:20:77:de:03:2a:fd:ad:79:f0:53:7f user@example.com (RSA)
+---[RSA 3072]----+
|    o            |
| . o .           |
|= .   .          |
|.+     .         |
|+ . o   S        |
|o+ +.o  .        |
|o o .oo. .       |
| . . o+.  . E    |
|    +o..   .     |
+------[MD5]------+

Протокол SSH позволяет прокладывать TCP туннели внутри защищенного соединения. Фактически это означает, что клиент и сервер SSH создают по дополнительному сокету. Один из них принимает входящие соединения, а второй соединяется с кем-то в своей сети или в интернете. Данные из одного сокета пробрасываются в другой. В зависимости от распределения ролей сокетов туннели делятся на локальные (local) и удалённые (remote) . Первые принимают входящие соединения на локальном порту и пробрасывают их на удаленный сервер, вторые принимают соединения на удаленном сервере и пробрасывают их в локальную сеть.

      ++++++++     ++++++++      
      |Клиент| SSH |Сервер|      Кто то в сети
Я --->|порт  |-----|      |----> сервера или в интернете 
      |5678  |     |      |      с портом 80      
      ++++++++     ++++++++

          ++++++++     ++++++++      
Мой комп  |Клиент| SSH |Сервер|     Кто то из сети
порт  <---|      |-----|порт  |<--- сервера  или из интернета
3389      |      |     |5678  |     подключается ко мне
          ++++++++     ++++++++

В Unix проброс локального порта 5678 на remoteserv.com:80 через ssh_host.com выглядит так:

ssh -L localhost:5678:remoteserv.com:80 ssh_host.com

После создания канала можно подключаться браузером на http://loclahost:5678. localhost: в опции -L можно опустить. Это значение по умолчанию. Если надо подключиться на порт 80 самого ssh_host.com то можно задать опцию так:

ssh -L 5678:localhost:80 ssh_host.com

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

ssh -R *:5678:localhost:3389 ssh_host.com

* означает, что на сервере будут задействованы все доступные сетевые интерфейсы. Если этот параметр не указать, то порт 5678 откроется на сервере ssh_host.com только по адресу 127.0.0.1

Проброс портов без запуска терминала

В командах выше кроме проброса портов на удалённой машине запускается shell и устанавливается терминальное соединение. Если терминал не нужен, то можно запустить ssh с опцией -N. В этом случае никакая команда на удаленном сервере не запустится, и, что интересно, команды w, last и т.п. не будут показывать ваш вход на сервер. Впрочем, информация об авторизации в системе останется в логах категории authpriv.

Особые случаи

Опция -A находит на локальной машине порт ssh-agent пробрасывает его на удаленную машину на случайный порт или Unix-сокет и устанавливает в сеансе ssh переменную SSH_AUTH_SOCK для дальнейшей авторизации через агента.

Опция -X находит на локальной машине порт XWindow и пробрасывает его на первый свободный порт начиная от порта 6000 (базовый порт XWindow). Переменная DISPLAY в сеансе ssh устанавливается в :<номер порта - 6000>. Так, если номер порта на сервере 6007 то DISPLAY=":7".

Опция -D addr:port превращает ваш компьютер в SOCKS прокси с выходом в интернет на стороне сервера. Как и раньше, если вы укажете только порт, то вместо адреса подставится 127.0.0.1 и ваш прокси будет доступен только на локальном компьютере. Если вместо адреса подставить *, то вашим SOCKS прокси смогут воспользоваться все компьютеры, имеющие к вам доступ по сети.

Туннели в putty

Настройка туннелей в putty находится в настройках соединения в пункте Connection -> SSH -> Tunnels. Локальный/удаленный туннель может выбираться автоматически на основе введённых данных. В нашем примере локальному туннелю соответствуют поля: Source port - 5678; Destination - remoteserv.com:80

Не забудьте после ввода данных нажать кнопку "Add".

Если вам не нужен терминал, зато нужно формировать туннель из .bat файла - воспользуйтесь программой plink. Её параметры совпадают с параметрами ssh.

Традиционно свойства процессов и некоторые параметры ядра отображаются в Linux в каталог /proc через драйвер псевдофайловой системы procfs. Начиная с ядра 2.6 параметры ядра, связанные с драйверами устройств и файловых системам, были вынесены в каталог /sys и псевдофайловую систему sysfs.

/proc

Через файл /proc/cpuinfo можно получить информацию о физических процессорах, физических ядрах и гипертрединговых логических ядрах.

$  cat /proc/cpuinfo
...
model name      : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
....
cpu MHz         : 1733.000
...

Через файл /proc/net/dev можно получить список сетевых интерфейсов и статистику по ним

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
eth0: 1767479002126 7440045654    0 209199 176227535     ...
lo: 809098010894 313483867    0    0    0     0          ...

/sys

Каталог содержит информацию об инициализированных устройствах, сгруппированную по разным критериям: типам устройств, шинам, диагностическим протоколам доступа и т.п. Одни и те же устройства могут быть показаны в разных каталогах через символические ссылки.

• /sys/devices - основной каталог, на который ссылаются остальные
• /sys/dev - классификация по type, major, minor
• /sys/bus - классификация по шине - pci, usb, scsi и т.п.
• /sys/block - драйверы блочных устройств.
• /sys/class - классификация по типу устройства

Заряд батареи

cat /sys/class/power_supply/BAT0/charge_full
cat /sys/class/power_supply/BAT0/charge_full_design
cat /sys/class/power_supply/BAT0/charge_now

Альтернативный путь к тем же данным

 /proc/acpi/battery/BAT0/*

• dmesg - сообщения ядра. Включают информацию об обнаруженных устройствах.
• lscpu - список процессоров (ядер). Выводит информацию из /proc/cpuinfo
• lsusb - список устройств на шине USB (/sys/bus/usb/devices)
• lspci - список устройств на шине PCI (/sys/bus/pci/devices)
• lsblk -список дисков, разделов, логических томов и т.п.
• hdparm - считывание параметров жёстких дисков и управление этими параметрами.
• smartctl - считывание параметров S.M.A.R.T. жёсткого диска. Диагностика диска.
• dmidecode - список устройств на материнской плате, в том числе информация о BIOS и о планках памяти.

Утилиты acpi, acpitool отсутствуют в большинстве современных дистрибутивов.

Cyrus IMAPD – сервер, обеспечивающий доступ к почте по протоколам IMAP и POP3.

Почта не привязана к локальным пользователям системы. Почтовые ящики хранятся в своем формате в отдельном каталоге, пароли могут проверяться различными способами, которые доступны через библиотеку SASL. Можно хранить пароли в базе My SQL, в sasldb или проверять через любые PAM модули. В состав Cyrus IMAPD входят программа для локальной доставки почты.

Внимание Необходимо сменить владельца /etc/imapd.conf на cyrus и отобрать у «прочих» права на чтение
chown cyrus /etc/imapd.conf
chmod o-r /etc/imapd.conf

/etc/imapd.conf
================
configdirectory: /var/lib/imap

#Где хранятся почтовые ящики
partition-default: /var/spool/imap

#Список администраторов, которые могут управлять почтовыми ящиками.
admins: cyradm

allowplaintext: 1
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail

#Не трогаем 8ой бит.
munge8bit: 0

#Все ящики в нижнем регистре. При подключении клиентов регистр преобразуется.
username_tolower: 1

#Дает возможность использовать имена с точками. Если стоит "0", то точка используется как разделитель в системе почтовых каталогов.
unixhierarchysep: 1

#Для повышения производительности каталог с почтовыми ящиками разбивается на подкаталоги по алфавиту
# /var/spool/imap/a/, /var/spool/imap/b/ и т.д.
hashimapspool: true

#Проверка пойдет через PAM
sasl_pwcheck_method: saslauthd
# PLAIN - способ получения пароля от клиента, только PLAIN подойдет для проверки в файлах (базе) с паролями.
sasl_mech_list: PLAIN

#Список виртуальных доменов, для которые мы держим почтовые ящики
loginrealms: mydomain1.my mydomain2.my

#Сертификаты для шифрованного соединения
tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem
tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem
tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt

# Если мы хотим проверять пароли в БД с помощью встроенных модулей sasl, можно добавить
sasl_pwcheck_method: auxprop saslauthd
sasl_auxprop_plugin: sql
sasl_sql_engine: mysql
sasl_sql_user: mailadmin
sasl_sql_passwd: mailpasswd
sasl_sql_hostnames: localhost
sasl_sql_database: maildb
sasl_sql_statement: select password from accountuser where username = '%u' and domain_name = '%r'

(см. Аутенификация SASL)

/etc/cyrus.conf
Все по умолчанию

Программа cyradm

cyradm – скрипт на Perl для управления почтовыми ящиками по протоколу IMAP. Запуск

cyradm -u cyradmin localhost

cyradm можно использовать в диалоговом режиме, либо перенаправлять ему вывод какого либо скрипта

Создание почтового ящика и установка квоты 100МБ

cm user/newuser
sq user/newuser 100000

Удаление ящика
sam user/newuser cyradm c
dm user/newuser

Восстановление индексных файлов в порушенном ящике
sudo -u cyrus /usr/lib/cyrus-imapd/reconstruct user/john.dou

Переход на Postfix с sendmail в CentOS осуществляется почти автоматически.
Устанавливаем postfix
yum install postfix
Правим конфигурационные файлы в каталоге /etc/postfix, удаляем Sendmail, cтроим hash для файла aliases, стартуем Postfix и добавляем его в список загружаемых при старте демонов

vi /etc/postfix/main.cf
rpm -e sendmail
newaliases
/sbin/service postfix start
/sbin/chkconfig postfix on

Замечательные русские инструкции по настройке Postfix можно найти здесь: http://sergeysl.pnz.ru/freebsd/mailsystem.php
Данная страница посвящена решению некоторых специфических задач конфигурации.

Альтернативные программы

В CentOS используется специальный механизм выбора версии программы, имеющей несколько реализаций. К таким программам относятся почтовые серверы, принт серверы, различные варианты java. В каталоге /etc/alternatives/ сделаны символические линки на реально установленные программы например, /etc/alternatives/mta изначально является символическим линком на /usr/lib/sendmail.sendmail. При удалении Sendmail происходит замена и /etc/alternatives/mta становится символическим линком на /usr/lib/sendmail.postfix. Файл /usr/sbin/sendmail является в свою очередь линком на /etc/alternatives/mta. Т.к. Postfix обрабатывает те же опции при запуске, что и Sendmail, подмену никто не заметит. Аналогичная ситуайия с mailq, newaliases, rmail.

Борьба со спамом и вирусами

Желательно установить Greylisting, clamav, spamassasin и/или mimedefang

yum install postgrey clamav clamd spamassassin mimedefang

Чтобы установка прошла атоматически, надо подключить к списку репозиториев yum'а Dag RPM Repository ( http://dag.wieers.com/rpm/ )
Возможны некоторые проблемы с зависимостями mimedefang с sendmail. (Похоже там явно прописана зависимость от rpm-пакета sendmail).
Подключение этих программ к Postfix будет описано ниже, при описании конфигурационных файлов.

Mimdefang подключится если у нас Postfix версии 2.4

Правим права доступа

В файле /etc/sysconfig/mimedefang (Проверить)
MX_USER=postfix

chown -R postfix.postfix /var/spool/MIMEDefang

MIMEDefang ожидает что сокет clamd расположен в /var/spool/MIMEDefang/clamd.sock, причем это прошито в коде /usr/bin/mimedefang.pl. Clamd по умолчанию помещает свой сокет в /tmp/clamd.socket. Попробуем сделать линк (Проверить)

ln -s /tmp/clamd.socket /var/spool/MIMEDefang/clamd.sock

По умолчанию MIMEDefang запускает Spamassassin с конфигурационным файлом /etc/mail/sa-mimedefang.cf, а пакет spamassassin устанавливает свой конфиг в /etc/mail/spamassassin/local.cf. Чтобы не было путаницы удаляем /etc/mail/sa-mimedefang.cf, MIMEDefang переключится на /etc/mail/spamassassin/local.cf автоматически.

Для postgrey прописываем белые листы:

Пользователи которым нельзя задерживать доставку почты ни под каким видом
Файл /etc/postfix/postgrey_whitelist_recipients

abuse@
quickaccess@

Локальные сети
Файл /etc/postfix/postgrey_whitelist_clients.local

192.168.100

К сожалению маска сети не предусмотрена. Если ваша подсеть больше или меньше стандартного класса, то придется перечислять все подсети или IP адреса (может получиться до 128 строк на подсеть)

Теперь надо включить postgrey, clamd, spamassassin и mimedefang в автозапуск.
/sbin/chkconfig clamd on
/sbin/chkconfig spamassassin on
/sbin/chkconfig mimedefang on

Файл /etc/postfix/main.cf
Основной конфигурационный файл Postfix'а описывающий «политические» параметры (контроль доступа, виртуальные домены и т.п.).
Полный список параметров и их значения по умолчанию можно посмотреть в main.cf.default
Ограничения на пересылку почты
Перед первым запуском правим имя хоста. Скорее всего оно определится из hostname, но лучше подстраховаться.

myhostname = mail.my.net
myorigin = $mydomain

myorigin подменяет почтовый домен для почты отправляемой с локальной машины. Нынче многие почтовые серверы проверяют наличие MX записи для адреса отправителя. В приведенном примере MX запись для my.net скорее всего существует, а для mail.my.net не существует. Почта с локальной системы, например диагностические сообщения, без установки myorigin будет блокироваться.

Ограничения на пересылку почты определяютя так
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 168.100.189.0/24, 127.0.0.0/8
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_policy_service unix:postgrey/socket

Результат ограничений – разрешаем пересылку почты из локальных сетей. Из остального мира после аутенификации и прохождения greylisting'а, либо для наших пользователей из списка почтовых доменов mydestination и прохождения greylisting'а. (есть еще список виртуальных пользователей, но оних ниже).
(Неприятный вопрос, будеть ли greylisting пропускать аутенифицированных пользователей?)
Пример других ограничений http://www.opennet.ru/tips/info/813.shtml

Подключение mimedefang для Postfix версии >= 2.4. Postfix 2.3.3 параметр воспринял, но Mimedefang выдал ошибки протокола при попытке отправить письмо.
smtpd_milters = unix:/var/spool/MIMEDefang/mimedefang.sock
milter_default_action = tempfail

В этом варианте spamassassin и антивирус запустятся через MIMEDefang.

Доставка почты

Почта предназначенная для локальных пользователей может доставляться
в классический файл формата mailbox

mail_spool_directory = /var/mail

или в каталог Maildir

home_mailbox = Maildir/

или с помощью внешней программы (если надо проверять на вирусы только входящую почту, то здесь можно вставить антивирусный фильтр)

mailbox_command = /usr/bin/procmail

или по протоколу lmtp если Postfix используется в связке с Cyrus IMAPD

mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp

Можно описать собственный транспорт в файле /etc/postfix/master.cf

Файл /etc/postfix/master.cf

Конфигурационный файл, описывающий «технические» параметры (запускаемые почтовые службы и их настройки).

Подключение spamassassin и антивируса для Postfix версии < 2.4.
Проверяем только SMTP

#smtp inet n - n - - smtpd
smtp inet n - n - - smtpd -o content_filter=avfilter:dummy
...
avfilter unix - n n - - pipe
flags=R user=clamav argv=/usr/local/sbin/avfilter.sh -f ${sender} -- ${recipient}

Файл /usr/local/sbin/avfilter.sh может быть таким

#!/bin/sh
INSPECT_DIR=/tmp #Каталог куда будут сохраняться письма для сканирования
SENDMAIL="/usr/sbin/sendmail -i"
VIRUSADMIN="root@my.net" # адрес для уведомлениий

EX_TEMPFAIL=75
EX_UNAVAILABLE=69

# строка для запуска spamassassin
FILTER_SPAMC="/usr/bin/spamc"
#FILTER_SPAMC="/usr/bin/spamc -u spamfilter -U /var/run/spamd.sock"
# строка для запуска clamav
FILTER_CLAMAV="/usr/bin/clamdscan -v --no-summary --stdout"

trap "rm -f $INSPECT_DIR/in.$$ $INSPECT_DIR/vr.$$ $INSPECT_DIR/vr1.$$" 0 1 2 3 15

# Проверка на спам
cat | $FILTER_SPAMC > $INSPECT_DIR/in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }

# Проверка на вирусы
$FILTER_CLAMAV ${INSPECT_DIR}/in.$$>$INSPECT_DIR/vr.$$

# Результат проверки
AV_RESULT=$?

case "$AV_RESULT" in
0)
# Проверено. Мин нет :)
$SENDMAIL "$@" <${INSPECT_DIR}/in.$$
exit 0
;;
1)
# Обнаружен вирус. Посылаем уведомление админу
echo "Subject: VIRUS FOUND" >> $INSPECT_DIR/vr1.$$
echo >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
echo "* MAIL *" >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
echo >> $INSPECT_DIR/vr1.$$
# Включаем в отчет реальные адреса релеев
grep Received $INSPECT_DIR/in.$$ >> $INSPECT_DIR/vr1.$$
echo "Mail from: $2 (may be forget)" >> $INSPECT_DIR/vr1.$$
echo "To: $4" >> $INSPECT_DIR/vr1.$$
grep Subject $INSPECT_DIR/in.$$ >> $INSPECT_DIR/vr1.$$
echo >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
echo "* Virus(es) *" >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
# Включаем в отчет список вирусов
cat $INSPECT_DIR/vr.$$ >> $INSPECT_DIR/vr1.$$
$SENDMAIL -f $VIRUSADMIN -r $VIRUSADMIN -F "Antivirus" $VIRUSADMIN < $INSPECT_DIR/vr1.$$
exit 0
;;
*)
# Произошла ошибка в работе антивируса. Сообщим об ошибке админу
echo "Subject: ANTIVIRUS FAILED" >> $INSPECT_DIR/vr1.$$
echo >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
echo "* Antivirus Failed with next problem *" >> $INSPECT_DIR/vr1.$$
echo "************************************************" >> $INSPECT_DIR/vr1.$$
case "$AV_RESULT" in
40)
echo "* Unknown option passed. *" >> $INSPECT_DIR/vr1.$$
;;
50)
echo "* Database initialization error. *" >> $INSPECT_DIR/vr1.$$
;;
52)
echo "* Not supported file type. *" >> $INSPECT_DIR/vr1.$$
;;
53)
echo "* Can't open directory. *" >> $INSPECT_DIR/vr1.$$
;;
54)
echo "* Can't open file. (ofm) *" >> $INSPECT_DIR/vr1.$$
;;
55)
echo "* Error reading file. (ofm) *" >> $INSPECT_DIR/vr1.$$
;;
56)
echo "* Can't stat input file / directory. *" >> $INSPECT_DIR/vr1.$$
;;
57)
echo "* Can't get absolute path name of current *" >> $INSPECT_DIR/vr1.$$
echo "* working directory. *" >> $INSPECT_DIR/vr1.$$
;;
58)
echo "* I/O error, please check your filesystem. *" >> $INSPECT_DIR/vr1.$$
;;
59)
echo "* Can't get information about current user *" >> $INSPECT_DIR/vr1.$$
echo "* from /etc/passwd. *" >> $INSPECT_DIR/vr1.$$
;;
60)
echo "* Can't get information about user *" >> $INSPECT_DIR/vr1.$$
echo "* clamav (default name) from /etc/passwd. *" >> $INSPECT_DIR/vr1.$$
;;
61)
echo "* Can't fork. *" >> $INSPECT_DIR/vr1.$$
;;
63)
echo "* Can't create temporary files/directories *" >> $INSPECT_DIR/vr1.$$
echo "* (check permissions). *" >> $INSPECT_DIR/vr1.$$
;;
64)
echo "* Can't write to temporary directory (please *" >> $INSPECT_DIR/vr1.$$
echo "* specify another one). *" >> $INSPECT_DIR/vr1.$$
;;
70)
echo "* Can't allocate and clear memory (calloc). *" >> $INSPECT_DIR/vr1.$$
;;
71)
echo "* Can't allocate memory (malloc). *" >> $INSPECT_DIR/vr1.$$
;;
*)
echo "Unknown error $AV_RESULT" >> $INSPECT_DIR/vr1.$$
;;
esac
echo "************************************************" >> $INSPECT_DIR/vr1.$$
$SENDMAIL -f $VIRADMIN -r $VIRADMIN -F "Antivirus" "$VIRADMIN" < $INSPECT_DIR/vr1.$$
exit $EX_TEMPFAIL
;;
esac
exit 0

Виртуальные домены

В Postfix используются несколько способов задания имен локальных почтовых ящиков.
1. Имена пользователей зарегистрированных в системе. Т.е. в файле /etc/passwd
2. Имена перечисленные в файле /etc/aliases
3. Почтовые ящики перечисленные в файле /etc/postfix/virtual
4.Имена, определяемые локальной программой доставки

В зависимости от подсистемы обслуживающей почтовые ящики, имена из virtual могут отображаться, а могут и не отображаться на имена пользователей из файла passwd.

Основное идеологическое отличие между /etc/aliases и /etc/postfix/virtual в том, что aliases предназначены для локальных имен (например postmaster->root->adminuser или root->root@remote.com), а файл virtual предназначен для отображения имен пользователей различных почтовых доменов, обслуживаемых данным сервером, в имена локальных или удаленных почтовых ящиков (например user@virtual.net ->user_virtual_net).
Другими словами aliases нужны для корректной доставки почты на компьютере не являющемся выделенным почтовым сервером, а virtual это средство для развертывания почтовой системы массового обслуживания.
Если используются оба файла, то вначале для определения маршрута доставки почты используется virtual, а затем, если почта должна быть доставлена в локальный почтовый ящик, aliases.

Squirrelmail - веб интерфейс к IMAP серверу/

После инсталляции размещается в /usr/share/squirrelmail, в /etc/httpd/conf.d создается конфигурация для виртуального каталога /webmail, в /etc/squirrelmail/ помещаются файлы config.php и config_local.php

Файл config.php редактируется скриптом /usr/share/squirrelmail/config/conf.pl Настройки сводятся к выбору языка и типа IMAP сервера.

Внимание! Для cyrus-imapd надо в /etc/squirrelmail/config_local.php прописать $default_folder_prefix= 'INBOX/';

Для включения ssl желательно дописать в /etc/httpd/conf.d/squirrelmail.conf

<Directory /usr/share/squirrelmail>
SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire %{HTTP_HOST} eq "mail.mydomain.my"
ErrorDocument 403 https://mail.mydomain.my/webmail
</Directory>

Дистрибутив CentOS 7

Удалить письма из архива

Сначала чистим почтовый архив, потом регенерируем веб-архив, стирая старый

mutt -f  /var/lib/mailman/archives/private/mylist.mbox/mylist.mbox
/usr/lib/mailman/bin/arch --wipe mylist

SASL – Simple Authentication and Security Layer, это метод аутенификации пользователя для встраивания в сетевые протоколы основанные на соединении. Ниже описана конфигурация одной из реализаций механизма - cysrus-sasl версии 2.

В cysrus-sasl существует два основных способа аутенификации: auxprop - через библиотеку, слинкованную с приложением и saslauthd - по особому протоколу через сервер аутенификации saslauthd.

auxprop позволяет проводить аутенификацию в базе данных SQL (mysql, sqlite), файле BeklyDB или в LDAP. Список вариантов проверки saslauthd можно узнать командой

# saslauthd -v
saslauthd 2.1.26
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap httpform

Один экземпляр saslauthd может использовать только один механизм аутенификации.

Не стоит использовать auxprop совместно с БД, поскольку существующая реализация требует хранить пароли БД открытым текстом. Более гибким способом является связка saslauthd + pam + pam_mysql.

Поддержка SASL включена, в частности, postfix и в cyrus-imapd. Опции SASL для cyrus-imapd прописываются в файл /etc/imapd.conf, для postfix в CentOS 7 - в файле /etc/sasl2/smtpd.conf (/usr/[local/]lib[64]/sasl2/smtpd.conf в других дистрибутивах).

Пример конфигурации с хранением незашифрованных паролей в mysql

Файл конфигурации cyrus-imapd /etc/imapd.conf

#Для отладки взаимодействия с SQL сервером (печать sql-запросов)
sasl_log_level: 5
#Для логирования необходимо вставить в конфигурацию `rsyslogd` строку
#*.=debug /var/log/debug

#Механизм запроса пароля. В данном случае в виде открытого текста.
sasl_mech_list: PLAIN

#Механизм доступа к SASL
sasl_pwcheck_method: auxprop

#Плагин, используемый через auxprop
#Сами плагины лежат в /usr/[local/]lib[64]/sasl2/
sasl_auxprop_plugin: sql

#Опции для sql плагина
# mysql - тип сервера (еще есть sqlite)
sasl_sql_engine: mysql
# Доступ к базе
sasl_sql_user: mailadmin
sasl_sql_passwd: mailpassword
sasl_sql_hostnames: localhost
sasl_sql_database: mail

# Запрос должен извлечь пароль в виде текста для пользователя %u@%r (%r - realm)
# По умолчанию вместо %r подставляется имя хоста, на котором запущен cyrus-imapd
sasl_sql_statement: select password from accountuser where username = '%u' and domain_name = '%r'

Пример использования saslauthd с postfix

Файл конфигурации postfix - /etc/postfix/main.cf

# Сервер, который будет делать проверку
smtpd_sasl_path = smtpd

smtpd_sasl_auth_enable = yes

Файл /etc/sysconfig/saslauthd содержит опции для запуска saslauthd, в том числе, используемый механизм проверки.

MECH=pam

Файл настроек sasl для демона smtpd /etc/sasl2/smtpd.conf

pwcheck_method: saslauthd
mech_list: PLAIN

Файл настроек PAM для службы smtp /etc/pam.d/smtp Приложения передают в saslauthd имя сервиса. postfix передаёт строку smtp.

#%PAM-1.0
auth required pam_mysql.so config_file=/etc/security/pam_mysql.conf [where=smtpauth=1]
account required pam_mysql.so config_file=/etc/security/pam_mysql.conf [where=smtpauth=1]

В дальнейшем считаем, что в БД создана база mail, доступ к ней разрешен пользователю mailadmin с паролем mailpassword. В администраторы cyrus-imapd внесен пользователь cyradmin.
Web-cyradm предпологает следующую структуру данных для хранения паролей:

CREATE TABLE accountuser (
username varchar(255) binary NOT NULL default '',
password varchar(30) binary NOT NULL default '',
prefix varchar(50) NOT NULL default '',
domain_name varchar(255) NOT NULL default '',
UNIQUE KEY username (username)
) TYPE=MyISAM;

Перенос почтовых ящиков

Скрипт для создания пустых почтовых ящиков на основе информации в /etc/passwd

#!/usr/bin/perl -w
#
# Written by Wil Cooley <wcooley@nakedape.cc>, 25 April 2002.
#
# This script is copyright (C) 2002 by Wil Cooley and
# licensed under the GNU GPL <http://www.gnu.org//licenses/gpl.txt>
#
# Usage: migrate-pw-to-cyrus2.pl
#
# Purpose: Creates empty Cyrus mailboxes.
#
# Input: None.
#
# Notes: Set the default quota below. I used a default
# of 100MB more as a failsafe than a restriction.
#
# $Id: migrate-pw-to-cyrus2.pl,v 1.1 2002/04/26 00:56:09 wcooley Exp $
###
my $adminuser = "cyradmin" ;
my $server = "localhost" ;
my $quota = 100*1024 ; # 100MB
my $user_uid_start = 500 ;
my $err = 0 ;
my ($user,$p,$uid) ;

use Cyrus::IMAP::Admin;

$imapcon = Cyrus::IMAP::Admin->new($server) || die "Unable to connect to $server";

unless ($imapcon) {
die "Error creating IMAP connection object\n" ;
}

$imapcon->authenticate(-user => $adminuser, -mechanism => "LOGIN") ;

if ($imapcon->error) {
die $imapcon->error ;
}

print "\n" ;

setpwent() ;

while (($user,$p,$uid) = getpwent) {
if ($uid >= $user_uid_start) {
unless ($imapcon->list("user.$user")) {
$imapcon->create("user.$user") ;
if ($imapcon->error) {
print "ERROR: ", $imapcon->error, "\n" ;
next;
} ;
$imapcon->setquota("user.$user", "STORAGE", $quota) ;
if ($imapcon->error) {
print "ERROR: ", $imapcon->error, "\n";
next;
} ;
print "Created mailbox user.$user [$uid]\n" ;
}
}
}
endpwent() ;

Перенос содержимого почтовых ящиков с помощью formail и cyrus deliver

# Script to import mbox-format mailboxes to Cyrus folders
# Requires formail (from procmail)
#
# Note: As this runs cyrdeliver directly, you'll need to be
# a member of the mail group for it to work.
#
# Use this script at your own risk! I'm not responsible if
# it trashes your mail system :)
#
# By Michael-John Turner <mj@debian.org>
#

USER=$1
MAILBOX=$2
CYRUSFOLDER=$3
#CYRDELIVER=/usr/sbin/cyrdeliver
CYRDELIVER=/usr/lib/cyrus-imapd/deliver
FORMAIL=/usr/bin/formail

if ! [ -x "$FORMAIL" ]; then
echo ""
echo "formail (from procmail) is required to run this script"
echo ""
exit 1
fi

if [ "$USER" = "" ]; then
echo ""
echo "syntax: $0 user [mbox] [cyrus folder]"
echo ""
echo "If no mbox is specified, the user and mbox name are taken to be the same"
echo "If no cyrus folder is specified, the INBOX is used"
echo ""
exit 2
fi

if [ "$MAILBOX" == "" ]; then
MAILBOX=$USER
fi

if [ "$CYRUSFOLDER" == "" ]; then
echo "Adding mailbox '$MAILBOX' to Cyrus INBOX of user '$USER'..."
$FORMAIL -I "From " -s $CYRDELIVER $USER < $MAILBOX
else
echo "Adding mailbox '$MAILBOX' to Cyrus folder '$CYRUSFOLDER' of user '$USER'..."
$FORMAIL -I "From " -s $CYRDELIVER -m $CYRUSFOLDER $USER < $MAILBOX
fi

Перенос паролей

При миграции возникает желание убрать записи почтовых пользователей из /etc/passwd и перейти на хранение паролей в MySQL, LDAP или где нибудь еще. Прямого пути нет!

В качестве обходного пути можно попытаться использовать PAM-modules Сергея Позднякова http://puszcza.gnu.org.ua/software/pam-modules/

Устанавливаем pam_fshadow из указанного пакета. Копируем записи почтовых пользователей из файла /etc/shadow (/etc/master.passwd во FreeBSD) в новое место, например в /etc/mail/shadow. Пишем настройки PAM для сервисов pop, imap и, возможно, sieve.

auth sufficient pam_fshadow.so sysconfdir=/etc/mail nopass
account sufficient pam_fshadow.so sysconfdir=/etc/mail nopass

Дополнительно настраиваем SASL для проверки в MySQL. Вариант с pam_mysql менее интересен, т.к. не поддерживает виртуальные домены.

auth sufficient pam_fshadow.so sysconfdir=/etc/mail nopass
auth sufficient pam_mysql.so config_file=/etc/pam_mysql.conf
auth sufficient pam_fshadow.so sysconfdir=/etc/mail nopass
account sufficient pam_mysql.so config_file=/etc/pam_mysql.conf

Пример /etc/pam_mysql.conf
users.host=localhost;
users.database=maildb;
users.db_user=mailadmin;
users.db_passwd=mailpassword;
users.table=accountuser;
users.user_column=username;
users.password_column=password;
users.password_crypt=plain;
users.disconnect_every_operation=true;
verbose=0;
log.enabled=1;
log.table=logins;
log.message_column=message;
log.pid_column=pid;
log.user_column=username;
log.host_column=machineip;
log.time_column=logintime;

В соответствие с RFC2060 национальные символы в именах почтовых ящиков на сервере должны кодироваться в модифицированную кодировку UTF7. Отличия от оригинальной UTF7 связаны с особым значением символа '+' в некоторых почтовых системах и символа '/' в роли разделителя имён каталогов в Unix.

Алгоритм кодирования имён папок: Текст -> UTF7; & -> &-; / -> ,; + -> &

Декодирование:

echo '.&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-' \
| sed 's/&\([^-]\)/+\1/g;s/&-/&/g;s/,/\//g' \
| iconv -f UTF7 -t UTF8

.Отправленные

Автоматическая отправка почты

echo test | mail -s test user@example.com

Отправка вложенного файла

uuencode filename ./filename | mail -s "test with file" user@example.com

Дополнительные опции при отправке

-s - Subject:
-c - Cc:
-b - BCc:
-r - From:

Открыть IMAP/mailbox/Maildir

mutt -f imaps://mail.example.com/
mutt -f file.mbox

или

MAIL='/home/user/Maildir' mutt -f file.mbox

Удалить письма с определенных доменов (From:)

Shift D ~f@example.com

Удалить письма со словом SPAM в поле Subject:

Shift D ~sSPAM

Удалить все письма (два варианта)

Shift D ~s.*
Shift D ~A

Восстановить удаленное письмо с номером 1234 1234<CR>u

Команды

Список писем

Чтение письма

Отправка письма

Шаблоны поиска

Установка PHP

В CentOS устанавливаем rpm пакеты

yum install php-common php-cli php

Если посмотреть список установленных файлов, то видно, что php устанавливает модуль для Apache /usr/lib/httpd/modules/libphp7.so, а php-cli — интерпретатор /usr/bin/php

Модуль для Apache требует внесения изменений в конфигурацию apache. В CentOS это делается при инсталляции пакета путем добавления файла /etc/httpd/conf.d/php.conf. Примерное содержимое файла

<FilesMatch \.(php|phar)$>
   SetHandler application/x-httpd-php
</FilesMatch>
DirectoryIndex index.php

Модули в PHP

Интерпретатор php позволяет подключать дополнительные модули, которые расширяют набор доступных в языке функций. Модули могут быть статически скомпилированы в интерпретатор либо подключаться динамически. Из популярных можно упомянуть php-mysql для связи с БД My SQL, php-gd – библиотека обработки изображений, php-mbstring – работа с Unicode.

В CentOS модули можно доустанавливать в соответствии с потребностями

yum install php-mysql

В соответствии с идеологией CentOS конфигурация php для модуля сохраняется в каталоге /etc/php.d/ и содержит строку подключения модуля:

extension=mysql.so

После установки модуля, веб сервер надо перегрузить.

Конфигурационный файл PHP

Общий для всех конфигурационный файл находится в /etc/php.ini

В инструкции по php перечислены параметры, которые можно (PHP_INI_ALL, PHP_INI_PERDIR) и которые нельзя (PHP_INI_SYSTEM) изменить на уровне каталога.

Начиная с версии PHP 5.3.0 в каталоге можно помещать локальный файл настроек .user.ini

Также установки «под себя» можно сделать в файле .htaccess строками подобными следующим

php_value upload_max_filesize 32M
php_value post_max_size 64M

Или в тексте самой программы

<?php
ini_set('memory_limit', '128M');
ini_set('max_input_time', '300');
ini_set('max_execution_time', '300'); // 5 minuites
?>

php_info.php

Простейшая, но очень полезная программа на php. Выдает всю информацию о конфигурации apache и php

<?php
print phpinfo();
?>

Пример подключения к MySQL

<?php
$host='localhost'; $user="user1"; $pass='123';
//Знак @  нужен, чтобы погасить выдачу возможных ошибок подключения на веб страницу
$connection = @mysql_connect($host, $user, $pass, TRUE, 2);
//Установка кодировки для обмена данными в mysql версии > 4.1.0
mysql_query('SET NAMES "utf8"', $connection);
$query ="SELECT * FROM table";
$result = mysql_query($query);
if( $result )
{
   while( $array=mysql_fetch_array($result, MYSQL_ASSOC) );
   print_r($array);
}
?>

Секции

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

В списке виртуальных серверов может присутствовать <VirtualHost *:80> который будет использоваться если к apache пришел запрос с отсутствующим (по ip) или несконфигурированным именем сервера.

<VirtualHost dummy-host.example.com:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot /www/docs/dummy-host.example.com
    ServerName dummy-host.example.com
    ErrorLog logs/dummy-host.example.com-error_log
    CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>

Допустимые опции каталога Indexes Includes, FollowSymLinks, SymLinksifOwnerMatch, ExecCGI, MultiViews, а также All или None.

<Directory "/var/www/html">
#
#Разрешаем просмотр каталогов в которых нет файла index.html
#Разрешаем использование символических ссылок
    Options Indexes FollowSymLinks
#Запрещаем задание прав на доступ в .htaccess
    AllowOverride None
#Разрешаем доступ всем
    Order allow,deny
    Allow from all
</Directory>



#Запрещаем доступ к файлам .htaccess, .htpasswd и т.п.
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>


Включаем прокси, но ограничиваем доступ к нему доменом **example.com**

<IfModule mod_proxy.c>
    ProxyRequests On
    <Proxy *>
        Order deny,allow
        Deny from all
        Allow from .example.com
    </Proxy>
</IfModule>

Файлы .htaccess

В файлах .htaccess можно переопределить права доступа к каталогу (и его подкаталогам), если в httpd.conf для него указано AllowOverride All (All это по максимуму, возможно, что разрешено будет переопределять только часть настроек). По сути дела .htaccess это секция <Directory ...>...</Directory> вынесенная в отдельный файл и лишенная обрамляющих конструкций. Если права меняются в httpd.conf, то серверу надо послать сигнал обновления конфигурации. Изменения в .htaccess вступают в действие мгновенно.

Если вы используете Apache совместно с PHP, то в .htaccess можно вынести некоторые параметры PHP необходимые для работы скриптов в данном конкретном каталоге. Например:

php_value include_path '.:/var/www/phplib:'
php_value default_charset 'windows-1251'

Правильный порядок Allow, Deny

В директивах определяющих доступ к каталогу правила Deny и Allow можно писать в любом порядке. Реальный порядок их применения определяется директивой Order. При запоминании порядка важно уяснить, что эти правила не описывают группы адресов как в некоторых других программах (например в Squid), а последовательно применяются к каждому конкретному адресу

**Order Deny,Allow** - по умолчанию всем разрешено, т.е. если нет запрещающего правила **Deny**, то клиент допускается.  

Если какое то правило Deny запрещает доступ, то дополнительно проводится проверка в правилах Allow, и при наличии подходящего правила клиенту все таки разрешается доступ. Т.е. мы пишем глобальное правило Deny, а потом формулируем для него исключения в Allow

**Order Allow,Deny** - по умолчанию всем запрещено. 

Если какое то правило Allow разрешает доступ, то дополнительно проводится проверка в правилах Deny и при наличии соответствующего запрета клиента отфутболивают. Т.е. мы пишем глобальное правило Allow, а потом формулируем для него исключения в Deny

Примеры

#Никому нельзя (например в каталоге с библиотеками PHP)
Order Deny,Allow
Deny from all

#Только с apache.org
Order Deny,Allow
Deny from all
Allow from apache.org

#Только с apache.org кроме foo.apache.org
Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org

Доступ по IP

<RequireAny>
  Require all denied
  Require ip 192.168.1.14
  Require ip 10.0.12.4
<RequireAny>

<RequireAll>
  Require all granted
  Require no ip 192.168.1.14
  Require no ip 10.0.12.4
<RequireAll>

Показ списка файлов в каталоге

DirectoryIndex disabled
Options Indexes
IndexOptions NameWidth=*