Hello:
As I continue dealing with iptables, another issue has come up that I can't tell is a mis-understanding on my part or a potential problem
I have three F16 machines, one x86_64 and two i383/686. If I run /sbin/ifconfig on them, I get (short summary of):
x86_64: eth0 i686: em1
Looking in /etc/sysconfig/network-scripts, I can see only ifcfg-em1 and no ifcfg-eth0 on all the machines (x86_64 and i686).
The closest bugzilla I can see if 784314 but it looks like it hints that ifconfig is old-school and the right way to do things (and its F17 not F16).
Does anyone know what I am either doing wrong or if this looks like a problem/bug. Plus, if there is a better way, I'd love to know.
What I want to do is have is a bash way to get the static ip address of the machine which I can see in eth0/em1. I've been using something I found online which assumes everything is eth0 (as in I think it was for older Fedora): +++ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}' +++
Its too clever for me to have come up with on my own (smile).
I tried expanding the grep to be 'inet addr:192.168.2' but that failed on the laptop which has an entry for wireless which is dhcp (I cannot assume wireless will be 192.168.2.*).
Any suggestions appreciated, Thanks, Paul
[updated, keeping original post and adding new info at bottom]
On 5/22/2012 8:12 PM, Paul Allen Newell wrote:
Hello:
As I continue dealing with iptables, another issue has come up that I can't tell is a mis-understanding on my part or a potential problem
I have three F16 machines, one x86_64 and two i383/686. If I run /sbin/ifconfig on them, I get (short summary of):
x86_64: eth0 i686: em1
Looking in /etc/sysconfig/network-scripts, I can see only ifcfg-em1 and no ifcfg-eth0 on all the machines (x86_64 and i686).
The closest bugzilla I can see if 784314 but it looks like it hints that ifconfig is old-school and the right way to do things (and its F17 not F16).
Does anyone know what I am either doing wrong or if this looks like a problem/bug. Plus, if there is a better way, I'd love to know.
What I want to do is have is a bash way to get the static ip address of the machine which I can see in eth0/em1. I've been using something I found online which assumes everything is eth0 (as in I think it was for older Fedora): +++ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}' +++
Its too clever for me to have come up with on my own (smile).
I tried expanding the grep to be 'inet addr:192.168.2' but that failed on the laptop which has an entry for wireless which is dhcp (I cannot assume wireless will be 192.168.2.*).
Any suggestions appreciated, Thanks, Paul
Okay, so I managed to figure out that 'ip' is the new command. I'd looked at it earlier to try to find a way around this, but couldn't figure it out. Just spotted the 'obsolete, use ip' in man page of ifconfig. As usual, there is always something discovered right after I make the post.
Should I assume that even if ifconfig is giving a problem, its academic and I should just focus on ip. And, if so, how the heck does one get the ip addr. If I use "ip addr show", I still get eth0 on the x86_64 and em1 on the i686?
Thanks, Paul
On 05/23/2012 11:22 AM, Paul Allen Newell wrote:
[updated, keeping original post and adding new info at bottom]
On 5/22/2012 8:12 PM, Paul Allen Newell wrote:
Hello:
As I continue dealing with iptables, another issue has come up that I can't tell is a mis-understanding on my part or a potential problem
I have three F16 machines, one x86_64 and two i383/686. If I run /sbin/ifconfig on them, I get (short summary of):
x86_64: eth0 i686: em1
Looking in /etc/sysconfig/network-scripts, I can see only ifcfg-em1 and no ifcfg-eth0 on all the machines (x86_64 and i686).
The closest bugzilla I can see if 784314 but it looks like it hints that ifconfig is old-school and the right way to do things (and its F17 not F16).
Does anyone know what I am either doing wrong or if this looks like a problem/bug. Plus, if there is a better way, I'd love to know.
What I want to do is have is a bash way to get the static ip address of the machine which I can see in eth0/em1. I've been using something I found online which assumes everything is eth0 (as in I think it was for older Fedora): +++ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}' +++
Its too clever for me to have come up with on my own (smile).
I tried expanding the grep to be 'inet addr:192.168.2' but that failed on the laptop which has an entry for wireless which is dhcp (I cannot assume wireless will be 192.168.2.*).
Any suggestions appreciated, Thanks, Paul
Okay, so I managed to figure out that 'ip' is the new command. I'd looked at it earlier to try to find a way around this, but couldn't figure it out. Just spotted the 'obsolete, use ip' in man page of ifconfig. As usual, there is always something discovered right after I make the post.
Should I assume that even if ifconfig is giving a problem, its academic and I should just focus on ip. And, if so, how the heck does one get the ip addr. If I use "ip addr show", I still get eth0 on the x86_64 and em1 on the i686?
I guess I really don't know what precisely is the problem you're having.
Interface naming convention has been undergoing changes since, maybe, F14. Interfaces that were once called eth0 became em1 and other niceties. I don't recall if the names changed on upgrades or only new installs. Anyway, the changes didn't make my life miserable, so I've kind of ignored the changes.
So, what is it that you are really after? Do you just want a script, or series of commands, to return the IP address of a single, known interface?
As in something like this?
[egreshko@meimei net]$ /sbin/ifconfig p128p1 | grep 'inet ' | cut -d : -f 2 | awk '{ print $1}' 192.168.0.18
Maybe if you posted the output of commands on your system and asked questions based on the output it would make more sense....at least to me.
On 5/22/2012 9:38 PM, Ed Greshko wrote:
I guess I really don't know what precisely is the problem you're having.
Interface naming convention has been undergoing changes since, maybe, F14. Interfaces that were once called eth0 became em1 and other niceties. I don't recall if the names changed on upgrades or only new installs. Anyway, the changes didn't make my life miserable, so I've kind of ignored the changes.
So, what is it that you are really after? Do you just want a script, or series of commands, to return the IP address of a single, known interface?
As in something like this?
[egreshko@meimei net]$ /sbin/ifconfig p128p1 | grep 'inet ' | cut -d : -f 2 | awk '{ print $1}' 192.168.0.18
Maybe if you posted the output of commands on your system and asked questions based on the output it would make more sense....at least to me.
Ed:
Thanks for reply.
First problem is I think there is something wrong if "ip addr show" lists eth0 on x86_64 and em1 on i686. I know things are in transition, but I would expect that to be on a release by release, not sub-set of platform by platform as it makes scripts that work on one break on the other. I am trying to get some validation that I am not doing something wrong so I can submit as bug
Second problem is, given that, I can't figure out how to get "ip addr show" to work on both platforms. My fault for not including example as I was more focused on the possible bug and thinking I just needed to kick the ip command a few more times.
On x86_64, "ip addr show" gives: +++
1: lo:<LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:1e:68:26:b1:ff brd ff:ff:ff:ff:ff:ff inet 192.168.2.13/24 brd 192.168.2.255 scope global eth0 inet6 fe80::21e:68ff:fe26:b1ff/64 scope link valid_lft forever preferred_lft forever 3: wlan0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:1f:3a:c1:1c:79 brd ff:ff:ff:ff:ff:ff inet 192.168.2.103/24 brd 192.168.2.255 scope global wlan0 inet6 fe80::21f:3aff:fec1:1c79/64 scope link valid_lft forever preferred_lft forever +++
On i686, it gives: +++ 1: lo:<LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:e0:81:00:4c:b0 brd ff:ff:ff:ff:ff:ff inet 192.168.2.10/24 brd 192.168.2.255 scope global em1 inet6 fe80::2e0:81ff:fe00:4cb0/64 scope link valid_lft forever preferred_lft forever +++
One uses eth0, the other em1.
I tried using the label option with a pattern, but can't figure out how to tell ip to show me any devices that match eth0 or em1. I figured out that I can tell it "label e*" but that feels like a hack since it opens me up to any future names changes that start with an e* without assures that there won't be two "e*" entries on a given machine.
So, I was able to hack up something in which: +++ theUname=`uname -p` theDeviceToCheck="eth0" if [ ${theUname} != "x86_64" ]; then theDeviceToCheck="em1" fi theIpAddr=`/sbin/ip addr show ${theDeviceToCheck} | grep 'inet ' | awk '{ print $2}' +++
SO, I am at least running (but with a groan at how)
I'd like a single command with no "if's" (ip or other) that give me 192.168.2.x (I can handle if it has "/24?) on the end.
Paul
On 05/23/2012 01:31 PM, Paul Allen Newell wrote:
SO, I am at least running (but with a groan at how)
I'd like a single command with no "if's" (ip or other) that give me 192.168.2.x (I can handle if it has "/24?) on the end.
Well, as you said, things are in transition.... And, if you did some google searches you'd find that there were/are differences between how interface names appear(ed) at various points depending on system architecture. That seems to be your main "issue".
All that aside.... If you have a system with a single interface you can always do....
[egreshko@meimei test]$ /sbin/ifconfig | grep 'inet ' | grep -v '127.0.0.1' | cut -d : -f 2 | awk '{ print $1}' 192.168.0.18
On 5/22/2012 10:49 PM, Ed Greshko wrote:
Well, as you said, things are in transition.... And, if you did some google searches you'd find that there were/are differences between how interface names appear(ed) at various points depending on system architecture. That seems to be your main "issue".
All that aside.... If you have a system with a single interface you can always do....
[egreshko@meimei test]$ /sbin/ifconfig | grep 'inet ' | grep -v '127.0.0.1' | cut -d : -f 2 | awk '{ print $1}' 192.168.0.18
Ed:
With all due respect, its become clear to me that ifconfig is obsolete and a solution which uses it doesn't have a future. Can you try to get the ip address with command "ip" on a i686 and x86_64 system without having to run a different command for each?
As for the "issue", I am still hoping someone can tell me that "ip addr show" giving a different device for the static IP on x86_64 and i686 is "not right" so I can bug it with confidence that I am not making a mistake (or let me know that I am making a mistake ... with enough info that I can confirm it is a pilot error)
Thanks, Paul
On 05/23/2012 02:17 PM, Paul Allen Newell wrote:
On 5/22/2012 10:49 PM, Ed Greshko wrote:
Well, as you said, things are in transition.... And, if you did some google searches you'd find that there were/are differences between how interface names appear(ed) at various points depending on system architecture. That seems to be your main "issue".
All that aside.... If you have a system with a single interface you can always do....
[egreshko@meimei test]$ /sbin/ifconfig | grep 'inet ' | grep -v '127.0.0.1' | cut -d : -f 2 | awk '{ print $1}' 192.168.0.18
Ed:
With all due respect, its become clear to me that ifconfig is obsolete and a solution which uses it doesn't have a future. Can you try to get the ip address with command "ip" on a i686 and x86_64 system without having to run a different command for each?
It will continue to work.... Just not support some new features.
As for the "issue", I am still hoping someone can tell me that "ip addr show" giving a different device for the static IP on x86_64 and i686 is "not right" so I can bug it with confidence that I am not making a mistake (or let me know that I am making a mistake ... with enough info that I can confirm it is a pilot error)
???? The "ip" command has nothing to do with the device/interface name.
It simply lists information on all the interfaces available on the system...regardless of if they are up/down.... There is no "right" or "wrong".
[egreshko@meimei ~]$ ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: p128p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 40:61:86:7c:2b:db brd ff:ff:ff:ff:ff:ff inet 192.168.0.18/24 brd 192.168.0.255 scope global p128p1 inet6 fe80::4261:86ff:fe7c:2bdb/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 70:1a:04:f4:df:69 brd ff:ff:ff:ff:ff:ff 5: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
[egreshko@meimei ~]$ ip addr show dev p128p1 2: p128p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 40:61:86:7c:2b:db brd ff:ff:ff:ff:ff:ff inet 192.168.0.18/24 brd 192.168.0.255 scope global p128p1 inet6 fe80::4261:86ff:fe7c:2bdb/64 scope link valid_lft forever preferred_lft forever
Maybe the question you should be asking is this?
I don't like the names that have been assigned to my network interfaces. How can I change them to be what I want them to be?
On 5/22/2012 11:33 PM, Ed Greshko wrote:
Maybe the question you should be asking is this? I don't like the names that have been assigned to my network interfaces. How can I change them to be what I want them to be?
Ed:
Okay, that's a good question that I hadn't considered. So do you happen to know how to change the names?
Paul
On 05/23/2012 02:46 PM, Paul Allen Newell wrote:
Okay, that's a good question that I hadn't considered. So do you happen to know how to change the names?
No. Not something that I've needed or wanted to do.
Am 23.05.2012 08:17, schrieb Paul Allen Newell:
With all due respect, its become clear to me that ifconfig is obsolete and a solution which uses it doesn't have a future. Can you try to get the ip address with command "ip" on a i686 and x86_64 system without having to run a different command for each?
As for the "issue", I am still hoping someone can tell me that "ip addr show" giving a different device for the static IP on x86_64 and i686 is "not right" so I can bug it with confidence that I am not making a mistake (or let me know that I am making a mistake ... with enough info that I can confirm it is a pilot error)
edit "/etc/udev/rules.d/70-persistent-net.rules" (ONE LINE, replace MAC with yours)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:bd:00:27", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" __________________________
this has NOTHING to do with i686 / x86_64 http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
remove the package, edit config as statet above and that was it
On 5/23/2012 1:07 AM, Reindl Harald wrote:
edit "/etc/udev/rules.d/70-persistent-net.rules" (ONE LINE, replace MAC with yours)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:bd:00:27", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" __________________________
this has NOTHING to do with i686 / x86_64 http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
remove the package, edit config as statet above and that was it
Reindl:
Thanks for the reply and the link. Its going to take a few readings to understand (and a bunch more googling to make sure I understand all the implications), but I think it is the start I need.
So I am presuming given your email that this is not something that I should consider a bug?
Paul
On 05/22/2012 09:12 PM, Paul Allen Newell wrote:
Hello:
As I continue dealing with iptables, another issue has come up that I can't tell is a mis-understanding on my part or a potential problem
I have three F16 machines, one x86_64 and two i383/686. If I run /sbin/ifconfig on them, I get (short summary of):
x86_64: eth0 i686: em1
Just to add fuel to the fire:
Soon more and more systems will have UEFI as well as, or instead of the old BIOS. On most newer sever class systems, the traditional BIOS is *emulated* in the EUFI.
The EUFI, and, therefore, newer BIOS, can provide much more information to the OS than before.
Linux kernels are attempting to be more 'aware' of the new information. It will provide much better control and flexibility with devices.
That being said, you can avoid it all for now, by adding 'biosdevname=0' to the kernel command line in grub, or upon boot. Already defined devices will not change, but if you include that argument during installs, or on LiveCDs, you will get the old consistent device names, ie: eth0, every time.
The fact that two fresh installs got one old (eth0) and one new (em1) device definition, shows the difference in the two versions of BIOS, NOT anything to do with 64 bit vs 32 bit.
Good Luck!
[comments inline]
On 5/23/2012 1:53 PM, Phil Meyer wrote:
Just to add fuel to the fire:
Soon more and more systems will have UEFI as well as, or instead of the old BIOS. On most newer sever class systems, the traditional BIOS is *emulated* in the EUFI.
The EUFI, and, therefore, newer BIOS, can provide much more information to the OS than before.
Linux kernels are attempting to be more 'aware' of the new information. It will provide much better control and flexibility with devices.
That being said, you can avoid it all for now, by adding 'biosdevname=0' to the kernel command line in grub, or upon boot. Already defined devices will not change, but if you include that argument during installs, or on LiveCDs, you will get the old consistent device names, ie: eth0, every time.
Phil:
Thanks for the reply. You just upped my reading list (smile). Let me google with what you've provided above and what others have offered. I've now got more than enough info to drown in and need to sort through it before trying to get more.
The fact that two fresh installs got one old (eth0) and one new (em1) device definition, shows the difference in the two versions of BIOS, NOT anything to do with 64 bit vs 32 bit.
Okay, that gives me a 100% answer on that question. I just assumed out of ignorance that it was on a Fedora level and never considered (or had the knowledge to consider) that it might be a BIOS issue.
Good Luck!
I think I am going to need it ...
Thanks again, Paul
Ed Greshko wrote:
On 05/23/2012 11:22 AM, Paul Allen Newell wrote:
[updated, keeping original post and adding new info at bottom]
On 5/22/2012 8:12 PM, Paul Allen Newell wrote:
Hello:
As I continue dealing with iptables, another issue has come up that I can't tell is a mis-understanding on my part or a potential problem
I have three F16 machines, one x86_64 and two i383/686. If I run /sbin/ifconfig on them, I get (short summary of):
x86_64: eth0 i686: em1
Looking in /etc/sysconfig/network-scripts, I can see only ifcfg-em1 and no ifcfg-eth0 on all the machines (x86_64 and i686).
The closest bugzilla I can see if 784314 but it looks like it hints that ifconfig is old-school and the right way to do things (and its F17 not F16).
Does anyone know what I am either doing wrong or if this looks like a problem/bug. Plus, if there is a better way, I'd love to know.
What I want to do is have is a bash way to get the static ip address of the machine which I can see in eth0/em1. I've been using something I found online which assumes everything is eth0 (as in I think it was for older Fedora): +++ /sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}' +++
Its too clever for me to have come up with on my own (smile).
I tried expanding the grep to be 'inet addr:192.168.2' but that failed on the laptop which has an entry for wireless which is dhcp (I cannot assume wireless will be 192.168.2.*).
Any suggestions appreciated, Thanks, Paul
Okay, so I managed to figure out that 'ip' is the new command. I'd looked at it earlier to try to find a way around this, but couldn't figure it out. Just spotted the 'obsolete, use ip' in man page of ifconfig. As usual, there is always something discovered right after I make the post.
Should I assume that even if ifconfig is giving a problem, its academic and I should just focus on ip. And, if so, how the heck does one get the ip addr. If I use "ip addr show", I still get eth0 on the x86_64 and em1 on the i686?
I guess I really don't know what precisely is the problem you're having.
Interface naming convention has been undergoing changes since, maybe, F14. Interfaces that were once called eth0 became em1 and other niceties. I don't recall if the names changed on upgrades or only new installs. Anyway, the changes didn't make my life miserable, so I've kind of ignored the changes.
The problem with naming is that for every server run by experienced sysadmins, there are thousands of machines with a single NIC which benefits not one bit from having a name based on which slot it occupies. That's actually not much of a benefit on a server, either, since the IP is assigned by MAC address in DHCP, and if I work on the machine I really want to be able to put any card in any slot and match the label on the cable to the label on the NIC, and have scripts which don't have to be needlessly complex to discover the name of the interface.
*Particularly if I want the script to run on multiple machines!*
So, what is it that you are really after? Do you just want a script, or series of commands, to return the IP address of a single, known interface?
I think he wants the "single, known interface" to have a single known name, and not some random characters determined by the whichness of what.
Am 27.05.2012 14:59, schrieb Bill Davidsen:
The problem with naming is that for every server run by experienced sysadmins
"experienced sysadmins" should not have a problem to open "/etc/udev/rules.d/70-persistent-net.rules" and define "eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="3c:d9:2b:65:95:9f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I really want to be able to put any card in any slot and match the label on the cable to the label on the NIC, and have scripts which don't have to be needlessly complex to discover the name of the interface.
nothing has changed here
if you replaced a network card in the past you also had to edit "70-persistent-net.rules" because it became "eth1"
"yum remove biosdevname" and act like all the years before i have in summary around 30 F16 setups with 20 of them as production sevrers and there is no machine not having "eth0"
Hi,
I'm going to do a clean install of F17 and was wondering about the new file system. I'm installing it onto a new hard drive. Since I'm doing a clean install is there a way to not install or remove the Symlinks in the new / directory layout? I see no need to have them. Will F17 run without them? I only ask because it would make a cleaner and neater file system. In no way does it bother me to have them. I'm just curious.
Norman
Am 27.05.2012 17:00, schrieb NRL:
I'm going to do a clean install of F17 and was wondering about the new file system. I'm installing it onto a new hard drive. Since I'm doing a clean install is there a way to not install or remove the Symlinks in the new / directory layout?
why?
I see no need to have them
remove them and you will see with broken system and software all over the place there are thousands of scriipts starting with "#!/bin/basg" as one example
Will F17 run without them?
no and even if you will not be able to run third party sofwtare for many years without them
Thanks for your response.
That makes sense. I kinda figured that but did not know.
Tuesday can't come fast enough.
-------------------------------------------------------------------------------------
On 05/27/2012 11:03 AM, Reindl Harald wrote:
Am 27.05.2012 17:00, schrieb NRL:
I'm going to do a clean install of F17 and was wondering about the new file system. I'm installing it onto a new hard drive. Since I'm doing a clean install is there a way to not install or remove the Symlinks in the new / directory layout?
why?
I see no need to have them
remove them and you will see with broken system and software all over the place there are thousands of scriipts starting with "#!/bin/basg" as one example
Will F17 run without them?
no and even if you will not be able to run third party sofwtare for many years without them
On 05/27/2012 08:59 PM, Bill Davidsen wrote:
I really want to be able to put any card in any slot and match the label on the cable to the label on the NIC, and have scripts which don't have to be needlessly complex to discover the name of the interface
OK, but you do realize that you are simply shifting the complexity to the human. If, for example, you (or someone who works for you) change a network card whose cable was labeled eth0 you will need to remember to edit the 70-persistent-net.rules. Otherwise you'll end up with that new card being labeled eth(n-1)+1 where n is equal to the number of interfaces you have.
FWIW, I believe, on a "normal" install the 70-persistent-net.rules doesn't exist. So, you'd need to....
1. yum erase biosdevname 2. reboot the system to have it create the 70-persistent-net.rules file 3. edit 70-persistent-net.rules to your liking 4. reboot for the changes to take effect.
But, the flexibility is there as Reindl pointed out.
On Sun, 27 May 2012 23:39:06 +0800 Ed Greshko wrote:
If, for example, you (or someone who works for you) change a network card whose cable was labeled eth0 you will need to remember to edit the 70-persistent-net.rules.
That always seemed dumb to me. It can tell (or make a good guess) if the interface is hot pluggable, or something you had to take the machine apart to change. In the case of old entries that weren't on hot pluggable interfaces, it should remove those before assigning names to new ones, then swapping out a NIC would still assign eth0 to the new NIC, but plugging in a new USB Wi-Fi dongle would continue to assign wlan0 then wlan1, etc.
It should do the same thing for persistent disks. If I replace an internal DVDROM, it should be smart enough to call the replacement sr0 instead of sr1.
On 5/27/2012 5:59 AM, Bill Davidsen wrote:
I think he wants the "single, known interface" to have a single known name, and not some random characters determined by the whichness of what.
Bill (and Reindl, Ed, and Tom who replied to Bill):
Thanks for the addition comments.
The statement Bill offers above is exactly what I was looking for. And I went through all of the information given in this thread and realized I was trying to solve the wrong problem.
What I was after was the ip address (aka 192.168.2.13) and the only way I could see to get it was through the ip command which needed a token to grep for. That token is what I wanted to be a single known name. My understanding of the situation now is that is not how things work.
Since I couldn't find a single command which would get me the static ip of the wired connection, I decided to just use hostname as the important thing was "a unique name". I originally didn't want to do that as names are changeable, but then I realized that the same holds true for static ip addresses ... if I can change a hostname, I can change a static ip.
I considered MAC address, but it looked like I was back to the problem of using ip and grepping on a potentially different token per machine.
Problem is solved as far as I am concerned, even though I am certain there is probably some way to get a unique token. Since my goal is to get the machine up and running so I can be a user on it, I learned from all the material offered that it is best to cut my losses.
Once again, I thank everyone for their help ... I've got a much better understand of just what eth0 and em1 are (smile)
Paul
Once upon a time, Paul Allen Newell pnewell@cs.cmu.edu said:
Problem is solved as far as I am concerned, even though I am certain there is probably some way to get a unique token. Since my goal is to get the machine up and running so I can be a user on it, I learned from all the material offered that it is best to cut my losses.
If you are looking for the address of the default interface, you can fetch based on the default route. This should work on most systems, as almost all have a default route, and few have more than one.
- get the default route entry: ip route list match 0.0.0.0
- get just the device name: ip route list match 0.0.0.0 | sed 's/.* dev ([^ ]*).*/\1/'
- list the address(es) on the default device: ip addr list $(ip route list match 0.0.0.0 | sed 's/.* dev ([^ ]*).*/\1/')