Posts Tagged ‘ERROR’

Linux “bash: mail: command not found” error fix – Installing mail cli on Fedora, Debian, CentOS, Ubuntu

Friday, September 7th, 2018

Reading Time: 2minutes

bash-mail-command-not-found-error-fix-linux-installing-bsd-mailx-linux-fedora-debian-centos

If you just hired a cheap VPS with some kind of Linux OS installed or just installed a home Linux test system environment inside a Virtual Machine (such as VirtualBox) on your notebook and you want to read system email reports delivered by services (e.g. track possible errors with the OS) or simply test whether Email relaying is configured properly

and you end up with shell error:

bash: mail: command not found

because mail command is missing and you wonder what Linux package you have to install in order to have the lovely mail / mailx command back on the OS … this article will help you how you can easily solve it by installing the mailx binary file (e.g. install the package providing it depending on the Linux Distribution Operating System youface the problem on.

1.  Install mailx command on Debian / Ubuntu / Mint and other .deb based Linux
 

root@linux:~# apt-get install –yes bsd-mailx

 


An alternative way to install the mailx systembinary is to install  mailutils package

which will set up the system with essential mail related programs and set up a light Exim MTA and common server Email surrounding  so you can easily configure default installed Exim Mail Server to serve as an SMTP relay (through dpkg-reconfigure exim4-config) command

 

root@linux~:# apt-get install mailutils
Reading package lists… Done
Building dependency tree       
Reading state information… Done
The following additional packages will be installed:
  exim4-base exim4-config exim4-daemon-light guile-2.0-libs libgsasl7
  libkyotocabinet16v5 libmailutils5 libmariadbclient18 libntlm0
  mailutils-common mysql-common
Suggested packages:
  eximon4 exim4-doc-html | exim4-doc-info spf-tools-perl swaks mailutils-mh
  mailutils-doc
The following NEW packages will be installed:
  exim4-base exim4-config exim4-daemon-light guile-2.0-libs libgsasl7
  libkyotocabinet16v5 libmailutils5 libmariadbclient18 libntlm0 mailutils

 

root@linux:~# dpkg-reconfigure exim4-config

 

dpkg-reconfigure-exim4-config-debian-linux-exim4-email-server-screenshot

2. Install mailx Linux command on Fedora / CentOS / RHEL e.g. Redhat based distros

 

On RPM based distrubutions the package name is different from debians to install it there you have to fetch and install current distro mailx .rpm

To install mail command on older CentOS / Redhat 7/6/5 distributions

 

[root@centos:~]# yum install -y mailx

 

On Fedora 22+ version yum auto-dependency tool was substituted with dnf:

 

[root@fedora:~]# dnf install -y mailx

 


3. Send Test Email with mail command

 

root@linux:~# echo "Sample Message Body" | mail -s "Whatever … Message Subject" remote_receiver@remote-server-email-address.com

 


Check the mailbox, you just sent the sample email, hopefully if MTA is relaying correctly and the SMTP relay is properly delivering the email should be at the recipient address.

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

Reading Time: 2minutes

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 configmy.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/mysqlin /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.

How to check and repair broken MySQL ISAM tables

Monday, July 11th, 2011

Reading Time: < 1minute
MySQL repair artistic picture

If you are stuffed with errors in /var/log/mysqld.log similar to:

110711 11:00:48 [ERROR] /usr/libexec/mysqld: Incorrect information in file: './anyboots_moncler_spaccio/zen_seo_cache.frm'
110711 11:00:48 [ERROR] /usr/libexec/mysqld: Incorrect information in file: './anyboots_moncler_spaccio/zen_sessions.frm'

This is a sure sign something terrible has happened with your mysql database tables that lead to corruption.
Having corrupt table in mysql installation can severely lead to data loss as well as significantly reduce the speed and performance of a MySQL server in this awful times mysqlcheck is the best friend of the administrator, here is how you can check and repair broken tables in MySQL server:

mysql-server:~# mysqlcheck --all-databases -u root -p
chillor_hjbgl.vn_users OK
chillor_lul.mybb_adminlog OK
chillor_lul.mybb_adminoptions OK
chillor_lul.mybb_adminsessions OK
chillor_lul.mybb_adminviews OK
chillor_lul.mybb_announcements OK
...

You will notice the corrupt sql tables will be reported as corrupt by the tool and mysqlcheck will try it’s best to recover the corrupt tables.

In most cases this should be enough to recover corrupt tables.

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

Friday, November 23rd, 2012

Reading Time: 2minutes

 

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

Reading Time: 3minutesDisable 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

Reading Time: 2minutesSome 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

Solving “Cannot redeclare show_subscription_checkbox() (previously declared in .. wp-content/plugins/subscribe-to-comments/subscribe-to-comments.php”

Monday, March 21st, 2011

Reading Time: < 1minute
I’m trying to install subscribe-to-comments wordpress plugin in order to make my users to easily set a tick and receive new emails if somebody replies to their comments in my blog. Pitily downloading and trying to install the subscribe-to-comments wordpress plugin was failing after it’s activation with an error message:

PHP Fatal error: Cannot redeclare show_subscription_checkbox() (previously declared in /var/www/blog/wp-content/plugins/subscribe-to-comments/subscribe-to-comments.php:12) in /var/www/blog/wp-content/plugins/subscribe-to-comments.php on line 58"

I did my best to edit the subscribe-to-comments.php to fix up the fatal error but it was no go, so after a bunch of research I’ve found out somebody created a new version of the plugin under the name subscribe-to-comments-reloaded .

I’ve proceeded and gave a try to subscribe-to-comments-reloaded as a substitute to the old broken subscribe-to-comments .

Enabling the subscribe-to-commets-reloaded worked out of the box and the plugin now works perfectly fine and even better is enabling all the functionaity of the subscribe-to-comments
Cheers 🙂

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

Reading Time: < 1minute

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 fix “The function split() is deprecated in PHP 5.3” on FreeBSD

Saturday, May 28th, 2011

Reading Time: < 1minute
If you’re installing some PHP based CMS/blog like (Joomla or WordPress) or some kind of template and suddenly you stumble on a error:

Deprecated: Function split() is deprecated in /usr/local/www/websitedomain/templates/youbizz/html/modules.php on line 78

In order to fix that the file which spits the error message, in my case modules.php needs to be modified and the split php function has to be substituted with explode on every occuring place.

I experienced this error on FreeBSD 7_2 with php version 5.3.5 installed from ports.
This simple fix works fine.