there i wanted to define dhcp reservations in dnsmasq in a separate file with "dhcp-hostsfile" option.
So i added dhcp-hostsfile=PATH_TO_FILE/dhcp.hosts in my dnsmasq.conf.
I then added dhcp reservations in dhcp.hosts e.g.:
dhcp-host=44:03:2c:11:ca:9e,192.168.1.101,set:lan,rpi
On dnsmasq start i keep getting
dnsmasq: bad hex constant at line 1
So the file dhcp.hosts gets read but i don't find an error, i checked mac adress and changed the case and i tested simpler versions of the reservation, still the same result.
So i took the line and pasted it in general dnsmasq.conf - and it suprisingly worked.
Does anybody have a clue whats wrong here?
I tested this with latest alpine linux & dnsmasq in a docker container on a raspberry pi.
Cheers
found it in the end:
if dnsmasq uses extra dhcp files one is not allowed to add "dhcp-host=" to the entries.
so for example only "44:03:2c:11:ca:9e,192.168.1.101,set:lan,rpi" and it works
Related
I expect to be able to resolve the DNS name www.foobar.dev using a DNS server that's running in a VM on my OS/X (High Sierra) system because I have created an /etc/resolver/dev file containing the following one line: (specifying the VM's virtual address)
nameserver ww.xx.yy.zz
... but dig www.foobar.dev continues to consult the Internet nameserver,
while dig #ww.xx.yy.zz www.foobar.dev successfully retrieves the entry from the VM's DNS.
I've used the dscacheutil command to be sure that an errant entry is not in the DNS resolver cache.
So, why isn't the presence of an /etc/resolver/dev file with the specified contents sufficient to direct "anything.dev" to the specified DNS server?
Interestingly – sometimes it seems to work. Also, the command scutil --dns produces the following expected entry, which seems to indicate that the /etc/resolver/dev file is being detected!
resolver #8
domain : dev
nameserver[0] : ww.xx.yy.zz
flags : Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
It's probably working fine, you're just testing it wrong. dig (and host and nslookup) don't use the system resolver, nor do they fully implement the system resolver's lookup policy. As a result, they're useful for testing the DNS system itself, but not for testing how the OS uses DNS. The official way to test the system resolver is dscacheutil (e.g. dscacheutil -q host -a name www.foobar.dev), but that's annoyingly verbose, so I tend to just use ping and look at the IP it reports.
As #GordonDavisson in other answer said - ping command is useful for the system resolver testing. My addition is that it also may fail because of DNS cache. Do not forget to clear it:
sudo killall -HUP mDNSResponder
Better replace /etc/resolver files with true DNS config, as just like /etc/resolv.conf this is all legacy stuff kept only for backward compatibility (and maybe because POSIX requires it?).
Here's how you can do it from command line using scutil, it's really simple.
Of course, there is also a programmatic interface to all this.
See Apple's SystemConfiguration Framework.
I'm having trouble connecting to a replica set.
[MongoDB\Driver\Exception\ConnectionTimeoutException]
No suitable servers found (`serverSelectionTryOnce` set):
[Server closed connection. calling ismaster on 'a.mongodb.net:27017']
[Server closed connection. calling ismaster on 'b.mongodb.net:27017']
[Server closed connection. calling ismaster on 'c.mongodb.net:27017']
I however, can connect using MongoChef
Switching any localhost references to 127.0.0.1 helped me. There is a difference between localhost and 127.0.0.1
See: localhost vs. 127.0.0.1
MongoDB can be set to run on a UNIX socket or TCP/IP
If all else fails, what I've found that works most consistently across all situations is the following:
In your hosts file, make sure you have a name assigned to the IP address you want to use (other than 127.0.0.1).
192.168.0.101 coolname
or
192.168.0.101 coolname.somedomain.com
In mongodb.conf:
bind_ip = 192.168.0.101
Restart Mongo
NOTE1: When accessing mongo from the command line, you now have to specify the host.
mongo --host=coolname
NOTE2: You'll also have to change any references to either localhost or 127.0.0.1 to your new name.
$client = new MongoDB\Client("mongodb://coolname:27017");
I had the same error in a docker based setup:
container1: nginx listening on port 80
container2: php-fpm listening on port 9000
container3: mongodb listening on port 27017
nginx forwarding php to php-fpm
Trying to access mongodb from php gave this error.
In the mongodb Dockerfile, the culprit was:
CMD ["mongod", "--bind_ip", "127.0.0.1"]
Needed to change it to:
CMD ["mongod", "--bind_ip", "0.0.0.0"]
And the error went away. Hope this helps somebody.
The IP address of your home network may have changed, which would lead to MongoDB locking you out.
I solved this problem for myself by going to MongoDB Atlas and changing which IP address is allowed to connect to my data. Originally, I'd set it up to only allow connections from my home network. But my home network IP address changed, and I started getting the same error message as you.
To check if this is the same issue with you, go to MongoDB Atlas, go into your project, and click "Network Access" on the left hand side of the screen. That's where you're able to update your IP address. It shows you what IP address(es) it's allowing in. To find out what your current IP address is, go to whatismyipaddress.com and update MongoDB if it's different.
In my case, I am temporarily coding PHP from Windows7 against MongoDB on my VPS running Linux Debian 9. The PHP will be eventually running in the same Linux box to provide an API to the MongoDB data.
BTW, it does not appear this local composer install is doing me any good, it's pure ugliness. My PHP after the fix below works without the require line require_once 'C:\Users\<Windows User Name>\vendor\autoload.php'.
My fix is different than the accepted answer which to me did not make sense.
I did not have to touch any hosts file
So edit your /etc/mongod.conf with your target machine's IP and restart with sudo systemctl restart mongod that's it
I don't know what to blame
PHP and MongoDB sites for the terrible documentation skimpy and incomplete PHP examples, or...
MongoDB installation on Linux failing to mention this bindIP.
My startup experience with MongoDB is so far very negative given all the changes that have occurred nothing matches what I expected from the videos I watched. I can't seem to find any that reflect what I am going thru like
$DB_CONNECTION_STRING="mongodb://user:password#164.152.09.84:27017"
$m = new MongoDB\Driver\Manager( $DB_CONNECTION_STRING )
instead of
$m = new MongoClient()
Hope this helps someone
PS. Always say NO to semicolons, camelCAsE and anything case-sensitive... absurdity at its best.
I'm trying to view php files locally on my mac.
I'm running Yosemite.
I have MAMP installed on my computer. When I press start the MySQL server starts but Apache doesn't. An error message appears saying 'Error. Apache couldn't be started. Please check your MAMP installation'
I've gone through the internet typing stuff into terminal and changing 'envvars' to '_envvars' but nothing works.
I reinstalled OSX and that worked but when I shut down the computer the problem occurs again.
Can anyone help?
Thanks
Check if you changed the Document Root Location or Renamed it. At least this was my mistake.
MAMP > Preferences > Web Server > Document Root
I didn't get it working with port 8000 or the default 8888, but did get it working with port 80 per the suggestion here:
http://forums.macrumors.com/showthread.php?t=1744944
That didn't work after all, but it didn't error out. However I manually ran the following at the command line (because log file was empty):
sudo /Applications/MAMP/Library/bin/apachectl start
Only to find that after upgrading I was missing the mod_example.so
httpd: Syntax error on line 83 of /Applications/MAMP/conf/apache/httpd.conf: Cannot load /Applications/MAMP/Library/modules/mod_example.so into server: dlopen(/Applications/MAMP/Library/modules/mod_example.so, 10): image not found
Copied it from my old install and I was good to go.
If you try to start the server from the terminal, likely that will tell you what is wrong e.g.
sudo /Applications/MAMP/bin/startApache.sh
Password:
(48) Address already in use: make_sock: could not bind to address [::]:8888
(48) Address already in use: make_sock: could not bind to address 0.0.0.0:8888
no listening sockets available, shutting down
Unable to open logs
What you can do in this case, I was inadvertently running a Blockstack browser out of 8888, so changing MAMP to 8887 allowed it to start. [Your mistake might be different.]
Had the same problem, nothing in the logs. After trying the_dillio's suggestion:
sudo /Applications/MAMP/Library/bin/apachectl start
I got an error that pointed back to my vhosts file. It turns out I had an extra /VirtualHost tag. Removed it and it started working again.
i've solved this issue using this command in the terminal :
sudo apachectl stop
I think I've found the solution.
It was the wrong port. I altered the .conf file in the Apache folder. I changed all instances of port 8888 to 8000. When I run MAMP now it all seems to work fine.
Thanks for your help
Also be aware that if you by any chance deleted the folder that was set as Document Root the last time you were using MAMP, you will get this error. Simply open MAMP again, change Document Root to a location that does exist and start the servers.
I received the same error but interestingly it was caused simply because I renamed the root folder and didn't realize it. Sounds like you have a different issue but for anyone else who gets this error message, make sure you haven't renamed the root!
Absolutely bizarre behavior for MAMP PRO (paid license too btw...)
In my case I had to change the location of the log file in order to get it to work...
Click on Mysql icon then the little folder to the right of the path and try changing it to something else.
For MAMP :
You can open the terminal and write:
ps aux | grep mysql
lsof -i
killall -9 mysqld
I hope is good for you!
Bye
I had this experience when upgrading to V4. It tried to used the files from my previous installation and it just never worked. The workaround was to RENAME the original MAMP installation to something different than "MAMP", install brand new version and then copy files you may need like VHOST configs and DATABASES. After all this it worked just fine.
My Apache server problem arose after I enabled SSL. So if this is your case, check your https-ssl.conf file (Applications -> Mamp -> conf -> apache -> extra). The Document Root under the Virtual Host settings had a different file path for htdocs than where it was actually located (easily overlooked). I changed this to "/Applications/MAMP/htdocs" and problem solved. Perhaps also check Document Root in your https.conf file (Applications -> Mamp -> conf -> apache) to see if it has the correct file path to htdocs too.
These are the steps I used to solve this issue.
Checking vcredist that are required and installing them. to check which are the missing vcredist I used a tool called "check_vcredist" from wamp.
I also installed latest Microsoft Visual C++ Redistributable x64.
Doing this steps solved my issue of Apache server not running
upon running Comodo Cleaning Essentials found Modified Hosts Threat Warning, checked file in WINDOWS\system32\drivers\etc and to my surprise three undefined characters were added after localhost:
http://i60.tinypic.com/2d1s6wz.jpg
(see image), are these just unnecessary spaces or what could have generated this change in hosts file?
I should add that i've been running XAMPP on localhost with no problems connecting though, is it safe to remove these characters? and will XAMPP continue to perform as expected? or should this be error be reported to Comodo?
Thanks in advance!
First of all try to use ip address like http://127.0.0.1/ or your lan ip adres
Original question
From a few hours of struggling with installing git on Windows 7. First I installed the GitHub on Windows but not appealed to me. Then I installed the Git-1.9.2-preview20140411 and have started to have problems.
I suppose that there is a conflict by multiple installations. So I uninstalled everything. I decided to try Cygwin.
I acted according to this tutorial: How To install Git client on Windows using Cygwin By Johnathan Mark Smith
I added the generated public key SSH to my account on GittHub by Web browser . I created the first repository (through a browser).
After returning to the cygwin terminal and I typed:
git clone git#github.com:akawalko/ZFExt.git
I received such a result
Cloning into 'ZFExt'...
ssh: Could not resolve hostname github.com: Non-recoverable failure in name resolution
fatal: The remote end hung up unexpectedly
I do not understand this message. I did something wrong?
EDIT 1:
To the person who gave me the minus one. In your opinion I shouldn't have asked. Instead, format the hard drive. In this way it would be okay?
Updated question
I started to ask google with less detailed questions and i found it: git and ssh: Could not resolve hostname, ping works. I changed my DNS addresses to open DNS and was able to clone my repo by using ip adres instead domain:
git clone git#192.30.252.128:akawalko/ZFExt.git some_git_repo/
Using domain name still not work:
git clone git#github.com:akawalko/ZFExt.git some_git_repo/
Cloning into 'some_git_repo'...
ssh: Could not resolve hostname github.com: Non-recoverable failure in name resolution
fatal: The remote end hung up unexpectedly
Any ideas (other then changing DNS)?
I had this issue inside a VMware Fusion VM. I had to change my network from NAT to Bridged and it started working.
For anyone else having this issue on VMWare Fusion and Windows 10, see this thread: https://communities.vmware.com/thread/518949?start=0&tstart=0
In summary, ssh won't do dns resolution over NAT on Fusion with Windows 10. This is a known bug, but in the meantime, add an entry to your host file to access bitbucket
131.103.20.167 bitbucket.org
Also, as #Jim Redmond pointed out, bitbucket is changing their IP addresses soon (December 15, 2016).
Another, more permanent, option would be to set Google as your DNS provider. Use 8.8.8.8 or 8.8.4.4. Or for ipv6: 2001:4860:4860::8888 or 2001:4860:4860::8844. https://developers.google.com/speed/public-dns/docs/using
For me, it started happening when I upgraded to Git 2.7.4. The fix in the link below worked for me, you need to change SSH configuration in \etc\ssh\ssh_config.
AddressFamily inet
See the last comment in the thread linked below:
Can't resolve hostname with SSH
Summary
It's been a few days and I have not found any solution. In conclusion, it's more a problem with the operating system than the tools (Cygwin, Git).
I installed two competing Git clients (Git-1.9.2-preview20140411 and GitHub on Windows) which resulting in messed up windows registry. This gives in an error: STATUS_ACCESS_VIOLATION at eip=68086014. I returned to app GitHub For Windows and will use Windows Power Shell. It's far from perfect but it works.
I was so focused on problem mentioned above that I didn't spot problem with DNS. Because I don't have knowledge how to solve this problem (answers on stackoverflow didn't work for me) I will use the IP address instead of github domain in commands like git clone and others until I reinstall Windows. :-(
I have modified the title to more precise.
Big thanks to #Chris for his contribution.
I had the same problem .then I tried with account name prefixed in the domain.
like try
git clone git#youraccountname.github.com:akawalko/ZFExt.git
it worked for me also make sure in your git config you are using the same url.
Experienced the same problem with Windows 7 and VmWare Fusion 8.5.3.
Tried 2 options. Both worked. But issue is weird. Seem to happen to github.com and bitbucket.com only.
Setting DNS manually in adapter settings (e.g. 8.8.8.8)
Change networking from NAT to Bridged
For me it works fine when I changed the hostname to ip address.