I have a samba-server. Can connect to it from my local network with no problem.
Can see that 139 and 445 port are opened. Site "speed-tester.info" also tells me that these ports are opened.
BUT when I scan my server nmap doesnt show me these ports!
have this string in smb.conf, so samba should listen external interface:
interfaces = lo0 msk*
I tried to add "\\89.179.246.174\disk_1" to my network in windows 7 but it failed.
Please help. What is wrong?
I was tired trying to connect my samba shares to my pc remotely.
So I found for myself 2 other solutions:
Use expandrive (binds drive to explorer over ssh, but ssh slows down connection)
Use hamachi
pipitas, thanks anyway!
First, your line interfaces = lo0 msk* does not look right to me. I've never come across an OS that names its NIC devices with a 'msk*' convention.
Second, get aware of the correct syntax for the interfaces = ... statement in smb.conf. Here is my summary of it:
... may hold one or several network interface names
... may hold one or several IP addresses
... may hold one or several hostnames
... may hold one or several IPaddress/netmask pairs
... may hold one or several broadcast/netmask pairs
... may hold a mixture of all of the above
More details to be found in man smb.conf. Assuming that 89.179.246.174 is the address of your Samba server, the following should do what you want:
interfaces = lo0 89.170.246.174
Related
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
Since google Compute engine does not provides internal DNS i created 2 centos bind machines which will do the resolving for the machines on GCE and forward the resolvings over vpn to my private cloud and vice versa.
as the google cloud help docs suggests you can have this kind of scenario. and edit the resolv.conf on each instance to do the resolving.
What i did was edit the ifcg-eth0 to disable the PEERDNS and in /etc/resolv.conf
i added the search domain and top 2 nameservrs my instances.
now after one instance gets rebooted..it wont start again because its searching for the metadata.google.internal domain
Jul 8 10:17:14 instance-1 google: Waiting for metadata server, attempt 412
What is the best practice in this kind of scenarios?
ty
Also i need the internal DNS for to do the poor's man round-robin failover, since GCE does not provides internal balancers.
As mentioned at https://cloud.google.com/compute/docs/networking:
Each instance's metadata server acts as a DNS server. It stores the DNS entries for all network IP addresses in the local network and calls Google's public DNS server for entries outside the network. You cannot configure this DNS server, but you can set up your own DNS server if you like and configure your instances to use that server instead by editing the /etc/resolv.conf file.
So you should be able to just use 169.254.169.254 for your DNS server. If you need to define external DNS entries, you might like Cloud DNS. If you set up a domain with Cloud DNS, or any other DNS provider, the 169.254.169.254 resolver should find it.
If you need something more complex, such as customer internal DNS names, then your own BIND server might be the best solution. Just make sure that metadata.google.internal. resolves to 169.254.169.254.
OK, I just ran in to this.. but unfortunately there was no timeout after 30 minutes that got it working. Fortunatly nelasx had correctly diagnosed it, and given the fix. I'm adding this to give the steps I had to take based on his excellent question and commented answer. I've just pulled the info I had to gather together in one place, to get to a solution.
Symptoms: on startup of the google instance - getting connection refused
After inspecting serial console output, will see:
Jul 8 10:17:14 instance-1 google: Waiting for metadata server, attempt 412
You could try waiting, didn't work for me, and inspection of https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google-startup-scripts/usr/share/google/onboot
# Failed to resolve host or connect to host. Retry indefinitely.
6|7) sleep 1.0
log "Waiting for metadata server, attempt ${count}"
Led me to believe that will not work.
So, the solution was to fiddle with the disk, to add in nelasx's solution:
"edit ifcfg-eth and change PEERDNS=no edit /etc/resolv.conf and put on top your nameservers + search domain edit /etc/hosts and add: 169.254.169.254 metadata.google.internal"
To do this,
Best to create a snapshot backup before you start in case it goes awry
Uncheck "Delete boot disk when instance is deleted" for your instance
Delete the instance
Create a micro instance
Mount the disk
sudo ls -l /dev/disk/by-id/* # this will give you the name of the instances
sudo mkdir /mnt/new
sudo mount /dev/disk/by-id/scsi-0Google_PersistentDisk_instance-1-part1 /mnt/new
where instance-1 will be changed as per your setup
Go in an edit as per nelasx's solution - idiot trap I fell for - use a relative path - don't just sudo vi /etc/hosts use /mnt/new/etc/hosts - that cost me 15 more minutes as I had to go through the: got depressed, scratched head, kicked myself cycle.
Delete the debug instance, ensuring your attached disk delete option is unchecked
Create a new instance matching your original with the edited disk as your boot disk and fire it up.
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've got a trio of Windows servers (data1, data2 and datawitness) that aren't part of any domain and don't use AD. I'm trying to set up mirroring based on the instructions at http://alan328.com/SQL2005_Database_Mirroring_Tutorial.aspx. I've had success right up until the final set of instructions where I tell data1 to use datawitness as the witness server. That step fails with the following message:
alter database MyDatabase set witness = 'TCP://datawitness.somedomain.com:7024'
The ALTER DATABASE command could not be sent to the remote server instance 'TCP://datawitness.somedomain.com:7024'. The database mirroring configuration was not changed. Verify that the server is connected, and try again.
I've tested both port 7024 as well as 1433 using telnet and both servers can indeed connect with each other. I'm also able to add a connection to the witness server from SQL Server Manager on the primary server. I've used the Configuration Manager on both servers to enabled Named Pipes and verify that IP traffic is enabled and using port 1433 by default.
What else could it be? Do I need any additional ports open for this to work? (The firewall rules are very restrictive, but I know traffic on the previously mentioned ports is explicitly allowed)
Caveats that are worth mentioning here:
Each server is in a different network segment
The servers don't use AD and aren't part of a domain
There is no DNS server configured for these servers, so I'm using the HOSTS file to map domain names to IP addresses (verified using telnet, ping, etc).
The firewall rules are very restrictive and I don't have direct access to tweak them, though I can call in a change if needed
Data1 and Data2 are using SQL Server 2008, Datawitness is using SQL Express 2005. All of them use the default instance (i.e. none of them are named instances)
After combing through blogs and KB articles and forum posts and reinstalling and reconfiguring and rebooting and profiling, etc, etc, etc, I finally found the key to the puzzle - an entry in the event log on the witness server reported this error:
Database mirroring connection error 2 'DNS lookup failed with error: '11001(No such host is known.)'.' for 'TCP://ABC-WEB01:7024'.
I had used a hosts file to map mock domain names for all three servers in the form of datax.mydomain.com. However, it is now apparent that the witness was trying to comunicate back using the name of the primary server, which I did not have a hosts entry for. Simply adding another entry for ABC-WEB01 pointing to the primary web server did the trick. No errors and the mirroring is finally complete.
Hope this saves someone else a billion hours.
I'd like to add one more sub answer to this specific question, as my comment on Chris' answer shows, my mirror was showing up as disconnected (to the witness) Apperently you need to reboot (or in my case i just restarded the service) the witness server.
As soon as i did this the mirror showed the Witness connection as Connected!
See: http://www.bigresource.com/Tracker/Track-ms_sql-cBsxsUSH/
Problem
Users from other IPs on the (Windows XP) LAN suddenly cannot connect to my local MySQL server.
Background
I've set up MySQL on my local Windows computer so that other computers on the network have access to the root account. I've added each IP as a host for root. Up to some weeks ago, things worked flawlessly and I could connect to the server programatically and using various MySQL admin tools. Now, however, the MySQL server simply refuses connections from those IPs and I can't figure out why.
The network changes that I've done are: changing network card for two (of three) computers and fiddled around with MySQL settings. None of which should have caused this problem. I've tried adding a new user with all relevant hosts, but I get the same type of error:
MySQL Error number 1045 Access denied
for user 'root'#'shop' (using
passwords: YES)
The odd part is that the computer name, 'shop', is used instead of the IP. I don't know why.
Somehow, IPs seem to be resolved now and hostnames are used. Did you grant access to root#shop? Did you flush privileges?
First thing that pops into mind is Windows Firewall, which could have got re-enabled if you swapped NICs on the host computer.
My next suggestion would be to use a sniffer like Wireshark on the host computer and see what exactly happens packet-wise. You can use filters to make to reduce the output - they're very simple and easy to use. This tool has saved me countless hours of debugging.
-EDIT-
Another possible cause might be that your server somehow decided to resolve IPs to hostnames, in which case ip addresses may no longer work - one would need to add hostnames to the allowed list. Not sure if it works this way for MySQL though.
Could you have turned off TCP connections in MySQL?
Also, is the MySQL port open in your firewall?
If you changed your IP (DHCP?), make sure to correct it in my.cnf if you bound mysqld to your lan ip:
[mysqld]
...
bind-address=192.168.x.y