понедельник, 14 октября 2019 г.

сертификаты Let's Encrypt при помощи Certbot

ubuntu
установим необходимое для работы с PPA программное обеспечение:

apt-get install software-properties-common
Затем добавим нужный PPA:

add-apt-repository ppa:certbot/certbot
Обновим список пакетов:

apt-get update
и установим Certbot:

apt-get install certbot

В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:
 mkdir /var/www/letsencrypt
chown www-data:www-data /var/www/letsencrypt
Теперь нам нужно сделать так, чтобы любой запрос вида:
http://example.com/.well-known/acme-challenge
приводил к физическому размещению:
/var/www/letsencrypt/.well-known/acme-challenge
Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.

Apache 2.x

Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Require all granted
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Order allow,deny
    Allow from all
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.

Nginx

Nginx - второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:
location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
   return 404;
}
Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:
server {
   server_name example.com
   ..
   include /etc/nginx/templates/letsencrypt.conf;
}
Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов.

Получение сертификата

Наконец-то мы подошли к самому главному - получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:
certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата, --webroot - указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.
После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:
certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Сертификат получен, отлично! Но где нам его искать? Перейдем в /etc/letsencrypt/live где для каждого полученного сертификата будет создана папка с именем первого указанного в запросе домена, т.е. для нашего примера - example.com. Внутри будут находиться четыре файла:
  • cert.pem - собственно сертификат
  • chain.pem - цепочка доверия, включает корневой и промежуточный сертификаты Let's Encrypt
  • fullchain.pem - полная цепочка, включающая кроме содержимого chain.pem сам сертификат
  • privkey.pem - закрытый ключ сертификата, данный файл является секретным.
Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL, конкретные реализации выходят за рамки данной статьи и это будет сделано в отдельных материалах, мы же заглянем еще глубже под капот.
При внимательном рассмотрении выяснится, что файлы в директории live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:

Источник:

напоминалка по netstat

sudo netstat -ltup

Флаг -l указывает netstat вывести все прослушивающие сокеты (сокет это ip + порт), -t показывает все TCP-соединения, -u отображает все соединения UDP, а -p позволяет выводить имя приложения/программы, прослушивающее порт.

Чтобы выводить числовые значения (номер порта), а не имена служб, добавьте флаг -n.

$ sudo netstat -lntup
-------------------------------------------------------------------
s — еще один полезный инструмент для отображения информации о сокетах. Он в своём использовании похож на netstat. Следующая команда выведет все порты прослушивающие соединения TCP и UDP в числовом формате.

$ sudo ss -lntu

Оригинал:
http://blog.sedicomm.com/2019/02/27/4-sposoba-uznat-kakie-porty-proslushivayutsya-v-linux/


1С-Битрикс: Низкие показатели MySQL в мониторе производительности (Решение)


Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
База данных MySQL (запись)      72      5 600      количество запросов на запись в секунду
База данных MySQL (чтение)      5 869   7 800      количество запросов на чтение в секунду
База данных MySQL (изменение)   4 251   5 800      количество запросов на изменение в секунду
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
База данных MySQL (запись)     4 395     5 600     количество запросов на запись в секунду
База данных MySQL (чтение)    6 220    7 800    количество запросов на чтение в секунду
База данных MySQL (изменение)    4 643    5 800    количество запросов на изменение в секунду
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы.

Оригинал статьи - в интернете

подсказки по работе с docker

Docker: Удалить Контейнер — Удалить Все Контейнеры

Список Docker-контейнеров
Список запущенных Docker-контейнеров:

$ docker ps
Список всех Docker-контейнеров:

$ docker ps -a
Удалить Docker-контейнер
Удалить Docker-контейнер по CONTAINER ID или NAME:

$ docker rm
Принудительно удалить запущенный Docker-контейнер:

$ docker rm -f
Удалить Все Docker-контейнеры
Удалить все остановленные (неиспользуемые) Docker-контейнеры:

$ docker container prune -f
Принудительно удалить все Docker-контейнеры, включая запущенные контейнеры:

$ docker rm -f $(docker ps -a -q)

Docker: Удалить Образ — Удалить Все Образы — Удалить Неиспользуемые

Список Docker-образов
Список всех локальных Docker-образов:

$ docker images
Удалить Docker-образ
Удалить Docker-образ по IMAGE ID:

$ docker rmi
Принудительно удалить Docker-образ:

$ docker rmi -f
Удалить Неиспользуемые Docker-образы
Удалить все неиспользуемые Docker-образы:

$ docker image prune -a -f
Удалить Все Docker-образы
Принудительно удалить все Docker-образы:

$ docker rmi -f $(docker images -q)

оригинал:

четверг, 13 сентября 2018 г.

Прерывание проверки дискового массива в mdadm

MDADM, поставляемый вместе с дистрибутивом Debian, содержит задание CRON, которое раз в месяц запускает проверку целостности массива. На больших массивах, размер которых превышает несколько терабайт, такая проверка может занять слишком много времени. Прогресс выполнения проверки можно узнать в /proc/mdstat

# cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      [>....................]  check =  0.0% (8832/1911569360) finish=7201.4min speed=4416K/sec
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices: 

Прервать такую проверку можно так:

# echo idle > /sys/block/md1/md/sync_action

После чего можно проверить, что массив действительно перестал проверяться:
# cat /proc/mdadm
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices:  

Чтобы отменить такую проверку в будущем, нужно установить параметр AUTOCHECK=false в /etc/default/mdadm

Оригинал статьи:
https://blog.tataranovich.com/2012/04/mdadm.html

вторник, 22 мая 2018 г.

Заметка для рейд1 xen 7.x и XCP-NG 
по мотивам копипаста и исправления ошибок в мануалах.
базовая таблица диска поле установки xen 7.x, без созданного на стадии установки локального хранилища
/ (root) 18GB
(update) 18GB
/boot/efi 512M
/var/log 4GB
swap 1GB

0. Удаляем старое


Первым делом отключаем существующие хранилища (если есть):

xe sr-list
xe pbd-list sr-uuid=
xe pbd-unplug uuid=
xe sr-forget uuid=

естественно, pv и vg указываем свои, т.е. после знака равно можно использовать "TAB"

Теперь останавливаем и удаляем RAID, если они есть в системе:
mdadm --stop /dev/md0
mdadm --stop /dev/md1
mdadm --stop /dev/md2
mdadm --stop /dev/md3
mdadm --stop /dev/md4
mdadm --stop /dev/md5

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2
mdadm --zero-superblock /dev/sdb3
mdadm --zero-superblock /dev/sdb4
mdadm --zero-superblock /dev/sdb5
mdadm --zero-superblock /dev/sdb6

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

cat /proc/mdstat

и останавливаем/удаляем существующие

Ниже я считаю, что раздела /dev/sda4 у вас нет.

1. Строим новое


Удаляем таблицу разделов на /dev/sdb и копируем её с /dev/sda:

sgdisk --zap-all /dev/sdb
sgdisk -R /dev/sdb /dev/sda

Задаем тип RAID для разделов:

sgdisk --typecode=1:fd00 /dev/sdb
sgdisk --typecode=2:fd00 /dev/sdb
sgdisk --typecode=3:fd00 /dev/sdb
sgdisk --typecode=5:fd00 /dev/sdb
sgdisk --typecode=6:fd00 /dev/sdb

Создаем, собственно, RAID:

yes|mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb1 missing
yes|mdadm --create /dev/md1 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb2 missing
yes|mdadm --create /dev/md2 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb3 missing
yes|mdadm --create /dev/md3 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb5 missing
yes|mdadm --create /dev/md4 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb6 missing


Создаем новый раздел подкачки. Он не будет жить на RAID, поэтому у нас их будет два.
mkswap /dev/md4


Создаем разделы (корень и /var/logs) и монтируем:
mkfs.ext3 /dev/md0
mkfs.ext3 /dev/md3
mount /dev/md0 /mnt
mkdir -p /mnt/var/log
mount /dev/md3 /mnt/var/log

Копируем файлы на новый раздел:

cp -xR --preserve=all / /mnt

Создаем файл mdadm.conf:

echo "MAILADDR root" > /mnt/etc/mdadm.conf
echo "auto +imsm +1.x -all" >> /mnt/etc/mdadm.conf
echo "DEVICE /dev/sd*[a-z][1-9]" >> /mnt/etc/mdadm.conf

mdadm --detail --scan >> /mnt/etc/mdadm.conf
cp /mnt/etc/mdadm.conf /etc


2. Правим fstab и grub



Изменяем точки монтирования на RAID:
sed -i 's/LABEL=root-[a-zA-Z\-]*/\/dev\/md0/' /mnt/etc/fstab
sed -i 's/LABEL=swap-[a-zA-Z\-]*/\/dev\/sda6 md4/' /mnt/etc/fstab
sed -i 's/LABEL=logs-[a-zA-Z\-]*/\/dev\/md3/' /mnt/etc/fstab
sed -i '/sda6/ a\/dev/sdb6          swap      swap   defaults   0  0 ' /mnt/etc/fstab


Копируем метку раздела на /dev/sdb:
e2label /dev/sda1 |xargs -t e2label /dev/sdb1


Делаем chroot в нашу будущую систему:
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /run /mnt/run
chroot /mnt  /bin/bash


Устанавливаем загрузчик:
grub-install /dev/sdb

груб начнет ругатся, исправление:
parted /dev/sdb set 3 bios_grub on

(или grub-install /dev/sdb но перед входом в chroot)

и обновляем мбр/жпт   partprobe
Создаем новый initrd:
Внимание! В большинстве мануалов, строка для дракута немного длиннее, т.к. все скопипищено с аналогичного мануала xen 6x
в результате дракут не отрабатывает как положено.
dracut -q --mdadmconf --fstab --add="dm mdraid" --add-drivers="raid1 raid10" --force /boot/initrd-$(uname -r).img $(uname -r) -M




Меняем конфигурацию GRUB, чтобы загрузиться с RAID:
sed -i 's/quiet/rd.auto rd.auto=1 rhgb quiet/' /boot/grub/grub.cfg
sed -i 's/LABEL=root-[a-zA-Z\-]*/\/dev\/md0/' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod gzio' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod part_msdos' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod diskfilter mdraid09' /boot/grub/grub.cfg
sed -i '/search/ c\   set root=(hd0,gpt1)' /boot/grub/grub.cfg


Выходим из chroot:
exit

////////Запрашиваем КВМ

Перезагружаемся. В качестве загрузочного диска ставим второй, на котом мы создали RAID. Если что-то пойдет не так — будет шанс загрузиться со «старой» системы и попробовать еще раз.

Если всё прошло удачно, то переписываем таблицу с /dev/sdb на /dev/sda:
sgdisk -R /dev/sda /dev/sdb


И добавляем разделы в RAID:
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3
mdadm -a /dev/md3 /dev/sda5
mdadm -a /dev/md4 /dev/sda6


На всякий случай, и переустанавливаем загрузчик на /dev/sda:
grub-install /dev/sda

Перезагружаемся еще раз, дабы проверить, что все установилось корректно.
Ну вот, собственно, и всё. Теперь осталось подключить (или создать) разделы с данными, добавить (если нужно) их в RAID и создать/подключить хранилища:

сначала создаем разделы на sda и sdb, потом рейд, и потом дальше по тексту

xe sr-create content-type=user device-config:device=/dev/md5 host-uuid= name-label=”SRRaid1-Local” shared=false type=lvm

понедельник, 28 августа 2017 г.

Cloud Hosted Router god mode installation
(Установка CHR на любое железо либо VDS)

CHR_VERSION=6.37
INSTALLPATH=/dev/vda

apt-get update &&
apt-get install -y unzip wget pv &&
wget http://download2.mikrotik.com/routeros/${CHR_VERSION}/chr-${CHR_VERSION}.img.zip &&
unzip chr-${CHR_VERSION}.img.zip &&
echo u > /proc/sysrq-trigger &&
pv chr-${CHR_VERSION}.img | dd of=$INSTALLPATH &&
reboot
/user set admin password=********
/ip address add address=A.B.C.D/24 interface=ether1
/ip route add gateway=A.B.C.1
Оригинал на гитхаб https://gist.github.com/deemru/b6ae7e87aed251b727650b360867cfae