[opensuse-factory] xinetd socket services replacement
Hello everyone, I would like to start xinetd obsoletion by systemd socket services. In most cases it should be 1:1 replacement (in some cases we will have to keep xinetd). Quite few packages already migrated or provide both. If checking on my system these packages provide the xinetd services: scarabeus@bugaboo: /etc/xinetd.d $ rpm -qf * |sort -u cvs-1.12.12-183.6.x86_64 net-tools-1.60-769.1.x86_64 procps-3.3.11-4.1.x86_64 rsync-3.1.2-1.2.x86_64 sane-backends-1.0.25-2.2.x86_64 subversion-1.9.4-1.2.x86_64 xinetd-2.3.15-10.3.x86_64 xorg-x11-Xvnc-1.6.0-3.1.x86_64 Should I file bug reports? Or should I just start to do sr#s against the packages, or are there some volunteers to help? Cheers Tom
Hello, On Jun 13 12:57 Tomas Chvatal wrote (excerpt):
I would like to start xinetd obsoletion by systemd socket services. ... sane-backends-1.0.25-2.2.x86_64
If an openSUSE contributor likes to replace /etc/xinetd.d/sane-port by something else then he must also fix yast2-scanner because it writes /etc/xinetd.d/sane-port to set up scanning via network via the SetupNetworkScanningConfig function and via /usr/lib/YaST2/bin/setup_network_scanner_config See also https://bugzilla.opensuse.org/show_bug.cgi?id=859353 Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
By "obsoleting" xinetd I hope you don't mean removal, at least in the near term. As detailed in http://0pointer.de/blog/projects/inetd.html, systemd does not have feature parity with xinetd, in all respects, and certain functionality, such as "only_from" require creating iptables rules, which with SuSEfirewall2 isn't always pretty. Meaning such addition are not are not supported by "yast firewall services" which requires custom scripting to add values to FW_SERVICES_ACCEPT_{EXT,DMZ,INT}. Perhaps systemd.network or firewalld will be extended to more easily achieve this, unless I've missed something, but who know if/when that is coming. I'm not saying this isn't the "better" approach, just that xinetd shouldn't be removed anytime soon and that it has it's place. -- Later, Darin On Mon, Jun 13, 2016 at 6:57 AM, Tomas Chvatal <tchvatal@suse.cz> wrote:
Hello everyone,
I would like to start xinetd obsoletion by systemd socket services.
In most cases it should be 1:1 replacement (in some cases we will have to keep xinetd). Quite few packages already migrated or provide both.
If checking on my system these packages provide the xinetd services: scarabeus@bugaboo: /etc/xinetd.d $ rpm -qf * |sort -u cvs-1.12.12-183.6.x86_64 net-tools-1.60-769.1.x86_64 procps-3.3.11-4.1.x86_64 rsync-3.1.2-1.2.x86_64 sane-backends-1.0.25-2.2.x86_64 subversion-1.9.4-1.2.x86_64 xinetd-2.3.15-10.3.x86_64 xorg-x11-Xvnc-1.6.0-3.1.x86_64
Should I file bug reports? Or should I just start to do sr#s against the packages, or are there some volunteers to help?
Cheers
Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Darin Perusich píše v Po 13. 06. 2016 v 09:51 -0400:
By "obsoleting" xinetd I hope you don't mean removal, at least in the near term. As detailed in http://0pointer.de/blog/projects/inetd.html , systemd does not have feature parity with xinetd, in all respects, and certain functionality, such as "only_from" require creating iptables rules, which with SuSEfirewall2 isn't always pretty. Meaning such addition are not are not supported by "yast firewall services" which requires custom scripting to add values to FW_SERVICES_ACCEPT_{EXT,DMZ,INT}. Perhaps systemd.network or firewalld will be extended to more easily achieve this, unless I've missed something, but who know if/when that is coming.
I'm not saying this isn't the "better" approach, just that xinetd shouldn't be removed anytime soon and that it has it's place.
The plan is to obsolete it on all possible places to reduce its usage only to points hwere it makes sense. As you pointed with the blog. Cheers Tom
participants (3)
-
Darin Perusich -
Johannes Meixner -
Tomas Chvatal