Posts Tagged ‘ERROR’

Allowing MySQL users access from all hosts – Fixing mysql ERROR 1045 (28000): Access denied for user ‘root’@’remote-admin.com’ (using password: YES)

Friday, June 20th, 2014

mysql_allow_access-from-remote-any-host-fix-access-error-after-sql-migration

I recently migrated MySQL database server from host A to host B (remotesystemadministration.com), because I wanted to have the mysql database server on a separate machine (have separation of server running services and have a dedicated mysql server).

MySQL server host (running on localhost previously was set from my mysql config my.cnf to listen and serve connections on localhost with

bind-address = 127.0.0.1

). MySQL is used by a Tomcat running Java application on localhost and my task was to set the Tomcat to use the MySQL database remotely to MySQL host B (new remote hostname where MySQL is moved is  remotesystemadminsitration.com and is running on IP 83.228.93.76).

Migration from MySQL Db server 1 (host A) to MySQL Db server 2 (host B) is done by binary copying the mysql database directory which in this case is (as it is a Debian server installed MySQL), the standard directory where mysql stores its database data is /var/lib/mysql ( datadir = /var/lib/mysql in /etc/mysql/my.cnf)

Binary copying of data from MySQL db (host A) to MySQL Db (host B) is done with rsync

After migrating and trying to login on migrated mysql  database on remotesystemadministration.net with mysql cli client:

remotesysadmin:~$ mysql -u root -p

I got following error:
 

ERROR 1045 (28000): Access denied for user 'root'@'remotesystemadministration.com' (using password: YES)


To fix the issue I had to login remotely from old migration server mysql (host A) cli:

mysql:~$ mysql -u root -p -h remotesystemadministration.com

and  run SQL commands:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'remotesystemadministration.com' WITH GRANT OPTION;
GRANT USAGE ON *.* TO 'root'@'remotesystemadministration.com' IDENTIFIED BY 'secret-mysql-pass';
FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.03 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)


Another way to solve the problem is to add the root user to be able to connect from any host (Enable MySQL root access from all host), to do so issue:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Note: In newer version of MySQL, flush privileges could be omitted.

Another approach if you want to substitute access from localhost for all users and enable all users to be able to authenticate to mysql remotely is to execute SQL Query:

UPDATE USER SET host='%' WHERE host='localhost';

Allowing all users to be able to connect from anywhere on the internet is a very bad security practice anyways, if you already have a tight firewall setup and you can only access the server via specific remote IP addresses allowing MySQL access from all hosts / ips should be ok.

w00tw00t.at.ISC.SANS.DFind in apache error.log – Filtering script kiddie port scanner on GNU / Linux

Friday, November 23rd, 2012

 

w00tw00t.at.ISC.SANS.Dinfd - Filtering script kiddies port scanners from Apache logs and servers with iptables firewall

If you get thousand of messages:

[Wed Nov 21 16:28:49 2012] [error] [client 89.136.100.192] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

 

in /var/log/apache2/error.log It is due to a script kiddie port scanner, usually such requests originate from Turkia, Romania ,Russia.. Usually, for servers getting in Apache error.log  GET/w00tw00t.at.ISC.SANS.DFind:) once in a while, it is not an issue however if you get too many of this messages it is sometimes useful to filter them with a simple iptables rule

debian:~# /sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t.at.ISC.SANS." --algo bm --to 70 -j DROP

What above command does is it greps the 1st 70 bytes and checks, whether it contains string '/w00tw00t.at.ISC.SANS.DFind:)' , whether string is matched it jumps to DROP rule filtering the IP. Of course on busy servers checking each incoming IP client TCP/IP request for a certain string might not be very efficient and even can be a possible bottleneck. So I don't know whether filtering /w00tw00t.at.ISC.SANS.DFind:) is good or bad practice. Anyways generally it is wise to filter IPs doing the request anyways since, they could try a various script kiddie cracking tools, port scanners and even some of them might be hosts attempting DoS or DDoS.

Also it is useful to store for later the rule with:

debian:~# /sbin/iptables-save > /root/iptables_rules.txt

Then you can load up /root/iptables_rules.txt with:

debian:~# /sbin/iptables-restore < /root/iptables_rules.txt

Some common way to keep the iptables rule loaded on system boot is by adding /iptables-restore  to /etc/rc.local
 

Some alternative methods to filter IPs issuing GET  /w00tw00t.at.ISC.SANS.DFind:) to Apache is through  fail2ban, denyhosts or blockhosts or Apache mod security filters.
You can read further Information on what DFind hacktool does here

To keep an eye on all DROPped and REJECT-ed traffic (in bytes) it is useful to use:

debian:~# /sbin/iptables -L INPUT -nvx|grep -i -E 'drop|reject'
       0        0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable
       0        0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 17
       0        0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 13
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x03/0x03
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06
    1526    77004 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp reject-with icmp-host-prohibited
 
For filtering

Disable Apache access.log and error.log logging on Debian Linux and FreeBSD

Tuesday, September 25th, 2012

Disable Apache logging Debian and FreeBSD Linux logo

Many times disabling logging on a busy websites is quite beneficial, especially if more than few Gigabytes are written in Apache visitors log (access.log) every day. Too much visitors to Apache webserver could pose significantly increase disk writes and be negative for overall server performance.

Disabling the log is handy also for websites which already integrate a different type of visitors logging lets say – via MySQL, PostgreSQL (SQL) …

From security perspective disabling logging is a very stupid idea thought, however on systems which are experiencing high load and you need to sacrifice logging to reduce a bit the load (especially if you cannot afford to get a new server hardware), disabling it is an option.

1. Disabling access.log and error on Debian Linux

a) Disabling access.log logging
As most Debian users already know on Debian GNU Linux Apache logs all incoming (port 80) Apache requests to /var/log/apache2/access.log and /var/log/apache2/error.log

Disabling logging is very simple, just comment out line in /etc/apache2/sites-enabled/000-default:


CustomLog ${APACHE_LOG_DIR}/access.log combined

to


#CustomLog ${APACHE_LOG_DIR}/access.log combined

Then restart the webserver to re-read new config value:


# /etc/init.d/apache2 restart
....

Of course this is one of the ways to disable access.log logging. Other ways are to make logging gets logged in good old /dev/null. To use /dev/null forwardingp put Customlog /dev/null in /etc/apache2/sites-enabled/000-default


CustomLog /dev/null

In Debian Lenny and older Debian releases Customlog Apache directive is found in /etc/apache2/apache2.conf.

b) Disabling error.log logging

Same procedure applies for disabling error.log, comment out default ErrorLog directive, restart Apache and you’re done:


ErrorLog ${APACHE_LOG_DIR}/error.log

should become:


ErrorLog /dev/null

Usually just comming ErrorLog ${APACHE_LOG_DIR}/error.log is supposed to work, unfortunately for reason on Debian Squeeze this worked not commenting it and restarting Apache failed to restart apache with error:


# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting (2)No such file or directory: apache2: could not open error log file /etc/apache2/logs/error_log.
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
failed!

Thus to disalbe error.log you need to add ErrorLog /dev/null in /etc/apache2/apache2.conf and once again restart Apache.


ErrorLog /dev/null


# /etc/init.d/apache2 restart

Bear in mind that if you use some custom virtualhosts which has the ErrorLog directive in (let’s say /etc/apache2/sites-enabled/{website-domain.com,website-domain1.com} etc. you need to change there too.
2. Disabling access.log and error.log logging on FreeBSD
On FreeBSD to disable access.log add CustomLog /dev/null to /usr/local/etc/httpd.conf and just like on Linux restart Apache:


freebsd# /usr/local/etc/rc.d/apache2 restart
....

Disaling error.log on BSD is done by changing:


ErrorLog /var/log/httpd-error.log

to


ErrorLog /dev/null

BTW disaling error.log is quite a stupid idea but in some situation, where you don’t update software versions and don’t change often webserver script interpreter and (processed) server side executables / PHP scripts it could be ok.
Still it is much better to change the amount of Apache logged information and keep error.log logging by changing:


LogLevel crit

Using LogLevel crit, will prevent Apache from logging numerous not so useless warnings in error.log, so if you have a very busy server with high loads you better use it.

Don’t expect that disabling logging will drastically improve performance usually even on Apache servers which serve more than 20 000 of requests daily disabling access.log / error.log could would probably reduce load with from 00.1 to maximum 2-3 percentage.

Thunderbird mail check problem fix to: “An error occurred sending mail: Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn’t advertise that feature.”

Wednesday, August 22nd, 2012

Some clients of one of the qmail servers mail domain complained that there are problems sending e-mails with Thunderbird (pop / imap) client.

The exact Thunderbird sending error is:

Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn't advertise that feature.
Switch off STARTTLS for that server or contact your service provider.

For for almost half an hour I pondered why the heck this odd error happens in sending mails with a fresh new Thunderbird (auto) configured mail address.
Few months back some clients were experiencing similar STARTTLS errors so I went back to check my previous post to get an idea what was wrong then in order to determine if the current reported error had to do with the previous one. My previous post is here – How to work around STARTTLS Qmail Thunderbird / Outlook mail sending (error) issues

After reading on the previous error and some assumptions I found out the whole problem lays in incorrectly set DNS records.
By default Thunderbird (and probably other mail clients) are configuring automatically as SMTP server (smtp.examplehost.com) if the DNS record for smtp.examplehost.com points to an IP address / host which belongs to another mail server, everytime thunderbird tries to send email the incorrect smtp.examplehost.com is used, hence the mail sending fails with the err:

Unable to establish a secure link with SMTP server smtp.examplehost.com using STARTTLS since it doesn't advertise that feature.
Switch off STARTTLS for that server or contact your service provider.

In my case the DNS for examplehost.com which is the mail server host was managed by Godaddy’s DNS-es:

ns49.domaincontrol.com
ns50.domaincontrol.com

The A record for our domain smtp.examplehost.com was by default set in GoDaddy to point to incorrect IP, so the fix was simply to change the Domain alias of smtp.examplehost.com to the proper mail host.

Another thing I had to do is change variables in /var/qmail/supervise/qmail-smtpd/run and /var/qmail/supervise/qmail-smtpdssl/run

In both files I changed variables:

SSL=0
ALLOW_INSECURE_AUTH=0

to

SSL=1
ALLOW_INSECURE_AUTH=1

Also variables FORCE_TLS and DENY_TLS in /var/qmail/supervise/{qmail-smtpd,qmail-smtpdssl}/runs should be:

FORCE_TLS=0
DENY_TLS=1

Though the problem was occuring in Mozilla Thunderbird, i’m sure same email sending problem will be present if Microsoft Outlook Express or any other desktop pop3 client is used.
After this changes I had to restart qmail server through qmailctl:

# qmailctl stop; sleep 5; qmailctl start

This fixed clients mail sending issues … hope this will help to others looking for way to remove STARTTLS, TLS, SSL qmail support

How to solve “[crit] [client xxx.xxx.xxx.xxx] (13)Permission denied: /var/lib/ejabberd/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://jabber.mydomain.com/” – Error Cause and Solution

Thursday, January 5th, 2012

While configuring JWchat domain, I've come across around an error:

pcfg_openfile: unable to check htaccess file, ensure it is readable

The exact error I got in /var/log/apache2/error.log looked like so:

[crit] [client xxx.xxx.xxx.xxx] (13)Permission denied: /var/lib/ejabberd/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://jabber.mydomain.com/

The error message suggested /var/lib/ejabberd/.htaccess – is missing or not readable, however after checking i've seen .htaccess existed as well as was readable:

debian:~# ls -al /var/lib/ejabberd/.htaccess
-rw-r--r-- 1 www-data www-data 114 2012-01-05 07:44 /var/lib/ejabberd/.htaccess

At first glimpse it seems like the message is misleading and not true, however when I switched to www-data user (the user with which Apache runs on Debian), I've figured out the error meaning of unreadability is exactly correct:

www-data@debian:$ ls -al /var/lib/ejabberd/.htaccess
ls: cannot access /var/lib/ejabberd/.htaccess: Permission denied

This permission denied was quite strange, especially when considering the .htaccess is readable for all users:

debian:~# ls -al /var/lib/ejabberd/.htaccess
-rw-r--r-- 1 www-data www-data 114 2012-01-05 07:44 /var/lib/ejabberd/.htaccess

After a thorough look on what might go wrong, thanksfully I've figured it out. The all issues were caused by wrong permissions of /var/lib/ejabberd/.htaccess .You can see below the executable flag for all users (including apache's www-data) is missing :

debian:/var/lib# ls -ld /var/lib/ejabberd/drw-r--r-- 3 ejabberd ejabberd 4096 2012-01-05 07:45 /var/lib/ejabberd/

Solving the error, hence is as easy as adding +x flag to /var/lib/ejabberd :

debian:/var/lib# chmod +x /var/lib/ejabberd

Another way to fix the error is to chmod to 755 to the directory which holds .htaccess:

From now onwards pcfg_openfile: unable to check htaccess file, ensure it is readable err is no more 😉

How to play VCD videos in Debian Linux

Monday, September 26th, 2011

Totem VCD error occured, could not open location you might not have permissions to open the file

A friend of mine gave me a VCD with some coptic Orthodox Christian exorcism, where there pope was chasing some evil spirits from possessed muslims who came to the Coptic Orthodox Church in egypt. The video was made to be in VCD and as you can expect this did not worked out of the box with Totem and VLC out of the box.
Putting in the VCD video inside my cdrom poped up an error like the one in the header of the post.
In order to make the video play I had to use the old school and now a bit obsolete mplayer.
Hence in order to play the VCD on Debian Linux I had to install mplayer and w32codecs packages first e.g.:

debian:~# apt-get update && apt-get install mplayer w32codecs

Second to play the video from gnome-terminal, I had to switch to the mounted cdrom location /media/cdrom0 and launch the video with mplayer cmd like so:

debian:~$ cd /media/cdrom0/vcd
debian:/media/cdrom0/vcd$ mplayer vcd://2
...

In some cases it might be necessery to play the video with mplayer command like:

debian:/media/cdrom0/vdd$ mplayer vcd://2 vcd://3

Watching it with mplayer from console has some downsides as I couldn’t make the fast rewind work, but still it’s way better than nothing.
Too bad in Debian Squeeze 6 gmplayer is no longer installable. The gmplayer can probably be installed if mplayer is compiled from source, but I’m too lazy to try it out.
I’ve red also in some forums online that gxine is capable of playing the VCD play nice, but I couldn’t install it from my existing Debian repositories so I did not give it a go.

Fix to Nagios is currently not checking for external commands

Wednesday, August 24th, 2011

While I was deploying a new Nagios install to Monitor some Windows hosts I’ve came across the following error in Nagios’s web interface:

Sorry, but Nagios is currently not checking for external commands, so your command will not be committed!
Read the documentation for information on how to enable external commands...

This error is caused by an option configuration for /etc/nagios/nrpe.cfg (part of the nrpe-nagios-server Debian package.

The config variable in nrpe.cfg causing the error is check_external_command=0 , the fix comes to changing the variable to:

check_external_command=1

As well as restart the /etc/init.d/nagios-nrpe-server and /etc/init.d/nagios3 services:

debian:~# /etc/init.d/nagios3 restart
...
debian:~# /etc/init.d/nagios-nrpe-server
...

This changes has work out the error Sorry, but Nagios is currently not checking for external commands, so your command will not be committed! , however immediately after another kind of error appared in Nagios web interface when I tried to use the send Nagios commands button. The error was:

Error: Could not stat() command file '/var/lib/nagios3/rw/nagios.cmd'!

This error is due to a deb package, which seems to be affecting the current deb versions of Nagios shipped with Debian 6 Squeeze stable, as well as the Latest Ubuntu release 11.04.

Thanksfully there is a work around to the problem I found online, to fix it up I had to execute the commands:

debian:~# /etc/init.d/nagios3 stop debian:~# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
debian:~# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
debian:~# /etc/init.d/nagios3 start

And hooray Thanks God the error is gone 😉

Fix “checking build system type… Invalid configuration `x86_64-unknown-linux’: machine `x86_64-unknown’ not recognized” on ./configure

Wednesday, August 3rd, 2011

I’m trying to compile vqadmin on x86_amd64 (64 bit Debian) and I got error during ./configure . The error I got is as follows:

debian:~/vqadmin-2.3.7# ./configure --enable-cgibindir=/var/www/mail/cgi-bin -enable-htmldir=/var/www/mail/ --enable-isoqlog=y
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/downloads/vqadmin-2.3.7/missing: Unknown `--run' option
Try `/downloads/vqadmin-2.3.7/missing --help' for more information
configure: WARNING: `missing' script is too old or missing
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... Invalid configuration `x86_64-unknown-linux': machine `x86_64-unknown' not recognized

So my compile failed with:
checking build system type… Invalid configuration `x86_64-unknown-linux’: machine `x86_64-unknown’ not recognized

Thanksfully, there is a tiny script which originally is part of the CVS project. I’ve modified a bit the script to remove few lines of code which are not necessery. The `x86_64-unknown-linux’: machine `x86_64-unknown’ not recognized fix script fix_x86_64-unknown-linux-gnu.sh is here

To fix up the broken configure all required is:

debian:~/vqadmin-2.3.7# sh fix_x86_64-unknown-linux-gnu.sh

Next on I could compile normally again vqadmin just fine.

How to install Skype on 64 bit Ubuntu (amd64) architecture

Sunday, July 17th, 2011

It seems Skype has troubles installing on 64 bit Ubuntu via Ubuntu’s Graphical Package Install manager which in Ubuntu 11.04 is called (Ubuntu Software Center)

During my attempt to take advantage of the nice GUI apt frontend, I encontered the error:
Wrong Architecture amd64

And Skype install failed, as you see in below’s picture (which you might be unable to read since it’s stating the error in Bulgarian 😉

error Ubuntu 11.04 Skype Install error in architecture amd64

The error is quite understandable, since the Skype deb package which tried to install was built for the i386 architecture.
Since the Software Center was not intelligent enough to work around the issue, I finally fixed it myself using the good old apt-get in terminal, like so:

root@ubuntu:~# apt-get install skype
...

apt did not even complain that the package had a different architecture for i386 and installed skype without any errors as well Skype worked immediately even though the arthictural difference.
This is probably because even though it’s a amd64 Ubuntu it has a kernel module loaded to support i386 binaries 😉
Now my sister can enjoy her skype on the shiny Ubuntu 😉