As a preamble, I have developed my own CRM (something like SalesForce or SAP) of a much much lower "scale" as it is oriented for services, not sales. I use MySql or MariaDB (preferred now) on Ubuntu 16.04 server to save all data.
I have always used the MySQL or MariaDB server public IP address as the binding address in my.cnf, and it all has worked fine for years. But sometimes it just stops allowing communication from the outside world (It allow connections locally), when it does it does not allow outside connections anymore until I change the binding IP to 0.0.0.0 or:: then it all works. So the question is, what happens? I am also a little concern about using 0.0.0.0 (ipv4) or:: (ipv6) for the binding address because I am not sure if there is any higher security risk when doing this.
I do run a Master to Master connection and the second Master do have the public address as the binding address and it is working fine.
The Ubuntu internal firewall is disabled as I rely on another firewall for it. I have disabled this firewall for a few seconds for testing but the problem persists. I do use Fail2Ban for Linux but nothing is being blocked.
What do you guys think might be causing the change in behavior (not allowing external connections)?
Is there any benefit of using the Public IP address as the binding address?
What are the risks of using 0.0.0.0 for the binding address instead of the server public address?
Is it better to use :: than 0.0.0.0? what are the benefits?
Thanks in advance!
Check your mysql database User and Db tables. You MUST have a proper GRANT for the external IP your a re trying to reach from. You will need something like
GRANT ALL ON <database>.* TO 'externaluser'#'external_ip' IDENTIFIED BY 'whatever';
Otherwise, MySQL will not allow access
I have a problem with chrome resolving an entry in my local hosts file (/etc/hosts). This is my host-file:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
127.0.0.1 mylocalpage.com
Unfortunately I got the following error from chrome when I try to access the page:
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL:
http://mylocalpage.com/
Unable to determine IP address from host name mylocalpage.com
The DNS server returned:
Name Error: The domain name does not exist. This means that the system
was not able to resolve the hostname presented in the URL. Check if
the address is correct.
On all the other browsers like firefox, opera etc. It works like a charm. Is there a setting in chrome which I forgot?
I dont really know how to start here. Can someone give me an approach how to proceed here.
It's seems like a cache issue. Try clearing it at chrome://net-internals/#dns.
Our Terminal Server (TS) is only accessible on one network, therefore I believe the default gateway has not been set correctly or needs to be updated.
I am looking for the commands in a telnet session to:
1. Review the current configuration of the terminal servers default gateway ip address and,
2. The command to set it if it needs to be changed.
The TS is a :
N-Base Xyplex Max Server 1640
I Have reviewed some on line documentation but can't really find a clear solution but I am also not a network tech!
Many Thanks
Hope this may come in handy for others:
To set gateway address:
ENTER GATEWAY IP ADDRESS [0.0.0.0]:
Good instruction manual available here
Still not sure how to check current gateway setting.
I've been running my Google Compute VM for literally 1 day, and I was hacked, by this IP: http://www.infobyip.com/ip-121.8.187.25.html
I'm trying to understand what I can do next (user connected via ssh, root password was changed), to avoid these types of attacks (and to understand more than what /var/log/auth.log is telling me) ?
I assume you deleted the instance already, right ? from Developers console.
As suggested, always use ssh rsa keys to connect to your instance, instead of passwords. Additionally, depending on where you want access from, you can only allow certain IPs through the firewall. Configuring the firewall along with iptables, gives you better security.
You may also want to take a look at sshguard. Sshguard will add iptables rules automatically when it detects a number of failed connection attempts.
Just to make sure, please change the default port 22 in /etc/ssh/sshd_config to something else.
I want to send emails using gmail's smtp with the PHP script posted below using Swiftmailer. Now this works fine on my own webserver. But when I used it on the webserver of the people I'm creating this for, I get an exception:
Fatal error: Uncaught exception 'Swift_TransportException' with message 'Connection could not be established with host smtp.gmail.com [Connection timed out #110]' in ...
What could be the problem?
I'm assuming its got to do with the difference in server settings, because the code works on my own webserver. I've checked with phpinfo() the following:
- Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
- OpenSSL support enabled
- OpenSSL Library Version OpenSSL 1.0.1e-fips 11 Feb 2013
This is my PHP code:
$emailname = MY_GMAIL_ACCOUNT_USERNAME;
$emailpass = MY_GMAIL_ACCOUNT_PASSWORD;
$transport = Swift_SmtpTransport::newInstance('smtp.gmail.com', 465, "ssl")
->setUsername($emailname)
->setPassword($emailpass);
$mailer = Swift_Mailer::newInstance($transport);
$message = Swift_Message::newInstance($emailtitle)
->setFrom(array($emailname.'#gmail.com' => $emailsender))
->setTo(array($emailrecp))
->setBody($emailbody,'text/html');
$result = $mailer->send($message);
I had the same issue on a Digital Ocean server. Turns out they're blocking SMTP by default on IPv6. Here's the fix:
nano /etc/gai.conf
precedence ::ffff:0:0/96 100
as per:
https://www.digitalocean.com/community/questions/outgoing-connections-on-port-25-587-143-blocked-over-ipv6
My easy solution to avoid the problem of dynamic IP (every time i ping smtp.gmail.com I see a slight difference in the last 3digit chunk), is to simply use php built-in gethostbyname() to read the IP in real-time.
$smtp_host_ip = gethostbyname('smtp.gmail.com');
$transport = Swift_SmtpTransport::newInstance($smtp_host_ip,465,'ssl')
->setUsername('username')->setPassword('pwd');
Im not advanced in php and streams but it seems that IPv6 DNS resolution depends on the router and/or ISPs. I changed my provider, got a new router and the smtp connection always timed out.
To use IPv6 you should either add your own IPv6 or force stream_context_create to use IPv4. You can call setSourceIp() on a swiftmailer object or directly change the Swift_SmtpTransport class (i.e. in the constructor).
Use IPv6:
// replace IP with your own IPv6
$this->setSourceIp('2aaa:8a8:fc0:230:fds:4fd:faa:24ae');
Use IPv4 (mentioned at https://github.com/phergie/phergie/issues/195):
$this->setSourceIp('0.0.0.0');
just add
74.125.130.108 smtp.gmail.com
to server's hosts file
I've just been doing battle with exactly the same problem. Mine worked locally too, but as soon as it got on a real server ... no. It just would not work even though all the settings were the same.
After many hours, I've think I've found out why.
What seems to happen is that on a server with IPv4 and IPv6 support, IPv6 takes precedence. Which makes sense, given that it's newer. But in the case of smtp.gmail.com, it appears to only listen on IPv4. So when the server resolved smtp.gmail.com, it got its IPv6 address back and so PHP tried to connect to it. That eventually gives up with a "Connection timed out" exception. Now you would think that fsockopen, presumably, would detect the connection wasn't working and so try IPv4, but seemingly it doesn't.
If you find out what smtp.gmail.com's IPv4 address is (ping smtp.gmail.com) and simply put that IP in place of the hostname in the code - it works :)
It's not ideal coding in an IP address - given that Google could change it at any minute - but at least you will get some emails sent
The answer for me was that my server was blocking the outbound connection. It could be your firewall or your host.
The way to test this is to try connecting yourself. I used telnet on two different machines to compare and it became obvious that this was my issue. There may be a way to test this with curl directly.