Don't force the IdentityLabel option one way or another when the client
doesn't specifically request one or the other, so that the server can
choose to use its default behavior.
Fixes#26669
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
The "compat-volumes" setting shouldn't be provided by the compat build
endpoint, the docker daemon's isn't expected to recognize it.
It is also a conditional boolean flag, so if it isn't specified by the
caller, don't send a value from a client to the server, so that the
server will be able to apply its own default.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
The inherit-labels setting is a conditional boolean flag, so if it isn't
specified either way by the caller, don't send a value from a client to
the server, so that the server will be able to apply its own default.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When parsing an entry in /proc/sys/fs/binfmt_misc, don't return an error
if we find an empty "flags" field in the file. Wine packaged for Fedora
provides a binfmt.d file that results in such a file, so... it's normal.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Wire up the source-date-epoch, rewrite-timestamp, and created-annotation
flags so that a client can correctly ask a server to honor them.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
There is no reason for local and rmeote to use a different error that
just differs in quoting. Make them consitent to simplify the tests.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I noticed recently when I made a typo that then auto-update errored but
it did not tell me which container was incorrect so I had to check all
containers myself. Include the container ID in the error to make it
clear which container has the issue.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Do not ignore ErrUnexpectedEOF from DemuxHeader(), if we fail to parse
the header there must have been a clear protocal error between client
and server which should be reported and not silently ignored. I wonder
ig this might explain why we have missing remote exec/attach output
without any error, it is possible we are eating some internal errors due
this.
Commit ba8eba83ef added the ErrUnexpectedEOF check but without any
explanation why that would be needed. The tests from that commit pass
without it locally but not in CI. With some debugging best I found the
issue is actually a test bug. The channel is not consumed until it is
closed which means the main test exists before the log reading goroutine
is done. And if the main test exists the first step it does is to kill
the podman service which then can trigger the ErrUnexpectedEOF server on
the still open http connection and thus the test case failed there.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
DemuxFrame() already returns a byte slice with the correct length so
this makes it simpler and the caller does not need to check this at all.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
io.ReadFull() already returns ErrUnexpectedEOF if there was a short read
so this check is redundant and can be dropped.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Lock access to and modification of the index.json file, to ensure
concurrent addition/removal does not result in lost state. Use a
standard c/storage lockfile, making use of its r/w locking
ability to support concurrent access, only serializing writes.
This is not a very efficient locking scheme around artifact
removal and - especially - addition. I view this as the first
step, establishing any sort of mutual exclusion to prevent state
corruption. Step 2 is to adapt the staged removal work being
done to make image removal require only minimal use of locks,
ensuring it works with artifact addition. This staged addition
means we won't have to hold the lock for the full artifact pull.
Signed-off-by: Matt Heon <mheon@redhat.com>
An HTTP response with Content-Type application/json does not need
to be HTML escaped. Doing this causes encoding issues in the Podman
REST API output as seen in the issue:
Fixes#17769
Remove the HTML escaping from Content-Type: application/json responses.
Signed-off-by: Stef Walter <stef@thewalter.net>
Co-Authored-By: Claude <noreply@anthropic.com>
All callers ignore the error anyways so no reason to return it as the
function itself already logs it.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
