Posts Tagged ‘boot time’

How to Remove / Add SuSE Linux start service command

Thursday, July 2nd, 2015

If you happen to administer SUSE LINUX Enterprise Server 9 (x86_64) and you need to add or remove already existing /etc/init.d script or custom created Apache / Tomcat .. etc. service and you're already familiar with Fedora's / RHEL chkconfig, then the good news chkconfig is also available on SuSE and you can use in same way chkconfig to start / stop / enable / disable boot time services.

To list all available boot time init.d services use:

suse-linux:/etc # chkconfig –list


SuSEfirewall2_final       0:off  1:off  2:off  3:off  4:off  5:off  6:off
SuSEfirewall2_init        0:off  1:off  2:off  3:off  4:off  5:off  6:off
SuSEfirewall2_setup       0:off  1:off  2:off  3:off  4:off  5:off  6:off
Tivoli_lcfd1.bkp          0:off  1:off  2:off  3:off  4:off  5:off  6:off
activate_web_all          0:off  1:off  2:off  3:on   4:off  5:on   6:off
alsasound                 0:off  1:off  2:on   3:on   4:off  5:on   6:off
apache2                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
apache2-eis               0:off  1:off  2:off  3:on   4:off  5:off  6:off
atd                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
audit                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
autofs                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
autoyast                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.clock                0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.crypto               0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.device-mapper        0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.evms                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.idedma               0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.ipconfig             0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.isapnp               0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.klog                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.ldconfig             0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.loadmodules          0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.localfs              0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.localnet             0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.lvm                  0:off  1:off  2:off  3:off  4:off  5:off  6:off                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.multipath            0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.proc                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.restore_permissions  0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.rootfsck             0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.sched                0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.scpm                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.scsidev              0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.shm                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.swap                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.sysctl               0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.udev                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
coldplug                  0:off  1:on   2:on   3:on   4:off  5:on   6:off


To then stop the service:

suse-linux:/etc # chkconfig gtiweb off

If you prefer to do it the SuSE way and learn a bit more on SuSE boot time process check out:


suse-linux:/etc # man insserv

Removing already existing SuSE start-up script from init.d start up with insserv is done with:

suse-linux:/etc # cd /etc/init.d/
suse-linux:etc/init.d # insserv -r gtiweb
insserv: script ipmi.hp: service ipmidrv already provided!
insserv: script boot.multipath.2008-10-29: service boot.multipath already provided!

To install a new custom written and placed into /etc/inti.d/ on SuSE's server boot time with insserv:


suse-linux:/etc/init.d/ # insserv your_custom_script_name

How to stop / start services in boot time and install / remove / update SuSE SLES (Suse Enterprise Linux Server)?

Friday, February 6th, 2015

If you're long time Linux sysadmin but you haven't need to adminster SuSE Linux still and your company buys other business / company which already owns some SuSE servers and you need to deal with them, even though you're just starting up with SuSE Linux but you had already plenty of experience with other Linux distributions Fedora / RHEL / CentOS, don't worry set up / stop / start a service (daemon) to boot on Linux boot time is just the same as any other Redhat (RPM) Linux based distributions. it is done by multiple shell scripts located in /etc/init.d directory which can be manually stopped start by issuing the script with an argument e.g

suse:/etc/init.d# cd /etc/init.d/
suse:/etc/init.d# ./snmpd 
Usage: ./snmpd {start|stop|try-restart|restart|force-reload|reload|status}

To configure how each of the /etc/init.d/ existent service boots you can the use good old /sbin/chkconfig (a script written in perl) – which you already know from Fedora / CentOS and other RPM distros.

1. Get a list of all enabled on boot SuSE Linux services

To get a list of all set up to run on boot SuSE server services with chkconfig:


suse:/etc/init.d# /sbin/chkfong –list 

Makefile                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
OVCtrl                    0:off  1:off  2:off  3:on   4:on   5:on   6:off
SuSEfirewall2_init        0:off  1:off  2:off  3:off  4:off  5:off  6:off
SuSEfirewall2_setup       0:off  1:off  2:off  3:off  4:off  5:off  6:off
Tivoli_lcfd1              0:off  1:off  2:on   3:on   4:off  5:on   6:off
Tivoli_lcfd1.bkp          0:off  1:off  2:off  3:off  4:off  5:off  6:off
aaeventd                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
acpid                     0:off  1:off  2:on   3:on   4:off  5:on   6:off
alsasound                 0:off  1:off  2:on   3:on   4:off  5:on   6:off
apache2-eis               0:off  1:off  2:off  3:off  4:off  5:off  6:off
atd                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
auditd                    0:off  1:off  2:off  3:on   4:off  5:on   6:off
autofs                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
autoyast                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
boot.apparmor             0:off  1:off  2:on   3:on   4:off  5:on   6:off  B:on
cron                      0:off  1:off  2:on   3:on   4:off  5:on   6:off
dbus                      0:off  1:off  2:off  3:on   4:off  5:on   6:off
earlykbd                  0:off  1:off  2:off  3:off  4:off  5:on   6:off
earlysyslog               0:off  1:off  2:off  3:off  4:off  5:on   6:off
esound                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
evms                      0:off  1:off  2:off  3:off  4:off  5:off  6:off
fbset                     0:off  1:on   2:on   3:on   4:off  5:on   6:off
firstboot                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
fixperms                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
gpm                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
gssd                      0:off  1:off  2:off  3:off  4:off  5:off  6:off
gwproxy                   0:off  1:off  2:on   3:on   4:off  5:on   6:off
haldaemon                 0:off  1:off  2:off  3:on   4:off  5:on   6:off
hp-health                 0:off  1:off  2:on   3:on   4:on   5:on   6:off
hp-ilo                    0:off  1:off  2:off  3:on   4:off  5:on   6:off
hp-snmp-agents            0:off  1:off  2:on   3:on   4:on   5:on   6:off
hpsmhd                    0:off  1:off  2:off  3:on   4:on   5:on   6:off
idmapd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
ipmi                      0:off  1:off  2:off  3:off  4:off  5:off  6:off
ipmi.hp                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
irq_balancer              0:off  1:on   2:on   3:on   4:off  5:on   6:off
itcaIBMTivoliCommonAgent0  0:off  1:off  2:on   3:on   4:off  5:on   6:off
jboss                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
joystick                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
kadmind                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
kbd                       0:off  1:on   2:on   3:on   4:off  5:on   6:off  S:on
kdump                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
kpropd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
krb524d                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
krb5kdc                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
ldap                      0:off  1:off  2:off  3:on   4:off  5:on   6:off
lm_sensors                0:off  1:off  2:off  3:off  4:off  5:off  6:off
lw_agt                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
mdadmd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
microcode                 0:off  1:on   2:on   3:on   4:off  5:on   6:off  S:on
multipathd                0:off  1:off  2:off  3:off  4:off  5:off  6:off
mysql                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
network                   0:off  1:off  2:on   3:on   4:off  5:on   6:off
nfs                       0:off  1:off  2:off  3:on   4:off  5:on   6:off
nfsboot                   0:off  1:off  2:off  3:on   4:off  5:on   6:off
nfsserver                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
nohup.out                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
novell-zmd                0:off  1:off  2:off  3:off  4:off  5:off  6:off
nscd                      0:off  1:off  2:off  3:on   4:off  5:on   6:off
ntp                       0:off  1:off  2:on   3:on   4:off  5:on   6:off
openct                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
opsware-agent             0:off  1:off  2:off  3:on   4:on   5:on   6:off
osddownt                  0:off  1:off  2:off  3:on   4:on   5:on   6:off
ovpa                      0:on   1:off  2:on   3:on   4:off  5:on   6:off
pcscd                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
pctl                      0:off  1:off  2:on   3:on   4:off  5:on   6:off
portmap                   0:off  1:off  2:off  3:on   4:off  5:on   6:off
postfix                   0:off  1:off  2:off  3:on   4:off  5:on   6:off
powerd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
powersaved                0:off  1:off  2:off  3:off  4:off  5:off  6:off
random                    0:off  1:off  2:on   3:on   4:off  5:on   6:off
raw                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
resmgr                    0:off  1:off  2:on   3:on   4:off  5:on   6:off
rpasswdd                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
rpmconfigcheck            0:off  1:off  2:off  3:off  4:off  5:off  6:off
rrdtools                  0:off  1:off  2:off  3:on   4:off  5:on   6:off
rsyncd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
saslauthd                 0:off  1:off  2:off  3:off  4:off  5:off  6:off
skeleton.compat           0:off  1:off  2:off  3:off  4:off  5:off  6:off
slurpd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
smartd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
smpppd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
snmpd                     0:off  1:off  2:on   3:on   4:off  5:on   6:off
splash                    0:off  1:on   2:on   3:on   4:off  5:on   6:off  S:on
splash_early              0:off  1:off  2:on   3:on   4:off  5:on   6:off
sshd                      0:off  1:off  2:off  3:on   4:off  5:on   6:off
suseRegister              0:off  1:off  2:off  3:off  4:off  5:off  6:off
svcgssd                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
syslog                    0:off  1:off  2:on   3:on   4:off  5:on   6:off
sysstat                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
tecad_logfile             0:off  1:off  2:off  3:on   4:off  5:on   6:off
tomcat55                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
tomcat_eis                0:off  1:off  2:off  3:off  4:off  5:off  6:off             0:off  1:off  2:on   3:on   4:off  5:on   6:off
uc4_smgrp                 0:off  1:off  2:off  3:on   4:off  5:on   6:off
uc4_smgrq1                0:off  1:off  2:off  3:on   4:off  5:on   6:off
xbis-ldap-tool            0:off  1:off  2:off  3:off  4:off  5:off  6:off
xdm                       0:off  1:off  2:off  3:off  4:off  5:on   6:off
xfs                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
xinetd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
ypbind                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
xinetd based services:
        chargen:            off
        chargen-udp:        off
        daytime:            off
        daytime-udp:        off
        echo:               off
        echo-udp:           off
        netstat:            off
        rsync:              off
        servers:            off
        services:           off
        systat:             off
        time:               off
        time-udp:           off


2. Stop / Disable a service in all Linux boot runlevels or in a concrete one

As you should know already in Linux there are multiple runlevels in which server can boot, under normal circumstances SuSE servers (as of time of writting) this article boots into runlevel 3, if you'r'e  unsure about the runlevel you can check it with runlevel command:

 suse:/etc/init.d# /sbin/runlevel
N 3

To stop a service on all possible boot runlevels – 1,2,3,4,5

suse:/etc/init.d# /sbin/chkconfig xinetd off

If you want to stop xinetd or any other service just for certain runlevels (lets say run-level 3,4,5):

suse:/etc/init.d# chkconfig –level 345 xinetd off


3. Start / Enable a service for a runlevel or all boot levels 1,2,3,4,5

To disable boot.apparmor on all boot runlevels –  kernel enhancement that enabled to set a limited set of resources for services (good for tightened security, but often creating issues with some external server configured services).

suse:/etc/init.d# chkconfig boot.apparmor off

Or for single boot modes again with –level option:

suse:/etc/init.d# chkconfig –level 345 boot.apparmor off


suse:/etc/init.d# chkconfig xfs off 

4. SuSE Linux Package management zypper console tool

If you need / wonder how to install /remove / update a service on a SuSE Linux server, take a look at zypper tool.
zypper is  a  command-line  interface to ZYPP system management library.

To install a package / service with zypper the syntax is very much like yum, for example:

suse: ~# zypper install vim -emacs


will remove emacs editor and install Vi Improved

The equivalent of yum -y  Fedora command in SuSE Enterprise Linux is –non-interactive option


suse:~# zypper –non-interactive install


In SuSE it is pretty annoying when you're asked for accepting licensing on some proprietary (external vendor) non-free software packages to get around this:

suse:~# zypper patch –auto-agree-with-licenses

To keep the SuSE server up2date – i.e. SLES equivalent of CentOS's yum update && yum upgrade


suse:~# zypper list-patches
Loading repository data…
Reading installed packages…
Repository                          | Name      | Version | Category | Status
Updates for openSUSE 11.3 11.3-1.82 | lxsession | 2776    | security | needed




suse:~# zypper patch-check
Loading repository data…
Reading installed packages…
5 patches needed (1 security patch)

To look for a certain package with Zypper (equivalent of yum search packagename)

suse: ~# zypper search apache

To verify whether an RPM installed package dependecies are OK:

suse:~# zypper verify

The equivalent of Fedora yum update command in SuSE (SLES) are:

suse:~# zypper refresh

To force a complete refresh and rebuild of the database, including a forced download of raw metadata.

suse:~# zypper refresh -fdb


For people that are used to ncurses (midnight commander) like text interface you can also use yoast2 (text GUI) package manager:

suse:~# yoast2


If a package is messed you can always go back and use good old RPM (Redhat Package Manager) to solve it.


Set ISP provider default DNS to overwrite DHCP settings on Debian / Ubuntu Linux

Monday, February 11th, 2013

dhcp linux ovewrite dns settings from console and terminal Debian Ubuntu Fedora CentOS Linux

These days, almost every home wireless ISP network router, ADSL modem etc. has its own local running DNS service. Generally this is very good as it puts off the burden of  Internet Service Provider DNS servers and "saves" multitude of users from so common overloads with ISP DNS Servers – caused by ISP DNS Service unable to handle the incoming user DNS (Domain resolve) traffic. Common scenario, where ISP DNS servers is unable to handle DNS traffic is when few thousands of users belonging to ISP gets infected with a Worm, Trojan horse or Virus doing plenty of DNS Spoofs and distributed DDoS attacks.

Though local DNS service (daemons) on local Cable and Wireless Network Routers is something designed to be good it becomes another bottleneck for DNS resolve problems, Calling the ISP tech support for help is often loose of time, as  in ISPs it is so rare to find someone understanding Linux Networking.

The periodic issues with DNS resolving from home routers in my observations has 3 main reasons;

  • Local Cheap network Wireless routers with slow hardware (CPU) and little memory are unable to handle DNS requests, because of torrent Downloads
  • DNS Wireless Router can't handle DNS requests to its DNS local service, because a small local network of computers with a landline and wireless (lets say 5 to 10) is trying to access the Internet (browsing) – again due to its low hardware paremeters router CPU heats up cause of multitude of DNS requests


  • Something is wrong with general network topology of PCs behind the router. Often people buy a router and use it shared with their neighbors – tampering with Router settings messing it up.

DNS resolving problems are even harder to track whether Internet provider has policy to deliver Internet via automated IP assignment protocol (DHCP),

A very common scenario, I've seen is Internet coming via ISP ADSL / Network router installed at home and mis-configured due to a custom user installation,   or because of ISP technician who installed router in hurry or lacked good competency and messed up with Router Network configuration.

During the years I had to install various Linux distributions for Desktop use in networks located behind such mis-configured Network Hubs. Because of this mis-configured DNS, even though Linux hosts succesfully graps the IP addresses for host IP, Gateway and DNS, they occasionally create problems with Internet Connection leaving the user with impression that Linux is not ready for Desktop use or somehow it is the the Linux distro fault.

After giving an introduction I will continue further to exact problem I've faced with one such mis-configured just today. The same issue has happened in my sysadmin practice over and over again so many times. So finally I decided to write this small story explaining the whole scenario, its causes and fix.

I'm writing this little post from another Linux installation like this which is living on a small local network served by a Vivacom ISP through ADSL Commtrend SmartAX MT882 Router.

The Commtrend does NAT (Network Address Translation)-ting for whole local network, auto-assigning some DNS server to Natted IP PCs local Network addresses in IP raneg; ( The DNS the router assigns for internet is with IP (, where in reality the DNS on the router is run on Network interface with IP 1921.68.1.1, in other words belonging to the router from another network. Thus PCs connected via a UTP land-line cable connection does not see – meaning Domain name resolving works not at all.
The solution is to assign a static IP address for DNS of Google Public DNS or Open DNS, while leaving the Linux host to automatically assign LAN IP and Gateway using DHCP – (Dynamic Host Configuration Protocol).

By default most Linux distributions use DNS configured in /etc/resolv.conf as a host DNS servers, however as CommTrend Network Router does provide settings for DNS Servers to be used for resolving along with other settings on each Linux host boot settings from /etc/resolv.conf gets ovewritted with the unreachable (from, nameserver

Thus to work-around this on most all Linux distributions you can set /etc/resolv.conf to be overwritten adding a line to /etc/rc.local script (before its last line – exit 0);

echo 'nameserver' > /etc/resolv.conf
echo 'nameserver' >> /etc/resolv.conf

This method is universal, but the problem with it arises, if on the Linux host is planned to run 24 hours a day. DHCP Servers on router has configured DHCP Expiry lease time, which is different on different routers but usually few hours i.e. (4 hrs). Thus in 4 hours, due to DHCP Lease expiry the Linux host will question the DHCP Server for IP, getting together with DHCP IP and Gateway Settings also a DNS IP (overwritting again /etc/resolv.conf – with local running ISP Router IP – One stupid solution of course is to use good old Windows philosophy (reboot it and it will work).

Other little more intelligent but not very efficient solution to problem is to set a cronjob, to run every 1 minute and overwrite /etc/resolv.conf DNS setting.

# crontab -u root -e

*/1 * * * * echo -e 'nameserver\nnameserver' > /etc/resolv.conf >/dev/null 2>&1

Since the cronjob to overwrite DNS IPs runs every one minute it is possible the host ends up without internet from few secs to 1 minute, this might happen quite rare so for a desktop this is ok. Other inconvenience is it puts a tiny load on system every 1 minute.

Final and best solution is to configure DNS server from /etc/dhcp/dhclient.conf  for Ethernet Interface eth0. Inside /etc/dhcp/dhclient.conf for eth0 make sure you have:

# vi /etc/dhcp/dhclient.conf

interface "eth0" {
prepend domain-name-servers;
prepend domain-name-servers;
prepend domain-name-servers;
prepend domain-name-servers;

Fix “Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.” in FreeBSD

Monday, May 21st, 2012


I'm running FreeBSD with Apache and PHP on it and I got in dmesg (kernel log), following error:

freebsd# dmesg|grep -i vm.pmap.shpgperproc
Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.

The exact FreeBSD, Apache and php versions I have installed are:

freebsd# uname -a ; httpd -V ; php –version
FreeBSD pcfreak 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 i386
Server version: Apache/2.0.64
Server built: Mar 13 2011 23:36:25Server's Module Magic Number: 20050127:14
Server loaded: APR 0.9.19, APR-UTIL 0.9.19
Compiled using: APR 0.9.19, APR-UTIL 0.9.19
Architecture: 32-bit
Server compiled with….
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D HTTPD_ROOT="/usr/local"
-D SUEXEC_BIN="/usr/local/bin/suexec"
-D DEFAULT_PIDLOG="/var/run/"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="etc/apache2/httpd.conf"
PHP 5.3.5 with Suhosin-Patch (cli) (built: Mar 14 2011 00:29:17)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator

After a bunch of research a FreeBSD forums thread , I've found the fix suggested by a guy.

The solution suggested in the forum is to raise up vm.pmap.pv_entry_ma to vm.pmap.pv_entry_max=1743504, however I've noticed this value is read only and cannot be changed on the BSD running kernel;

freebsd# sysctl vm.pmap.pv_entry_max=1743504
sysctl: oid 'vm.pmap.pv_entry_max' is read only

Instead to solve the;

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable.
, I had to add in /boot/loader.conf


Adding this values through /boot/loader.conf set them on kernel boot time. I've seen also in the threads the consider increasing either the vm.pmap.shpgperproc is also encountered on FreeBSD hosts running Squid, Dansguardion and other web proxy softwares on busy hosts.

This problems are not likely to happen for people who are running latest FreeBSD releases (>8.3, 9.x), I've read in same above post in newer BSD kernels the vm.pmap is no longer existing in newer kernels.

How to disable ACPI (power saving) support in FreeBSD / Disable acpi on BSD kernel boot time

Tuesday, May 15th, 2012

FreeBSD disable ACPI how ACPI Basic works basic diagram

On FreeBSD the default kernel is compiled to support ACPI. Most of the modern PCs has already embedded support for ACPI power saving instructions.
Therefore a default installed FreeBSD is trying to take advantage of this at cases and is trying to save energy.
This is not too useful on servers, because saving energy could have at times a bad impact on server performance if the server is heavy loaded at times and not so loaded at other times of the day.

Besides that on servers saving energy shouldn't be the main motivator but server stability and productivity is. Therefore in my personal view on FreeBSD used on servers it is better to disable complete the ACPI in order to disable CPU fan control to change rotation speeds all the time from low to high rotation cycles and vice versa at times of low / high server load.

Another benefit of removing the ACPI support on a server is this would probably increase the CPU fan life span and possibly prevent the CPU to be severely heated at times.

Moreover, some piece of hardware might have troubles in properly supporting ACPI specifications and thus ACPI could be a reason for unexpected machine hang ups.

With all said I would recommend to anyone willing to use BSD for a server to disable the ACPI (Advanced Configuration and Power Interface), just like I did.

Here is how;

1. Quick review on how ACPI is handled on FreeBSD

acpi support is being handled on FreeBSD by a number of loadable kernel modules, here is a complete list of all the kernel modules dealins with acpi:

freebsd# cd /boot
freebsd# find . -iname '*acpi*.ko'

By default on FreeBSD, if hardware has some support for ACPI the acpi gets activated by acpi.ko kernel module. The specific type of vendors specific ACPI like IBM, ASUS, Fujitsu are controlled by the respective kernel module from the list …

Hence, to control if ACPI is loaded or not on a FreeBSD system with no need to reboot one can use kldload, kldunload module management BSD cmds.

a) Check if acpi is loaded on a BSD

freebsd# kldstatkldstat | grep -i acpi
9 1 0xc9260000 57000 acpi.ko

b) unload kernel enabled ACPI support

freebsd# kldunload acpi

c) Load acpi support (not the case with me but someone might need it, if for instance BSD is running on laptop)

freebsd# kldload acpi

2. Disabling ACPI to load on bootup on BSD

a) In /boot/loader.conf add the following variables:


b) in /boot/device.hints add:


c) in /boot/defaults/loader.conf make sure:

### ACPI settings ##########################################
acpi_dsdt_load="NO" # DSDT Overriding
acpi_dsdt_type="acpi_dsdt" # Don't change this
# Override DSDT in BIOS by this file
acpi_video_load="NO" # Load the ACPI video extension driver

d) disable ACPI thermal monitoring

It is generally a good idea to disable the ACPI thermal monitoring, as many machines hardware does not support it.

To do so in /boot/loader.conf add


If you want to learn more on on how ACPI is being handled on BDSs check out:

freebsd# man acpi

Other alternative method to permanently wipe out ACPI support is by not compiling ACPI support in the kernel.
If that's the case in /usr/obj/usr/src/sys/GENERIC make sure device acpi is commented, e.g.:

##device acpi


How to install and configure NTP Server (ntpd) to synchronize Linux server clock over the Internet on CentOS, RHEL, Fedora

Thursday, February 9th, 2012

Every now and then I have to work on servers running CentOS or Fedora Linux. Very typical problem that I observe on many servers which I have to inherit is the previous administrator did not know about the existence of NTP (Network Time Protocol) or forgot to install the ntpd server. As a consequence the many installed server services did not have a correct clock and at some specific cases this caused issues for web applications running on the server or any CMS installed etc.

The NTP Daemon is existing in GNU / linux since the early days of Linux and it served quite well so far. The NTP protocol has been used since the early days of the internet and for centuries is a standard protocol for BSD UNIX.

ntp is available in I believe all Linux distributions directly as a precompiled binary and can be installed on Fedora, CentOS with:

[root@centos ~]# yum install ntp

ntpd synchronizes the server clock with one of the /etc/ntp.conf defined RedHat NTP list


To Synchronize manually the server system clock the ntp CentOS rpm package contains a tool called ntpdate :
Hence its a good practice to use ntpdate to synchronize the local server time with a internet server, the way I prefer to do this is via a government owned ntp server, e.g.

[root@centos ~]# ntpdate
8 Feb 14:21:03 ntpdate[9855]: adjust time server offset -0.003770 sec

Alternatively if you prefer to use one of the redhat servers use:

[root@centos ~]# ntpdate
8 Feb 14:20:41 ntpdate[9841]: adjust time server offset 0.005671 sec

Now as the system time is set to a correct time via the ntp server, the ntp server is to be launched:

[root@centos ~]# /etc/init.d/ntpd start

To permanently enable the ntpd service to start up in boot time issue also:

[root@centos ~]# chkconfig ntpd on

Using chkconfig and /etc/init.d/ntpd cmds, makes the ntp server to run permanently via the ntpd daemon:

[root@centos ~]# ps ax |grep -i ntp
29861 ? SLs 0:00 ntpd -u ntp:ntp -p /var/run/ -g

If you prefer to synchronize periodically the system clock instead of running permanently a network server listening (for increased security), you should omit the above chkconfig ntpd on and /etc/init.d/ntpd start commands and instead set in root crontab the time to get synchronize lets say every 30 minutes, like so:

[root@centos ~]# echo '30 * * * * root /sbin/ntpd -q -u ntp:ntp' > /etc/cron.d/ntpd

The time synchronization via crontab can be also done using the ntpdate cmd. For example if you want to synchronize the server system clock with a network server every 5 minutes:

[root@centos ~]# crontab -u root -e

And paste inside:

*/5 * * * * /sbin/ntpdate 2>1 > /dev/null

ntp package is equipped with ntpq Standard NTP Query Program. To get very basic stats for the running ntpd daemon use:

[root@centos ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
B1-66ER.matrix. 2 u 47 64 17 149.280 41.455 11.297
*ponderosa.piney 2 u 27 64 37 126.933 32.149 8.382
www2.bitvector. 2 u 1 64 37 202.433 12.994 13.999
LOCAL(0) .LOCL. 10 l 24 64 37 0.000 0.000 0.001

The remote field shows the servers to which currently the ntpd service is connected. This IPs are the servers which ntp uses to synchronize the local system server clock. when field shows when last the system was synchronized by the remote time server and the rest is statistical info about connection quality etc.

If the ntp server is to be run in daemon mode (ntpd to be running in the background). Its a good idea to allow ntp connections from the local network and filter incoming connections to port num 123 in /etc/sysconfig/iptables :

-A INPUT -s -m state --state NEW -p udp --dport 123 -j ACCEPT
-A INPUT -s -m state --state NEW -p udp --dport 123 -j ACCEPT
-A INPUT -s -m state --state NEW -p udp --dport 123 -j DROP

Restrictions on which IPs can be connected to the ntp server can also be implied on a ntpd level through /etc/ntp.conf. For example if you would like to add the local network IPs range to access ntpd, in ntpd.conf should be added policy:

# Hosts on local network are less restricted.
restrict mask nomodify notrap

To deny all access to any machine to the ntpd server add in /etc/ntp.conf:

restrict default ignore

After making any changes to ntp.conf , a server restart is required to load the new config settings, e.g.:

[root@centos ~]# /sbin/service ntpd restart

In most cases I think it is better to imply restrictions on a iptables (firewall) level instead of bothering change the default ntp.conf

Once ntpd is running as daemon, the server listens for UDP connections on udp port 123, to see it use:

[root@centos ~]# netstat -tulpn|grep -i ntp
udp 0 0* 29861/ntpd
udp 0 0* 29861/ntpd
udp 0 0* 29861/ntpd
udp 0 0* 29861/ntpd


How to enable AUTO fsck (ext3, ext4, reiserfs, LVM filesystems) checking on Linux boot through /etc/fstab

Tuesday, July 12th, 2011

How to auto FSCK manual fsck screenshot

Are you an administrator of servers and it happens a server is DOWN.
You request the Data Center to reboot, however suddenly the server fails to boot properly and you have to request for IPKVM or some web java interface to directly access the server physical terminal …

This is a very normal admin scenario and many people who have worked in the field of remote system administrators (like me), should have experienced that bad times multiple times.

Sadly enough only a insignifant number of administrators try to do their best to reduce this down times to resolve client stuff downtime but prefer spending time playing the ztype! game or watching some porn website 😉

Anyways there are plenty of things like Server Auto Reboot on Crash with software Watchdog etc., that we as sysadmins can do to reduce server downtimes and most of the manual human interactions on server boot time.

In that manner of thougts a very common thing when setting up a new Linux server that many server admins forget or don’t know is to enable all the server partition filesystems to be auto fscked during server boot time.

By not enabling the auto filesystem check options in Linux the server filesystems did not automatically scan and fix hard drive partitions for fs innode inconsistencies.
Even though the filesystems are tuned to automatically get checked on every 38 system reboots, still if some kind of filesystem errors are found that require a manual confirmation the boot process is interrupted and the admin ends up with a server which is not reachable remotely via ssh !

For the remote system administrator, this times are a terrible times of waitings, prayers and hopes that the server hardware is fine 😉 as well as being on hold to get a KVM to get into the server manually and enter the necessery input to fsck prompt.

Many of this bad times can be completely avoided with a very simple fix through /etc/fstab by enabling all server partitions containing any filesystem to be automatically checked and fixed in case if inconsistencies or errors are found by fsck.ext3, fsck.ext4, fsck.reiserfs etc. commands.

A very typical default /etc/fstab file you will find on many servers should look something like:

/dev/sda8 / ext3 errors=remount-ro 0 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sda1 /home ext3 defaults 0 0

Notice the line:
/dev/sda1 /home ext3 defaults 0 0

The first column in the example contains the device name, the second one its mount point, third its filesystem type, fourth the mount options, fifth (a number) dump options, and sixth (another number) filesystem check options. Let’s take a closer look at this stuff.

The ones which are interesting to enable auto fsck checking and error resolving is provided usually by the last sixth variable (filesystem check option) which in the above example equals 0 .

When the filesystem check option equals 0 this means the auto fsck and repair for the respective filesystem is disabled.
Some time in the past the dump backup option (5th option in the example) was also used but as far as I can understand today it’s not that important in modern GNU/Linux distributions.

Now having the above sample crontab in order to enable the fsck file checking on Linux boot for /dev/sda1 , we will need to modify the above line’s filesystem check option be 2, e.g. the line would afterwards look like:

/dev/sda1 /home ext3 defaults 0 2

Setting the 2 as an option for filesystem check is necessery for every filesystem which is not mounted as a root filesystem /

In above example /etc/fstab you already see that auto filesystem fsck is enabled for root partition:

/dev/sda8 / ext3 errors=remount-ro 0 1
(notice the 1 in the end of the line)

Finally a modified version of the default sample /etc/fstab which will check the extra /dev/sda1 /home partition would look like so:

/dev/sda8 / ext3 errors=remount-ro 0 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sda1 /home ext3 defaults 0 2

Making sure all Linux server partitions has the auto filesystem check option enabled is something absoultely necessery!
Enabling the auto fsck on servers always makes me sleep calmer 😉
Hope it helps your too. 🙂

How to configure and enable Xen Linux dedicated server’s Virtual machines Internet to work / Enable multipe real IPs and one MAC only in (SolusVM) through NAT routed and iptables

Saturday, June 4th, 2011

Xen Linux Virtual Machine Logo

I’ve been hired as a consultant recently to solve a small task on a newly bought Xen based dedicated server.
The server had installed on itself SolusVM

The server was a good hard-iron machine running with CentOS Linux with enabled Xen virtualization support.
The Data Center (DC) has provided the client with 4 IP public addresses, whether the machine was assigned to possess only one MAC address!

The original idea was the dedicated server is supposed to use 4 of the IP addresses assigned by the DC whether only one of the IPs has an external internet connected ethernet interface with assigned MAC address.

In that case using Xen’s bridging capabilities was pretty much impossible and therefore Xen’s routing mode has to be used, plus an Iptables Network Address Translation or an IP MASQUERADE .

In overall the server would have contained 3 virtual machines inside the Xen installed with 3 copies of:

  • Microsoft Windows 2008

The scenario I had to deal with is pretty much explained in Xen’s Networking wiki Two Way Routed Network

In this article I will describe as thoroughfully as I can how I configured the server to be able to use the 3 qemu virtual machines (running inside the Xen) with their respective real interner visible public IP addresses.

1. Enable Proxyarp for the eth0 interface

To enable proxyarp for eth0 on boot time and in real time on the server issue the commands:

[root@centos ~]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp[root@centos ~]# echo 'net.ipv4.conf.all.proxy_arp = 1' >> /etc/sysctl.conf

2. Enable IP packet forwarding for eth interfaces

This is important pre-requirement in order to make the iptables NAT to work.

[root@centos ~]# echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
[root@centos ~]# echo 'net.ipv6.conf.all.forwarding=1' >> /etc/sysctl.conf

If you get errors during execution of /etc/init.d/xendomains , like for example:

[root@centos ~]# /etc/init.d/xendomains restart
/etc/xen/scripts/network-route: line 29: /proc/sys/net/ipv4/conf/eth0/proxy_arp: No such file or directory
/etc/xen/scripts/network-route: line 29: /proc/sys/net/ipv6/conf/eth0/proxy_arp: No such file or directory

in order to get rid of the message you will have to edit /etc/xen/scripts/network-route and comment out the lines:

echo 1 >/proc/sys/net/ipv4/conf/${netdev}/proxy_arp
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_arp
#echo 1 >/proc/sys/net/ipv4/conf/${netdev}/proxy_arp
#echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_arp

3. Edit /etc/xen/xend-config.sxp, disable ethernet bridging and enable eth0 routing (route mode) and NAT for Xen’s routed mode

Make absolutely sure that in /etc/xen/xend-config.sxp the lines related to bridging are commented.
The lines you need to comment out are:

(network-script network-bridge)
(vif-script vif-bridge)

make them look like:

#(network-script network-bridge)
#(vif-script vif-bridge)br />

Now as bridging is disabled let’s enable Xen routed network traffic as an bridged networking alternative.

Find the commented (network-script network-route) and (vif-script vif-route) lines and uncomment them:

#(network-script network-route)
#(vif-script vif-route)

The above commented lines should become:

(network-script network-route)
(vif-script vif-route)

Next step is to enable NAT for routed traffic in Xen (necessery to make routed mode work).
Below commented two lines in /etc/xen/xend-config.sxp, should be uncommented e.g.:

#(network-script network-nat)
#(vif-script vif-nat)

Should become:

(network-script network-nat)
(vif-script vif-nat)

4. Restart Xen control daemon and reload installed Xen’s Virtual Machines installed domains

To do so invoke the commands:

[root@centos ~]# /etc/init.d/xend
[root@centos ~]# /etc/init.d/xendomains restart

This two commands will probably take about 7 to 10 minutes (at least they took this serious amount of time in my case).
If you think this time is too much to speed-up the procedure of restarting Xen and qemu attached virtual machines, restart the whole Linux server, e.g.:

[root@centos ~]# restart

5. Configure iptables NAT rules on the CentOS host

After the server boots up, you will have to initiate the following ifconfig & iptables rules in order to make the Iptables NAT to work out:

echo > > /proc/sys/net/ipv4/conf/tap1.0/proxy_arp
/sbin/ifconfig eth0:1 netmask
/sbin/ifconfig eth0:2 netmask
/sbin/ifconfig eth0:3 netmask

/sbin/iptables -t nat -A PREROUTING -d -i eth0 -j DNAT --to-destination
/sbin/iptables -t nat -A PREROUTING -d -i eth0 -j DNAT --to-destination
/sbin/iptables -t nat -A PREROUTING -d -i eth0 -j DNAT --to-destination
/sbin/iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source
/sbin/iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source
/sbin/iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source

In the above ifconfig and iptables rules the IP addresses:,, are real IP addresses visible from the Internet.
In the above rules eth0:1, eth0:2 and eth0:3 are virtual ips assigned to the main eth0 interface.

This ifconfig and iptables setup assumes that the 3 Windows virtual machines running inside the Xen dedicated server will be configured to use (local) private network IP addresses:, and

You will have also to substitute the, and with your real IP addreses.

To store the iptables rules permanently on the fedora you can use the iptables-save command:

[root@centos ~]# /sbin/iptables-save

However I personally did not use this approach to save my inserserted iptable rules for later boots but I use my small script to add virtual interfaces and iptables rules via the /etc/rc.local invokation:

If you like the way I have integrated my virtual eths initiation and iptables kernel firewall inclusion, download my script and set it to run in /etc/rc.local, like so:

[root@centos ~]# cd /usr/sbin
[root@centos sbin]# wget
[root@centos ~]# chmod +x /usr/sbin/
[root@centos ~]# mv /usr/sbin
[root@centos ~]# echo '/usr/sbin/' >> /etc/rc.local

Note that you will have to modify my script to substitute the, and with your real IP address.

So far so good, one might think that all this should be enough for the Virtual Machines Windows hosts to be able to connect to the Internet and Internet requests to the virtual machines to arrive, but no it’s not!!

6. Debugging Limited Connectivity Windows LAN troubles on the Xen dedicated server

Even though the iptables rules were correct and the vif route and vif nat was enabled inside the Xen node, as well as everything was correctly configured in the Windows 2008 host Virtual machines, the virtual machines’s LAN cards were not able to connect properly to connect to the internet and the Windows LAN interface kept constantly showing Limited Connectivity! , neither a ping was available to the gateway configured for the Windows VM host (which in my case was:

You see the error with Limited connectivity inside the Windows on below’s screenshot:

Limited Connectivty Windows error Lan Interface, status screenshot

Here is also a screenshot of my VNC connection to the Virtual machine with the correct IP settings – (TCP/IPv4) Properties Window:

Windows Xen Network Connections Windows VNC TCP/IPv4 Properties Window

This kind of Limited Connectivity VM Windows error was really strange and hard to diagnose, thus I started investigating what is wrong with this whole situation and why is not able the Virtualized Windows to connect properly to the Internet, through the Iptables NAT inbound and outbound traffic redirection.

To diagnose the problem, I started up with listing the exact network interfaces showing to be on the Xen Dedicated server:

[root@centos ~]# /sbin/ifconfig |grep -i 'Link encap' -A 1
eth0 Link encap:Ethernet HWaddr 00:19:99:9C:08:3A
inet addr: Bcast:
eth0:1 Link encap:Ethernet HWaddr 00:19:99:9C:08:3A
inet addr: Bcast:
eth0:2 Link encap:Ethernet HWaddr 00:19:99:9C:08:3A
inet addr: Bcast:
eth0:3 Link encap:Ethernet HWaddr 00:19:99:9C:08:3A
inet addr: Bcast:
lo Link encap:Local Loopback
inet addr: Mask:
tap1.0 Link encap:Ethernet HWaddr FA:07:EF:CA:13:31
vifvm101.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet addr: Bcast:

I started debugging the issue, using the expelling logic.
In the output concerning my interfaces via ifconfig on eth0, I have my primary server IP address , this one is working for sure as I was currently connected to the server through it.

The other virtual IP addresses assigned on the virtual network interfaces eth0:1, eth0:2 and eth0:3 were also assigned correctly as I was able to ping this ips from my Desktop machine from the Internet.

The lo , interface was also properly configured as I could ping without a problem the loopback ip –

The rest of the interfaces displayed by my ifconfig output were: tap1.0, vifvm101.0

After a bit of ressearch, I’ve figured out that they’re virtual interfaces and they belong to the Xen domains which are running qemu virtual machines with the Windows host.

I used tcpdump to debug what kind of traffic does flow through the tap1.0 and vifvm101.0 interfaces, like so

[root@centos ~]# tcpdump -i vifvm101.0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vifvm101.0, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root@centos ~]# tcpdump -i tap1.0
cpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap1.0, link-type EN10MB (Ethernet), capture size 96 bytes
08:55:52.490249 IP > UDP, length 42

I’ve figured out as it’s also observable in above’s two tcpdump commands output, that nothing flows through the vifvm101.0 interface, and that there was some traffic passing by tap1.0 interface.

7. Solving the Limited Connectivy Windows Internet network connection problems

As below’s ifconfig output reveals, there is no IP address assigned to tap1.0 interface, using some guidelines and suggestions from guys in’s #netfilter irc channel, I’ve decided to give a go to set up an IP address of to tap1.0 .

I choose for a reason as this IP address is configured to be my Gateway’s IP Address inside the Emulated Windows 2008 hosts

To assign the to tap1.0, I issued:

[root@centos ~]# /sbin/ifconfig tap1.0 netmask
To test if there is difference I logged in to the Virtual Machine host with gtkvncviewer (which by the way is a very nice VNC client for Gnome) and noticed there was an established connection to the internet inside the Virtual Machine 😉

I issued a ping to google which was also returned and opened a browser to really test if everything is fine with the Internet.
Thanks God! I could browse and everything was fine 😉

8. Making tap1.0 (VM hosts gateway to be set automatically, each time server reboots)

After rebooting the server the tap1.0 assignmend of disappeared thus I had to make the, be assigned automatically each time the CentoS server boots.

To give it a try, I decided to place /sbin/ifconfig tap1.0 netmask into /etc/rc.local, but this worked not as the tap1.0 interface got initialized a while after all the xendomains gets initialized.

I tried few times to set some kind of sleep time interval with the sleep , right before the /sbin/ifconfig tap1.0 … ip initialization but this did not worked out, so I finally completely abandoned this methodology and make the tap1.0 get initialized with an IP through a cron daemon.
For that purpose I’ve created a script to be invoked, every two minutes via cron which checked if the tap1.0 interface is up and if not issues the ifconfig command to initialize the interface and assign the IP to it.

Here is my shell script

To set it up on your host in /usr/sbin issue:

[root@centos ~]# cd /usr/sbin/
[root@centos sbin]# wget
In order to set it on cron to make the tap1.0 initialization automatically every two minutes use the cmd:

[root@centos ~]# crontab -u root -e

After the cronedit opens up, place the cron invokation rules:

*/2 * * * * /usr/sbin/ >/dev/null 2>&1

and save.

That’s all now your Xen dedicated and the installed virtual machines with their public internet IPs will work 😉
If this article helped you to configure your NAT routing in Xen drop me a thanks message, buy me a beer or hire me! Cheers 😉

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:


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

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 }'

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:

, 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 ( and a gateway (, 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

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

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.