Adding new user - no user directory created

[henning-gerhardt]

On adding a new user no user home directory is created in this creation process. In kitodo_config.properties defined script script_createDirUserHome is not called once.

[matthias-ronge]

I believe the script is called when the user logs in?

[henning-gerhardt]

Nope and why? This needs only be done once and not every time a user log in.

[matthias-ronge]

If you use LDAP, the user must first have been written into LDAP so that the operating system knows him. Otherwise chown will fail because it cannot look up the username. So this cannot happen when creating a user. On the other hand, if you are not using LDAP, you will never write the user in LDAP, so the script cannot be triggered when the LDAP entry is written. As a result, the script cannot be used until the user logs in first. All calls in the script should implement idempotency (that is, they do not change anything if the target state is already given).

[henning-gerhardt]

Sorry, I have a different opinion to this issue: on creating a new user an user home directory should be created independent if you use LDAP or not. If you use LDAP than adding this user to LDAP should be done between creating database entry and creating user home directory.

If on every login the user home directory is checked if existing or not than this is for me a big waste of time and resources.

Last sentence: even without using LDAP and logging in as this user the user home directory is currently not created!

[matthias-ronge]

Well, but in the script chown is called to give the user the permissions to his directory. chown cannot resolve the user name if it is not already in the system, and that is typically done via the LDAP. The script cannot work at all without LDAP—at least the script that we deliver with the release. How do you suppose this to work then?

[matthias-ronge]

Perhaps we then need two different scripts, one that runs when the user is created and one that runs when the user is written to LDAP. I agree that this doesn't have to be the case every time you log in. And we have to keep the script that runs at login because there is probably some facility out there that is misusing it for something else.

[henning-gerhardt]

Perhaps we then need two different scripts, one that runs when the user is created and one that runs when the user is written to LDAP.

You can do this with one script if you call the script after the user is added to the database (which is needed in any way) and optional written into the LDAP.

I don't know: should the default provided scripts for running out of box without any modification for database only usage, LDAP usage or both? If they should support both then you need more logic into the scripts as a database only usage did need other chown calls than a LDAP usage. You can even add a new parameter to the scripts which is informing the scripts if the use is a database only or ldap user. You can even miss this new parameter if you use a Linux / unix call to get the information (maybe through a getent passwd <username> call and then use the provided information to do the next needed things.

And we have to keep the script that runs at login because there is probably some facility out there that is misusing it for something else.

Which script? Currently there is no script and even in 2.x there is no such kind of script called at log in of a user. Why you want to add such kind of script which is not needed or tell me the use case where such kind of script is needed.

[matthias-ronge]

You can then still have the two scripts variables point to the same script physical.

I think it's basically stupid that the default-provided script doesn't work in any environment, but you always have to adapt it, for example with sudo, as described in the installation instructions. Couldn't it be that, for a standard case, it works, just unzip the application and start and then it works (basically). If you then want to change directories or paths, you can still do that, but that is everyone's own problem.

For this I wrote #3328, that is a directory structure that is there and then everything is in it that you need first of all. That would be my idea, but like so often my ideas, nobody cares.

[henning-gerhardt]

I think it's basically stupid that the default-provided script doesn't work in any environment,

Because the scripts are to simple to work in any environment. They are basically from 1.x and never get touched because any user in the past modified it in any way to his local environment. If you really want to make them to work out of the box in any environment then you must put a lot more logic into them but this make them harder to maintain as there is not one environment out there. So I would suggest to include the basic idea of the script usage (which parameters it gets) and what the script should do (f.e. creating a directory and maybe assign right user rights to this created directory) but not with explicit commands which maybe not work everywhere.

For this I wrote #3328, that is a directory structure that is there and then everything is in it that you need first of all. That would be my idea, but like so often my ideas, nobody cares.

Your suggestion is not bad but not related to this issue as your suggestion is for the structure of the repository and not for the used script files and where they should be stored nor their content.

[matthias-ronge]

I would suggest removing the scripts and implementing the basic functionality in the application. In addition, scripts can optionally be called at various points if you want additional functionality. Otherwise, whoever completely deviates, should implement their own filesystem management module.

[henning-gerhardt]

I would suggest removing the scripts and implementing the basic functionality in the application.

No way. If this scripts would get removed I lost the control about the application!

In addition, scripts can optionally be called at various points if you want additional functionality.

Where should this scripts called? You need additional functionality for calling them in the right places like now. F.e. call of the script for linking into the user home directory must be done in this place and not after the application has done something which did not work in a specific environment.

Or like creating the meta data directories: for most of the users they could "life" with a flat directory system but if you have a lot of directories with even more data (1 TB per process f.e.) then you may have a little bit other directory structure in the background and do some things only to look like a flat directory structure.

Otherwise, whoever completely deviates, should implement their own filesystem management module.

As long as the file management module (like other modules too) is in this repository you must maintain a fork of the whole project instead only one module. Even then the core application did calling not in any case the file management module for creating directories and / or files and doing it with direct Java calls instead of delegating this to the file management module.

[matthias-ronge]

I would suggest removing the scripts and implementing the basic functionality in the application.

No way. If this scripts would get removed I lost the control about the application!

Maybe that's a fundamental problem: Should you have control over the program, or should the program (as long as you don't change it) have control over its data? There are good arguments for both sides.

In addition, scripts can optionally be called at various points if you want additional functionality.

Where should this scripts called?

I meant these three scripts as replacements for the one script_createDirUserHome that exists at the moment. (The others stay as they are.) One script is called when a user is created (before an LDAP entry is written). The second script is called after writing to LDAP, the third is called at login. You can also comment out all three script paths or use the same script if that makes sense. Then you have complete flexibility as to when and what to do.

Otherwise, whoever completely deviates, should implement their own filesystem management module.

As long as the file management module (like other modules too) is in this repository you must maintain a fork of the whole project instead only one module.

Yes, that's it. As long as you don't touch the rest of it, it should come to the same thing.

Even then the core application did calling not in any case the file management module for creating directories and / or files and doing it with direct Java calls instead of delegating this to the file management module.

These cases need to be identified and I consider them to be bugs that need to be fixed!

[henning-gerhardt]

the third is called at login

Why did you need this? What did you want to archive with a script call at log in?

[matthias-ronge]

Assume that the user password is not stored in the database in a decipherable manner, but only as a hash. “Write user in LDAP” function is then not available at anytime. It requires the password in clear text. The function can only be carried out after entering the password, and that is when logging in. However, the user is being registered in LDAP, is a prerequisite for the Linux operating system to recognize the username for the chown command. The user is made known to the operating system from LDAP through PAM-LDAP. So it depends, and it can only be done in that order.

[henning-gerhardt]

Maybe I have a to simple idea how this should work if a new user get stored:

1. store user data including password, user namen, etc pp into the database
2. if the user data has a ldap group assigned then create entry into the LDAP system with the stored user data object
3. create the user home directory - in any way all data should be available even on a system with LDAP integration. What is done inside the called external shell script does not matter as this script is depending on the system environment and / or the usage scenario on creating the user in this particular system

If in 1), 2) or 3) an error happened did not go further into this creation workflow and report the user in the ui the error message.

[matthias-ronge]

Yes, the idea is too simple. The goal is precisely not to save the user's password in the database, but only an irreversible hash. But this is the topic of #4576 now. Sorry, I got confused between the issues yesterday.

Back to your initial question/bug report: The script_createDirUserHome is currently not called when creating the user, but when the LDAP user is created (if LDAP is used, the reason is chown failing, as I explained up there) or when the user directory is accessed from the code (for installations that don’t use LDAP at all):

In our current set-up, it seems to be working. Can you please check in which the four cases it doesn’t work for you that the script is not executed?

Notes:

• Scripts provided in the release typically have Windows line endings and don’t work, because Linux doesn’t have an interpreter bash^M. You need to run dos2unix command line utility on them.
• Of course, scripts must have execute permissions.
• For sudo root without password, must have corresponding configuration (see installation instructions, last paragraph of section 7.3).
• On recent distributions, you need to set NoNewPrivileges to false in /lib/systemd/system/tomcat9.service and sudo systemctl daemon-reload && sudo service tomcat8 restart for sudo root without password to work.