Re: Oracle on raw devices in SLES9

Ok , the problem "persistence ownership" on raw volumes is over by using 
udev, now i am facing a one more problem in SLES9 SP3, and the problem 
is with SAN disks (raw disks) (persistent binding).

I am trying to solve the problem by using same udev concept, as i found 
that we need add line in the udev rules file, and redhat documentation 
said that we need add a line in /etc/udev/rules.d/20-names.rules file.

http://kbase.redhat.com/faq/FAQ_85_8082.shtm

(KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="UUID", 
NAME="devicename")

As SLES9 ships a single udev rules file, i have added the above line in 
/etc/udev/udev.rules in SLES9.


KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", 
RESULT="3600508b4001007d000017000044a0000", NAME="disk/fc/fc_lun0"

For each LUN, i have added a line like above.

Now in the YaST, when i run (#yast2 disk) , in the YaST GUI, i am seeing 
all my assigned names.

/dev/disk/fc/fc_lun0

/dev/disk/fc/fc_lun2

/dev/disk/fc/fc_lun3

so on..................


But in any LUN, if i try to create a partition, YaST doesn't through any 
error, but actually the partition will not be created.

when you run YaST next time, that partitions own't be there .

Any one has any solution for this?

How others are doing ?


Thanks



Alexei_Roudnev wrote:
> If you use standard SuSe orarun, then oracle get a secondary group 'disk'
> and have read/write access to the raw devices by default. It works for
> everything except CSSFile on CRS (RAC cluster).
>
> Other method is, yes, to modify udev permissions.
>
> But I use modified rawnames script which
> - creates symlinks for raw devices so that oracle dont work with 'raw' names
> but works with names such as 'DISK1', 'LOG2' and so on;
> - it uses 'sleep 5; chown' so it set up owner after udev finish t's work.
>
>
>
> ----- Original Message ----- 
> From: "Kevin Lyons" <[email protected]>
> To: "Shashi Kanth Boddula" <[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Friday, June 01, 2007 9:36 AM
> Subject: Re: [suse-oracle] Oracle on raw devices in SLES9
>
>
>   
>> On Fri, 2007-06-01 at 21:37 +0530, Shashi Kanth Boddula wrote:
>>     
>>> Hi All,
>>>
>>> I am installing Oracle 10gR2 on SLES9 SP3 raw volumes which is made by
>>> Linux LVM. As per the oracle documentation, all the raw devices should
>>> be owned by oracle user, for that we need to change the ownership on all
>>> raw devices  where your installing database to oracle user.
>>>
>>> The problem is , after you create a mapping file in /etc/raw, and when
>>> you start the raw service (#rcraw start), the permission again set back
>>> to root.
>>>
>>> I have tried to solve this problem by modifying /etc/init.d/raw file ,
>>> but still , always , when you start the raw services, the ownership on
>>> raw devices again go back to root.
>>>
>>> Anyone has any solution for this ?
>>>
>>>       
>> Modifying the /etc/init.d/raw script is not the way to go.
>>
>> When the raw devices (or really any devices) are created, the udev
>> subsystem automatically sets the permissions to root:disk:660.
>>
>> On SLES9 edit the /etc/udev/udev.permissions file which has rules for
>> what permissions are given to devices files as they are created.
>>
>> For raw devices, the permissions are set by the following line:
>>
>> raw/raw*:root:disk:660
>>
>> You want to add some rules to set the permissions for the raw devices
>> that you are going to use like so:
>>
>> raw/raw1:oracle:oinstall:644
>> raw/raw2:oracle:oinstall:644
>> raw/raw3:oracle:oinstall:644
>> raw/raw*:root:disk:660
>>
>> Or whatever is appropriate for your setup.  The rules can contain some
>>     
> standard
>   
>> shell expansions like 'raw/raw[1-3]' or similar.  The man page has more
>>     
> details.
>   
>> Note that the file is processed in order, and when a matching rule is
>>     
> found
>   
>> processing stops.  So you need to have the default rule come after your
>>     
> custom
>   
>> rules or it will not work.
>>
>> Thanks,
>> Kevin
>>
>>
>>
>> -- 
>> To unsubscribe, email: [email protected]
>> For additional commands, email: [email protected]
>> Please see http://www.suse.com/oracle/ before posting
>>
>>
>>     
>
>   


-- 
To unsubscribe, email: [email protected]
For additional commands, email: [email protected]
Please see http://www.suse.com/oracle/ before posting