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.
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 am trying to turn on my TV using a Raspberry Pi.
I have followed the below instructions and added my remote config file, however, am having no luck! Any suggestions.
When running sudo /etc/init.d/lircd status, I get
lircd.service - Flexible IR remote input/output application support
Loaded: loaded (/lib/systemd/system/lircd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-11-11 13:27:07 UTC; 5min ago
Docs: man:lircd(8)
http://lirc.org/html/configure.html
Main PID: 334 (lircd)
CGroup: /system.slice/lircd.service
└─334 /usr/sbin/lircd --nodaemon
Nov 11 13:32:23 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:23 raspberrypi lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:42 raspberrypi lircd[334]: lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:42 raspberrypi lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:42 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:42 raspberrypi lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:54 raspberrypi lircd[334]: lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:54 raspberrypi lircd-0.9.4c[334]: Notice: accepted new client on /var/run/lirc/lircd
Nov 11 13:32:54 raspberrypi lircd[334]: lircd-0.9.4c[334]: Info: removed client
Nov 11 13:32:54 raspberrypi lircd-0.9.4c[334]: Info: removed client
Here are the steps I took to set it up.
# Add the following lines to /etc/modules file
lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17
# Add the following lines to /etc/lirc/hardware.conf file
LIRCD_ARGS="--uinput --listen"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
# Update the following line in /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17
# Update the following lines in /etc/lirc/lirc_options.conf
driver = default
device = /dev/lirc0
$ sudo /etc/init.d/lircd stop
$ sudo /etc/init.d/lircd start
# Check status to make lirc is running
$ sudo /etc/init.d/lircd status
# Reboot before testing
$ reboot
Just run into the same problem. There are two main parts to it:
Part 1: new LIRC config
With the new version on lirc 0.9.0+, the configuration needed is much less:
The driver is already included in the kernel, no need to edit anything in modules
The new config syntax is much different, there's a shell script provided to change an old config to the new one. Run: sudo /usr/share/lirc/lirc-old2new.sh
To summarise, you only need to change the /etc/lirc/lirc_options.conf. In particular, you need to edit the lines to driver = default AND device = /dev/lirc0.
This should solve part 1.
Part 2: new IR drivers
As you can see in the /boot/overlays/README, the LIRC driver is being outdated. There are new ones provided for IR input and output. The driver for IR output is the new gpio-ir-tx. You need to use that instead of lirc-rpi in your /boot/config.txt.
In summary, change dtoverlay=lirc-rpi,gpio_out_pin=17,gpio_in_pin=13 to
dtoverlay=gpio-ir-tx,gpio_pin=17
NOTE the missing _out in the config. This driver only supports output, so no need for an input one. To handle inputs, use the gpio-ir one.
After some time the Postgres database stopped working of my live server. I'm working on this server from last 8 months. Now suddenly it's stopped working.
when I try to enter the command, psql produces an error
psql: 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"?
enter image description here
I'm using odoo8.
First, you need to make sure the socket file is located in /var/run/postgresql/.s.PGSQL.5432. To check that
$ cat /var/run/postgresql/.s.PGSQL.5432
if result shows something, then the problem is anything else. But, if file is not there you need to check /tmp dir (specially for OSX Homebrew users)
$ cd /tmp
$ l
total 16
drwxrwxrwt 7 root wheel 224B Mar 11 08:03 .
drwxr-xr-x 6 root wheel 192B Jan 23 18:35 ..
-rw-r--r-- 1 root wheel 65B Nov 7 22:59 .BBE72B41371180178E084EEAF106AED4F350939DB95D3516864A1CC62E7AE82F
srwxrwxrwx 1 shiva wheel 0B Mar 11 08:03 .s.PGSQL.5432
-rw------- 1 shiva wheel 57B Mar 11 08:03 .s.PGSQL.5432.lock
drwx------ 3 shiva wheel 96B Mar 10 17:11 com.apple.launchd.C1tUB2MvF8
drwxr-xr-x 2 root wheel 64B Mar 10 17:10 powerlog
Now, there are two ways you can solve the error
Solution One
You can change the application configuration to see for sockets at /tmp/.s.PGSQL.5432
For Rails Users
# config/database.yml
default: &default
adapter: postgresql
pool: 5
# port:
timeout: 5000
encoding: utf8
# min_messages: warning
socket: /tmp/.s.PGSQL.5432
Solution Two
You can create symlinks to the expected location
$ sudo mkdir /var/pgsql_socket
$ sudo ln /tmp/.s.PGSQL.5432 /var/pgsql_socket/
Then the error should go.
Hope this helps.
Note: Your default socket directory may not be /tmp
Did you update/upgrade your database?
Did you start a docker container that interfered with any of your data-store/socket file locations?
This probably doesn't fit your situation exactly, but maybe it will provide some insight:
Sometimes when you try
sudo systemctl start postgresql.service
and the systemd status says it is started but you still get that error message when trying to connect, try this instead:
sudo pg_ctlcluster <version> <cluster> <action>
which in my case had been
sudo pg_ctlcluster 13 main start
I'm on CentOS 7 and I'm trying to get through the 'PG::ConnectionBad: FATAL: Peer authentication failed for user' error.
So I've already figured out that I should change pg_hba.conf (peer to md5) and I've done it. It seems that I have to restart postgres but it is not so easy as I thought.
I tried 'service postgresql restart' which resulted in 'Failed to restart postgresql.service: Unit not found.'
Then tried to install posgresql-server. Got:
oct 23 01:16:15 serverct1 pg_ctl[3280]: HINT: Is another postmaster already running on port 5432? If ...try.
oct 23 01:16:15 serverct1 pg_ctl[3280]: WARNING: could not create listen socket for "localhost"
oct 23 01:16:15 serverct1 pg_ctl[3280]: FATAL: could not create any TCP/IP sockets
oct 23 01:16:16 serverct1 pg_ctl[3280]: pg_ctl: could not start server
oct 23 01:16:16 serverct1 systemd[1]: postgresql.service: control process exited, code=exited status=1
oct 23 01:16:16 serverct1 systemd[1]: Failed to start PostgreSQL database server.
About 5432 port usage:
postgres 5432/tcp postgresql # POSTGRES
postgres 5432/udp postgresql # POSTGRES
So I'm curious:
1) Do postgresql and postgresql-server work separately?
2) Is it possible to restart posgresql without postgresql-server?
3) If not - how to get the port 5432 free in order to run postgresql-server?
You can avoid troubles with serverct1 if you use standard postgres pg_ctl, eg:
pg_ctl reload
Or if needed pg_ctl reload -D $PGDATA
You dont need to restart the postgres for pg_hba changes to apply: https://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html
The pg_hba.conf file is read on start-up and when the main server
process receives a SIGHUP signal. If you edit the file on an active
system, you will need to signal the postmaster (using pg_ctl reload or
kill -HUP) to make it re-read the file.
Good day!
After installing and running kolab letters delivered instantly. But after a few days letters to local destinations have become delivered with a delay. Over time, they are delivered, but the delay may be several hours. An example of the path of the letter:
root#myhost:~# cat /var/log/mail.log | grep 7AA7935B1FC
Jan 12 11:31:03 myhost postfix/smtpd[19494]: 7AA7935B1FC:
client=localhost[127.0.0.1]
Jan 12 11:31:05 myhost postfix/cleanup[19492]: 7AA7935B1FC:
message-id=<20160112093103.7AA7935B1FC#mail.myhost.com>
Jan 12 11:31:05 myhost postfix/qmgr[7021]: 7AA7935B1FC:
from=<noreply#myhost.com>, size=1279, nrcpt=3 (queue active)
Jan 12 11:31:05 myhost lmtpunix[19631]: Delivered:
<20160112093103.7AA7935B1FC#mail.myhost.com> to mailbox:
myhost.com!user.user1
Jan 12 11:31:06 myhost postfix/lmtp[19617]: 7AA7935B1FC: to=<user1#myhost.com>, relay=mail.myhost.com[/var/lib/imap/socket/lmtp], delay=2.6, delays=2/0.01/0/0.59, dsn=4.3.0, status=deferred (host
mail.myhost.com[/var/lib/imap/socket/lmtp] said: 421 4.3.0 lmtpd:
failed to mmap /var/lib/imap/deliver.db.NEW file (in reply to end of
DATA command))
Jan 12 11:31:06 myhost postfix/lmtp[19617]: 7AA7935B1FC: to=<user2#myhost.com>, relay=mail.myhost.com[/var/lib/imap/socket/lmtp], delay=2.7, delays=2/0.01/0/0.68, dsn=4.4.2, status=deferred (lost connection with mail.myhost.com[/var/lib/imap/socket/lmtp] while sending end of data
-- message may be sent more than once
Jan 12 11:31:07 myhost postfix/lmtp[19617]: 7AA7935B1FC: to=<user3#myhost.com>, relay=mail.myhost.com[/var/lib/imap/socket/lmtp], delay=2.7, delays=2/0.01/0/0.68, dsn=4.4.2, status=deferred (lost connection with mail.myhost.com[/var/lib/imap/socket/lmtp] while sending end of data
-- message may be sent more than once)
Currently mailq features a variety of messages in queue. An example of one of these:
7BBDF35B123 6162 Tue Jan 12 13:19:24 user#rambler.ru (delivery temporarily suspended: lost connection with mail.myhost.com[/var/lib/imap/socket/lmtp] while sending end of data -- message may be sent more than once) user4#myhost.com
-- 11667 Kbytes in 327 Requests.
I think that the main reason is described here:
lmtp: failed to mmap /var/lib/imap/deliver.db.NEW file
But, unfortunately, not been able to find a solution.
The problem was solved according to this recommendation: http://lists.kolab.org/pipermail/users-de/2015-May/001998.html
Stop Services cyrus-imap and postfix
Delete files deliver.db.NEW and deliver.db in the directory /var/lib/imap/
Start the services and the file deliver.db is automatically created
Restart the queue: postsuper -r ALL
Some of the letters delivered from the queue again.
Proposed cause: after installing and start services on the new server users download messages en masse in the format *.eml, downloaded from the last post. Perhaps these actions somehow overflowed index files.
P.S.: Unfortunately, the solution was temporary: the situation described above is repeated periodically :(