Well, I’ve finally deployed some production Openfiler ESA 2.99.1 machines as home-brew iSCSI boxes, primarily used for backups or low-stress virtual storage. Yes, they’re great — my basic write speeds on a Core 2 Duo box (recycled Dell Precision 390 workstation with 2GB of RAM and a single 1TB drive *no* RAID):

[shell]

administrator@mail:/backup-iscsi$ sudo dd if=/dev/zero of=garbage bs=131072 count=20000

20000+0 records in

20000+0 records out

2621440000 bytes (2.6 GB) copied, 40.8493 s, 64.2 MB/s

[/shell]

I’m pretty happy with that. What I’m not please with is a 56MB log (/var/log/secure) filled with strange messages:

[shell]Jul 26 12:25:46 e0-002 sudo: openfiler : TTY=unknown ; PWD=/opt/openfiler/var/www/htdocs ; USER=root ; COMMAND=/usr/bin/uptime

Jul 26 12:25:46 e0-002 sudo: PAM unable to dlopen(/lib64/security/pam_gnome_keyring.so)

Jul 26 12:25:46 e0-002 sudo: PAM [error: /lib64/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory]

Jul 26 12:25:46 e0-002 sudo: PAM adding faulty module: /lib64/security/pam_gnome_keyring.so[/shell]

Okay, so the first message isn’t strange. In fact, it’s normal. But I couldn’t figure out why a non-GUI (yes, it has a web interface, but no default window manager) distro was trying to load the Gnome keyring shared object. I still don’t know why. What I do know is how to get rid of this message:

1. Verify which PAM files reference this shared object:
2. [shell][root@e0-002 pam.d]# cd /etc/pam.d/

[root@e0-002 pam.d]# grep -i -n ‘pam\_gnome\_keyring.so’ *

system-auth:5:# FL: Have (patched) pam\_gnome\_keyring.so grab the password before pam_unix.so

system-auth:6:auth optional pam\_gnome\_keyring.so

system-auth:16:password optional pam\_gnome\_keyring.so[/shell]

2. In this instance, the ‘system-auth’ file contained these troublesome pam_gnome_keyring.so entries.
3. Fire-up your favorite text editor and comment those lines.
4. Reboot & enjoy a log without an absurd amount of irrelevant errors.