This package implements all core configuration.
Network configuration is saved inside the NetworksDB (
Example of a database containing an interface:
eth0=ethernet bootproto=none device=eth0 gateway=192.168.1.254 ipaddr=192.168.1.1 netmask=255.255.255.0 onboot=yes role=green
Each entry describes a network interface according to CentOS/RHEL specification for network-scripts files:
<device_name> = type role = <role> <param> = <value>
type variable is the type of interface. Valid values are:
<device_name> variable is the name for the device.
role property is a mandatory parameter which describes the interface role. Valid values are:
If the role property is empty, the interface is not used by the system.
There are also 3 special roles:
- bridged: interface is part of a bridge
- slave: interface is part of a bond
- alias: interface is an alias of another interface
- xdsl-disabled: xdsl disabled interface
See also Roles and zones for the meaning of each color.
<param>/<value> are all valid CentOS network parameter for the specified interface. All parameters must be lowercase. Example:
All parameters will be mapped 1-to-1 to the configuration file
One green ethernet:
db networks set eth0 ethernet role green ipaddr 192.168.1.4 netmask 255.255.255.0 network 192.168.1.0 onboot yes bootproto static
Any property starting with
BondOpt prefix is used as bonding options.
bond0=bond BondOptMode=0 BondOptMiimon=80 bootproto=none gateway=192.168.1.100 ipaddr=192.168.1.2 netmask=255.255.255.0 role=green
The network database can be manipulated using the esmith::NetworksDB perl module. For more information use:
If you need to access the local IP address within a template, use this code snippet:
use esmith::NetworksDB; my $ndb = esmith::NetworksDB->open_ro() || return;; my $LocalIP = $ndb->green()->prop('ipaddr') || '';
Old templates used a variable called LocalIP to access the green IP address. This variable is no more available.
All network configurations are applied by
All interfaces are imported from configuration files to database using
The networks database is updated Whenever an interface is plugged into the system.
DHCP on red interfaces¶
When configuring a red interface in DHCP mode, enable also the above options:
peer_dnsto avoid resolv.conf overwriting from dhclient
persistent_dhclientto enforce dhclient to retry in case of lease request errors
Remember also to remove all gateway IP address from green devices. This configuration will create the correct routes and correctly set DHCP options on dnsmasq.
Create a bridge interface from command line. The new interface will have green role (eth0 was the previous green interface):
db networks delprop eth0 ipaddr netmask bootproto db networks setprop eth0 role bridged bridge br0 db networks set br0 bridge bootproto static device br0 ipaddr 192.168.1.254 netmask 255.255.255.0 onboot yes role green signal-event interface-update
Reset network configuration¶
In case of misconfiguration, it’s possible to reset network configuration by following these steps.
Delete all logical and physical interfaces from the db
Display current configuration:
db networks show
Delete all interfaces:
db networks delete eth0
Repeat the operation for all interfaces including bridges, bonds and vlans.
ifconfig eth0 down
In case of a bridge:
ifconfig br0 down brctl delbr br0
In case of a bond (eth0 is enslaved to bond0):
ifenslave -d bond0 eth0 rmmod bonding
Remove configuration files
Network configuration files are inside the
/etc/sysconfig/network-scripts/directory in the form:
/etc/sysconfig/network-scripts/ifcfg-<devicename>. Where devicename is the name of the interface like eth0, br0, bond0.
Delete the files:
rm -f /etc/sysconfig/network-scripts/ifcfg-eth0
Repeat the operation for all interfaces including bridges, bonds and vlans.
Restart the network
After restarting the network you should see only the loopback interface:
service network restart
Use ifconfig command to check the network status.
Manually reconfigure the network
Choose an IP to assign to an interface, for example 192.168.1.100:
ifconfig eth0 192.168.1.100
Then reconfigure the system:
The interface will have the chosen IP address.
Open the web interface and reconfigure accordingly to your needs
Log retention and rotation¶
By default logs are rotated weekly and kept for 4 weeks. Some packages come with different defaults, but the majority do not specify a custom rotate value.
Logrotate db property:
Rotate: rotation frequency, can be
monthly. Default is
Times: rotate log files
Timesnumber of times (days, weeks or months) before being removes, default is 4
Compression: can be
disabled. Defaults is
logrotate=configuration Compression=disabled Rotate=weekly Times=4
Keep logs for 6 months, rotate once a week:
config setprop logrotate Rotate weekly config setprop logrotate Times 24 signal-event nethserver-base-update
Transport Layer Security¶
TLS policy page controls how individual services configure the
Transport Layer Security (TLS) protocol, by selecting a policy identifier.
Each module implementation decides how to implement a specific policy identifier, providing a trade off between security and client compatibility. Newer policies are biased towards security, whilst older ones provide better compatibility with old clients.
You can enforce the TLS policy (20180330), or choose the legacy one (empty policy property) if your clients are not supported/maintained anymore (Windows XP for example).
- TLS db property in configuration database: ::
The event to expand the templates of all rpm which use TLS is
Main repositories are:
nethserver-base: it contains packages and dependencies from core modules. It is updated when a new milestone is released. Enabled by default.
nethserver-updates: it contains updated packages. If needed, these updates can be applied without requiring manual intervention. Enabled by default.
nethforge: communty provided modules for NethServer. Enabled by default.
nethserver-testing: contains packages under QA process. Disabled by default.
base: base packages from CentOS. Enabled by default.
updates: updated packages from CentOS. Enabled by default.
centos-sclo-sclo: SCL repositories. Both enabled by default.
extras: extra RPMs. Enabled by default.
A standard installation should have the following enabled repositories:
Packages published in above repositories should always allow a non-disruptive automatic update.
NS Release Lock¶
As default NethServer is configured to access latest upstream repositories using the “Rolling release” approach.
It is possibile to lock repositories to che current minor release using
NS release lock feature:
config setprop sysconfig NsReleaseLock enabled signal-event software-repos-save
When NS Release Lock is enabled, the following repositories are available (where
ce stands for CentOS):
These repositories point to a fixed CentOS release, the configuration is stored inside
Configuration of enabled repositories is stored inside:
/etc/nethserver/pkginfo.conf: list of YUM repositories that have their groups listed
- on the Software Center
/etc/nethserver/eorepo.conf: list of YUM repositories enabled by
software-repos-saveevent, every non-listed repository will be disabled
Please note that NS Release Lock is mutually exclusive with subscription:
when a subscription is enabled,
NSReleaseLock will be disabled.
Some third-party repositories don’t support accessing RPMs using a minor release like
but only using a major release like
Actually, this limitation is present for:
NsReleaseLock is set to
- installation from the Software Center will enable all upstream repositories otherwise YUM will not be able to resolve package dependencies
- updates from the Software Center will disable repositories which doesn’t support locking to minor
- updates from the command line will enable all upstream repositories
yum-cronhas access to a special repository configuration stored inside
/etc/nethserver/yum-update.d/and enabled using
Third party repositories¶
It’s possible to install third party repositories, using standard CentOS methods.
If such repositories support access using minor release, they can be safely added
pkginfo.conf using a template-custom.
nethserver-yum-cron has been merged into
The cron job runs each night with a random time before to start of 6 hours..
You can decide who receive the notifications (default is root), which updates to do, if you just check, download, or install automatically the updates.
Original author: Stephane de Labrusse (@stephdl)
applyUpdate: can be
no. If set to
yes, downloaded updates will be installed
customMail: comma-separated list of extra mail recipients, as default a mail will be sent to root
download: can be
no. If set to
yes, download new package updates
messages: can be
no. Whether a message should be emitted when updates are available
randomWait: random number of minutes to wait before executing the download procedure - NS6: 1 to 60 minutes - NS7: 1 to 360 minutes, negative and the job start immediately
status: can be
disabled. When enabled, a cron script will search for package updates
yum-cron=service applyUpdate=yes customMail= download=no messages=no randomWait=360 status=enabled