Jump to content


brokers: filter runs on one, fails on another


  • Please log in to reply
3 replies to this topic

#1 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts

Posted 30 October 2018 - 05:24 PM

We have two, essentially identical[1] forwarding replicas that are remote from the master. Call them E and M.
On each of these hosts, we have a broker that handles various things, including enhanced commands (using filters).
Some of the enhanced commands are there to let non-super users run specific things that require super access. These work fine on server E but fail on server M with "Perforce password (P4PASSWD) invalid or unset."
I can run the filter line (as it appears in the broker config file) manually on host M, both as myself and as the p4 user (which the broker runs as). The p4 user is a UNIX-only user; we have no Helix user named p4. In both cases the filter runs fine from the command line with no password errors. This tells me the tickets file is good and that the super user is logged in. I can also run the straight Helix command the filter ends up running (p4 -u foo -p host command)- again as myself or p4- and it works.
What could cause this to fail when run from the broker on host M, but wrok on the command line on M, and work in all cases on E?

Thanks for any insights.

[1] The only configuration differences are things like serverid, ldap configs, tcpsize tweaks, etc.

#2 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts

Posted 30 October 2018 - 06:59 PM

Also, within the filter, I have tried setting the port to master:ourport, replica:ourport, and localhost:ourport .All of these work on M if I run them, from the command line (as myself or p4). All of them fail if I run them in the filter.

#3 p4rfong

p4rfong

    Advanced Member

  • Staff Moderators
  • 286 posts

Posted 02 November 2018 - 12:35 AM

In the filter script, run all commands with p4 -u <user>, and just before running these commands, run "p4 -u <user> login -s" to check whether you are logged in.  For example, run

p4 -u <username> login < /<dir>/input.txt
p4 -u <username> login -s

where /<dir>/input.txt contains the user's password.  This should show you if you have a valid ticket in the script.  You can use the P4TICKETS variable to specify where the tickets file is to be used.

#4 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts

Posted 05 November 2018 - 08:26 PM

The user was never logged in when the scripts ran, even though they were definitely logged in. It turns out that something is different about the Unix user's perl environment, such that P4TICKETS was not set when running perl as that user on that host. Adding the env var solves the problem.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users