VerneMQ MySQL authentication - mysql

I already have installed vernemq in my cloud server, everything seems running fine. But from any client, it is unable to connect the broker using username/password authentication. The authentication is based on MySQL, the Lua script is running fine. But strangely the authentication not working or something is wrong. I couldn't trace anything as nothing shows in Log. The only debug message I see is as follows:
[debug] <0.227.0>#plumtree_broadcast:schedule_lazy_tick:720 0ms mailbox traversal, schedule next lazy broadcast in 10000ms, the min interval is 10000ms
OS : Ubuntu 18.04
MySQL Version : 5.7.29
VerneMQ Version : 1.10

That debug log message is unrelated (it shows load information on the metadata exchange protocol).
Please make sure the password formats/hashing methods are compatible between VerneMQ and MySQL.

Related

Powershell Remoting from windows to windows on different domain

I want to connect two windows server on different domains using powershell remoting.
I follows step that given in below blog
https://activedirectoryfaq.com/2018/09/import-powershell-sessions-from-computers-in-another-domain/
but it did not work for me. By following this blog, on connection it gives
**
Enter-PSSession : Connecting to remote server failed with the following error message : WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer
. Verify that the computer exists on the network and that the name provided is spelled correctly. For
more information, see the about_Remote_Troubleshooting Help topic
**
client server is windows server 2022 machine (powershell version 5.1.20348.1366)
remote server is windows server 2016 machine (powershell version 5.1.14393.1480)
Help me with it.

Zabbix Mattermost notification integrations - Timeout exceeded while connecting to 'localhost' when testing Mattermost Media Type

I am trying to intergrate our mattermost with zabbix to receive notifications on alerts. I've followed up the instructions on this link. We are using Zabbix 4.4 with MM 5.19.
After enabling the integration, No alerts are being posted on Mattermost. I tried testing the Media type on Administration > Media Types > Mattermost > Test.
I've added the following as the parameters, but it throws the error : Connection timeout of 3 seconds exceeded when connecting to Zabbix server "localhost".
bot_token : {Token generated for the Bot in Mattemost}
mattermost_url : {https://mattermost.our-company.com}
send_mode : alarm
Tried changing {ZABBIX_URL} to both http://127.0.0.1 and http://zabbix.our-company.com (The DNS is resolved only internally, but our mattermost is available on public network) but none of them work.
I checked the logs inside /var/log/zabbix but no error or anything. I even tried putting the zabbix logs to Debug mode but no luck in any case, the only Debug log I've got is the following :
2063:20200216:090224.146 trapper got '{"request":"alert.send","sid":"74095b240dd6783618571516f029187a","data":{"parameters":{"zabbix_url":"{$ZABBIX.URL}","send_mode":"alarm","send_to":"{ALERT.SENDTO}","event_tags":"{EVENT.TAGS}","event_name":"{EVENT.NAME}","event_nseverity":"{EVENT.NSEVERITY}","event_ack_status":"{EVENT.ACK.STATUS}","event_value":"{EVENT.VALUE}","event_update_status":"{EVENT.UPDATE.STATUS}","event_date":"{EVENT.DATE}","event_time":"{EVENT.TIME}","event_severity":"{EVENT.SEVERITY}","event_opdata":"{EVENT.OPDATA}","event_id":"{EVENT.ID}","event_update_message":"{EVENT.UPDATE.MESSAGE}","trigger_id":"{TRIGGER.ID}","trigger_description":"{TRIGGER.DESCRIPTION}","host_name":"{HOST.NAME}","host_ip":"{HOST.IP}","event_update_date":"{EVENT.UPDATE.DATE}","event_update_time":"{EVENT.UPDATE.TIME}","event_recovery_date":"{EVENT.RECOVERY.DATE}","event_recovery_time":"{EVENT.RECOVERY.TIME}","bot_token":"qs3rkqdappy6i8gs3a8871phxc","mattermost_url":"https:\/\/mattermost.our-company.com"},"mediatypeid":"7"}}'
What can be the issue? Is there a way to "debug" and find the root cause of this error? Any help is appreciated! Note that right now we have integrated Slack with Zabbix and it's working fine, but we are moving to Mattermost and therefore, we need to migrate the integrations as well.
We found out the issue with our Network Admin. The problem was that our Zabbix server was trying to resolve Mattermost name from local network route (i.e. 192.168.x.x) and it kept failing, therefore, no SSL connection could be initiated.
It seems that Zabbix integration tests' error messages are quite generic and sometimes, misleading. Thorough investigation is needed for finding out the root cause.

Server requires auth switch, but no auth switch handler provided

I'm using node-mysql2 and receiving this error message when connecting to a production instance of mysql via a wan:
Server requires auth switch, but no auth switch handler provided
This error is not received when connecting to our local dev server.
Furthmore, connecting to this mysql instance by other means works fine (mysql cli, Toad)
node-mysql2 version: mysql2#1.1.2 installed via npm.
This error was allegedly fixed back in Aug (RC9) https://github.com/sidorares/node-mysql2/pull/331
I'm not very familiar with mysql, Is there a server setting we can change to workaround this issue?
So it turns out this error also occurs with other libraries which give more meaningful error messages, e.g.: Authentication with old password no longer supported, use 4.1 style passwords
Solution from here: https://forums.mysql.com/read.php?38,593423,593423
SET SESSION old_passwords=0;
SET PASSWORD=PASSWORD('YOURDATABASEPASSWORD');

JMeter - trouble configuring payload for jmeter-server test connecting over SSH

I'm tearing my hair out over a JMeter config issue. I'm running JMeter on a dedicated injection server, using the gui on my local box to control the tests [EDIT: The connection is SSH. The client is Windows 7 and the server is Linux). I've run the tests from my local box and I confirmed that they're working correctly from there. I put the payload (text files containing one JSON object each) on to the injection server and changed the Publisher configuration in the message source section so the path pointed to the files on there and...nothing.
This is the only output I get:
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: running clientengine run method
2012/09/24 14:26:50 INFO - jmeter.samplers.StandardSampleSender: Using StandardSampleSender for this test run
2012/09/24 14:26:50 INFO - jmeter.samplers.StandardSampleSender: Using StandardSampleSender for this test run
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: sent test to <IP_ADDRESS_OBSCURED> basedir='.'
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: Sending properties {}
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: sent run command to <IP_ADDRESS_OBSCURED>
I don't know what I'm doing wrong. I tried Apache's highly comprehensive documentation, but surprisingly there's nothing at all about this. How should I be configuring the path to the payload on the server?
Coincidentally, I solved this one today and was on my way home to post the answer. The important thing to note is that the tests weren't running at all. The server reported stop-start but the tests weren't running. This is why:
I was using a JMS Producer sampler and connecting over SSH. This was part of the problem. In order to connect to a remote SSH server, it's necessary first to create an SSH tunnel, then start the JMeter server and client with special parameters. The process is described in this helpful and concise blog post:
http://blog.ionelmc.ro/2012/02/16/how-to-run-jmeter-over-ssh-tunnel/
The second mistake I was making was that I was running the server on a Linux box (CentOS) and the client on a Windows 7 desktop. It's not recommended to do this, but I didn't realise that it'd stop the test from running. I dropped a Linux VM on my windows box, ran the tests from there and everything worked perfectly.

Sqoop authenticates but fails to start a map reduce job

I am trying to transfer data using sqoop from HDFS to the MSSQL server. But for some reasons, sqoop hangs at
tool.BaseSqoopTool: Enabled debug logging.
sqoop.ConnFactory: Added factory com.microsoft.sqoop.SqlServer.MSSQLServerManagerFactory specified by /usr/lib/sqoop/conf/managers.d/mssqoop-sqlserver
DEBUG sqoop.ConnFactory: Loaded manager factory: com.microsoft.sqoop.SqlServer.MSSQLServerManagerFactory
DEBUG sqoop.ConnFactory: Loaded manager factory: com.cloudera.sqoop.manager.DefaultManagerFactory
DEBUG sqoop.ConnFactory: Trying ManagerFactory: com.microsoft.sqoop.SqlServer.MSSQLServerManagerFactory
INFO SqlServer.MSSQLServerManagerFactory: Using Microsoft's SQL Server - Hadoop Connector
INFO manager.SqlManager: Using default fetchSize of 1000
DEBUG sqoop.ConnFactory: Instantiated ConnManager com.microsoft.sqoop.SqlServer.MSSQLServerManager#45db05b2
INFO tool.CodeGenTool: Beginning code generation
DEBUG manager.SqlManager: No connection paramenters specified. Using regular API for making connection.
I check the firewall and it is allowing connections without any restrictions. Sqoop gets authenticated but doesnt initiate a map reduce job after it gets authenticated. Any one has faced similar problems before?
Try using --verbose to print more information.
Is your SQL Server running on a Virtual Machine? I had a similar problem with Oracle. I was running Oracle on a VM with a static IP and a Bridged network adapter. Servers within the same network as the Oracle server could connect fine, but servers outside the network showed these same symptoms. The solution was to change from a Bridged Interface to a NAT'd interface. Then you need to set up a port forwarding rule on the host machine to your database server, and make your Sqoop connection to the host machine IP rather than the VM's IP. It took me several days to get this figured out. Hope it helps.
We has MsSQL server running on our machines. The problem was that the particular version of JVM (Java(TM) SE Runtime Environment (build 1.6.0_29-b11)) had bug and caused the client to hang in the getconnection method.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103725
We upgraded to a newer version and things worked fine.