ACP-100 - Jira Server Administration



Exam Topic:
  • Recognize the benefits of having production and non-production instances.  Given a scenario, recommend whether or not to upgrade and determine the effects of roll-back.  
  • Evaluate the need for re-indexing following a set of modifications, and explain the effects of re-indexing.  Troubleshoot application-level problems with Jira (logging and profiling) and escalate when appropriate.   
  • Identify and troubleshoot the appropriate configuration of an outgoing email server.  
  • Given a workflow, describe which attributes will and will not be imported/exported.  
  • Given a scenario, assess the impact of user directory order and configuration. 
Expected Questions%: (10-15% of exam)

Important Notes:
  • Exam questions will be on Production and non production environment, for example why need non production environment
  • If you performed a rollback, you will lost newly created issues and new implemented schemes.
  • While performing rollbacks, following will be replaced
    • Database
    • Home directory
    • Installation directory
  • Type of Jira logging
  • HTTP Access Logging
    • Turn this on to have JIRA log all HTTP requests to an access log. This information will be sent to 'atlassian-jira-http-access.log'.
  • SQL Logging
    • Turn this on to have Jira log all SQL requests. This information will be sent to the console and 'atlassian-jira-sql.log'.
  • Profiling
    • Turn this on to get profiling information from Jira. This information will be sent to the console and 'atlassian-jira.log'.
  • Mail
    • Outgoing Mail information is sent to 'atlassian-jira-outgoing-mail.log'.
    • Incoming Mail information is sent to 'atlassian-jira-incoming-mail.log'.
  • Default Loggers
    • Note that any changes you make here are not persisted across server restarts.
    • You will need to edit 'WEB-INF/classes/log4j.properties' to change levels permanently.
    • Logging will go to the console.
  • Jira re-indexing
    • Project Index
    • Jira full index
      • Background re-indexing
      • Full index by lock jira
    • When required re-indexing for operations otherwise JQL will not work correctly.
      • Added new custom field
      • Update custom field search type
      • Update field context

Background re-index

Full re-index

Single-threaded, slower to complete.

Multi-threaded, faster to complete.

Can be canceled at any time.

Can't be canceled once started.

Keeps current index and updates it in-place.

Rebuilds the index, optimizes it, and deletes the old one.

Causes disk fragmentation.

Eliminates disk fragmentation.


  • While importing or exporting workflows following will not be imported/exported
    • Custom fields
    • custom conditions/validators/postfunction
User Directories

Login

The directory order is significant during the authentication of the user, in cases where the same user exists in multiple directories. When a user attempts to log in, the application will search the directories in the order specified, and will use the credentials (password) of the first occurrence of the user to validate the login attempt.

Permissions

The directory order is significant when granting the user permissions based on group membership. If the same username exists in more than one directory, the application will look for group membership only in the first directory where the username appears, based on the directory order.

Example:

  • You have connected two directories: The Customers directory and the Partners directory.

  • The Customers directory is first in the directory order.

  • A username jsmith exists in both the Customers directory and the Partners directory.

  • The user jsmith is a member of group G1 in the Customers directory and group G2 in the Partners directory.

  • The user jsmith will have permissions based on membership of G1 only, not G2.

Updating Users and groups

If you update a user or group via the application's administration screens, the update will be made in the first directory where the application has write permissions.

Example 1:

  • You have connected two directories: The Customers directory and the Partners directory.

  • The application has permission to update both directories.

  • The Customers directory is first in the directory order.

  • A username jsmith exists in both the Customers directory and the Partners directory.

  • You update the email address of user jsmith via the application's administration screens.

  • The email address will be updated in the Customers directory only, not the Partners directory.

Example 2:

  • You have connected two directories: A read/write LDAP directory and the internal directory.

  • The LDAP directory is first in the directory order.

  • Since you can create users in both directories, you can choose the directory in which you want to perform the update. 

https://confluence.atlassian.com/adminjiraserver/managing-multiple-directories-938847057.htm







Please feel free to provide your feedback in comments section. I would be happy to answer all of your queries


About Author
Muhammad Ramzan  is a certified Atlassian Consultant having 10+ years of professional experience in the area of DevOps, Software Testing(Manual/Automation) and Atlassian Tools Administration

2 Comments

  1. Nice Information friend. A doubt with User Directory.

    I have a Cloud Instance.

    First, I created internal users and 1 month later, We carry out the integration of Active Directory verifying the domain of the company.

    What happens with users that already existed before integration and are also in the Active Directory? are we going to have 2 equal users? Or what happens with all issues where this users are reporter, asignee etc.

    ReplyDelete
  2. I would suggest to read this, it will give you very clear picture

    https://confluence.atlassian.com/adminjiraserver/managing-multiple-directories-938847057.html

    Please let me know if still any confusion

    ReplyDelete