Dmitry

В переменной $? лежит код возврата предыдущей команды. Обычно ноль означает что она завершилась успешно.
Вы же хотите получить данные которые команда вывела в stdout, для этого в bash (и вообще в *sh) есть конструкция $(command).
В вашем случае исправление тривиально:
result=$(exim -bpc)

Запускайте контейнеры с ключом --network host

Эта опция установит host-режим для сети контейнера.

Но это отключит мэппинг портов, опции -p 8080:80 будут игнорироваться. Если контейнер слушает на 80-м порту, это будет именно 80-й порт хоста. Соотв. не получится запустить одновременно несколько одинаковых сервисов в таком режиме.

занести в переменную
register:
и там же (в плейбуке) можете его отредактировать, не перенаправляя в файл
Примерно так

tasks: 
    - name: 'Pwgen Username Password'
      command: pwgen 12 1
      register: userpass

Далее используем переменную {{ userpass }}

Возможно не хватает файла bootstrap для работы
вот хорошая статья по бакуле: www.bog.pp.ru/work/bacula.html#bootstrap

Калькулятор в помощь www.gestioip.net/cgi-bin/subnet_calculator.cgi

Если я запишу диапазон как 2a03:2880::/8 - то я правильно понимаю, что в него попадут все адреса, которые начинаются на 2a03:2880?

Нет, это будет 2a03::/8. правильная будет 2a03:2880::/32

Может у кого-то есть подобный опыт как обеспечить более-менее надежность подобных систем?
Здесь вопрос даже не к raspberry, а вообщем к системам на базе Linux (и не только)

Как раз относится и к расберри. Флешки, какие бы они не были, ненадежны.
1) Для начала городите любое гарантированное питание.
2) На серверах неспроста используется ЕСС память, поэтому даже в случае сферического "хорошо" в вакуме ошибки имеют место быть.
3) Выносите БД на другое хранилище.

Для надежности в целом:
1) Используйте f2fs вместо ext3\4.
2) Переводите корневой \ раздел в режим только чтение
3) БД храните отдельно от системы. Подключенный по usb hdd\ssd. Смонтировать по сети из более нажедного источника.
4) Можно заморочиться с оверлееями. Условно каталог с БД кинуть в оверлей где верхний уровень будет в tmpfs а нижний на флешке. Запускать раз в N часов\сутки слияние из верхнего в нижний уровень.

Как надежное питание можно использовать powerbank или даже обычный бесперебойник. Плюсом последнего будет то что его можно будет подцепить к малине и смотреть сколько заряда, какое состояние и принимать меры если питание перешло на батарею. Т.е. в вашем случае к примеру как по пункту 4 запускать слияние.

crontab -l > foocron
echo "* * * * * rm -rf /home/user/testfolder" >> foocron
crontab foocron
rm foocron

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

у меня кажется получилось добится такой же ошибки.
решилось введением имени юзера через имя_хоста\имя_юзера. имя хоста конечной удаленной машины, на которой нужно выполнить scriptblock. юзер - локальный админ на конечной удаленной машине.

перед этим я, правда, игрался с credssp и везде его повключал (enable-wsmancredssp, в invoke-command добавить ключ -authentication credssp). но после нахождения решения выше, отключил и попробовал еще раз - работает.

кстати, invoke-command, похоже, использует Negotiate как дефолтный метод аутентификации. возможно, непостоянство проблемы вызвано тем, что при "переговорах" от том, как будем аутентифицироваться машины снюхиваются разными методами (почему? понятия не имею, это только теория) или разные машины выбирают разные методы. какие-то с какими-то машинами работают, какие-то нет и вылазит ошибка. возможно, стоит перебрать все значения параметра -authentication в invoke-command, найти тот, который работает каждый раз и его жестко указывать.

Нет, установка Генту делает из вас хорошего копипастера мануалов.
Источник: личный опыт.

Если комментариев к статье неограниченное количество, то хранить данные таким образом - неудачная идея. В mongodb документ по умолчанию не может превышать более 16 mb, но даже при отсутствии подобного ограничения, это привело бы к единовременному считыванию большого объема данных в память. В таком случае данные следует моделировать также, как и в РСУБД.

Есть CAP-теорема и выбирать тип базы данных нужно исходя из того, какие 2 из 3 свойств для вас важнее. РСУБД дают согласованность и доступность (CA), но жертвуют возможностью разделения такой базы, nosql решения идут другим путем и жертвуют согласованностью в пользу доступности и устойчивости к разделению (AP). Согласованность данных в таких системах достигается при помощи шаблона Saga вместо ACID.

В целом NoSQL это про проекты данные которых не помещаются в рамках одного сервера, а не про то, каким образом моделировать эти данные. Вложенные документы в mongodb - это скорее следствие её архитектуры, которое используют как маркетинговый ход, чем решение, которое будет использоваться повсеместно. В подавляющем большинстве случаев документы будут ссылаться друг на друга, точно также как это происходит и в РСУБД.

Для проекта с крохотными объемами данных логичнее выбирать РСУБД и тем самым значительно упростить себе жизнь. Но в целом как используют NoSQL, шардируют данные и как достигают согласованности данных при отсутствии ACID знать желательно, хотя бы в общих чертах.

Самое ужасное, это выбрать базу данных и использовать её неправильно, как пример документа с вложенными комментариями при условии их бесконечности в mongodb. Пишем скрипт генерирующий триллион комментариев к статье, а затем просим нам выдать эту статью и сайт уходит в офф. Хорошо что в mongodb есть защита от дурака.