Re: Metalink Fiasco

From: Andre van Winssen <dreveewee_at_gmail.com>
Date: Thu, 12 Nov 2009 11:11:23 +0100
Message-ID: <9b46ac490911120211i442de477iceb990627efb06eb_at_mail.gmail.com>

MOS Benefits: "Improved System Stability" .."Faster Problem Resolution"..errare humanum est

 the output of OCM (Release: 10.3.2.0.0) that it send to oracle is collected in $ORACLE_HOME/ccr/state. I can see four files on my system, 2 per RAC database.
The *stat files contains information about feature usage, high water marks etc. pretty innocent (although I expect a link between "feature usage" and oracle corp's licensing departement, cq sales) I can see vip hostnames being sent because they are spfile parameter values (e.g. *listener) but not any other ip address or mac address. Where did you see that MAC address is being sent to oracle"

I use OCM in connected mode for my 11.2 test system with OCM 10.3.2. I was hoping to be able to log SR more quickly using uploaded system configurations but unfortunately it failed with "Unable to process request for SERVICE_FETCH_CONFIG_CONTEXT_FOR_SR_DETAILS" in previous metalink and I haven't been able to create a new SR in MOS.

Anyway, the OCM help output indicates that you can disable any uploading using the commandline.
$ORACLE_HOME/ccr/bin/emCCR help

Oracle Configuration Manager - Release: 10.3.2.0.0 - Production Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights reserved.

---

Please specify a command.
Usage:

    emCCR start| stop| status
    emCCR set collection_interval="[FREQ=MONTHLY | WEEKLY | DAILY]

                              [; BYMONTHDAY=1 to 31, when FREQ is MONTHLY]
                              [; BYDAY=MON to SUN, when FREQ is WEEKLY]
                              [; BYHOUR=0 to 23]
                              [; BYMINUTE=0 to 59]"
             DAILY is the default Frequency.

    emCCR hold | resume
    emCCR [-annotation="annotation string"] collect | upload | getupdates     emCCR [-verbose] [-register] test
    emCCR register
    emCCR automatic_update on/off
    emCCR enable_target | disable_target     emCCR upload -diagnostic=SR=Service request number,FILE=Absolute path of diagnostic package [-restart] [-force]

    emCCR status -diagnostic[=SR=Service request number,FILE=Absolute path of diagnostic package]

    emCCR clear -diagnostic[=SR=Service request number,FILE=Absolute path of diagnostic package] [-completed] [-force]

    emCCR update_components [-silent] -staged_dir="Directory containing OCM packages" | -distribution="OCM installation kit path"

    emCCR help

Andre
2009/11/12 Nuno Souto <dbvision_at_iinet.net.au>

> Jared Still wrote,on my timestamp of 12/11/2009 3:37 AM:
>
> Lots of anti-OCM sentiment here.
>>
>> I must confess that I like OCM however..
>>
>> OCM is not going to change anything in a database, but it
>> does alert you to possible issues.
>>
>
> Sure. But it's what it does silently that worries me.
>
> For example, did you know that *by default* it does send to Oracle all IP
> addresses *AND* all MAC addresses it can find in the database servers? I
> can understand the IP address, but the MAC address???
>
> If that transmission ever gets intercepted, it's an open door for a hacker
> attack. The arp command is just a start.
>
> I only came about this by accident after spending a lot of time reading and
> following links from an install guide that is long on marketing and short on
> information.
>
> How many other undocumented defaults is it really sending?
>
> Nay, forget that! I want to know *everything* it sends, optional or
> default, period!
>
> These are *my* company's systems, not Oracle's. *I* - or someone else in
> this company - decide what gets sent to an external organization about our
> setup.
>
> First, most basic rule of intrusion avoidance: do *not* send out *any*
> information. An extension of this is precisely why firewalls work in both
> directions!
>
>
> As for the fear of opening servers to the net, expressed in other replies:
>
> that is easily avoided. In the latest release, OCM allows "disconnected"
> mode of operation. Basically, it collects all info into a jar file, then
> *you* upload that jar file to MOS via the "Flash" interface.
>
> You have the power of decision of when info is sent. That is indeed a much
> more intelligent solution and should have been there since day one.
>
> Any guesses as to why MOS was so important to Oracle Support?
> No MOS, no disconnected-mode OCM: simple as that.
> Not a sine-qua-non but I can understand their anxiety in getting MOS going.
>
> However, to me it still needs to pass the first validation: I want to know
> *everything* it can possibly send, default or optional. NO exceptions.
> Until that is clear in my mind and under my control, no go.
>
>
>
> --
> Cheers
> Nuno Souto
> in wet Sydney, Australia
> dbvision_at_iinet.net.au
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Nov 12 2009 - 04:11:23 CST