HP-UX

Hi,

At my new company they use HP-UX on all the servers.
They use Serviceguard to provide different packages, which are treated as if they where seperate systems. Therefore people log into packages instead of Host, and even the home directories live in the package.

Now there are a different packages on different hosts, and a single LDAP server to store passwd data, which includes the home directory for a user.
But all the packages live in a directory tree in /pkg/[pkgname]/,
and hence the home directory is different on each package...

They "solved" the problem by either creating a single user on each package where everyone logs in, or by creating one passwd entry per user and package, to allow specifying the correct home directory on each package, which leads to me having a different name on each package.

Is this really the way the system should work?
What is the main flaw in the above concept?
Is there an easy way to fix it on a production system, i.e. without any deep intrusion?

Suggest you create an account on the HP ITRC (whether or not you have a maintenance contract) and ask your question there. Serviceguard is a HP-specifice package and outside the scope of unix.com.

Hi Michas,

I think this might not be true. MCSG is a HA product. Kinda like you have few servers clustered together to ensure if one goes down, the other remains up. Yes, it has packages but, you do not have operating systems in packages. We have applications on packages. So, the server fails, all the packages (applications) move to the other node. Not the system itself!

Yes, we assign an (relocatable) IP to the package so the application users directly login to the applications instead of server. To say it simple, they use the application IP to access it. So, the users are not exactly aware on which server is running it. They need not know either.

Are you referring to a System user or a Application user? Both are different.

Again, the question here is on security than on MCSG. I assume it works as expected.

If we are talking about application logins and application security, its better we talk to DB/Application team and get more information.

All the best!

-DB

Thanks for the explanation. I still don't quite understand the difference between system and application user.

Lets take an department with 10 employees, and 10 applications each running in its own package. Each application runs under the uid of a user owning all the files. Additionally, each employee shall have an username and password, which he can use to ssh to each of the packages. Is this possible?

At the moment I see only two alternatives. Everyone logs in as one of the 10 users the application in question runs at, which empowers everyone to delete arbitrary data, intentionally or not.
Or creating 100 additional accounts, one for each employee on each package, which among others results in 10 different user names and passwords for each user.

Is it possible to have the same username/password but different home directories on different packages? Or does the home directory has to live outside of the package and therefore won't be moved when the packages moves?

IMHO, this is not how it should be. There is no accountability on a system like that.

I undertand, what you are saying about the separate filesysetms.

We run SG and Oracle.

First, users (people) should be logging in to a server with an account that is theirs and only theirs. People should not log into servers as any other user (oracle or root or otherwise). All accounts should be named accounts, there should be no shared accounts.

So, pick a server to host your users (people). Create accounts for every user (real people and application owners [like oracle]) on EVERY server. Make your UIDs and GIDs consistent throughout the whole environment. Lock the users on servers they shouldn't have access to. In fact this could be in a package. You could reuse the LDAP server too (I don't use LDAP).

Use autofs to mount/share users home directories to every server.

>"Therefore people log into packages instead of Host"
You mean, SSH is configured on the package IP? This is ok. I do this sometimes.