[sles-beta] Issues on Beta4

[Richard Brown]

My advice would be using systemd's mask feature to make it next to impossible for the CUPS service to be started 

http://0pointer.de/blog/projects/three-levels-of-off

http://www.freedesktop.org/software/systemd/man/systemctl.html

Apologies for my brevity, written while boarding a flight

- Richard Brown
QA Engineer, SUSE

On 29 April 2014 17:22:39 CEST, Klaus Gmeinwieser <Klaus.Gmeinwieser at oce.com> wrote:
>Hello Johannes,
>
>thanks for your quick answer. I see I need to go in more detail.
>
>@ALL: this is not intended to annoy the list, but an important question
>to me. If this should be off topic -> please tell me
>
>The coexistence with SLES standard software is not the problem at all.
>As we install a production printing suite on the SLES it is required
>from our side, that any misconfiguration is prevented on best effort
>(what is not installed cannot be started or used accidentally).
>
>Having both software packages installed is just one part of the
>conflict
>(a started cups server will block the TCP/IP ports for our software as
>first problem). As we are shipping to customers worldwide, the
>existence
>of the cups software (especially the server) will conflict with our
>policies not to use the SLES for any other purpose. This is also true
>for the apache server not to be allowed on our installations for use of
>ports 80/443.
>
>We had several severe issues on (so called) "experts" using/trying
>cups/apache in parallel with our software (not going into details).
>This is also an issue of better supportability for our service people.
>
>In my opinion, the best way is not to install any unwanted service or
>to
>be urged to do so. As an example I would point to the rsh/rexec which
>is
>also not installed (I know for security) or the apache server - if I
>want to use it I have to install it. I cannot see the difference
>between
>a print server being a fixed part of the SLES and any other service
>being not? (Anyway I cannot see any requirement for cups server on an
>enterprise machine except a print server)
>
>Please advise what we can do...
>
>Thanks in advance & Rgds
>Klaus
>
>Am 29.04.2014 16:04, schrieb Johannes Meixner:
>>
>> Hello Klaus,
>>
>> the issue may become off-topic on this mailing list.
>> Personally I don't mind but perhaps other do?
>> If you like we can continue via personal mail.
>> On the other hand, the issue could be of general interest
>> because it could be an example how other software could
>> coexist with SLE12 standard software.
>>
>> On Apr 29 12:38 Klaus Gmeinwieser wrote (excerpt):
>>> our product is a complete printing solution supporting from input
>>> modules to driving multiple printers. For compatibility to older
>>> versions, we also have e.g. lpr, ipp modules.
>>> With SLE10 and SLE11 only cups-client and cups-libs was
>>> installed/required and this was fine with us....
>>
>> I still cannot imagine what real conflict there could be
>> between your software and CUPS.
>>
>> Currently I could only imagine file conflicts.
>> I.e. when your software provides same files as CUPS.
>> In particular when your software provides binaries like
>> /usr/bin/lp that are also provided by the cups-client RPM.
>>
>> But as you wrote an installed cups-client RPM did not cause
>> a conflict with your software, I do not understand what in
>> the cups RPM causes a real conflict with your software.
>>
>> For example - as far as I see - the cupsd in the cups RPM
>> does not cause a real conflict with any other IPP server
>> when that other IPP server is not installed as /usr/sbin/cupsd.
>>
>> Of course a running cupsd conflicts with with any other running
>> IPP server (i.e. any other listener on port 631) but that is
>> not a conflict with the /usr/sbin/cupsd file in the cups RPM.
>>
>>  From my current point of view I have the gut feeling that what
>> looks like a hard conflict between your software and CUPS
>> is perhaps basically "false alarm" and actually your software
>> could coexist with an installed CUPS regardless whether or not
>> having CUPS installed without running cupsd makes much sense.
>>
>> As far as I currently see: If your software and CUPS do not have
>> same files, your software could be "just installed" on a standard
>> SLE12 system.
>>
>>
>> Kind Regards
>> Johannes Meixner
>
>--
>Klaus Gmeinwieser
>T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
>E klaus.gmeinwieser at oce.com W www.oce.com
>
>Océ Printing Systems GmbH & Co. KG • A Canon Group Company
>P.O. Box 1260 • 85581 Poing
>Siemensallee 2 • 85586 Poing • Germany
>
>Océ enables its customers to manage their documents efficiently and
>effectively by offering
>innovative print and document management products and services for
>professional
>environments.
>
>Océ Printing Systems GmbH & Co. KG
>The company is a limited partnership with its registered office in
>Poing
>– Trade Register HRA 100955 (Amtsgericht München) – WEEE-Reg.-No. DE
>888
>05 443
>
>General Partner: Océ Printing Systems Geschäftsführungsgesellschaft mbH
>Registered Office: Poing – Trade Register HRB 206480 (Amtsgericht
>München)
>Executive Officer: André Mittelsteiner, Hans Manzer
>This message and attachment(s) are intended solely for use by the
>addressee and may contain information that is privileged, confidential
>or otherwise exempt from disclosure under applicable law. If you are
>not the intended recipient or agent thereof responsible for delivering
>this message to the intended recipient, you are hereby notified that
>any dissemination, distribution or copying of this communication is
>strictly prohibited. If you have received this communication in error,
>please notify the sender immediately by telephone and with a 'reply'
>message. Thank you for your co-operation.
>_______________________________________________
>sles-beta mailing list
>sles-beta at lists.suse.com
>http://lists.suse.com/mailman/listinfo/sles-beta

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140429/e4dc3aba/attachment.htm>