Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix
>

NetworkManager

News

 Linux Networking

Recommended Books

 Recommended Links

Network Utilities

 Configuring the Services Setting a Default Gateway in RHEL
Ethernet Protocol Linux ifconfig How to change IP address in RHEL ethtool Autonegotiation Traceroute ntop
Setting a Default Gateway in RHE NetworkManager Disabling RHEL 6 Network Manager        
Linux Routing Linux route command netstat Samba VNC on Linux SSH FTP
Sendmail on RHEL Postfix Nmap Horror Stories Unix History Humor Etc
NetworkManager is a desktop component, which is useless for rackmounted servers with static IP and cable connection.

Introducing NetworkManager by Rosanna Yuen

Redhat Magazine

Issue #3 January 2005

Introduction

Network management has been a necessary but relatively ignored part of the Linux environment for years. With network connections pervading everyday life, the need for a better way to manage network connections has never been greater. Within this past year, a new application called NetworkManager has been created to fill this need. What is NetworkManager and how did it come into being? Let us go back to the beginning.

A brief history of Internet connectivity

Long ago, in the days of yore, the Internet was born. A computer could access this Internet by attaching itself to it with a cable. Once this cable was connected, the parameters were set once and forgotten. It barely mattered if the set-up was difficult; a favor from a more technically-savvy friend and you were good to go. There was no need for maintenance as the connection would continue working in the background indefinitely.

Then everyone got laptop computers. Every time someone with a laptop computer wanted to access the Internet, they would have to plug a wire into their network card. These mobile devices would have to be stationary for as long as the Internet access was needed. Access was usually limited to one's home and/or workplace, which meant set-up was only twice as complicated as a desktop computer. That technically-savvy friend might have grumbled a bit, but was still willing to show off the required expertise.

But lately, the boom of wireless networking has meant a proliferation of Internet access points everywhere, from local coffee shops to laundromats, from (if you live in the right location) city parks to public libraries, from train cars to airports. And each time a laptop computer needs to access a new wireless point, configurations would have to be done anew. Bringing your technically-savvy friend with you everywhere became infeasible. An easy and intuitive way to set up network connectivity suddenly became more important.

A new way

The desktop team at Red Hat realized the current interface in Linux networking is unacceptable. They wanted to create a new application that is simple to use. However, simplicity is a concept that is easier to understand than to define. With this in mind, they came up with some guidelines for their new application. They believe that a network tool should:

Another important feature planned from the start of NetworkManager is its ability to function with any Linux distribution. Among the distributions which already offer NetworkManager packages are Fedora, Gentoo, Debian, and Slackware. As NetworkManager was designed with portability in mind, packaging for other distributions should be relatively painless. With such broad distribution support, application developers are able to utilize the features of NetworkManager with the knowledge that their efforts reap widespread rewards.

The price of simplicity

Although I know a few people who already run NetworkManager as a standard part of their desktop, it is not currently ready for widespread use as NetworkManager is still a work in progress. The hope is that with enough work, NetworkManager will be the network tool of choice for people with mobile computers. In the interim, those that are lucky enough to have supported hardware can use it while others have to wait until appropriate drivers are implemented.

Another drawback of NetworkManager is that it cannot implement all command line possibilities. For most hardware configurations, this lack does not matter as it does not affect its ability to connect to the Internet. However, for those configurations that require various tricks and obscure incantations to get working, NetworkManager most likely will not work.

From start to go

Now that we know where NetworkManager came from, it is time to get it running on your system.

Getting the packages

NetworkManager packages are available for some Linux distributions. For Fedora, enter the following at a command prompt: 

yum install NetworkManager NetworkManager-gnome

NetworkManager is now installed on your computer.

Getting the source

If you are unable to find a prepackaged version of NetworkManager for your distribution, you could try and build it yourself. Download the source tarballs from the GNOME FTP site.

Build and install as per the method appropriate for your particular distribution.

Running NetworkManager

Once NetworkManager is installed on the system, it can be started by entering the following on a command line as root: 

service NetworkManager start

If you are unsure about using NetworkManager as your primary network application, using this command is a good way to test it out. You can run this command every time you boot up your computer to start NetworkManager.

However, if you know NetworkManager works well for you and you want to have it start up every time by default, enter the following command as root: 

chkconfig --add NetworkManager

Once the NetworkManager daemon is running, log in as the user and enter the following in a terminal: 

NetworkManagerInfo &

The NetworkManager icon should appear in the Notification Area.

If you do not have a Notification Area in your panel, you can create one. Start by right clicking on the panel and selecting Add to Panel.... Choose the Notification Area from the dialog box.

To make the NetworkManager icon return every time you log in, enter the following in a terminal: 

gnome-session-save
Using NetworkManager

NetworkManager attempts to intelligently select a network connection. The first thing it checks is whether or not an Ethernet card is connected and running. Because an Ethernet card creates a wired connection, it is assumed to be inherently faster than any wireless possibility. If such a connection exists, NetworkManager tries to get a DHCP lease on that connection.

If there is no wired connection available, NetworkManager uses the wireless card to scan for available ESSIDs (Extended Service Set Identifier, a code used to identify packets on a wireless network). If one or more of these access points have been used in the past, the one that was used most recently is automatically selected. If none of them have been used before, NetworkManager waits for user input.

Since NetworkManager considers wireless selection as a preference, it does not connect to any wireless networks unless a user is logged onto a desktop and one is selected. At a casual glance, this inactivity might seem unusual. What could be simpler than to have NetworkManager automatically pick the best connection?

There are a few reasons why this is not a good idea. First of all, NetworkManager has no way of knowing whether or not an access point is actually yours to use. It could belong to a neighbor who would not be happy if you used it. Second, there is no way for NetworkManager to gauge which connection would be best. Although it can tell signal strength, that is not a good way to compare connections. A connection to an access point with lower signal strength may be a better pick if the access point is connected to a much faster connection down the line. Lastly, some access points may be more secure than others. Because a user may one day prefer to choose a connection that offers a faster connection with lower security and on a different day choose differently, network selection has to be selected on a per-user basis.

NetworkManager is constantly scanning for changes in network hardware on the system as well as for new access points. If a new wired network becomes available, NetworkManager switches to it automatically. If the wire is disconnected, NetworkManager quietly switches back to the preferred wireless connection.

Running NetworkManager for the first time

The first time you log in to the computer with NetworkManager running, the NetworkManager icon shows up in the Notification Area. Click on this icon and the selection menu pops up as shown in Figure 1, “The network selection menu”. This menu shows the available networks and their various strengths. Selecting a network activates that connection.

The network selection menu

Figure 1. The network selection menu

If a network is password protected, the listing of that network in the menu has an icon of a lock next to it. Selecting a password protected network pops up a dialog box. Select the appropriate hash type and enter your password to activate that connection.

Connecting to a hidden access point

Some access points are intentionally hidden by the administrator as a security measure. If you know the ESSID, you can still access it. From the NetworkManager icon in the Network Area, select Other Wireless Networks.... In the dialog box (shown in Figure 2, “Entering information for a hidden network”), enter the ESSID. If necessary, enter the password type and password as well.

Entering information for a hidden network

Figure 2. Entering information for a hidden network

How NetworkManager works

Now that we have covered how to use NetworkManager, let us explore how it works.

Architectural overview

The NetworkManager application is made up of four distinct parts:

These components interact with each other to perform tasks associated with NetworkManager. A diagram displaying their interactions is shown in Figure 3, “NetworkManager interactions”.

NetworkManager interactions

Figure 3. NetworkManager interactions

NetworkManager and D-BUS

NetworkManager uses D-BUS (a message bus that allows applications to talk to each other) to interact with other applications. Using D-BUS allows for the flexibility of a standard interface while also including built-in security.

D-BUS is used internally for communication between:

Externally, NetworkManager uses D-BUS to broadcast information about various state changes. Other applications can monitor this information and theoretically be able to change network status.

NetworkManager and HAL

Included in Fedora Core 3 and in upcoming Red Hat Enterprise Linux releases, HAL, or Hardware Abstraction Layer, provides the ability for applications to learn about existing and new hardware. For more information on HAL, read David Zeuthen's article on HAL.

NetworkManager queries HAL at startup to learn what network interfaces are available. Any changes in network hardware and link information is detected by HAL, and this information is immediately relayed to NetworkManager. HAL can also provide information about the network card's driver, which allows NetworkManager to special case certain cards.

The future of NetworkManager

There are many future features planned for NetworkManager. The following are a few of the more exciting ones currently being developed:

VPN
A VPN (Virtual Private Network) is private network used mostly by companies and organizations to conduct private business over the Internet. Currently, attempting to connect to a VPN on a Linux system is more complicated than setting up a wireless network from the command line. Work has begun to integrate VPN connections into NetworkManager. When completed, accessing a VPN will be as easy as selecting a wireless network.
Notifying Desktop Applications
Have you ever lost your network connection without warning? Every network dependent application suddenly panics and pops up a warning that the connection has been lost. Mail clients, Web browsers, and Internet chat clients are just some of the everyday applications that are affected. NetworkManager aims to solve this annoyance. By having network information consolidated in one place, applications can query NetworkManager for the status of the network instead of harassing the user. Individual applications could then switch themselves to work off-line until the network connection is once again established.
Consolidating DHCP Options
DHCP (Dynamic Host Configuration Protocol) is a networking protocol that allows a DHCP client and a DHCP server to relate information necessary for the client to access the network. Other than the IP address, a DHCP server can provide information such as the location of print servers, SMTP servers, and POP servers. Having all of this information easily available in NetworkManager that can be accessed via D-BUS allows a sane and consistent way for applications to get this information.
Disabling Access
In an ideal world, having network connectivity all the time would be a wonderful benefit. However, in this world, there are times when automatic connections are a hindrance. For instance:
  • You are on an airplane and are told that all network devices have to be shut down.
  • The battery on the laptop is low (constant monitoring of available networks take a nontrivial amount of power.)
  • You want the computer to be unaccessible for security (or personal) reasons.
NetworkManager will soon make turning off networking as simple as clicking a mouse button.
Dial-up Networking Support
Neither modems nor ISDN connections are currently supported in NetworkManager. However, they are planned and when implemented will be options in the NetworkManager menu.
How to help

NetworkManager is still a work in progress. The developers welcome help from the community. Testing wireless cards, writing documentation, packaging for currently unsupported distributions, and contributing code are various ways that you can help NetworkManager achieve its full potential.

Getting the code

The latest release of the source code for NetworkManager can be downloaded as stated in the section called “Getting the source”. Although this method does not get the absolute latest improvements, there is a much better chance that the version is stable. For people helping with documentation or testing, these tarballs are more than adequate.

Building from CVS

For those people who are adventurous or want to contribute code, getting the latest version is essential. This involves getting the code fresh out of CVS.

Before building NetworkManager from CVS, you need to check the following:

To download the NetworkManager code from CVS, execute: 

cvs -d :pserver:[email protected]:/cvs/gnome get NetworkManager

Once the downloading is complete, you are ready to build a new version of NetworkManager. Enter the following commands in a terminal: 

cd NetworkManager
./autogen.sh --prefix=/usr --sysconfdir=/etc
make

and as root, type: 

make install

Congratulations! You have just built the newest version of NetworkManager onto your computer.

To get your computer to recognize this new build, enter the following as root: 

service NetworkManager restart

This command restarts the NetworkManager daemon. To restart the front end, issue the command killall NetworkManagerInfo in a terminal.

Contacting the developers

Whether you have questions, suggestions, or offers to help, you need to be able to contact the developers. Here is a list of ways to get more information:

Mailing Lists
Like all software projects, NetworkManager has its own mailing list where developers and users discuss problems and suggest possible solutions.
  • Archives — NetworkManager mailing list archives
  • mailing list — page to subscribe to the NetworkManager mailing list
Websites
The Official NetworkManager website
Words with the creator

NetworkManager creator and developer Dan Williams took time out of his hectically busy schedule to answer some questions.

What prompted you to start working on NetworkManager?
Havoc Pennington. The Red Hat Desktop Team was having a meeting earlier this year to discuss things that would be cool to work on for Fedora Core 3, and he brought up the topic of easy wired and wireless networking. There weren't really any good GUI tools for configuring wireless, and you had to redo the entire setup for your wireless card every time you wanted to connect to a new access point. So, the idea of NetworkManager was born, where users could move seamlessly between desk and mobile environments and not have to care about configuration.
What was the most frustrating thing about working on NetworkManager?
Definitely the state of wireless drivers on Linux. They are horrible, both individually and as a group. There isn't complete support for any card that I know of, and across all the drivers things like quality information and basic support is inconsistent. If anyone wants to be a hero, this would be a great place to help out. Children will love you for it. Don't be afraid, wireless drivers aren't really all that complicated structurally or conceptually, and they are fairly encapsulated.
What's with those StudlyCaps, anyway?
Well, coming from a Classic Mac OS background, in which everything was StudlyCaps, it is quite natural for me to use the Shift key, which many Linux programmers seem to run away from in fear. Which is quite silly, if you ask me. There's nothing to be afraid of. In any case, it also had to do with aesthetics. A daemon called network_manager just doesn't look good (using '_' instead of ' ' probably comes from the traditional Unix aversion to spaces in file names, which is also silly), and networkmanager is just pathetically hard to read, so it had to be NetworkManager. It is also quite sad that this is almost the longest answer to any of these questions.
Besides NetworkManager, what do you like to do/work on?
I also work on OpenOffice.org, particularly in the graphics and lower layers to make it integrate better with Linux. Besides that, I enjoy tinkering around with computer hardware, various outdoors things like hiking, reading books on various archaeological topics, and trying to figure out how archaeologists can use computers more in their research. If anyone could recommend good technical books on intersections of archeology and scientific disciplines (especially paleohydrology), I'd be quite interested since I'm not "forced" to read them for college anymore. They were fun. I miss reading them.
Picking a good network card

Here are some network cards that have been shown to work with NetworkManager:

Network cards that currently do not work with NetworkManager include:

Conclusion

With NetworkManager anticipating and fulfilling the new needs of network management, Internet connectivity becomes an easy and forgettable task. Users can configure it quickly themselves. With all the time you save, you can take your technically-savvy friend out to lunch!

About the author

Rosanna Yuen is an avid computer user who often finds herself surrounded by computer programmers. She co-wrote AisleRiot and is a dabbler in the GNOME project. In her spare time, she reads, knits, and experiments in her kitchen.


 

 

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Original author(s) Red Hat
Initial release November 19, 2004; 12 years ago (2004-11-19)
 
Stable release 1.8.0 / May 10, 2017; 2 months ago (2017-05-10) [1] [2]
 
Repository cgit.freedesktop.org/NetworkManager/NetworkManager/
Written in C with GObject
Operating system SUS/POSIX
Platform Unix-like
Type
License GNU GPL
Website wiki.gnome.org/Projects/NetworkManager

NetworkManager is a software utility that aims to simplify the use of   on Linux-based and other Unix-like operating systems.

The device drivers for hardware network interfaces, are typically part of the operating system kernel. User space tools such as ifconfig or ip (from the iproute2-bundle) are used to configure the addresses and other characteristics of these network interfaces. Traditionally, during the operating system startup process, programs such as System V init or systemd have run shell scripts or other programs which configure the network interfaces based on fixed information from the host's configuration files.

However, dynamic configurations (i.e., not stored in a static configuration file but taken from outside the host, and potentially changing after boot) have been an increasingly more common configuration, especially as we've moved from physically large servers to more portable hosts that may be plugged and unplugged (or moved from WiFi hotspot to WiFi hotspot) at the will of the user. Bootp was an early protocol used for this, and to this day its descendant DHCP is still very common. Many Unix-like systems include a program called dhclient to handle this dynamic configuration.

Given a relatively static or simple dynamic configuration, static configuration modified by dhclient works well. However, as networks and their topologies get more complex, a central manager for all the network configuration information becomes more essential.

History[edit]

Red Hat initiated a NetworkManager project in 2004 with the goal of enabling Linux users to deal more easily with modern networking needs, particularly wireless networking. NetworkManager takes an opportunistic approach to network selection, attempting to use the best available connection as outages occur, or as the user roams between wireless networks. It prefers Ethernet connections over "known" wireless networks, which are preferred over wireless networks with SSIDs to which the user has never connected. The user is prompted for WEP or WPA keys as needed.

The NetworkManager project was among the first major Linux desktop components to utilize D-Bus and HAL extensively. Since June 2009, however, NetworkManager no longer depends on HAL, and since 0.9.10 (ca. 2014), neither does it require the D-Bus daemon to be running for root operation.[3]

Software architecture[edit]

NetworkManager has two components:

  1. the NetworkManager daemon, the actual software which manages connections and reports network changes
  2. several graphical front-ends for diverse surfaces, such as GNOME Shell, GNOME Panel, KDE Plasma Workspaces, Cinnamon, etc.

Both components are intended by the developers to be reasonably portable, and the applet is available to desktop environments which implement the Freedesktop.org System Tray Protocol,[4] including GNOME, KDE Plasma Workspaces, Enlightenment (software) and Xfce. As the components communicate via D-Bus, applications can be written to be "link-aware", or to replace the provided applet entirely. One example is KNetworkManager, a KDE frontend to NetworkManager developed by Novell for SUSE Linux.

Graphical front-ends and command line interfaces[edit]

Mobile broadband configuration assistant[edit]

Antti Kaijanmäki announced the development of a mobile broadband configuration assistant for NetworkManager in April 2008;[7] it became available in NetworkManager version 0.7.0. Together with the package mobile-broadband-provider-info the connection is easily configured.

See also[edit]

References[edit]

  1. Jump up ^ https://wiki.gnome.org/Projects/NetworkManager/
  2. Jump up ^ https://cgit.freedesktop.org/NetworkManager/NetworkManager/tag/?id=1.8.0
  3. Jump up ^ "We'll Build A Dream House Of Net". Blogs.gnome.org. Retrieved 2015-05-28.
  4. Jump up ^ Havoc Pennington <[email protected]>. "System Tray Protocol Specification". Standards.freedesktop.org. Retrieved 2012-02-04. CS1 maint: Multiple names: authors list (link)
  5. Jump up ^ "Initial pieces of nmcli, gitweb". Cgit.freedesktop.org. Retrieved 2015-05-28.
  6. Jump up ^ "cnetworkmanager - Command Line Interface for NetworkManager". Vidner.net. Retrieved 2012-02-04.
  7. Jump up ^ "Announce on networkmanager-list". Mail.gnome.org. 2008-04-10. Retrieved 2012-02-04.
  8. Jump up ^ "UMTSmon". Umtsmon.sourceforge.net. Retrieved 2012-02-04.

The NetworkManager Daemon

The NetworkManager daemon runs with root privileges and is, by default, configured to start up at boot time. You can determine whether the NetworkManager daemon is running by entering this command: 
~]$ systemctl status NetworkManager
NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled)
   Active: active (running) since Fri, 08 Mar 2013 12:50:04 +0100; 3 days ago
The systemctl status command will report NetworkManager as Active: inactive (dead) if the NetworkManager service is not running. To start it for the current session enter the following command as the root user: 
~]# systemctl start NetworkManager
Run the systemctl enable command to ensure that NetworkManager starts up every time the system boots: 
~]# systemctl enable NetworkManager
For more information on starting, stopping and managing services, see the Red Hat Enterprise Linux 7 System Administrator's Guide.

⁠1.4.2. Interacting with NetworkManager

Users do not interact with the NetworkManager system service directly. Instead, users perform network configuration tasks using graphical and command-line user interface tools. The following tools are available in Red Hat Enterprise Linux 7:
  1. A simple curses-based text user interface (TUI) for NetworkManager, nmtui, is available.
  2. A command-line tool, nmcli, is provided to allow users and scripts to interact with NetworkManager. Note that nmcli can be used on systems without a GUI such as servers to control all aspects of NetworkManager. It is on an equal footing with the GUI tools.
  3. The GNOME Shell also provides a network icon in its Notification Area representing network connection states as reported by NetworkManager. The icon has multiple states that serve as visual indicators for the type of connection you are currently using.
  4. A graphical user interface tool called control-center, provided by the GNOME Shell, is available for desktop users. It incorporates a Network settings tool. To start it, press the Super key to enter the Activities Overview, type control network and then press Enter. The Super key appears in a variety of guises, depending on the keyboard and other hardware, but often as either the Windows or Command key, and typically to the left of the Space key.
  5. A graphical user interface tool, nm-connection-editor, is available for certain tasks not yet handled by control-center. To start it, press the Super key to enter the Activities Overview, type network connections or nm-connection-editor and then press Enter.

1.7. Network Configuration Using the Command-Line Interface (CLI)

The commands for the ip utility, sometimes referred to as iproute2 after the upstream package name, are documented in the man ip(8) page. The package name in Red Hat Enterprise Linux 7 is iproute. If necessary, you can check that the ip utility is installed by checking its version number as follows: 

~]$ ip -V
ip utility, iproute2-ss130716
The ip commands can be used to add and remove addresses and routes to interfaces in parallel with NetworkManager, which will preserve them and recognize them in nmcli, nmtui, control-center, and the D-Bus API.

Note that the ip utility replaces the ifconfig utility because the net-tools package (which provides ifconfig) does not support InfiniBand addresses. The command ip help prints a usage message. Specific help is available for OBJECTS, for example: ip link help and ip addr help.

Note

ip commands given on the command line will not persist after a system restart. Where persistence is required, make use of configuration files (ifcfg files) or add the commands to a script.

Examples of using the command line and configuration files for each task are included after nmtui and nmcli examples but before explaining the use of one of the graphical user interfaces to NetworkManager, namely, control-center and nm-connection-editor.

⁠Running Network Script

Run the script only with the systemctl utility which will clear any existing environment variables and ensure clean execution. The command takes the following form: 
systemctl start|stop|restart|status network
Note that in Red Hat Enterprise Linux 7, NetworkManager is started first, and /etc/init.d/network checks with NetworkManager to avoid tampering with NetworkManager's connections. NetworkManager is intended to be the primary application using sysconfig configuration files and /etc/init.d/network is intended to be secondary, playing a fallback role.

The /etc/init.d/network script is not event-driven, it runs either:

  1. manually (by one of the systemctl commands start|stop|restart network),
  2. on boot and shutdown if the network service is enabled (as a result of the command systemctl enable network).
It is a manual process and does not react to events that happen after boot. Users can also call the scripts ifup and ifdown manually.

⁠Custom Commands and the Network Scripts

Custom commands in the scripts /sbin/ifup-local, ifdown-pre-local, and ifdown-local are only executed when those devices are controlled by the /etc/init.d/network service. The ifup-local file does not exist by default. If required, create it under the /sbin/ directory.

The ifup-local script is readable only by the initscripts and not by NetworkManager. To run a custom script using NetworkManager, create it under the dispatcher.d directory. See Section 1.8, "Running Dispatcher scripts" for an explanation of the dispatcher scripts.

Note

Red Hat does not provide support if a user modifies any files included with the initscripts package or related rpms.

There are ways to perform custom tasks when network connections go up and down, both with the old network scripts and with NetworkManager. When NetworkManager is enabled, the ifup and ifdown script will ask NetworkManager whether NetworkManager manages the interface in question, which is found from the "DEVICE=" line in the ifcfg file. If NetworkManager does manage that device, and the device is not already connected, then ifup will ask NetworkManager to start the connection.
  • If the device is managed by NetworkManager and it is already connected, nothing is done.
  • If the device is not managed by NetworkManager, then the scripts will start the connection using the older, non-NetworkManager mechanisms that they have used since the time before NetworkManager existed.
If you are calling ifdown and the device is managed by NetworkManager, then ifdown will ask NetworkManager to terminate the connection.

The scripts dynamically check NetworkManager, so if NetworkManager is not running, the scripts will fall back to the old, pre-NetworkManager script-based mechanisms.

⁠Running Dispatcher scripts

NetworkManager provides a way to run additional custom scripts to start or stop services based on the connection status. By default, the /etc/NetworkManager/dispatcher.d directory exists and NetworkManager runs scripts there, in alphabetical order. Each script must be an executable file owned by root and must have write permission only for the file owner. For more information about running NetworkManager dispatcher scripts, see the Red Hat Knowledgebase solution How to write a NetworkManager dispatcher script to apply ethtool commands.
Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

1.9. Network Configuration Using sysconfig Files

The /etc/sysconfig/ directory is a location for configuration files and scripts. Most network configuration information is stored there, with the exception of VPN, mobile broadband and PPPoE configuration, which are stored in /etc/NetworkManager/ subdirectories. Interface specific information for example, is stored in ifcfg files in the /etc/sysconfig/network-scripts/ directory.
The file /etc/sysconfig/network is for global settings. Information for VPNs, mobile broadband and PPPoE connections is stored in /etc/NetworkManager/system-connections/.

In Red Hat Enterprise Linux 7 when you edit an ifcfg file, NetworkManager is not automatically aware of the change and has to be prompted to notice the change. If you use one of the tools to update NetworkManager profile settings, then NetworkManager does not implement those changes until you reconnect using that profile. For example, if configuration files have been changed using an editor, NetworkManager must be told to read the configuration files again. To do that, issue the following command as root: 

~]# nmcli connection reload
The above command reads all connection profiles. Alternatively, to reload only one changed file, ifcfg-ifname, issue a command as follows: 
~]# nmcli con load /etc/sysconfig/network-scripts/ifcfg-ifname
The command accepts multiple file names. These commands require root privileges. For more information on user privileges and gaining privileges, see the Red Hat Enterprise Linux 7 System Administrator's Guide and the su(1) and sudo(8) man pages.

Changes made using tools such as nmcli do not require a reload but do require the associated interface to be put down and then up again. That can be done by using commands in the following format: 

nmcli dev disconnect interface-name
Followed by: 
nmcli con up interface-name
NetworkManager does not trigger any of the network scripts, though the network scripts will try to trigger NetworkManager if it is running when ifup commands are used. See Section 1.8, "NetworkManager and the Network Scripts" for an explanation of the network scripts.

The ifup script is a generic script which does a few things and then calls interface-specific scripts like ifup-ethX, ifup-wireless, ifup-ppp, and so on. When a user runs ifup eth0 manually, the following occurs:

  1. ifup looks for a file called /etc/sysconfig/network-scripts/ifcfg-eth0;
  2. if the ifcfg file exists, ifup looks for the TYPE key in that file to determine which type-specific script to call;
  3. ifup calls ifup-wireless or ifup-eth or ifup-XXX based on TYPE;
  4. the type-specific scripts do type-specific setup;
  5. and then the type-specific scripts let common functions perform IP-related tasks like DHCP or static setup.
On bootup, /etc/init.d/network reads through all the ifcfg files and for each one that has ONBOOT=yes, it checks whether NetworkManager is already starting the DEVICE from that ifcfg file. If NetworkManager is starting that device or has already started it, nothing more is done for that file, and the next ONBOOT=yes file is checked. If NetworkManager is not yet starting that device, the initscripts will continue with their traditional behavior and call ifup for that ifcfg file.

The end result is that any ifcfg file that has ONBOOT=yes is expected to be started on system bootup, either by NetworkManager or by the initscripts. This ensures that some legacy network types which NetworkManager does not handle (such as ISDN or analog dial-up modems) as well as any new application not yet supported by NetworkManager are still correctly started by the initscripts even though NetworkManager is unable to handle them.

Note

It is recommended not to store backup ifcfg files in the same location as the live ones. The script literally does ifcfg-* with an exclude only for these extensions: .old, .orig, .rpmnew, .rpmorig, and .rpmsave. The best way is not to store backup files anywhere within the /etc directory.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

  • man(1) man page - Describes man pages and how to find them.
  • NetworkManager(8) man page - Describes the network management daemon.
  • NetworkManager.conf(5) man page - Describes the NetworkManager configuration file.
  • /usr/share/doc/initscripts-version/sysconfig.txt - Describes ifcfg configuration files and their directives as understood by the legacy network service.
  • /usr/share/doc/initscripts-version/examples/networking/ - A directory containing example configuration files.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019