Posts Tagged ‘configuration files’

VIM and VI UNIX text editor syntax highlighting and howto add remove code auto indent

Tuesday, February 4th, 2014

vim-vi-linux-text-editor-logo-vim-highlighting how to turn vim syntax highlighting on linux

For my daily system administration job I have to login to many SuSE Linux servers and do various configugration edits.
The systems are configured in different ways and the only text editors available across all servers I can use are VI and VIM (VI Improved).

As I usually had to edit configuration files and scripts and I'm on SSH color terminal its rather annoying that on some of the servers opening a file with VIM is not displayed with SYNTAX HIGHLIGHTING. Not having syntax highlighting is ugly and makes editting ugly and unreadable.
Thus it is useful to enable VI syntax highlighting straight into the file being editted. I suspect many novice sysadmins might not know how to turn syntax highlighting in vi so here is how.
 

Turn Syntax Highlighting in VIM

 

1. Open file with vim lets say Apache configuration

# vim /etc/apache2/apache2.conf

2. Press (Esc) Escape and ":" from kbd and then type in syntax on

:syntax on

vim-syntax-highlighting-howto-syntax-on-picture-screenshot-apache-config

To Turn On / Off VI Syntax Highlighting permanent add ":syntax on"
into ~/.vimrc

~/.vimrc file is red automatically on VIM start, so right after :syntax on is appended in it on relaunch vim will start showing colorfully.

Enjoy ! 🙂

 

Client Denied By Server Configuration Linux Apache error solution

Thursday, August 1st, 2013

Client denied by server configuration fix solution Apache feather logo

If you run Apache server on Debian Linux / Ubuntu / CentOS whatever Linux OS and you try to install a new PHP application under lets say /var/www/ getting an error in Apache error.log like:
 

[Wed Jul 31 03:36:21 2013] [error] [client 192.168.10.2] client denied by server configuration: /var/www/vea/index.php, referer: http://192.168.10.9/vea/


This is due to misconfigured AllowOverrides in some of your main configuration files.

So what is causing the error?

Reason is by default in most current Linux distributions Apache is configured to have restrictive policy following the good security practice (Restrictive by default).
Apache is configured by default to not accept AllowOverrides – i.e. AllowOverride None for DocumentRoot /, because there are plenty of administrators who run Apache without having profound understanding leaving it to interpret by default mod_rewrite rules from .htaccess files etc.

To fix this issue, hence you have to add extra configuration for AllowOverride directive for directory giving the err. In this case /vea:

<Directory /var/www/vea/> 
Options -Indexes FollowSymLinks
AllowOverride AuthConfig
FileInfo Order allow,deny
Allow from all
</Directory> 

Above rules are a bit restrictive and will allow only to have .htaccess with only for protecting directory with htaccess passsword for exmpl. – (AuthUserFile, AuthGroupFile, AuthName, AuthType) .htaccess.
-Indexes – instructs /var/www/vea directory listing to be disabled, below two lines:

Order allow, deny
Allow from all

Makes the directory Allowed to be visible by all, however note that it is possible in some of other Apache configuration files to have other rules configured for /vea documentroot /var/www/ which are preventive (Default Deny) – if this is the case just walk through all Apache configs and change where necessary to Allow from all.

In some cases it is possible Web application or Website placed requires AllowOverride All directive instead. If above <Directory>

does not help and you continue to get:

[Wed Jul 31 03:36:21 2013] [error] [client xxx.xxx.xx.x] client denied by server configuration: /var/www/php-application/index.php, referer: http://xxx.xxx.xx.xx/php-application/  

Try setting Directory rules with AllowOverride All ;

<Directory /var/www/php-application/> 
Options -Indexes FollowSymLinks
AllowOverride All
FileInfo Order allow,deny
Allow from all
</Directory> 

Debian / Ubuntu server admins should check closely for AllowOverride rules in files /etc/apache2/conf.d/*

as well as in /etc/apache2/mods-available/*:

Usually there are AllowOverride rules set from files:

/etc/apache2/conf.d/apache2-doc
/etc/apache2/conf.d/localized-error-pages
/etc/apache2/conf.d/security

and also in

/etc/apache2/mods-available/alias.conf
/etc/apache2/mods-available/userdir.conf

On Debian GNU / Linux, very common reason for getting client denied by server configuration is AllowOverride definitions in /etc/apache2/conf.d/security, default AllowOverride there are set to None, i.e.:

<Directory />
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

If that's the case with you make sure you config rules to become:

# <Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
# </Directory>

A very useful command to find where there is occurance of AllowOverride in Apache many configs is:

root@linux:~# cd /etc/apache2
root@linux:/etc/apache2# grep -rli AllowOverride *
apache2.conf
conf.d/localized-error-pages
conf.d/apache2-doc
conf.d/security
mods-available/userdir.conf
mods-available/alias.conf
sites-available/www.website1.com
sites-available/www.website2.com
...


 

Once you did all necessary config Restart Apache:

root@linux:~# /etc/init.d/apache2 restart
....

How to get rid of Debian and Ubuntu GNU / Linux obsolete configuration files and system directories

Wednesday, October 19th, 2011

debian_ubuntu-linux-get-rid-of-obsolete-files
I've been using Debian GNU / Linux on my Thinkpad laptop for almost 3 years and half. Initially the Debian version which I had installed was a stable Debian Lenny. As I was mostly dissatisfied of the old versions of the programs, I migrated to testing / unstable
Testing / unstables shipped program versions were a bit better but still back in the day I wanted to get advantage of the latest program versions so for a while I switched to unstable .
Later I regretted for this bad idea, after the migration to Unstable, it was too buggy to run on a notebook one uses for everyday work.
Then to revert back to a bit stable I downgraded to testing unstable again.
When Debian launched Debian Squeeze I set in my /etc/apt/sources.list file software repositories to be the one for the stable Debian Squeeze.

As you can see, I've done quite a lot of "experiments" and "excersises". Many packages were installed, then removed, some became obsolete with time others I just temporary installed out of curiosity. Anyways as a result I ended up with many packages uninstalled / removed , which still kept some of their directory structres and configurations on the machine.

Today, I decided to check how many of these obsolete packages are still present in dpkg database and I was shocked to find out 412 debs were still in my package database! To check the number I used cmd:

root@noah:~# dpkg -l | grep -i '^rcs.*$'|wc -l

Considering the tremendous number of packs waiting to be purged, I decided to get rid of this old and already unnecessery files for the sake of clarity, besides that removing the old already uninstalled packages removes old configuration files, readmes, directories and frees some little space and therefore frees some inodes 😉

Before proceeding to remove them, I carefully reviewed and all the package names which I was about to completely purge in order to make sure there is no package with a configuration files I might need in future:

root@noah:~# dpkg -l |grep -i '^rcs.*$'
...
After reviewing all the deb packages possessing the rc – (remove candidate) flag, I used the following bash one liners to remove the obsolete deb packages:

root@noah:~# for i in $(dpkg -l |grep -i '^rcs.*$'|awk '{ print $2 }'); do echo dpkg --purge $i done...
root@noah:~# for i in $(dpkg -l |grep -i '^rcs.*$'|awk '{ print $2 }'); do dpkg --purge $i done

First line will just print out what will be purged with dpkg , so after I checked it out I used the second one to purge all the RC packs.

How to configure networking in CentOS, Fedora and other Redhat based distros

Wednesday, June 1st, 2011

On Debian Linux I’m used to configure the networking via /etc/network/interfaces , however on Redhat based distributions to do a manual configuration of network interfaces is a bit different.

In order to configure networking in CentOS there is a special file for each interface and some values one needs to fill in to enable networking.

These network adapters configuration files for Redhat based distributions are located in the files:

/etc/sysconfig/network-scripts/ifcfg-*

Just to give you and idea on the content of this network configuration file, here is how it looks like:

[root@centos:~ ]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe
DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:19:99:9C:08:3A
IPADDR=192.168.0.1
NETMASK=255.255.252.0
ONBOOT=yes

This configuration is of course just for eth0 for other network card names and devices, one needs to look up for the proper file name which corresponds to the network interface visible with the ifconfig command.
For instance to list all network interfaces via ifconfig use:

[root@centos:~ ]# /sbin/ifconfig |grep -i 'Link encap'|awk '{ print $1 }'
eth0
eth1
lo

In this case there are only two network cards on my host.
The configuration files for the ethernet network devices eth0 and eth1 from below example are located in files /etc/sysconfig/network-scripts/ifcfg-eth{1,2}

/etc/sysconfig/network-scripts/ directory contains plenty of shell scripts related to Fedora networking.
This directory contains actually the networking boot time load up rules for fedora and CentOS hosts.

The complete list of options available which can be used in /etc/sysconfig/network-scripts/ifcfg-ethx is located in:
/usr/share/doc/initscripts-*/sysconfig.txt

, to quickly observe the documentation:

[root@centos:~ ]# less /usr/share/doc/initscripts-*/sysconfig.txt

One typical example of configuring a CentOS based host to possess a static IP address (192.168.1.5) and a gateway (192.168.1.1), which will be assigned in boot time during the /etc/init.d/network is loaded is:

[root@centos:~ ]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe
IPV6INIT=no
BOOTPROTO=static
ONBOOT=yes
USERCTL=yes
TYPE=Ethernet
DEVICE=eth0
IPADDR=192.168.1.5
NETWORK=192.168.1.0
GATEWAY=192.168.1.1
BROADCAST=192.168.1.255
NETMASK=255.255.255.0

After some changes to the network configuration files are made, to load up the new rules a /etc/init.d/network script restart is necessery with the command:

[root@centos:~ ]# /etc/init.d/network restart

Of course one can always use /etc/rc.local script as universal way to configure network rules on a Redhat based host, however using methods like rc.local to load up, ifconfig or route rules in a Fedora would break the distribution logic and therefore is not recommended.

There is also a serious additional reason against using /etc/rc.local post init commands load up script.
If one uses rc.local to load up and configure the networing, the network will get initialized only after all the other scripts in /etc/init.d/ gets started.

Therefore using /etc/rc.local might also be DANGEROUS!, if used remotely via (ssh), supposedly it might completely fail to load the networking, if all bringing the server interfaces relies on it.

Here is an example, imagine that some of the script set in to load up during a CentOS boot up hangs and does continue to load forever (for example after some crucial software upate), as a consequence the /etc/rc.local script will never get executed as it only starts up after all the rest init scripts had succesfully completed execution.

A network eth1 interface configuration for a Fedora host which has to fetch it’s network settings automatically via DHCP is as follows:

[root@fedora:/etc/network:]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Intel Corporation 82557/8/9 [Ethernet Pro 100]DEVICE=eth1
BOOTPROTO=dhcp
HWADDR=00:0A:E4:C9:7B:51
ONBOOT=yes

To sum it up I think Fedora’s /etc/sysconfig/network-scripts methodology to configure ethernet devices is a way inferior if compared to Debian.

In GNU/Debian Linux configuration of all networking is (simpler)!, everything related to networking is in one single file ( /etc/network/interfaces ), moreover getting all the thorough documentation for the network configurations options for the interfaces is available as a system wide manual (e.g. man interfaces).

Partially Debian interfaces configuration is a bit more complicated in terms of syntax if matched against Redhat’s network-scripts/ifcfg-*, lest that generally I still find Debian’s manual network configuration interface to be easier to configure networking manually vicommand line.

Qmail’s Voodoo spells and magics ! Workarounds to some common problems, QMAIL HELL!

Friday, October 2nd, 2009

It's one of this days, when you'd wish to be dead and never born ever!

I experienced terrible problems with Qmail once AGAIN!

Most of the qmail administrators out there are probably aware, Everytime qmail stops working it's like

walking in a dark room without a light torch before you fix it up.

To fix a broken qmail your only friend could be patience. It's fucking insane seriously I more and more start hating qmail when it's broken.

I've experienced the following error messages today on our corporate qmail:

delivery xx: failure: Sorry._Although_I'm_listed_as_a_best-preference_MX_or_A_for_that_host,/it_isn't_in_my_control/locals_file,_so_I_don't_treat_it_as_local.

as well as:

delivery 232: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/

A lot of this junk filled the qmail logs. I still am not completely sure the exact reasons

what caused the problems. However I fixed the situation tweakening some of the common

qmail and vpopmail configuration files and respectively their cdb files.

Here is the list of files I got to rebuild and the things I've did to resolve the qmail issues:

cd /home/vpopmail/domains;
for i in *; do echo +$i-:$i:89:89:/home/vpopmail/domains/$i:-:: >>assign; done
# backup old assign file just in case something goes wrong
cp -rpf /var/qmail/users/assign /var/qmail/users/assign.bak
mv assign /var/qmail/users/assign

# backup virtualdomains list file
cp -rpf /var/qmail/control/virtualdomains /var/qmail/control/virtualdomains.bak
for i in *; do echo $i:$i >>virtualdomains; done
mv virtualdomains /var/qmail/control/

# Make sure your /var/qmail/control/rcpthosts contains all the vpopmail domains
# backup rcpthosts for laters
cp -rpf /var/qmail/control/rcpthosts /var/qmail/control/rcpthosts.bak
for i in *; do echo $i >>rcpthosts; done
cp -rpf rcpthosts /var/qmail/control/
# backup morercpthosts
cp -rpf morercpthosts /var/qmail/control/morercpthosts.bak
# overwrite the old morercpthosts
# in my case morercpthosts was missing all the vpopmail virtual domains
# thus the domains missing the file wasn't able to receive mail
cp -rpf rcpthosts /var/qmail/control/morercpthosts

# Another problem if you're using qmail check user patch might be in /var/qmail/users/recipients
# Thus rebuilding the recipients file is a good idea.
# Rebuilding it might be done through qmail-vpopmail2recipients script
# the script has a bug the last if statement, where two if's have to be commented to make it wokring
# Below I'll put a link to a working version of the qmail-vpopmail2-recipients script

# Another possible problem could be in /var/qmail/users/cdb
# Therefore it might be a good idea to rebuild it with
/var/qmail/bin/qmail-newu
# Another thing to do is to rebuild the /var/qmail/control/morercpthosts.cdb file with the command
/var/qmail/bin/qmail-newmrh
# Other things I did was
# to assure myself that /var/qmail/control/me contains my mail server host name
# /var/qmail/control/locals should contain "localhost" as well as the FQDN (Fully Qualified Domain Name) (e.g. your domain name)

# Also I checked my /etc/tcp.smtp and assured myself everything is correct there.
# After which I executed
qmailctl cdb
# That rebuilded my /etc/tcp.smtp.cdb file
# Well that was mostly what I did to fix my problems.
# Another think that might be a good idea is to try
cd /home/vpopmail/domains;
for i in *; do /home/vpopmail/bin/vdominfo $i; done
# If you observe some domain's domain info cannot be shown
# then that might be due to some problem with your vpopmail
# It might be a good idea to check your
/var/qmail/bin/qmail-showctl
# qmail-showctl is a handy diagnosis qmail tool
# While looking over the command output
# I had to make sure my cdb files are "Modified Recently"
# and my virtualdomains are all showing up
# THat's mostly what fixed qmail for me
# Next I executed
qmailctl stop; sleep 10; qmailctl start
# that restarted my qmail
# However qmail doesn't always start logging to /var/log/qmail directory right away
# after restart
# SOmetimes the qmail server needs a couple of restarts before it starts serving mail
# Thus restarting it is always full of uncertancies and a lot of broken nerves!

I love qmail it absolutely works brilliant as long as it works, quite often

if you do even minor changes that usually means a broken qmail and qmail hell again!

I truly hope this post could be helpful to somebody out there

Here is a link to a working version of qmail-vpopmail2-recipients