First I get this error "connect to address 10.0.0.102 and port 12489: Connection refused", then I made some changes according to forums and I changed nclient.ini file. I adjusted the allowed hosts and password.
Then server side the Status Information is changed. Now I get this error in Nagios Admin Panel:
NSClient - ERROR: Invalid password.
However, at Nagios XI Server I checked password and it's same as in nsclient.ini file on client side.
I used this command to check:
/usr/local/nagios/libexec/check_nt -H 'hostname' -s nagpasswd -p 12489 -v CPULOAD -w 80 -c 90 -l 5,80,90,10,80,9 NSClient
What might be the issue? Any help would be perfect.
after changing the password , you need to restart your nagios service once
Related
I use snowflake and snowsight on windows OS. And, I did the below command but the error happened.
Do you have the answer about this error 250001 (n/a)?
C:\Docs>snowsql -a lvXXXXX.ap-northeast-1.aws -u username -o log_level=DEBUG
Password:
250001 (n/a): Could not connect to Snowflake backend after 0 attempt(s).Aborting
If the error message is unclear, enable logging using -o log_level=DEBUG and see the log to find out the cause. Contact support for further help.
Goodbye!
The error message appears to be an issue with "Failed to check OCSP response cache file."
You can try to connect using insecure mode to bypass the OCSP checks.
Use this:
snowsql -a lvXXXXX.ap-northeast-1.aws -u username -o insecure_mode=True
If the connection is successful, it means there may be a firewall/proxy that is blocking the connection to the OCSP server. Note: OCSP connects via port 80.
I am using below batch command for ExpressMaint. I know it has worked with a Windows account.
When I disable the Windows account on the SQL Server instance, it doesn't work correctly.
D:\ExpressMaint\ExpressMaint.exe -S . -D TEST -T CHECKDB -R D:\ExpressMaint\Report -RU WEEKS -RV 4
I get this message
Failed to connect to server ..
Login failed for user 'DPY\gw.lee'. Reason: The account is disabled.
ExpressMaint finished unsuccessfully at 2020-03-09 오후 3:47:32 with Return Code(-3)
Can I have option for specifying ID/PW of SQL Server instance?
I'm trying to connect to my SQL Server from a Linux terminal using SQSH. The line is:
sqsh -S <ip address> -U <DOMAIN\user>
which throws an error:
Msg 18456, Level 14, State 1 Server 'DC2', Line 1
Login failed for user ''.
Notice that it seems to have removed the '\' which separates my domain and user.
On the server side, my event log confirms the same thing. The event reads:
Login failed for user 'DOMAINuser'.
Reason: Could not find a login matching the name provided.
I've tried using single and double quotation marks to encapsulate the domain and user name, but when I do that, the request does not even make it to the server, probably because the quotes signify something else syntactically.
Does anyone know what I'm doing wrong?
sqsh uses the FreeTDS configuration file by default, so the version of TDS can be specified. A full description can be found here, but the command line result should look like this:
sqsh -S<config file name> -D <database name> -U <domain>\\<user> -P <password / hash>
Example:
sqsh -S mssql -D MyDB -U DOMAIN\\testuser -P MyTestingClearPassword1
I'm trying to excute the following command:
/usr/lib/nagios/plugings/check_nrpe -H xxxxxxx -c check_disk -a 60 80 /dev/sda1
but I got the following message:
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.
When I consult the log in the remote host, I found that:
anonymous rsyslogd-2359: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/2359 ]
The command /usr/lib/nagios/plugings/check_disk -a 60 80 /dev/sda1 is working fine in the remote host.
A couple of things to check:
On the machine where you have NRPE installed, check the nrpe.cfg file. Make sure the allowed_hosts= line is uncommented and that its value includes the IP address of the Nagios server that's trying to connect to it. Make sure the dont_blame_nrpe line is uncommented and it's value is set to 1, i.e.: dont_blame_nrpe=1.
Restart nrpe.
If you have firewall rules enabled on this machine, make sure there's a rule to allow connections to tcp port 5666.
I have started the pgpool using the command
sudo pgpool -n &
it started giving the following message on the terminal:
2012-05-04 10:54:29 LOG: pid 4109: pgpool-II successfully started. version 2.3.2.1 (tomiteboshi)
But when I try to run the following command:
createdb -p 9999 bench_replication
I get the following error message:
createdb: could not connect to database postgres: could not connect to server: No such file or directory.
Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.9999"?
When I change the port from 9999 to 5432, a database bench_replication is created on the local node only, not on slave nodes. But, tutorial say to mention port 9999 in this command in order to create database bench_replication on all slave nodes through pgpool.
To confirm whether pgpool is really running or not, I stop the pgpool using command
2012-05-04 10:58:50 LOG: pid 4109: received smart shutdown request
stop request sent to pgpool. waiting for termination...done.
[1]+ Done sudo -A pgpool -n
which confirms the pgpool was actually running. What am I doing wrong? I have changed all my pgpool configuration file as mentioned in the standard tutorials on net.
Try this command :
createdb -p 9999 -h 127.0.0.1 bench_replication
By default PostgreSQL try to use the socket.
Late response but useful for future generations:
When you run
createdb -p 9999 bench_replication
under root, this generates the following error in log:
no pg_hba.conf entry for host "12.34.56.78", user "root", database
"postgres", SSL off
This means you should explicit mention username just like this:
createdb -U postgres -p 9999 bench_replication
Then you will get another error:
no pg_hba.conf entry for host "12.34.56.78", user "postgres", database
"postgres", SSL off
So you were blocked by second node on HBA level.
In this case either you should allow on second node access from first (in pg_hba.conf):
host all postgres 12.34.56.77 trust
or you should set password:
createdb -U postgres -p 9999 bench_replication -W SoMeP4Ssw0rD
If this is not clear enough - just check for your logs.