UNIX for Dummies Questions & Answers

Hi all,

Here is the oracle user shadow line in /etc/shadow
<pre>

<B>oracle:Lic8CakzDxM3o:11529:0:28:24::: <B>

username The user's login name (UID).

password A 13-character encrypted password for the user, a
lock string to indicate that the login is not
accessible, or no string, which shows that there
is no password for the login.

lastchg The number of days between January 1, 1970, and
the date that the password was last modified.

min The minimum number of days required between pass-
word changes.

max The maximum number of days the password is valid.

warn The number of days before password expires that
the user is warned.


So, if the maximum number of days the password is valid is = 28, does that mean that the password has expired?? No-one has changed the password, and I can switch to 'oracle' from 'root' using 'su - oracle' fine.

Also the variables can seen below:

$ whoami
oracle
$ env |grep ORACLE
ORACLE_BASE=/u01/app/oracle
ORACLE_SID=CLFY
ORACLE_DOC=/u01/app/oracle/product/8.1.6/doc
ORACLE_HOME=/u01/app/oracle/product/8.1.6
--------------------------------------------------------------------
$ env |grep oracle
PATH=/usr/local/bin:/usr/bin:/usr/ucb:/etc:/u01/app/oracle/product/8.1.6/bin:/usr/bin:/etc:/usr/ccs/bin:/usr/openwin/bin:/usr/local/bin
ORACLE_BASE=/u01/app/oracle
CLASSPATH=/u01/app/oracle/product/8.1.6/jdbc/lib/class/classes111.zip:
LOGNAME=oracle
ORACLE_DOC=/u01/app/oracle/product/8.1.6/doc
HOME=/home/oracle
LD_LIBRARY_PATH=:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib
ORACLE_HOME=/u01/app/oracle/product/8.1.6
PWD=/home/oracle
----------------------------------------------------------------------------------
$ set |grep ORACLE
ORACLE_BASE=/u01/app/oracle
ORACLE_DOC=/u01/app/oracle/product/8.1.6/doc
ORACLE_HOME=/u01/app/oracle/product/8.1.6
ORACLE_SID=CLFY

Do you think that I still have to set the variables in the script. The script can be seen above in past thread. I believe that it is something to do with the password, what do you think ??

Thanks for your help!

Yeah, it would be to your benefit to add those variables to the top of your script. Remember that if you call sub-scripts, you may need to export the variables.

If you do change the Oracle password, <b>please</b>, for the love of Mel, pick a better password. The last/current one stunk.

I have a safer way that we use at work for editing any crontab.

$ crontab -l > tempcron.root
$ vi tempcron.root
$ crontab tempcron.root

This way you always have a copy of your crontab, in this case for root, and if you make any mistakes editing you are not actually messing up the crontab file itself.

LivinFree,

I don't even know what the password is. As I said I was handed the system and the procedure was always to switch using 'su - oracle'. Anyway, there is no security issue, so no worries about it.
By the way,.is the password still valid or expired?
Also, why should I inlcude the variables to te script if already are set to env when I log in as oracle??

Kelam_Magnus,

If you read the manual about the crontabs, you will find that the ONLY way to EDIT the crontab is by using 'crontab -e'. If you edit the file itself it will NOT recognise the changes. I am using Solaris 7.

Thanks alot

Guest100,

I used to use only "crontab -e" until I found this way of editing the crontab. It is much safer for you and if you make any mistakes it doesn't corrupt your crontab file.

When you look at the options for the manpage for crontab, the first options is "crontab filename".

My only point about saving the crontab out to a file and editing it is 1) so that you will have a copy of it and 2) when you edit this text file that you just saved out, you can execute "crontab filename" to replace the current crontab with the newly edited one. In addition, it prevents you from making a mistake typing while using "crontab -e".

Step 1
Copy out the crontab to a saved file.
$ crontab -l > somefile

Step 2
edit somefile and make changes.
$ vi somefile

Step 3
copy the newly edited file back into place.
$ crontab somefile

This is the safest way to edit the crontab file so that it doesn't get corrupted.

I work for a very large telecom company and this is the company standard for all platforms: SUN, HPUX, and AIX with several different versions on each platform.


In addition, yes you can go to /usr/spool/cron/crontabs and vi the file in question, edit it and save. The file will be recognized by cron because I have done this as well. I have even cut and pasted from a Word document into a telnet session while vi'ing a file in /usr/spool/cron/crontabs file. And there was no corruption of the file when I saved it and ran cron.

Trust me, all of these things work! Can someone else back me up on this? I am not trying to mess you up, only to help you out.

A few comments here. First, cron on Solaris does indeed check to see if a user's password has expired and if so refuses to run cron jobs for that user. And the error message is indeed "bad user". I have never heard of this behavior before, but I have looked this up on Sun's website. Solaris does seem to have a few surprises.

Second, run a cronjob that simply has "env >/tmp/env.out" and you see the need to set environment variables.

Finally, the technique that Kelam_Magus used is valid and a bit safer. "crontab filename" is a valid way to set your crontab.

Guest100, the password is the same as the username...
Try logging in, and you will know very quickly if Oracle can log in.