I have a setup of sensu core(single server with muliple clients).
I am facing the issue like - 'No keepalive sent from client for 7807 seconds (>=180)' from multiple clients though they instances are alive.
I've checked the time in both client and server instances. It does not have much variations(only in secs). I tried to install ntpdate on both instances.
[root#client-machine user]# ntpdate pool.ntp.org
31 Aug 14:07:50 ntpdate[14158]: the NTP socket is in use, exiting
[root#server-machine:/home/user]# ntpdate pool.ntp.org
31 Aug 14:08:04 ntpdate[29031]: the NTP socket is in use, exiting
At intermittently, status in uchiwa shows green for this client-machine and it automatically goes to RED for further checks
Kindly advise to get rid of this problem!
I had the same issue. Resolved it by first setting the timezone and then installing the following packages
date
timedatectl set-timezone Europe/Dublin
yum -y install chrony
timedatectl set-ntp true
Related
I installed Kali Linux via VMware and did a full system upgrade:
apt-get update
apt-get upgrade
apt-get full-upgrade
As part of the upgrade postgresql upgraded from v11 to v12. I followed the instructions to finish this part of the upgrade:
pg_dropcluster 12 main --stop
pg_upgradecluster 11 main
pg_dropcluster 11 main
I start postgresql, initialize metasploit, and start Armitage:
/etc/init.d/postgresql start
msfdb init
armitage
The only console output appears unrelated:
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
I do get the popup box with the connection information. I found that I get the "Unexpected end of file from server" if I use 'localhost' as the host, so - per their instructions - I change it to the external IP (in this case 192.168.9.134). I checked metasploit-framework/config/database.yml for
the port and login credentials.
After clicking 'Connect' with this information I get a connection window stating:
Connecting to 192.168.9.134:5432 Connection refused (Connection
refused)
There's also the progress bar that over time will completely fill up (unless I click 'Cancel'). After which nothing happens. As I run the command from the terminal I can see that the process is still running (I don't get my prompt back) but the window disappears and Armitage doesn't actually start. The log file, as verified by pg_lsclusters (/var/log/postgresql/postgresql-12-main.log) doesn't is actually empty.
The link I mentioned before suggests that the problem could either be not enough RAM (I set the VM to have 4gb and free -m shows):
total used free shared buff/cache available
Mem: 3964 803 2677 29 483 2787
Swap: 4093 0 4093
Or that the Metasploit RPC daemon never started (that window does come up the first time, but not subsequent times). I verified that it's running via msfdb status:
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (exited) since Fri 2020-02-07 16:06:52 EST; 19min ago
Process: 1753 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 1753 (code=exited, status=0/SUCCESS)
Feb 07 16:06:52 kali systemd1: Starting PostgreSQL RDBMS... Feb 07
16:06:52 kali systemd1: Started PostgreSQL RDBMS.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME postgres
1735 postgres 3u IPv6 32516 0t0 TCP localhost:5432 (LISTEN)
postgres 1735 postgres 4u IPv4 32517 0t0 TCP localhost:5432
(LISTEN)
UID PID PPID C STIME TTY STAT TIME CMD postgres 1735
1 0 16:06 ? Ss 0:00 /usr/lib/postgresql/12/bin/postgres -D
/var/lib/postgresql/12/main -c
config_file=/etc/postgresql/12/main/postgresql.conf
[+] Detected configuration file
(/usr/share/metasploit-framework/config/database.yml)
Also, running regular Metasploit appears to work fine (msfconsole) and loads without error (not sure if there's any output that would be helpful here). I don't use postgresql directly, so I haven't messed with any configuration nor do I have any other applications (that I'm aware of) that use it, so it should be a pretty clean setup (not to mention this is a fresh install of Kali Linux). I'm out of ideas for what to check next. An online search didn't seem to match this problem well. Any thoughts?
Armitage has been deprecated for some time now, as it has not been updated since 2015, and is (to some extent) incompatible with current versions of metasploit.
Although this may not fix your problem, I suggest not using software this much out of date.
I've been trying to set up the correct date in my Beaglebone Black but the solutions I've tried are not permanent, everytime I poweroff the Beagle and power on later, the date is wrong again.
So this is what initially looks like:
root#beaglebone:~# date
Sat May 21 17:48:28 CDT 2016
Then I installed ntp and ntpdate
root#beaglebone:~# apt-get install ntp ntpdate
Reading package lists... Done
Building dependency tree
Reading state information... Done
ntp is already the newest version.
ntpdate is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
After that I edit the ntp.conf file like this
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
...
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
restrict 192.168.0.11 mask 255.255.255.0 nomodify notrap
The next step was
root#beaglebone:~# rm /etc/localtime
root#beaglebone:~# ln -s /usr/share/zoneinfo/America/Mexico_City /etc/localtime
After that I was supposed to enable the ntp service with
root#beaglebone:~# systemctl enable ntpdate.service
Failed to enable unit: No such file or directory
or
root#beaglebone:~# service ntpdate start
Failed to start ntpdate.service: Unit ntpdate.service not found.
I couldn't continue with thas because I don't have the ntp.service file so then I tried this
root#beaglebone:~# timedatectl set-ntp true
root#beaglebone:~# timedatectl status
Local time: Sat 2016-05-21 18:16:10 CDT
Universal time: Sat 2016-05-21 23:16:10 UTC
RTC time: Sat 2016-05-21 23:16:11
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
root#beaglebone:~# nano /etc/systemd/timesyncd.conf
[Time]
NTP=0.north-america.pool.ntp.org 1.north-america.pool.ntp.org 2.north-america.pool.ntp.org 3.north-america.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
Finally I reboot and seems to work
root#beaglebone:~# timedatectl status
Local time: Sun 2017-09-10 23:32:28 CDT
Universal time: Mon 2017-09-11 04:32:28 UTC
RTC time: Mon 2017-09-11 04:32:28
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
But then again, after poweroff the time sets itself back to May 21st, 2016. I even tried set and sync the clock manually with hwclock --set --date "date" --localtime and systohc but after poweroff the result is the same.
Am I missing something or doing something wrong?
I also change 'UTC' to 'LOCAL' in /etc/adjtime and time goes back to May 2016.
Thanks.
Try this:
dpkg-reconfigure tzdata
This should work. A prompt appears and you can configure it with a graphical interface. It is as easy as America and enter. And then, you can pick your time zone, too.
Seth
ubuntu 16.04 server. My first ubuntu, so yeah, ubuntu newbie factor.
System time on server is about 17 minutes fast. I can reset it many various ways successfully at the command line. In every case, within 15 or so seconds, it will be reset to the wrong time again. systemd seems to be at the root of it. In message log:
systemd[20113]: Time has been changed
I assumed the culprit was timedatectl. Made sure to disable and check:
root#portal:~# systemctl status systemd-timesyncd.service
â systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
ââdisable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
root#portal:~# systemctl list-units|grep 'time-sync'
root#portal:~#
This:
root#portal:~# ntpdate -s 0.north-america.pool.ntp.org
root#portal:~# journal -f
Results in this:
Dec 08 20:04:18 portal sudo[4486]: pam_unix(sudo:session): session opened
for user root by owen(uid=0)
Dec 08 19:46:44 portal systemd[2814]: Time has been changed
Dec 08 19:46:44 portal ntpdate[4502]: step time server 171.66.97.126 offset -1098.814353 sec
Dec 08 20:05:35 portal systemd[2814]: Time has been changed
Notice the timestamp of each log entry...
What, pray tell, is resetting the time and where is it getting the ntp server setting, and why is it wrong??? I thought the large drift might be part of the issue, but it doesn;t match up with the number of minutes it's off...
TIA
FTR, this turned out to be the date on the virtual server being wrong. I had checked the hardware server itself and it was accurate, but the date/time via vmware was off a weird increment. Once I corrected this, everything settled down.
While trying to run a puppet update form a node:
sudo /opt/puppetlabs/bin/puppet agent -t
I get an error:
Error: Could not retrieve catalog; skipping run
Error: Could not send report: Connection refused - connect(2) for "puppet" port 8140`
Elsewhere indicates this is likely a problem with the puppetserver service, and suggests to reboot the server. Restarting didn't help, and when I try to restart the service I get failure:
~$ sudo service puppetserver restart
Job for puppetserver.service failed because the control process exited with error code. See "systemctl status puppetserver.service" and "journalctl -xe" for details.
I've looked at these logs, and as a puppet/linux noob, I'm not sure what to do next.
systemctl status puppetserver.service
● puppetserver.service - puppetserver Service
Loaded: loaded (/lib/systemd/system/puppetserver.service; enabled; vendor preset: enabled)
Active: activating (start-post) since Fri 2016-09-02 15:54:26 PDT; 2s ago
Process: 22301 ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver (code=exited
Main PID: 22306 (java); : 22307 (bash)
Tasks: 17
Memory: 335.7M
CPU: 5.535s
CGroup: /system.slice/puppetserver.service
├─22306 /usr/bin/java -Xms6g -Xmx6g -XX:MaxPermSize=256m -XX:OnOutOfMemoryError=kill -9 %p -Djava.security.egd=/dev/urandom -cp /opt/p
└─control
├─22307 /bin/bash /opt/puppetlabs/server/apps/puppetserver/ezbake-functions.sh wait_for_app
└─22331 sleep 1
Sep 02 15:54:26 puppet systemd[1]: Starting puppetserver Service...
Sep 02 15:54:26 puppet java[22306]: OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
puppet version 4.6.1
The puppet master communicates with the other node using port number 8140.
I don't think a restart will help, since this looks like a connection issue between the server and the node.
please try the following -
first make sure that the puppet master is actually listening on port 8140. run the following command on the puppetmaster -
netstat -ntlp | grep 8140
this command should return something like this -
tcp 0 0 0.0.0.0:8140 0.0.0.0:* LISTEN 1783/puppetmaster
If you don't get the same output, your puppetmaster is not listening, and therefore can not compile catalogs for the node.
Try checking the puppet master log at /var/log/puppetmaster.log
check that the node can communicate with the puppetmaster on the relevant port. you can check this quickly with the telnet command. run this on your node -
telnet < puppetmaster ip address \ dns name> 8140
you should get something like -
Connected to <puppet-master-IP/DNS-name>
Escape character is '^]'.
if you don't get this output, this means that something is blocking you from accessing the puppetmaster. try opening the port in your firewall to access the puppetmaster.
if you're still stuck try using the --debug flag for verbose output and edit your question.
Could be 2 things: (1) in puppet.conf you have configured more memory than you have on your machine. Or (2) You installed both apt-get install puppetserver and apt-get install puppet.
If you get failed to start puppet.service: unit not found. error on slave machine while connecting to puppet.
Close the putty and then again open and connect it.The issue wont come while starting putty on slave.
The error occurs because there is not enough RAM and to fix the error, open the Puppet server configuration file:
sudo nano /etc/sysconfig/puppetserver
And reduce the amount of allocated RAM for the Puppet server (for example, I specified 512m instead of 2g):
JAVA_ARGS="-Xms512m -Xmx512m"
Now let’s start the Puppet server:
sudo systemctl start puppetserver
Closed. This question is not about programming or software development. 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 last month.
Improve this question
This is a very annoying problem that i am having with the rndc reload
I am getting the following error:
rndc: connect failed: 127.0.0.1#953: connection refused
However the following work fine,
[root#cbgfx ~]# service named restart
Stopping named: . [ OK ]
Starting named: [ OK ]
[root#cbgfx ~]# tail -f /var/log/messages
Aug 7 12:51:09 cbgfx named[31990]: zone 120.88.167.in-addr.arpa/IN: loaded serial 14
Aug 7 12:51:09 cbgfx named[31990]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Aug 7 12:51:09 cbgfx named[31990]: zone domain.com/IN: domain.com/MX 'mail.servergreek.com' has no address records (A or AAAA)
Aug 7 12:51:09 cbgfx named[31990]: zone domain.com/IN: loaded serial 14
Aug 7 12:51:09 cbgfx named[31990]: zone localhost.localdomain/IN: loaded serial 0
Aug 7 12:51:09 cbgfx named[31990]: zone localhost/IN: loaded serial 0
Aug 7 12:51:09 cbgfx named[31990]: managed-keys-zone ./IN: loaded serial 4
Aug 7 12:51:09 cbgfx named[31990]: zone domain.com/IN: sending notifies (serial 14)
Aug 7 12:51:09 cbgfx named[31990]: zone 120.88.167.in-addr.arpa/IN: sending notifies (serial 14)
Aug 7 12:51:09 cbgfx named[31990]: running
The vps has ipv6 ip address, is there anything i missed here?
Thanks in advance guys
I fixed it myself , it was a permission and ownership issue.To fix it you need to execute those ssh commands
Fix rndc connection refused error
chown root:named /etc/rndc.key
chmod 640 /etc/rndc.key
clear the file of directory /var/cache/bind/ and after in terminal bash
/etc/bind/bind9 restart
The problem might not only be in rndc.key.
The easiest way to detect is running:
service named restart
Check if there is any error, if there is an error, run:
systemctl status named.service
Check any permission denied error. It could be in the log files as well.
In my case as bsentosa comment I needed start process named, you can enable to named start together within system
$ systemctl enable named
I am on Mac OS X (Ventura), with Bind9 installed through Brew. I ran into the same issue. I had to run named with sudo to make this error disappear: It was an ownership issue.
Also, you should pay attention to named logs, sometimes you have just errors in your *.zone file.
I hope it will help Mac users landing here.