KEYCLOAK-4563: Large user account ID and group ID may break distribut… #3936
Conversation
|
I'd suggest that a better way to do this would be to not set tarLongFileMode on every occurrence of assembly plugin, but rather remove it from those where it's already present, and add the following into plug 8000 inManagement section of parent pom (the pom.xml in project root): |
|
Sure! I wasn't sure of how to do it globally. I'll submit a new version shortly. |
…ion builds. - Maven documentation recommends using POSIX tar format.
|
Just updated the PR with the suggested change. |
|
I'm not convinced about this. The general recommendations seems to be to use the gnu format and I'm concerned this will fix your issue, but break for others. |
|
To better inform any decision ... I also looked at it a bit ... Here is the section 8.3.7 from GNU tar manual. I understand this to mean that from version 1.14 the gnu tar will unpack tar files in posix format without any need for any extra options. I'd expect any system with java on it to have a version of tar newer than that (version 1.14 was released in 2004). |
|
Additionally, it seems that LONGFILE_GNU option in apache commons tar package is less portable than posix option according to 'Long File Names' section here. |
|
How about other archive tools? I did a little browse on Github to see what others use and WildFly, Infinispan as well as a few Apache projects seems to be using GNU and not POSIX. |
|
Googling the error message always seem to point to MacOS users, potentially linked to ActiveDirectory. I'm sure the error could also occur on Linux if UID/GID were to be too large. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (assemble) on project keycloak-as7-adapter-dist: Execution assemble of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: group id '1316617920' is too big ( > 2097151 ). Use STAR or POSIX extensions to overcome this limit -> [Help 1] My guess is that a correct solution would be to force the UID/GID in the generated archive (to 0/0), rather than use the ones from the filesystem. While the "tar" command supports that, unfortunately the Maven archive plugin doesn't have any option for it. In all cases I've found, they point to the tarLongFileMode=posix. Any reason to stick to GNU format? POSIX format has been there since 2001 and should likely be handled by most if not all archive tools outside of the Linux world: https://en.wikipedia.org/wiki/Tar_(computing)#POSIX.1-2001.2Fpax Again, I'm not sure why the Maven project only added a FAQ and don't change the default format... Most tickets to the project get closed with a reference to that flag and the FAQ: https://issues.apache.org/jira/browse/MASSEMBLY-728 |
|
I tried unpacking the server distribution generated with the POSIX file format using 7-zip on Windows and I do encounter issues I don't see with the official distribution TGZ file. A long path doesn't get unpacked correctly (missing and renamed folder/files). From experience, 7-zip doesn't have a very good track record with TAR files and I would guess that the official archive to use for Windows would be the ZIP archive? Using GNU tar on Cygwin works flawlessly with the POSIX file. |
|
I'm going to merge this, but if we get issues reported we may change it back to gnu |
In my case, this is an environmental issue caused by macOS computer being connected to an Active Directory domain. I don't have the control on the UID/GID used for my user account.