Hi James,

So you don't think it is being run on your current production server either, although at least there it exists.

It is possible that there is either something that connects to you server and runs update_users or remotely connects to you database to add user records.  I very much doubt the latter is likely or even the former.  It may be worth checking the joined time of the most recent users on your production repository.  Are they being added a times when you would expect users to login (for the first time) or are there a batch being added at the same time when it is unlikely for users to be logging in?

One other possibility is that there is something in your user_login.pl, the script that manages both local and LDAP login, which behaves differently on your test repository.  However, if you have configured this for LDAP I would assume this would be in your archive's cfg/cfg.d/ directory so would not have changed between production and test.  However, a very subtle change to $c->{check_user_password} could affect whether new users using LDAP can have a new account created for them the first time they login or whether an account on EPrints already needs to be in place for them to login.

Regards

CAUTION: This e-mail originated outside the University of Southampton.

Hi David,

Thanks for your response in my time of need!

I'm fine moving the files across and putting them in place. I'm technically still finishing the Test server upgrade. The issue I'm really having is that the live repository is still creating new users without a problem, but I can't see the "update_users" in any crontab for any user. I'm bewildered as to how it's managing to create these users if the script isn't being triggered. Which in turn is making me anxious to run it on the test server in case it's old/deprecated and some other script somewhere is making the users.

Running this as root I can see all cron jobs for all users on my server:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

I can see all the eprints user tasks I would expect, but not update_users. I might just run it manually on test and see what happens.

Thanks,

James

On Wed, Aug 16, 2023 at 11:52 AM David R Newman <drn@ecs.soton.ac.uk> wrote:

[Just noticed I only replied to you and not the whole list so I am resending.]

Hi James,

LDAP login to EPrints is an add on, so it no available in the core codebase by default.  The code/configuration for this mainly exists within the wiki page guide for using LDAP [1].  In a situation where LDAP is deployed I would expect to add all the files that relate to LDAP including the LDAP-based update_users script to exist under the archive.  However, some of this will be under the archive's cfg/ directory but the script would need to reside under the archive bin/ directory.  Maybe, the update_users script was added elsewhere (e.g. EPRINTS_PATH/bin/ rather than EPRINTS_PATH/archives/ARCHIVEID/bin/), so it was not ported over to you test repository you have upgraded.

Generally, if an existing user can login using LDAP, then the LDAP-based update_users script should be able to run successfully.  However, this may be affected by how you LDAP / AD server is configured as well as your configuration in cfg/cfg.d/ldap.pl.

I am not sure how you created your test repository, maybe it is a clone of you production repository, which you have subsequently upgraded.  Therefore, maybe you would expect the same cron jobs to be present under the eprints crontab.  However, usually the first thing I advise to people cloning an EPrints repository server VM, is to make sure you disable all EPrints related cron jobs.  Some may not work as the location of the script has moved, so you will need to update the crontab.  However, the main reason is that some cron jobs can send out emails and this can confuse users when they receive duplicates or two emails with similar but not quite the same information (e.g. a saved search emails with slightly different results).

It sounds like this should be a simple case of copying you update_users script over to the bin directory of you archive and adding it to the eprints crontab on this test server.  If the update_users script was in a different location, you may need to modify the FindBin line near the top of the file it exists, as if the update_users is now in a slightly different location relative to EPrints' perl_lib then it may not load properly.

Regards

David Newman

[1] https://wiki.eprints.org/w/LDAP

On 16/08/2023 11:12, James Kerwin wrote:

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi All,

I'll get to it; we have some new team members that need to log in to my test repository which was recently upgraded. Usually a new user attempts to log in, waits until the next day and then they're in. My new staff members are getting continued failures to log in.

The live repository is fine and allows the new accounts to be created. The difference between the two is that the live repository is awaiting an upgrade while the test repository has been upgraded.

Looking in ../archive/archive_name/cfg/cfg.d/ldap.pl I can see  a note that mentions an "update_users" script in eprints3/bin/. This is apparently set to run each night via cron and creates the new accounts. This file exists on live and not in test (totally fine, I can move it over).

I can't find the "update_users" script listed anywhere on any cron tabs. I borrowed this from stack overflow to loop through each users cron and there is no update_users in any.

This whole process has always been shrouded in mystery for me. Can anybody advise? Ideally I would find how this script is being initiated on live and copy it on to test.

Thanks,

James