Oracle on raw devices in SLES9

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 ?

-- Shashi



-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

>>> On 6/1/2007 at 9:07 AM, Shashi Kanth Boddula
<shashi-kanth.boddulahp.com>
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 ?

Put user oracle to disk group (disk:6:or
acle). This works well and used by package orarun.

-Arun 




--
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

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: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

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" <kevin.x.lyonsoracle.com>
To: "Shashi Kanth Boddula"
<shashi-kanth.boddulahp.com>
Cc: <suse-oraclesuse.com>; <suse-sles-esuse.com>
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: suse-oracle-unsubscribesuse.com
> For additional commands, email: suse-oracle-helpsuse.com
> Please see http://www.suse.com/oracl
e/ before posting
>
>


-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

Btw, Arun, it do not work for CRS with CSSFile - by some
reason some of CRS
daemons change owner to oracle without setting groups
properly. I use
rawnames script which set up owner on case by case basis
(just with 'sleep
5' delay so that it works after udev).


But it do work for the rest of the system including CSS and
ASM.

----- Original Message ----- 
From: "Arun Singh" <Arun.Singhnovell.com>
To: <suse-oraclesuse.com>; <suse-sles-esuse.com>
Sent: Friday, June 01, 2007 9:31 AM
Subject: Re: [suse-oracle] Oracle on raw devices in SLES9


>>> On 6/1/2007 at 9:07 AM, Shashi Kanth Boddula
<shashi-kanth.boddulahp.com>
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 ?

Put user oracle to disk group (disk:6:or
acle). This works well and used by
package orarun.

-Arun




-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting



-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

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://k
base.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" <kevin.x.lyonsoracle.com>
> To: "Shashi Kanth Boddula"
<shashi-kanth.boddulahp.com>
> Cc: <suse-oraclesuse.com>;
<suse-sles-esuse.com>
> 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: suse-oracle-unsubscribesuse.com
>> For additional commands, email:
suse-oracle-helpsuse.com
>> Please see http://www.suse.com/oracl
e/ before posting
>>
>>
>>     
>
>   


-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

First off, I would never listen to anything REDHAT has to
say about
anything...seriously...maybe just my personal opinion, but
it comes
from a lot of experience between the two big commercial
players out
there...ok..with that said, I have multiple Sles9 Sp3, 10g
clusters
running at the moment.  Some 2 node clusters,  all the way
up to
multiple 18 node clusters in production.  They all utilize
shared
fiber storage, and raw devices with ASM.  I use the
device-mapper for
my persistent binding, and udev for the persistent
permissions.  I've
created a multipath.conf file aliasing my devices to the UID
of each
of the multipath'd luns.  Here's an entry for an individual
lun:

multipath {
                wwid                   
1HITACHI_R450A82C09A5
                alias                     ora_registry1
                path_grouping_policy    multibus
                path_checker            readsector0
                path_selector           "round-robin
0"
                failback                60
}

and then make entries in my /etc/raw file like so:

##
# First 5 devices for Oracle services
##
raw1:mapper/ora_voting1p1
raw2:mapper/ora_voting2p1
raw3:mapper/ora_voting3p1
raw4:mapper/ora_registry1p1
raw5:mapper/ora_registry2p1


The p1 obviously is the partition for the device of the
alias created.
 I simply lay out a partition on each of the luns before I
pull them
into the device-mapper for consistency, and that way anyone
else in my
team can easily see what devices are free on the system in
question if
there is no partition on said device when they're looking. 
From the
/etc/raw file, I just have my entries for permissions in
/etc/udev/udev.permissions and away we go.  I've had our
larger
clusters running in this fashion for well over a year now. 
If you
have any more questions on anything more specific, or If
I've confused
you even more, just let me know and I can get into more
detail.


Hope this helps,
Mike





On 6/2/07, Shashi Kanth Boddula <shashi-kanth.boddulahp.com> wrote:
> 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://k
base.redhat.com/faq/FAQ_85_8082.shtm
>
> (KERNEL="sd*", BUS="scsi",
PROGRAM="/sbin/scsi_id", RESULT="UUID",
> NAME="devicenam
>
> 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"
<kevin.x.lyonsoracle.com>
> > To: "Shashi Kanth Boddula"
<shashi-kanth.boddulahp.com>
> > Cc: <suse-oraclesuse.com>;
<suse-sles-esuse.com>
> > 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:
suse-oracle-unsubscribesuse.com
> >> For additional commands, email:
suse-oracle-helpsuse.com
> >> Please see http://www.suse.com/oracl
e/ before posting
> >>
> >>
> >>
> >
> >
>
>
> --
> To unsubscribe, email: suse-oracle-unsubscribesuse.com
> For additional commands, email: suse-oracle-helpsuse.com
> Please see http://www.suse.com/oracl
e/ before posting
>
>

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

Michael, Thanks for your reply.

Your given solution worked for me. Thank you once again.

I always thought that i need to touch multipath only when if
i have 
multiple paths to a LUN. But in my case , i don't have
multiple paths, 
so i thought multipath is not the way to go. But, today i
learned that 
it can also used for persistent binding.

But, still i have one more problem with SAN attached disks.

I am creating oracle database on raw in two ways

(1) LVM on a LUN
(2) Physical partitions on a LUN.

i am successful at (2) but not (1)

In (2), i have partitioned the LUN into several partitions ,
and added 
that LUN into multipath.conf, and added all those
/dev/mapper/*  
partitions to my /etc/raw , and installed oracle database,
and it 
worked, it installed successfully.

Now , In (1) , Created several LVs on a LUN, added that LUN
to 
multupath.conf, configured lvm.conf to bring LVM under the
control of 
multipath, and added all /dev/mapper/LV* in /etc/raw , and
tried to 
installed oracle database, but it failed. In the
"dbca", "step 10 of 
11", "storage section" , it throws an error
saying that "Raw device 
validation check for data file /dev/raw/raw1" failed,
file /dev/raw/raw1 
is not a raw device . "Device or resource busy" .

Here, anyone, please tell me, RAW-Linux LVM-Multipath  is
actually 
supported?

Any help here ?

But, i can tell one thing, in (1) , without multipath , and
by giving 
all /dev/volume_group/LV* to /etc/raw , it works , and  it
worked for me.

-- Shashi



Michael Kershaw wrote:
> First off, I would never listen to anything REDHAT has
to say about
> anything...seriously...maybe just my personal opinion,
but it comes
> from a lot of experience between the two big commercial
players out
> there...ok..with that said, I have multiple Sles9 Sp3,
10g clusters
> running at the moment.  Some 2 node clusters,  all the
way up to
> multiple 18 node clusters in production.  They all
utilize shared
> fiber storage, and raw devices with ASM.  I use the
device-mapper for
> my persistent binding, and udev for the persistent
permissions.  I've
> created a multipath.conf file aliasing my devices to
the UID of each
> of the multipath'd luns.  Here's an entry for an
individual lun:
>
> multipath {
>                wwid                   
1HITACHI_R450A82C09A5
>                alias                     ora_registry1
>                path_grouping_policy    multibus
>                path_checker            readsector0
>                path_selector          
"round-robin 0"
>                failback                60
> }
>
> and then make entries in my /etc/raw file like so:
>
> ##
> # First 5 devices for Oracle services
> ##
> raw1:mapper/ora_voting1p1
> raw2:mapper/ora_voting2p1
> raw3:mapper/ora_voting3p1
> raw4:mapper/ora_registry1p1
> raw5:mapper/ora_registry2p1
>
>
> The p1 obviously is the partition for the device of the
alias created.
> I simply lay out a partition on each of the luns before
I pull them
> into the device-mapper for consistency, and that way
anyone else in my
> team can easily see what devices are free on the system
in question if
> there is no partition on said device when they're
looking.  From the
> /etc/raw file, I just have my entries for permissions
in
> /etc/udev/udev.permissions and away we go.  I've had
our larger
> clusters running in this fashion for well over a year
now.  If you
> have any more questions on anything more specific, or
If I've confused
> you even more, just let me know and I can get into more
detail.
>
>
> Hope this helps,
> Mike
>
>
>
>
>
> On 6/2/07, Shashi Kanth Boddula
<shashi-kanth.boddulahp.com> wrote:
>> 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://k
base.redhat.com/faq/FAQ_85_8082.shtm
>>
>> (KERNEL="sd*", BUS="scsi",
PROGRAM="/sbin/scsi_id", RESULT="UUID",
>> NAME="devicenam
>>
>> 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"
<kevin.x.lyonsoracle.com>
>> > To: "Shashi Kanth Boddula"
<shashi-kanth.boddulahp.com>
>> > Cc: <suse-oraclesuse.com>;
<suse-sles-esuse.com>
>> > 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:
suse-oracle-unsubscribesuse.com
>> >> For additional commands, email:
suse-oracle-helpsuse.com
>> >> Please see http://www.suse.com/oracl
e/ before posting
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> -- 
>> To unsubscribe, email: suse-oracle-unsubscribesuse.com
>> For additional commands, email:
suse-oracle-helpsuse.com
>> Please see http://www.suse.com/oracl
e/ before posting
>>
>>


-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting