.profile issue

[raymond cavanaugh_2]

We are having a problem with, I assume our .profile. This started at the end of the work day, and I've checked the .profiles of some of our other directories, but am unable to resolve the problem. We've checked the permissions and ownership and nothing seems out of sync. Also, when back to a backup tape and recovered a known good .profile, but that didn't work either. Next rebooted the server and logged back on, but still unsuccessful. We've checked the other set .profiles and .chrsc(s), but can not find any issues which would cause the problems. Any suggestions to this problem?

[Geoff Wild]

Depends - what is the problem?

Check shell in /etc/passwd....

Check /etc/profile....

Rgds...Geoff

[raymond cavanaugh_2]

Check the permissions, or the ownership of the passwd and profile? There does not seem to be anything out of the norm there. also when I do a su - to a specific user, rather than it going to the /home directory of the specified user I will be prompted to be the user, but will place me in the directory where I last was at before I did the su - . We have a form menu set up for these users and it (the unix box) is not directing them to that form. There is a path in there .profile which directs them to the form menu, and in this case it is not.

[Bill Hassell]

It sounds like your profiles are not being run at all. Let's start with the shell. Is it the standard POSIX shell (/usr/bin/sh)? Does /etc/profile get executed (hint: add an echo at the front of /etc/profile)? If none of your profiles are being run, something fairly serious has occurred. A possibility is that root has changed top level directories (never a good idea). Make sure that / /opt /usr /var /home are all 755 (drwxr-xr-x). Somebody may be trying to improve security with all the details.

[raymond cavanaugh_2]

Well, I was going to tell you it didn't work, but now it does! I guess the system has to take. But I do still get a minor error saying (su/var/tmp/sh2950.13: Cannot create the specified file.)
In the /var/tmp directory the sh**** files are set at 6 and I changed the ownership to oracle:dba.

Also with this point system how do I award the points? I tried it once before, but was unsuccessful.

[Bill Hassell]

You wrote:

"But I do still get a minor error saying (su/var/tmp/sh2950.13: Cannot create the specified file.) In the /var/tmp directory the sh**** files are set at 6 and I changed the ownership to oracle:dba.

First, the path: su/var/tmp/sh2950.13 means that in whatever directory you are now located, the su directory as well as the subdirectories var and tmp must exist before the file can be created. I doubt that this is what was intended. If the "su" was a typo and the directory is /var/tmp, then the permissions on /var/tmp are 777 (or 1777) and owner is bin:bin.

Now the files can be 666 although that is bad sysadmin practice, they should be 644 or even 600. Look at the contents of the sh* files--they are probably temp files that can be removed.

[Geoff Wild]

As Bill says, you need the sticky bit set on /var/tmp

chmod +t /var/tmp

As far as points go:

How Do I Assign Points?
Only the question author can assign points to a given response. If you submit a question or new topic and another member replies to it, you will see a dropdown menu of points next to the reply (you must be logged in to see the menu). Select the point value and then click the "submit points" button. Note that you can rate multiple replies and submit them at one time.


Rgds...Geoff

[raymond cavanaugh_2]

Ok, I've done all of this and still the same problem. I've also spoken by phone to another SA who is now a DBA, and after talking with her, we think it has to do with the environment within the .profile . We have a general directory where most of the users log in and use the same .profile, to process in applications written for them. I went to my backups again to retrieve an older .profile before this started and tried to login or su - username to see if it would work. I can get the menu, but not into the applications listed within the menu. I did a vipw to check the passwd file, but could see nothing wrong as of yet.
The other suggestions you've both gave has helped me to allow other users onto the system, but not these users. Any more suggestions?

[Bill Hassell]

You need to verify the correct environment and store it into a file. Hint:

set > /tmp/user1-localenv
env > /tmp/user-2myglobalenv

Then login to a working user's account and do the same thing. Now compare the two files:

diff /tmp/user1-localenv /tmp/user2-localenv
diff /tmp/user1-globalenv /tmp/user2-globalenv

Now this all assumes a *NORMAL* login using telnet and /usr/bin/sh as the shell. Since you said that users are sharing the same $HOME directory (is that correct?), this can be extremely problematic (anyone of them can mess around with local files and directories). Shared $HOME is not a stable way to control environments, in fact it has the opposite effect.

If the users are not Unix-savvy, don't give them any command shell at all. Instead, write a clean shell script menu so they never get a shell prompt. This script becomes the user's shell in /etc/passwd and each user has their own $HOME with a simple .profile (the menu program takes care of all the required settings).

You might have to explain a bit more on how the users actually login (what is their shell and what is run automatically?).

[raymond cavanaugh_2]

Our users actually have their own /home directories, it's a copy of the general user directory. I had another SA come down to help setup a menu screen added into the .profile of these users to prevent what you're saying, knowing it would happen. They login and get a screen form allowing them six selections 1-5 and a z to exit. I can log into the screen, and exit from the screen, but it will not allow them into the application menus. Also, we are running oracle 6i forms and they can not get into the forms60 the system says can not find. The forms60 is out there, but it wouldn't or cann't see it.
We've had problems with the unix server in the past, due to the network switching to Active Directory, or the network people running scans on the network, or using SMS to different systems.

[RAC_1]

pwck
grpck
logins -d
logins

Still confused about what exactly is your problem.

Anil

[raymond cavanaugh_2]

Ok, the problem is for some reason our common users can not get into their applications. They can now get into the screen menu, but can not do anything other that get to the screen menu, other than exit from the screen. Don't get me wrong, between you two responders, I've been able to allow some of the other less common users onto the system again so they can process there data, but for some reason the menu works but will not allow them to access there applications. The menu does a loop and if I try to access the application without the menu? I get a (jssadp: /var/tmp/sh****.##) error. The jssadp being the application error. This particular application resides in the /user directory the users are attempting to access and not the /home directory.

[RAC_1]

Correct perms on apps?? Correct menu script??

Run the menu script through set -vx and check if it executes ok or not.

[raymond cavanaugh_2]

I tried to run the script as a local user, in this case it's called /comp. went into where the screen menu resides and tried that first. Same result as before, then went into where the app menu resides and just tried to execute the menu app. with the same result and giving me an error from /var/tmp.

[Geoff Wild]

If you su to the user - can you run the menu manually? can you launch the apps manually?

Can you post the menu?

Rgds...Geoff

[raymond cavanaugh_2]

Actually I called a couple of the programmers for the applications in question, and they said it has to do with the PATH of the .profile . It is missing something there. I can execute the applications as a local user, and one of the applications will execute but not the other applications. The menu does not want to play with the other applications nicely.

[RAC_1]

As a user with which you want to access the apps, logon. (no menu business)

type apps1
type apps2

Does it resolve?? Does menu script sets the PATH?? If yes, Change to
PATH=$PATH:/something/xx:/cc/vv

[Geoff Wild]

Sounds like you need to set the PATH environment for each menu option...

Rgds...Geoff

[raymond cavanaugh_2]

OK, my system is back up and fully operational. The final poriton which was preventing the users from accessing the system, was I needed to go into the various log files and change the chmod from 755 to 775 to allow the apps to write to the log files. Once I did this the user logins could work.

Thanks for all of the help. This makes me feel more confiednt in using the HP forums as solid viable resources.

Thanks,

[Bill Hassell]

It sounds like no one really knows what is required to get the menu and apps working correctly. If the programmers/DBAs think PATH is wrong, what exactly is wrong? In 'normal' logins, the file /etc/PATH has the default PATH value. Users can then modify their local .profile to add, change or replace the PATH variable. Normal .profile maintenance would use something like:

export PATH=$PATH:/some/new/path/or/2

You're going to have to trace the menu operations because the visible errors aren't giving you any clues. Login to a user that works OK but don't run the menu. If the menu is run automatically, put the word: echo in front of it. Once in the shell, run the menu program like this:

sh -x /comp 2>/tmp/menu.log

Now the menu will run but a trace of each step will be put into the menu.log file. NOTE: /comp is a bad place for any executables or scripts. Once you get the trace output, you can see where it fails UNLESS the script has a number of functions (sh -x only traces the main program) or the script calls other scripts. You can put set -x into each of the menu functions and subscripts.


The error message: jssadp: /var/tmp/sh****.## likely indicates that the jssadp script needs some tracing. If there are any sh****.## files in /var/tmp, look at the contents and see if you can correlate them to something in the jssadp script.