Blunker: можно вызвать из программы, можно скачать исходники и посмотреть, как работает.
В любом случае, консольная программа должна работать в любом терминале - и в графическом, и на физической консоли, и на терминале, подключенном через SSH/telnet, и терминале, работающем через COM-порт. Так что добавлять к ней взаимодействие с оконным менеджером я бы не стал. В крайнем случае - сделал бы дополнительный скрипт, который вызывает развёрнутый во весь экран графический терминал с нужной программой.
CityCat4: содежимое писем тоже оказывается на mail.ru, если адресат там держит ящик. Единственный способ иметь безопасную почту - это иметь защищённые системы с обеих сторон, что всё-таки довольно редкий юз-кейс.
канал от провайдера - ну так если он ляжет, пользователи без всякой почты останутся - и если она хостится в ДЦ, и на Яндекс.ПДД, и даже без локальной. В последнем случае будет продолжать ходить почта внутри конкретного филиала организации, но не думаю, что от этого станет сильно легче.
CityCat4:
- рассылка клиентам периодических отчётов (их много, но они по делу) - попадало в спам регулярно. Побороли переходом на AWS SES.
- про spamhaus про деньги была какая-то мутная история, подробностей уже не помню. На уровне слухов, могу быть не прав.
У меня когда-то маленький сервер только для рассылки почты юзерам попал в smaphaus, и по-моему пользователям на outlook.com (могу уже путать, давно было) письма в итоге не приходили. Он точно не был открытым релеем, пистма шли только от нас. Да, без DKIM и SPF, я тогда про них и не знал ещё. А воспользовался бы стохоронним отлаженным сервисом - не потратил бы время и силы на решение вопроса. ИМХО, если почта не является основным сервисом - надо использовать проверенное стороннее решение. Ну, например, DNS можно тоже поднять свои, поддерживать и обеспечивать отказоустойчивость, но зачем? Стороннее решение быстрее, проще и часто надёжнее.
Fetur: я писал в ответе, права на созданные файлы определяет umask процесса, который их создавал. https://ru.wikipedia.org/wiki/Umask. Для пользовательского шела задаётся в /etc/profile, ~/.bashrc и т. д. Для сервиса можно задать в /etc/default/, если он его читает.
Ещё можно воспользоваться POSIX ACL, оно позволяет очень гибко настраивать права доступа к создаваемым в каталоге файлам. https://access.redhat.com/documentation/en-US/Red_... Но они сложнее обычного chmod/chown (разумеется, всё обратно совместимо), и требуют монтировать ФС с опцией acl, по умолчанию она не ставится.
Конфиги - это httpd.conf, всё что в него инклудится и .htaccess для ЧПУ.
"oasis.dev/aktsii" - куда она должна отображаться? Какой-нибудь "oasis.dev/?param=aktsii"?
Вобщем, пока ты не начнёшь давать достаточно информации для диагностики, тебе никто не поможет, потому что вместо "посмотреть - решить проблему" требуется долго и упорно из тебя выпытывать, что там происходит, а это никому не интересно. Ты как будто гос. тайну разгласить боишься.
> случай обыденность и есть набор инструкций по типу проверить то и то, раскоменитьровать это и проблема решится
Ага, а всех админов уволить и заменить на простой скрипт
Где конфиги? Причём все куски конфигов, а не та одна строчка, в который, как ты считаешь, что-то не так. Где описание проблемы, типа какой URL должен срабатывать, но не срабатывает?
NaStyashka: нет. Во-первых, сделать `mount --bind` ему не хватит прав, для этого нужен root. Во-вторых, даже если кто-то сделает `mount --bind`, права внутри папки останутся те же самые.
askeet: сложный вопрос. Пока ведёшь проект один - точно можешь. Если принимал коммиты от других людей - то может потребоваться их согласие. Например, ядро Linux до сих пор под GPLv2 а не GPLv3 в том числе по этой причине.
Можно лицензировать двойной лицензией: OpenSource или проприетарная на выбор. Тогда начиная с любой новой версии проекта лицензию можно поменять, потому что проприетарная такое допускает, и все, кто коммитил в старые версии, соглашались, что проприетарная тоже может применяться. Но старые версии всё равно останутся под той OpenSource лицензией, которая бвла изначально. Там вообще чёрт ногу сломит, для таких вещей специально обученных юристов используют. Лучше сразу ставить правильную лицензию.
ИМХО - GPL/LGPL рулит: нефиг крысить наработки от сообщества, надо вместе дружно пилить софт в светлое будущее :)
Евгений Гаврилов: ну в крайнем случае пишем скрипт sctipr.sh вида "ssh server2 /bin/command1; ssh server2 /bin/command2;" и запускать его средствами капистрано с server1 с пробросом ssh-agent
askeet: есть давний холивар между сторонниками "вирусных" лицензий(aka GPL и производные) и "use-any-way-you-want"(BSD-like). Можно нагуглить много аргументов и кидания экскрементами с обоих сторон. Я делаю так: для мелких кусков кода ставлю WTFPL(BSD-like, причём очень простая и понятная :), для чего-то относительно серьёзного - GPL/LGPL/AGPL, чтобы те, кто используют, дальше делились с сообществом наработками.
Понятно. Покрутил `pv`, не удаётся заставить его писать stderr в stdout, даже с опцией `-f`. Задача всё-таки не очень подходит для баша, проще реализовать на каком-нибудь питоне/перле и не мучаться.
В любом случае, консольная программа должна работать в любом терминале - и в графическом, и на физической консоли, и на терминале, подключенном через SSH/telnet, и терминале, работающем через COM-порт. Так что добавлять к ней взаимодействие с оконным менеджером я бы не стал. В крайнем случае - сделал бы дополнительный скрипт, который вызывает развёрнутый во весь экран графический терминал с нужной программой.