| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CSD07 |
« View previous topic :: View next topic » |
| Author |
Message
|
| KIRANP |
 Posted: Mon Jul 19, 2004 7:05 am Post subject: CSD07 |
 |
|
Acolyte
Joined: 23 Jul 2002
Posts: 51
|
Hi ,
I have CSD-04 on my windows box.I want to upgrade to CSD 07.Do i need to uninstall CSD 04 and then install CSD 07 or directly install 07?
Thanks
Kiran |
|
| Back to top |
|
 |
| JasonE |
| Posted: Mon Jul 19, 2004 8:49 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| No. All windows fixpacks are cumulative from GA, so you can apply any at any point of the fixpack cycle (eg. ga -> fpx -> fpy, or ga->fpy or even ga->fpw->fpx->fpy) |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Jul 19, 2004 11:45 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Jason, speaking of CSD07, I just did a bunch of upgrades at a client site last Friday and discovered some interesting.
Specs:
OS: Sun Solaris 8
WMQ: 5.3 CSD03
mqm account shell: /bin/ksh
After the upgrade on the first box, I put a message to a triggered queue and nothing happened. I stopped the trigger monitor and then started it in the foreground. After I put the message, I realized that the application was crashing. It is a Java application (requires v1.4) started from a shell script. It is a message router that I wrote for them and runs under the mqm account.
The mqm account has the profile with the path to a JRE that is v1.4 (without it, the apps will run under v1.2.2 - and will fail). The app shell script has the path to required stuff including MQ jars.
As soon as I put the JRE bin path in the PATH (and JAVA_HOME) environment of the shell script everything worked.
As I upgraded each Solaris box, the same thing happened over and over again, and as soon as I updated the shell script, everything worked.
I even tested 1 box before the upgrade by stopping the queue manager and restarting it (including command server, listener, channel init, & trigger monitor). The app would start via the trigger. I then stopped the queue manager, upgraded it, and the triggering failed until I updated the script!!!!!
Note: The trigger monitor does run under the mqm account.
So somebody at Hursley, changed how a shell script is launched via trigger monitor (from CSD03 to CSD07 - I don't know which CSD).
Also, I case you wondering, the first line of the shell script is:
#!/bin/sh
I only have a handful of production boxes left to do, so it is not a big deal - given that I know what to do. But I 'pitty the fool' who has hundreds of scripts on hundreds of boxes. In this case, I would expect some hate mail. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Jul 20, 2004 3:13 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 20, 2004 7:53 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The Java application was throwing an exception and dying. The Java application is using a v1.4 only method. So, when it runs under Java v1.2.2, it dies. Luckly, the '1.4 only' method is in the 'init' section of the program, and it has not connected to a queue manager or openned any queues yet.
This is must definitely repeatable (at least until I run out of boxes!!). Do you want some scripts or profile info?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Jul 20, 2004 9:16 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| (Contacted offline via PM) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 20, 2004 9:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
Note: The trigger monitor does run under the mqm account.
|
Roger, how did you accomplish this in your particular case?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 20, 2004 10:09 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Peter,
Are you referring to the trigger monitor? If so, here is a sample startup script that I created for Solaris (it resides in /etc/rc3.d )
| Code: |
#!/sbin/sh
#
case "$1" in
'start')
su - mqm -c "cd /opt/mqm/bin; ./strmqm MYQMGR "
su - mqm -c "cd /opt/mqm/bin; ./strmqcsv MYQMGR "
su - mqm -c "cd /opt/mqm/bin; ./runmqlsr -m MYQMGR -t TCP -p 1414 & "
su - mqm -c "cd /opt/mqm/bin; ./runmqchi -m MYQMGR & "
su - mqm -c "cd /opt/mqm/bin; ./runmqtrm -m MYQMGR & "
;;
'stop')
su - mqm -c "cd /opt/mqm/bin; ./endmqm -i MYQMGR "
su - mqm -c "cd /opt/mqm/bin; ./endmqlsr -m MYQMGR & "
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0 |
Or if you are referring to the script that is used to start the Java program, I updated the PATH with the JDK path:
| Code: |
| PATH=/apps/j2sdk1.4.2_03/bin:/opt/mqm/java/lib:$PATH |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 21, 2004 8:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Duh.
For some reason I thought you said you ran the trigger monitor NOT under mqm.
That is something I have to figure out, since I can't have the triggered processes running under mqm, as it defeats all the setmqaut commands I did for the application groups. I have received lots of conflicting responses on this issue, the most "severe" one being there is no way to make the default runmqtrm run under any ID but mqm, since there is actual code in the executable that forces this.
I am just gonna try different things I have read here and there to see if any of them work, but right now don't feel to confident. I was hoping you had figured a way to do it. Guess I read in your post what I was hoping for instead of what you actually wrote.
If I can't figure it out (I want runmqtrm to run as mqapps01, an ID with only +allmqi aut), maybe I'll start a new thread on the subject.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jul 21, 2004 8:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter -
What OS?
On unix, the "su - mqapps01" should do it.
On Windows, you can create a scheduled task to runmqtrm at startup, in the background, and assign that task to be run mqapps01. If you need to run multiple instances of runmqtrm, you might want to make renamed copies of the binary and run those instead. So that Task Manager lets you know which process to kill if you need to.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 21, 2004 8:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
See thats what I thought. But then I got the following post from the listserve:
| Quote: |
orld has no permissions by default so only root and user mqm or group mqm members can start it (mqappid would need to be a member of group mqm). Regardless of who starts runmqtrm, since it is setuid (and setgid) mqm it will run with effective id mqm and effective group mqm, as will any triggered program. Plus, mqappid being a member of group mqm is probably not a good thing.
If you unset setuid (and setgid), as Greg suggested in (b) (possibly leaving group mqm as owner and giving world r-x) then it will run as whomever starts it, as will any triggered programs. That allows any user to run the trigger monitor but the object authorities will determine if it can actually work.
The MQ permissions need to be set so that the user's group(s) has permissions necessary to run the trigger monitor successfully. I forget exactly what the required settings are but something like get+inquire on the inititiation queue and display on the process.
I think a benefit of settings "-r-xr-xr-x mqm mqm", as opposed to "-r-xr-x--- mqm mqapps" (see Greg's solution b), would be more control of which groups could listen to which initq(s) and start which process(es) instead of lumping them all into one group with common permissions. Depends on requirements - I guess that'd be more flexible but entail a bit more administrivia.
Having all triggered programs run as user/group mqm can be problematic though not nearly as bad as running them as root 
One issue is you probably don't want to give away mqm rights so readily.
Another is mqm often doesn't have rights to either start the triggered app or do something the app is supposed to do.
Yet another arises when you use the client trigger monitor and hopefully enforce clients attach as a user other than mqm.
I believe a problem with Dennis' suggestion is you cannot su in a script/program unless you are root and you never want to run the trigger monitor, nor anything else you don't have to, as root. I think a non-root issued su requires the password to be entered on a tty so you can't redirect one in or anything like that - assuming you'd even want to.
To not answer Greg's question I have no idea why runmqtrm is setuid/setgid but it would be interesting to find out. It's been that way for a very long time and I'm sure there is, or was, a logical reason.
I've used Greg's solution (a) before but seems like (b) would be better so you don't lose track of all those trigger monitor programs. Don't know if there's a (c), outside of something like a custom trigger monitor running as root that can switch effective user/group before the system() call but that doesn't sound like a great idea. Maybe the list will come up with a good answer for (c) - the optimal approach.
Just thought of one possible approach - leave runmqtrm as it is and setuid/setgid the triggered applications to appropriate values. One drawback to that is devious app owners could, depending on permissions, unset setuid/setgid so they get mqm rights. mqm would have to be in the group that owns the app too, if it's not world executable. Oh well, it might work.
Hope that helps the discussion some and didn't introduce much misinformation.
Cheers,
Marty
Hi Greg, how are things at Pioneer? Heard from Rob Rehms lately?
>
>-----Original Message-----
>From: Miller, Dennis [mailto:DMiller@SNOPUD.COM]
>Sent: Friday, July 09, 2004 6:21 PM
>To: MQSERIES@AKH-WIEN.AC.AT
>Subject: Re: Trigger Monitors
>
>
>I think it's not so much the trigger monitor runs under MQM as that the
>triggered applications also inherit that userid. Since the mqadmin can
>tightly control what programs the trigger monitor can run, you might
>consider a scheme where the trigger monitor runs shell scripts that SU
>to a more appropriate userid before getting on with business logic.
>
>Regards,
>Dennis
>
>-----Original Message-----
>From: Smith, Gregory [mailto:gregory.smith@PIONEER.COM]
>Sent: Friday, July 09, 2004 11:47 AM
>To: MQSERIES@AKH-WIEN.AC.AT
>Subject: Trigger Monitors
>
>
>I'm posting this here for discussion and will likely open a PMR with IBM
>to get their perspective.
>
>In the UNIX realm for a while we have discussed the fact we are not
>comfortable triggering an application and having it run as mqm with full
>mqm privileges. We would prefer and are considering having multiple
>trigger monitors each running under a unique application group id.
>
>Naturally out of the box the trigger monitors attributes are set to
>force the monitor to run as mqm as the example below shows:
>
> lx03-cluster:#> ls -al /opt/mqm/bin/run*
> -r-sr-s--- 1 mqm mqm 18328 Feb 11 16:09
>/opt/mqm/bin/runmqtmc
>
>#1 - Is anyone aware of a technical reason for this?
>
>We are considering two approaches to this
>
>a) Placing a copy of the executable in each application groups home
>directory. The down side to this is we could have many versions that we
>as admins would have to keep track of whenever we apply maintenance to
>the software.
>
>b) Modifying the attributes of the source
>
> -r-xr-x--- 1 mqm mqapp 18328 Feb 11 16:09
>/opt/mqm/bin/runmqtmc
>
> but again we would need to keep note of this whenever we apply
>maintenance to the software however this would be the lesser of the two
>evils.
>
>c) are there other options??
>
>Thanks for your input in advance!
>
>Gregory P. Smith
>Pioneer, A DuPont Company
>E-Mail: No SPAM:Gregory.Smith@pioneer.com
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| clindsey |
| Posted: Wed Jul 21, 2004 9:16 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
| Quote: |
since I can't have the triggered processes running under mqm
|
Peter, you might try experimenting with amqstrg ( in /opt/mqm/samp/bin or /usr/lpp/mqm/samp/bin). It is a non-setuid trigger monitor.
It doesn't take '-q' or '-m' as parms, only initqname and qmgrname.
Charlie |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 22, 2004 4:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Well, I got the default runmqtrm to run under another ID, and it kicks off
processes under that ID as well. Those triggered processes truly are running
under the new ID (not mqm), as they follow the rules I set with setmqaut,
and doing a Q status shows the User ID connected is in fact the ID I want,
not mqm. If I try and send the triggered app to a queue I did not give it
authority to, it gets the 2035.
All I did to get runmqtrm to run as mqappsaa, and any triggered process to
run as mqappsaa, was the following. The triggered app should only be able to
GET/PUT from SYSTEM.DEFAULT.LOCAL.QUEUE, no other queue:
1. Create a group called mqappsaa
2. Create a user called mqappsaa, and put him into the group mqappsaa
3. setmqaut -m SOLARIS1 -t qmgr -g mqappsaa +allmqi
4. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEFAULT.INITATION.QUEUE -g mqappsaa
+allmqi
5. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEAD.LETTER.QUEUE -g mqappsaa +allmqi
6. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEFAULT.LOCAL.QUEUE -g mqappsaa
+allmqi
7. chmod 777 runmqtrm, so that anyone can start it. Probably can be tighter
on this step, but you get the point.
8. log on as mqm, just to prove it will work even if I su to mqappsaa
| Code: |
masun1 > su mqappsaa
Password:
$ whoami
mqappsaa
$ runmqtrm -m SOLARIS1
5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED.
WebSphere MQ trigger monitor started.
__________________________________________________
Waiting for a trigger message
/var/mqm/peterscript.sh 'TMC 2PETER
End of application trigger.
__________________________________________________
Waiting for a trigger message
|
9. Open up another session, and check what ID runmqtrm is running under:
| Code: |
masun1 > ps -ef|grep runmqtrm
mqm 4160 3977 0 20:09:49 pts/3 0:00 grep runmqtrm
mqappsaa 4145 4143 0 20:02:12 pts/2 0:00 runmqtrm -m SOLARIS1
|
10. Drop a test message into the triggered queue, and quickly do the
following command to see what ID amqsget is running under. I triggered
amqsget to run in the background.
| Code: |
masun1 > ps -ef|grep amqsget
mqm 4165 3977 0 20:20:09 pts/3 0:00 grep amqsget
mqappsaa 4163 1 0 20:20:03 pts/2 0:00 /opt/mqm/samp/bin/amqsget
SYSTEM1
|
A Queue Status on the INIT queue and the DLQ shows runmqtrm running as
mqappsaa.
A Queue Status on SYSTEM.DEFAULT.LOCAL.QUEUE shows amqsget running as
mqappsaa, and it consumes the message.
Switching the process def to run amqsget against
SYSTEM.DEFAULT.LOCAL.QUEUEXXXXXX causes the app to get a 2035, proving
security can be set on a triggered process started by the default runmqtrm.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
