This section describes NSS debugger logging features so you can identify when these logs are turned on and turn them off in your operational environment.
On OES, most of the NSS code runs in kernel space, but some portions are required to run in user space. To communicate across the boundary between user and kernel space, some internal mechanisms were implemented. For debugging purposes, some logging features were added to track these communications between user and kernel space. These logging features are slow and cumbersome, and are intended for use by Novell support engineers to help diagnose any problems that arise. They are not intended for everyday use, and seriously impact performance when they are turned on.
There are two main areas where logging is built into the system. The first is the capacity to log all XML communication to/from the _ADMIN volume. The second is the capacity to log NSS kernel requests to communicate with eDirectory, NICI, and LUM, all of which run in user space.
When working with encrypted volumes it is important to realize that the volume password and key information is exchanged between user and kernel space as encrypted volumes are created and/or mounted. If you have logging enabled on the Linux server when you enter the encryption password, your password and volume key information might show up in the log file.
You must be the root user or an equivalent user with root user privileges to perform the steps required to enable logging, disable logging, or read /var/log/messages. This prevents ordinary users from manipulating the logging environment. We strongly recommend that you protect the physical access to the server and the root user passwords to prevent unauthorized access to your servers.
Even though the logging mechanisms are root user protected, we strongly recommend that you make sure logging is disabled whenever you plan to enter the encryption password for an encrypted NSS volume on your system. You enter an encryption password when you create the volume and when you mount the volume for the first time after any system start or reboot.
Applications such as NSSMU and Perl scripts communicate with NSS via the _admin volume. In these communications, the volume’s encryption password is passed in the clear. There are two utilities that can log these exchanges, the adminusd daemon and the nss /vfs commands in NSSCON. Logs are written to /var/log/messages.
You must be the root user or an equivalent user with root user privileges to perform the steps required to enable logging, disable logging, or read /var/log/messages. This prevents ordinary users from manipulating the logging environment.
On your OES server, an NSS daemon called adminusd is installed into /opt/novell/nss/sbin directory. It is run from the startnss.bsh script. Output data is written to the /var/log/messages directory.
At a Linux terminal console, do the following to enable adminusd logging:
Log in as the root user.
Kill the adminusd daemon.
Run the daemon with logging turned on by entering
adminusd -l
Using the -l option enables logging of all communication to and from the _ADMIN volume in the /var/log/messages.
At a Linux terminal console, do the following to disable adminusd logging:
Log in as the root user.
Kill the adminusd daemon.
Run the daemon with logging turned off by entering
adminusd
Not using the -l option turns logging off.
Delete and purge the adminusd log files in /var/log/messages.
In the NSS Console (NSSCON), the VFS option for NSS can log communications between NSS and the _ADMIN volume. The logged data is displayed on the NSSCON screen and is also written to the /var/log/messages.
At a Linux terminal console, do the following to enable VFS logging:
Log in as the root user, then enter
nsscon
In NSSCON, enter
nss /vfs
Logging is turned on.
At a Linux terminal console, do the following to disable VFS logging:
Log in as the root user, then enter
nsscon
In NSSCON, enter
nss /novfs
Logging is turned off.
Exit NSSCON.
If the terminal console logging feature was on, turn it off, then delete and purge the logged session.
Delete and purge the VFS log files in /var/log/messages.
All internal NSS kernel space requests for NetIQ eDirectory, NICI, and Linux User Management are routed through an interface called the NDP (Novell Data Portal). NDP has a user space daemon (ndpapp) and a kernel module (ndpmod). In communications between ndpapp and ndpmod, the volume’s encryption password is obscured, but it can be easily broken. Both ndpapp and ndpmod have a logging capacity, and both of them write their log data to /var/log/messages.
You must be the root user or an equivalent user with root user privileges to perform the steps required to enable logging, disable logging, or read /var/log/messages. This prevents ordinary users from manipulating the logging environment.
On your OES server, an NSS daemon called ndpapp is installed into /opt/novell/nss/sbin. It is run from the startnss.bsh script.
At a Linux terminal console, do the following to enable ndpapp logging:
Log in as the root user.
Kill the ndpapp daemon.
Run the daemon with logging turned on by entering
ndpapp --debug=nn
Replace nn with the log level desired. Set the log level to 1 and above to turn logging on. The higher the number, the greater and more detailed is the logged output.
At a Linux terminal console, do the following to disable ndpapp logging:
Log in as the root user.
Kill the ndpapp daemon.
Run the daemon with logging turned off by entering
ndpapp
Running ndpapp without the --debug option turns logging off.
Delete and purge the log files in /var/log/messages.
At a Linux terminal console, do the following to enable ndpmod logging:
Log in as the root user, then enter
echo nn >/proc/driver/ndp/debug
Replace nn with the log level desired. Set the log level to 1 and above to turn logging on. The higher the number, the greater and more detailed is the logged output.
At a Linux terminal console, do the following to disable ndpmod logging:
Log in as the root user, then enter
echo 0 >/proc/driver/ndp/debug
Setting the Log Level field to 0 turns logging off.
Delete and purge the log files in /var/log/messages.