7:24 a.m.
Hello!!
On 08/09/20 11:28 pm, Daniel Walsh wrote:
What command are you using to launch the Envoyproxy container?
$ sudo podman run -v ./envoy.yaml:/etc/envoy/envoy.yaml --network test
--name test-lz -d -p 10000:10000 envoyproxy/envoy:v1.15.0
The AVC's indicate the container is attempting to write to a fifo_file
created by podman
# podman run --privileged -v /usr/bin/find:/usr/bin/find fedora find /
-type p
The issue is I am not getting any information about what fifo file is
being blocked?
There is no output returned by the above command in rootful mode.
Running the same command in rootless mode returns
find: '/proc/tty/driver': Permission denied
Is this running rootful or rootless?
The AVC output in the pastebin was from the container running in rootful
mode.
I have tried running the container in both rootful and rootless mode.
--
Chintan Mishra
On 9/8/20 13:06, Chintan from Rebhu wrote:
>
> Hello, everyone!!
>
> Thank you Chris, Matt, and Daniel for helping me understand the
> queries in my mind.
>
> Here is a pastebin of Access Vector Cache(AVC) output
> https://pastebin.com/c1w8AnA7
>
> The contents were fetched using `|ausearch -m avc --start recent|`.
>
> On 08/09/20 6:32 pm, Chris Evich wrote:
>> On 9/8/20 12:48 AM, Chintan from Rebhu wrote:
>>> The same error is not present when I switch from v1.15.0 to v1.14.4
>>> of Envoyproxy.
>>>
>>> I am out of my wits about this. Please tell me how I should find a
>>> solution.
>>>
>>> We only use Podman in our infrastructure.
>>
>> Hi,
>>
>> First off, I don't mean to dismiss the scale of your frustrations or
>> challenges here. However, this list may not be the appropriate
>> place for seeking infrastructure support for third-party
>> interoperability (open-source or closed).
>>
>> We're really narrowly focused on podman and it's intimately related
>> container technologies, and improving the state thereof. If you're
>> looking for end-to-end debugging and help, then a commercial support
>> option would probably be best.
>
> If it was something non-trivial then I would happily seek commercial
> support. I am just trying to run a command that works with Docker on
> Debian(checked a few moments ago) but fails on Podman. Podman is
> marketed as a drop-in replacement for Docker. So, one would expect
> that commands work out of box. And most generic applications do run
> fine. But there are a significant number of applications that need
> certain modifications to get things working with Podman. One grows
> appreciative of the finer details as they use Podman. But these finer
> details are poorly documented and highly fragmented all over the
> internet. And if applications keep not working and stay without
> resolution or without documentation then that will be a deterrent for
> Podman's wider community adoption.
>
> What do you suggest the community do to get applications running
> through Podman?
>
>>
>> OTOH, I see you're follow-up mail, which does have some
>> podman-specific questions we can probably help with. I just want to
>> be clear up-front, that this list is not an official/commercial
>> means for overall/general system support.
>>
> In the first e-mail, I failed to mention that I ruled out issues in
> the containerfile provided by the Envoyproxy maintainers. There is no
> mention of a similar issue on their communication channels like
> Slack, GitHub issues and Google group. So, it was only logical to
> conclude that the issue is with Podman.
>
> --
> Chintan Mishra
>
> _______________________________________________
> Podman mailing list --podman(a)lists.podman.io
> To unsubscribe send an email topodman-leave(a)lists.podman.io
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io