Hello Reader, here is this month’s iRODS news and developments!
If you’re facing an issue with iRODS you’re not sure how to solve, please do drop me a line; if I’ve come across a solution or seen something relevant elsewhere, I’ll do my best to let you know. Or just drop me a mail to say ‘Hi’. Always nice to hear from people, particularly in these pandemic times!
I’d love your thoughts and feedback on how this newsletter could be better for you.
It happened! I was there, and so were a number of you (welcome, new subscribers!). You can see us all in front of a Belgian castle in this tweet.
I wrote a round-up on my website;
At the end of the UGM I made a call during a lighting talk, for people interested in writing system-admin and best practice focussed documentation for the community and quite a few people said they would, so work has started with a GitHub Repository holding a MK Docs site. It’s early days right now - we don’t even have a theme at the time I write this, or a deployed site, but contributions are welcome!
I had so much fun at the UGM talking to everyone I completely forgot to mention that I am available for some small consultancy if that would be useful - initially around training, but do drop me a mail if you think I might be able to help.
More details on my website
1.1.4
"This CMake feature seems like a very good way to capture various build configurations. It may also save developers from having to write build scripts whose main purpose is to set various build options."
"The iRODS server was originally written in C around 20 years ago. We would like to refactor the core server software with C++ to use modern, high-level techniques for purposes of maintainability and performance as well as extensibility."
'If you're using icommands, replace the use of "PAM" in your irods_environment.json file with "pam_password".'
One fr the ‘when upgrading to 4.3’ list!
A nice bit of developer documentation here, might steal it for the community project…
Enhancement request: “There are situations where the logger can be passed an object that is expensive to construct or copy and never actually logged.
By the time the logging API determines that the object will be ignored, it is too late. We've already paid the price of construction.
The logging API needs to provide a way to skip this."
To be clear, this is between two collections not between a file system ad a collection, and on 4.2.8. I am told that >= 4.2.9 might clear up a lot of this, as I’ve found unusable (along with) in 4.2.8.
"The python rule engine plugin build hook (https://github.com/irods/irods_rule_engine_plugin_python/blob/dff2042e8119643bb03395bef8dc790b10c22461/irods_consortium_continuous_integration_build_hook.py#L76) requires built iRODS packages to be supplied in order to build the plugin. It would be nice to be able to use the officially released packages from packages.irods.org or core-dev.irods.org for building with the build hook."
Not sure if this is just 4.3.x or affects earlier as well? Probably the latter.
setup_irods.py
Assumes default_resource_name
to be present in server_config
When configuring 4.3.0 with the json_configuration_file
option, setup_irods.py
should be present at the top level, but not in. However, setup_irods.py
looks for it in both locations. The issue also has a link to an MR provide to patch setup_irods.py
.
Searching data names is fast, whereas searching for checksums is slow. The reporter suggests adding an index at database creation/upgrade time.
I like the idea of pre-setup, but I’m not sure about this specifically. There is database overhead to maintain an index, so if you are writing lots of checksums (e.g. you have msiDataObjChksum
in an upload rule), you might not want this as the default, and it can be added later by a DBA et al.
"in data_obj_test.py , PRC reports three different possible errors test_create_from_invalid_path__250 based on changes in server version only.
ex.SYS_INVALID_INPUT_PARAM: prior to 4.2.9
ex.CAT_UNKNOWN_COLLECTION: from 4.2.9 - 4.2.11"+" ( current tip of 4.2.stable at 3989081 and icommands=c5f663c8bb1f932a8e66131cb8d4ccd39a7e98da)
ex.SYS_INVALID_FILE_PATH: beginning in 4.3.0"
This seems to be an issue of site specific configuration - of one server not being able to resolve, or connect to another server on the higher ports required for multithreaded large file transfer.
"metadata.hpp is full of function definitions that should be moved to a .cpp file and replaced with declarations. In its current state, including the header more than once in a single library or executable will result in linker errors due to overlapping symbol definitions."
4.3.0
"Further investigation has revealed that this only happens with 4.3.0.0 of the audit rule engine plugin installed and configured according to the training slide deck.
As this does not happen with a default configuration or with packages built from tip of main, I think this is actually an issue with the audit rule plugin and was fixed with irods/irods_rule_engine_plugin_audit_amqp#99."
"In my custom.re rule playbook I would like to call a rule defined in a custom plugin (a .so file) which is defined in my server conf with a particular instance_name. "
Good discussion in how to use a custom plugin in your configuration.
git224-core
no longer available for centos:7
buildsirods/apiNumber.h
4.3.0
"in irods/apiNumber.h, constants are defined which should be static. This matters when the file is included (for example, through irods/rodsClient.h) in multiple C source files, leading to a clash at link time."
iget -r
cannot be combined with -n
They can, but, you probably shouldn’t.
"If there is an efficient way to get the size of all the data objects under specified collection(maybe recursive) like linux du -s
Thanks a lot."
and a sample bit of code to do this from the issue!
total_size_in_bytes = 0 n_data_objs = 0 collection = session.collections.get('/myZone/home/myUser/home/testCollection') for info in collection.walk( ): n_data_objs += len( info[2] ) total_size_in_bytes += sum( d.size for d in info[2] )
Possibly fixed in 1.1.4?
To be fixed in 1.1.5? In the meantime, you can pull the master branch.
To be fixed in 1.1.5? In the meantime, you can pull the master branch.
To be fixed in 1.1.5? In the meantime, you can pull the master branch.
"In case a user has own access only provided by the group permission, then this user cannot add metadata via the atomic operations."
fixed in later versions of iRODS;
"By the way, our core dev team seems to have fixed the problem on the way to upcoming releases post 4.2.11 :
4.2.12
4.3.0"
To be fixed in 1.1.5? In the meantime, you can pull the master branch.
"closing as duplicate of conversation at irods/irods#6447"
If you think someone else would appreciate this newsletter, they can sign up at https://theresource.metadata.school/
Four Yaks were shaved in the making of this newsletter.
Your monthly iRODS developments The Resource Image showing text with 'welcome to 2025' and snakes Hi everybody! Like many other newsletters or companies you might have forgotten you had subscribed to, The Resource wishes you a Happy New Year and much successful data management in 2025! Yes, before you ask, the fact you're getting this at all means that the newsletter, which has been on hiatus, whilst, amongst other things, I moved house. Now that that's over with, I'm looking to resurrect the...
Your monthly iRODS developments The Resource Hello Reader, here is this month’s iRODS news and developments! News Two months off - oops! The ‘holiday’ season somewhat derailed me (should you meet me in person, ask me about the three c calamities) - lets see if I can pick it up for the new year! Fediverse? Does anyone know of any iRODS resources on Mastodon / the Fediverse? With Twitter increasingly hard to use and arguably unpleasant, I’ve seen a lot of technical communities move over to...
Your monthly iRODS developments The Resource Hello Reader, here is this month’s iRODS news and developments! News iRODS 4.3.1 is released! release announcement This release represents a steady improvement on 4.3.0's significant release last year. Most significantly, the memory leaks introduced with the new frameworks in 4.3.0 have been fixed alongside internal refactoring. Additionally, three new operating systems are now supported by our binary packaging.Detached mode has been added to the...