[opensuse-packaging] How to start systemd service after package install?
Hello, I have the following gap in my knowledge. I have erlang-epmd package with the following %postin script %service_add_post epmd.service epmd.socket You may check that epmd.socket is enabled in /usr/lib/systemd/system-preset/90-default-openSUSE.preset However, unit epmd.socket is in enabled but inactive state just after the package installation. I am not sure, but I remember that many years ago I already had checked this case and it seems that the socket was enabled and active at that time. What is the recommended way to start the socket unit just after installation? I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 07:24]:
Hello,
I have the following gap in my knowledge. I have erlang-epmd package with the following %postin script
%service_add_post epmd.service epmd.socket
You may check that epmd.socket is enabled in /usr/lib/systemd/system-preset/90-default-openSUSE.preset
However, unit epmd.socket is in enabled but inactive state just after the package installation. I am not sure, but I remember that many years ago I already had checked this case and it seems that the socket was enabled and active at that time.
What is the recommended way to start the socket unit just after installation?
I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.
there really are man pages and examples systemctl start <particular service> systemctl start cups systemctl --help note: probably also need to enable the service so it restart on reboot systemctl enable cups -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Feb 11, Patrick Shanahan wrote:
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 07:24]:
What is the recommended way to start the socket unit just after installation?
I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.
there really are man pages and examples systemctl start <particular service> systemctl start cups
This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
11.02.2019 17:29, Thorsten Kukuk пишет:
On Mon, Feb 11, Patrick Shanahan wrote:
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 07:24]:
What is the recommended way to start the socket unit just after installation?
I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.
there really are man pages and examples systemctl start <particular service> systemctl start cups
This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically.
Yes, this is exactly what I asked. Thank you.
We never do that for security and stability reasons.
That is sad. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
11.02.2019 18:51, Jan Engelhardt пишет:
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-)
I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 10:59]:
11.02.2019 18:51, Jan Engelhardt пишет:
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-)
I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947
you want to bypass security for convenience? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
11.02.2019 20:35, Patrick Shanahan пишет:
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 10:59]:
11.02.2019 18:51, Jan Engelhardt пишет:
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-)
I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947
you want to bypass security for convenience?
I want to find an elegant solution satisfying all constraints. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2019-02-11 16:57, Matwey V. Kornilov wrote:
11.02.2019 18:51, Jan Engelhardt пишет:
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-)
I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947
It's 2019. Why are we still depending on portmappers? The real deal here is that an unprivileged user should, only under specific circumstances be able to cause root processes to come into existence. Else you could cause undesirable resource use - up to a DoS. It looks to me like what erl really should be doing is connect to a *user-local* mapper by default, and only use a *global* mapper if run as root. That global mapper also better have some form of authentication or authorization. Like, how dbus is modeled. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
11.02.2019 20:37, Jan Engelhardt пишет:
On Monday 2019-02-11 16:57, Matwey V. Kornilov wrote:
11.02.2019 18:51, Jan Engelhardt пишет:
On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:
We never do that for security and stability reasons.
That is sad.
What part of it? That Debian does start services and thus fails in the two points? ;-)
I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947
It's 2019. Why are we still depending on portmappers?
The real deal here is that an unprivileged user should, only under specific circumstances be able to cause root processes to come into existence. Else you could cause undesirable resource use - up to a DoS.
It looks to me like what erl really should be doing is connect to a *user-local* mapper by default, and only use a *global* mapper if run as root. That global mapper also better have some form of authentication or authorization. Like, how dbus is modeled.
It does have authorization. This port mapper is common for all erlang nodes running on the same host. You can discover the node (until the node is 'hidden') in epmd, but it doesn't mean that you may connect to this node, you usually need to know the node cookie which is usually randomly generated. The main issue that that erl tries to spawn epmd process every time when it cannot connect to epmd on start (using its own hard-coded tcp/ip port number). And this is an issue because epmd process belongs to arbitrarily systemd cgroup then. Some system service group or user session one. Sooner or later, it will be terminated as a part of the cgroup and all unrelated local erlang nodes will crash. This is why we need separate systemd service for running epmd. We can specify that it is a separate service and can define dependencies between the services. So when you try to start rabbitmq then systemd knows that it should to start epmd first. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2019-02-11 18:55, Matwey V. Kornilov wrote:
It's 2019. Why are we still depending on portmappers?
[epmd] does have authorization. This port mapper is common for all erlang nodes running on the same host. You can discover the node (until the node is 'hidden') in epmd, but it doesn't mean that you may connect to this node, you usually need to know the node cookie which is usually randomly generated.
Even so, you get a list of services, which could be considered an information leak.
The main issue that that erl tries to spawn epmd process every time when it cannot connect to epmd on start
and if it were using a user-local epmd, all would be better methinks: - do not announce own presence to unrelated users - do not spin up a process in another users's context ^ security guys won't be as mad anymore ^ if epmd screws up, it'll be limited to one's own user identity - epmd started in the user systemd session is bound to the session lifetime / cgroup. Outlives the login shell generally. - won't drag other users' erl nodes down when your epmd terminates -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
11.02.2019 21:57, Jan Engelhardt пишет:
On Monday 2019-02-11 18:55, Matwey V. Kornilov wrote:
It's 2019. Why are we still depending on portmappers?
[epmd] does have authorization. This port mapper is common for all erlang nodes running on the same host. You can discover the node (until the node is 'hidden') in epmd, but it doesn't mean that you may connect to this node, you usually need to know the node cookie which is usually randomly generated.
Even so, you get a list of services, which could be considered an information leak.
The main issue that that erl tries to spawn epmd process every time when it cannot connect to epmd on start
and if it were using a user-local epmd, all would be better methinks:
- do not announce own presence to unrelated users
- do not spin up a process in another users's context ^ security guys won't be as mad anymore ^ if epmd screws up, it'll be limited to one's own user identity
- epmd started in the user systemd session is bound to the session lifetime / cgroup. Outlives the login shell generally.
- won't drag other users' erl nodes down when your epmd terminates
This ideas are probably cool, but they are something to be discussed with upstream erlang/otp community. This is not something which could be done during packaging stage. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk schrieb:
On Mon, Feb 11, Patrick Shanahan wrote:
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 07:24]:
What is the recommended way to start the socket unit just after installation?
I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.
there really are man pages and examples systemctl start <particular service> systemctl start cups
This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Unless it's a dbus service. When set up correctly a dbus services will autolaunch just fine right after installation as soon as some program asks for it on the bus. If that is ok I actually don't see a reason to not allow the same for sockets. It's just that AFAIK infrastructure is not in place to do that properly. Clearly explicit "systemctl start" lines in %post woulnd't be the right way. We'd have to extend the presets mechanism so activating sockets happens transparently and package(r)s don't have to worry. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/02/2019 19:20, Ludwig Nussel wrote:
Thorsten Kukuk schrieb:
On Mon, Feb 11, Patrick Shanahan wrote:
* Matwey V. Kornilov <matwey.kornilov@gmail.com> [02-11-19 07:24]:
What is the recommended way to start the socket unit just after installation?
I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.
there really are man pages and examples systemctl start <particular service> systemctl start cups
This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Unless it's a dbus service. When set up correctly a dbus services will autolaunch just fine right after installation as soon as some program asks for it on the bus. If that is ok I actually don't see a reason to not allow the same for sockets. It's just that AFAIK infrastructure is not in place to do that properly. Clearly explicit "systemctl start" lines in %post woulnd't be the right way. We'd have to extend the presets mechanism so activating sockets happens transparently and package(r)s don't have to worry.
cu Ludwig
Once we get to the point of discussing changes like this we probably should be doing it on the factory list because there's a number of people interested in the discussion that are not on this list. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies. The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure. https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_syste... - Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
12.02.2019 12:07, Adam Majer пишет:
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_syste...
epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
- Adam
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:
12.02.2019 12:07, Adam Majer пишет:
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
That is a very valid point. I want to add about the user experience topic that this is mostly related with the user expectations. When openSUSE install a new package that contains a systemd service file is not expected that the service is started. The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will ruin completely the user experience. Is expected that the user can adjust the configuration file before she / he start the service. Even if is enabled by default. IMHO following the openSUSE guidelines about systemd services is helping the user experience. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/12/19 10:32 AM, aplanas@suse.de wrote:
On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:
12.02.2019 12:07, Adam Majer пишет:
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files
epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will
The important keyword here is "sometimes" but how do these apply to enabled services? Can I get logical answers? 1. If something is enabled by default, why is it not started by default? 2. Does reboot automatically makes things better when things are automatically started? 3. If default configuration is wrong or needs customization, why was the service enabled by default? Either the service is enabled and then started or we have it disabled in the first place until the user configures it. Configuration clearly includes enabling the service. - Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday, February 12, 2019 11:16:25 AM CET Adam Majer wrote:
On 2/12/19 10:32 AM, aplanas@suse.de wrote:
The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will The important keyword here is "sometimes" but how do these apply to enabled services? Can I get logical answers?
Uhm I get your points and I think that you are right.
1. If something is enabled by default, why is it not started by default?
2. Does reboot automatically makes things better when things are automatically started?
Surely not. I understand that the same window that we give to the user to update the configuration files, can be used to do a systemctl enable. Is simply less work to the user.
3. If default configuration is wrong or needs customization, why was the service enabled by default?
Either the service is enabled and then started or we have it disabled in the first place until the user configures it. Configuration clearly includes enabling the service.
Sounds sane to me. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2019-02-12 10:32, aplanas@suse.de wrote:
On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:
12.02.2019 12:07, Adam Majer пишет:
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
That is a very valid point.
FWIW, auto-enabling sockets is in essence auto-starting the daemon: as soon as the socket is there, any rogue program trying to connect to it in a busyloop can cause the service unit behind the socket unit to start. sockets are just a way of making the actual daemon have a "delayed startup", but otherwise, their enablement means the actual service is enabled. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt schrieb:
On Tuesday 2019-02-12 10:32, aplanas@suse.de wrote:
On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:
12.02.2019 12:07, Adam Majer пишет:
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
That is a very valid point.
FWIW, auto-enabling sockets is in essence auto-starting the daemon: as soon as the socket is there, any rogue program trying to connect to it in a busyloop can cause the service unit behind the socket unit to start.
sockets are just a way of making the actual daemon have a "delayed startup", but otherwise, their enablement means the actual service is enabled.
In the context of systemd one needs to enable and start a socket unit. Just enabling a socket unit doesn't make systemd actually listen on the actual socket. That is the whole point in this discussion. We use the preset mechanism to enable socket units but then they only get started after reboot. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
12.02.2019 12:32, aplanas@suse.de пишет:
On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:
12.02.2019 12:07, Adam Majer пишет:
On 2/11/19 3:29 PM, Thorsten Kukuk wrote:
And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.
Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.
The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.
That is a very valid point.
I want to add about the user experience topic that this is mostly related with the user expectations. When openSUSE install a new package that contains a systemd service file is not expected that the service is started.
The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will ruin completely the user experience. Is expected that the user can adjust the configuration file before she / he start the service. Even if is enabled by default.
IMHO following the openSUSE guidelines about systemd services is helping the user experience.
Generally, I am agree with you. But I think that the following exceptions are important in this particular case. 1. User may not expect that the package contains some services. epmd.socket is internal erlang thing. 2. epmd.socket is listening on 127.0.0.1 by default. Though currently it leads to constant complaining, this was required by security team at the time when epmd.socket was introduced. It is minimal working local configuration and it should be fine until you really need distribution setup. 3. erlang has its own default hard-coded way to start epmd. It just execs new epmd process every time when it cannot connect to existing one. So, while epmd.socket is not active, any erl command invocation leads to starting new epmd process that listens on 0.0.0.0. Is it more secure? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
1. User may not expect that the package contains some services. epmd.socket is internal erlang thing.
2. epmd.socket is listening on 127.0.0.1 by default. Though currently it leads to constant complaining, this was required by security team at the time when epmd.socket was introduced. It is minimal working local configuration and it should be fine until you really need distribution setup.
3. erlang has its own default hard-coded way to start epmd. It just execs new epmd process every time when it cannot connect to existing one. So, while epmd.socket is not active, any erl command invocation leads to starting new epmd process that listens on 0.0.0.0. Is it more secure?
I agree with Matwey. It is enough to execute and erlang command and the epmd will listen to 0.0.0.0 I think that that this is a bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947 (I opened it) It is not clear the beahaviour for the final user. We had to implement a few workarounds to handle the situation described to https://bugzilla.opensuse.org/show_bug.cgi?id=1124947#c0 We'd like to find a solution instead avoiding workarounds. Thank you -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Dienstag, 12. Februar 2019, 10:32:47 CET schrieb aplanas@suse.de:
The reason is about the configuration file. Sometime the defaults are insecure,
If you know or find an insecure default config, that clearly qualifies as a bug and is worth a bugreport. Our defaults should always be secure or at least "as secure as possible".
useless or simply wrong.
These are not nice, but still somewhat ok. People will notice, and change to a more useful config. Nevertheless, if you know a better default config, it might be worth a bugreport ;-) Regards, Christian Boltz --
the wiki should be stable again. :) What was the reason? The /.-ing or something else? who needs slashdot if you can kill your box with just announcing a new release? [> houghi and Marcus Rueckert in opensuse]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (10)
-
Adam Majer -
aplanas＠suse.de -
Christian Boltz -
Gabriele Santomaggio -
Jan Engelhardt -
Ludwig Nussel -
Matwey V. Kornilov -
Patrick Shanahan -
Simon Lees -
Thorsten Kukuk