Емейл, к сожалению, не полностью децентрализованный. В случае использования почты от гугла или яндекса невольно становишься заложником этих компаний. По этому поводу я с большим интересом слежу за https://en.wikipedia.org/wiki/Bitmessage
Каким образом у вас одни метрики идут на локальный statsd, а другие на общий? Это логика вашего приложения и вы используете разные адреса для разных метрик?
Сохранение состояния можно делать при помощи trap. Если каждый шаг сам определяет следующий шаг, то основной цикл сильно упрощается:
trap 'echo STEP=$STEP > state' EXIT;
while true; do
${STEP};
done
Код выше оформлен тегами pre, но что-то они не работают.
Прошу прощения, надо было сформулировать более развернутый вопрос. Могу ли я при помощи systemd организовать мета сервис, который бы при запуске генерировал конфиги для компонент и запускал бы их, перезапускал компоненты в случае их аварийного завершения, при остановке мета сервиса останавливал бы запущенные компоненты и удалял бы сгенерированные конфиги? Я хочу зарегистрировать в systemd только метасервис, работа с компонентами должна происходить автоматически без человеческого вмешательства. Что произойдет, если при запущенном метасервисе машина внезапно уйдет на перезагрузку? При следующем старте компоненты будут запущены даже если метасервис запускается в ручном режиме? Отдельный вопрос: может ли systemd проверять живость сервиса при помощи сетевого запроса?
Я далек от того, чтобы утверждать, что systemd это плохо. Давайте проведем аналогию с автомобилями. Машину выпуска 80-х годов прошлого века можно починить в гараже своими силами. Машину выпуска 2010-го года в гараже починить не реально. Это не хорошо и не плохо, это то, куда пришло автопроизводство исходя из рыночной коньюктуры. Если бы люди покупали только машины, которые можно ремонтировать в гараже, то ситуация была бы другая. Но люди охотно покупают машины, которые можно ремонтировать исключительно методом агрегатной замены и исключительно у дилера. Что касается systemd то тут похожая ситуация с той разницей, что возможность ремонта в гараже для многих критична. systemd достаточно новая штука. Им предполагается заменить ключевые компоненты системы, обкатанные годами. Негативный опыт использования systemd, в том числе моими непосредственными коллегами, уже есть. Мне очень не комфортно использовать в продакшене систему, которую я не могу починить отредактировав пару скпиптов. А в том, что она не будет ломаться, у меня пока что уверенности нет. Вот такая моя личная позиция, которую я ни в коем случае никому не навязываю.
Может чтобы ускорить миграцию на systemd? Про хорошо и годно вопрос не однозначный. Я вот с грустью смотрю на список дистрибутивов без systemd и размышляю куда мигрировать.
В данном случае все было сделано правильно. Все, что вы упомянули выше, было учтено. Тем не менее пришлось выкручиваться и временно посылать почту на некоторые домены со старого айпи. После того, как проблему утрясли с принимающими сторонами исключения из когфигурации убрали и все заработало как надо без дополнительных правок.
Буквально только что наблюдал ситуацию, когда смена исходящего адреса при отправке почты привела к тому, что почта на некоторые адреса (больше всего отличились yahoo и aol) перестала уходить. Пришлось списываться с тамошней поддержкой и просить их внести новый адрес в белый список. Справедливости ради надо отметить, что на другие адреса (например gmail) почта уходила без проблем.
Я бы к этому добавил, что обязательно по результатам каждого серъезного прокола надо не только проводить работу над ошибками внутри команды, но еще и в деталях обсуждать случившееся с вышестоящим начальством, чтобы начальство видело, что дело не пущено на самотек, с проблемами борются. А если руководитель команды из раза в раз заметает мусор под ковер, то это действительно верх некомпетентности и наплевательского отношения и к заказчику, и к команде, и к своей компании. Опытный человек от подобного начальника сам уйдет не дожидаясь бесславного конца всей команды.
Есть ли какая-то возможность поднять домашний smtp сервер, если провайдер блокирует порт 25? Гугление на тему портов 587 и 465 к сожалению не принесло ответа на вопрос…
В конфигурации distributed replicated volume будет ли GlusterFS нормально работать при потере сервера? Насколько безболезненно восстанавливается система при появлении сервера обратно? Как ведет себя GlusterFS в состоянии split brain (когда есть, скажем 2 сервера, клиент видит оба сервера, а вот они друг друга не видят)?
HISTTIMEFORMAT='%t%F %T%t'
echo $PROMPT_COMMAND|grep -q bash_eternal_history || export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND; } history -a; "'echo -e $?\\t$USER\\t$HOSTNAME\\t$PWD\\t"$(history 1)" >> ~/.bash_eternal_history'
Вот пример как работает trap EXIT:
$ cat 054-trap-test.sh
#!/bin/bash
trap 'echo done' EXIT
[ -z "$1" ] && echo no arg && exit
echo arg is $1
$ ./054-trap-test.sh
no arg
done
$ ./054-trap-test.sh 1
arg is 1
done
$
В случае нормального завершения скрипта можно сохранять первый шаг последовательности. Или пустое значение.
trap 'echo STEP=$STEP > state' EXIT; while true; do ${STEP}; done
Код выше оформлен тегами pre, но что-то они не работают.