[Spacewalk-list] FW: What does ULN gives you that standard oracle public yum doesn't

[Paul Robert Marino]

Well that's part of the support thing. they put a delay on the updating to
the public repos.
on a side note since oracle considers spacewalk to be its official package
management tool im willing to bet there is a way to get it to work with ULN
just like how you can get the official red Hat channels to sync to
spacewalk even though its unsupported.

On Thu, Aug 25, 2016 at 3:52 PM, NZ Asparona Technical Support (NZ -
Auckland) <technical.support at asparona.com> wrote:

> Thanks for an interesting response,
>
>
>
> However the question was more technical rather legislative, assuming that
> we have support and have a choice either to use ULN or Yum.
>
>
>
> Found that clarification by Avi:
>
>
>
> https://community.oracle.com/docs/DOC-921379
>
> … Some repository content, such as content for the update-level specific
> patch is available from ULN but not from the Oracle public yum server,
> while other repository content, such as content for the Spacewalk Client
> and Spacewalk Server channels, can be populated from the Oracle public yum
> server but not from ULN…
>
>
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
> bounces at redhat.com] *On Behalf Of *Avi Miller
> *Sent:* Wednesday, February 24, 2016 8:55 AM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] base patch or latest
>
>
>
> … Some more general advice: use ULN only for the base/patch channels (and
> the non-open Oracle channels like Ksplice, when you get access to them).
> The rest of the channels you should sync from yum.oracle.com because it's
> hosted on the Akamai CDN and is much, much faster. The actual content is
> identical and can be validated via GPG signatures…
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
> bounces at redhat.com] *On Behalf Of *prmarino1 at gmail.com
> *Sent:* Thursday, August 25, 2016 6:54 PM
> *To:* NZ Asparona Technical Support (NZ - Auckland);
> spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] FW: What does ULN gives you that standard
> oracle public yum doesn't
>
>
>
> This is not a spacewalk related subject but I will answer it any way.
>
> Indemification‎!
>
> In other words if your business has any SOX or ‎PCI requirements and you
> use oracle linux you need to pay them for support for the required servers.
>
> ‎The reason is that unless you can reasonably prove that you employ
>  developers for every package on all of the boxes that fall under those
>  requirements then you must pay for support. To fully understand the
> reasons for this you need to understand what a lot of purposely vague legal
> phrases actually mean, but in short it means you need proof you pay some
> one to ensure you're operating system is secure and if a new vulnerability
> is doscovered at your company then you can get some one qualified to fix it
> in a resonable amount of time.
>
>
>
> *From: *NZ Asparona Technical Support (NZ - Auckland)
>
> *Sent: *Wednesday, August 24, 2016 23:59
>
> *To: *spacewalk-list at redhat.com
>
> *Reply To: *spacewalk-list at redhat.com
>
> *Subject: *[Spacewalk-list] FW: What does ULN gives you that standard
> oracle public yum doesn't
>
>
>
> Hi guys,
>
>
>
> The question I was trying to answer configuring spacewalk is:
>
>
>
> What does Oracle ULN gives you that standard oracle public yum doesn't?
>
>
>
> Except DTrace and ASMLib which are rarely used in general case scenario,
> what are other ULN advantages before public yum?
>
>
>
> Regards,
>
> Dmitry
>
>
>
> CAUTION: This email message and attachments are confidential to Deloitte
> and may be subject to legal privilege or copyright. If you have received
> this email in error, please advise the sender immediately and destroy the
> message and any attachments. If you are not the intended recipient you are
> notified that any use, distribution, amendment, copying or any action taken
> or omitted to be taken in reliance of this message or attachments is
> strictly prohibited.  If you are an existing client, this email is provided
> in accordance with the latest terms of engagement which we have agreed with
> you.
>
> Email is inherently subject to delay or fault in transmission,
> interception, alteration and computer viruses. While Deloitte does employ
> anti-virus measures, no assurance or guarantee is implied or should be
> construed that this email message or its attachments are free from computer
> viruses. Deloitte assumes no responsibility for any such virus or any
> effects of such a virus on the recipient's systems or data.
>
> Deloitte refers to the New Zealand member firm of Deloitte Touche Tohmatsu
> Limited
>
>
>
>
>
> CAUTION: This email message and attachments are confidential to Deloitte
> and may be subject to legal privilege or copyright. If you have received
> this email in error, please advise the sender immediately and destroy the
> message and any attachments. If you are not the intended recipient you are
> notified that any use, distribution, amendment, copying or any action taken
> or omitted to be taken in reliance of this message or attachments is
> strictly prohibited.  If you are an existing client, this email is provided
> in accordance with the latest terms of engagement which we have agreed with
> you.
>
> Email is inherently subject to delay or fault in transmission,
> interception, alteration and computer viruses. While Deloitte does employ
> anti-virus measures, no assurance or guarantee is implied or should be
> construed that this email message or its attachments are free from computer
> viruses. Deloitte assumes no responsibility for any such virus or any
> effects of such a virus on the recipient's systems or data.
>
> Deloitte refers to the New Zealand member firm of Deloitte Touche Tohmatsu
> Limited
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160826/df71fa3d/attachment.htm>