Failed authentication check

[pfist]

When I run this script manually, it works perfectly and the message shows up in my Discord server. When I submit a changelist to our depot, it runs but nothing happens. When I look at the debug output file, output, desc, and user are all blank. I checked my Perforce server log and it appears to run user-describe twice. The first one completes, but the second one is followed by failed authentication check.

Can you offer any guidance on why this might be happening?

[saadbruno]

I think I had this issue when initially setting it up.

If output, desc and user are all blank, it seems like the linux user that is running the script is not logged in to your p4 repo.

here's a few questions that can help us have a better idea of what's going on:

• When you ran the script manually, were you using the same linux user as your p4 server? (usually it's the perforce user. It's also listed in the :: Linux user line in the debug output file.
• In the debug output file, what does the :: p4 info line says? Did it login successfully? It should give you some information about the server if it was logged in successfully.
• What is the user that shows up when you run ps aux | grep p4d on the server?

it seems to me that the user running the script from the p4-trigger (which is the same user running the p4 server) is lot logged in, therefore it cannot read the changelists.

[pfist]

Thanks for getting back to me.

When you ran the script manually, were you using the same linux user as your p4 server?

Yes. It's the perforce Linux user.

In the debug output file, what does the :: p4 info line says? Did it login successfully?

This section shows detailed info about the client and server. Everything appears to be normal except for one thing: line 4 says Client unknown. This may be related.

What is the user that shows up when you run ps aux | grep p4d on the server?

Both lines show the perforce user.

I noticed that it says "Perforce password (P4PASSWD) invalid or unset." near the top of output.log, just before ":: Sending webhook...". I'm not sure why this happens. I followed your advice in the README about adding my superuser to a group with Login Timeout set to unset, and I've ensured the perforce Linux user is logged into that superuser with p4 login.

I'm not sure what to try next.

[saadbruno]

Thanks for the reply!

Alright, let's try to dig deeper into this.

line 4 says Client unknown. This may be related.
I double checked on mine, it also says client unknown. I'm not sure what that means exactly, but It works fine here, even with that message, so I don't think it's related

Now, one last place i would check for a different configuration would be in the p4dctl file for your server. It needs the same user in there as the one you logged in. I donk know if you already checked there, but it might be worth a shot.

1 - Inside the /etc/perforce/p4dctl.conf.d/ there should be a .conf file for you server. In my case, it's in /etc/perforce/p4dctl.conf.d/master.conf.

2 - In that file, make sure the P4USER is set to the same user you logged in beforehand, which is the one you logged in using p4 set P4USER=your.username. It should also show up in the :: p4 info of your output log.

Should look something like this:

p4d master
{
    Owner    =  perforce
    Execute  =  /opt/perforce/sbin/p4d
    Umask    =  077

    # Enabled by default.
    Enabled  =  true

    Environment
    {
        P4ROOT    =     /opt/perforce/servers/master/root
        P4USER    =     YOUR_USERNAME_HERE
        P4PORT    =     ssl64:1666
        P4SSLDIR  =     ssl
        PATH      =     /bin:/usr/bin:/usr/local/bin:/opt/perforce/bin:/opt/perforce/sbin

        # Enables nightly checkpoint routine
        # This should *not* be considered a complete backup solution
        MAINTENANCE =   true
    }

}

3 - then restart your server by running p4dctl restart master (change master to whatever your server name is)

Lemme know if that helps!

The perforce documentation also has an article on how to log in non-interactively that might help.

[pfist]

I'm not sure when or why, but something did change after fiddling with things last night. The webhook now successfully sends a message to Discord, but it's mostly empty thanks to output, user, and desc still being blank:

I checked my p4dctl config, and the user does indeed match. I also ran p4 login -s to make sure the login isn't expiring. I also restarted my server just to make sure. Still no dice. It still works perfectly when run manually on the server, but fails with the "P4PASSWD invalid or unset" error when changelists are submitted. I suspect there's some silly, small thing I'm missing somewhere (as these things tend to go).

[saadbruno]

Yeah, I also think it's some silly small thing we're missing here.

I literally installed a new instance of a perforce server here in my VM to see if I'm missing anything in this repo's readme.

Everything was on a fresh installation of ubuntu, new Perforce server, fresh clone of this repo, new Discord webhook URL, everything new. And it worked just fine.

If you double checked:

• the :: Linux user in the output.log saying "perforce"
• the :: p4 info: User name: <perforce account username> in the output.log matching both the p4 login set in the command line, AND in the /etc/perforce/p4dctl.conf.d/master.conf file

which you said you did, then i'm running out of ideas. I could record a step by step video of how i set mine up, so you could check if there's any difference.

---

The ONLY other thing that comes to mind, is if your server accepts BOTH encrypted (SSL) and non-encrypted connections, what might be happening is that, when you're running the server manually, you're connected without SSL to the server, and when running the script, p4 is trying to connect using SSL, which requires you to trust the fingerprint interactively, and that's failing cause there's no user input.

IF that is the case, make sure that when when setting up the local login to the server in the command line, you set your P4PORT to use SSL.
Ex.: p4 set P4PORT=ssl:localhost:1666

And then run p4 trust to accept the certificate.

That's the only thing that comes to mind, otherwise your installation seems solid.

Edit: I just edited the README to consider SSL installations.

[pfist]

I discovered the cause of the issue today.

I was comparing the p4 info section in output.log for manual runs vs. trigger runs - desperately searching for a reason why one works and not the other - and I noticed that the server address was different. For manual runs, it was set to ssl:my.server.ip.address:1666, but trigger runs were setting this to ssl:localhost:1666.

I tried setting P4PORT to ssl:localhost:1666 on the server and, sure enough, that breaks the manual runs in the same manner, with the same Perforce password (P4PASSWD) invalid or unset error in the output log. So it appears to be an issue with the trigger environment.

[saadbruno]

That's interesting. Connecting to ssl:localhost:1666 should work fine (of course, considering the server is running on the same machine you're running the script from).

But, if you can only connect to your server through ssl:my.server.ip.address:1666, you can set that up as the trigger environment by editing your p4dctl config file (by default it is located at /etc/perforce/p4dctl.conf.d/master.conf )

The p4dctl config file should have a P4PORT under the Environment section. You can change that to the same one you were using when triggering the script manually

[pfist]

I finally got it working. It must've been a typo or other mistake I made along the way. I spun up a brand new VPS and Perforce server to test it out with a clean slate. Like you, this worked perfectly with no trouble. After that, I went back to my main server and made double triple sure everything matched, and now we're in business. 🎉

Thank you again for putting this script together, and for helping me troubleshoot this issue. I'm very thankful to finally have Perforce updates piping into my team's Discord server! 😄

[saadbruno]

I'm glad to hear! Lemme know if you run into any issues again.
Closing the issue for now.

cheers!