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
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 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
Digitalocean disabled my droplet's internet access. After fixing the error (rollback to older backup) they restored the internet access. But afterwards I constantly get an error when deploying, I can't seem to get my Postgres database up and running.
I'm getting an error each time I try to deploy my application.
PG::ConnectionBad: 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.5432"?
So I used SSH to login to my server and check if my Postgres was actually running with:
pg_lsclusters
Results into:
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5432 down postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
Postgres server status
So my Postgres server seems to be down. I tried putting it 'up' again with:
pg_ctlcluster 9.5 main start After doing so I got the error: Insecure directory in $ENV{PATH} while running with -T switch at /usr/bin/pg_ctlcluster line 403.
And /usr/bin/pg_ctlcluster on line 403 says:
system 'systemctl', 'is-active', '-q', "postgresql\#$version-$cluster";
But I'm not to sure what the problem could be here and how I could fix this.
Update
I also tried updating the permissions on /bin to 755 as mentioned here. Sadly that did not fix my problem.
Update 2
I changed the /usr/bin to 755. Now when I try pg_ctlcluster 9.5 main start, I get this:
Job for postgresql#9.5-main.service failed because the control process exited with error code. See "systemctl status postgresql#9.5-main.service" and "journalctl -xe" for details.
And inside the systemctl status postgresql#9.5-main.service:
postgresql#9.5-main.service - PostgreSQL Cluster 9.5-main
Loaded: loaded (/lib/systemd/system/postgresql#.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-01-28 17:32:38 EST; 45s ago
Process: 22473 ExecStart=postgresql#%i --skip-systemctl-redirect %i start (code=exited, status=1/FAILURE)
Jan 28 17:32:08 *url* systemd[1]: Starting PostgreSQL Cluster 9.5-main...
Jan 28 17:32:38 *url* postgresql#9.5-main[22473]: The PostgreSQL server failed to start.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Control process exited, code=exited status=1
Jan 28 17:32:38 *url* systemd[1]: Failed to start PostgreSQL Cluster 9.5-main.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Unit entered failed state.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Failed with result 'exit-code'.
Thanks!
You better not mix systemctl and pg_ctlcluster. Let systemctl makes the calls to pg_ctlcluster with the right user and permissions. You should start your postgresql instance with
sudo systemctl start postgresql#9.5-main.service
Also, check the errors in the startup log. You can post them too, to help you figure out what's going on.
Your systemctl status also outputs that the service is disable, so, when the server reboots, you will have to start the service manually. To enable it run:
sudo systemctl enable postgresql#9.5-main.service
I hope it helps
It is mainly because /etc/hosts file is somehow changed.I have removed extra space inside /etc/hosts file.Use cat /etc/hosts
Add these lines into the file
127.0.0.1 localhost
127.0.1.1 your-host-name
::1 ip6-localhost ip6-loopback
And I have given permission 644 to /etc/hosts file.It is working for me even after the reboot of the system.
I'm trying to apply the timezone Europe/Berlin on a Raspberry PI running the Debian-based Raspbian.
sudo dpkg-reconfigure tzdata
returns
Current default time zone: 'Europe/Berlin'
Local time is now: Sun Jun 25 20:26:51 CEST 2017.
Universal Time is now: Sun Jun 25 18:26:51 UTC 2017.
but
sudo date
still returns the British Summer Time (BST) instead of the Europe/Berlin Central European Summer Time (CEST)
Sun Jun 25 19:26:55 BST 2017
If there is internet connection available follow the steps to set the
date/time:
sudo raspi-config
Internationalization options
Change Time Zone
Select geographical area
Select city or region.
Reboot your pi.
This way, you will have accurate time. Need not set the date again for every boot.
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.