Can't get personalization API to set default webmail app
I have an existing Perl script that uses the /Personalization/set API to set the default webmail app to roundcube. It works on my current production server.
I am in the process of setting up a new server (which has the same version of cPanel), but the same code doesn't work. The only major difference is the new one is AlmaLinux vs the production server which is CentOS 7.
I can use the following SSH command to test the operation and it succeeds on the new server:
echo '{"personalization":{"username@domain.com_default_webmail_app":"roundcube"}}' | uapi --user=root --input=json --output=json Personalization set
I thought it was supposed to create a default_webmail_app file in the /home/[accountuser]/.cpanel/nvdata folder. But that folder or file does not exist after the command is executed.
When I try my script using the Personalization API on the new server, the returned response content is an HTML page that says my security token is invalid. I have checked the user ID and password being sent in during authorization and it's correct and works elsewhere.
I thinking this must be some difference in the server/cPanel configuration or perhaps a configuration difference with the user account on the new server, since the same code works fine on the existing production server. Also, perhaps using "root" as the user in the SSH command allows it to succeed whereas the script is not authenticating as root (although it doesn't authenticate as root on the production server either). In the script, it authenticates using the account-level user ID and password, which works on the existing production server.
Any ideas why the nvdata/default_webmail_app folder/file isn't being created when the command executes successfully in a SSH console? Or why the API call would fail from my script on the new server?
Thanks for any advice or suggestions you may have.
-
While debugging this further, I changed my app to manually create the nvdata folder, but it failed to create it (said it already existed but it didn't). So I created it manually from SSH (as root). I then updated my script to manually create the user@domain_default_webmail_app file, but it failed saying "permission denied." I manually chown'd the nvdata folder to the user account's user ID and then my script could create the default_webmail_app file in the folder. So it appears there is some issue with permissions creating the nvdata folder at first, and my guess is that the API is hitting that issue. I'm just not sure why it works on the production server and not on the new server. Perhaps it is related to how the user account was created in the first place. On the production server, it was created under a reseller account that I don't have on the new server yet. I just did a backup of a test account on the production server and moved it to and restored it on the new server, so perhaps that causes some permission to be different some place... 0 -
Hey there! On my system, the SSH command creates a file named email@domain.com_default_webmail_app inside /home/cptest2/.cpanel/nvdata, so that seems to be working well on my end. I did change the username in your example from "root" to the specific cPanel account in question. As far as the token, it might be time to switch from tokens instead of a user/pass in the API call: How to Use cPanel API Tokens | cPanel & WHM Documentation 0 -
Thanks. I have figured out that the "file exists" error when creating the folder was a typo. After that, I can create the nvdata folder in my script. But then I let the script continue to try to use the API and it still fails. If I manually write out a default_webmail_app file with "roundcube" in it, it works to send the user to the roundcube inbox right after login. But I will continue to debug further to try to get the API working as I would prefer that method... Thanks for your suggestion and I will check out tokens and see if it makes a difference. 0
Please sign in to leave a comment.
Comments
3 comments