Category Archives: Networking

MySQL remote user access not working on Ubuntu + Plesk

Posted by on June 27, 2011 No comments

Last week one of my mate’s private vServer was hacked, hijacked and used for DoC attacks which prompted his provider (Strato) to disable the machine and recommended a reinstallation of the OS. That was not as bad as it sounds, as all data on the server were on backup and the OS was outdated to boot (OpenSuse 9!).

The vServer was reinstalled with Ubuntu 10.04 LTS and Plesk 10. After all data were back in place, all sites back up and running, all that was missing was the remote connection to the MySQL server. My mate uses Navicat (as do I, btw) to remotely manage his databases. So a new user was added to MySQL with remote access rights, the Navicat settings were altered accordingly and… a connection could not be established. D’Oh!

What went wrong? Well, I had a look at the issue. First off, I checked the [mysqld] settings in the MySQL configuration (aka my.cnf).

user            = mysql
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
bind-address    = 0.0.0.0
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
skip-external-locking

That looked all good. The standard port was set to 3306, the bind-address was set to listen to all incoming traffic (although a security related “no-no” in my opinion), and no trace of the “skip-networking” directive that might have negated the bind-address settings.

Just to be on the safe side I restarted the mysql server (service restart mysql), but Navicat would still not connect.

Next stop was to have a look at the output generated by iptables -L and there I found this:

DROP       tcp  --  anywhere             anywhere            tcp dpt:mysql

Hmm. It seems that tcp connections to MySQL are dropped for some reason. Probably not a bad idea to keep that setting (and set my.cnf’s bind-address to 127.0.0.1) just to avoid new system intrusions via the MySQL route.

Of course that meant that the Navicat connection problem remained… that is, as far as a direct connection to the MySQL server is concerned. However, Navicat permits to connect to MySQL via SSH tunneling*. And using that option works like a treat minus the security risks of an open MySQL server.

* A bit confusing is that you have to manually set the MySQL Server address to “localhost” in Navicat’s main connection property window. I would have thought that the software would choose this setting automatically, if SSH tunneling is activated. Well, just a minor nuisance.

Mac OS X Network & NAS – the “Unix Executable” file type problem

Posted by on October 28, 2010 No comments

So we are on an Apple Network here. But rather than relying on time machine as a backup solution – which isn’t really the way to go for multiple machine backups – we’re using Retrospect. (I could write a novel about the grief that piece of software has caused me – but why bother?). And while we ran our backups for yonks onto DVDs, the stack of media just took on ridiculous dimensions. That is why we installed a NAS (LevelOne FNS-5000B, good hardware, but shoddy interface, should have gone with a QNAP), with two 1.5 Tb hard disk in a RAID1 configuration. The NAS offers multiple protocols to connect to the network.

Retrospect is maintaining its backup files via the network on the NAS. And out of convenience (and for security reasons) we also keep older backup sets on the NAS. Now some of our guys have the Retrospect software (not just the client) installed one their machine so that they can access and retrieve files from historic backup sets.

And that’s where we encountered problems on a random basis. Sometimes on the Macs Retrospect simply refused to accept the backup files on the NAS as valid Retrospect catalogues. In the finder, the files did not show up with their usual icon, but instead featured the wee terminal icon. Apple-I showed the files as “Unix Executables”. Strangey enough, this problem would occur on some machine one day, but would be miraculously fixed the next day. If it did not fix itself I used to fix the issue by using a tool called FileType to change file type and creator codes. However, for some reason that did not work more recently. Plus I never felt quite comfortable fiddling with the backup set files anyhow.

So I did a bit of research and found that the “Unix Executable” problem has something to do with Macs not being able to “read the file’s resource fork“. So I asked myself, why the resource fork was readable one day, but not the next and I figured that it might have something to do with the network protocoll the Macs were using to access the NAS.

Sure enough, when the problem reoccured today, I did an Apple-I and found that the NAS was mounted using the Samba protocoll (smb://nas/). Now since the NAS also support AFP I wondered whether connecting via that protocol would fix the problem.

So I unmounted the NAS volume on the Mac (by clicking the eject icon next to the volume name in Finder) and then rather than using the Finder to re-connect to the NAS, I pressed Apple-K to get to the Finder’s  “Connect To Server…” window and typed in afp://192.168.1.* (i.e. our NAS IP). The NAS remounted into my finder and – voila! – gone was the “Unix Executable” problem.

Why the Macs sometimes connected via smb and then again via afp is beyond me. But at least now I know how to fix the problem.