Honor static IP configuration from interactive ISO installer

If you remove it, the machine became totally inaccessible from the network.
This behavior has been in place since NS 6, I never found a better way to handle it.

How would you like to change it?

I suspect it overrides the user’s configuration applied by Anaconda. Is it possible?

…if the admin does not configure any network interface!

Use the upstream default, remove those lines.

What I am most worried about is when interfaces are not getting any settings when settings were given during install… :unamused:

Same worries me as a SysAdmin too Rob. I’ve set my custom IPs in anaconda during install, but at first boot I’ve found that the 2 eth card (who I gave static IP) were set to nothing and only the 1 set to DHCP was correct.
Also we are using PPPoE which is not configurable in the anaconda, that is why I’ve kept that eth card to DHCP saying: I’ll upgrade it via the webconfig. But since the staic addresses were not present I couldn’t find the server. So it was a pain to set up the server without a DHCP server (since this was intended to be it)

I didn’t know I’ll start sutch a brainstorm. Sorry for it. :smiley:

BTW: What do I have to do to become a NethServer Ambasador? :slight_smile: Who is your Hungarian representative?

1 Like

It’s fine for me to remove the network auto-configuration.
But please keep in mind that network configuration is not a required step by anaconda.
My prevision for the future: I see many users blaming the installer because the network is unreachable.

1 Like

Take a look at this:

tl;tr Become heavily active, create great contributions and probably you will be able to join the group in the future :slight_smile: Getting a regular level would definitely help

Ok, now a step back for me!

Right, but ns6 Anaconda was very different. However we have this setup in ns7 since alpha stage: it has been running for months. For this reason I wouldn’t remove it now. I’d only see if it is possible to make a small tweak to the kickstart file… will report back

1 Like

@giacomo: If you configure an interface, and when the system boots and the settings are not propagated for the interface, THAT is a bug. And that was what I was referring to.

I agree with you, but it seems a bug in Anaconda. Sadly, I can’t find anything inside any tracker.

Do you think leaving the whole network configuration to the user is a viable choice?

I have done multiple installs of NS7RC3 and RC4 the past weeks. Some of them on a physical machine (HP G7 microserver) and most in Virtualbox on an Ubuntu 16.04 host.
Both on the HP microserver and in Vbox I noticed that settings for network interfaces were not propagated after the initial reboot. I did not use the unattended install, and frankly, unless you have a simple single disk server, you want to configure your disks and network manually. But sadly, this seems not consistent with NS7RC3/4. (Or should I say it consistently fails?)
If this is an Anaconda issue, is upstream notified about these problems?

Well, I think I came to @giacomo’s conclusion. And it’s not an Anaconda bug, neither a kickstart one. Maybe Anaconda has some usability issues and breaks the user’s expectations …but we can’t fix them, we can only improve our docs :frowning:

I ran some experiments (more details at bottom) and read some docs

IMPORTANT

When a Red Hat Enterprise Linux 7 installation finishes and the system boots for the first time, any network interfaces which you configured during the installation will be activated. However, the installation does not prompt you to configure network interfaces on some common installation paths - for example, when you install Red Hat Enterprise Linux from a DVD to a local hard drive.

When you install Red Hat Enterprise Linux 7 from a local installation source to a local storage device, be sure to configure at least one network interface manually if you require network access when the system boots for the first time.

And

You will also need to set the connection to connect automatically after boot when editing the configuration.

This is documented to be the “Automatically connect to this network when it is available” option:

We could add an additional installation option. Now we have interactive, unattended and centos. We could add a manual one: it would be like interactive but does not pre-set any storage and network option.

More info about Anaconda kickstart customization:


Do you remember if you set “Automatically connect to this network when it is available”?

I can’t reproduce it:

My experiment

  1. Fired a new VM in KVM, with 4 network adapters. Three of them are attached to a network with DHCP.
  2. Boot with interactive method.
  3. Anaconda enables only the interfaces with DHCP (even if our kickstart enables all of them)
  • Entered the Network & Host Name section
    • Disabled DHCP interfaces
    • Enabled the remaining one
    • Entered the “Configure” section for it
      • Enabled “Automatically connect to this network when it is available” under General tab
      • Set manual IP configuration method under “IPv4 settings” (IP, mask, gateway, DNS)
      • Pressed “Save” button
    • After a while, my settings are displayed under the main screen
    • Set host name FQDN
    • Clicked “Apply”
    • Clicked “Done”

…the resulting system has ens3 configured as expected. I was astonished to see also the DHCP interfaces UP. I’d expect them DOWN, but this is another story…

1 Like

Cheers Fattorini,

In this case I won’t be a good ambasador but a good SysAdmin and guardian angle because I can’t be active. I’ve a 9h job every day and after job I’m happy if I can get to bed. Unless the community can give me a fix monthly payment. :smiley: In that case I’ll consider switching workplaces. :smiley:

Community can reward you in many ways, sadly payment isn’t one of them.
I hope that many hugs would be enough :family_men_boys:

1 Like

I like the idea.
To recap:

  • unattended installation not changed
  • interactive installation not changed
  • manual installation: only nethserver packages will be pre-selected, all other configuration will be left to the user

/cc @dev_team @quality_team @ambassadors_group

1 Like

Opened an issue

AFAIR I did not set the “Automatically connect to this network when it is available” since I though this is default for static cards. However, seems just the oposite happened. The DHCp was OK, the 2 static was not up. But the issue here is not if the network card is up or down. I had no settings at all. Basically everything I’ve set during the install, were ereased.

May I also advise to use the text based installer? I think it looks way cooler to use. :smiley:

What do you exactly mean with everything?

Speaking of static network interfaces, the symptom matches our expectations. At first boot NethServer (during system-init event) initializes the e-smith DB “networks” with the output from ip addr. It detects any running dhclient instance to see if DHCP is required. This is the script:

nethserver-base/root/etc/e-smith/events/actions/nethserver-base-initialize-db at 914aa14be9229d2f1a57a86f3564459e1914086a · NethServer/nethserver-base · GitHub

Under everything I mean everything. There was no ifcfg-eth1 and ifcfg-eth2 and there were no settings available for these two cards. Only eth0 was present with DHCP settings but since there was no DHCP server at the time (cause it became the DHCP server later on) it did not recieve eny IP address.

The only thing to do in that case is set “Automatically connect to this network when it is available”, otherwise the settings from Anaconda are lost after system-init.

BTW, this is the kind of things that happen when we don’t follow CentOS. On a clean CentOS installation there are NetworkManager and firewalld running. We use the legacy network script and Shorewall, instead. We’ve seen here the reasons to keep the things the way they are, but - yes - there are some inconsistencies.