From oracle-l-bounce@freelists.org Mon Oct 24 13:51:56 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j9OIpu5U031462 for ; Mon, 24 Oct 2005 13:51:56 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j9OIpVvX031284 for ; Mon, 24 Oct 2005 13:51:31 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8A13A20CDA3; Mon, 24 Oct 2005 13:51:28 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16861-08; Mon, 24 Oct 2005 13:51:28 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0F58B20CD81; Mon, 24 Oct 2005 13:51:28 -0500 (EST) Message-ID: <435D2CBB.1090107@gmail.com> Date: Mon, 24 Oct 2005 13:49:31 -0500 From: Rodd Holman User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: oracle-l@freelists.org Subject: Re: PCI compliance and shared Linux accounts References: <006c01c5d8cb$04ab67f0$3800040a@itasoftware.com> In-Reply-To: <006c01c5d8cb$04ab67f0$3800040a@itasoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 27472 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Rodd.Holman@gmail.com Precedence: normal Reply-To: Rodd.Holman@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Henry, You don't need a direct connect as Oracle. Just ssh -X and it will tunnel the X stuff back to your display. Just export the display back. If you need to do it as a sudo rather than su - oracle, write a wrapper shell for runInstaller.sh that exports the display to your display and then run it. Rodd Henry Poras wrote: > I am wondering how other companies deal with this issue. We are > currently enmeshed in the PCI (payment card industry) compliance > process. One of the requirements is "do not permit group, shared, or > generic accounts/passwords." This means that when we need to access > the database server, we will connect as ourselves, and then sudo to > the 'oracle' account. For a single node database (non-RAC) this > doesn't seem like a big deal. The only limitation is the necessity of > a direct connect for X-windows implementation. If we want to avoid a > silent install we will need a direct login as 'oracle', but OUI isn't > used too frequently. > > I was wondering more about the problems we will have with RAC. An > 'oracle' password will again be necessary for X, as well as to > configure scp in the installation process. There are also some other > tasks that will be more difficult. For example, running the monitoring > tool RACDDT (it will destroy your environment as it removes the > bugs???) uses ssh. I guess I could run it from my personal account if > I am careful to set all permissions, but ... > > I guess I am wondering how important having direct access to a shared > 'oracle' account will be in a RAC environment. Are there any > emergencies or administrative tasks that will become noticably more > difficult with this limitation in place? > > Thanks. > > Henry > -- Rodd Holman Enterprise Data Systems Engineer LodgeNet Entertainment Corporation rodd.holman@gmail.com -- http://www.freelists.org/webpage/oracle-l