Testing the AD User Authentication with Centrify

Test 1: Test with SSH

The simplest way is to enable SSH and connect to it.

Test 2: Test with adinfo

# adinfo -A --user user1
Active Directory password:
Password for user "user1" is correct

Test 3: Test using kinit

# /usr/share/centrifydc/kerberos/bin/kinit user1
# /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user2@test.com
.....
.....
Valid starting       Expires           Service principal
.....
.....

References:

  1. Centrify is in connected mode but users are unable to login.

Resolving Unable to determine user account for execution

If you are facing this issue “Unable to determine user account for execution;”, it is likely casued by the fact that LSF cluster must be restarted if user authentication is switched from NIS to LDAP.

After user authentication method is switched from NIS to LDAP, all user jobs are pending with the pending reason: “Unable to determine user account for execution”.

If user authentication mode is changed, you have to restart LSF daemons on all LSF hosts for jobs to run successfully. On the LSF master master host do:

# lsadmin reconfig
# badmin mbdrestart
# badmin hrestart all

References:

  1. LSF cluster must be restarted if user authentication is switched from NIS to LDAP

Packing serial jobs neatly in Platform LSF

Taken from Placing jobs based on available job slots of hosts

Platform LSF allowed you to pack or spread jobs as required. Before that, just a few terms to defined

  1. Packing means always placing jobs on the hosts with the least available slots first. Packing jobs can make room for bigger parallel jobs.
  2. Spreading tries to spread jobs out and places jobs on the hosts with the most available slots first. Spreading jobs maximizes the performance of individual jobs.

I will deal with one situation where I want to pack all the serial jobs neatly in as few nodes as possible.

But here are some terms from the LSF Wiki

The slots keyword represents available slots on each host and it is a built-in numeric decreasing resource. When a job occupies some of the job slots on the host, the slots resource value is decreased accordingly. For example, if MXJ of an LSF host is defined as 8, the slots value will be 8 when the host is empty. When 6 LSF job slots have been occupied, slots becomes 2. The slots resource can only be used in select[] and order[] sections of a job resource requirement string. To apply a job packing or spreading policy, you can use the order[] section in the job resource requirement. For example, -R “order[-slots]” will order candidate hosts based on the least available slots, while –R “order[slots]” will order candidate hosts based on the hosts with the most available slots.

To use ! in an order[] clause, you must set SCHED_PER_JOB_SORT=Y in lsb.params. To make the parameter take effect, run badmin mbdrestart or badmin reconfig on the master host to reconfigure mbatchd.

The following is an example of using the slots resource:
Step 1: Configure RES_REQ in a Queue section of lsb.queues.

Begin Queue
QUEUE_NAME = myqueue
…
RES_REQ = order[-slots]
…

End Queue

Step 2: Make the configuration take effects

# badmin reconfig

Step 3: Check whether the configuration take effects.

# bqueues -l myqueue
QUEUE: myqueue
…
RES_REQ: order[-slots]

You can also do it at the application level. For more information, please read the PLatfrom LSF Wiki

References:

  1. Placing jobs based on available job slots of hosts