IP Aliases: The YaST way and the "ip" way -- Are both slightly broken?
by rnturn from LinuxQuestions.org on (#5K9PE)
Environment: OpenSUSE Leap 15.2 (that upgrade to 15.3 is just around the corner). Apache 2.4.4 newly compiled. No error/warnings (remarkably clean session log).
I have three Apache 2.4.4 virtual hosts that are supposed to use addresses "192.168.13.20[0-2]". Initially, I created those using the dialog in YaST for adding additional addresses to a particular interface. Apache would not start, complaining about not being able to "bind a sock" (I don't recall the exact error message but it seemed to be address-related). I tried verifying that YaST had created them by issuing "ip addr" but no aliases. So... I deleted them in YaST.
Those aliases were then added using "ip address add 192.168.13.20N/24 dev eth0" and they actually show up when issuing "ip addr". I am unable to ping any of the three despite "ip" telling me that they're associated with "eth0". Using the deprecated "netstat", I cannot see any of those three addresses in a "LISTEN" state. (Which I didn't find surprising since Apache didn't start and there weren't any processes tied to those addresses.)
Just for grins, I created an address "192.168.13.234/24" using YaST. Then I grepped for that IP address under /etc. I found that, as expected, it had left information under /etc/sysconfig/network about the alias---something that "ip" didn't do when I grepped for one of the "aliases" I'd set up using that utility. Wierd. (Especially since "ip" is the new kid here to replace "ifconfig".) Also, the YaST-created alias showed up in netstat's output but NOT in ip's.
I decided to edit the ifcfg-eth0 file in /etc/sysconfig/network and duplicate the entry for the ".234" address and tweaked them so that I had ".200", ".201", and ".202". Then I jumped into YaST and verified that it "saw" the hand-edited aliases. It even accepted the ":" I put in the labels for the aliases (something that YaST itself would not allow in its add-an-address dialog). Thinking that the "ifcfg" files are, apparently, only getting read when the network layer (in my case "wicked") is bounced, I had systemctl do that even though I thought YaST did that step after you committed your changes. After that, "ip" sees the new YaST-approved aliases/labels as well.
On another forum I stumbled across while researching this, one of the frequent posters seemed to insist that "ip" was the True and Correct way to create aliases. If that's the case I'm just not sure how "ip"'s settings result in network changes that survive a reboot.
Question: Just what is the correct means of manipulating network addresses these days? YaST seems to leave the disk-based information that subsequent bootstraps and network restarts can use. AFAICT, "ip" just seems to tweak settings in memory. Is this akin to the days of a device like, say, a terminal server where you could "define" a setting (make it part of the non-volatile configuration) or "set" a setting (change it now in the in-memory configuration but lose that after a restart) so, essentially, YaST is doing the "define" but "ip" only does the "set"?
I look forward to reading other's experiences with this.
Cheers...
I have three Apache 2.4.4 virtual hosts that are supposed to use addresses "192.168.13.20[0-2]". Initially, I created those using the dialog in YaST for adding additional addresses to a particular interface. Apache would not start, complaining about not being able to "bind a sock" (I don't recall the exact error message but it seemed to be address-related). I tried verifying that YaST had created them by issuing "ip addr" but no aliases. So... I deleted them in YaST.
Those aliases were then added using "ip address add 192.168.13.20N/24 dev eth0" and they actually show up when issuing "ip addr". I am unable to ping any of the three despite "ip" telling me that they're associated with "eth0". Using the deprecated "netstat", I cannot see any of those three addresses in a "LISTEN" state. (Which I didn't find surprising since Apache didn't start and there weren't any processes tied to those addresses.)
Just for grins, I created an address "192.168.13.234/24" using YaST. Then I grepped for that IP address under /etc. I found that, as expected, it had left information under /etc/sysconfig/network about the alias---something that "ip" didn't do when I grepped for one of the "aliases" I'd set up using that utility. Wierd. (Especially since "ip" is the new kid here to replace "ifconfig".) Also, the YaST-created alias showed up in netstat's output but NOT in ip's.
I decided to edit the ifcfg-eth0 file in /etc/sysconfig/network and duplicate the entry for the ".234" address and tweaked them so that I had ".200", ".201", and ".202". Then I jumped into YaST and verified that it "saw" the hand-edited aliases. It even accepted the ":" I put in the labels for the aliases (something that YaST itself would not allow in its add-an-address dialog). Thinking that the "ifcfg" files are, apparently, only getting read when the network layer (in my case "wicked") is bounced, I had systemctl do that even though I thought YaST did that step after you committed your changes. After that, "ip" sees the new YaST-approved aliases/labels as well.
On another forum I stumbled across while researching this, one of the frequent posters seemed to insist that "ip" was the True and Correct way to create aliases. If that's the case I'm just not sure how "ip"'s settings result in network changes that survive a reboot.
Question: Just what is the correct means of manipulating network addresses these days? YaST seems to leave the disk-based information that subsequent bootstraps and network restarts can use. AFAICT, "ip" just seems to tweak settings in memory. Is this akin to the days of a device like, say, a terminal server where you could "define" a setting (make it part of the non-volatile configuration) or "set" a setting (change it now in the in-memory configuration but lose that after a restart) so, essentially, YaST is doing the "define" but "ip" only does the "set"?
I look forward to reading other's experiences with this.
Cheers...