Posts Tagged ‘configuration files’

How to create PCS / Corosync High Availability Cluster config backup and migrate to new Virtual Machines

Thursday, October 26th, 2023

pcs-pcmk-internals-explained-picture

The aim of this article is to illustrate how to literally migrate a an Haproxy PCS Pacemaker / Corosync Cluster configurations from old Virtual Machines that due to time passed become unsupported (The Operating System end of life (EOF)) has reached to a new ones. 
This is quite a complex task especially as you usually need to setup the Hypervisor hosts with VMWare / Xen / KVM / OpenVZ or whatever kind of virtualization is to be used. Then setup the correct network interfaces IPs failover the heartbeat lines over which the cluster will work to prevent Split Brain scenartions, the Network Bonding interfaces to guarantee a higher amount of higher availability as well as physically install and update all the cluster software on the new built Linux hosts that will be members of the new cluster in setup. 

All this configuration from scratch of a PCS Corosync cluster is a very lenght topic which I'll try to cover in some of my next articles. In short to migrate the cluster from old machines to new once all this predescribed steps are in line. 
You will need to.


1. Create backup of old cluster configuration
2. Migrate the backup to a new built VM Machine hosts
3. Import the cluster configuration into the PCS Cluster.


Bear in mind that this article discusses a migration of CentOS Linux release 7.9.2009 with its shipped versions of corosync / pacemaker and pcs 

How to create cluster config backup and migrate to new VM

1. Dump cluster assuming that is a Quality Assuare or Pre – Production host  to create full cluster config backup

[root@old-cluster-machine ~]# pcs config backup old-cluster-machine.pcs.config.bak

2. Dump cluster Production full configuration

[root@old-cluster-machine1 ~]# pcs config backup old-cluster-machine1.pcs.config.bak

This command will output a backup of 

old-cluster-machine1.pcs.config.bak.tar.bz2

3. Migrate a cluster identical config to the new Virtual machines

Usually this moval of produced backup files with pcs config backup  commands can be copied with something like FTP / SFTP  or SSL-ed / TLS-ed protocol. However if you have to move the configuration files from a paranoid Citrix environment that doesn't allow you to have any SFTP / SSH or FTP kind of transfer protocol from the location where the old config lays to the new ones. 
A simple encoding of the binary format dumped configuration to plain text files can be done and files, can be moved via a simple copy / paste operation (a bit of a hack) 🙂

Encode the cluster config to be able to migrate configuration in plain text via a simple Copy / Paste operation.

 

[root@old-cluster-machine ~]# base64 config backup old-cluster-machine.pcs.config.bak > old-cluster-machine.pcs.config.bak.tgz.b64

[root@old-cluster-machine1 ~]# base64 old-cluster-machine1.pcs.config.bak.tar.bz2 > old-cluster-machine1.pcs.config.bak.tgz.b64
[root@old-cluster-machine ~]# cat  old-cluster-machine.pcs.config.bak.tgz.b64

(Copy output and Paste to new host VM) /root/haproxy-cluster-backup)

[root@old-cluster-machine1 ~]# cat old-cluster-machine1.pcs.config.bak.tgz.b64 


(Copy output and Paste to new host VM) /root/haproxy-cluster-backup)

Login to the new hosts, where configs has to be migrated and restore the files with base64

For QA / Preprod to restore backup config

[root@dkv-newqa-vm ~]# mkdir /root/haproxy-cluster-backup
[root@dkv-newqa-vm ~]# cd /root/haproxy-cluster-backup
[root@dkv-newqa-vm ~]# base64 -d old-cluster-machine.config.bak.tgz.b64 > old-cluster-machine.pcs.config.bak.tar.bz2
[root@dkv-newqa-vm ~]#  tar -jxvf old-cluster-machine.pcs.config.bak.tar.bz2
ak.tar.bz2
version.txt
pcs_settings.conf
corosync.conf
cib.xml
pacemaker_authkey
uidgid.d/

 

For Prod to restore backup config

[root@dkv-newprod-vm  ~]# mkdir /root/haproxy-cluster-backup
[root@dkv-newprod-vm ~]# cd /root/haproxy-cluster-backup
[root@dkv-newprod-vm ~]# base64 -d old-cluster-machine.config.bak.tgz.b64 > old-cluster-machine1.pcs.config.bak.tar.bz2
ak.tar.bz2
version.txt
pcs_settings.conf
corosync.conf
cib.xml
pacemaker_authkey
uidgid.d/


N!B! An Useful hin is on RHEL 8 Linux's shipped pcs command version has also a very useful command with which you can simply dump completly the config of the cluster in straight commands which you can run directly on the new VM machines where you have migrated.

The command to print out commands that would add existing cluster resources on Redhat 8:

# pcs resource config –output-format=cmd

Another useful command for cluster migration is cibadmin

i.e. to dump cluster xml config

#cibadmin –q > cluster.xml

Later you can import the prior xml dump with it.

# cibadmin –replace –xml-file cib.xml

 

Set proxy only for apt, apt-get, aptitude package manager on Debian / Ubuntu Linux

Wednesday, December 22nd, 2021

debian-package-manager-run-via-a-proxy

 

Intro

Main console package install apt-get / apt and / aptitude did not use the HTTP Proxy environment variables by default as there is no default proxy set on Debian / Ubuntu / Mint and other deb based distros after OS Install. Under some circunstances for DMZ placed or firewall secured servers, direct access to internet address or even Package repository is only allowed via a proxy and hence the package manager needs to have a proxy host set.
 Setting a global wide proxy on Linux is easily possible by setting http_proxy="http://yourhost.com:8080" and https_proxy or if FTP connection via ftp_proxy somewhere in /etc/profile , /etc/bashrc or via /etc/environment but as using this Shell variables set it global wide for all applications lynx / links / wget / curl, sometimes it is useful to set the Proxy host only for deb package management tools.

Note that if you want to set a proxy host for deb operations this can be done during initial OS install installation, the Apt configuration file would have been automatically updated then. 

Creating  an Apt Proxy Conf File

Apt loads all configuration files under /etc/apt/apt.conf.d. We can create a configuration specifically for our proxy there, keeping it separate from all other configurations.

  1. Create a new configuration file named proxy.conf.

     

     

    # touch /etc/apt/apt.conf.d/proxy.conf
    
  2. Open the proxy.conf file in a text editor.

     

     

    # vi /etc/apt/apt.conf.d/proxy.conf
    
  3. Add the following line to set your HTTP proxy for apt.

     

     

    Acquire::http::Proxy "http://username:password@proxy.server:port/";
    
  4. Add the following line to set your HTTPS proxy.

     

     

    Acquire::https::Proxy "http://username:passw0rd@proxy.server:port/";
    
  5. Save your changes and exit the text editor.
     

Your proxy settings will be applied the next time you run Apt.

Simplifying the Configuration

As mentioned by a user in the comments below, there is an alternative way for defining the proxy settings. While similar, it removes some redundancy.

Just like in the first example, create a new file under the /etc/apt/apt.conf.d directory for example /etc/apt/apt.conf.d/proxies, and then add the lines as.

Acquire {
HTTP::proxy "http://127.0.0.1:8080";
HTTPS::proxy "http://127.0.0.1:8080";
}

 

How to add local user to admin access via /etc/sudoers with sudo su – root / Create a sudo admin group to enable users belonging to group become superuser

Friday, January 15th, 2021

sudo_logo-how-to-add-user-to-sysadmin-group

Did you had to have a local users on a server and you needed to be able to add Admins group for all system administrators, so any local user on the system that belongs to the group to be able to become root with command lets say sudo su – root / su -l root / su – root?
If so below is an example /etc/sudoers file that will allow your users belonging to a group local group sysadmins with some assigned group number

Here is how to create the sysadmins group as a starter

linux:~# groupadd -g 800 sysadmins

Lets create a new local user georgi and append the user to be a member of sysadmins group which will be our local system Administrator (superuser) access user group.

To create a user with a specific desired userid lets check in /etc/passwd and create it:

linux:~# grep :811: /etc/passwd || useradd -u 811 -g 800 -c 'Georgi hip0' -d /home/georgi -m georgi

Next lets create /etc/sudoers (if you need to copy paste content of file check here)and paste below configuration:

linux:~# mcedit /etc/sudoers

## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb

 

## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp

## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe

Cmnd_Alias PASSWD = /usr/bin/passwd [a-zA-Z][a-zA-Z0-9_-]*, \\
!/usr/bin/passwd root

Cmnd_Alias SU_ROOT = /bin/su root, \\
                     /bin/su – root, \\
                     /bin/su -l root, \\
                     /bin/su -p root


# Defaults specification

#
# Refuse to run if unable to disable echo on the tty.
#
Defaults   !visiblepw

#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults    always_set_home
Defaults    match_group_by_gid

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

#
# Adding HOME to env_keep may enable a user to run unrestricted
# commands via sudo.
#
# Defaults   env_keep += "HOME"
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##      user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## Allows members of the users group to mount and unmount the
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom
## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

%sysadmins            ALL            = SU_ROOT, \\
                                   NOPASSWD: PASSWD

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

zabbix  ALL=(ALL) NOPASSWD:/usr/bin/grep


Save the config and give it a try now to become root with sudo su – root command

linux:~$ id
uid=811(georgi) gid=800(sysadmins) groups=800(sysadmins)
linux:~$ sudo su – root
linux~#

w00t Voila your user is with super rights ! Enjoy 🙂

 

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.

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

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 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.