Re: Metalink Fiasco
- From: Andre van Winssen <dreveewee@xxxxxxxxx>
- To: dbvision@xxxxxxxxxxxx
- Date: Thu, 12 Nov 2009 11:11:23 +0100
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@xxxxxxxxxxxx>
> 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@xxxxxxxxxxxx
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
