I updated my bind server from 9.11.8 to 9.11.13.The installation procedure was fine. And I installed it perfectly. But when I tried to start bind server then it failed every time.Then I view the message of /var/log/messages and I found following error:
/etc/named.conf:16: '127.0.0.1/8':address/prefix length mismatch '8'
Then I checked the named.conf file and there I saw I use 127.0.0.1/8 this IP address in the acl "trust-net" section.
But when I run 9.11.8 the setting was same and that run perfectly.
But after installation bind 9.11.13,I can't start my bind server.
Major Information:
-centos5.4(final)
acl conf:
acl trust-net { 127.0.0.1/8;};
Please help me out from this situation.
Related
my client machine has syslog-ng and my remote machine has rsyslog configuration.
my server/remote machine manages many clients and I need to differentiate which machine is sending which logs.
normally I would use syslog-ng on the server side but these machines aren't meant to have them.
Also would like to mention it isn't for apache or web servers just physical machines.
On the client's side
Tried altering and adding different options or changing them to yes/no respectively.
options {
keep_hostname(yes);
create_dirs(no);
use_dns(no);
};
for eg:keep_hostname to no, it worked but only when I changed the hostname to the machine's ip address. which is not what I want.
Using a template
template("$(ISODATE) $(FULLHOST_FROM) $(SOURCEIP) $(HOST) $(HOSTNAME) ${PROGRAM}: ${MESSAGE}\n")
output:
day time localhost abc[ID] .source.s_local SourceIP=127.0.0.1 localhost localhost (root) CMD (xyz.conf)#ID
this isn't the output I want, it is printing in the message section when I want it in the place of the "host" and I don't understand how the source ip is the loopback address.
Using structured logging
rewrite r_sourceip{
set('${SOURCEIP}' value(HOST));
};
log { source(s_local); rewrite(r_sourceip);destination(d_syslog_tcp); };
output:
and the ip is displayed in the logs as the loopback address instead of the machine ip.
day date time 127.0.0.1 syslog-ng.service: Succeeded.
Tried installing rsyslog on my client but it doesn't work
sudo add-apt-repository ppa:adiscon/v8-stable
sudo apt-get update
sudo apt-get install rsyslog
I kept running into many errors, fixing them was impossible due to the difference in OS version or type maybe.
add apt repository command not found
wget command not found
On the server's side
Using a template
which creates a folder with the client's hostname and stores the logs in that particular folder.
not the solution I want.
$template DynaFile,"/var/log/%FROMHOST-IP%/%syslogfacility-text%.log"
*.* -?DynaFile
I want the logs to appear as such
day date time `client's ip address` syslog-ng.service: Succeeded.
Can someone suggest me a solution and why I keep getting the loopback address as my client's ip?
I am installing a server using IIS 7, and I succeded to install it, and access it by localhost:80 or [my IP]:80. But when I use my smartphone, when I access to [my IP]:80, I get "localhost refused to connect: ERR_CONNECTION_REFUSED". What should I do to solve this error?
I tried to restart IIS, but it didn't work.
I tried to check the log file, but there was no error.
According to your description, I guess you may not add the ip address binding for your router.
I suggest you could try to add the both public ip and vitual ip into the binding and make sure your domain is right.
More details about how to add the binding, you could refer to below image:
I have the guest's HTTPS port set to 443 on it's Apache 2 installation.
In Vagrantfile
I have vm.forwarded_port set to forward from 443 to 8443
I have vm.hostname set to actualdomain.org
I've also installed the vagrant plugin install vagrant-hostsupdater so that actualdomain.org is written to my hosts file, so it pulls up the developer environment and not the actual site when it is requested.
List item
I ran vagrant connect...
I ran vagrant share --https 443 --domain actualdomain.org but it reports the following:
==> default: Detecting network information for machine...
default: Local machine address: 192.168.xx.10
default: Local HTTPS port: 443
==> default: Checking authentication and authorization...
==> default: Creating Vagrant Share session...
There was an error returned by the Vagrant Cloud server. The
error message is shown below:
Domain cannot be used with this account
But if I run vagrant share without the --domain parameter, I end up with the following in my logs when I try to contact the site remotely:
Hostname XXXXX-YYY-ZZZZ provided via SNI and hostname XXXXX-YYY-ZZZZ.vagrantshare.com provided via HTTP are different
And in the browser I am returned an HTTP 400 Bad Request.
Is there any easy way around this? It seems to me that this didn't happen the last time I used vagrant, and it seems as though there was something added to TLS that causes it to balk about the SNI error since then.
I even tried adding a server alias that was the same as the XXXXX-YYY-ZZZ.vagrantshare.com, and it still is giving me an issue; does that mean that I have to rebuild the certificate everytime the hashicorp URL changes if I want to show it off to somebody via their browser?
I'm on CentOS 7. I'm running this command:
wget http://wordpress.org/latest.tar.gz
This is the returned output:
--2016-09-08 15:53:04-- http://wordpress.org/latest.tar.gz
Resolving wordpress.org (wordpress.org)... 66.155.40.250, 66.155.40.249
Connecting to wordpress.org (wordpress.org)|66.155.40.250|:80... failed: Network is unreachable.
Connecting to wordpress.org (wordpress.org)|66.155.40.249|:80... failed: Network is unreachable.
I'm not sure why that might be. I have access to my local network from my machine; I can install yum packages without issue.
EDIT
Result of ip route get 66.155.40.249
RTNETLINK answers: Network is unreachable
My /etc/sysconfig/network-scripts/ifcfg-eno16777736 after I edited it:
TYPE=Ethernet
BOOTPROTO="static"
IPADDR=192.168.2.100
NETMASK=255.255.255.0
NM_CONTROLLED=no
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eno16777736
UUID=*random*
DEVICE=eno16777736
ONBOOT=yes
With the exception of my UUID... Specifically I added: bootproto, ipadder, netmask, and nm_controlled.
This situation happens when no entry in the routing table has been found.
If you're using a laptop (with wifi and ethernet) this may happen if you dhclient -r from one interface, which can remove the default route.
Easy resolution:
make a new dhcp request (optionally release the current lease)
add the default route by hand: ip route add default via <<GW ip>>. If you have several interfaces, you may need to specify the output interface using ip route add default via <<GW ip>> dev <<devname>> instead.
I am trying to setup a redis server following this guide to provide shared sessions for my Elastic Beanstalk.
I've installed redis on a new ec2 instance, and it's working fine, locally. However, when I tried to connect the project from my Beanstalk to my redis server, I am getting a "connection refused" error.
After some poking around, I found out that my redis only listens to local (I think?)
netstat -l
tcp 0 0 localhost:6379 *:* LISTEN
I have already out bind 0.0.0.0 to /etc/redis/6379.conf, but I suspect that redis is not reading the same configuration file.
My questions:
How do I check if my redis server is actually loading the configuration file? I tried typing spam into the file and sudo service redis_6379 restart expecting errors, but redis starts normally.
Is there another way for me to configure redis to listen to all connections from my VPC?
Edit: Found my answer.
To find out what configuration file is loaded: redis-cli -p 6379 info server
There's 2 parts of the configuration file that I need to change, firstly bind 0.0.0.0 and comment the bind 127.0.0.1 that comes after.
On Linux Ubuntu server 20.04 LTS I was running into a similar issue after reboot of the EC2 server, for me what resolved it (my nodeJs app was running as Ubuntu user I needed to make that path available) was to add to the PATH within /etc/crontab by:
sudo nano /etc/crontab and just comment out the original path in there so you can switch back if required (mine was: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin ) and replace it with:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/ubuntu/.nvm/versions/node/v12.20.0/bin and that error disappeared for me