Hi,

As a part of Oracle Dbase 10gR2 pre-installation tasks on in SUSE Enterprise Server 10, I’m trying to update oracle’s user shell startup file. Oracle’s procedure for that is here:

http://download-east.oracle.com/docs...102/b28052.pdf

on page 13.

I open the file for editing in vi:

$ vi .profile

and added one line ther as

umask 022

but when I try to save file with command :wq I’m getting a message:

“.profile” E212: can’t open file for writing

when I try to exit vi with command :q the message becomes:

Can't write viminfo file in /home/oracle/.viminfo

while acc to Oracle instructions everything should work OK of course.

Can anyone help me understand what is going on? I’m new to Linux, and I don’t even know the name of the file I’m trying to edit [is it really .profile?], let alone its location.

Sergei

It there an oracle user. It almost looks like they set it up where oracle is a regular user.
Try su'ing as the oracle user, or su'ing to root before editing the file.

thanks for the response. I thought so myself too: maybe *oracle* user does not have the right permissions. So r u suggesting this?:

# su - root
# vi .profile

..then anither Q: how can i be sure that I'm editing the right shell startup file [i.e. the one for *oracle* user]? cana u suggest right commands for this?

appreciating your help on this..

The one in oracle's home directory is the correct one. Read though the section in the "info bash" manual. Search ( /profile ) for profile or bash_login. Bash will run one of three startup scripts depending on which one is present. If you accidentally produced another one such as bash_login or bash_profile, that one may be sourced instead. Of course you could have the one with higher priority source the other one, the same way that ~oracle/.profile may source ~/.bashrc.

Remember that the .profile script is an interactive login script, so before you changes can take effect, you will need to either restart the oracle service or reboot.

---

I'm surprised that oracle is setup as a regular user and not as a system user. That is usually how things like samba, mysql and others work. They even have /bin/false as their default shell in /etc/passwd. This is to prevent someone from logging in as that user.

jschiwal,

thanx a lot for yr time answering this. 80% of what u r talking about still does not make much sense to me due to my [very] limited Unix experience, but anyway i'm getting some very valuable pointers. In the mean time, i was able to work around the problem by running command that Oracle apparently omitted from their guidelines:

chown -R oracle.oinstall /u01

..after that I was able to edit/then save the shell file, and then check *oracle* user environment param(s) by running

# umask
#env | more