Re: Java https сервер на умолчательном порту

2018-03-03 Пенетрантность Коротаев Руслан 
В сообщении от [Сб 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 сервер на умолчательном порту

2018-03-03 Пенетрантность Victor Wagner 
В 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 Пенетрантность Коротаев Руслан 
В сообщении от [Сб 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 сервер на умолчательном порту

2018-03-03 Пенетрантность Alex Kicelew 
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 сервер на умолчательном порту

2018-03-03 Пенетрантность Victor Wagner 
В 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 сервер на умолчательном порту

2018-03-02 Пенетрантность Евгений Капун 

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 сервер на умолчательном порту

2018-03-02 Пенетрантность Artem Chuprina 
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 сервер на умолчательном порту

2018-03-02 Пенетрантность Alex Kicelew 
On 03/02/18 18:03, Victor Wagner wrote:
>> Если не возражаете против использования systemd для запуска программы,
>> то добавьте в юнит такую строчку:
> Вот это - однозначно вредный совет. Только сегодня напоролся (правда,
> совсем с другой программой).

Эти строки можно добавить в
/etc/systemd/system.control/имя-сервиса.service.d/произвольное-имя.conf.
Эти файлы не трогаются пакетным менеджером и всегда используются при
старте имя-сервиса.service.

Re: Java https сервер на умолчательном порту

2018-03-02 Пенетрантность Victor Wagner 
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 Пенетрантность Коротаев Руслан 
В сообщении от [Пт 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 сервер на умолчательном порту

2018-03-02 Пенетрантность Artem Chuprina 
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 сервер на умолчательном порту

2018-03-02 Пенетрантность Игорь Чумак 
Можно оставить Jenkins на непривилигированном порту в localhost, без
HTTPS,  и nginx на 443 порту поставить в позу прокси-сервера.

Re: Java https сервер на умолчательном порту

2018-03-02 Пенетрантность Alexander Gerasiov 
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 сервер на умолчательном порту

2018-03-02 Пенетрантность Victor Wagner 
Коллеги,

Вот есть такая проблема: Имеется 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 не принят).

--