The business needs to carry out some work at the weekend that requires no users to be in the system. Is there any "easy" way to block users from logging onto Baan but still keeping the system up?

We run 4c4, Oracle805 on HPUX11

Thanks

PJ

If you only need bsp to be able to access the system, just do a chmod 700 on $BSE/lib/user - this will allow bsp to login and keep all others out - this is the best way. Afterwards you only need to do a chmod 770 on $BSE/lib/user to allow them to access the system again (we use this a lot!).

If you need some users to be able to login, you can move the ufiles from $BSE/lib/user by greping on their package combinations - usefull if you need to create RTDD and keep particular users off. I'll post a script here afterwards that does that...

This is one of the advantages of the wrapper script that I implement on the sites where I am responsible for the administration. I just simple create a file in the ${BSE}/etc/ directory, this blocks the user and shows the contents. In that way you can simply prevent users to login in and you provide them a way to see why they aren't allowed to login in.

In that same script you can also easily prevent them to logon more than once etc.

Kind regards,
Han

Thanks for your replies.

Han - Your wrapper script sounds interesting. Can you explain what a wrapper script is? Could you post the contents of your script?

Cheers

PJ

Move the ufiles based on pVRC contents


#!/bin/sh

# Variables here
BSE=/opt/baan4/bse
package_comb=$1

directory=<whatever_where_to_store_the_ufiles>

cd ${BSE}/lib/user
ls u* | xargs grep -l ${package_comb} | while read ufile
do
mv ${ufile} ${directory}
done
echo "Users that can access the $package_comb are moved to $directory"
echo "To restore their logon, move the ufiles back to $BSE/lib/user"

another way if you want more than just bsp to be able to login is to backup the ora_users file and to use a different one only containing say the superusers/users you want to access the system at that time. you can create the first one by copying the ora_users file and remarking out the users you don't want to be able to login. when finished put the original ora_users back.

If only bsp has to do the work (as usualy) try this one:

touch $BSE/tmp/nologin

after the work is done

delete the file "nologin"

thats all.

I am on NT baan 5 and use ttams1110m000 - User Data Template to set the allowable time from 0000 to 0000 for all templates except system - then a quick Run Time and no-one new signs in.

ls.,

i simply change the rights of $BSE/lib/ipc_info if only one user must logon.

chmod 400 $BSE/lib/ipc_info
chown <user> $BSE/lib/ipc_info

if more than one user has to logon i change bshell (or whaterever you use in ipc_info) in ipc_info to something different and tell the users to change that in the bwclient:
bshell s 0 0 p ${BSE}/bin/bshell6.2

to for example:
bstest s 0 0 p ${BSE}/bin/bshell6.2

This is a quick and diryt method..

solong

HenryT

hello baumgartner
this nologin fle works only for telnet users not for rexec login i supposeon baan.
regards ankur
correct me if i am wrong

Nope,
we are working with the BW-Client and it works fine!
If you need more information, please let me know!

Have a nice day
Phil

Create a role in oracle that you can assign to the users that will allow them access (i.e. weekend_users). Grant the necessary access to the tables for this user (i.e. insert, update, select, delete on all baan table objects) then create a pl/sql procedure that will revoke the standard privileges from the users (i.e. baanuser_role) and when the users not in the weekend_users group attempt to login they will get an error because they do not have the necessary privileges to read the tools tables.

If you have ever installed Baan, and had the install crash, you will find that you can not login to Baan, but during the install it actually will ask for the username and password. The installation can then login. So how does the install script login, when you cant from another session?

Baan removes the bshell6.x login program and uses bshell6.x.install. It's the same program, but by removing the bshell6.x baan successfully locks out everyone else. If you look in the ipc info file you will see both names in the file. You need to change your client profile, or create a new one to use the bshell6.x_install. The works for interactive login and install scripts, however it may not work for Jobs.