Re: Java https сервер на умолчательном порту
В сообщении от [Сб 2018-03-03 23:03 +0300] Victor Wagner пишет: > Если я правильно понимаю, то не вместе с init-скриптом, а вместо него, > что отличается от ситуации когда в пакете сервис-файл есть, и тогда > пользовательские файлы из /etc/systemd читаются вместе с системным > (пакетным) файлом .service и пользовательские настройки по определенному > алгоритму комбинируются с системными. Когда есть инит-скрипт, то вы можете заменить его пользовательским сервис-файлом. Да, то есть «вместо». Но нигде не написано, что нельзя комбинировать инит-скрипт и пользовательский сервис-файл, по аналогии с пакетным сервис-файлом и пользовательским (их тоже можно заменять полностью, а не комбинировать). Хотя я так не делал (всё-таки это разные подсистемы), мне казалось проще заменить инит-скрипт чем комбинировать, но вы можете попробовать и рассказать что получилось. -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Java https сервер на умолчательном порту
В Sat, 3 Mar 2018 23:39:09 +0500 Коротаев Руслан пишет: > В сообщении от [Сб 2018-03-03 19:21 +0300] > Victor Wagner пишет: > > > А вот интересно, если в пакете unit-файла нет, есть только > > init.d-скрипт, но системой инциализации работает systemd, эти файлы > > будут обрабатываться? > > Да, будут обрабатыватся в режиме совместимости, выглядит он также как > юнит, например exim4.service. В таком режиме есть нюансы, о них можно > подробно почитать в этой книге [1] на русском (главы «Преобразование > SysV init-скрипта в systemd service-файл» и «Совместимость с SysV»). > Также много литературы на импортном вот здесь [2]. > > Если коротко, то вместо init-скрипта, например foobar, создаете файл с > таким же именем в /etc/systemd/system/foobar.service и будет > запускаться он, а не init-скрипт. Если я правильно понимаю, то не вместе с init-скриптом, а вместо него, что отличается от ситуации когда в пакете сервис-файл есть, и тогда пользовательские файлы из /etc/systemd читаются вместе с системным (пакетным) файлом .service и пользовательские настройки по определенному алгоритму комбинируются с системными. > > [1]: http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf > [2]: https://www.freedesktop.org/wiki/Software/systemd/ > -- Victor Wagner
Re: Java https сервер на умолчательном порту
В сообщении от [Сб 2018-03-03 19:21 +0300] Victor Wagner пишет: > А вот интересно, если в пакете unit-файла нет, есть только > init.d-скрипт, но системой инциализации работает systemd, эти файлы > будут обрабатываться? Да, будут обрабатыватся в режиме совместимости, выглядит он также как юнит, например exim4.service. В таком режиме есть нюансы, о них можно подробно почитать в этой книге [1] на русском (главы «Преобразование SysV init-скрипта в systemd service-файл» и «Совместимость с SysV»). Также много литературы на импортном вот здесь [2]. Если коротко, то вместо init-скрипта, например foobar, создаете файл с таким же именем в /etc/systemd/system/foobar.service и будет запускаться он, а не init-скрипт. [1]: http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf [2]: https://www.freedesktop.org/wiki/Software/systemd/ -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Java https сервер на умолчательном порту
On 03/03/18 19:21, Victor Wagner wrote: >> Эти строки можно добавить в >> /etc/systemd/system.control/имя-сервиса.service.d/произвольное-имя.conf. >> Эти файлы не трогаются пакетным менеджером и всегда используются при >> старте имя-сервиса.service. > А вот интересно, если в пакете unit-файла нет, есть только > init.d-скрипт, но системой инциализации работает systemd, эти файлы > будут обрабатываться? Эти строки будут обрабатываться, если systemctl status показывает соответствующий сервис. С помощью systemctl cat имя.service можно это проконтролировать.
Re: Java https сервер на умолчательном порту
В Fri, 2 Mar 2018 18:10:13 +0300 Alex Kicelew пишет: > On 03/02/18 18:03, Victor Wagner wrote: > >> Если не возражаете против использования systemd для запуска > >> программы, то добавьте в юнит такую строчку: > > Вот это - однозначно вредный совет. Только сегодня напоролся > > (правда, совсем с другой программой). > > Эти строки можно добавить в > /etc/systemd/system.control/имя-сервиса.service.d/произвольное-имя.conf. > Эти файлы не трогаются пакетным менеджером и всегда используются при > старте имя-сервиса.service. А вот интересно, если в пакете unit-файла нет, есть только init.d-скрипт, но системой инциализации работает systemd, эти файлы будут обрабатываться? -- Victor Wagner
Re: Java https сервер на умолчательном порту
02.03.2018 15:58, Коротаев Руслан пишет: Если не возражаете против использования systemd для запуска программы, то добавьте в юнит такую строчку: [Service] … ExecStartPre=/sbin/setcap cap_net_bind_service=+ep /usr/local/bin/myprog … Если уж использовать systemd, то лучше прописать AmbientCapabilities=CAP_NET_BIND_SERVICE Тогда capability будет работать только для конкретного сервиса. И ещё почитать man 5 systemd.exec.
Re: Java https сервер на умолчательном порту
Victor Wagner -> debian-russian@lists.debian.org @ Fri, 2 Mar 2018 18:03:19 +0300: >> Если не возражаете против использования systemd для запуска программы, >> то добавьте в юнит такую строчку: >> >> [Service] >> … >> ExecStartPre=/sbin/setcap >> cap_net_bind_service=+ep /usr/local/bin/myprog … > Вот это - однозначно вредный совет. Только сегодня напоролся (правда, > совсем с другой программой). > Дело в том, что unit-файл systemd, в отличие от скриптов в /etc/init.d > не рассматривается дебиановской пакетной системой как конфигурационный > файл, пользовательские изменения в котором надо тщательно сохранять при > апгрейде софтины. Поэтому как только из репозитория приедет новая > версия пакета, добавленная вручную в unit строчка ExecStartPre (или > Environment) оттуда испарится. > С другой стороны авторы пакетов jenkins - люди консервативные. > И у них в пакете нет unit-файла, и systemd его запускает через > init.d-шный скрипт. Который вообще-то конфигом считается. > Правда не факт, что в следующей версии пакета у них unit не появится. Витус, systemd, конечно, какашка, но если уж приходится нюхать, то надо читать документацию про дезодоранты :) Надо не редактировать имеющийся unit-файл, как в sysvinit, а добавлять новый. В /etc/systemd, а не в /lib/systemd. Об этом авторы какашки все-таки подумали.
Re: Java https сервер на умолчательном порту
On 03/02/18 18:03, Victor Wagner wrote: >> Если не возражаете против использования systemd для запуска программы, >> то добавьте в юнит такую строчку: > Вот это - однозначно вредный совет. Только сегодня напоролся (правда, > совсем с другой программой). Эти строки можно добавить в /etc/systemd/system.control/имя-сервиса.service.d/произвольное-имя.conf. Эти файлы не трогаются пакетным менеджером и всегда используются при старте имя-сервиса.service.
Re: Java https сервер на умолчательном порту
On Fri, 2 Mar 2018 17:58:56 +0500 Коротаев Руслан wrote: > > Если не возражаете против использования systemd для запуска программы, > то добавьте в юнит такую строчку: > > [Service] > … > ExecStartPre=/sbin/setcap > cap_net_bind_service=+ep /usr/local/bin/myprog … Вот это - однозначно вредный совет. Только сегодня напоролся (правда, совсем с другой программой). Дело в том, что unit-файл systemd, в отличие от скриптов в /etc/init.d не рассматривается дебиановской пакетной системой как конфигурационный файл, пользовательские изменения в котором надо тщательно сохранять при апгрейде софтины. Поэтому как только из репозитория приедет новая версия пакета, добавленная вручную в unit строчка ExecStartPre (или Environment) оттуда испарится. С другой стороны авторы пакетов jenkins - люди консервативные. И у них в пакете нет unit-файла, и systemd его запускает через init.d-шный скрипт. Который вообще-то конфигом считается. Правда не факт, что в следующей версии пакета у них unit не появится.
Re: Java https сервер на умолчательном порту
В сообщении от [Пт 2018-03-02 12:24 +0300] Victor Wagner пишет: > Проблема в том. что хочется чтобы оно слушало на дефолтном порту для > https, т.е. 443. > > Для того, чтобы java-приложению дали прибиндиться к порту < 1024, надо > сделать > > sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/java > > Мне, в принципе не жалко, большой дыры в безопасности мне это не > создаст (тем более что машинка в интранете). Проблема в другом. > Через пару месяцев другой сотрудник, которому либо я забыл рассказать > про setcap, либо я рассказал, да он забыл, сделает на этой машинке > apt-get upgrade, и к нему приедет апгрейд OpenJDK. И при изменении > бинарника capabilities слетят. И jenkins перестанет запускаться. Коллеги в рассылке предлагали использовать прокси-сервер, а вашу программу оставить на непривилегированном порту. Хорошая мысль, там и TLS и различные политики можно прикрутить. А если использовать прокси централизовано, для всех сервисов компании, то про вашу программу никто не забудет при смене администратора (она будет прописана в конфигах). > Вопрос в том, а куда бы наиболее соответствующим политике дистрибутива > способом прописать скрипт, который будет делать этот вызов setcap, > чтобы быть уверенным что в момент запуска jenkins бинарник java будет > иметь требуемые capabilities? Если не возражаете против использования systemd для запуска программы, то добавьте в юнит такую строчку: [Service] … ExecStartPre=/sbin/setcap cap_net_bind_service=+ep /usr/local/bin/myprog … > (кстати из man setcap я не понял что произойдет с capabilities при > простой перезагрузке, без изменения бинарника - сбросятся они или нет? > Вроде у нас persistent state в linux не принят). При перезагрузке не сбросятся, а если заменить бинарник, то да, setcap нужно делать заново (или прописать в юните см. выше). -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Java https сервер на умолчательном порту
Victor Wagner -> debian-russian@lists.debian.org @ Fri, 2 Mar 2018 12:24:15 +0300: > Коллеги, > Вот есть такая проблема: Имеется java-приложение (jenkins) которое > умеет работать веб-сервером, в том числе и по https. > Ставится оно из deb-пакета, предоставляемого производителем приложения > и работает от своего собственного непривилегированного юзера. > В пакете есть файлик в /etc/defaults через который можно много что > настроить, в частности порты на которых слушает web-сервер. > Проблема в том. что хочется чтобы оно слушало на дефолтном порту для > https, т.е. 443. > Для того, чтобы java-приложению дали прибиндиться к порту < 1024, надо > сделать > sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/java > Мне, в принципе не жалко, большой дыры в безопасности мне это не > создаст (тем более что машинка в интранете). Проблема в другом. > Через пару месяцев другой сотрудник, которому либо я забыл рассказать > про setcap, либо я рассказал, да он забыл, сделает на этой машинке > apt-get upgrade, и к нему приедет апгрейд OpenJDK. И при изменении > бинарника capabilities слетят. И jenkins перестанет запускаться. Ну, вообще в жабовебе и скаловебе рекомендованное решение - reverse HTTP proxy. Он же и TLS займется.
Re: Java https сервер на умолчательном порту
Можно оставить Jenkins на непривилигированном порту в localhost, без HTTPS, и nginx на 443 порту поставить в позу прокси-сервера.
Re: Java https сервер на умолчательном порту
Hello Victor, On Fri, 2 Mar 2018 12:24:15 +0300 Victor Wagner wrote: > sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/java > > Мне, в принципе не жалко, большой дыры в безопасности мне это не > создаст (тем более что машинка в интранете). Проблема в другом. > Через пару месяцев другой сотрудник, которому либо я забыл рассказать > про setcap, либо я рассказал, да он забыл, сделает на этой машинке > apt-get upgrade, и к нему приедет апгрейд OpenJDK. И при изменении > бинарника capabilities слетят. И jenkins перестанет запускаться. > > Вопрос в том, а куда бы наиболее соответствующим политике дистрибутива > способом прописать скрипт, который будет делать этот вызов setcap, > чтобы быть уверенным что в момент запуска jenkins бинарник java будет > иметь требуемые capabilities? Видимо нужен механизм вроде dpkg-statoverride. Но вроде не припомню такого. Как вариант сделать Dpkg::Post-Invoke в настройках apt, чтобы вызывать скриптик, проверяющий и устанавливающий. Несколько костыль, но по крайней мере рабочий. > (кстати из man setcap я не понял что произойдет с capabilities при > простой перезагрузке, без изменения бинарника - сбросятся они или нет? > Вроде у нас persistent state в linux не принят). capabilities это же xattr. -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su WWW: http://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Java https сервер на умолчательном порту
Коллеги, Вот есть такая проблема: Имеется java-приложение (jenkins) которое умеет работать веб-сервером, в том числе и по https. Ставится оно из deb-пакета, предоставляемого производителем приложения и работает от своего собственного непривилегированного юзера. В пакете есть файлик в /etc/defaults через который можно много что настроить, в частности порты на которых слушает web-сервер. Проблема в том. что хочется чтобы оно слушало на дефолтном порту для https, т.е. 443. Для того, чтобы java-приложению дали прибиндиться к порту < 1024, надо сделать sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/java Мне, в принципе не жалко, большой дыры в безопасности мне это не создаст (тем более что машинка в интранете). Проблема в другом. Через пару месяцев другой сотрудник, которому либо я забыл рассказать про setcap, либо я рассказал, да он забыл, сделает на этой машинке apt-get upgrade, и к нему приедет апгрейд OpenJDK. И при изменении бинарника capabilities слетят. И jenkins перестанет запускаться. Вопрос в том, а куда бы наиболее соответствующим политике дистрибутива способом прописать скрипт, который будет делать этот вызов setcap, чтобы быть уверенным что в момент запуска jenkins бинарник java будет иметь требуемые capabilities? Понятно, что пересобирать самому пакеты ни jenkins, ни, упаси боже, openJDK, не хочется. (кстати из man setcap я не понял что произойдет с capabilities при простой перезагрузке, без изменения бинарника - сбросятся они или нет? Вроде у нас persistent state в linux не принят). --