Find out which process is using a port in Linux

1. netstat
# netstat -tuplna|grep port_number
[root@love ~]# netstat -tuplan|grep 1477
tcp        0      0 :::1477                     :::*                        LISTEN      12129/runmqlsr
tcp        0      0 ::ffff:127.0.0.1:1477       ::ffff:127.0.0.1:50240      ESTABLISHED 12710/amqrmppa
tcp        0      0 ::ffff:127.0.0.1:50240      ::ffff:127.0.0.1:1477       ESTABLISHED 23447/java

從上面結果可知:
(1)pid 12129 (runmqlsr)    這個process 在LISTEN 1477這個port
(2)pid 12710 (amqrmppa) 這個process用127.0.0.1的1477 port連往 127.0.0.1的50240 port
(3)pid 23447 (java)           這個process 用127.0.0.1的50240 port連往 127.0.0.1的1477 port


2. fuser
#fuser port_number/tcp -u -v
[root@love ~]# fuser 1477/tcp -u -v
                     USER        PID   ACCESS    COMMAND
1477/tcp:      mqm       12129   F....            (mqm)runmqlsr
                     mqm       12710   F....            (mqm)amqrmppa

3. lsof
#lsof -i :port_number
[root@love ~]# lsof -i :1477
COMMAND  PID  USER FD TYPE DEVICE SIZE/OFF NODE NAME
runmqlsr        12129  mqm   5u  IPv6      699704    0t0       TCP *:ms-sna-server (LISTEN)
amqrmppa     12710  mqm   6u  IPv6     2028669   0t0       TCP localhost:ms-sna-server->localhost:50240 (ESTABLISHED)
java               23447   root  118u  IPv6    2028668   0t0       TCP localhost:50240->localhost:ms-sna-server (ESTABLISHED)

Ref:
Linux Find Out Which Process Is Listening Upon a Port

https://www.cyberciti.biz/faq/what-process-has-open-linux-port/

How to change the MQ qmgr error log file permission to allow user not in mqm group could access it

If you would like to allow user in non mqm user group to access the qmgr error log, you may try to modify the file and directory permission for the non mqm user group. However you will find after qmgr updating the content of the qmgr error log or qmgr restart, the qmgr sets all the files and folder permission back to the default setting. The non mqm user can’t access the error log again. To solve this issue, you need to use the following parameter in the qm.ini file.

Filesystem:ValidateAuth=No

This setting will cause the queue manager to leave the permissions on the error log files unaltered.

IT09572: ValidateAuth=No does not maintain file permissions on queue manager error logs

http://www-01.ibm.com/support/docview.wss?uid=swg1IT09572

passing an argument to mq process script

How to pass an argument to mq process script (or run it background in unix)

Example:

If we would like define a process which invokes the "luke.sh" script

and would like also passes the argument "lightsaber" to luke.

=== process definition ===

DEFINE PROCESS(P1) +
       DESCR ('MQ test process script') +
       APPLTYPE(UNIX) +
       APPLICID('/tmp/luke.sh') +
       USERDATA(' ') +
       ENVRDATA('lightsaber')
=== process definition ===

You must put the argument in the 'ENVRDATA' but not 'USERDATA'.

*** tip:

You can also put "&" in the ENVRDATA for the UNIX script running in the background.

DEFINE PROCESS

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q085670_.htm

****On UNIX systems, ENVRDATA can be set to the ampersand character (&) to make the 

    started application run in the background.

OpenSSL commands to check and verify your SSL certificate, key and CSR

https://support.asperasoft.com/hc/en-us/articles/216128468-OpenSSL-commands-to-check-and-verify-your-SSL-certificate-key-and-CSR

It can be useful to check a certificate and key before applying them to your server. The following commands help verify the certificate, key, and CSR (Certificate Signing Request).

(1)Check a certificate
Check a certificate and return information about it (signing authority, expiration date, etc.):

#openssl x509 -in server.crt -text -noout

(2)Check a key
Check the SSL key and verify the consistency:
#openssl rsa -in server.key -check

(3)Check a CSR
Verify the CSR and print CSR data filled in when generating the CSR:
#openssl req -text -noout -verify -in server.csr

(4)Verify a certificate and key matches
These two commands print out md5 checksums of the certificate and key; the checksums can be compared to verify that the certificate and key match.
#openssl x509 -noout -modulus -in server.crt| openssl md5
#openssl rsa -noout -modulus -in server.key| openssl md5

For the WAS or MQ, you can also use the keytool which under the jre/bin folder

#keytool -printcertreq -file your_req_file
#keytool -printcert -file your_cert_file

For Windows Platform, you can use certutil command (built-in) to review the file.
certutil -dump <file>


*** the MQ gskit command (runmqckm) can not do this job.

Removing a qmgr from a cluster

Procedure

Perform the following tasks at the TORONTO queue manager:

1. Modify the full repository queue manager REPOS and
REPOSNL attributes
If your queue manager is a full repository queue manager, before you can remove
it from a cluster, perform the additional step of altering the queue manager
definition to set the REPOS and REPOSNL attributes to blank. This sends a
notification to other queue managers advising them that they must stop sending
cluster information to this queue manager.

2. Check that the REPOS and REPOSNL changes have been
propagated
Check that the changes you made in the previous step have been propagated
around the cluster by issuing the following command on a remaining full
repository:

DIS  CLUSQMGR(TORONTO)  QMTYPE

and check that it shows that the queue manager is no longer a full repository. The
output should match the following:
AMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
QMTYPE(NORMAL)

3. Suspend queue manager TORONTO
Issue the SUSPEND QMGR command to suspend availability of the queue
manager to the INVENTORY cluster:
SUSPEND  QMGR  CLUSTER(INVENTORY)
When you issue this command, other queue managers are advised that they
should refrain from sending messages to TORONTO.


4. Check that queue manager TORONTO has been suspended
Check that TORONTO has been suspended before moving on to the next step by
issuing the following command on a full repository:
DIS  CLUSQMGR(TORONTO)  SUSPEND
and check that it shows that the queue manager is suspended. The output should
match the following:
Removing a queue manager
114    Queue Manager ClustersAMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
SUSPEND(YES)

5. Remove the CLUSRCVR channel definition
Remove the CLUSRCVR definition from the cluster:
ALTER  CHANNEL(TO.TORONTO)  CHLTYPE(CLUSRCVR)  CLUSTER(’  ’)
This command causes the full repository queue managers to remove all
information about that channel from their full repositories, so that queue managers
will no longer try to send messages to it. You can verify that this command has
been successfully propagated by issuing the following command on the full
repository:
DIS  CLUSQMGR(TORONTO)
You should receive a message like that below:
AMQ8147:  WebSphere  MQ  object  TORONTO  not  found

6. Stop the CLUSRCVR channel at TORONTO
Note:  Before performing this step, ensure that any bound messages have arrived
on TORONTO, otherwise these messages will become stuck on the sending
queue manager’s cluster transmit queue.
Issue the STOP CHANNEL command to stop the cluster-receiver channel:
STOP  CHANNEL(TO.TORONTO)
Once the channel is stopped, no more messages can be sent to TORONTO.
Later, to tidy up, you will probably want to delete the channel:
DELETE  CHANNEL(TO.TORONTO)
Note:  At this point the TORONTO queue manager is no longer a valid destination
in the cluster, but there may be messages bound to TORONTO (messages
put using BIND_ON_OPEN) still being sent from other queue managers in
the cluster.

7. Delete the CLUSSDR channel definition
Note:  Do not attempt this step before completing all previous steps in this task.
The CLUSSDR channel definition points to the full repository at queue manager
NEWYORK. Stop this channel as follows:
STOP  CHANNEL(TO.NEWYORK)
and then delete it:
DELETE  CHANNEL(TO.NEWYORK)

8. Issue the REFRESH CLUSTER command
Issue the REFRESH CLUSTER command to remove any auto-defined cluster
channels:
REFRESH  CLUSTER(INVENTORY)  REPOS(YES)

The queue manager TORONTO is no longer part of the cluster. However, it can
still function as an independent queue manager.


Ref:
Queue Manager Clusters

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

https://developer.ibm.com/answers/questions/213076/in-ibm-websphere-mq-can-you-disable-tlsv10-and-tls.htm

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

Question by MCregge  (3351) | Sep 10, 2015 at 06:54 AMMQSSLTLSCIPHERSTLSV1.1TLSV1.0

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

Like ·    1 ·    Comment   Reward user

3 answers

 · Add your answer

• Sort: 

Accepted answer

Answer by MCregge (3351) | Sep 10, 2015 at 06:55 AM

As you probably know, the latest updates to MQ are deprecating (disabling) the use of SSLv3 ciphers (and some "weak" TLS ciphers) due to known security vulnerabilities. Several customers have asked about disabling TLSv1.0 and TLSv1.1 ciphers also.

---

*There is a new APAR which allows disabling TLSv1.0 ciphers at the listener level in the latest maintenance releases of MQ v8 and v9. This is enabled via a qm.ini setting, see:

 SSL:
    AllowTLSV1=NO  

http://www.ibm.com/support/docview.wss?uid=swg1IT23235

---

Before that APAR, TLSv1 could not be disabled at the listener level, but you could still configure MQ to only allow channel communications on certain ciphers.

The simplest way to disable TLSv1.0 & TLSv1.1 protocols would be to set a TLSv1.2 cipherspec in the channel definition. The queue manager will only allow that cipherspec to be used which was configured on the channel; thus if you configure your channels with TLSv1.2 ciphers, that would mean that TLSv1.0 & TLSv1.1 protocols being disabled.

There is another way to disable TLSv1.0 protocol which is by enabling Suite B mode. The GSKit docs state that Suite B will disable all protocols except TLSv1.2. Information on Suite B implementation is here:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010200_.htm?lang=en

The configuration of Suite B mode is given in the following link:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010210_.htm

To have a look at the list of cipherspecs and the corresponding protocols used by them, follow the below link:

http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q014260_copy.htm

Update: MQ/SSL connections can not disabled at MQ listener level, the options noted above cause the MQ channel to fail to start unless using an adequate cipher, but they do not disable the MQ listener process from initially receiving the TLSv1.0 session.

I hope this helps. Please add comments or info.

---

Related info:

Deprecation: SSLv3 protocol ( MQ v7.0.1.13, v7.1.0.7, v7.5.0.5, v8.0.0.2 )
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q123420_.htm?lang=en

Deprecation: Weak Ciphers deprecated ( MQ v7.0.1.13, v7.1.0.7, v7.5.0.6, v8.0,0.3 )
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q123425_.htm?lang=en

Like ·    0   Comment   Reward user   Share

Answer by CarlosBarros (1) | Oct 15, 2015 at 11:06 AM

We have some problems regarding the suggestions.

Set a TLSv1.2 cipherspec in the channel definition doesn't mean the TLS 1.0 and TLS 1.1 will be disable. We did the test and they are enable.

Set SUITEB on queue manager will force the ciphers TLS 1.2 with elliptic curve. Unfortunately, ciphers with elliptic curve are vulnerable too. http://www-01.ibm.com/support/docview.wss?uid=swg21688949

Do we have any other option to disable the TLS 1.0 and TLS 1.1?

Like ·    0   Comment   Reward user   Share

Answer by MCregge (3351) | Aug 01, 2016 at 10:55 AM

Before APAR IT23235 (noted above), by default MQ would accept the TLS 1.0 connection and then disconnect it if it requests a channel that requires TLS 1.2.
There was no way to disable TLS 1.0/1.1 completely short off the SUITEB setting noted above..

If there is a need to fully disable TLS 1.0/1.1 the recommendation is to create an Enhancement requests at the following website:

http://www.ibm.com/developerworks/rfe/?BRAND_ID=181

Select 'IBM MQ', then can search or submit new requests.

Like ·    0   Comment   Reward user   Share

How to list defects with special key work from the fix list using Linux command

lynx -nonumbers -dump http://www-01.ibm.com/support/docview.wss?uid=swg27043086|grep -E 'memory leak|Fix Pack'|grep -B1 'memory leak'|perl -ne 's/^\s+//;print'|grep -v "\-"

lynx:

-nonumbers : 去掉行數
-width         : output 的欄位長度, 預設為80, 因此可看見最後一個fix 顯示有問題, 加長後解決
-dump         : 直接純文字輸出到螢幕

perl:

-n                :按行讀取
-e                :執行右邊的命令

未加 -width

















加-width=120
lynx -nonumbers -width=120 -dump http://www-01.ibm.com/support/docview.wss?uid=swg27043086|grep -E 'memory leak|Fix Pack'|grep -B1 'memory leak'|perl -ne 's/^\s+//;print'|grep -v "\-"|grep -E ' memory leak|Fix Pack'

參考資料﹕
Perl命令行使用技巧
https://wenku.baidu.com/view/96060bee4afe04a1b071de48.html