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.
БогородицаiDevices like the iPhone and iPad have the ability to print to select “supported” printers. Basically, those printers are just broadcasting Apple’s bonjour service to which the iDevice detects natively.
However, those “supported” printers aren’t all that readily available and corporate environments being inundated with iDevices can’t rightly replace all of their printers.
With a standard CUPS server, the avahi-daemon, and a simple python script, this can be easily solved! Grab the script from https://github.com/tjfontaine/airprint-generate and run it against your installed CUPS printers.
Avahi/Bonjour is a protocol that does not cross subnets. If you have a need for this, which is a typical corporate need, check out http://www.grouplogic.com/Knowledge/PDFUpload/Info/WanBonjour_1.pdf