You may have noticed that fresh installations of Fedora 15 have network device named of “em1” or “p1n1” rather than the easy to remember “eth” nomenclature. It seems that those in the Linux world wish to take a step backwards, forgetting all that was gained with the simplified naming convention.
Dial back time about 15 years, SunOS and HP-UX dominate the market, and it was a nightmare scripting around the various network device names (as well as the disk device names, too, but that is another story.. let’s hope that doesn’t return!). When dealing with multiple models within the same platform, there was no guarantee you would end up with the same device name.
In the most simplistic terms, with linux’s use of “eth” and “hd” (or now “sd”), it made the newly evolving world of systems administration that much easier to manage and maintain.
While there is justification behind the change on the Fedora site, it is clearly a “head in the sand” move, one that only moves the core coding difficulties out from the linux device drivers & udev to now be a difficulty for the administrators and end users. Administrators and users now have to update udev rules to go back to “eth” device names if they want to keep things clean. Thanks for the extra work.
Device mapper does a great job at translating devices to somewhat human readable format. Yet, that layer breaks down in the logging. Let’s take the situation where you have an error in the filesystem that is getting reported in dmesg or syslog:
[1297912.800024] EXT4-fs (dm-1): error count: 1
[1297912.800030] EXT4-fs (dm-1): initial error at 1322435090: ext4_find_entry:934: inode 7340671
[1297912.800034] EXT4-fs (dm-1): last error at 1322435090: ext4_find_entry:934: inode 7340671
Questions abound: “This looks bad, but what is this?” “It’s a filesystem problem, but which filesystem?”
Take a look at /dev/dm*:
~]# ls -l /dev/dm*
brw-rw---- 1 root disk 253, 0 Jan 27 14:29 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jan 27 14:29 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jan 27 14:29 /dev/dm-2
brw-rw---- 1 root disk 253, 3 Jan 27 14:29 /dev/dm-3
And, finally, map the two based upon the node number. In the above example, from our ls we know that dm-1 is “253,1” and from dmsetup we know that “253,1” is vg_hostname-lv_root. So, dm-1 is vg_hostname-lv_root, and, since it is the root volume, a forced recheck of the root volume needs to be perfored at the next reboot (touch /forcecheck; init 6). It is best to monitor that re-check of the filesystem, so it would not be advisable to do this fsck remotely.
On a Fedora server (in this case 14, 15, and 16) acting as the primary LDAP server, it can get stuck booting if LDAP is not ready in time. You end up with a race condition where LDAP is stuck attempting to start for one reason or another and other services are stuck waiting for LDAP. Typically, this is because PAM, either via the nss_ldap or pam_ldap modules, is attempting to look up a user to start a particular server and it is configured to also look in LDAP.
There are two ways to fix this:
1. Maintain /etc/pam_ldap.conf and /etc/nss_ldap.conf’s “nss_initgroups_ignoreusers” line to contain all of your various services, or
2. Modify /etc/pam_ldap.conf and /etc/nss_ldap.conf to have “bind_policy soft” enabled.
The “bind_policy soft” is synonymous to a “soft” mount in /etc/fstab: it will cause a soft “fail” of the lookup allowing the process to proceed rather than hang on trying to get a response. This policy is a bit easier to manage and safer since it won’t put the administrator in a position where there is a deadlock.