On Wednesday 12 February 2014 18:04:39 Frederic Crozat wrote:
Le mercredi 12 février 2014 à 17:13 +0100, Johannes Meixner a écrit :
Hello,
On Feb 12 16:30 Sascha Peilicke wrote (excerpt):
On Wednesday 12 February 2014 14:59:02 Johannes Meixner wrote:
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines only talks about "Register services in install scripts"
Assume an older version of package "foobar" that provided both foo.service and bar.service as described in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines is already installed.
Now a newer version of "foobar" does no longer provide bar.service (but foo.service is still provided).
I hope this is not related to cups.socket?
Of course it is.
I need to ensure that cupsd works for SLE12 in the same plain and simple way for printing in a network as it did for SLE11. For enterprise usage I cannot play around with features that are not yet enterprise ready to be used by default out of the box, cf. https://bugzilla.novell.com/show_bug.cgi?id=857372#c66
I don't know if it's better to add comment #110 or just replying here. Just because you have a daemon (cups) listen on 0.0.0.0 for UDP packets doesn't mean "The Internet" (citing comment #66) can attack you. I'd argue that 99% of openSUSE user's machines sit in a local NAT'ed network (behind an adsl router). That's as insecure as OpenSSH running is. And your SuSEFirewall still blocks the port by default. So with pristine settings, you are safe. Letting the service _not_ listen on any interface simply means it can't do it's job. Listening for CUPS printer broadcasts in that case.
Therefore for SLE12 there can be neither cups.socket nor cups.path provided in systemd's unitdir. Instead I provide them as templates in /usr/share/doc/packages/cups/systemd/ so that admins can make their own individual systemd unit files for socket activation and/or path activation as they need it for their particular cases.
SLE12 and openSUSE have identical goals here, there's no need to distinguish. Or do you want to maintain cups' init script for the next 13 years? I'd say go with the system service. Either way, I'm happy to take the minimal burden of maintaining cups. In fact I already prepared the version update (we're ancient ATM).
Or you continue to ship them and change systemd-preset-branding-SLE to not enable cups.path/cups.path. This branding package has been created exactly to handle behaviour difference between SLE and openSUSE..
Exactly. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org