Multiple Unix Users

[Max Drown (Infor)]

We have 12 people developing Cloverleaf interfaces in our group. Currently, everyone logs into the unix (solaris and aix) servers as hci. This causes some “issues” (ex. not knowing who has the Netconfig locked). Is this the recommended way for Cloverleaf developement and support or does Cloverleaf support multiple user accounts?

-- Max Drown (Infor)

Topic

[James Cobane]

Max,

What version of Cloverleaf are you on? Are you running the Cloverleaf GUI’s on the server instead of the client?  Normally, when you are running the GUI’s, you are running them from your workstation (client) and it uses the persons network id as the user id for the config files; i.e. that users network ID shows as the person who has a given file locked.  If you are logging into the server (as ‘hci’) via X-windows, then running the GUI’s on the server, then the user ID is going to be ‘hci’; so you should be running the GUI’s from your workstation, not the server.

With that said, when you are running hci commands (i.e. hcicmd -p myprocess -c ‘mythread pstart’ ,etc) via the command line, you need to be the ‘hci’ user in order to have the proper authority/privileges.

Hope this helps.

Jim Cobane

Henry Ford Health

[Max Drown (Infor)]

We are running Cloverleaf 5.2.1P. Most of the time the developers open the GUIs using hciaccess from the command line after telnet’ing to the box.

Common Scenario

01) telnet server_name

02) login as hci

03) set site using an alias such as “testsc”

04) hciaccess &

I’ve tried telnet’ing to the box using my own user, which works fine except when I use hci commands. So I guess its not possible to run hci commands (such as bouncing processes) properley as another user?

-- Max Drown (Infor)

[James Cobane]

Max,

You should be running the Cloverleaf GUI’s from your client machines, NOT logging into the server then running the GUI from ‘hciaccess’.  If you run the GUI’s from the client, you’ll know who has the file locked, and also know who was the last person to change the file (by looking within the prologue of the configuration file and seeing who the ‘author’ was).  I assume that all of the developers have the client software installed on their workstations/PC’s, so they should be running from there; i.e. assuming Windows then from the “Start” menu:  Start >All Programs > QDX Platform 5.2 > QDX Integration Services > IDE.  Then select the ‘Use the Remote Config Server’ radio button, and enter the server name/address.

Jim Cobane

Henry Ford Health

[Max Drown (Infor)]

We don’t have the clients running on our SunBlades. Probably should look into that. 🙂

(I have Solaris 10 on my SunBlade and apparently the clients won’t install on that version)

-- Max Drown (Infor)

[Richard Hart]

Max.

We have multiple users, each having their own Cloverleaf sites, owned by them.  We have a user ‘hcimgr’ that runs all the test and production sites and we ‘sudo’ to this login to access these.

Almost all of the work is completed under ‘our’ usernames, stored in CVS and then checked out for test/production.

NetConfig changes are usually checked on our test server, under ‘hcimgr’ before migrating to test or production.

We are on AIX (4.3.3 -> 5.3) and have been using this for a number of years for all versions of Cloverleaf; 3.5.2 -> 5.4.

We use the local GUI’s as this reduces the issues with ‘sharing’ sites etc.

We maintain about 60 production sites.

[Gene Salay]

Richard, I’m quite interested in hearing more about your setup and development process.  

How does hcimgr relate to the hci user that Quovadx runs under?  

What commands to you give your users for sudo?

Are the sites that the developers “own” just individual development areas, separate from the official test sites?

Do you maintain separate servers for test/production?

Sorry for all the questions – you sound like a large site and I am interested in best practices for our environment.

Also – is there a Quovadx log that indicates which sites are locked by another user without having to login to each site?

Thanks,

[Richard Hart]

Gene.

I hope this helps

Cloverleaf software is installed as standard with user ‘hci’; user ‘hcimgr’ is in the same group as hci and we use this to create any sites that are possibly ‘shared’ by the developers, occasionally dev and always test and production sites.

We work on the AIX server and use the GUI’s from there – rarely use the client software as his restricts our work.

We use ‘sudo’ to login as user hcimgr from our own logins.  

We have a test server that runs test sites and developers own sites.

The production server has production servers and some ‘dummy’ sites used to prove code installation changes.

We connect Metro hospitals and generally have one Cloverleaf site for each type and connection

ie

we have one AHS site for each hospital that runs an AHS (Allied Health System) application.

We use our own monitoring that reports issues with the enterprise tool to Ops.  We have provided Ops with procedures and a menu that performs all useful actions.  We get a call if Ops cannot rectify the issue.

We use CVS to store all scripts/NetConfig files etc.

Almost all of our translation code is TCL – we have a library of ‘smart’ code so a translation of a segment (within a translation script) is quite simple [see below] – the ‘GlobCXT$HciConnName ‘gives access to local namspace and allows us to ‘pass’ the namespace, so library code has access to the namespace.

We also ensure that all scripts contain a version id that is printed at thread startup.

A typical migration will start with a developer performing the change and unit testing in their schema – usually with shell scripts

eg …

export TEST_THDNAME=top_prod_rp_adt_in

DAT=ccm_xlate_top.dat

OUT=ccm_xlate_top.out

ERR=ccm_xlate_top.err

hcitpstest -r run -a -L -f nl    -S -c sms_ib_data -e "" ./$DAT "ccm_xlate_top" > $OUT 2>$ERR

The code is migrated to test for user system testing and then onto prod.

We use Unix links so that all Cloverleaf sites of a particular type share the same TCL translation scripts. Our ‘upgrade’ process creates a separate directory for the code [the existing TCL scripts and the new script] and the upgrade script changes the Unix link to the new directory and bounces the thread and checks that the correct revision is installed.  A backout is simply the reverse of this.  The script handles all sites/threads and reports success/failure.

proc XlateMSH {aAllFields} {

   global HciConnName

       #

       # sending application

       #

   set myId 2

   set aAllFields [lreplace $aAllFields $myId $myId "TOP@[GlobCXT$HciConnName GET SITE]"]

       #

       # sending facility

       #

   set myId 3

   set aAllFields [lreplace $aAllFields $myId $myId  QDX]

       #

       # receiving application

       #

   set myId 4

   set aAllFields [lreplace $aAllFields $myId $myId "[GlobCXT$HciConnName GET MSHRCV]"]

       #

       # receiving facility

       #

   set myId 5

   set aAllFields [lreplace $aAllFields $myId $myId CCM]

....

       #

       # return the segment we have just created

       #

   return $aAllFields

}

[Author]

Replies