I am working at my company to control the 'bsp' ID among our BaaN Administrators. I am of the understanding that the changes made to the application, must be made through the 'bsp' account, so the password for the account is shared amongst the 10 BaaN Administrators.

My questions are:
Can 'bsp' rights/privileges be given to an individual ID?
And if not can a user "su" to bsp, in a similar manner as root, and execute the program change.

Thanks in advance!
MWC

Hi MWC,

you can su to bsp, no problem.

But I personally think it is a myth, that changes need to be done as bsp.

Normal administration can be done as any user account, this should include:

a) creating users
b) assigning permissions
c) Generation of menus etc in DEM
d) configuring printers
e) configuring audit
f) installing patches

Several activities in Baan create files somewhere in $BSE, eg. convert to runtime. You need a setup to guarantee two things:

a) The generated files are readable by all members of bsp
b) The generated file can be overwritten by the other administrators

you can control this by using the umask command in Unix, but normally the default settings are already like this.

Maybe somebody knows something specific, what must (!) be done as bsp?

Regards

Markus

P.S.: sharing the bsp password is obviously not a good idea, because then it is impossible to track, who did what.

I applied several months of updates on LN with the Baan user without issue. However, some of the Tools patches and the Exchange module had problems and had to be done with the BSP user. This was the first time that this had happened. I have not tracked down the persmissions problem since the BSP user worked.

Normally the only requirement on some of the installs and configurations that it has to be done from the server console, and not from a workstation or remote desktop other than console 0.

The BSP user is normally left at the default package combination with company 000, and the Baan user is used as a common administrator. However, each administrator can have their default as SuperUser, you just need to be sure that the OS default permissions match the Baan user.

Just as a clarification: My above statement was covering BaanIV on Unix only.

Baan ERP might behave differently and Baan on Widows definitely does.

Normal practice is to do normal admin activities with bsp (though can also be done with other a/cs in many cases ) and to make other baan users members of bsp group . On unix levels the file system permissions are so set that all users can read however can not inadvertently write it (error 13 ) where it's so required . U can use baan executable binperm6.1 to correct incorrectly set permissions of executables .

Further u also need to have proper umask for proper default permissions.

Except for Triton, I don't think I have ever been instructed in any installation or administrator guide to sign in as BSP. Baan has been the administrator account starting with Baan IV. BSP was considered the failsafe login that the company and package combination should never be changed in.

Thanks a lot for all of your responses.

Our real issue is that we are trying to have effective segregation of duties between migrators and developers, for customized changes to BaaN. But this has been impossible since our migration team has insisted on utilizing the bsp account and sharing the password among the several individuals. From your responses, it sounds as though this is not really required as they have been stating.

If they are using the bsp account only for customizing changes to BaaN then you can set up every individual as a super user and they can to there normal work as with BSP permissions, so there is no reason to share the BSP account at all.

We have been using non-bsp (but superuser) accounts for installations & updates without any issues, except, while performing "create runtimes", but this maybe a permissions issue.

In case you give them separate account...

1. Ensure that the new accounts are part of the bsp group & whatever other group is required like sometimes, dba or oinstall is required by when using oracle as the backend.

2. And before removing any accounts, ensure that you change the ownership of files owned by them to an existing account.

Regards.

1. Ensure that the new accounts are part of the bsp group & whatever other group is required like sometimes, dba or oinstall is required by when using oracle as the backend.
You can always create a new group 'baanadm' (Baan Administrators) and assign the user ids to it.
2. And before removing any accounts, ensure that you change the ownership of files owned by them to an existing account.
We avoid part of this issue but creating a custom fixperms.ksh (to reset different directory/file permissions/owners) and its executed everyday by the Batch job.
Our real issue is that we are trying to have effective segregation of duties between migrators and developers, for customized changes to BaaN.
The developers do not need Super User access. You can create a authorization template and set them down to normal user. Refer to the threads - Sarbanes-Oxley Issue... (http://www.baanboard.com/baanboard/showthread.php?t=24747), Authorization for Developers (http://www.baanboard.com/baanboard/showthread.php?t=14614)
On unix levels the file system permissions are so set that all users can read however can not inadvertently write it (error 13 ) where it's so required .
You can avoid this issue, using the fixperm.ksh script and also refer to the thread - file permission on UNIX (http://www.baanboard.com/baanboard/showthread.php?t=10295)