iRODS misuses POSIX's gethostname() by passing a buffer of size HOST_NAME_MAX.

Use of the map() member function (as seen in the snippet below) is very convenient as it grants access to the underlying nlohmann::json object directly. However, it can result in data races because it bypasses the synchronization mechanisms used internally by the irods::server_properties instance.

Not all config properties are allowed to be changed post setup. Therefore, docs.irods.org needs to list which properties are safe to change post setup.

Unattended installs will completely overwrite the contents of server_config.json and irods_environment.json. This can lead to a nonfunctional server if information shared between the config files and the database become out of sync.
docs.irods.org needs to include a few statements about this behavior.

I have found when testing the Globus plugin (client to iRODS) that we appear to be linking to a version of base64_encode and base64_decode that is not the intended version. These function names are too generic and should be placed into a namespace or something.

One use case of iRODS is to colocate a data consuming service on the resource server hosting the data for this service. The service needs file system level permission to access the data, which can be configured using default_file_mode. Currently, iRODS chooses the value of default_file_mode set on the iRODS server the uploading client connects to, ii.e., the client's irods_host configuration value. If the client connects to the zone's canonical iRODS host, which may be a load balancer, it is likely that the client won't connect to the colocated resource server, and this server's default_file_mode won't be chosen. To prevent this from happening, the default_file_mode on all of the iRODS servers needs to be set to the value required on the colocated one. This isn't intuitive, and it's not always desirable.
Could iRODS be changed so that the selected default_file_mode come from the resource server hosting the storage resource chosen for a new replica? Or maybe the unixfilesystem resource could be modified to accept file mode as a context value.

This is working as designed.
This bugfix was part of #4084 for 4.2.9.
Diff for the docs: irods/irods_docs@d2631f0
Note the difference in the last row of the tables in 4.2.7:
https://docs.irods.org/4.2.7/system_overview/configuration/#default-resource-configuration
vs 4.2.11
https://docs.irods.org/4.2.11/system_overview/configuration/#default-resource-configuration

These are in the s3 plugin (s3plugin_lib.py). They have been requested to be added to lib.py.

This seems to be caused by the fact that the initial delay_server leader is set to the FQDN of my iRODS host, while the code uses the (short) hostname for comparison.

We had this configuration in iRODS 4.2.8, and we never got this error. I think because acPostProcForFilePathReg was not triggered when an object was put. This seems to have changed somewhere between 4.2.8 and 4.3.0.
We used this rule to create a checksum for objects that are registered using ireg.

Yes, in 4.2.9, with the work done to unify many of the codepaths and provide logical locking - the registration for both 'large' AND 'small' files now happens prior to data being written to disk - as a placeholder for the locking to have a thing to hold.
In 4.2.8 and before, registration-before-data-on-disk would have only happened for 'large' files that triggered parallel transfer (default, >32MB).
Please try pep_api_phy_path_reg_post() instead... I believe this will not fire for an iput, but will fire for ireg.

For easy reproduction, the following should trigger the bug:
Run an irods server version 4.2.11
Run iinit from another host with icommands version 4.2.10 or 4.2.11 and a readable /etc/irods/server_config.json containing only:
{
    "negotiation_key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "zone_key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

#6593 means we need to consider a few things regarding long running agents:
How do we handle memory leaks?
How do we handle admins modifying policy, primarily for the iRODS rule language?
One way to get around this is to introduce a counter that is associated with each connection. This counter will represent the number of requests processed by the agent. Once the counter exceeds N requests, the connection is replaced by a fresh connection.
Replacing the connection enables the following:
The agent servicing the requests is shut down
Memory leaked by the agent is returned to the OS
The new agent sees the updated policy

The mysql function R_ObjectId_nextval() is not safe for parallel database updates, that some of our users can trigger by opening a large number of parallel connections.

This message was added to leave signal that an attempt was made to unlink a file not found in an iRODS vault, leading to potential data loss. However, iunreg is not attempting to unlink the file; so, the log message is superfluous. A keyword called RESOURCE_SKIP_VAULT_PATH_CHECK_ON_UNLINK was provided to instruct the API to skip the vault check, and iunreg should provide this in its call to rcDataObjUnlink.

maximum_size_of_delay_queue_in_bytes` (optional) (default 0) - The maximum number of bytes available to the delay queue. When set to 0, the delay server will use as much memory as it needs to hold queued rules.

I have confirmed that replacing the SimpleQuery implementation with a GenQuery implementation resolves this issue. I am going to try to replace the other SimpleQuery uses in iadmin as part of this effort so that we can eventually remove it as this seems to be the last remaining holdout.

The library should be modeled after the user/group administration library with the goal of providing a modern interface and simplifying usage of the zone management features provided by the iRODS C API function, rxGeneralAdmin.

iRODS connections tie the identity of a user to the socket. This is fine for one-off commands, but not for situations where there can be hundreds to thousands of concurrent users. Creating a new connection for every user will quickly drain resources.
Therefore, iRODS should provide a way to change the user identity tied to the connection object. This would lead to huge improvements regarding performance, scalability, and resource management.
This would also improve support for client applications because the client libraries would finally be able to implement real connection pooling for iRODS connections.

ichmod is currently allowed to bypass the permission model when the user adjusting the permissions matches the original owner.
Only users with own permissions or an admin should be allowed to restore alice's permissions.

User requested to be able to determine whether to use SSL or not based on the incoming network connection (internal network or external). Original thread at https://groups.google.com/g/irod-chat/c/3afhUiB2A0k.
This would be done within acPreConnect(), however, there is no connection information available to that PEP to make an internal/external determination. It is handed a manufactured, empty rei.

Add detached mode to UFS.
This will be similar to what is done for the cacheless S3 plugin. Any resource server can serve up the request.

It was noted in this previous issue and comment that more information could be given in the product of repr(e), with e being an irods.exception returned to the PRC client from the iRODS server. Specifically the errno code provided by the OS (and propagated back to the client was e.code is 28 -> ENOSPC -> 'No space left on device'. That is essential information which rightfully should be expected as part of the repr(e) output.

In making an SSL connection more naturally following the configured irods_ssl_* settings allow the SSLContext to be automatically generated by the client library instead of relying on the user to provide a default-generated context

The Python os library module in Windows does not implement the getuid() function. As a result, attempting to encode()/decode() a password with the password_obfuscation module results in an AttributeError. The getlogin() function, however, is implemented for Windows. Provided the login can be assumed to be as unique as a uid, this can be used as replacement salt for the process.

 action is to move to 4.2.12 / 4.3.0! There are notes about various iRODS versions in the README already and it would be helpful to have an additional note to the effect that PRC put != iput and the consequences of how that interacts with different iRODS versions.

The statistics module shows total used storage by category and group. But no distinction is possible between research area, vault area, and total used storage.

The configuration for OIDC domains works only for the root domain, for example surf.nl.
If the organization has users with emails with subdomains, they are not matched by the current Yoda rules.
For example mydepartment.surf.nl is not matched if the oidc_domains list contain surf.nl.

When a Data Access Password has expired a WebDAV client will throw an authentication error, this might lead to unneeded support calls when researchers forget they have to set a new password themselves.
Describe the solution you'd like
Send an automatic notification to the user X hours (configurable for the instance) before a Data Access Password expires. The existing notification functionality in 1.8 seems suitable for this.

Support for DOI versions is added in UtrechtUniversity/yoda-ruleset@2b15ff9