Я не таскаю закрытый ключ на промежуточную машину. Прыжок для меня — дырка в TCP, не второй дом для ssh-agent. Ниже — чем ProxyJump отличается от проброса агента, когда агент всё-таки оставляю, и чем проверяю, что ключ с ноутбука никуда не уехал.

Хосты в примерах вымышленные: jump.example.net (документационный 203.0.113.40), внутренний prod-web-01.internal, пользователь ops. Свои имена и ключи подставляйте, чужие из чатов не копируйте.

Две привычки, которые путают с «удобным прыжком»

Первая: положить тот же закрытый ключ на bastion. «Ну я же сам туда захожу, чего его беречь». Bastion — это машина, на которую смотрит интернет. На ней чаще стоят общие учётки, старый sudo, чужой tmux. Если ключ от прода лежит файлом в ~/.ssh на такой коробке, компрометация прыжка равна компрометации всего, куда этот ключ пускают. Пароль на ключ тут слабое утешение: его снимут вместе с файлом, из памяти агента или из вашей же сессии.

Вторая: ForwardAgent yes глобально в ~/.ssh/config или в системном ssh_config. Так делают, чтобы со прыжка открыть следующий ssh «как с ноутбука». Удобно. И ровно поэтому опасно. На время сессии на джампе появляется unix-сокет агента. Любой, кто может читать этот сокет — root, ваша скомпрометированная учётка, чужой процесс под тем же uid — может пользоваться ключами, пока вы онлайн. Ключ с диска не копировали. Подпись от вашего агента уже достаточно.

Есть ещё гибрид: ключ на ноутбуке, а на прыжок его один раз залили «на всякий случай» и забыли. Потом ротировали ключ дома, на джампе старый остался. Я такие находки встречаю чаще, чем хотелось бы: ls -l ~/.ssh на bastion и два id_*, один из которых уже «не наш».

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

ssh-agent на ноутбуке — нормальная вещь. Он держит расшифрованные ключи в памяти, чтобы не тыкать passphrase на каждый git fetch. Плохо не агент. Плохо отдавать его сокет чужой машине.

При ForwardAgent yes клиент поднимает на удалённой стороне канал и выставляет SSH_AUTH_SOCK. Дальше ssh prod-web-01, запущенный уже на прыжке, ходит в этот сокет. Подпись делает ваш ноутбук. Выглядит безопасно: «ключ же дома». Но решение «подписать вот этот challenge» принимает процесс на bastion. Если bastion врет, вы подпишете не то соединение, о котором думаете.

Практическая картинка, которую я показываю заказчику:

• Вы в сессии на jump.example.net.
• echo $SSH_AUTH_SOCK даёт путь вроде /tmp/ssh-XXXX/agent.1234.
• С правами на этот сокет можно сделать ssh-add -L и увидеть ваши ключи.
• Дальше — обычный ssh ops@prod-web-01.internal. Прод видит ваш ключ. В authorized_keys это тот же самый ключ, которым вы заходите «сами».

Root на джампе для этого не всегда нужен. Достаточно вашей же утёкшей сессии, crон-скрипта под тем же uid или «временного» бинарника в $PATH. Поэтому фраза «ну у нас же на bastion только свои» меня не греет: свои тоже ошибаются, а агент не спрашивает, кто именно попросил подпись.

Отдельно: ssh-add -c на ноутбуке чуть лучше, чем голый агент. Перед каждой подписью всплывает confirm. Это не броня, но если сокет увели тихо, вы хотя бы увидите лишний запрос в момент, когда сами ничего не открывали.

ProxyJump: прыжок без вашего ключа на той стороне

ProxyJump (ключ -J) делает другое. Клиент на ноутбуке открывает ssh на bastion и просит его прокинуть TCP до цели. Аутентификация на prod-web-01 идёт с ноутбука, напрямую в этом тоннеле. На прыжке нет вашего закрытого ключа, нет сокета агента, нет второго ssh от вашего имени.

Грубо: bastion видит, что с вашего IP пришёл ssh и что вы попросили соединиться с prod-web-01:22. Bastion не видит, каким ключом вы представились проду, и не может этот ключ переиспользовать через минуту после того, как вы отключились.

Минимальный ~/.ssh/config, с которого я начинаю:

Host jump
    HostName jump.example.net
    User ops
    IdentityFile ~/.ssh/id_ed25519_jump
    IdentitiesOnly yes
    ForwardAgent no

Host prod-web-01
    HostName prod-web-01.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent no

Два ключа — не паранойя. Ключ на интернет-джамп я считаю расходным: его проще отозвать. Ключ на прод на прыжок не кладу и в агент для сессии на jump не пихаю, если можно не пихать. IdentitiesOnly yes обязателен: иначе клиент переберёт все ключи из агента, и вы сами не вспомните, чем открыли хост. Плюс лишние попытки ключей иногда заканчиваются Too many authentication failures.

Одноразово без конфига:

ssh -J ops@jump.example.net ops@prod-web-01.internal

Два и больше прыжка — список через запятую:

ssh -J jump.example.net,dmz-gw.example.net ops@prod-web-01.internal

В конфиге то же самое: ProxyJump jump,dmz-gw. Старый ProxyCommand ssh -W %h:%p jump я оставляю только там, где клиент древний и ProxyJump ещё нет. Смысл тот же: проброс TCP, не проброс агента.

Как я проверяю, что агент не уехал

После захода на цель смотрю три вещи, не «ну вроде работает».

На ноутбуке, до входа:

ssh -G prod-web-01 | egrep -i 'proxyjump|proxycommand|forwardagent|identityfile|identitiesonly'

Хочу увидеть свой ProxyJump, forwardagent no, нужные IdentityFile и identitiesonly yes. Если forwardagent yes приехало из /etc/ssh/ssh_config или из Host * в конце файла — чиню там, а не добавляю ещё один Host выше, который потом перебьют.

Вход с отладкой:

ssh -v prod-web-01 2>&1 | egrep -i 'proxy|jump|forwarding|agent|Offering|Authentication succeeded'

Ищу, что клиент идёт через jump и что нет строк про agent forwarding. «Offering public key» должно относиться к ключу прода, не к ключу джампа. Если клиент предлагает пять ключей подряд — IdentitiesOnly не сработал.

На самой цели и на прыжке, уже внутри сессии:

echo "SSH_AUTH_SOCK=${SSH_AUTH_SOCK:-}"
ssh-add -l

На prod-web-01 при чистом ProxyJump сокет агента обычно пустой, ssh-add -l отвечает, что агента нет. На прыжке при обычном заходе на сам jump — то же самое, если я не просил проброс. Если сокет вдруг есть, а я его не включал, ищу кто: Host *, Include-info в конфиге, обёртка вроде assh/sshpass, корпоративный «улучшатель» ssh.

Ещё одна проверка, которую люди пропускают: ключи на диске прыжка.

ls -l ~/.ssh
find ~/.ssh -type f \( -name 'id_*' -o -name '*.pem' \) ! -name '*.pub'

Закрытых ключей там быть не должно. Если есть — снимаю с машины, смотрю authorized_keys на проде, не торчит ли тот же pubkey, и ротирую. Pubkey на прыжке (чтобы вы сами на него заходили) — нормально. Приватник от прода — нет.

Когда агент всё-таки нужен — и как его не размазать

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

• С удалённой машины нужно сходить в git по SSH вашим ключом, а ключ на эту машину класть нельзя. Тогда агент — меньшее зло, чем файл в ~/.ssh.
• Старый сценарий, который сам делает ssh со прыжка на пачку хостов и не умеет ProxyJump. Это чинят, но не в пять минут посреди инцидента.
• Промежуточный хост должен подписать что-то ещё вашим ключом (редко, и я сначала пытаюсь перенести это действие на ноутбук).

Правило одно: агент включаю на конкретный Host, не на *. И только на время задачи.

Host git-build.internal
    HostName git-build.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent yes

На ноутбуке ключ в агент кладу с подтверждением:

ssh-add -c ~/.ssh/id_ed25519_prod

Сессию короче держу. После работы ssh-add -d этот ключ из агента. На прыжке в sshd_config я по возможности ставлю AllowAgentForwarding no — тогда даже ошибочный ForwardAgent yes у клиента не поднимет сокет. Если агент нужен на одну машину за прыжком, форвардинг агента разрешаю только там, не на bastion.

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

ansible_ssh_common_args: '-o ProxyJump=ops@jump.example.net'

или ansible_ssh_extra_args с тем же. Ключ остаётся на контрольной машине. Если вам «без ForwardAgent плейбук не едет», чаще виноват не Ansible, а то, что роли сами делают ssh/rsync/git уже на целевом хосте вашим ключом. Это другая задача: либо ключ деплоя на целевой машине, либо отдельный deploy key в git, либо вынести шаг на ноутбук.

Что должно быть на самом прыжке

Bastion я собираю скучно. Чем меньше на нём живёт, тем меньше соблазна «раз уж зашли, давайте тут ключи».

• Отдельный ключ только для входа на jump. Этот ключ не пускает на прод.
• PermitRootLogin no, вход по паролю выключен, по возможности отдельный порт или хотя бы geo/fail2ban — как принято у заказчика, не догма.
• AllowTcpForwarding yes (иначе ProxyJump не взлетит), AllowAgentForwarding no, X11Forwarding no.
• Если sshd умеет PermitOpen — ограничиваю, куда вообще можно прыгать: только рабочие подсети, не «любой порт мира через нас».
• Нет общих ops с одним ключом на пятерых. Если ключ общий, вы не отзовёте одного человека.
• На диске нет id_* без .pub. Нет authorized_keys с ключами прода «для удобства».

Кусок sshd_config на прыжке, от которого я отталкиваюсь:

AllowAgentForwarding no
AllowTcpForwarding yes
X11Forwarding no
PermitTunnel no
GatewayPorts no
# если политика позволяет — режем направления:
# PermitOpen prod-web-01.internal:22 prod-db-01.internal:22

PermitOpen легко забыть и потом час ловить administratively prohibited. Сначала проверяю, что ProxyJump жив без него, потом сужаю. Логи sshd на прыжке смотрю не «красиво ли», а кто и куда просил forward: если из сессии ops вдруг полезли на адрес, которого в заявке не было, это уже не удобство, а инцидент.

Мелочи, из-за которых «прыжок не работает»

Частая жалоба: «с -J меня не пускает, а два ручных ssh работают». Почти всегда одно из трёх.

Первое — разные пользователи. На jump вы ops, на проде deploy, а в команде указали одного. В конфиге это два User. В -J — явно ops@jump и deploy@prod.

Второе — DNS. Ноутбук не резолвит prod-web-01.internal, а bastion резолвит. ProxyJump соединяет туда, куда сказал клиент. Если клиент не знает имя, пишу в HostName адрес, который виден с прыжка, либо завожу имя в локальный /etc/hosts только как метку. Обратная ловушка: в HostName поставили внешний IP прода, которого с прыжка нет — ручной второй ssh с jump шёл на внутреннее имя, а ProxyJump пытается в белый адрес.

Третье — ключи и агент. Клиент предлагает ключ джампа на прод, прод отвечает «не тот» несколько раз и отваливается. Лечится IdentitiesOnly и отдельным IdentityFile. Если ключ в агенте один, а файлов много, агент всё равно может предложить не то: поэтому для прод-хостов я указываю файл явно.

Четвёртое, реже: ControlMaster. Мультиплекс на jump удобен, но старый сокет иногда держит чужие опции. Если после правки конфига поведение «как раньше», сношу сокеты ~/.ssh/cm-* и проверяю ещё раз.

Что я отказываюсь считать решением

Не считаю решением скопировать закрытый ключ на bastion «только на время работ». Файл переживает работы. Его найдёт следующий, кто зайдёт под той же учёткой.

Не считаю решением глобальный ForwardAgent yes «потому что так в wiki». Wiki часто писали, когда ProxyJump ещё не было в клиенте по умолчанию. Сейчас клиент это умеет давно.

Не считаю решением один ключ на всё: ноутбук, jump, прод, git, CI. Отзыв после утечки тогда равен «перевыпустить жизнь». Два-три ключа с понятной ролью дешевле нервов.

Не считаю решением «у нас на джампе свои люди, нам не надо». Свои люди оставляют tmux, ставят тестировать бинарник, дают sudo на час. Агент в этот час работает на всех.

Считаю решением короткую схему, которую можно проговорить вслух: ключ прода живёт на ноутбуке, прыжок только прокидывает TCP, агент выключен, кроме одной явно названной машины, и на диске bastion нет ни одного id_* без суффикса .pub. Это скучно. Зато когда bastion однажды вскроют — а интернет-машину вскрывают — прод не откроется тем же ключом из чужой сессии.

Я не продаю «умный дом, который сам всё спасёт». Мне нужно одно: когда я не дома, машины должны успеть сами размонтировать диски и погаснуть в правильном порядке. Ниже — как я это собираю, что ломается, если порядок перепутать, и что смотреть утром, если ночью свет всё-таки ушёл.

Хосты в примерах вымышленные: nas.home.lan, pc-office, nut-master. Свои имена, VLAN и модель ИБП подставляйте.

Почему «ИБП стоит» ≠ «файловая система целая»

Журнал ext4, NTFS dirty bit, ZFS intent log — это подушки. Они уменьшают шанс полной смерти тома, но не отменяют простой факт: если в момент отключения шёл сброс кэша, дописывался RAID-страйп или клиент держал открытый файл по SMB, вы ловите как минимум долгий fsck и «тихую» порчу одного файла. На NAS это особенно обидно: локальный диск ПК ещё можно пережить, а общий том — уже заявка «откати бэкап, но не вчерашний».

ИБП даёт время. Не бесконечное. Бытовой line-interactive на NAS + роутер + коммутатор часто держит от нескольких минут до четверти часа под реальной нагрузкой. Если за это время никто не начал shutdown, батарея просто кончится. Тогда ИБП либо уйдёт в bypass и потухнет, либо сам отрубит розетки. Для дисков разницы почти нет: питание пропало на работающей ФС.

Отдельная ловушка — «умные» розетки и сценарии вроде «через 60 секунд после пропадания 220 отключить NAS, чтобы экономить батарею». Это не shutdown. Это тот же hard power-off, только реле сработало красиво. Резать питание можно только после того, как ОС сама погасла.

Порядок, который я держу в голове

Клиенты с сетевыми дисками выключаются раньше хранилища. Хранилище — раньше, чем сеть, по которой ему пришла команда. Монитор ИБП (тот, у кого USB в ИБП) гаснет последним из компьютеров. Коммутатор и роутер живут до последнего: без них команда shutdown до NAS не доедет.

На пальцах для типичной квартиры/небольшого офиса:

• Короткий моргающий свет (секунды) — ничего не выключаю. Только пишу в лог ONBATT и, если настроено, шлю уведомление.
• Питание так и не вернулось, батарея ушла в «мало» или осталось несколько минут рантайма — начинаю сценарий.
• Сначала ПК, тонкие клиенты, виртуалки, которые держат SMB/NFS/iSCSI на NAS. Им нужно сбросить кэш и отпустить файлы.
• Потом сам NAS: unmount, flush, штатный poweroff. DSM/TrueNAS на это могут занять пару минут, не секунды.
• Потом хост, который видит ИБП по USB (NUT master). Он же в конце может дать ИБП команду снять нагрузку.
• Роутер и коммутатор не трогаю сценарием. Они умрут сами, когда ИБП снимет розетки — к этому моменту компьютеры уже должны быть off.

Перепутать два места легко. Первое: NAS выключился, а pc-office ещё дописывает проект на \\nas\share. Клиент получит обрыв, локальный кэш SMB может соврать, а на томе останется недописанный файл. Второе: выключили коммутатор «чтобы экономить батарею», и NAS, который должен был принять команду по сети, её уже не услышит. Дальше NAS живёт до нуля батареи и падает как есть.

Кто вообще имеет право нажимать shutdown

USB от ИБП физически торчит в один хост. Не в два сразу: hid-драйвер не шарится. Этот хост становится источником правды: он читает OL/OB/LB, считает рантайм и рассылает остальным «пора гаснуть».

Три рабочие схемы, которые я встречаю:

• USB в NAS (Synology/TrueNAS). NAS сам гаснет по своему «UPS». Остальные машины либо клиенты NUT/Synology UPS Server, либо их вообще нет в сценарии. Минус: если ПК с примонтированными шарами не клиент, он переживёт NAS и умрёт позже на пустой батарее.
• USB в отдельный Linux («nut-master»). Классика Network UPS Tools: master видит ИБП, slaves слушаются. Порядок я тогда рисую скриптом на master, а не надеюсь, что все slaves погаснут «примерно одновременно».
• Вендорский агент на Windows (PowerChute и аналоги). Работает, пока в контуре один ПК. Как только появляется NAS с шарами, Windows-агент про NAS не думает. Либо добавляю NUT/SSH со стороны Linux, либо сознательно оставляю NAS единственным, кто умеет гаснуть.

Правило, которое я записываю заказчику в одну строку: кто держит диски с чужими сессиями — тот не имеет права умереть первым. NAS с открытыми SMB — не первый. Хост с USB — не первый, если он должен ещё раздать команду.

NUT: master, slave и почему «все slave» — плохой порядок

На nut-master минимум такой каркас. Имена и пароли вымышленные, в прод так не копировать.

# /etc/nut/ups.conf
[officeups]
    driver = usbhid-ups
    port = auto
    desc = "office line-interactive"

# /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN 192.168.10.10 3493

# /etc/nut/upsd.users
[upsmon]
    password = "replace-me"
    upsmon master

# /etc/nut/upsmon.conf
MONITOR officeups@localhost 1 upsmon replace-me master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
POWERDOWNFLAG /etc/killpower
FINALDELAY 5

LISTEN только во внутреннюю сеть, не на белый IP. upsd — не веб-морда.

На NAS или втором Linux slave выглядит так:

MONITOR officeups@192.168.10.10 1 upsmon replace-me slave
SHUTDOWNCMD "/sbin/shutdown -h now"

Если и pc-office, и nas.home.lan оба slave, NUT при FSD скажет им гаснуть почти вместе. Для меня этого мало. Клиенту нужно 20–40 секунд на unmount, NAS — минуты на сброс томов. Поэтому на master я не полагаюсь на одновременный FSD, а вешаю свой NOTIFYCMD: сначала гашу клиентов по SSH, жду, потом NAS, и только потом локальный shutdown.

Грубый скелет, без прикрас:

#!/bin/bash
# /usr/local/sbin/ups-shutdown-order.sh
# вызывается из NOTIFYCMD на ONBATT+LB или FSD, не на каждый ONBATT
set -eu
clients="pc-office.home.lan htpc.home.lan"
nas="nas.home.lan"

for h in $clients; do
  ssh -o ConnectTimeout=5 "shutdown@$h" 'sudo /sbin/shutdown -h +0' || true
done
sleep 45

ssh -o ConnectTimeout=8 "shutdown@$nas" 'sudo /sbin/shutdown -h now' || true
# DSM: часто удобнее synoshutdown / shutdown из их sudoers, не systemd
sleep 90

/sbin/shutdown -h now

Таймауты не универсальные. На живом NAS я один раз засекаю, сколько он гаснет от команды до того, как погасли дисковые LED. Это и есть нижняя граница sleep плюс запас. Если DSM выключается 2,5 минуты, sleep 30 — способ убить том почти наверняка: master погас, ИБП снял нагрузку, NAS ещё писал.

Доступ shutdown@ — отдельная учётка с sudo только на shutdown -h, ключ без пароля, только с nut-master. Не админ «на все команды».

Когда начинать: ONBATT — ещё не повод рубить всё

Короткий провал 220 я не превращаю в массовый reboot. Иначе каждый сварочный сосед и каждый ввод резерва на ТП будут по ночам гасить офис.

Смотрю статус так:

upsc officeups@localhost
# важные поля:
# ups.status     OL / OB / LB / FSD / CHRG
# battery.charge
# battery.runtime

OL — сеть есть. OB — работаем от батареи. LB — мало. FSD — forced shutdown уже идёт.

Практическая схема, которой я пользуюсь:

• ONBATT без LB — лог, письмо или Telegram, ничего не гашу. Жду 30–120 секунд: свет часто возвращается.
• Порог по рантайму, не по красивому проценту. «20%» на старой батарее может быть одной минутой. Смотрю battery.runtime и засечённое время реального гашения контура.
• Старт сценария, когда остатка хватает на: ожидание клиентов + shutdown NAS + запас. Если весь контур гасится 3 минуты, порог «осталось 4 минуты» — уже игра в кости.
• Калибровку батареи и «сколько реально держит» делаю раз в сезон, локально, не в первую командировку.

Вендорские галочки в DSM вроде «выключить при 15%» без замера рантайма я не доверяю. Процент врёт чаще, чем секунды.

Что именно вешать на батарейные розетки

На «battery backup», не на «surge only»:

• роутер и коммутатор, через который NAS получает команду;
• сам NAS;
• хост с USB в ИБП;
• ПК, которые обязаны штатно погаснуть, а не «ну переживём chkdsk».

Не вешаю лазерный принтер, обогреватель, большой монитор «ну раз розетка свободна». Они съедают минуты, которые нужны дискам. PoE-коммутатор с кучей камер может сожрать батарею быстрее NAS — тогда камеры либо на отдельный маленький ИБП, либо сознательно не входят в контур «спасти ФС».

Отдельный камень: модем провайдера. Если он не на ИБП, уведомление «свет пропал» из дома вы не получите: канал умрёт вместе с 220. На shutdown это не влияет — сценарий локальный. На ваше спокойствие в поездке — влияет. Я либо питаю ONT/модем от того же ИБП, либо не жду, что телега доедет.

Windows, DSM, TrueNAS — где люди обычно срезают угол

Windows по умолчанию не слушает NUT. Варианты, которые работают у меня без вендорской простыни: WinNUT-Client как slave, либо SSH/WinRM с master и штатный shutdown /s /t 0 /f. /f закрывает приложения принудительно — для ночного обрыва питания это меньшее зло, чем диалог «сохранить документ» до конца батареи. Для интерактивного ПК днём — неприятно, поэтому порог LB, а не первый ONBATT.

Synology: «Панель управления → Оборудование и питание → ИБП». Если USB в NAS, включаю сетевой UPS-сервер Synology, чтобы другой их же NAS или NUT-совместимый клиент получил сигнал. Если USB в Linux — DSM настраиваю как NUT slave на nut-master. Проверяю, что команда реально гасит DSM, а не пишет «событие ИБП» в журнал и живёт дальше. Разница видна один раз, если посидеть рядом с LED дисков.

TrueNAS: служба UPS — тот же NUT. Не забываю SHUTDOWNCMD и что jail/VM должны уехать до zpool. Иначе пул экспортируется, пока виртуалка ещё пишет в zvol.

systemd на Linux: shutdown -h лучше, чем systemctl halt без понимания, уйдёт ли питание. Для NUT master ещё важен POWERDOWNFLAG /etc/killpower и проверка upsmon -K на старте: ИБП после пачки shutdown должен снять нагрузку, а когда 220 вернётся — подать её снова, чтобы машины включились. Без этого батарея догорит в ноль на уже выключенных ПК, и утром часть железа не встанет, пока кто-то не нажмёт кнопку на ИБП.

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

Выключение — половина. В BIOS/UEFI хоста и NAS смотрю «Restore AC Power Loss» / «After Power Loss»:

• NAS — обычно Always On. Хранилище должно подняться само.
• nut-master — тоже Always On. Иначе следующий обрыв никто не отследит.
• Офисный ПК — Last State или Off. Мне редко нужно, чтобы он сам ревел в пустой комнате.

Wake-on-LAN тут ни при чём: его некому послать, пока вы спите в другом городе. Это про поведение блока питания после возврата 220.

Роутер на ИБП сам поднимется. Если у провайдера ONT долго регистрируется, это не повод задерживать shutdown: к моменту возврата света компьютеры уже должны быть холодные.

Как я это проверяю, не надеясь на «первый настоящий обрыв»

Первый тест — только локально, днём, с руками на кнопке ИБП и с копией важных томов, которая не на этом же NAS.

• upsc в норме: OL, рантайм похож на правду, USB не отваливается в dmesg.
• Выдёргиваю входную вилку ИБП из стены, не нагрузку. Статус должен стать OB. Клиенты ещё живы.
• Жду порог или форсирую сценарий. Смотрю, что pc-office погас первым, шары отпустились, потом погас NAS, потом master.
• Засекаю время от старта сценария до момента, когда на NAS нет активности дисков. Это число кладу в sleep и в порог батареи.
• Втыкаю вилку обратно. ИБП берёт сеть, поднимает нагрузку, NAS стартует сам.

Форсировать FSD командой NUT можно, но на чужом контуре в пятницу вечером я этого не делаю. Слишком легко получить тот самый обрыв, от которого писали статью.

После теста:

# Linux / TrueNAS
journalctl -u nut-monitor -u nut-server --since today
zpool status
dmesg -T | tail

# DSM: Storage Manager / журналы ИБП, не «всё зелёное в виджете»

# Windows
wevtutil qe System /q:"*[System[EventID=6008 or EventID=6006 or EventID=41]]" /c:5 /f:text

6008 — неожиданное выключение. Если он есть после «успешного» сценария, Windows погасили питанием, не shutdown /s. Сценарий врёт.

Утро после настоящего обрыва, когда меня не было дома

Короткий список, без магии:

• Поднялся ли NAS сам. Если нет — сначала ИБП и «Restore AC», не fsck.
• Тома смонтировались без ручного repair. На ZFS — zpool status, нет ли FAULTED/UNAVAIL после внезапного питания. На DSM — Storage Manager, не «папка открывается в File Station».
• Клиенты, которые писали ночью (бэкап, 1С, камеры на шару). Открыть не «файл на месте», а хвост: последняя запись, целостность архива, не обрезан ли контейнер.
• Журнал NUT: был ли OB → сценарий → shutdown, или сразу смерть на OL (тогда ИБП не участвовал: выбили автомат после ИБП, сдох USB, уехал драйвер).
• Рантайм в логе. Если от OB до смерти прошло меньше, чем длится shutdown NAS — порог надо поднимать или разгружать ИБП.
• Батарея после серии обрывов. Старый аккумулятор «держит на экране 12 минут» и отдаёт три — это уже не настройка NUT, а замена батареи. Цены тут не считаю: если ИБП пищит и рантайм сдулся, это расходник, не «ещё чуть крутануть процент».

Если том всплыл, а один каталог странный — не чиню «на горячую» и не запускаю агрессивный repair, пока нет копии. Сначала снимок/бэкап, потом fsck. ИБП спасает от внезапного питания, но не от желания починить живой диск первой попавшейся галочкой.

Что я отказываюсь считать решением

Не считаю решением плагин умного дома «выключить розетку NAS через минуту». Не считаю решением «поставим ИБП побольше и не будем ничего гасить» — батарея всё равно кончится в длинный обрыв, плюс вы греете комнату зря. Не считаю решением только уведомление в мессенджер: в 03:00 я могу не успеть, а канал может умереть вместе с модемом.

Считаю решением короткую цепочку, которую можно проговорить вслух: кто видит USB, кто гаснет первым, сколько минут это занимает, сколько батарея реально держит, и что должно включиться само, когда 220 вернётся. Это скучно. Зато утром NAS монтирует том, а не просит «ваш диск был извлечён неправильно».

Это не одна настройка. XML-RPC — старый вход в PHP-файл. Application Passwords — отдельные пароли к REST API (и, если xmlrpc не закрыт, ещё и к нему же). Двухфакторка на wp-login.php вторую дверь не закрывает. Ниже — как я решаю, что оставлять, что резать на nginx, и где «плагин запретил xmlrpc» оставляет дыру, которой хватает боту.

Хосты в примерах вымышленные: shop.example. Свои пути, пользователя и префикс логов подставляйте.

Две двери, не «один API WordPress»

На живом сайте обычно торчат три способа что-то сделать «не из браузера»:

• /xmlrpc.php — XML-RPC. Методы вроде wp.getUsersBlogs, wp.newPost, pingback. Клиент шлёт логин и пароль в теле XML на каждый запрос.
• /wp-json/ — REST API. Gutenberg, приложение, ваш скрипт, куча плагинов. С WordPress 5.6 туда ходят Application Passwords через HTTP Basic Auth.
• /wp-login.php — человек в браузере. Сюда Application Password не подходит: это не замена пароля учётки для формы входа.

Путаница начинается здесь. Человек включает 2FA и считает, что «без телефона никто не войдёт». Для формы логина — да. Для xmlrpc, если он принимает основной пароль пользователя, второго фактора нет. Бот не открывает браузер и не вводит код из приложения.

Вторая путаница: «раз есть Application Passwords, xmlrpc больше не нужен, WordPress сам его выключит». Не выключит. Это разные стеки. Пароль приложения, если xmlrpc жив, подходит и туда: в документации ядра прямо сказано, что Application Password можно подставить вместо обычного пароля в XML-RPC. То есть вы завели «безопасный» токен для REST, а старый файл его тоже съест.

Третья: галочка в плагине «Disable XML-RPC». Часто это фильтр xmlrpc_enabled. Он отключает методы, которым нужна авторизация. Файл при этом открывается, PHP крутится, pingback и часть методов без логина могут отвечать. Для бота, которому нужно занять php-fpm, этого достаточно. Для меня критерий «закрыто» — nginx/apache не отдают этот URI в PHP, а не «в админке галочка зелёная».

Зачем xmlrpc вообще существует в 2026-м

Когда-то это был нормальный способ писать с телефона и цеплять Jetpack. Сейчас на большинстве витрин, которые мне отдают, в access.log по xmlrpc.php нет ни одного своего User-Agent. Есть словари паролей, system.multicall и pingback на чужие сайты.

Две атаки, из-за которых я не оставляю файл «на всякий случай»:

• Брутфорс пачкой. system.multicall в одном HTTP-запросе прогоняет десятки wp.getUsersBlogs с разными паролями. Лимитер по запросам на IP видит один POST. Лимит без закрытия multicall — полумера: словарь укладывается в один хит.
• Pingback как чужой молоток. Сайт принимает pingback.ping и сам идёт на URL, который подсунули. Либо участвует в отражённой нагрузке, либо светит внутренние адреса, если кто-то целится в SSRF. Даже без успешного логина файл уже не бесплатный.

Jetpack, официальное приложение WordPress старых версий, часть сервисов рассылки и редкие десктопные клиенты xmlrpc ещё используют. Поэтому я не ставлю deny all вслепую на проде, пока не посмотрел неделю логов. Но «вдруг пригодится» — не причина держать вход, который умеет перебирать пароль администратора без 2FA.

Что такое Application Passwords на практике

С WordPress 5.6 у пользователя в профиле появляется блок «Пароли приложений». Вы даёте имя («backup-bot», «магазин-контент», «телефон редактора»), ядро показывает 24 символа один раз, дальше пароль лежит хешем в user meta. Пробелы в отображении можно не копировать — перед проверкой их срезают.

Зачем это, если «и так есть пароль админа»:

• Основной пароль не разъезжается по скриптам, телефону и подрядчику. Сменили пароль учётки после увольнения — бот с Application Password продолжает жить, пока его явно не отозвали. Это и плюс, и минус: ротация учётки дыру не закрывает.
• Отзыв точечный. Удалили один пароль — отвалилось одно приложение, редактор в браузере не вылетел.
• 2FA на логине можно держать жёсткой. Скрипту второй фактор не нужен, человеку — нужен. Раньше из-за xmlrpc люди 2FA не включали: «приложение не зайдёт».
• В профиле видно, когда пароль последний раз использовали и с какого IP. Не в реальном времени до секунды, с задержкой примерно до суток, но «висит полгода, last used — никогда» уже повод снести.

Ходят они по HTTPS Basic Auth: логин учётки плюс этот пароль. Без HTTPS ядро по умолчанию блок даже не показывает: иначе пароль утечёт на первой же кофейне. Если сайт за прокси и WordPress думает, что он на http, в профиле пусто. Тогда сначала чинят HTTPS/X-Forwarded-Proto, а не «включают фильтр разрешить без SSL». Разрешить Application Passwords по http — сознательно оставить секрет в открытую на участке до прокси.

Права у такого пароля — права пользователя, не «только читать посты». Завели под администратором — получили администратора. Для заливки черновиков мне хватает роли автора или редактора и отдельной учётки, не «ещё один токен на admin».

Как я смотрю, кто чем пользуется

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

Nginx, если access_log в обычном combined:

# пути к логам подставьте свои
awk '$7 ~ /xmlrpc\.php/ {print $1,$4,$9,$11}' /var/log/nginx/shop.example.access.log | tail -n 50
awk '$7 ~ /xmlrpc\.php/ {c[$1]++} END {for (i in c) print c[i], i}' /var/log/nginx/shop.example.access.log | sort -n | tail
awk '$7 ~ /wp-json\// {print $1,$9,$7}' /var/log/nginx/shop.example.access.log | awk '{print $3}' | sort | uniq -c | sort -n | tail

Что я хочу увидеть:

• По xmlrpc: либо пусто, либо одни и те же /24 из сканеров, статус 200 на POST. Свой телефон обычно один-два IP, предсказуемый интервал, не 400 запросов в минуту.
• User-Agent. Jetpack и приложение WordPress не маскируются под Mozilla/5.0 с кривой кодировкой. Сканеры часто пишут xmlrpc, пусто или «WordPress» без версии.
• По REST: Gutenberg с админки будет, это норма. Смотрю, есть ли POST/PUT с внешних IP на /wp-json/wp/v2/posts или media. Если есть — это живой клиент, его нельзя убить вместе с xmlrpc.

Проверка «файл вообще отвечает», не из лога:

curl -sS -D - -o /dev/null https://shop.example/xmlrpc.php
curl -sS https://shop.example/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' | head

200 и список методов — дверь открыта, даже если «плагин безопасности установлен». 403/404 с nginx без X-Powered-By и без тела PHP — уже похоже на правду.

REST и доступность Application Passwords:

curl -sS https://shop.example/wp-json/ | python3 -m json.tool | head
# в корне смотрю ключ authentication.application-passwords
curl -sS -u 'editor:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://shop.example/wp-json/wp/v2/users/me

Если в корне authentication пустой — либо HTTP, либо фича выключена фильтром, либо что-то по дороге срезает заголовок Authorization. Последнее на nginx с PHP-FPM встречается: CGI не пробрасывает Authorization, пока не сказать.

# внутри location ~ \.php$
fastcgi_param HTTP_AUTHORIZATION $http_authorization;

Без этой строки «пароль приложения не работает, а обычный логин в браузере живой» — не баг WordPress, а FPM не видит Basic Auth.

Если xmlrpc никому не нужен — режу на веб-сервере

Это мой дефолт для витрины без Jetpack и без старого мобильного клиента. Фильтр в теме — вторым слоем, не вместо.

# server { ... }
location = /xmlrpc.php {
    access_log /var/log/nginx/shop.example.xmlrpc.denied.log;
    return 403;
}

deny all или return 444 тоже работают. Мне удобнее 403 и отдельный лог: сразу видно, что сканеры не исчезли, просто больше не крутят PHP. На Apache в корне сайта или в конфиге хоста:

<Files xmlrpc.php>
    Require all denied
</Files>

Правило на WAF (если он есть) дублирует, не заменяет. Когда человек правит только Cloudflare и забывает origin, прямой IP сервера xmlrpc снова открыт.

После рестарта nginx проверяю тем же curl: не 200 со списком методов, а 403 без text/html от WordPress. Затем на час оставляю отдельный лог — если вдруг вылезет свой клиент, это будет видно по IP, а не «через неделю редактор звонит, что приложение молчит».

Плагины «выключить xmlrpc» я не ставлю как основную защиту. Лишний PHP на периметре, плюс половина из них делает только xmlrpc_enabled.

Почему xmlrpc_enabled я не считаю закрытием

В functions.php или mu-plugin часто копируют:

add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает авторизованные методы. Запрос всё равно доходит до WordPress: php-fpm воркер занят, плагины загрузились, объектный кеш дёрнули. Pingback на части сборок остаётся в списке. Сканер с system.multicall получает отказ, но уже после входа в PHP.

Если xmlrpc по какой-то причине оставляю, вычищаю хотя бы multicall и pingback:

<?php
// mu-plugins/disable-xmlrpc-extras.php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'], $methods['system.multitask'] );
    unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это не «можно не закрывать файл». Это минимум, если Jetpack реально нужен и закрыть location нельзя. Плюс лимит запросов на этот URI отдельно от admin-ajax.php — иначе снова либо дыра, либо свои ловят 429.

Когда xmlrpc оставляю

Короткий список, не «все интеграции»:

• Jetpack и связанные сервисы Automattic, если они включены сознательно, а не «поставили и забыли».
• Старое официальное приложение WordPress, которое ещё ходит в xmlrpc, а не в REST. Новые клиенты умеют Application Passwords и REST — их я перевожу.
• Редкий десктопный клиент публикации, который заказчик не готов менять сегодня.

Если оставляю, пароль приложения завожу под отдельным пользователем с нужной ролью, основной пароль этой учётки длинный и никуда не светится, 2FA на человеческих админах включена. xmlrpc тогда принимает Application Password, и утечка основного пароля админки не даёт боту этот вход. Обратное тоже верно: утечка пароля приложения — это вход в API с правами этой учётки, пока не отозвали.

Белый список IP на xmlrpc.php лучше, чем открытый мир. Для Jetpack это набор адресов Automattic, он плавает; без WAF с готовым правилом я не рисую его руками «по памяти» и не выкладываю чужие схемы. Практичнее: либо официальное правило у CDN, либо закрыть xmlrpc и жить на REST.

Application Passwords: заводить, не размножать, уметь выключить

Правила, без которых я токен не создаю:

• Одно приложение — один пароль. Не «один на все скрипты», чтобы потом не гадать, какой cron его светит.
• Имя в профиле человеческое: rsync-report bot, iPhone редактор, не test и не 1.
• Учётка с минимальной ролью. Для черновиков не нужен администратор. Для медиа — часто хватает автора.
• Пароль копирую в секрет хранилища один раз. В чат, в тикет и в тело статьи его не кладут. В логах nginx он не должен появиться: Basic Auth лучше не писать в access_log.
• Раз в квартал смотрю last used. Не использовался — удаляю, не «вдруг пригодится».

Через WP-CLI, если SSH есть:

cd /var/www/shop.example/public_html
wp user list --fields=ID,user_login,roles
wp user application-password list editor --fields=uuid,name,created,last_used,last_ip
# создать и сразу забрать только секрет, без таблицы
wp user application-password create editor 'content-bot' --porcelain
# отозвать по uuid из списка
wp user application-password delete editor 00000000-0000-4000-8000-000000000000

Если Application Passwords на сайте никто не использует (нет мобильного клиента, нет внешних скриптов, черновики пишут руками), я их выключаю. Иначе любой администратор может завести себе токен, а через дырявый плагин или XSS это делают уже не только администраторы.

<?php
// mu-plugins/disable-application-passwords.php
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Точечно, только выбранным ролям:

<?php
add_filter( 'wp_is_application_passwords_available_for_user', function ( $allow, $user ) {
    if ( $user instanceof WP_User && in_array( 'administrator', (array) $user->roles, true ) ) {
        return $allow;
    }
    return false;
}, 10, 2 );

Выключить и забыть отозвать уже выданные пароли — мало. Фильтр закрывает новые и использование, но я всё равно прохожусь по списку и удаляю старые: меньше сюрпризов, когда фильтр кто-то снимет «чтобы приложение заработало».

REST я не вырубаю «за компанию»

После статьи про xmlrpc находится человек, который в плагине безопасности ставит Disable REST API. Gutenberg после этого рисует белый экран, кастомайзер полуживой, часть блоков не сохраняется. REST — не xmlrpc. Это штатный транспорт админки.

Что я ограничиваю, не выключая REST целиком:

• Публичный список пользователей. На многих сайтах GET /wp-json/wp/v2/users без авторизации отдаёт логины. Для брутфорса это подарок: не надо угадывать admin. Плагин безопасности или маленький mu-plugin, который на rest_authentication_errors закрывает users для анонимов, — нормальная гигиена. Слепой «REST off» — нет.
• Лимит на /wp-json/ на краю, отдельно от html, если вижу перебор. Не общий location ~ \.php$.
• Не торчит ли создание Application Passwords для всех ролей, если фича нужна только админу.

Проверка, светит ли сайт логины:

curl -sS 'https://shop.example/wp-json/wp/v2/users' | python3 -m json.tool | head

Если в ответе массив с slug — аноним уже знает, кого подбирать. Это не «дыра нулевого дня», это дефолт, который я закрываю в тот же вечер, что и xmlrpc.

Какие комбинации я считаю нормальными

Свожу к трём схемам, без зоопарка галочек.

1. Витрина, правки из браузера, нет Jetpack, нет внешних ботов. xmlrpc на nginx 403. Application Passwords выключены фильтром. 2FA на администраторах. REST живой, список users для гостя закрыт. Это большинство сайтов, которые мне отдают «просто посмотрите безопасность».
2. Нужен скрипт или телефон. xmlrpc всё равно 403, если клиент умеет REST. Одна учётка с ролью по задаче, один Application Password, HTTPS доведён до ядра, Authorization проброшен в FPM. Основной пароль этой учётки не совпадает с паролем приложения и никуда не записан в cron.
3. Jetpack или старый клиент, без них пока никак. xmlrpc открыт, multicall и pingback сняты, лимит на URI, по возможности ограничение по источнику на WAF. Пароли приложений для этого клиента, не основной пароль админа. Остальным пользователям Application Passwords не светятся.

Схема, которую я снимаю сразу: 2FA «для галочки», xmlrpc открыт на мир, в cron лежит основной пароль администратора, в профиле три пароля приложения с именами test/test2/asdf, REST отдаёт users. Это не «чуть-чуть не донастроили». Это три входа с одним секретом и одним без второго фактора.

Что проверить за ночь, а не сразу закрыть ноутбук

После изменений я не верю одному curl с ноутбука. За ночь видно, не отвалился ли свой клиент и не начал ли сканер долбить соседнюю дверь.

• Отдельный лог 403 по xmlrpc: есть чужие POST, нет 200 в php-fpm slowlog по этому файлу.
• В access.log нет всплеска 401/403 на /wp-json/wp/v2/ с офисного IP. Если есть — вы закрыли не то, или срезали Authorization.
• Админка открывается, запись сохраняется, медиа грузится. Gutenberg ходит в REST; если его прибили, узнаете утром от редактора, не из мониторинга.
• wp user application-password list по всем, у кого не пусто: имена понятные, last_ip свой, лишние удалены.
• Повторный curl на /wp-json/wp/v2/users без куки — не список логинов.
• Плагин безопасности не включил обратно xmlrpc своим «режимом совместимости» и не выключил REST. После обновления плагинов это проверяю отдельно.

Если за ночь в xmlrpc-логе вдруг свой IP приложения — не открываю файл обратно «как было», а перевожу клиент на REST и Application Password. Старый xmlrpc ради одного телефона на витрине с заказами я оставляю только когда перевод реально нельзя сделать сегодня, и тогда это временная схема с датой, а не новая норма.

Я почти всегда нахожу одно и то же. Кто-то сделал в phpMyAdmin REPLACE по option_value или прогнал дамп через «найти и заменить» в редакторе. Поля siteurl и home в wp_options — обычные строки, они меняются и сайт «как будто живой». Виджеты, theme_mods, ACF, настройки кэша и куча plugin-опций лежат как PHP-сериализация. Наивная замена портит длину строк внутри этой каши. unserialize() возвращает false, WordPress считает «настроек нет» и рисует пустые сайдбары.

Ниже — как я перевожу домен, чтобы не чинить потом сериализацию руками. Хосты в примерах вымышленные: old.example → shop.example. Свои домены, префикс таблиц и путь к сайту подставляйте, чужой дамп из интернета на прод не накатывайте.

Почему обычный REPLACE ломает сайт

PHP пишет строку не как «текст», а как «длина плюс текст». Упрощённо:

s:19:"https://old.example";

«19» — это число байт внутри кавычек, не «примерно длина». Если в дампе или SQL вы меняете old.example на shop.example, букв становится больше, а префикс s:19: остаётся. Для интерпретатора это уже не валидная сериализация. Массив вокруг тоже разваливается: один битый кусок — и весь option «не читается».

Отсюда картина, которую путают с «плагин не перенёсся»:

• Админка работает: логин, список записей, даже медиатека. Это не сериализация, это обычные таблицы.
• Виджеты пустые или «сбросились на дефолт». Классика — sidebars_widgets и widget_*.
• Кастомайзер/меню выглядят как новый сайт на чистой теме: theme_mods_* не распаковался.
• Страница открывается, визуальный редактор — нет. У конструкторов URL ещё и в JSON/CSS, не только в serialize.
• В PHP-логах за ночь: unserialize(): Error at offset … на option_value или postmeta. Это не «хостер глючит», это вы вчера поправили домен в БД.

siteurl/home я вообще не считаю критерием успеха. Их можно поменять руками за минуту. Критерий — живые виджеты, меню, конструктор и отсутствие старого хоста в опциях, которые WordPress реально читает.

Что я снимаю до любой замены

Пока не лежит откат, я замену не запускаю. Испорченная сериализация откатывается из дампа за две минуты и чинится «на глаз» полдня.

Минимум:

• Дамп базы до замены, не «сейчас сниму, если что». И файл не в wp-content/uploads этого же сайта.
• Архив файлов: тема, uploads, mu-plugins. Конструкторы после смены домена часто оставляют CSS со старым хостом уже в файлах, не в MySQL.
• Текущие siteurl и home, плюс константы из wp-config.php. Если заданы WP_HOME/WP_SITEURL, база может врать, а сайт всё равно ходить на старый адрес — или наоборот, «замена в БД не действует».
• Список вариантов URL, которые реально встречаются. Не один «красивый» https.

Варианты, которые я выписываю в блокнот до команды, не в процессе:

https://old.example
http://old.example
https://www.old.example
http://www.old.example
//old.example
old.example

Слеш на конце — отдельная история. В опциях чаще без него, в контенте и в JSON конструктора бывает с ним. Менять «с слэшем» и «без» двумя проходами безопаснее, чем надеяться, что один проход поймает оба.

Голый old.example без схемы я оставляю на последний проход и смотрю отчёт: он может задеть e-mail вида shop@old.example, CDN, упоминания в тексте. Если почта на этом домене остаётся — голый хост не трогаю или меняю точечно.

Префикс таблиц не угадываю:

# каталог сайта подставьте свой
cd /var/www/example-site/public_html
wp config get table_prefix
wp option get siteurl
wp option get home
wp config get WP_HOME
wp config get WP_SITEURL

Если две последние константы заданы и расходятся с тем, куда вы переезжаете, сначала правлю wp-config.php. Иначе search-replace в базе вы сделаете, а WordPress продолжит считать каноническим старый URL.

WP-CLI: основной путь

На VPS и нормальном хостинге с SSH я не открываю phpMyAdmin для этой задачи. wp search-replace ходит по ячейкам, понимает PHP-сериализацию (и в свежих версиях — JSON), первичные ключи не трогает.

Сначала сухой прогон, чтобы увидеть масштаб, а не «сразу на прод»:

cd /var/www/example-site/public_html

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --dry-run \
  --report-changed-only

--all-tables-with-prefix нужен потому, что дефолт — таблицы, которые WordPress зарегистрировал в $wpdb. У Magento-в-WP это не про нас, а у WooCommerce, форм, кэша, самописных плагинов таблица wp_something_extra легко остаётся со старым хостом. --all-tables без префикса я на шареде с общей MySQL не включаю: можно вылезти в чужую базу на том же пользователе.

--precise гоняет замену через PHP, не через быстрый SQL. Медленнее, зато меньше шансов проскочить колонку, где сериализация не похожа на «очевидную». На магазине в сотни мегабайт дампа это не мгновенно — зато не потом ночью ловить пустую корзину.

Если сухой прогон выглядит здраво (есть попадания в wp_options, postmeta, может быть post content — и нет сюрприза в wp_users.user_email на тысячи строк), снимаю ещё один свежий дамп и запускаю без --dry-run.

GUID записей я обычно пропускаю:

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --skip-columns=guid \
  --report-changed-only

guid в WordPress — идентификатор, не «красивая ссылка». Менять его при переезде домена не обязательно, а фиды и импорты от этого иногда едут. Если у вас старый зоопарк, где в GUID руками писали permalink — смотрите отчёт dry-run по колонке и решайте точечно, не «всем REPLACE».

Дальше те же команды для http://, www и протоколо-относительного //old.example. Один проход по «основному» https почти никогда не вычищает всё: редирект на https могли включить год назад, а в виджете 2019 года лежит http.

Если WP-CLI есть на старом сервере, а на новом ещё нет, удобен экспорт уже с заменой:

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --skip-columns=guid \
  --export=/root/shop-example-after-replace.sql

Накатываю этот SQL на новое место, а не «сырой дамп плюс sed». sed по .sql — тот же класс ошибки, что REPLACE в phpMyAdmin, только в файле на 400 МБ её ещё и не видно.

Если WP-CLI нет

На дешёвом shared без SSH люди ставят плагин вроде Better Search Replace. Под капотом та же идея, что у interconnect/it: идти по ячейкам и пересобирать serialize. Это лучше, чем правка дампа. Это хуже, чем WP-CLI, потому что плагин работает из-под веба, на больших таблицах упирается в timeout, и его ещё надо не забыть удалить.

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

• Сначала дамп. Плагин «умеет dry-run» — dry-run обязателен, как у CLI.
• Ставить, прогнать, снести. Search-Replace, оставленный в корне сайта, — готовая дыра: это скрипт с доступом к базе, который не должен торчать в интернет ни минуты после работы.
• Не мешать в одном заходе «домен» и «путь на диске». Это разные строки. Путь /home/u1234/public_html в сериализации тоже бывает, его меняют отдельно, когда переезд ещё и на другой аккаунт хостинга.

Перенос «архивом плагина миграции» (Duplicator и родственники) сериализацию обычно переживает, потому что замену они делают своим движком, не вашим REPLACE. Имеет смысл, когда нет SSH. Не имеет смысла, когда вы уже на VPS и можете одну команду. Я не тащу лишний плагин на прод ради смены домена.

Что search-replace не видит

База — не весь сайт. После удачной замены в MySQL у меня регулярно всплывает старый хост в файлах.

cd /var/www/example-site/public_html
grep -R --binary-files=without-match -l 'old.example' \
  wp-content/themes wp-content/plugins wp-content/mu-plugins \
  wp-content/uploads wp-config.php 2>/dev/null | head

Типичные находки:

• WP_HOME/WP_SITEURL в wp-config.php — перекрывают базу, спор «я же заменил в опциях» решается здесь.
• CSS/JSON конструктора в wp-content/uploads/elementor/ (и аналоги у других билдеров). Это файлы. Их WP-CLI не трогает. У Elementor после смены домена я ещё регенерирую CSS из админки или, если есть их CLI, отдельной командой замены URL, не надеясь только на MySQL.
• Жёстко прошитый адрес в дочерней теме: логотип, пиксель, кастомный endpoint. Это уже код, не контент.
• Объектный кэш. Redis/Memcached продолжает отдавать старые сериализованные blobs. После замены — flush. Иначе «в базе уже новый домен, в браузере старый» до истечения TTL, и вы начнёте чинить то, что уже починено.

Мультисайт — не тот же чеклист. Там wp_blogs, wp_site, домены блогов, и CLI нужно звать с --url конкретного сайта плюс --network, когда меняете сразу сеть. Если у вас не мультисайт, не копируйте чужие однострочники с --network «на всякий случай».

Как понять, что сериализация жива

Первая проверка — не «главная открылась». Я смотрю то, что сериализация обычно убивает, и то, что REPLACE обычно забывает.

# канонические URL — уже новый домен, без редиректа в голове
wp option get siteurl
wp option get home

# остатки старого хоста по всем таблицам с префиксом
wp db search 'old.example' --all-tables-with-prefix --table_column_once

# виджеты реально читаются, не «таблица на месте»
wp widget list sidebar-1
wp option get sidebars_widgets

Если sidebars_widgets печатает массив с именами сайдбаров — сериализация этого option жива. Если пусто, false или PHP Notice на unserialize — откатились к дампу, не «восстанавливаем виджеты руками».

Грубый проход по опциям, которые WordPress считает сериализованными, но уже не может распаковать:

wp eval '
foreach ( wp_load_alloptions() as $name => $value ) {
  if ( ! is_serialized( $value ) ) { continue; }
  $restored = @unserialize( $value );
  if ( $value === "b:0;" || $restored !== false || $value === serialize( false ) ) { continue; }
  echo $name, PHP_EOL;
}
'

Пустой вывод — хороший знак. Имена вроде widget_block, theme_mods_…, external_updates в этом списке — плохой: именно они после «успешного» REPLACE приезжают битыми.

В админке руками:

• Внешний вид → Виджеты / редактор блоков виджетов: блоки на месте, не пустой холст.
• Меню и расположения меню. «Меню существует, но нигде не назначено» часто значит, что theme_mods не прочитался.
• Медиа: открыть пару старых записей, не главную. В контенте https://old.example/wp-content/uploads/… после нормальной замены быть не должно.
• Конструктор: открыть на редактирование страницу, которую точно верстали не вчера. Белый экран при живой публичной странице — почти всегда JSON/CSS со старым хостом или битая meta.

Смешанный контент (главная по https, картинки по http старого домена) я проверяю не глазами, а по исходнику и по логам. Браузер может дорисовать из кэша.

Что смотреть overnight

Днём вы видите то, что кликнули. Ночью всплывает cron, письма и боты.

За ночь мне нужны:

• Письма сайта: сброс пароля, WooCommerce, формы. В теле и в заголовке From/ссылках не должен торчать старый хост. Это часто не siteurl, а отдельная опция плагина или константа SMTP.
• Cron: wp cron event list и системный crontab. Старый URL в HTTP-cron (wget на wp-cron.php) продолжает дергать прежний домен, пока DNS жив.
• Карта сайта и robots: плагины SEO пишут абсолютные URL. Rank Math/Yoast после переезда я открываю и пересохраняю карту, не надеясь, что «само подхватит».
• Редирект со старого домена. Пока он не 301 на тот же путь нового, Google и закладки клиентов будут кормить оба хоста. Сам search-replace редирект не настраивает — это nginx/хостер.
• Логи PHP на unserialize и на mixed content в error_log. Одна-две строки offset — повод не «подождать», а свернуть на дамп и прогнать замену нормально.
• REST и превью: /wp-json/ должен отдавать новый home в url/home. Иначе мобильные приложения и часть плагинов продолжают стучать на старое имя.

Если старый домен ещё резолвится в тот же DocumentRoot без редиректа, вы будете неделю ловить «то новый, то старый» в кэше и в сериализации, которую кто-то снова сохранит из админки, зайдя по старому имени. Схема одна: один канонический хост, второй только 301, константы и опции смотрят на канон.

Переезд домена в WordPress — это не «поменять две опции в wp_options». Две опции как раз переживают любой REPLACE. Ломается то, что вы не видите в phpMyAdmin с первого экрана: длины строк внутри serialize. Я меняю URL инструментом, который эти длины пересчитывает, потом отдельно ищу хвосты в файлах и кэше, и только после живых виджетов и пустого поиска по старому хосту считаю переезд состоявшимся — не в момент, когда открылась главная.

Проверяем, авторизован ли пользователь на сервере, и есть ли запущенные от него процессы

who
sudo ps -u username

Убиваем процессы пользователя, если они есть

sudo killall -9 -u username

Отключаем все задачи планировщика cron этого пользователя

sudo crontab -r -u username

Собственно удаляем пользователя

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

sudo deluser username

Если нужно удалить всё, включая и его домашнюю директорию, то выполняем команду:

sudo deluser --remove-home username

Команда grep

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

grep "ключевое_слово" /путь/к/файлу.txt

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

grep -r "искомый_текст" /путь/к/каталогу

find и xargs совместно

Комбинация команд find и xargs позволяет находить файлы с заданными критериями и передавать их в качестве аргументов для других команд. Пример:

find /путь -type f -exec grep "искомый_текст" {} +

В данном примере find находит все файлы (-type f) в указанном пути и передает их в grep, где производится поиск заданного текста.

find и grep совместно

Комбинирование find и grep позволяет более тонко настраивать поиск. Например, поиск в файлах, измененных за последние 7 дней:

find /путь -type f -mtime -7 -exec grep "искомый_текст" {} +

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

Что такое cron?

Cron — это стандартный инструмент в Unix-подобных системах, предназначенный для выполнения задач в установленное время или периодически. Он основан на файлах cron, в которых определены задания и их расписание. Эти файлы хранятся в каталоге /etc/cron.d/ или /var/spool/cron/ и обычно недоступны для редактирования напрямую.

Работа с cron

Создание и редактирование cron-задач

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

crontab -e

Она открывает текстовый редактор, в котором можно определить расписание и команду для выполнения. Например, чтобы запустить скрипт “myscript.sh” каждый день в 2 часа ночи, добавьте следующую строку:

0 2 * * * /путь/к/скрипту/myscript.sh

Редактировать команды другого пользователя можно так:

sudo crontab -u username -e

Листинг задач

Список текущих cron-задач можно просмотреть с помощью команды:

crontab -l

Это полезно для проверки текущего расписания и быстрого определения того, что уже настроено.

Вывести задачи другого пользователя можно так:

sudo crontab -u username -l

Удаление задач

Эта команда удаляет все cron-задачи пользователя:

crontab -r

Если необходимо удалить конкретную задачу, используйте:

crontab -l

чтобы увидеть ее номер, а затем:

crontab -r номер

Вывод результата в лог-файл

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

* * * * * /путь/к/вашему/скрипту.sh >> /путь/к/лог-файлу.log 2>&1

Здесь >> используется для добавления вывода в конец файла, 2>&1 перенаправляет стандартные ошибки в стандартный вывод, чтобы они также попадали в лог-файл.

Указание времени выполнения задач

В планировщике задач cron в Linux время выполнения задач задается в виде пяти полей, каждый из которых представляет собой определенный аспект времени. Эти поля определяют минуты, часы, дни месяца, месяцы и дни недели. Вот структура этих полей:

* * * * *
- - - - -
| | | | |
| | | | +----- День недели (0 - воскресенье, 1 - понедельник, ..., 6 - суббота)
| | | +------- Месяц (1 - январь, 2 - февраль, ..., 12 - декабрь)
| | +--------- День месяца (1 - 31)
| +----------- Час (0 - 23)
+------------- Минуты (0 - 59)

Каждое поле может принимать определенные значения или диапазоны значений, а также знаки “*” (звездочка) и “/” (косая черта).

• *: Означает “каждый”. Например, если в поле минут стоит “*”, это означает, что задача будет выполняться каждую минуту.
• число: Определенное значение. Например, если в поле часов стоит “3”, задача будет выполняться в 3 часа.
• число-число: Диапазон значений. Например, “1-5” в поле дней недели означает с понедельника по пятницу.
• */число: Каждый определенный интервал. Например, “*/15” в поле минут означает каждые 15 минут.

Примеры:

Запуск задачи каждый день в 3 часа утра:

0 3 * * *

Запуск задачи каждый понедельник и среду в 12:30:

30 12 * * 1,3

Запуск задачи каждый час:

0 * * * *

Запуск задачи каждый день в 5 утра и 8 вечера:

0 5,20 * * *

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

Поиск больших файлов с сортировкой по убыванию, с выводом в терминал только 20 больших файлов,  в указанной папке

find /путь/к/каталогу -type f -size +100M -exec du -h {} + | sort -rh | head -n 20

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

Поиск больших файлов с сортировкой по убыванию в текущей папке

find . -type f -size +500M -exec du -h {} + | sort -rh

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

Поиск больших папок с сортировкой по убыванию и выводом в терминал только 20 самых больших папок

du -h --max-depth=1 /путь/к/каталогу | sort -rh | head -n 20

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

Поиск папок, содержащих большое количество файлов, с сортировкой по убыванию, и выводом только 20 таких папок

find /путь/к/каталогу -type d -exec sh -c 'echo -n "{} " && find "{}" -maxdepth 1 -type f | wc -l' \; | sort -k2 -nr | head -n 20

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

Для проброса приватного ключа используется SSH Агент. Способ одинаково работает в консоли любых операционных систем Linux, macOS и Windows.

Первым делом проверяем, запущен ли агент, и знает ли он что-то о вашем ключе:

ssh-add -l

Если получаем ответ: Could not open a connection to your authentication agent, запускаем агент командой:

eval 'ssh-agent'

Если ответ: The agent has no identities, значит нужно сообщить ему о вашем приватном ключе, выполнив команду:

ssh-add

Если в ответе команды ssh-add -l вы видите путь к своему приватному ключу, значит всё хорошо, и вы можете подключаться к удалённому серверу по ssh, добавив при подключении опцию -A, то есть вот так:

ssh -A user@host:port

Или можно установить опцию ForwardAgent yes в файле ~/.ssh/config на вашем локальном компьютере:

Host *
  ForwardAgent yes

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

echo "$SSH_AUTH_SOCK"

Если всё ок, то она должна вернуть что-то похожее на:

/tmp/ssh-DCIux21917/agent.21917