IPLM CLI FAQs

`pi ip load` prompts for password, then fails

If a user is prompted for a password for sg during a pi ip load operation, they can resolve this by setting no_setaccess so that workspace unix permissions will not be set. See Configuring whether to set access in the workspace.

no_setaccess=True

Unicode issues

Perforce IPLM 2.0 uses Unicode characters in the CLI formatting to improve the look and feel but may require some setup for correct display.

Typical Unicode configuration

> export LANG=en_US-UTF8 in /etc/sysconfig/i18n on Redhat
> export LANGUAGE=en_US-UTF8 in /etc/sysconfig/i18n on Redhat

For xterms make /usr/bin/xterm -en utf-8 the default
- Set xterm*faceName: xtf:DejaVu Sans Mono:style=Book:size=10x20 in ~/.Xresources

Note 1. ~/.login and ~/.profile behavior can influence shell behavior and should be reviewed

Note 2. We use bash syntax by default in this discussion

Forcing non-Unicode encoding from IPLM CLI

If you're unable to resolve these unicode issues you may revert back to the basic ASCII terminal encoding by setting

Non-Unicode

export MDX_PI_ASCII=1

Pi command prematurely terminates with broken pipe indication

This applies to IPLM CLI versions before mdx-picli-lib-2.9.0.

With a large Neo4j database it has been seen that on occasion a pi command, like an ip load, release, or update, may prematurely terminate, usually ending with the text "Broken pipe". The broken pipe is the result of a connection (pipe) between Pi Client and PiServer that has remained idle for longer than twice the idleTimeout period given in PiServer's piserver.yml file in the relevant server:applicationConnectors:port section followed by two successive writes to the connection by the client. After the connection was initially made, the client makes a GET request that returns a large amount of data, which takes the client longer than twice PiServer's idleTimeout period to process, then the client attempts to update the database with a PUT or POST request which has to be broken into multiple payloads to be sent to the server, at which point the broken pipe results.

To prevent this, a large value can be given for the idleTimeout period in piserver.yml, for example:

server:

  applicationConnectors:

    - port: 8080

      idleTimeout: 1 hour

Confusing Ruby/Puppet errors

Unfortunately the Puppet configuration management tool chose its client name as "pi" and occasionally this appears on a users unix $PATH before the Perforce IPLM "pi" client. When this happens you could see problems like:

Ruby/Puppet Errors

/usr/lib64/ruby/vendor_ruby/1.8/puppet/defaults/: warning
Could not parse options: invalid option --verbose

To resolve this, define $PATH so that the Perforce IPLM client appears first.

Profiling Perforce IPLM commands

See IPLM Client Performance Profiling for information on profiling Perforce IPLM commands.

How do I find the Exact User or Group Name if there are leading or trailing spaces?

While setting up scripting of external user import functionality it is possible to accidentally import external users and groups that have leading or trailing spaces in the user or group name. This can cause confusion because the spaces aren't visible in many displays on the command line. In order to determine the exact name of a user or group you can list the user or group in json format:

json query

> pi user list --format json
{
    " confusing_user  ": {
        "description": "userid 34A66",
        "email": "confusing_user@example.com",
        "fullname": "Confusing User",
        "groups": [
            "admin"        ],
        "is_active": true,
        "name": " confusing_user  ",
        "uc": 2,
        "uuid": "66145d34-e7d8-487b-81ef-41d7561c0c1b"    }
}

The name of the user is surrounded by quotation marks, and the number of spaces can be determined.

What environment variables must be set to configure Perforce IPLM?

MDX_PI_SERVER

MDX_PI_SERVER identifies the Perforce IPLM server to run pi commands against. The current value of MDX_PI_SERVER can be found directly or via running 'pi settings'.

MDX_PI_SERVER

> export MDX_PI_SERVER=http://<my_servername>:8080

MDX_PICACHE_SERVER

MDX_PICACHE_SERVER identifies the IPLM Cache server to use.

MDX_PICACHE_SERVER

> export MDX_PICACHE_SERVER=<my PiCache server>:5000

MDX_CONFIG_DIR

MDX_CONFIG_DIR identifies the directory MDX tools should use to find config files.

MDX_CONFIG_DIR

> export MDX_CONFIG_DIR=/usr/share/mdx/config

MDX_PIWEB_SERVER

MDX_PIWEB_SERVER is used to define where VersIC should look for the IPLM Web server.

MDX_PIWEB_SERVER

> export MDX_PIWEB_SERVER=<my_piweb_server>:80

P4PORT

P4PORT identifies the Perforce server to run p4 commands against. The current perforce configuration can be found by running 'p4 info'

P4PORT

> export P4PORT=<my_servername>:1666

P4CONFIG

P4CONFIG identifies the name of the perforce configuration file to get the P4CLIENT info for each Perforce IPLM workspace.

P4CONFIG

> export P4CONFIG=.p4config

P4IGNORE

P4CONFIG identifies the name of the perforce configuration file to get the P4CLIENT info for each Perforce IPLM workspace.

P4IGNORE

 export P4CONFIG=$MDX_CONFIG_DIR/p4config

PATH

The PATH variable should be set to include the executables for Perforce ('p4'), Buildic ('bic'), and if the self extracting pi client is being used Perforce IPLM ('pi')

PATH

> export PATH=/usr/share/mdx/products/piextras/perforce/current/bin:$PATH
> export PATH=<path to self extracting pi client>/bin

Library Add fails when Vim is closed with "ZZ"

The Vim default behavior is to abort saving a file when you use the "Shift ZZ" short cut, this will cause the pi lib add command to abort since the template was not passed into pi from Vim

ZZ Error

> pi lib add new_lib
ERROR:Operation aborted

To resolve this users should use the :wq! Vim command to force a save of the unedited template

ZZ Resolution

> pi lib add new_lib
Successfully created Library 'new_lib'

Why is the Perforce IPLM Client Looking for a Server on 127.0.0.1:8080?

If the 'MDX_PI_SERVER' environment variable is not set and the Perforce IPLM client 'pi' is called from the command line, the client wrapper script will by default look for a Perforce IPLM server running on address '127.0.0.1:8080'.

If 'MDX_PI_SERVER' is set the Perforce IPLM client will use that value rather than looking at 127.0.0.1:8080.

This can be seen in the 'pi' client wrapper:

Pi Client Wrapper

> which pi
/usr/local/bin/pi
> cat /usr/local/bin/pi

Which contains the following check:

Server Check

if [ -z "${MDX_PI_SERVER}" ]; then
    export MDX_PI_SERVER=http://127.0.0.1:8080
fi

Pi Commands Say: CRITICAL:Unknown Workspace Manager

Problem: Any pi command I type returns 'CRITICAL:Unknown Workspace Manager:'

Solution: In this case Perforce IPLM is not able to determine its workspace manager. To fix this, set 'MDX_CONFIG_DIR' to the configuration location and set 'MDX_WORKSPACE_MANAGER' to the appropriate value (either BUILDIC or PWM).

Typical settings are:

Workspace Manager Command
                                                                    
> export MDX_CONFIG_DIR=/usr/share/mdx/config
> export MDX_WORKSPACE_MANAGER=PWM (or BUILDIC)
                                                                    

Once these variables are set Perforce IPLM should respond normally.

Getting Errors When Running Pi Commands from Remote Site

Problem: pi commands run from remote sites fail, but pi commands run from the same site as the server work

Solution: Time settings cannot be offset between the Perforce IPLM client and server. Setting the correct time at both the remote and server sites should resolve this issue.

How do I get debug information from the Perforce IPLM CLI?

Problem: I want to get more information on what is happening when a Perforce IPLM command is run

Solution: Using the "-d" or "–debug" flag will produce additional output from Perforce IPLM commands.

-debug Flag

> pi -d version
DEBUG:MainThread:0.716:/usr/share/mdx/products/piclient/local/lib/python2.7/site-packages/methodics/picli/pi.pyc -d version
DEBUG:MainThread:0.717:Using configuration file: /usr/share/mdx/config/piclient.conf
DEBUG:MainThread:0.964:Read token 209819ff for server http://tau-deploy-test-c6:8080
DEBUG:MainThread:0.964:Read token 91b24e67 for server http://127.0.0.1:8080
DEBUG:MainThread:1.350:SYSINFO: Neo4j version: 3.5.3
DEBUG:MainThread:1.351:SYSINFO: PiServer version: 2.31.1
DEBUG:MainThread:1.351:SYSINFO: PiClient version: 2.31.1
DEBUG:MainThread:1.351:SYSINFO: OS version: Linux tau-deploy-test-c6 2.6.32-696.6.3.el6.x86_64 #1 SMP Wed Jul 12 14:17:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
DEBUG:MainThread:1.352:SYSINFO: Perforce version: P4D/LINUX26X86_64/2018.2/1740258 (2018/12/11)
DEBUG:MainThread:1.366:Use cache for GET http://tau-deploy-test-c6:8080/cli/v1/system/info
PiServer version : 2.31.1
PiClient version : 2.31.1

The output of the pi command including the --debug flag is also copied to ~/picli.log. Subsequent pi commands run without the --debug flag will remove the ~/picli.log file. Perforce IPLM performance is negatively affected by running pi commands with the --debug option, so it should be avoided in normal usage.

I manually edited my P4 Client - How do I fix It?

Problem: I manually edited my p4 client definition and now it is out of sync with Perforce IPLM, how do I reset it?

Solution: It is generally not a good idea to manually edit the p4 client definition, this should be left to Perforce IPLM to update. In cases where the p4 client spec has been edited it can be reset to the state Perforce IPLM expects via the 'pi ws refresh --reset' command.