Zimbra и Ubuntu 16.04

Насколько известно все переходят на SystemD систему инициализации.

В принципе это правильно, но при обновлении Zimbra и Ubuntu 14.04->16.04 столкнулся с тем что старый upstart конфиг от Zimbra нормально не встает.

Пришлось переписать на SystemD сервис.

Проблема выложенного  на github в том, что не стартует сервис logger.

Проблема изза того, что при старте генерится perl класс, который использует внутренние пакеты Zimbra, на которые в переменных нет ссылки.

Решается это подгрузкой переменных среды.

Короче выкладываю рабочий результат. Пользуйте.

[Unit]

Description=Zimbra Collaboration Suite

After=network.target remote-fs.target time-sync.target syslog.target

Conflicts=sendmail.service exim.service postfix.service

[Service]

Type=forking

User=zimbra

Group=zimbra

ExecStart=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol start"

ExecStop=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol stop"

ExecReload=/bin/bash -c ". /opt/zimbra/.bashrc && /opt/zimbra/bin/zmcontrol restart"

TimeoutSec=500

[Install]

WantedBy=multi-user.target

Такие программисты

Не выдержал... Как же меня бомбит от таких постов на нормальном ресурсе Habrahabr.

Начну пожалуй 

1. "Проблема — «непоследовательное» наследование" - это не проблема. Проблема в коде, который просто недостоин существования в 2017 году. Научитесь писать модульно и вы забудете об этом навсегда.

   "При настройках студии "по умолчанию" важен порядок подключения зависимых скриптов" - не умеете готовить не пользуйтесь.

   Если для сборки проекта используете средство интегрируемое, через костыль (а плагин - это костыль), то как бы может быть разобраться как средство работает в своей среде и насколько ему начхать на ваши Solution и Project в терминах Visual Studio.

   Используйте хотя бы paths в tsconfig.json для маппинга проектов.

2. "Проблема — глобальные переменные" - проблема в руках. Никто в 2017 году не использует глобальные переменные. А если ваш проект экспортирует, то это не должно быть проблемой.

3. "Обратите внимание на длинные относительные пути. Они тут нарочно, чтобы показать, что такое случается" - случается, если используешь не модульную систему. И более скажу, использование регистрозависимых путей может привести к веселым последствиям )) особенно когда будешь собирать под другой системой )

4. "Переписать весь наш код на использование импортов за один подход не представляется возможным. " - сколько не оттягивай процесс, все равно вернешься.

5. Интегрирование чего то куда то ради интегрирования это бред.