New ApisCP users resulting in "listfile for pam service does not exist"

Foo · February 7, 2024, 2:37am

Bug Report Template

Description

Adding new users to a domain wind up in an error. " * smtp: listfile for pam service does not exist" or " * smtp: listfile for pam service does not exist".

Steps to Reproduce

Please provide detailed steps to reproduce the bug. Include any necessary code snippets, commands, or configuration files.

Create or use existing domain.
Add user via User > Manage Users
User accounts will be created, email will be received, but email will not be checked in the edit of details and cannot login.
Returning to the page lists " * imap: listfile for pam service does not exist" for each users.

Expected Behavior

Describe what you expected to happen when the bug occurred.

Expected just to add a user like any time else.

Actual Behavior

Describe what actually happened when the bug occurred.

" * imap: listfile for pam service does not exist" lists for each user.

Environment

ApisCP version: 3.2.40
Operating System: 4.18.0-513.9.1.el8_9.x86_64

Additional relevant information (e.g., PHP version, database, etc.):

Additional Information

Provide any additional information about the bug, such as error messages, logs, screenshots, or any other relevant details.

msaladna · February 7, 2024, 2:43am

Is mail service enabled for this domain? If so, what’s the mail provider?

Foo · February 7, 2024, 4:12am

Yes. Mail is enable. Builtin.

msaladna · February 7, 2024, 7:07pm

I am unable to reproduce with the provided steps. See attached screencap.

Foo · February 13, 2024, 9:47pm

Trying to track this down.
This is currently affecting the most recent domain added to ApisCP. Adding emails to the respective users will display an error.

Email cannot be enabled under the user Nexus - Users - Manage Users - Edit.
apiscp-email-screenshot
Green check under email will not appear when editing the user.

Ensured the domain’s MX pointed to the server correctly.
Ensured mail is enabled and match the settings of other domains on the server.
Just in case, ran “upcp -sb” and “EditDomain --reconfig --all” to ensure everything is clean.

msaladna · February 13, 2024, 11:32pm

Just to confirm, you’re reproducing this if you add a new domain?

AddDomain -c siteinfo,domain=testdomain.test -c dns,enabled=0 -c mail,enabled=1 -c mail,provider=builtin -c siteinfo,admin_user=djkhdsf

/etc/<service>.pamlist is created when mail,enabled=1. Mail::install() is always true, so this condition is always triggered.

expand · February 11, 2025, 10:21pm

im experiencing the same thing with a transfersite.php errors out with the same messages, did this ever find a resolution, i should clarify this is on a brand new server with only multi php changed and rspamd enabled with piggyback off spamassassin

msaladna · February 12, 2025, 1:51am

PM me the transfer log.

msaladna · February 12, 2025, 2:59pm

Two observations based upon the log:

Panel version is behind. What does cpcmd misc:cp-version report?

#2 /usr/local/apnscp/lib/CLI/Transfer.php(638): CLI_Transfer->_sync('remote', 'user_add', 'X', 'Y...', 'Z', 0, Array)

Correct line would be 633, not 638

Later versions call cpcmd -d DOMAIN user:enrollment USER to determine which services a user has access to. On the source side, it’s reporting imap, pop3, and smtp services as evidenced by the error message:

FAILURE: user_add
Util_Pam::add(): imap: pam service does not exist
Util_Pam::add(): pop3: pam service does not exist
Util_Pam::add(): smtp: pam service does not exist 
Line 86

Now, if the source server has mail enabled and target does not (cpcmd scope:set mail.enabled false) - this will also error. In such a case, disable mail on the source domain (EditDomain -c mail,enabled=0) before initiating a transfer.

Transfers are intended to make 1:1 copies of the account. If an account explicitly has mail support, then it must match that behavior on the target server even if that server lacks mail support globally.

expand · February 13, 2025, 2:19am

okay found the issue the panel was as you said out of date despite selecting edge when running the installer, it was stuck at 3.2.0 i forced the git repo to pick 3.2.45 like the source server and then ran upcp and it looks like its done what it needs to, going to try the transfer now and see

expand · February 13, 2025, 2:42am

okay running upcp --reset and upcp -b reset it to 3.2.0 again i am switching to major then back to edge to see if that helps

msaladna · February 13, 2025, 6:50pm

Refer to the commit to determine the current release. Version is based upon when HEAD jumped off from the last tag (release), which on new installs isn’t always known.

For example, to flip back somewhere in the past…

git reset --hard 4e55ace958f7e6cd6de6f1bb5c63a2ec457bffc3

Then query the notes:

# git log -n1 HEAD

commit 4e55ace958f7e6cd6de6f1bb5c63a2ec457bffc3 (HEAD)
Author: hephaestus builder <build@apisnetworks.com>
Date:   Sat Jan 2 19:12:01 2021 -0500

    FIX: php.version- initial majors truncate to integer (Admin\Settings)
    CHG: extract php_admin_value to policy map (Fpm)

Remove -n1 to see all prior history. Move back to master with git reset --hard origin/master

You can also plug the commit into the following URL for something more graphical, https://gitlab.com/apisnetworks/apnscp/-/commit/COMMIT-GOES-HERE