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?
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…
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.
BTW: What do I have to do to become a NethServer Ambasador? Who is your Hungarian representative?
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.
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 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
@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
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:
…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…
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. In that case I’ll consider switching workplaces.
Community can reward you in many ways, sadly payment isn’t one of them.
I hope that many hugs would be enough
I like the idea.
To recap:
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.
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:
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.