See License Management.

If you are installing ACP, either for the first time or as an upgrade, you can enable the use of wildcards. See Enable wildcard support.

Back to Contents - Back to beginning of section

If you select to install Auditing you won’t see the login screen until you complete additional Auditing setup questions.

You need to set at least one log location per product, otherwise Flume will not monitor any logs at all.

GitMS uses:

SVN MSP uses:

For both products you will need to set the following environment variables:

If FLUME_AVRO_SSL=true you also need to set:

One of the final steps you must implement is to call the following REST API after EULA acceptance, and with all ACP nodes operational:

Note: This call outputs a task id, and you need to follow it to make sure that it finishes. To do that, you make the following call, until the status returns isDone=true:

When the task is complete, after approximately 30 seconds to a minute, you must do the following check at all ACP nodes:

If the call returns null on all of your nodes then you must:

During the installation you must set the ENABLE_AUDITING variable. If you set this variable to TRUE then you also need to set the variables listed in Install Auditing Function.

Flume location can be set on install. It defaults to: /opt/wandisco/flume-<product-name> so is
/opt/wandisco/flume-svn-multisite-plus or
/opt/wandisco/flume-git-multisite or
/opt/wandisco/flume-scm-access-control-plus:

If using Cirata-supplied SystemD unit files, then run:

If using "init.d" scripting, then run the following command:

When upgrading from ACP 1.5.1.1, the environmental variable FLUME_MAX_MEMORY is not currently set correctly. You need to set the value in /opt/wandisco/scm-access-control-plus/config/main.conf.

Default value: 256m, (MiB RAM) Recommended value: 256m

Memory sizes in the 'main.conf' file are in MiB but must be integers. Do not append the 'm'.

You will need to set a value that is higher than the default if you find that Apache, svnserve, etc. logfile entry rate is high. We recommend that you find what value works for your deployment; If set too low the Flume log file will show an error and the Flume agent will have exited.

Back to Contents - Back to beginning of section

On all nodes:

On all nodes:

Back to Contents - Back to beginning of section

The following diagrams show the flow used in the two phases of authentication when using ACP with SVN MSP:

Back to Contents - Back to beginning of section

If you are running a version of ACP that didn’t include Flume, it’s possible to install Flume during an upgrade of ACP. The procedure differs a little from that used when installing both ACP and Flume from scratch. For that, see Install Auditing Function.

Back to Contents - Back to beginning of section

Should you get locked out of an admin account for ACP you can run the protocol here. This will enable you to create a new admin account.

Back to Contents - Back to beginning of section

There are two ways to install flume:

Use ACP’s installer to handle the upgrade, the installer will detect that you are performing an upgrade and that Flume is not yet installed. The installer will ask:

Just answer the brief series of question to install Flume.

For the non-interactive upgrade, to install Flume for a first time for ACP you will need to set the following variables:

To start ACP:

ACP starts. Read more about the svn-multisite init.d script.

To shut down:

Cirata uses a talkback agent to capture log information to help investigate problems. When you report a problem to Support, run talkback and attach the output file.

The start-up script for persistent running of ACP is in the /etc/init.d folder. Run the script with the help command to list the available commands:

Check the running status (with current process ID):

Check the version

If an administrator loses their password and no other administrative account is available to reset it, then you can recover access to ACP by running the "reset security" process below. The result of this process will be a new local administrative account with a known password.

Use the ACP Search tool to find Accounts, Teams, Rules and Resource permissions.

Search for refinements where the repository is git-repo1 and the refinements are the type "TAG".

Back to Contents - Back to beginning of section

There are three methods for four routes to create an account. This procedure describes steps to follow after clicking Create User on the Accounts pane that appears on the master screen. You can also create an account from within the Create Team procedure. Usually you will add accounts by setting up a query to an available LDAP authority. To add accounts using LDAP, see Connect to LDAP.

Use the + LDAP Add to add an LDAP group by searching the available LDAP authorities. The search is currently limited to account names, so it’s not possible to search using name fields (surname, firstname etc).

To edit an existing account:

Public SSH keys can be managed from:

Keys coming from LDAP are not modifiable through the ACP admin console, you will need to make changed through the LDAP authority.

An administrator can add/change/remove any SSH keys associated with an account except those coming from LDAP. An account owner (user) can add/change/remove any of their own account’s SSH keys except those coming from LDAP.

Following the above stated rules, use this procedure to add any number of public SSH keys to an ACP account.

Follow this procedure for removing public SSH keys from an account.

Audit accounts are accounts that can see everything but do nothing. They are used by auditors to validate ACP configuration etc. They can also be used by scripts that only read ACP data.

When you install the auditing function, you are asked for the name of the Account Access Logging service account. The logging service account is created during installation and is from now on referred to as logger. The logger account is used to log account access information from monitors on the log files which contain information about accounts accessing the SCM system. Logging this information is the only thing that the logger account can do, and it is only logging service accounts which can use the logging REST API. It is not possible to log in to the UI using the logger account. You will see the message:

Best practice is to:

Two jar files are delivered which enable the maintenance of the logging service account. They cannot be used through the UI:

Use the dashboard Reports tab to query the audit database from the UI:

You can choose from the following types of report:

Note: You may see a message warning that the report could take a long time, i.e. a few seconds:

Confirm that you want to continue.

For example, there may be a Priority Conflicts report:

To report on the last access time by an account, as an administrator, from the dashboard Accounts section select an admin, then click View/Edit dropdown for Access Details:

Click View Account Report to show the last access time for a single account:

Any conflict report is shown in the Reports menu. If there are any current conflicts in the system then a report of those conflicts can be found in the reports dropdown. The triangle-with-exclamation-point icon signifies that there are existing conflicts.

To remove an account from ACP:

The account is completely removed from ACP. It no longer appears on the accounts list, or in any teams or rules. If the account is an LDAP account and that account is a member of an LDAP group that is used to define an ACP Team via an LDAP query then that account will be re-created and re-instantiated into the team upon next LDAP poll.

If you need to check the account’s particulars to ensure that you are removing the correct account, go to the accounts details screen, you’ll find a Delete button at the bottom. This does the same thing as the remove link on the main management screen.

Disabled accounts remain stored in ACP. They are, however, unable to log in or interact with any repository resources. You can quickly add back a disabled account by re-enabling it.

Back to Contents - Back to beginning of section

Use this procedure to set up a new ACP team. This is the same method as for adding accounts manually. You can also manage your team structure through LDAP, setting up a query that filters for the specific account holders that you need for a particular team. For more information see Adding an LDAP-based team.

Resources are repositories that have been associated with repository Templates (or refinements thereof).

Follow this procedure to create a team that is populated from an LDAP authority.

A disabled LDAP-managed account will NOT be re-enabled if manually associated with a new team. In this scenario an administrator must re-enable the account by hand.

When LDAP-based accounts have been added to ACP, they appear within the Accounts pane and can be added to any team. However, it’s easier to track and manage LDAP users if they’re enabled through their own team, where the team is set up to get its members from an authority. However, so long as you tick the checkbox Allow local users, you can also add local users to an LDAP-managed team.

From ACP 1.9 it’s possible to remove LDAP-based team members from a team. Previously, you were required to delete then recreate the team.

On the Team edit screen you can add team leaders for the team:

Use the following procedure to remove a team from ACP.

Back to Contents - Back to beginning of section

For SVN deployments, you can create "local" (non-replicated) resources. This is not possible for Git deployments because GitMS is the AuthZ enforcement mechanism for Git.

Use this procedure to create team resources, when not syncing with Cirata MultiSite products. If you are connecting to MultiSite then resources are created from whatever repositories that are automatically added. See Create a resource in a MultiSite Environment.

Use this procedure to create additional resources, if syncing with Cirata MultiSite products. If you are connecting to MultiSite then resources are selected from whatever repositories that are automatically added.

You can easily edit resources by clicking on the resource’s name.

ACP supports repository resources in various configurations:

You can tell the type of a particular resource by checking the text under its title. It says either "Replicated" or "Non-replicated".

You can refine a resource to specify a Subversion sub-repository path or a Git Branch or Git Tag:

You can now add this resource to a rule for the team. See the Rules section.

You can remove a resource from the main screen. Tick the checkbox for the resource you want to remove and click Remove.

The Rule lookup provides administrators with a means of testing what access and permissions apply to a specific account. Given that accounts can belong to multiple teams and have multiple rules applied, the Rule lookup tool can useful.

Click the Lookup button to start the search. All rules that apply to the account for the specified resources are displayed in the Permissions table.

In the example, conflicts are being handled correctly now with most permissive rule on a path being displayed correctly on rule look up.

To create a new rule:

When troubleshooting user access problems (in deployments that manage htpasswd/sshd files) you may notice that an active account for which only DENY rules currently apply will generate an authentication rather than authorization error on any Git/SVN access attempt. It’s as if the account didn’t exist or the wrong password was given, instead of not having the appropriate access permissions. This apparent quirk is by design. If an account doesn’t have access to any resources at all, we don’t bother writing it to the password or sshd rules file. In fact, if the account doesn’t have any associated rules then "Deny" rules are applied by default and the account will not be written to the AuthZ file either.

You should note that this does not occur if authentication is delegated to LDAP/AD or any method which does not use passwd/sshd files.

Back to Contents - Back to beginning of section

If you are deploying multiple ACP nodes, follow these steps so that the nodes communicate with each other correctly

Node repair is not used to handle the loss of one or more nodes when replication is setup. It is used to re-align the ACP accounts, teams, resources and rules should divergence occur. It essentially copies all of this data from the helper node to the target node.

Removing inducted nodes is done via the Node Induction page on the Settings area.

Back to Contents - Back to beginning of section

SSL is enabled for both UI and the underlying Rest API (the administrator’s access to HTTP port will automatically redirect to HTTPS) AND for internal communication between nodes on 'application.port' and 'content.delivery port'. For this reason the switchover needs to be done on all nodes at once, otherwise those nodes that delayed their switch will no longer be able to talk to those nodes running with SSL.

Java’s default SSL implementation is intentionally weak so as to avoid the import regulations associated with stronger forms of encryption. However, stronger algorithms are available to install, placing the legal responsibility for compliance with local regulation on the user.

See Oracle’s page on the Import limits of Cryptographic Algorithms.

If you need stronger algorithms, i.e. AES which supports 256-bit keys, then you can download JCE Unlimited Strength Jurisdiction Policy Files that can be installed with your JDK/JRE.

See Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7

Keystores and truststores in a nutshell
You might be familiar with the public key system that allows two parties to use encryption to keep their communication with each other private (incomprehensible to an intercepting third-party).

The keystore is used to store the server certificates and the keys that enable access to them that are used in this system. However, in isolation, the system remains susceptible to the untrustworthy server certificates, where a server certificate and the client can then be unaware that it will communication with an impostor. Certificate Authorities, CAs, are trusted third parties that issue digital certificates that verify that a given server certificate is trustworthy. The information about which server certificates to trust is stored in the truststore. The truststore is like a keystore file, but used for certificates instead of keys. An SSL implementation requires the use of both truststore and keystore files.

Changes in any of these values require a restart of ACP. Any invalid value is likely to result in ACP not running properly.

In the keystore, the server certificate is associated with a key. By default, we look for a key named server to validate the certificate. If you use a key for the server with a different name, enter this in the SSL settings.

Next, if using self-signed certificates, you need to export the certificate so that it can be added to the truststore as the trusted certificate. Again, using Java’s Keytool. Note that some administrators may want to simply combine all of their server certificates into a single keystore and then use that keystore as the truststore. The only thing they’ll need to do is

After exporting the certificate use creates a keystore file named myTrustStore in the current working directory and imports the first certificate into the truststore with an alias of <Cert-Name-Alias>. The format of myTrustStore is JKS. Each additional run of the command adds additional certificates to the TrustStore. When completed, myTrustStore is available to be used as the truststore.

If auditing is installed: . Update the setting acp_agent.sinks.acpSink.acp_ssl_enabled in the <flume install dir>/receiver/conf/flume_acp_receiver.properties file to:

A complete debug of the SSL logging will be required to diagnose the problems. To capture the debugging, run the java process with:

To enable the logging of SSL implemented layer, turn the logging to FINEST for the com.wandisco.platform.net package.

The following table shows you how the Group DN is used, when evaluating the Team LDAP query field.

The result of this set of behaviors is a very high degree of flexibility which is required to support the vast range of possible LDAP schemas.

The settings tell ACP how to use any available LDAP authorities that you connect up.

This is the entry form for adding any number of LDAP Authorities. Multiple Authorities are checked in the order that matches their order number (see below). The lower the order number, the earlier the authority is checked.

The following events currently trigger notifications when suitably configured:

Back to Contents - Back to beginning of section

The Repository Template section covers the configuration of a number of different template types that are used to integrate SVN or Git repositories into ACP.

List of template types

'svnserve.conf' controls the behavior of the SVNServe daemon on a per-repository basis. It is located in the conf subdirectory of the repository, e.g. '/opt/svn/repo/conf/svnserve.conf'.

The following configuration is required on the server:

The following configuration is required for clients:

The following log files are generated during operation:

The logger file will look like this:

ACP uses a logging system called log4j. We use it rather than java.util.logging because it has a better range of functionality

We still need to provide a log file that contains the log output of DConE and the ALM product. We do this by bridging between java.util.logging and log4j. All the log output of java.util.logging is directed to log4j which writes out the log messages for DConE and the ALM application to a single log file. We use slf4j to do this: http://www.slf4j.org/.

We also have log rotation, were we rotate to a new log file after it has grown over a size defined in the logrj.properties file.

Our log4j.properties file looks like this :

Although you can edit this file, we do not recommend it. If you get it wrong then it will affect the format of the logs we get through our Talkback system.

If you do need to make changes, the following parameters can be changed :

Back to Contents - Back to beginning of section

The Repository Template options are used when connecting new SCM repositories to ACP. A repository template stores the paths for the repositories authentication and authorization files that are used by the Generic File Replication scripts to ensure that changes on each node are synced to all other nodes.

See Create a repository template.

ACP needs to handle situations where the customer’s Active Directory/Windows-based systems are maintaining user accounts that are case-insensitive, i.e. account "jsmith" and "JSmith" are considered the same account. ACP treats account names as case sensitive by default. In summary, the manner in which ACP handles "case insensitivity" is via "downcasing" all account names before comparison (and storage).

Enable Global Downcasing to ensure that Subversion users have their usernames forced into lowercase. This ensures consistency and protects against the possibility of AuthZ rules being applied incorrectly.

By default Global Downcasing is disabled and accounts are all considered case sensitive. Enabling Global Downcasing triggers a warning message:

If Global downcasing is enabled, it can be disabled from the same section in Settings.

The Edit Local Node Settings panel lets you modify the node properties at any time after the node has been setup and inducted.

This section describes how the ACP nodes work when connected together.

The Node Repairs tool allows you to get ACP data around Repositories, Resources, RepoTemplates, Teams, Rules, Accounts, etc. back into sync.

When ACP is run in Standalone mode, this section includes a File Generation settings screen.

Settings for connecting ACP to an LDAP service for managing users and access.

Email notification settings. See Email Notification

Settings for the connected SVN MSP node or GitMS node.

Use the external applications settings to connect with MultiSite products (GitMS and / or SVN MSP).

Lists all available SCM repositories.

Back to Contents - Back to beginning of section

To create a resource using wildcards follow the steps below.

With Subversion, resources are sub-repository paths and permissions can be used to restrict read or write access, including preventing visibility completely.

To create a resource using wildcards follow the steps below.

There are 2 different wildcards, used for both Git and Subversion:

See Creating Git Wildcard Resources and Creating Subversion Wildcard Resources above for how to create and refine resources.

Once you include wildcards in the refinement space, it is possible for multiple refinements to match the same component. How do you decide which refinement will win? The answer is a combination of precedence, the sort order of the rule, and the priority of the rule. See Working with Rules and Setting priorities for more information.

Back to Contents - Back to beginning of section

You can set a priority from -9 to +9 (0 is default) for every resource within every rule.

When adding a resource to a rule you may get a priority conflict between this new rule and an existing one.

The priority chosen for the rules in conflict will depend on the global setting for conflict resolution, by default set to "Highest Wins". The conflict is then included in the count shown on the page header.

Critical conflict interactions occur where there is:

Then direct access works if the path is known:

If a conflict is detected while creating or editing a rule then you see a message:

Click Continue or Cancel.

To resolve conflicts you need to compare priorities. Either:

Then:

Wildcard conflicts are counted in the page header by Priority Conflicts.

Click Priority Conflicts to display:

Alternatively you can run an API call conflict/conflictsreport which then lists:

The report of priority conflicts will depend on the privileges of the account running the report. Administrative accounts can see them all. Team leaders can only see rules that they have rights to see (not rules in other teams where they have no rights). Ultimately it might take an administrator to resolve a conflict dispute.

The pre-placement scripts for the authorized_keys and password files must be located within the appropriate gfr directory for the type of SCM being delivered to. There are 3 options:

The delivery behavior depends on the pre-placement script’s exit value:

This pre-placement script lets you overcome the limitation of having a single authorized_keys generator. The key principle is that each generator is represented by a UUID that does not change from delivery to delivery:

Back to Contents - Back to beginning of section

The configuration file is not required. If it exists it will be read. The configuration file must be located here:

Comments starting with a hash character ('#') are ignored within the file. Blank lines are ignored. Currently the only configurable value is "GFRTIMEOUT". An example entry would be:

The default value for GFRTIMEOUT is 20 seconds.

If your implementation has a very large number of AuthN or AuthZ files that need to be delivered then it may timeout. If this happens you will see errors to the effect of "message='acpLockAndRun: Error: Received signal ALRM, sending SIGINT to PGRP 32707 and exiting" in your GitMS and/or MSP log files. To work around this increase the timeout.

Back to Contents - Back to beginning of section

Use the following LDAP filter to remove disabled and locked accounts from user account polling.

Back to Contents - Back to beginning of section

When performing API calls that filter on UserType, you need to use the following enumeration to match the appropriate searchValueList integer value.

Back to Contents - Back to beginning of section