Let's reopen this to track work on integrating the interactive PAM plugin as it seems we do not currently have one of those.

A superficial examination of the iRODS core code reveals two quantities which are set, but never used:
"remExec" is inserted as either a prefix or wrapper (depending on context) for the rule text in the remoteExec and smsi_remoteExec functions . But across the codebase, it seems never to get scanned-for, let alone used, despite the uneasy indication that it is somehow central to how rule text gets parsed (and indeed appears to be the only input to rsExecMyRule indicating the rule text is meant for remote execution).
"execCondition" is a key set in the execMyRuleInp_t structure by addKeyVal -- also in functions remoteExec and smsi_remoteExec -- but also is apparently never scanned-for or used.
iRODS Version, OS and Version
iRODS 4.2.11 and 4.3.0
(... and all the way back into iRODS 3.x and iRODS-Legacy)

The client library was not installed alongside the iCommands package. Seems there's just a little gap in the packaging for this platform that needs to be filled in. This problem is not exhibited on Ubuntu 20.04.

EditorConfig is meant to be an mostly-universal way of telling editors and IDEs how to treat certain files. This can be used to provide defaults for indent width, line endings, and some code formatting directives.

Currently, issues are reported on whichever version the reporter finds them on, and are tested on that version and (usually) the latest version. When a fix is found, usually a test is added to ensure regression doesn't occur in the future.
It would be nice to have these tests run against prior versions (say back to 4.2...something), so that the issue can be updated with which versions are susceptible to the bug.

The solution is to msiSetDefaultResc to a resource that exists in the system, and the message should go away.

Administrator can get permissions acting like client_user to put data into his/her collection and the data owner is the client_user.
If there is way to do the same thing in icommand?

The admin can also alias as any user via the 'clientUserName' environment
variable.
in the example we can just export clientUserName=tom to solve the problem.

Users that simply would like to installand use the icommands on their workstation would benefit from binary package installation instructions. These instructions could be added to the README file.

No, this is the intended behavior.
Inheritance affects new data objects and subcollections...

The configuration reload feature doesn't cover any use cases with multiple instances.
Given that, it is desirable to add this to irods-grid so that it may be invoked across the zone, something like irods-grid reload all

this is scoped for 4.3.1 as a Documentation exercise

Execute some iRODS native rule text remotely when a plugin other than the native rule plugin is first in the rule_engines[] part of the server configuration.
This should be possible by using INST_NAME tag in the hints argument to remote( ), and should cause only the targeted RE instance to see the request.

Some settings require a server restart to apply.
If the facility exists as a thread in the main server process, it could update the settings in the main server process. If the facility exists as a forked process, it might be a bit harder to implement this.
new advanced setting to determine how often to run... default... 600 seconds?

The website is currently an auto-redirect to irods.org (without www), where the cert is valid. Like you say, the other browsers forward without complaint, and then certify correctly. Safari catches the intermediate hop and complains.
EFF's Certbot will begin issuing wildcard certs in January 2018 - and we will be in line when they are rolled out. This issue should resolve itself at that time.

Allthough metadata items can be queried and filtered for create_time/modify_time columns, the higher level class iRODSMeta does not expose these fields. Consequently, they are not available when fetching metadata from collections and data objects (and resources and users).
Can these time fields be added?

Whether "irods_ssl_verify_server": "cert" is in the irods_environment.json file or as an argument to iRODSSession (irods_ssl_verify_server="cert" or ssl_verify_server="cert"), it does not appear to be applied. In a high availability arrangement where the connection is passed to an iRODS server with a different hostname, setting the verification to "cert" is required and works fine with the iCommands. When a connection is made after a PRC session is instantiated, however, the error below is seen.

Addressed sufficiently by https://github.com/irods/python-irodsclient/pull/381

Closing - no action needed here.

Clang fails to build under a fresh instance of Ubuntu 20.04 LTS
Suggested fix
Add update-alternatives as part of install_prerequisites.py
Or
Warn that this needs to be done at the end of install_prerequisites.py when gcc-9 is default

This is part of the readme... Do those instructions need updating?
https://github.com/irods/externals#ubuntu-18-ubuntu-20-and-debian-11

Ah, that documentation has it! --- I was using this documentation:
https://docs.irods.org/4.3.0/getting_started/installation/#non-package-install-run-in-place

Sorry for the trouble - yes, most people are not building their own externals and so we've not spent as much time keeping that documentation as polished for multiple releases.
I recommend looking at 4.2.11 documentation - it's mostly the same as 4.2.3 (linked), but some things have moved.
make sure you're building the 4-2-stable branch (git checkout 4-2-stable)
no need for make -j - each build target is already parallelized, and the dependencies themselves are defined in the Makefile
you can try make server first.. this subset of targets are the requirements for the irods-server. additional plugins may require some of the other make targets.
As a separate approach, consider a regular packaged install first, to see what success would look like. Building everything from source is definitely a tough first leap.

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.
Describe alternatives you've considered
The only alternative I can think of is a dedicated Yoda WebDAV client that can show a more appropriate error message.