Problem: Protecting Cognos 10 App Server
The Cognos 10 application runs within an application server. As a result it is vulnerable to attacks over the Internet through the open ports for WWW traffic.
Here are some notes on CAF.
You can track firewall activity by checking the log file, which contains rejected requests only. If firewall validation fails, you can check the log file to find where the failure occurred. By default, log messages are stored in the c8_location/logs/cogserver.log file. In a gateway-only installation, the file is named caf.log. If you configure a destination for log messages, IBM Cognos Application Firewall log messages are sent to the specified destination.
IBM Cognos Application Firewall also has a Secure Error feature, which gives administrators control over which groups or users can view detailed error messages. For more information, see the IBM Cognos 8 Administration and Security Guide.
When the domino server caches an MX record, and that record changes, it may take time before the cache is refreshed. In some instances it is desirable to have the DNS cache refreshed on demand.
On the Domino console (IBM Domino Administrator -> Server… -> Status -> Server Console) run the following domino command:
tell router update config
If you need the cache to be refreshed more often, you can set this command to run on a schedule as well.
When trying to install Lotus Notes 8.5.1 on SLED (Suse Linux Enterprise Desktop), the following error occurs:
error: Failed dependencies:
libgnomeprint-2-2.so.0 is needed by ibm_lotus_notes-8.5.1-20090929.1223.i586
libgnomeprintui-2-2.so.0 is needed by ibm_lotus_notes-8.5.1-20090929.1223.i586
This is due to the fact that Notes is a 32bit application. The latest SLED DVD doesn’t contain some of the 32bit libraries.
Using RPMfind, or your preferred RPM finder, locate, download and install the 32bit version of the following libraries:
The explain tables allow to create access plans and visualize them. Before the explain feature of DB2 can be used, the EXPLAIN tables need to be generated.
To create the EXPLAIN tables, the following command needs to be issued while connected to the database that the access plain needs to be generated in:
When using SMTP TLS, the IBM Domino server shows the following error in the log file:
SSL Error: Keyring File access error
When engaging the STARTTLS command, the Domino server looks in the default location for the Keyring file with the default name:
keyfile.sth. The location is the data root specified for the Domino server.
Notes/Domino 6 and 7 Forum
When using a complex email infrastructure, multiple email servers are involved usually. The core servers typically take care of managing the data that users access in their day to day activities. Other servers can be used for SPAM/Virus filtering, archival, store and forward functions. It is important for all these servers to be able to synchronize the list of valid users. The IBM Domino Server is perfect for this. For each organization, email administrators can configure a virtual LDAP server that handles the needs for authentication and user list synchronization.
In order to authenticate the the LDAP server on IBM Domino, the following steps are needed:
- In the server configuration, under Web / Internet Sites, configure an LDAP server for your organisation
- In the LDAP client that you want to connect from, specify the admin user for the connection as follows:
CN=User Name of Administrator/O=Organization Name
- To retrieve the valid email users, you can use this query:
Attributes: mail, proxyAddresses
You have one or more NetApp storage systems (F960 or later series), running Data ONTAP® 7G (or later). You would like to take advantage of the snapshot capabilities, to facilitate the database backup process. However, you don’t want to use the default root login for the automated logins, nor do you want to use the unsecure rsh, as these options would violate corporate security policies (especially if you have a compliance commitment to ISO 27002, PCI or HIPAA).
Create a restricted users that has only login access and the ability to manage snapshots:
ssh on the filer:
secureadmin setup ssh (it is recommended that you select long keys when you are asked 1024 and 768 for ssh v1 – ssh1 shouldn’t be enabled anyway – 2048 for ssh2).
ssh on the filer:
secureadmin enable ssh2 (at this point you should be able to log in to the filer with ssh as root with your admin password)
- Create group / role / user:
useradmin user add snapuser -g Users
useradmin role add snaps -c "Snapshot Manager" -a cli-snap*,login-ssh,login-telnet
useradmin group add cli-snapshot-group -r snaps
useradmin user modify snapuser -f -g cli-snapshot-group
useradmin user list snapuser
The last command allows you to check your work, and the output should like:
Allowed Capabilities: cli-snap*,login-ssh,login-telnet
Password min/max age in days: 0/4294967295
- Put your public keys in the authorized keys file on the filer:
/etc/sshd/snapuser/.ssh/authorized_keys (typically you do that by mounting the filer root volume on one of your AIX boxes – any OS that can mount the root volume should work).
- At this point you are ready to test by logging in via ssh to the
snapuser account. Keep in mind that before you can successfully log in, you have to log out from the NetApp.
You have a directory that deserves it’s own file system for some reason. This could be because you need to increase throughput, manage backups separately, manage quotas separately or just to have a cleaner data architecture.
- Create a new filesystem using
- Mount the new filesystem temporarily to
- Stop all processes that access the directory to move
- Move all contents to the new filesystem using
mount /new/filesystem /path/to/directory
This principle is pretty much the same of any Unix operating system.
One of our IBM Domino servers all of a sudden decided that it couldn’t get an exclusive lock on its database files any longer. The databases happened to be on a NetApp head, and even after rebooting the server, the locking problem would persist. I other words, Domino’s nfslock was failing. As a result Domino wouldn’t start, and would send out errors to the domino startup log file similar to:
“Directory Assistance failed opening Primary Domino Directory names.nsf, error: This database is currently in use by another process”
Turns out that the NetApp lock table is sensitive to the server name and not the IP address. As a result, a lock from domino12.domain.com isn’t the same as a lock from domino12. To make matters worse, a Red Hat Linux machine might present itself either way depending on the config file details (even the order of the short name vs long name in the hosts file matters).
How to confirm the problem? On the NetApp, list the locks with
lock status -f
Now that you know the client name under witch the lock shows up, you can clear the lock with
priv set advanced
sm_mon -l clientname
Finally, you can check the the lock is gone with:
lock status -f
To maximize the benefit from the multi-port adapters on a NetApp, it is best to bond the ports together (some vendors refer to this as “trunk groups”). Then over the new bonded trunk, the various networks can be assigned as VLANs, maximizing the network throughput for each LAN the NetApp needs to communicate with.
In this example, I will show how to bond two interfaces together, and create three VLANs:
vif create multi vif0 e9a e9b
vlan create -g vif0 200
vlan add vif0 201 202
ifconfig vif0-200 10.10.0.25 netmask 255.255.0.0
ifconfig vif0-201 10.20.0.25 netmask 255.255.0.0
ifconfig vif0-202 10.30.0.25 netmask 255.255.0.0