> Ну, это не очень сложно, на самом деле.

Это не сложно, пять примеров найдет практически кто угодно, если задастся целью. Вы серьезно думаете что в этом месиве гомнокода их не найдется? :)

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

Проблема только в том, что эти траблы были мной обнаружены в процессе практической эксплуатации систем. Я как-то не совсем понимаю как до таких сведений можно дойти только одной теорией, без практики.

> При этом для того чтобы выискивать неустранимые проблемы, рассуждая абстрактно-
> теоретически, достаточно быть школьником 16+. Поэтому абстрактно-теоретические
> рассуждения идут лесом.

Вот это я понимаю: школьная логика во всей красе. Чтобы понять насколько вы облажались в выводах, сообщу что я профессионально занимаюсь вопросами качества софта. ДЕКАДУ. И если бы я рассуждал только абстрактно-теоретически, я склеил бы ласты еще 10 лет назад, с голодухи. Поговорим о том кто и куда идет в разговорах о проблемах работы софта? :)

> Ну, вот это пример, да. С 3proxy и списком его фич я не знаком, ознакомлюсь на досуге.

Хорошая софтина, имхо. Код правда среднего качества (но именно дырок там не густо, автор IIRC интересуется секурити), но в целом - работает и умеет кучу всего при . По сути - в бинарнике на пару сотен кил живет: половина биллинговой системы, построитель цепочек прокси (с лоад-балансингом!!!), навороченная система ACL, несколько видов прокси, с возможностью фильтрации. И все это можно между собой комбинировать по принципу "фантомас в очках на аэроплане". Скажем юзерей идущих на вон тот IP - можно завернуть на отдельный parent проксь. Ну и так далее. Единственное что настраивать все это - надо хорошо разбираться в сетях и кое-что усвоить о внутренней работе программы.

Но за это воздается. Ну вот например: не умеет файрфокс (да и хром кажись) авторизоваться на socks5. Это глупо (прокси без авторизации - заявка на проблемы), но факт. Делаем козью морду, за 2 минуты пишем конфиг 3proxy на 5 строк, с одной стороны он слушает на локалхост, с другой - parent'ом в цепочке из 1 прокси, там же и прописываем авторизацию. Проксем указываем локалхост, а авторизацию сделает 3proxy. ЧСХ при умении пользоваться прогой - 2 минуты времени на войну с "стандартными сетевыми граблями" aka неумением браузеров авторизовываться на сокс5. Но это только 1 из over 9000 сценариев из жизни любителей сетей.

> sed -i 's|/usr/local/?|"${PREFIX}"/|' не спасает?

Как бы это сказать. Вбивать такие костыли я труба шатал, потому что потом окажется что где-то выйдет лажа, чего-то не доглядели, потом придется трублешутить запуск программы. При отсутствующем в sysv логгинге результатов его жизнедеятельности (или к вопросу зачем там встроенный логгер). Я не считаю что это - та административная практика которую я желаю видеть на постоянной основе, вот извините.

ИМХО нормальный человеческий подход - прописать путь 1 раз, как параметры конфигурации, каковым он и является, имхо.

> Вы ведь правили этот скрипт, как я понял, так?

Я его посмотрел... пришел в печаль... и написал конфиг апстарту. На 5 строк. Где не только рестарт, но еще и установка юзера и приоритета. И путь к программе - 1 раз фигурирует, а не 6. С systemd так тоже можно. И он мне нравится тем что в курсе про контейнеры и прочее, а в перспективе и про множественные состояния ситемы.

> А разработчикам свои правки не отправляли?

Я не собираюсь приводить этот скрипт в вменяемое состояние. Reason: конфиг на запуск апстартом (или systemd) написать в 5 раз быстрее.

А скрипт где будут вбиты мои системоспецифичные пути разработчикам тем более не надо. Потому что мой подход к инсталляции кастомных сервисов достаточно далек от того к чему вы привыкли. И ближе всего к "контейнерам". Ну то-есть это как-то так: сервис целиком ставится в свою диру, а после старта как минимум должен (классически) chroot()+setuid()+setgid(), после чего сервис лишается доступа всюду кроме своего загона. А лучше - более эффективный clone(), с отрезкой namespaces (если конфиг позволяет). Так сервис будет жить в отдельной микросистеме-контейнере, где кроме него ничего нет. Так что если сервис вдруг проломили - вокруг крайне печальная "система" где брать нечего.

До Поттера это вроде бы дошло и мне в ближайшем будущем не придется вбивать многие костыли лично, выгрузив это на поттера, чему я рад. До него судя по его взглядам также дошла и "парная" проблема. Иногда под сервис надо формировать "песочницу" с более полной структурой "копии ОС", при том как-то следя за обновленностью софта там. Дело в том, что если сервис может грузить шаред либы по ходу пьесы - после отрезания в контейнер он их, разумеется, по старым путям уже не сможет получить. Т.е. должен быть некий перенос либ в иерархию контейнера в которую мы себя отпилили. По максимуму это может быть всем юзермодом ОС и рулиться как отдельная копия ОС, это начинание известно миру как "VPS". И нехило бы проверять что секурити апдейты и на эти либы распостраняются. Решения этих проблем существуют, но являются или дико монструозными энтерпрайзятинами, или жутко кривыми костылями. А логичнее всего это смотрелось бы наверное как раз в системном менеджере, ему по иерархии и назначению логичнее всего чем-то таким заняться, наверное. А кто еще всем этим должен заведовать?

Т.е. контейнерный стиль мышления мне не только не чужд, но я еще и задолго до Поттера использовал техники администрирования которые он сейчас в systemd имплементит. Да, это довольно далеко от того к чему олдскульщики привыкли.

А если помечтать: раз уж сервис у нас относительно самодостаточный, можно попытаться подвинуть его живьем на соседнюю железку, если текущую железку надо потушить (мало ли, вентилятор начал барахлить или SMART показывает что диск скоро умрет, etc). Нуачо, CRIU в ядре уже есть, остается только грамотно обыграть. Создать на ремоте такую же песочницу и передвинуть туда. В идеале никто ничего и не заметит, даже tcp соединения не порвутся. Поттер с его управлениями множественными состояниями к этому скорее всего придет.

> прекрасно, если бы вы кинули в меня ссылкой на ваш или ещё чей-то блог,

С этим сложно - я не могу вспомнить мест где были бы хорошо описаны фичи 3proxy. Его хоумпага 3proxy.ru - там можно посмотреть некие примеры чего он может. Но я бы не сказал что это хорошо иллюстрирует все возможности.

> кто описывает проблему, критерии выбора 3proxy,

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

> почему /usr/local не устраивает

Тоже см. выше. Мне не надо бардак в этой дире + сетевые сервисы имеющие выход в внешний мир на мой вкус крайне желательно отпиливать в отдельный пустой загон, for security reasons. Старпeры как максимум знают про чрут. Но он малоэффективен, clone() с обрубанием namespaces не в пример эффективнее. И будет очень мило если этот трюк будет делать сам запускач, а не мои кастомные костыли.

> (хотя прокси ставится не из репов и, казалось бы, /usr/local самое подходящее место для установки),

А у меня иное мнение на этот счет. Да, оно может вынести мозг неподготовленному индивиду. Логика такая: это сетевой сервис. Мало ли чего. Дыры случаются везде. Поэтому с точки зрения минимального импакта лучше всего если он будет жить в пустом контейнере где ничего нет.

> детализации. Это было бы самым превосходным ответом, который бы снял все
> мои вопросы и все мои сомнения.

Боюсь, вы будете долго делить на ноль после того как прочитаете о предпочитаемых мной административных практиках, поскольку они довольно далеки от того того к чему привыкли любители классических подходов. Да, я не боюсь "лабиринтов отражений" - я ими наслаждаюсь :P.