Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use more permissions for mkdir #17658

Merged
merged 1 commit into from Oct 26, 2022
Merged

Use more permissions for mkdir #17658

merged 1 commit into from Oct 26, 2022

Conversation

cipherboy
Copy link
Contributor

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

@cipherboy cipherboy changed the title Use archive mode for copying source Use more permissions for mkdir Oct 26, 2022
@cipherboy cipherboy force-pushed the cipherboy-attempt-fix-docker branch 2 times, most recently from 8600744 to 6fcda98 Compare October 26, 2022 15:35
@cipherboy cipherboy force-pushed the cipherboy-attempt-fix-docker branch 2 times, most recently from dd8476d to 721b139 Compare October 26, 2022 15:41
@cipherboy
Copy link
Contributor Author

@ncabatoff Updated, we'll see if CI like this pass.

This appears to be due to a CI change that resulted in different user
IDs between the host and the container image.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
@cipherboy cipherboy merged commit a5e019e into main Oct 26, 2022
ltcarbonell pushed a commit that referenced this pull request Oct 26, 2022
This appears to be due to a CI change that resulted in different user
IDs between the host and the container image.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new group inside the container, with the host's GID (if it
doesn't already exist) and modifying the container user to also have
this group, it should be able to access these files without requiring a
chmod.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 28, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 31, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Oct 31, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
stevendpclark pushed a commit that referenced this pull request Nov 30, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
cipherboy added a commit that referenced this pull request Nov 30, 2022
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: #17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
@cipherboy cipherboy deleted the cipherboy-attempt-fix-docker branch December 1, 2022 14:56
jayant07-yb pushed a commit to jayant07-yb/hashicorp-vault-integrations that referenced this pull request Mar 15, 2023
This appears to be due to a CI change that resulted in different user
IDs between the host and the container image.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
jayant07-yb pushed a commit to jayant07-yb/hashicorp-vault-integrations that referenced this pull request Mar 15, 2023
When copying data into the container, due to the id changes pointed
out in the previous attempt, the container couldn't read this data.

By creating a new user in the container, matching the host's UID/GID, we
can successfully copy data in/out of the container without worrying
about differing UID/GIDs.

See also: hashicorp#17658

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants