Better not use pfsense opnsense and other WEB-panels

Панели создают впечатление, что при помощи них можно сэкономить время. Отчасти это верно. Вторая часть звучит как то, что еще больше этого времени можно будет легко потерять. Ключевым обстоятельством тут является то, что панеле-писатели добавляют заметное кол-во дополнительной «логики» в свои поделия, которая, в отличие от исходных компонентов (OS + user space утилит) скорее всего не будет описана нигде, кроме как в исходных текстах, и, если повезет, может быть частично отражена на километрах форумов, наполненных потоком проблем неквалифицированных пользователей — основными потребителями такого рода поделок. В этом придется копаться, и зачастую безрезультатно. Если вас прельщает сомнительная удача стать специалистом очередной «панели» — что ж, удачи, как говорится. Элементарная логика подсказывает, что разумнее потратить время на изучение базовых инструментов, из которых можно собрать систему с гораздо более прогнозируемым поведением. Приведу лишь один пример: OpenVPN в opnsense-системе, после перезагрузки, начал работать нестабильно: соединения устанавливались и спустя 10—15 секунд разрывались. Сам демон OpenVPN тоже перезапускался. Если попытаться гуглить симптомы, можно будет найти все, что угодно, кроме решения — горе-писатели opnsense (а возможно и pfsense — базы этого форка), мониторят доступность заданных шлюзов…

Jan 2 20:42:26 OPNsense apinger: Starting Alarm Pinger, apinger(13341)
Jan 2 20:42:36 OPNsense apinger: ALARM: GWv6(………) *** down ***
Jan 2 20:42:50 OPNsense apinger: Exiting on signal 15.

… и в случае недоступности любого из них (в моем случае это был IPv6 gateway, который перестал отвечать), считают, что нужен перезапуск OpenVPN. Удачной отладки.

How-to boot Proxmox system without starting its VMs

Как загрузить Proxmox-систему без запуска ее виртуалок

Применительно к Debian-based установке

За запуск VMs отвечает systemd’s pve-manager, который запускается в multi-user.target:

% sudo systemctl cat pve-manager.service | sed -ne '/\[Install/,$ p'
[Install]
WantedBy=multi-user.target

В пр-цпе, по логике вещей, достаточно просто запретить этот unit. При попытке сделать это, однако, выясняется, что это просто не работает:

% sudo systemctl disable pve-manager.service
Synchronizing state for pve-manager.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d pve-manager defaults
insserv: Service pveproxy has to be enabled to start service pve-manager
insserv: Service qemu-server has to be enabled to start service pve-manager
insserv: Service pvestatd has to be enabled to start service pve-manager
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
*** Error in `systemctl': double free or corruption (fasttop): 0x00005577b8f55b00 ***

В другом варианте, можно задействовать механизм target’ов, который позволяет сгруппировать набор запускаемых сервисов.

Если посмотреть какой target выполнения используется в Proxmox по-умолчанию, то можно удивиться:

% sudo systemctl get-default
graphical.target

— этот уровень по-смыслу скорее подходит для desktop’а пользователей, нежели сервера. Но это, даже, отчасти, облегчает решение: можно перенастроить pve-manager на запуск на уровне graphical.target, и при необходимости, загрузить систему только до multi-user.target.

Требуемую перенастройку можно сделать так:

systemctl cat pve-manager.service показывает размещение unit-файла:

% sudo systemctl cat pve-manager.service | head -n3
# /lib/systemd/system/pve-manager.service
[Unit]
Description=PVE VM Manager

Внизу, в секции Install, WantedBy нужно заменить на graphical.target. Для того, чтобы systemd подхватил изменения (внутри у него используются symlink’и):

% sudo systemctl reenable pve-manager.service

Загрузку в multi-user.target можно выполнить либо разово, указав systemd.unit=multi-user.target в перечне параметров загрузки системы, либо задать его по-умолчанию:

% sudo systemctl set-default multi-user.target

Если затем потребуется разово перейти в graphical.target, запустив, таким образом, виртуалки:

% sudo systemctl isolate graphical.target

Is your DNS traffic intercepted?

Оказывается, у Akamai и UltraDNS есть сервис, который позволяет ответить на вопрос «с какого IP в действительности они получили запрос от вас»:

  • dig whoami.akamai.net +short
  • dig whoami.ultradns.net +short

Попробуйте — может оказаться, что ваш DNS resolver далеко не последний. 😉

Having issues with scrub proto tcp reassemble tcp?

They might have been caused by tampering with TCP connection in transit. What kind? Well, in fact changing MSS with netfilter’s clamp or OpenVPN maxmss would cause establishing TCP connection to stall.

Если при использовании scrub proto tcp reassemble tcp возникают проблемы, они могут быть вызваны манипуляциями с TCP-соединением на транзитной сети. Например, вследствие изменения MSS, которое может производить Netfilter или OpenVPN maxmss, установка TCP-соединения так и не будет выполнена.

CEPH OSD on SmartOS won’t run in LX zones

На текущий момент (2017-10) запустить CEPH OSD в SmartOS не получится:

2017-10-05 03:54:18.269168 7ffff5151800 -1 filestore(/var/lib/ceph/osd/ceph-6) WARNING: max attr value size (1024) is smaller than osd_max_object_name_len (2048). Your backend filesystem appears to not support attrs large enough to handle the configured max rados name size. You may get unexpected ENAMETOOLONG errors on rados operations or buggy behavior
2017-10-05 03:54:18.274440 7ffff5151800 -1 journal FileJournal::_open: disabling aio for non-block journal. Use journal_force_aio to force use of aio anyway
2017-10-05 03:54:18.276959 7ffff5151800 -1 filestore(/var/lib/ceph/osd/ceph-6) WARNING: max attr value size (1024) is smaller than osd_max_object_name_len (2048). Your backend filesystem appears to not support attrs large enough to handle the configured max rados name size. You may get unexpected ENAMETOOLONG errors on rados operations or buggy behavior
2017-10-05 03:54:18.279105 7ffff5151800 -1 filestore(/var/lib/ceph/osd/ceph-6) Extended attributes don't appear to work. Got error (95) Operation not supported. If you are using ext3 or ext4, be sure to mount the underlying file system with the 'user_xattr' option.
2017-10-05 03:54:18.279239 7ffff5151800 -1 filestore(/var/lib/ceph/osd/ceph-6) FileStore::mount: error in _detect_fs: (95) Operation not supported
2017-10-05 03:54:18.279274 7ffff5151800 -1 OSD::mkfs: couldn't mount ObjectStore: error -95
2017-10-05 03:54:18.279523 7ffff5151800 -1 ** ERROR: error creating empty object store in /var/lib/ceph/osd/ceph-6: (95) Operation not supported

Можно запустить CEPH monitors.

MacOS uses ntpd no more. Now it’s timed

Скорее всего, выбор в пользу своего сервиса синхронизации часов был сделан при выпуске “Sierra”.  NTPd пока ещё присутствует в системе, но уже отмечен как устаревший:

/System/Library/LaunchDaemons/org.ntp.ntpd-legacy.plist

How many replicas MySQL production needs?

Если у вас production™, который базируется на MySQL, то, очевидно, вам нужны backup’ы. hot standby replica — та, на которую нужно будет переключиться, если произошёл отказ master’а — как минимум, одна: hot standby replica

Во-2-х, нужна replica, на которой можно выполнить mysqldump — чтобы не нагружать этим master. Если делать mysqldump с hot standby, вы получите replication lag, лишившись, таким образом hot standby, поэтому, это должна быть отдельная replica: dump replica

Кроме того, вы можете захотеть снять read-нагрузку с master, переложив её на одну из этих двух. Это однозначно не стоит делать на dump replica, поскольку при dump, там будет точно такой же lag, а неактуальные данные с неё, скорее всего, вам не нужны. Можно ли использовать hot standby replica для этих целей? Этот вариант кажется более логичным, но если read-запросов к ней слишком много, то, скорее всего, и там можно будет наблюдать lag. Поэтому для целей read offload — лучше всего поднять отдельные реплики, никак не связанные с прежними: read replica(s)

Рано или поздно может потребоваться сделать MySQL upgrade. Довольно очевидно, что это должна быть отдельная replica, с актуальными данными, которую вы можете без спешки обновить, протестировать, и использовать как новый master. Эту реплику можно, в пр-цпе, не использовать постоянно, но должен быть способ её быстрого изготовления: upgrade replica

Также, существуют рекомендации (a-la best practices) использовать intentionally delayed replica — когда replica намеренно плетётся за master с заданной задержкой. Суть в том, что если на production был выполнен какой-либо ошибочный update/delete/drop (и так далее), вы можете, не мешкая, метнуться на такую replica, и сделать replay, исключая ошибочные действия, которые были выполнены на master. Это позволит восстановить штатную работу системы с меньшим downtime: intentionally delayed replica

Итого:

  1. hot standby replica(s)
  2. dump replica
  3. read replica(s)
  4. upgrade replica
  5. intentionally delayed replica(s)

Очевидно, что такой набор slaves может ощутимо тормозить master, поэтому потребуются механизмы оптимизации процесса репликации.