sysmerge IT

15 авг. 2019 г.

Автообновление wildcard letsencrypt сертификата

Получить wildcard сертификат бесплатно сейчас довольно легко, через Letsencypt. С помощью подтверждения через DNS записи. Проблема лишь в том, что для продления сертификата оперцию придется повторить. У "больших" игроков на рынке есть специальные плагины для автообновления, как то certbot-dns-cloudflare или certbot-dns-digitalocean.  Сегодня же мы рассмотрим для этих целей плагин https://github.com/joohoi/acme-dns-certbot-joohoi .

Скрипт очень прост в использовании. Качаем его:
 # curl -o /etc/letsencrypt/acme-dns-auth.py https://raw.githubusercontent.com/joohoi/acme-dns-certbot-joohoi/master/acme-dns-auth.py
# chmod 0700 /etc/letsencrypt/acme-dns-auth.py
В случае необходимости настройки в скрипте можно отредактировать ( в частности ACMEDNS_URL ).

Теперь нужно выпустить сертификат. Для этого помимо стандартных опций для получения wildcard letsencrypt сертификата добавляется --manual-auth-hook , который указывает на этот самый скрипт, и который будет запомнен в качестве хука для домена на будущее продление.
 # certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py    --preferred-challenges dns --debug-challenges  -d example.org -d \*.example.org

Уточняем, что опция  --debug-challenges тут так же важна, она позволяет приостановить выполнение скрипта до момента, когда вы будете готовы к валидации CNAME записи.

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

Дальнейшее обновление может выполняться с помощью обычного крона и certbot renew.
20 июн. 2019 г.

Centos VestaCP - exim - Malformed value "unlimitedM" (expansion of "${extract{6}{:}{${lookup{$local_part}lsearch{/etc/exim4/domains/$domain/passwd}}}}M") in local_delivery transport

На одном из серверов возникла проблема с получением писем. В логах почтового сервера наблюдаем следующее:
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm DKIM: d=sender.net s=dkim c=relaxed/relaxed a=rsa-sha256 b=1024 [verification failed - signature did not verify (headers probably modified in transit)]
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm <= sender@sender.net H=mail.sender.net [185.14.28.86] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no K S=1527 id=0d4f9076-6cfb-6cfe-90f4-30ca6341e609@sender.net
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm == admin@site.com.ua R=localuser T=local_delivery defer (-1): Malformed value "unlimitedM" (expansion of "${extract{6}{:}{${lookup{$local_part}lsearch{/etc/exim/domains/$domain/passwd}}}}M") in local_delivery transport

Решением будет правка скрипта пересборки почтовых конфигов.
Нужно отредактировать скрипт  /usr/local/vesta/func/rebuild.sh. Ищем там функцию rebuild_mail_domain_conf() и добавляем в конец:
if [ "$QUOTA" = 'unlimited' ]; then
       QUOTA=0
fi
После чего пересобираем конфиги
v-rebuild-mail-domains admin
 Готово, прием почты должен работать корректно.
11 июн. 2019 г.

Критическая уязвимость в Exim CVE-2019-10149 ( версии 4.87 по 4.91 )

6 июня стало известно о критический уязвимости почтового сервера Exim CVE-2019-10149.
Уязвимости подвержены версии с 4.87 по 4.91.
Фрагменты вирусов, эксплуатирующих данную уязвимость могут быть обнаружены в директориях:
/etc/cron.daily/cronlog
/etc/cron.d/root
/etc/cron.d/.cronbus
/etc/cron.hourly/cronlog
/etc/cron.monthly/cronlog
/var/spool/cron/root
/var/spool/cron/crontabs/root
/etc/cron.d/root
/etc/crontab
/root/.cache/
/root/.cache/a
/usr/local/bin/nptd
/root/.cache/.kswapd
/usr/bin/[kthrotlds]
/root/.ssh/authorized_keys
/.cache/*
/.cache/.sysud
/.cache/.a
/.cache/.favicon.ico
/.cache/.kswapd
/.cache/.ntp
Так же могут присутствовать ключи ssh, скрипты автозапуска в  /etc/rc.local .

Для быстрой очистки и обновления Firstvds выкатил небольшой скрипт, который чистит все файлы, вышеперечисленные, обновляет Exim, делает реинсталл curl'а.

Запустить скрипт можно так:
wget http://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh

5 июн. 2019 г.

Firefox - после обновление пропали скрипты greasemonkey

После очередного обновления Firefox все скрипты greasemonkey (включая его самого) стали недоступны.
Речь идет об обновлении с версии Mozilla до 57 на версию выше.
Чтобы достать свои скрипты нужно полезть по следующему пути:
root@debian:/home/user# ls -la.mozilla/firefox/sbza604q.default/gm_scripts/MyUserScript/MyUserScript.user.js

Оттуда его можно выдернуть и перенести на новый greasmonkey
19 мая 2019 г.

Debian: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 88d 16h 32min 47s). Updates for this repository will not be applied.

На Debian 8 после переключения на архивный репозиторий ftp.debian.org на archive.debian.org запуск обновления пакетов командой apt-get update может завершиться ошибкой
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 88d 16h 32min 47s). Updates for this repository will not be applied.
Error executing command, exiting
Для решения этой проблемы apt можно запустить с ключем '' -o Acquire::Check-Valid-Until=false"
apt-get -o Acquire::Check-Valid-Until=false update
Сделать эту опцию перманентной можно так
echo 'Acquire::Check-Valid-Until "0";' > /etc/apt/apt.conf.d/10no-check-valid-until
после чего apt-get update будет работать в штатном режиме.
7 мая 2019 г.

Сброс пароля IMPI supermicro с загруженной ОС

Иногда может понадобится сброс пароля к IPMI . И если у вас уже имеется загруженная и работающая ОС подключенного к IPMI порту сервера, то сброс пароля IMPI  с этого сервера выглядит максимально просто.

Необходима утилита ipmitool. Теперь нужно определить список юзеров и ID необходимого нам:
# ipmitool user list
ID  Name         Callin  Link Auth    IPMI Msg   Channel Priv Limit
1                    true    false      false      Unknown (0x00)
2   ADMIN            true    false      false      Unknown (0x00)
3                    true    false      false      Unknown (0x00)
4                    true    false      false      Unknown (0x00)
5                    true    false      false      Unknown (0x00)
6                    true    false      false      Unknown (0x00)
7                    true    false      false      Unknown (0x00)
8                    true    false      false      Unknown (0x00)
9                    true    false      false      Unknown (0x00)
10                   true    false      false      Unknown (0x00)
Нужный нам юзер с ID 2.
Сбрасываем ему пароль:
# ipmitool user set password 2 passwdipmi
Set User Password command successful (user 2)
Готово.

 
13 февр. 2019 г.

Centos 7 + lvm2: после ребута изчезают созданные lvm тома - Timer to wait for more drives before activating degraded array md128

Имеем систему Centos 7, raid10, поверх него создается vg командой
vgcreate vg1 /dev/md128
Проверяем
# vgdisplay
 --- Volume group ---
 VG Name               vg1
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  7
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                3
 Open LV               2
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               1,75 TiB
 PE Size               4,00 MiB
 Total PE              459820
 Alloc PE / Size       11520 / 45,00 GiB
 Free  PE / Size       448300 / 1,71 TiB
 VG UUID               iW8xBm-WcJQ-ufP8-VzHH-WfgV-gWpo-A0rdS8
После рестарта же lvm не поднимется. Ни vgscan ни pvscan ничего не находят.
# vgscan
 Reading volume groups from cache.
# pvscan
 No matching physical volumes found
В логах можно заметить такие интересные строки
Started Timer to wait for more drives before activating degraded array md128
Stopped Timer to wait for more drives before activating degraded array md128
То есть почему-то при загрузке системы рейд md128 считается за " degraded". Соответственно на нем не могут инициализироваться lvm тома.
Погуглил на эту тему и натолкнулся на похожий баг https://bugzilla.redhat.com/show_bug.cgi?id=1445924 
Автор рекомендует выключить use_lvmetad  в конфиге /etc/lvm/lvm.conf. Что мы и сделали. И внезапно после ребута все работает как должно.

Загадкой осталось то, почему это происходит. В багтрекере причины тоже не были найдены.
10 янв. 2019 г.

Mariadb: Recovering after a crash using tc.log, Bad magic header in tc log

Клиент упустил момент, когда диск оказался заполненным и результатом оказалась неприятность с mysql сервером, который не восстанавливался после проблемы с ошибками в логе

янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [Note] Recovering after a crash using tc.log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Bad magic header in tc log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Can't init tc log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Aborting
янв 10 14:12:09 post4302.vds systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
янв 10 14:12:09 post4302.vds systemd[1]: Failed to start MariaDB 10.1.37 database server.
янв 10 14:12:09 post4302.vds systemd[1]: Unit mariadb.service entered failed state.
янв 10 14:12:09 post4302.vds systemd[1]: mariadb.service failed.

Решение довольно простое, удаляем из директории Mysql файл tc.log
mv /var/lib/mysql/tc.log /var/lib/mysql/tc.log.bkp

Ну не то чтобы удаляем, а скорее убираем.
Делаем рестарт Mysql сервера и все готово
[root@~]# service mysql restart
Restarting mysql (via systemctl):                          [  OK  ]
 
4 янв. 2019 г.

End of script output before headers: php - failed to setgid (1001: php)

Ни с того ни с сего рабочий буквально недавно сайт начал отдавать 500 ошибку с текстом в логе
End of script output before headers: php
В ходе небольших изысканий было обнаружено, что при попытке открыть сайт в лог /var/log/secure сыпятся следующие ошибки от suexec
Jan  3 22:44:58 user300 suexec[7386]: uid: (1001/admin) gid: (1001/admin) cmd: php
Jan  3 22:44:58 user300 suexec[7386]: failed to setgid (1001: php)
Jan  3 22:44:58 user300 suexec[7387]: uid: (1001/admin) gid: (1001/admin) cmd: php
Jan  3 22:44:58 user300 suexec[7387]: failed to setgid (1001: php)
Jan  3 22:44:58 user300 suexec[7388]: uid: (1001/admin) gid: (1001/admin) cmd: php
которые говорят нам о том, что вероятно у бинарника suexec не хватает S флага для установки SUID или SGID. Установить данный флаг можно командой:

chmod u+s /usr/sbin/suexec
после чего ошибки в логе пропадают.