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
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: email@example.com
Valid starting Expires Service principal
- Centrify is in connected mode but users are unable to login.
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
- LSF cluster must be restarted if user authentication is switched from NIS to LDAP
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
- Packing means always placing jobs on the hosts with the least available slots first. Packing jobs can make room for bigger parallel jobs.
- 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.
QUEUE_NAME = myqueue
RES_REQ = order[-slots]
Step 2: Make the configuration take effects
# badmin reconfig
Step 3: Check whether the configuration take effects.
# bqueues -l myqueue
You can also do it at the application level. For more information, please read the PLatfrom LSF Wiki
- Placing jobs based on available job slots of hosts
On your MS Desktop which is joined to the domain , type the following command in your MS-Command Ptompt
dsquery computer domainroot -name your-computer-name