Develop Reference

Rabbit MQ Error : unable to perform an operation on node 'rabbit#USERNAME'

Error: unable to perform an operation on node 'rabbit#YASHODIP-PC'. Please see diagnostics information and suggestions below.
Most common reasons for this are:
Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
Target node is not running
In addition to the diagnostics info below:
See the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more
Consult server logs on node rabbit#YASHODIP-PC
If target node is configured to use long node names, don't forget to use --longnames with CLI tools
DIAGNOSTICS
attempted to contact: ['rabbit#YASHODIP-PC']
rabbit#YASHODIP-PC:
* connected to epmd (port 4369) on YASHODIP-PC
* epmd reports: node 'rabbit' not running at all
no other nodes on YASHODIP-PC
* suggestion: start the node
Current node details:
* node name: 'rabbitmqcli-17388-rabbit#YASHODIP-PC'
* effective user's home directory: C:\Users\yasho
* Erlang cookie hash: 96Pe9121Rb1vncp1IqXA6Q==
I am not able to view the status of the rabbitMQ service installed on my local machine. Please suggest resolution.

This error can occur due to
Clustering between nodes are not proper
The erlang cookie is irrelevant
If you are not working on Clustering then second can be your problem, Please study RabbitMQ, erlang: how to "make sure the erlang cookies are the same"

This type of errors could happen if you have too long hostname. It's the reason why it explains :
If target node is configured to use long node names, don't forget to use --longnames with CLI tools
Solution
edit the rabbit's config file (for RHEL type it's /etc/rabbitmq/rabbitmq.conf). In the networking section :
#IPv4
listeners.tcp.local = 127.0.0.1:5672
#...
## write your ip and not your hostname
listeners.tcp.ohter_ip = 164.81.0.0:5672

Old topic, but I stumbled across it looking for reasons. So I will write what I have.
In the file /etc/rabbitmq/rabbitmq-env.conf
export RABBITMQ_NODENAME=rabbit#domain.com
replaced by
export RABBITMQ_NODENAME=rabbit#localhost

Executing command using SSH.NET on digi 6030dx modem - what are this character sequences starting with left square bracket?

I have some large project that connect to many devices over SSH.NET
Now I have to add support for new modem witch is digi 6030dx.
I added it and I am able to connect with no issues
But when I send some/any command like show config the output is:
[16C[0K
[16C[0Ks
[17C[0Kh
[18C[0Ko
[19C[0Kw
[20C[0K
[20C[0Kc
[21C[0Ko
[22C[0Kn
[23C[0Kf
[24C[0Ki
[25C[0Kg
Commands
-------------------------------------------------------------------------------
config View and modify the configuration
exit Exit the CLI
analyzer Analyzer commands.
cli-legacy Enter the legacy Admin CLI.
cp Copy a file or directory.
help Show CLI editing and navigation commands.
ls List a directory.
mkdir Create a directory.
modem Modem commands.
more View a file.
mv Move a file or directory.
ping Ping a host.
reboot Reboot the system.
rm Remove a file or directory.
scp Copy a file or directory over SSH.
show Show instance statistics.
system System commands.
traceroute Print the route packets trace to network host.
update Update firmware.
dra.wk.0001> ashowconfigdra.wk.0001> ashowconfig
[16C[0K
Does anyone known what are this strange signs / why my command is splited by this and newlines?
It is first device that have this issue and the app support over 200 other with no issues.
I guess some coding issue or something ? putty does not show this signs so probably 'understand' them somehow?

Those are ANSI escape codes.
In general, with SSH, you get these only if your client (library) declares support for terminal emulation.
SSH.NET library does that always, when you use the "shell" channel (SshClient.CreateShell or SshClient.CreateShellStream).
In general (were you connecting to well behaving SSH server), to avoid getting the codes:
Use "exec" channel (use SshClient.RunCommand). SSH.NET does not use terminal emulation on "exec" channel. Though SSH servers on "devices" (contrary to full servers) usually do not implement the "exec" channel. See also What is the difference between exec_command and send with invoke_shell() on Paramiko?
Modify SSH.NET code not to request terminal emulation for the "shell" channel. – Remove SendPseudoTerminalRequest request from Shell.Start implementation.
Though as you are connecting to some "device" and telneting further to another device and the codes probably come from the far device, the question is whether this will in fact have any effect on that device at all. Possibly you won't be able to avoid getting the codes. Lack of terminal emulation on the first SSH connection possibly won't have any effect on the second telnet connection.
In the end, you may have to deal with the codes.
See also How to strip ANSI escape codes from AIX topas command result in C#.

i did for now
this.answer = Regex.Replace(this.answer, #"\r\[\d{0,3}C\[0K", "", RegexOptions.IgnoreCase);
will see if have any negative impact but looks perfect for now :D

MQRC_NOT_AUTHORIZED when creating CCDT for MQ.NET Client

Error below occurs when accessing MQ server via .NET Client. Login credential is not asked when CCDT is created. But MQ server is looking for it for some reason.
I cannot find any information that covers both CCDT and the error below together.
IBM.WMQ.MQException: MQRC_NOT_AUTHORIZED
----- cmqxrsrv.c : 2356 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5540: Application 'bin\Debug\Producer.exe' did not supply a user ID
and password
EXPLANATION:
The queue manager is configured to require a user ID and password, but none was
supplied.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager configuration to OPTIONAL to allow applications to connect
which have not supplied a user ID and password.
----- amqzfuca.c : 4311 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'mqclient' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
ACTION:
Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
-------------------------------------------------------------------------------
17/04/2018 23:50:45 - Process(14900.9) User(SYSTEM) Program(amqrmppa.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ9557: Queue Manager User ID initialization failed for 'mqclient'.
EXPLANATION:
The call to initialize the User ID 'mqclient' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2356 -------------------------------------------------------
Server Setup
CCDT file is created by following the links below:
Setting up the server using IBM MQ Explorer
Server-connection Channel: LOCAL.DEF.SVRCONN
MCA User ID: empty
Setting up the client using IBM MQ Explorer
Clinet channe: LOCAL.DEF.SVRCONN
Queue Manager name: LocalQM
Connection name: 192.168.1.9(1415)
192.168.1.9 is localhost address
1415 is queue manager, LocalQM, TCP port.
SET CCDT Environment
1
C:\Users\'#.lp\source>SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\LocalQM\#ipcc
C:\Users\'#.lp\source>SET MQCHLTAB=AMQCLCHL.TAB
Put AMQCLCHL.TAB also to C:\ProgramData\IBM\MQ (I don't know why which might not be correct, because error on log file:
AMQ9518: File 'C:\ProgramData\IBM\MQ\AMQCLCHL.TAB' not found.
)
IBM MQ.NET
The code is below from here
MQQueueManager qm = null;
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\LocalQM\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
try
{
Hashtable props = new Hashtable();
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
qm = new MQQueueManager("LocalQM",props);
MQQueue queue1 = qm.AccessQueue("LocalQueue", MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
MQMessage msg = new MQMessage();
msg.WriteUTF("Hello this message is from .net client");
queue1.Put(msg);
queue1.Close();
qm.Disconnect();
}
catch (Exception ex)
{
Console.Write(ex);
}
IBM MQ V8 on Windows 10
MQ.NET Client V8 on Windows 10
Creating a client channel definition table
Using a client channel definition table with .NET
This thread is related to MQRC_Q_MGR_NAME_ERROR
Update 1
Following the link below. But it seems info on mqccred.ini is not used by MQ Server. Because the same error occurs.
Client side security exit to insert user ID and password ( mqccred )
Setup steps:
1 Create mqccred.ini (D:\mqccred.ini)
QueueManager:
Name=LocalQM
User=mqclient
password=password
2 Set Windows Environment variable
set MQCCRED=D:\mqccred.ini
3 Using mqccred
DEFINE CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(clntconn) +
CONNAME(127.0.0.1) +
QMNAME(LocalQM) +
SCYEXIT('mqccred(ChlExit)') +
REPLACE
4 Set ADOPTCTX(YES)
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
UPDATE 2
I updated MQ objects to uppercase, and still get the same error as above, but have new error log message below:
Do I need to write exit program in .NET according to Using channel exits in IBM MQ .NET ?
22/04/2018 22:37:15 - Process(11904.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
22/04/2018 22:38:21 - Process(5720.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
UPDATE 3
I have a different error below when MCA user ID is set to a Windows user.
IBM.WMQ.MQException: MQRC_Q_MGR_NOT_AVAILABLE
22/04/2018 22:38:21 - Process(5720.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
Update 4
Sorry for the confusion. Update 2 and 3 are the same. Both updates should have the same error: MQRC_Q_MGR_NOT_AVAILABLE, which comes after update 1. I put MQRC_NOT_AUTHORIZED by mistake.

The usage of a CCDT doesn't eliminate the need to prove identity to the queue manager. The first error you presented is because by default MQ requires a password for admin users.
There are four levels of CONNAUTH for client connections over the network:
CHCKCLNT(REQDADM) this is the default value. Any user with MQ administrative authority must provide a valid password. In addition any user without administrative authority that does provide a password must provide a valid password.
CHKCLNT(OPTIONAL) this is similar #1 but does not REQUIRE a password for users with MQ administrative authority. Any user Admin or not that provided a password must provide a valid password, with this value an administrative user would not be required to send a password.
CHCKCLNT(REQUIRED) this value means that all users must provide a valid password.
CHCKCLNT(NONE) no users are required to provide a password, and even if they do provide a password it will not be validated.
You can set this value for the entire queue manager on the AUTHINFO object set as the CONNAUTH value on the QMGR. If you set it to REQADMIN or OPTIONAL you can then uplift it for specific channels via a CHLAUTH rule to a stricter value such as REQUIRED. You can not set it lower.
If you disable security you have no security and anyone with access to your network can connect to your queue manager.
You have a few options to keep security enabled:
You could use a client security exit specified on the CLNTCONN to pass credentials such as mqcred.
You could use a client side certificate with TLS and map it to a MCAUSER on the SVRCONN.
Note based on your Update 1 you were specifying QMNAME(LocalQM), because there are no single quotes around the name MQ will fold this to UPPERCASE and set this as LOCALQM.
As Roger pointed out you also did not specify port 1415 on your CONNAME . You indicated you had problems with this you need to put single quotes around the CONNAME value if there are ( or ) characters in it.
Note based on your UPDATE 2 (Below gathered from comments that were moved to Chat):
Under the MQ installation directory normally under Program Files or Program Files(x86) you should find a sub-directory called Tools\c\Samples\mqccred, this should have sub-directories for 32bit (lib) and 64bit (lib64). You should copy the file from lib to the exits directory and from lib64 to the exits64 directory.
You only need a native .NET exit if you are using Managed .NET client mode which you indicate you are not using by having props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
UPDATE 2a based on your comment:
Sorry, I am using MQC.TRANSPORT_MQSERIES_MANAGED. I copied from
other thread. Does it mean I need to write .NET exit?
mqcred will not work with Managed mode .NET, to use a exit to provide the credentials you would need to write the equivalent in .net.
It would be much simpler to specify the credentials in your program via properties than to write a Managed mode exit similar to mqcred.
Roger's answer to "Sending message on IBM MQ: Hangs on AccessQueue
" provides a excellent sample that demonstrates passing the username and password in Managed mode. You can still get the connection details from the CCDT.
if (inParms.ContainsKey("-u"))
qMgrProp.Add(MQC.USER_ID_PROPERTY, ((System.String)inParms["-u"]));
if (inParms.ContainsKey("-x"))
qMgrProp.Add(MQC.PASSWORD_PROPERTY, ((System.String)inParms["-x"]));
if ( (inParms.ContainsKey("-u")) && (inParms.ContainsKey("-x")) )
qMgrProp.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);

Queue Manager name: LocalQM
Bad idea. You are shooting yourself in the foot. Use UPPERCASE for queue manager name and MQ object names. Once you are an intermediate or advance level MQAdmin, then you can try using mixed-case names.
DEFINE CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(clntconn) +
CONNAME(127.0.0.1) + QMNAME(LocalQM) + SCYEXIT('mqccred(ChlExit)') +
REPLACE
1st issue: If you do NOT put quotes around an MQ object name then MQ will AUTOMATICALLY uppercase it! So, MQ will see your command as for LOCALQM and not LocalQM.
The 2nd issue is that you did NOT specify the port # for CONNAME. Therefore, MQ will default to 1414. But you stated that you are using port # 1415.
And in case you don't know, MQ object names ARE case sensitive.
If I were you, I would delete the queue manager LocalQM and start over with LOCALQM and create all MQ objects with uppercase names.
Using CCDT should not require login credentials, which is one of the
purposes of using CCDT.
CCDT entries ONLY contain connection information. They will never include user/application credentials. To specify user/application credentials, you specify them in the application or use the mqccred client-side security exit.
In this day and age, every user and every application should be specifying user credentials so that we can have a secure MQ environments.
Update April 23, 2018
Architecture of the exit library does not match the process's
architecture which is '' bit.
Architecture is referring to the addressability of your program or the running framework of your program. Is it running as a 32-bit or 64-bit program. If it is running as a 32-bit program then you need to use the 32-bit mqccred.dll and if it is running as a 64-bit program then you need to use the 64-bit mqccred.dll.
I seem to remember something about .NET managed-mode (MQC.TRANSPORT_MQSERIES_MANAGED) programs cannot use natively built exits. You should ask IBM Support.

WCF Error : 'It is likely that certificate 'my cert' may not have a private key that is capable of key exchange

I have a WCF service I'm trying to host on our production web server (IIS6). I've set the web up and tied our cert to the web. When I try to browse to the service url, I receive the following error in the event log :
The exception message is: It is likely that certificate
'CN=.mydomain, OU=Secure Link SSL Wildcard, OU=I.T., C=US' may not
have a private key that is capable of key exchange or the process may
not have access rights for the private key. Please see inner exception
for detail.. ---> System.ArgumentException: It is likely that
certificate 'CN=.mydomain.com, OU=Secure Link SSL Wildcard,
OU=I.T., O=mydomain, C=US' may not have a private key that is capable
of key exchange or the process may not have access rights for the
private key. Please see inner exception for detail. --->
System.Security.Cryptography.CryptographicException: The handle is
invalid.
I've confirmed ASP.Net 1.1, 2, and 4 are all set to 'Allow' in 'Web Service Extensions'. I've also confirmed the cert is set up in iis and it shows 'You have a private key that corresponds to this certificate'. Also, Execute Permissions are set to 'Script and Executables'.

I had this problem, and it turned out that the account the service was running under did not have permissions to access the certificate's private key.
Here are the steps I used to solve it:
Start the Cetificate manager. Do this by running MMC, activate [File]-[Add/Remove Snap-in...], then add "Certificates", selecting "Computer Account" and "Local Computer" in the ensuing wizard dialogs.
In the certificate manager, right-click on the relevant certificate and activate [All Tasks]-[Manage Private Keys]
This gives you a permissions window. Click Add
Add the account name or group that this service runs under.

Seems like your certificate was created for signatures and not key exchange, what I suppose to be normal for SSL certificates.
If you look at the makecert documentation, you can see that the -sky switch lets you specify whether the certificate should be used for signatures or key exchange. You can try to create a self-signed certificate with type exchange and test whether the exception still occurs. Don't forget to put the self-signed certificate into the machine's trusted root certification authority folder in order to avoid exceptions that the certificate is not valid.

Ensure also that the account name or group that needs to access the certificate ALSO has access to the folder hierarchy that the certificate resides in. If your certificate is hiding in, for example, 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys', and the account that needs to access it is 'NETWORK SERVICE', then 'NETWORK SERVICE' needs access to that full path. Just assigning rights to the file is not enough.

Same problem here. To fix the problem I added the following line to the <system.web> node of the web.config.
<httpRuntime targetFramework="4.7.2"/>

I had this issue today and it was on a server cloned from another server. I had to uninstall the certs, reinstall the certs, and grant access to the certs (same manner as described in accepted answer).

OpenVPN --auth-user-pass FILE option on Windows [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
If you try to pass the username/password to OpenVPN from a file via the --auth-user-pass switch, you get the following error:
"Sorry, 'Auth' password cannot be read from a file."
At least they're polite.
So our workaround was to programmatically write to "standard in" when we get the Auth Username: and Auth Password: prompts (this is in C#).
Something with the timing isn't 100% reliable, so I was looking for a way to pass the credentials to OpenVPN in a different way and came across this post: OpenVPN Post
It says you can recompile the source with a --enable-password-save option. Has anyone been able to do this?
My final question is: How can I pass an auth username/password to openvpn.exe on the client side? And does OpenVPNGUI somehow do this (maybe we can copy what they do)?

NOTE! param auth-user-pass not work if start by GUI "C:\Program Files\OpenVPN\config\name.ovpn"
Made start file start_openvpv.cmd (+ link to with "run as admin") with content:
cd C:\Users\Name\Documents\VPN
"C:\Program Files\OpenVPN\bin\openvpn.exe" --config C:\Users\Name\Documents\VPN\myvpnconfig.ovpn --auth-user-pass "C:\Users\Name\Documents\VPN\pass.txt"
pass.txt:
yourusername
yourpassword
OR put line to name.ovpn, as in upper messege:
auth-user-pass pass.txt
+start_openvpv.cmd:
cd C:\Users\Name\Documents\VPN
"C:\Program Files\OpenVPN\bin\openvpn.exe" --config C:\Users\Name\Documents\VPN\myvpnconfig.ovpn

It's possible to open a VPN connection via a script by using the following DOS command (however this is not recommended since the password is not encrypted)
$openvpn.exe config.ovpn < username < password

It turns out the problem wasn't with standard in.
I was using some locking where if the process exited in the middle of writing to standard in, there could be a deadlock.
There is no issue sending the password in this manner.

For automatic authentication to Openvpn you have to modify the config.ovpn file.
-Go to OpenVPN\config directory and edit the .ovpn file
-Add this line to the config file -> auth-user-pass password.txt
-Then create the password.txt file and write in it:
yourusername
yourpassword
-After these steps your openvpn will connect automatically.