Error connection refused in logs

First--thanks for the great work on this app!
I have posted this issue on the thread in Vera but I am a new user so I am waiting for a moderator to approve my post. Apologies for the cross post.
I am seeing the same issues as xeinth--Error Calling out to HA Gateway, connection refused (to my VE)--multiple times. It then eventually connects. The UI correctly detects all Devices and Scenes and displays them. It is displaying Devices and Scenes in the UI even as the log shows repeated instances of Connection Refused. Devices generate URLs and test properly. I enabled UPNP on both my routers.
Scenes do not generate URLs. If I manually add a scene (http://vera:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=<scene#>) I either get a a popup with a 404 error or a popup with command ran successfully but the scene doesn't fire.
The scenes run fine in Vera Ui 7. I have done everything I can think of including deleting all devices and adding them again. At present I have (11) zwave switches/outlets that test successfully and work through Echo.
I am running this on an rpi 2, with Raspbian Jessie. I am running the most recent Vera firmware--1.7.1598 that was released last week.
Thanks!

So, there is a bug in url generation that needs to be fixed. It will be coming soon.
Thanks
The Support Team
--------- Original Message --------- Subject: [ha-bridge] Error connection refused in logs (#13)
From: "ckhyatt"<EMAIL_ADDRESS>Date: 11/30/15 3:40 pm
To: "bwssytems/ha-bridge"<EMAIL_ADDRESS>First--thanks for the great work on this app!
I have posted this issue on the thread in Vera but I am a new user so I am waiting for a moderator to approve my post. Apologies for the cross post.
I am seeing the same issues as xeinth--Error Calling out to HA Gateway, connection refused (to my VE)--multiple times. It then eventually connects. The UI correctly detects all Devices and Scenes and displays them. It is displaying Devices and Scenes in the UI even as the log shows repeated instances of Connection Refused. Devices generate URLs and test properly. I enabled UPNP on both my routers.
Scenes do not generate URLs. If I manually add a scene (http://vera:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=) I either get a a popup with a 404 error or a popup with command ran successfully but the scene doesn't fire.
The scenes run fine in Vera Ui 7. I have done everything I can think of including deleting all devices and adding them again. At present I have (11) zwave switches/outlets that test successfully and work through Echo.
I am running this on an rpi 2, with Raspbian Jessie. I am running the most recent Vera firmware--1.7.1598 that was released last week.
Thanks!
Reply to this email directly or view it on GitHub.

Excellent--thanks! What about the Error Calling out to HA Gateway, connection refused?

What is your command line? The call is a direct calm to the vera you specify on the command line.
Thanks
On Dec 1, 2015 9:32 AM, ckhyatt<EMAIL_ADDRESS>wrote:Excellent--thanks! What about the Error Calling out to HA Gateway, connection refused?
—Reply to this email directly or view it on GitHub.

This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!

Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
—Reply to this email directly or view it on GitHub.

I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
—Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

That is the upnp.config.address. If you want the vera helpers, you will need to add it.
On Dec 1, 2015 10:21 AM, ckhyatt<EMAIL_ADDRESS>wrote:I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
—Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

—Reply to this email directly or view it on GitHub.

My apologies, I copied this incorrectly from my configuration doc. Here is how it is configured:
ps ef | grep "habridge" | awk '{print $2}' | xargs kill
java jar Dvera.address=<IP_ADDRESS> Dupnp.device.db=/usr/local/habridge/devices.db /usr/local/habridge/habridge1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &

On Dec 1, 2015, at 11:24 AM, bwssytems<EMAIL_ADDRESS>wrote:
That is the upnp.config.address. If you want the vera helpers, you will need to add it.
On Dec 1, 2015 10:21 AM, ckhyatt<EMAIL_ADDRESS>wrote:I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
—Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

—Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

Ahh, looking through my notes, and updates for the next release, I have changed how the bridge connects to the vera. I have run into that before as well.
Comming soon.
Thanks
--------- Original Message --------- Subject: Re: [ha-bridge] Error connection refused in logs (#13)
From: "ckhyatt"<EMAIL_ADDRESS>Date: 12/1/15 9:25 am
To: "bwssytems/ha-bridge"<EMAIL_ADDRESS>Cc: "bwssytems"<EMAIL_ADDRESS>My apologies, I copied this incorrectly from my configuration doc. Here is how it is configured:
ps ef | grep "habridge" | awk '{print $2}' | xargs kill
java jar Dvera.address=<IP_ADDRESS> Dupnp.device.db=/usr/local/habridge/devices.db /usr/local/habridge/habridge1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &

On Dec 1, 2015, at 11:24 AM, bwssytems<EMAIL_ADDRESS>wrote:
That is the upnp.config.address. If you want the vera helpers, you will need to add it.
On Dec 1, 2015 10:21 AM, ckhyatt<EMAIL_ADDRESS>wrote:I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

Thanks! I just wanted to be sure I hadn't made a mistake.
Thanks again for all your work on this app. It is an excellent solution.
Regards,
Craig

On Dec 1, 2015, at 11:47 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh, looking through my notes, and updates for the next release, I have changed how the bridge connects to the vera. I have run into that before as well.
Comming soon.
Thanks
--------- Original Message --------- Subject: Re: [ha-bridge] Error connection refused in logs (#13)
From: "ckhyatt"<EMAIL_ADDRESS>Date: 12/1/15 9:25 am
To: "bwssytems/ha-bridge"<EMAIL_ADDRESS>Cc: "bwssytems"<EMAIL_ADDRESS>My apologies, I copied this incorrectly from my configuration doc. Here is how it is configured:
ps ef | grep "habridge" | awk '{print $2}' | xargs kill
java jar Dvera.address=<IP_ADDRESS> Dupnp.device.db=/usr/local/habridge/devices.db /usr/local/habridge/habridge1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &

On Dec 1, 2015, at 11:24 AM, bwssytems<EMAIL_ADDRESS>wrote:
That is the upnp.config.address. If you want the vera helpers, you will need to add it.
On Dec 1, 2015 10:21 AM, ckhyatt<EMAIL_ADDRESS>wrote:I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

I confirmed my device IDs and Scene IDs are duplicates. I suspect this is the reason it doesn't work when I manually copy the scene URL into the UI. Looks like both issues will be fixed in the next release.
Thanks again for all your hard work on this app.
Craig

On Dec 1, 2015, at 11:47 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh, looking through my notes, and updates for the next release, I have changed how the bridge connects to the vera. I have run into that before as well.
Comming soon.
Thanks
--------- Original Message --------- Subject: Re: [ha-bridge] Error connection refused in logs (#13)
From: "ckhyatt"<EMAIL_ADDRESS>Date: 12/1/15 9:25 am
To: "bwssytems/ha-bridge"<EMAIL_ADDRESS>Cc: "bwssytems"<EMAIL_ADDRESS>My apologies, I copied this incorrectly from my configuration doc. Here is how it is configured:
ps ef | grep "habridge" | awk '{print $2}' | xargs kill
java jar Dvera.address=<IP_ADDRESS> Dupnp.device.db=/usr/local/habridge/devices.db /usr/local/habridge/habridge1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &

On Dec 1, 2015, at 11:24 AM, bwssytems<EMAIL_ADDRESS>wrote:
That is the upnp.config.address. If you want the vera helpers, you will need to add it.
On Dec 1, 2015 10:21 AM, ckhyatt<EMAIL_ADDRESS>wrote:I originally had the IP and it made no difference. The readme indicates the IP is not necessary as it uses the default IP of the host. Is the readme incorrect? To be clear, the bridge is running and I can control 11 devices through Echo.
Thanks!

On Dec 1, 2015, at 11:11 AM, bwssytems<EMAIL_ADDRESS>wrote:
Ahh yes, you need to supply the vera IP address. Add this -Dvera.address= and you will be in business.
Please read the readme at HTTPS://github.com/bwssytems/ha-bridge as it will explain all the command line items and why you may need them.
The support team
On Dec 1, 2015 9:53 AM, ckhyatt<EMAIL_ADDRESS>wrote:This is the command line in the .sh:
ps -ef | grep "ha-bridge" | awk '{print $2}' | xargs kill
java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
This is in the crontab:
@reboot java -jar java -jar -Dupnp.device.db=/usr/local/habridge/devices.db
/usr/local/habridge/ha-bridge-1.1.0.jar 2>&1 | tee /usr/local/habridge/habridge.log &
Thanks!
-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

-Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.


Using PAT as Bearer for authorization Header is not working

It seems that using PAT as Bearer whether it's encoded to Base64 or not is not working.
I also disable Git Credential helpers
git -c http.extraHeader="Authorization: Bearer $B64Pat" clone <repo_uri>                                                                Cloning into '<repo_uri'...
Username for 'https://dev.azure.com':
Password for 'https://dev.azure.com':
fatal: Authentication failed for <repo_uri>

The question would be why this would still need to me get prompted with username as anything and password as PAT. would be this just causing a redundancy if Bearer  is taken place?

Git interactions require a username, which can be anything except the empty string. The PAT is used as the password. Additionally, you have to Base64-encode the username & PAT in order to use it with HTTP basic authentication. On Linux or macOS, in Bash, you can type:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 53f99d2d-363b-d01d-039d-4fdc636fa2df
Version Independent ID: f47330d5-e2de-36a4-e5b3-5bc77505b161
Content: Authenticate with personal access tokens - Azure DevOps
Content Source: docs/organizations/accounts/use-personal-access-tokens-to-authenticate.md
Product: devops
Technology: devops-security
GitHub Login: @chcomley
Microsoft Alias: chcomley

@jesslinocon Thank you for the feedback.
Unfortunately our support options in the documentation forum are limited to provided examples only.
Please use Report a problem or Suggest a feature in the Azure DevOps community to solicit help from the product team and include a link back to this issue.
Otherwise, for additional support options, see:

Azure DevOps support
Azure DevOps on StackOverflow


fix include outbound ports iptable rules in tproxy mode

As we are discussing https://github.com/istio/istio/issues/27565#issuecomment-765184403 we have an issue with IncludeOutboundPorts not working properly in TPROXY mode.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ X] Does not have any changes that may affect Istio users.

@lambdai see if this makes sense

@lambdai see if this makes sense

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test lint_istio

gencheck_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test lint_istio

gencheck_istio
f9789104b74d920a3211580fd307bf5c57b098a2
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
5cec1fe732aa58ae901ed0650c9bad68f1586040
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
5cec1fe732aa58ae901ed0650c9bad68f1586040
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-security-k8s-tests_istio

/test integ-security-k8s-tests_istio

@rlenglet I see. Thank you.  Based on the ip table output attached here https://github.com/istio/istio/issues/27565#issuecomment-764525722, would you be able to help what is the problem with IncludeOutboundPorts in TPROXY mode?

@rlenglet I see. Thank you.  Based on the ip table output attached here https://github.com/istio/istio/issues/27565#issuecomment-764525722, would you be able to help what is the problem with IncludeOutboundPorts in TPROXY mode?

The current tproxy chain in NAT table is below. see full table in https://github.com/istio/istio/issues/27565#issuecomment-764525722
I don't understand why neither  -m owner --uid-owner 1337 -j RETURN nor -m owner --gid-owner 1337 -j RETURN hit.
These two rules are supposed to bypass NAT rewrite(target ISTIO_REDIRECT) when Envoy connects to other containers.
@ramaraochavali confirmed that the Envoy is running under uid 1337 in tproxy?
@rlenglet Do you have any clue?
-A ISTIO_OUTPUT -o lo -s <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN

The current tproxy chain in NAT table is below. see full table in https://github.com/istio/istio/issues/27565#issuecomment-764525722
I don't understand why neither  -m owner --uid-owner 1337 -j RETURN nor -m owner --gid-owner 1337 -j RETURN hit.
These two rules are supposed to bypass NAT rewrite(target ISTIO_REDIRECT) when Envoy connects to other containers.
@ramaraochavali confirmed that the Envoy is running under uid 1337 in tproxy?
@rlenglet Do you have any clue?
-A ISTIO_OUTPUT -o lo -s <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN

is envoy running as uid 0 for tproxy for root?
On Sat, Jan 23, 2021, 5:28 PM Yuchen Dai<EMAIL_ADDRESS>wrote:

The current tproxy chain in NAT table is below. see full table in #27565
(comment)
https://github.com/istio/istio/issues/27565#issuecomment-764525722
I don't understand why neither -m owner --uid-owner 1337 -j RETURN nor -m
owner --gid-owner 1337 -j RETURN hit.
These two rules are supposed to bypass NAT rewrite(target ISTIO_REDIRECT)
when Envoy connects to other containers.
@ramaraochavali https://github.com/ramaraochavali confirmed that the
Envoy is running under uid 1337 in tproxy?
@rlenglet https://github.com/rlenglet Do you have any clue?

Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/30306#issuecomment-766272065, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNNHGT6YCO5GAE2N3LS3NZTDANCNFSM4WOKLZSA
.

is envoy running as uid 0 for tproxy for root?
On Sat, Jan 23, 2021, 5:28 PM Yuchen Dai<EMAIL_ADDRESS>wrote:

The current tproxy chain in NAT table is below. see full table in #27565
(comment)
https://github.com/istio/istio/issues/27565#issuecomment-764525722
I don't understand why neither -m owner --uid-owner 1337 -j RETURN nor -m
owner --gid-owner 1337 -j RETURN hit.
These two rules are supposed to bypass NAT rewrite(target ISTIO_REDIRECT)
when Envoy connects to other containers.
@ramaraochavali https://github.com/ramaraochavali confirmed that the
Envoy is running under uid 1337 in tproxy?
@rlenglet https://github.com/rlenglet Do you have any clue?

Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/30306#issuecomment-766272065, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNNHGT6YCO5GAE2N3LS3NZTDANCNFSM4WOKLZSA
.

@howardjohn Theoretically the requirement is CAP_NET_ADMIN. Uid 0 is overkill.

@howardjohn Theoretically the requirement is CAP_NET_ADMIN. Uid 0 is overkill.

I recall the injection template may set it to 0 though - worth checking. I
may remember wrong
On Sat, Jan 23, 2021, 5:33 PM Yuchen Dai<EMAIL_ADDRESS>wrote:

@howardjohn https://github.com/howardjohn Theoretically the requirement
is CAP_NET_ADMIN. Uid 0 is overkill.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/30306#issuecomment-766272537, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXLX4QR6LIHJQWJQFHTS3N2G3ANCNFSM4WOKLZSA
.

I recall the injection template may set it to 0 though - worth checking. I
may remember wrong
On Sat, Jan 23, 2021, 5:33 PM Yuchen Dai<EMAIL_ADDRESS>wrote:

@howardjohn https://github.com/howardjohn Theoretically the requirement
is CAP_NET_ADMIN. Uid 0 is overkill.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/30306#issuecomment-766272537, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXLX4QR6LIHJQWJQFHTS3N2G3ANCNFSM4WOKLZSA
.

I recall the injection template may set it to 0 though - worth checking. I may remember wrong
…

Then I guess the PROXY_UID=1337, PROXY_GID=1337 alone doesn't imply envoy running uid 1337.
Maybe the injection deserves the change, not the iptables.
CC @ramaraochavali

I recall the injection template may set it to 0 though - worth checking. I may remember wrong
…

Then I guess the PROXY_UID=1337, PROXY_GID=1337 alone doesn't imply envoy running uid 1337.
Maybe the injection deserves the change, not the iptables.
CC @ramaraochavali

@lambdai Thank you so much for looking in to this. Yeah, I also figured out that it is not returning properly but could not think uid is problem - I was tripped off by the iptable output. Looked at the injection template and pod.yaml - Yes, in TPROXY mode it is running as 0 as @howardjohn says.
I reverted the iptable change and fixed the template.
@lambdai @howardjohn @rlenglet PTAL - Thanks for helping out on this.

@lambdai Thank you so much for looking in to this. Yeah, I also figured out that it is not returning properly but could not think uid is problem - I was tripped off by the iptable output. Looked at the injection template and pod.yaml - Yes, in TPROXY mode it is running as 0 as @howardjohn says.
I reverted the iptable change and fixed the template.
@lambdai @howardjohn @rlenglet PTAL - Thanks for helping out on this.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
f86f2e4758631dc4d27767049ed7435d06afc449
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/retest

@lambdai So we patch the security context in the operator with the following
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  privileged: false
  readOnlyRootFilesystem: false
  runAsUser: 1337

And the SecurityContext for TPROXY pod is
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: false
      runAsUser: 0

and for REDIRECT is
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 1337

So I guess the operator patching is ignoring runAsGroup as it is not there in the patch?
So I am wondering the following rule is helping in REDIRECT mode
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN

But since runAsUser is 0 for TPROXY - it is failing.
So this PR is setting UID to 1337 which works for us.
WDYT?

@lambdai So we patch the security context in the operator with the following
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  privileged: false
  readOnlyRootFilesystem: false
  runAsUser: 1337

And the SecurityContext for TPROXY pod is
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: false
      runAsUser: 0

and for REDIRECT is
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 1337

So I guess the operator patching is ignoring runAsGroup as it is not there in the patch?
So I am wondering the following rule is helping in REDIRECT mode
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN

But since runAsUser is 0 for TPROXY - it is failing.
So this PR is setting UID to 1337 which works for us.
WDYT?

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

integ-pilot-k8s-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
b6c4e5396ffbc7b79a182b1c673193f1ef25bdac
link
/test integ-pilot-multicluster-tests_istio

integ-pilot-k8s-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ramaraochavali: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
de3385c6bca752ed12b1a65fd9f54690e05a1dc6
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

When did runAsGroup ever get removed from the securityContext? 🤔

When did runAsGroup ever get removed from the securityContext? 🤔

@rlenglet Agreed.  I am still looking in to why runAsGroup is not coming even when the injection template has it. One possible explanation is runAsGroup on container can be disabled using feature gate https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/. I am checking with our kubernetes team if that is the case in our environment.
Do you see any issues setting user to 1337 for TPROXY?

@rlenglet Agreed.  I am still looking in to why runAsGroup is not coming even when the injection template has it. One possible explanation is runAsGroup on container can be disabled using feature gate https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/. I am checking with our kubernetes team if that is the case in our environment.
Do you see any issues setting user to 1337 for TPROXY?

If UID != GID there are some edge cases that may not work btw. I think TestTraffic/selfcall will fail

If UID != GID there are some edge cases that may not work btw. I think TestTraffic/selfcall will fail

Do you see any issues setting user to 1337 for TPROXY?

Yes. IIRC, that's because Docker doesn't set ambient capabilities. So when it switches the container's UID from 0 to 1337, it loses all capabilities. Adding capabilities only work if UID is 0.

Do you see any issues setting user to 1337 for TPROXY?

Yes. IIRC, that's because Docker doesn't set ambient capabilities. So when it switches the container's UID from 0 to 1337, it loses all capabilities. Adding capabilities only work if UID is 0.

If UID != GID there are some edge cases that may not work btw. I think TestTraffic/selfcall will fail

That's a good point. The goals of (uid != 1337, gid=1337) are

Don't intercept uid=0 since we assume this uid is shared among Envoy and other processes.
Capture on gid=1337 which is Envoy(or whichever don't want to be captured)

So the Envoy runAsUid and captured uid must be independent, with the default case that
runAsUid = 1337, captured uid = {1337}. Note that captured uid is a collection.

If UID != GID there are some edge cases that may not work btw. I think TestTraffic/selfcall will fail

That's a good point. The goals of (uid != 1337, gid=1337) are

Don't intercept uid=0 since we assume this uid is shared among Envoy and other processes.
Capture on gid=1337 which is Envoy(or whichever don't want to be captured)

So the Envoy runAsUid and captured uid must be independent, with the default case that
runAsUid = 1337, captured uid = {1337}. Note that captured uid is a collection.

Yes. IIRC, that's because Docker doesn't set ambient capabilities. So when it switches the container's UID from 0 to 1337, it loses all capabilities. Adding capabilities only works if the UID is 0.

Is this the capability uniquely lost in docker-shim CRI?  Other CRI may support

Yes. IIRC, that's because Docker doesn't set ambient capabilities. So when it switches the container's UID from 0 to 1337, it loses all capabilities. Adding capabilities only works if the UID is 0.

Is this the capability uniquely lost in docker-shim CRI?  Other CRI may support

Ok. Another finding to test whether gid is the actual issue, I passed -g 0,1337 to iptables to let it skip gid 0 also. But the problem exists - It makes me wonder it is not gid but some thing else is there
Here is the proxy id uid=0(root) gid=0(root) groups=0(root),1337(istio-proxy)
and the ip table rules - now it added a rule to skip if gid is 0 - but still it did not skip
Environment:
------------
ENVOY_PORT=
INBOUND_CAPTURE_PORT=
ISTIO_INBOUND_INTERCEPTION_MODE=
ISTIO_INBOUND_TPROXY_MARK=
ISTIO_INBOUND_TPROXY_ROUTE_TABLE=
ISTIO_INBOUND_PORTS=
ISTIO_OUTBOUND_PORTS=
ISTIO_LOCAL_EXCLUDE_PORTS=
ISTIO_SERVICE_CIDR=
ISTIO_SERVICE_EXCLUDE_CIDR=

Variables:
----------
PROXY_PORT=15001
PROXY_INBOUND_CAPTURE_PORT=15006
PROXY_TUNNEL_PORT=15008
PROXY_UID=1337
PROXY_GID=0,1337
INBOUND_INTERCEPTION_MODE=TPROXY
INBOUND_TPROXY_MARK=1337
INBOUND_TPROXY_ROUTE_TABLE=133
INBOUND_PORTS_INCLUDE=*
INBOUND_PORTS_EXCLUDE=15090,15021,8181,15020
OUTBOUND_IP_RANGES_INCLUDE=<IP_ADDRESS>/32
OUTBOUND_IP_RANGES_EXCLUDE=
OUTBOUND_PORTS_INCLUDE=50010,50020,50075,50070,50090,9000,8019,8480,8481,8485,2181,8030,8031,8032,8033,8088,8040,8041,8042,10020,19888,33911,8020,8082
OUTBOUND_PORTS_EXCLUDE=
KUBEVIRT_INTERFACES=
ENABLE_INBOUND_IPV6=false

ip -f inet rule add fwmark 1337 lookup 133
ip -f inet route add local default dev lo table 133
Writing following contents to rules file:  /tmp/iptables-rules-1611637611221538655.txt201772342
* nat
-N ISTIO_INBOUND
-N ISTIO_REDIRECT
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp --dport 15008 -j RETURN
-A ISTIO_REDIRECT -p tcp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -o lo -s <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 0 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 0 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8030 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8031 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8032 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8033 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8088 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8040 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8041 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8042 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 10020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 19888 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 33911 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8082 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --uid-owner 1337 -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --gid-owner 0 -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --gid-owner 1337 -j RETURN
-A OUTPUT -p udp --dport 53 -j DNAT --to-destination <IP_ADDRESS>:15053
-A POSTROUTING -p udp --dport 15053 -j SNAT --to-source <IP_ADDRESS>
COMMIT
* mangle
-N ISTIO_DIVERT
-N ISTIO_TPROXY
-N ISTIO_INBOUND
-A ISTIO_DIVERT -j MARK --set-mark 1337
-A ISTIO_DIVERT -j ACCEPT
-A ISTIO_TPROXY ! -d <IP_ADDRESS>/32 -p tcp -j TPROXY --tproxy-mark 1337/0xffffffff --on-port 15006
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A ISTIO_INBOUND -p tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 8181 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ISTIO_DIVERT
-A ISTIO_INBOUND -p tcp -j ISTIO_TPROXY
-A PREROUTING -p tcp -m mark --mark 1337 -j CONNMARK --save-mark
-A OUTPUT -p tcp -m connmark --mark 1337 -j CONNMARK --restore-mark
-I ISTIO_INBOUND 1 -p tcp -m mark --mark 1337 -j RETURN
COMMIT

iptables-restore --noflush /tmp/iptables-rules-1611637611221538655.txt201772342
Writing following contents to rules file:  /tmp/ip6tables-rules-1611637611969044794.txt772360989

ip6tables-restore --noflush /tmp/ip6tables-rules-1611637611969044794.txt772360989
iptables-save
# Generated by iptables-save v1.4.21 on Tue Jan 26 05:06:51 2021
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ISTIO_DIVERT - [0:0]
:ISTIO_INBOUND - [0:0]
:ISTIO_TPROXY - [0:0]
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A PREROUTING -p tcp -m mark --mark 0x539 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT -p tcp -m connmark --mark 0x539 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A ISTIO_DIVERT -j MARK --set-xmark 0x539/0xffffffff
-A ISTIO_DIVERT -j ACCEPT
-A ISTIO_INBOUND -p tcp -m mark --mark 0x539 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 8181 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ISTIO_DIVERT
-A ISTIO_INBOUND -p tcp -j ISTIO_TPROXY
-A ISTIO_TPROXY ! -d <IP_ADDRESS>/32 -p tcp -j TPROXY --on-port 15006 --on-ip <IP_ADDRESS> --tproxy-mark 0x539/0xffffffff
COMMIT
# Completed on Tue Jan 26 05:06:51 2021
# Generated by iptables-save v1.4.21 on Tue Jan 26 05:06:51 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ISTIO_INBOUND - [0:0]
:ISTIO_IN_REDIRECT - [0:0]
:ISTIO_OUTPUT - [0:0]
:ISTIO_REDIRECT - [0:0]
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A OUTPUT -p udp -m udp --dport 53 -m owner --uid-owner 1337 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -m owner --gid-owner 0 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -m owner --gid-owner 1337 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination <IP_ADDRESS>:15053
-A POSTROUTING -p udp -m udp --dport 15053 -j SNAT --to-source <IP_ADDRESS>
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A ISTIO_OUTPUT -s <IP_ADDRESS>/32 -o lo -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --gid-owner 0 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 0 -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8030 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8031 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8032 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8033 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8088 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8040 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8041 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8042 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 10020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 19888 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 33911 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8082 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
-A ISTIO_REDIRECT -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Tue Jan 26 05:06:51 2021

Ok. Another finding to test whether gid is the actual issue, I passed -g 0,1337 to iptables to let it skip gid 0 also. But the problem exists - It makes me wonder it is not gid but some thing else is there
Here is the proxy id uid=0(root) gid=0(root) groups=0(root),1337(istio-proxy)
and the ip table rules - now it added a rule to skip if gid is 0 - but still it did not skip
Environment:
------------
ENVOY_PORT=
INBOUND_CAPTURE_PORT=
ISTIO_INBOUND_INTERCEPTION_MODE=
ISTIO_INBOUND_TPROXY_MARK=
ISTIO_INBOUND_TPROXY_ROUTE_TABLE=
ISTIO_INBOUND_PORTS=
ISTIO_OUTBOUND_PORTS=
ISTIO_LOCAL_EXCLUDE_PORTS=
ISTIO_SERVICE_CIDR=
ISTIO_SERVICE_EXCLUDE_CIDR=

Variables:
----------
PROXY_PORT=15001
PROXY_INBOUND_CAPTURE_PORT=15006
PROXY_TUNNEL_PORT=15008
PROXY_UID=1337
PROXY_GID=0,1337
INBOUND_INTERCEPTION_MODE=TPROXY
INBOUND_TPROXY_MARK=1337
INBOUND_TPROXY_ROUTE_TABLE=133
INBOUND_PORTS_INCLUDE=*
INBOUND_PORTS_EXCLUDE=15090,15021,8181,15020
OUTBOUND_IP_RANGES_INCLUDE=<IP_ADDRESS>/32
OUTBOUND_IP_RANGES_EXCLUDE=
OUTBOUND_PORTS_INCLUDE=50010,50020,50075,50070,50090,9000,8019,8480,8481,8485,2181,8030,8031,8032,8033,8088,8040,8041,8042,10020,19888,33911,8020,8082
OUTBOUND_PORTS_EXCLUDE=
KUBEVIRT_INTERFACES=
ENABLE_INBOUND_IPV6=false

ip -f inet rule add fwmark 1337 lookup 133
ip -f inet route add local default dev lo table 133
Writing following contents to rules file:  /tmp/iptables-rules-1611637611221538655.txt201772342
* nat
-N ISTIO_INBOUND
-N ISTIO_REDIRECT
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp --dport 15008 -j RETURN
-A ISTIO_REDIRECT -p tcp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -o lo -s <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 0 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 0 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d <IP_ADDRESS>/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8030 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8031 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8032 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8033 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8088 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8040 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8041 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8042 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 10020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 19888 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 33911 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp --dport 8082 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --uid-owner 1337 -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --gid-owner 0 -j RETURN
-A OUTPUT -p udp --dport 53 -m owner --gid-owner 1337 -j RETURN
-A OUTPUT -p udp --dport 53 -j DNAT --to-destination <IP_ADDRESS>:15053
-A POSTROUTING -p udp --dport 15053 -j SNAT --to-source <IP_ADDRESS>
COMMIT
* mangle
-N ISTIO_DIVERT
-N ISTIO_TPROXY
-N ISTIO_INBOUND
-A ISTIO_DIVERT -j MARK --set-mark 1337
-A ISTIO_DIVERT -j ACCEPT
-A ISTIO_TPROXY ! -d <IP_ADDRESS>/32 -p tcp -j TPROXY --tproxy-mark 1337/0xffffffff --on-port 15006
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A ISTIO_INBOUND -p tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 8181 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ISTIO_DIVERT
-A ISTIO_INBOUND -p tcp -j ISTIO_TPROXY
-A PREROUTING -p tcp -m mark --mark 1337 -j CONNMARK --save-mark
-A OUTPUT -p tcp -m connmark --mark 1337 -j CONNMARK --restore-mark
-I ISTIO_INBOUND 1 -p tcp -m mark --mark 1337 -j RETURN
COMMIT

iptables-restore --noflush /tmp/iptables-rules-1611637611221538655.txt201772342
Writing following contents to rules file:  /tmp/ip6tables-rules-1611637611969044794.txt772360989

ip6tables-restore --noflush /tmp/ip6tables-rules-1611637611969044794.txt772360989
iptables-save
# Generated by iptables-save v1.4.21 on Tue Jan 26 05:06:51 2021
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ISTIO_DIVERT - [0:0]
:ISTIO_INBOUND - [0:0]
:ISTIO_TPROXY - [0:0]
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A PREROUTING -p tcp -m mark --mark 0x539 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT -p tcp -m connmark --mark 0x539 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A ISTIO_DIVERT -j MARK --set-xmark 0x539/0xffffffff
-A ISTIO_DIVERT -j ACCEPT
-A ISTIO_INBOUND -p tcp -m mark --mark 0x539 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 8181 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ISTIO_DIVERT
-A ISTIO_INBOUND -p tcp -j ISTIO_TPROXY
-A ISTIO_TPROXY ! -d <IP_ADDRESS>/32 -p tcp -j TPROXY --on-port 15006 --on-ip <IP_ADDRESS> --tproxy-mark 0x539/0xffffffff
COMMIT
# Completed on Tue Jan 26 05:06:51 2021
# Generated by iptables-save v1.4.21 on Tue Jan 26 05:06:51 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ISTIO_INBOUND - [0:0]
:ISTIO_IN_REDIRECT - [0:0]
:ISTIO_OUTPUT - [0:0]
:ISTIO_REDIRECT - [0:0]
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A OUTPUT -p udp -m udp --dport 53 -m owner --uid-owner 1337 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -m owner --gid-owner 0 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -m owner --gid-owner 1337 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination <IP_ADDRESS>:15053
-A POSTROUTING -p udp -m udp --dport 15053 -j SNAT --to-source <IP_ADDRESS>
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A ISTIO_OUTPUT -s <IP_ADDRESS>/32 -o lo -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --gid-owner 0 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 0 -j RETURN
-A ISTIO_OUTPUT ! -d <IP_ADDRESS>/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j RETURN
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50010 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50075 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50070 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 50090 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 9000 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8019 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8480 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8481 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8485 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 2181 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8030 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8031 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8032 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8033 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8088 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8040 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8041 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8042 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 10020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 19888 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 33911 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8020 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -p tcp -m tcp --dport 8082 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -d <IP_ADDRESS>/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
-A ISTIO_REDIRECT -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Tue Jan 26 05:06:51 2021

So what do we do with this PR? I am still figuring out why runAsGroup as not being added in our environment even though injection template has it. Do we want to make uid and gid for the reasons @howardjohn mentioned or just rely on gid to skip?

So what do we do with this PR? I am still figuring out why runAsGroup as not being added in our environment even though injection template has it. Do we want to make uid and gid for the reasons @howardjohn mentioned or just rely on gid to skip?

Is this the capability uniquely lost in docker-shim CRI? Other CRI may support

No, I think none of them sets ambient capabilities. We can't rely on that.

Is this the capability uniquely lost in docker-shim CRI? Other CRI may support

No, I think none of them sets ambient capabilities. We can't rely on that.

@ramaraochavali the problem seems to be specific to your environment, so I would like to first understand what's going on there before we commit anything. Thanks!

@ramaraochavali the problem seems to be specific to your environment, so I would like to first understand what's going on there before we commit anything. Thanks!

@rlenglet Sure. That makes sense. I will update what I find here.

@rlenglet Sure. That makes sense. I will update what I find here.

I will close this PR for now and once we find what is causing runAsGroup not showing up and if it needs a fix, will open a separate PR.

I will close this PR for now and once we find what is causing runAsGroup not showing up and if it needs a fix, will open a separate PR.

@rlenglet @lambdai Update. The "runAsGroup" not setting per container seems to be problem with EKS. Our K8s team is a following up on that.
Another question - Do we really need to be "root" (runAsNonRoot: false)  for "TPROXY" or just "NET_ADMIN" is sufficient? I think since we are running as root, the gid is automatically set to 0 and since runAsGroup is not working as expected in our env, we are stuck with gid 0. If root is really not needed, removing that also would solve our case.

@rlenglet @lambdai Update. The "runAsGroup" not setting per container seems to be problem with EKS. Our K8s team is a following up on that.
Another question - Do we really need to be "root" (runAsNonRoot: false)  for "TPROXY" or just "NET_ADMIN" is sufficient? I think since we are running as root, the gid is automatically set to 0 and since runAsGroup is not working as expected in our env, we are stuck with gid 0. If root is really not needed, removing that also would solve our case.

root is needed. Again, adding capabilities doesn't work in container runtimes because they don't set ambient capabilities, so capabilities are lost when changing the uid. So uid 0 is required in order to preserve CAP_NET_ADMIN.

root is needed. Again, adding capabilities doesn't work in container runtimes because they don't set ambient capabilities, so capabilities are lost when changing the uid. So uid 0 is required in order to preserve CAP_NET_ADMIN.

@ramaraochavali Do you have any reference about runAsGroup not working on EKS?

@ramaraochavali Do you have any reference about runAsGroup not working on EKS?

@rlenglet No there is no reference any where. We could find by experiment and we did not get any response yet.

@rlenglet No there is no reference any where. We could find by experiment and we did not get any response yet.

@rlenglet Just closing loop on this, it turned out that there is a bug in one of the mutating webhooks that is running in our cluster is pinned to older version of client-go that does have "RunAsGroup" in the SecurityContext so was getting dropped during mutation. The webhook owner is fixing it. So It is not an AWS issue either.

@ramaraochavali awesome, thanks for looking deeper into this!


typo: analysisservices/resource-manager/Microsoft.AnalysisServices

Supends -> Suspends
enableing -> enabling
availibility -> availability

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

Can one of the admins verify this patch?


Custom settings are ignored

I am trying to install the chart into a local single node cluster for testing. I want external access, so I downloaded the default values.yaml, and set:
external:
  enabled: true
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  port: 8088

I now did:
helm install -f values.yaml confluentinc/cp-helm-charts

But when I do
kubectl get services

it outputs:
service/trendy-prawn-cp-kafka                ClusterIP   <IP_ADDRESS>   <none>        9092/TCP            74s
service/trendy-prawn-cp-kafka-connect        ClusterIP   <IP_ADDRESS>    <none>        8083/TCP            74s
service/trendy-prawn-cp-kafka-headless       ClusterIP   None             <none>        9092/TCP            74s
service/trendy-prawn-cp-kafka-rest           ClusterIP   <IP_ADDRESS>    <none>        8082/TCP            74s
service/trendy-prawn-cp-ksql-server          ClusterIP   <IP_ADDRESS>   <none>        8088/TCP            74s
service/trendy-prawn-cp-schema-registry      ClusterIP   <IP_ADDRESS>   <none>        8081/TCP            74s
service/trendy-prawn-cp-zookeeper            ClusterIP   <IP_ADDRESS>   <none>        2181/TCP            74s
service/trendy-prawn-cp-zookeeper-headless   ClusterIP   None             <none>        2888/TCP,3888/TCP   74s

Hence, it ignores the external setting in values.yaml.
What am I missing?
Followup 1
I tried:
helm install --set external.enabled=true confluentinc/cp-helm-charts

but it still uses ClusterIP instead of LoadBalancer.

Link #119

I'm actually not sure I see where external is defined
Have you seen this section?
https://github.com/confluentinc/cp-helm-charts/blob/master/charts/cp-kafka/README.md#external-access


Unable to run bob exercise: Missing option in Makefile

Hey everyone,
Thanks for coming up with these exercises. They are a great way to learn new languages.
I am experiencing a problem while trying to run the bob exercise.
This is the error I am seeing when trying to use the Str module in my solution:
+ ocamlfind ocamlopt -linkpkg -g -thread -package oUnit -package core bob.cmx test.cmx -o test.native
File "_none_", line 1:
Error: No implementations provided for the following modules:
         Str referenced from bob.cmx
Command exited with code 2.

In order for the make directive to run, I eventually found out that I have to modify the test.native directive of the Makefile to be:
test.native: *.ml *.mli
	@corebuild -r -quiet -pkg oUnit -pkg str test.native

I'm not sure if this is the correct solution, but it has worked for me.
Is there a way to give the users some direction on how to solve this in case it comes up or was I missing something all along?
Thanks in advance.

Hi @kevgathuku thanks for taking the time to report a problem you are experiencing. Exercism.io is meant to help people learn a new language. When anyone experiences problems the could be thrown of track, which would be unfortunate.
It is great to hear that you were able to solve your problem. If nothing else, your report could help others that are experiencing similar problems. The way you solved your problem is correct. In effect you have to tell OCaml build tool that you are using a module in your solution.
I totally agree that we could give users a helpful tip when they experience these kind of problems. Maybe you could suggest a hint that would have helped you?
In the meantime I will think of a good place for the actual hint.

I would suggest to give a hint how on how to solve these kinds of problems on the running the tests part of the OCaml track. @kevgathuku what do you think?

Hi @dvberkel thanks for your reply. It was frustrating to experience an error like this one and not have a place I could refer to. There wasn't a lot of useful information I could find online.
Including a tip would be extremely useful to other users in future, especially for this error.
I'm thinking it should be an extra section on it's own, with a sort of QA style of errors, their causes and common solutions. e.g. the format in this WIki page
I would really love to hear your feedback on that suggestion.
If you're okay with it, I can get started on it.

@kevgathuku I can relate to the frustration of a bug that when you just start out learning a language. I think you are right that a tip would help future users.
I think that a Wiki page would be beneficial, but I would like to ask @kytrinyx, because I am not sure what the exercism.io way would be.
None the less, starting with a draft of a tip can't hurt. Where it eventually end up is an other question.

Thanks @dvberkel. I'll start on it soon, as we wait for a response regarding where to put it.
For the Wiki link I included, this was to act a reference to how I think the content should be structured.

In the meantime I will think of a good place for the actual hint.

The best place for the hint would be a HINTS.md file in the exercise directory. This will be included in the README that gets delivered along with the test suite when people fetch the exercise.
exercises/bob/
├── Makefile
├── bob.mli
├── example.ml
├── HINTS.md
└── test.ml

@kytrinyx where would hints be placed when they are not exercise specific?

For hints that are general to the track, the SETUP.md file in the root of the repository will do what you need: https://github.com/exercism/xocaml/blob/master/SETUP.md

Hi @kevgathuku
How are you? Are you still interested in contributing your tips? Do you need any assistance?

Hi @dvberkel I'm still interested in contributing. I'll send my first draft soon and hopefully I can get some suggestions on making it better.

@kevgathuku Great! Looking forward to your contribution

I am closing this issue because @kevgathuku pull request #56 provides a useful hint that would solve the problem


commit_message_template does not have access to the labels list

https://docs.mergify.com/workflow/actions/copy/ the labels attribute is not available to commit_message_template:

labels
list of string
The list of labels to add to the created pull requests.

actions:
  queue:
    name: default
    method: squash
    allow_merging_configuration_change: true
    commit_message_template: |
      {{ title }} (#{{ number }})

      Approved by: @{{ approved_reviews_by | join(', @') }}

      Labels: {{ labels | join(',') }}

      {{ body }}

This is less of a bug and more of a feature request to have labels GH data exposed in the same way as approved_reviews_by is.

This would be extremely useful in persisting label attributes to the git commit message and to help in identifying things like breaking changes for https://www.conventionalcommits.org/en/v1.0.0/

This is exposed via label, not labels. We could probably add an alias though.

Thanks for the reply @jd, I should have tried the singular variant. Do you know where label is in the docs? I thought I looked thoroughly.

You can find the list of attributes here https://docs.mergify.com/configuration/conditions/#attributes-list

Wonderful, don't know why I wasn't able to hit on that list sooner, thanks for the response!


Theme colors

I see old issues about theme colors but the answers seem to be that it is resolved in beta 2. I upgraded to beta 2 and I cannot get theme colors to work. My file structure is to import individual BS files into main.scss. I have:
@import "bootstrap/functions"; @import "bootstrap/variables"; @import "_variables_custom.scss";
In my "_variables_custom.scss" file I have:
$brand-primary: 	#e95362; $theme-colors: ( 	"primary":    $brand-primary );
This code changes the primary color but wipes out all other colors in the theme-colors map. I have to redeclare all the color variables and the colors in the colors map to make it work.
Am I missing something?

Hi
i use like this way and work perfectly
// core bootstrap functions
@import "../scss/functions";
@import "../scss/mixins";
// variable overrides
@import "variables"; <== your variables (in wich you need the new grayscale and colors function...)
// full bootstrap
@import "../scss/bootstrap";
// style overrides if need
@import "xxxxx";

Hi @iantbarker, as @iantbarker mentions import your variables before Bootstrap's it's documented here:
http://getbootstrap.com/docs/4.0/getting-started/theming/#variable-defaults

Ah, my bad. Apologies.


Output log preview may fail if a input file > 32KB.

This PR is the temporary workaround about #476
This change output the following message in preview command.
Some users encounter the same issue.
This message may help for that users.
2017-03-15 21:11:55.609 +0900 [INFO] (0001:preview): Preview read a sample from the first file up to 32KB. It may raise an exception if input file larger than 32KB.
2017-03-15 21:11:55.609 +0900 [INFO] (0001:preview): See also: https://github.com/embulk/embulk/issues/476

I'm not sure why this test failed on Travis.
I tried the same test on my environment.
I met the same error Out of memory once.
After that, I tried it three or four times.
All of the tests passed.
Is this my code problem?

@hiroyuki-sato Sorry, I was missing this PR. Now working on https://github.com/embulk/embulk/pull/572. Does my PR work for you, https://github.com/embulk/embulk/pull/564 and https://github.com/embulk/embulk/issues/476? Please let me know if you have any concerns.

@hiroyuki-sato Can we close this ticket? Because I think that this is duplicated with https://github.com/embulk/embulk/pull/572.

@muga OK thanks.


Quick fix for (at least) Sonoma on ARM

configVars = """
window-title Stormfront 3D Radar Viewer
icon-filename assets/icon/icon.ico
gl-version 3 2
"""

if __name__ == "__main__":
    loadPrcFileData("", configVars)

    base = ShowBase()
    app = App(base)
    base.run()

The gl-version 3 2 was needed to get past shader error: ERROR: shader/vertex.glsl:1: '' :  version '330' is not supported
I just found this repo (good timing, because I'm in a nasty weather zone this evening!) and you're building something I've wanted to build for a long time. Are you looking for PRs?

@spdustin Unfortunately setting gl-version 3 2 breaks a few other effects like clip planes and LineSegs thickness so I don't want to commit it to main just yet but I have a branch https://github.com/jtfedd/3d-radar/tree/mac-support which is fairly up-to-date (and could easily have main merged in) if you would like to use that for now!

Awesome to see this merged, thanks!


for cordova or js

why they are only for native ios or android?  is there a js sdk available ? I am specifically looking for firebase object detection and tracking to capture most prominent object using phone camera without manually tapping a button

The JS quickstart can be found here: https://github.com/firebase/quickstart-js

This is just firebase quick start.  Nothing to do with object detection api sdk

ML Kit doesn't have a web component. You'll have to write native code and bridging calls to your hybrid app's JS layer.


[SwiftTestTool] Add support for parallel test execution

This is an awesome idea, thanks for working on it!! I'm curious, though: what does the output look like when running tests in parallel?

@modocache its jumbled right now but I hope to add a progress bar like lit uses.

@aciidb0mb3r I finished reading through the diff -- excellent work!
What do you think about moving the parallelization down into swift-corelibs-xctest? Wrapping the output of XCTest is one option, but I think that duplicates some effort, and complicates some aspects of the output.
For example, XCTest allows users to specify an output formatter. Would SwiftPM swallow their output? Would SwiftPM provide an output formatter to customize its progress bar output? Would third-party tools like xcpretty begin parsing the SwiftPM --parallel output?
XCTest seems like it could parallelize running of each test case provided to XCTMain, based on the presence of a command-line argument. It could also ensure that logs related to the start and end of a test bundle are printed out properly.

I think it would make sense to have parallelism in swift-corelibs-xctest but then we can't add the same option in macOS XCTest.
As for progress bar I would imagine it should be possible to have different kind of output based on requirements and terminal limitations for eg you can't have a progress bar if you're piping the output to a file.
@ddunbar can probably chip in with more thoughts

Speaking of macOS: Apple XCTest uses XPC to communicate with Xcode, and with iOS simulators/devices when running host tests. I'm not certain, but I think there would be complications if one were to attempt to run several XCTest processes in parallel. I've seen tools that work around these limitations, but ultimately I think it's something Apple developer tools teams need to deal with. I'm concerned that a SwiftPM-based approach could run into some of the same issues if SwiftPM was ever used as a build tool for projects that used UIKit.
Still, parallel execution seems like it would be fantastic to have. Because of the reasons above, I'd like to ask @mike-ferris-apple whether this approach works for macOS. Regardless, it certainly seems possible on Linux, but my viewpoint is that, if we're to implement it on Linux, the most elegant solution would be to have swift-corelibs-xctest handle it.
Anyway, just my two cents -- would definitely love to hear other opinions, especially some from Apple employees.

@mike-ferris-apple @ddunbar Friendly ping! Also /cc @briancroom in case he has any thoughts here. :)

I'm out on vacation, so this is a somewhat terse grab bag of comments:

I don't think we need to move the parallelism into XCTest, for several reasons:

As @aciidb0mb3r noted, we don't have a unified implementation.

XCTest's API itself isn't designed to be parallel, and I think it is quite hard to implement any consistent semantics for it without changing the API or using multiprocess based parallelism.

I personally want parallelism in tests to be the default for SwiftPM. I think it is a great fit for a new ecosystem to encourage people to have fast running and idempotent tests. However, I think we also need to run this through the proposal process in some form because there are tradeoffs and concerns (for example, this can make tests much slower if setUp and tearDown are very expensive, it also can make things harder to debug and we should have clarity on our approach).

I am fine staging in an implementation which is off by default.

I do think we should build all the infrastructure we need first rather than just get an implementation which works but isn't production quality. The things missing here are:

We need more infrastructure for handing the output buffering of tests and reporting the test failures. The individual XCTest reports will now have a lot of noise, and shouldn't be shown individually I don't think.

We will need a little more sophistication in the parallel dispatching of tests to handle the above, because we will need conceptual separate tasks for dispatching all of the tests, executing them in parallel, and then aggregating and reporting the results.

Thanks for the comments! I'd love to have this go through the evolution proposal process -- I think the implementation of this feature has significant consequences for XCTest and other testing frameworks. Last I read, we hadn't worked out SwiftPM integration with testing frameworks other than XCTest. How we expect parallel execution to work seems like something that would impact those integrations.

I don't think we need to move the parallelism into XCTest, [...] XCTest's API itself isn't designed to be parallel

This makes sense to me. But all the more reason to clearly define how SwiftPM expects parallelizable testing frameworks to behave.

I am fine staging in an implementation which is off by default.

If so, I'd prefer it be clear that the feature is experimental. --experimental-parallel-execution or something.

We need more infrastructure for handing the output buffering of tests and reporting the test failures.

One idea: Test frameworks typically allow observers to be registered dynamically, such as via the command line. For example, Apple XCTest allows custom XCTest observers to be registered via a plist:

If an NSPrincipalClass is declared in the test bundle’s Info.plist, XCTest automatically creates a single instance of that class when the test bundle is loaded. This instance provides a means to register observers or do other pretesting global set up.

How about the following:

We add a similar mechanism to specify custom formatters at runtime (not compile-time) to swift-corelibs-xctest. Perhaps corelibs-xctest parses a --formatters command-line argument that allows custom formatters to be registered.
SwiftPM uses the Apple XCTest and corelibs-xctest APIs to register formatters that report the results of tests back to SwiftPM somehow. This could obviate the need to do textual parsing of XCTest output.

@modocache I'm not sure I buy into going through formatters for the initial pass of this... we wouldn't need to parse the output of XCTest if we are just running one test at a time and looking for PASS/FAIL. Was there a reason you expected we would need it?

Closing this PR for now till we get all the infra in place. Thanks @modocache and @ddunbar for comments.

we wouldn't need to parse the output of XCTest if we are just running one test at a time and looking for PASS/FAIL

If a test fails, what would we display to the user? Without parsing the output, wouldn't we be forced to print out "A test failed, but we don't know which one"? Let me know if I'm misunderstanding something here.

Well, I have found the lit behavior of hiding the test output by default, but just showing the full XCTest log output if a test fails to be perfectly acceptable.

If the tests are run in parallel, that output could end up being pretty confusing: we'd end up with a bunch of "Test Suite X started" and "Test Case Y failed" statements interspersed with one another.
I agree that would probably be acceptable for the most part. I might be focusing too much on what I consider to be the ideal -- something that allows people to still have reasonable test output, even when they're run in parallel, and even if they're using their own test formatters -- but I think it's worth discussing.

The way lit handles it is that the tests are run in parallel, but the status is queued and reported serially -- I hadn't really considered any other model for reporting the status of parallel tests for exactly the reason you mentioned, interleaved output is confusing.

That is very cool. I could definitely see the same working here -- so yeah, I think you're right, formatters might be unrelated here. Thanks for the explanations!


Test(e2e): Enable Modal visual testing using v3 tokens

Description

Additional context

Issue reference

coverage: 78.791% (-18.0%) from 96.838%
when pulling 2fda13c2abcb93e412a50216385b384c1fbc891d on test/modal-v3
into a4baaa70469c6968f79ce77929e114ebf7d8a320 on integration/BC-v3-design-tokens.


restore timestamps in delta compression

also fixes #235 (the receiving*10s feature)

I am not sure if deleting the timestamps on the client side is a good idea. ISTR that stats for ended tracks would be kept around but the timestamp would never increase.

the code can now deal with clients that do not remove the timestamp.


BACKPORT: Add nodev to options of bind mounts from kube

Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>
- What I did
- How I did it
- How to verify it
- Description for the changelog

/test all

Looks the repo change not accounted for in 1.9: Expected cri-o to be cloned at /go/src/github.com/kubernetes-incubator/cri-o but it wasn't!
https://github.com/kubernetes-sigs/cri-o/blob/release-1.9/contrib/test/integration/build/cri-o.yml#L5

https://github.com/kubernetes-sigs/cri-o/pull/1852 should fix the build issue.

#1852 is in. Rebasing this should make the tests pass :)


improved code readability

@maxpv026
Thanks for taking the time to open this PR! We've added this to our backlog, pending to be reviewed.


Nonparametric version of ComBat in R

From email: Hello,
I am applying the ComBat software to a multisite harmonization question. I have seen mentions of ComBat being available in both parametric and non-parametric versions. Is the version available on GitHub parametric or non-parametric?

The non-parametric version has now been added in R. Thanks!


feat(core): add core command module

Codecov Report
Attention: 15 lines in your changes are missing coverage. Please review.

Comparison is base (1be7c45) 97.43% compared to head (942c04e) 76.19%.

Files
Patch %
Lines

core/src/main.rs
0.00%
12 Missing :warning:

core/src/error.rs
72.72%
3 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main      #12       +/-   ##
===========================================
- Coverage   97.43%   76.19%   -21.25%
===========================================
  Files           1        3        +2
  Lines          39       63       +24
===========================================
+ Hits           38       48       +10
- Misses          1       15       +14

Flag
Coverage Δ

integration
26.47% <26.47%> (-48.53%)
:arrow_down:

unit
94.11% <94.11%> (-3.32%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Added identification of charset to read sql file

┆Issue is synchronized with this Jira Story by Unito

Sorry for my English.
In my project it was necessary to set the endDelimiter for the rollback and can read sql file with ANSI encoding.
So it was added a jar to identify charset of the file at the time of reading and so treat properly.

I'd rather not add the dependency on any23 and tika, I'll have to look at how difficult it would be to implement on it's own.

Hi @tharsissantana ,
Would you consider resolving branch conflicts and adding tests for this PR?  Here's some guidance on that below:
Thanks for your pull request!
Here’s what happens next:
A member of the Liquibase team will take a look at your contribution and may suggest:

Changes based on guidelines for PR submission
Additional tests (unit and/or integration)
Provide other feedback, like requesting changes.

The PR will be prioritized according to our internal development and testing capacity.
We’ll let you know when it’s ready to move to the next step or if any changes are needed.

Hello! It has been a long time since this has been proposed and Liquibase tried different ways of handling file encodings in the meantime. So the way to specify a file encoding is using "--file-encoding" parameter, and changing that could cause issues with checksums .
Anyway thanks for the PR @tharsissantana ! If you have any concerns or other ideas please feel free to reopen it.


add libflate

This PR addresses #60. It adds new target that uses a pure rust implementation of deflate: libflate.
I think this works. I tested this by running the tests and a few of the examples compiled for the new libflate target. I also tested it with default features to make sure I didn't break anything. I did all this on Windows.
To build the new target:
> cargo build --no-default-features --features sile-libflate

I am open to nit-pick and style changes.

@mvdnes can this be reviewed?
My main use case is targeting web assembly. I have noticed different strategies for conditionally compiling target specific dependencies. This repository uses the named features so I continued doing that with sile-libflate feature.

Thank you for your contribution.
The first thing that springs to my attention is that this confuses the compression algorithm (8 = deflate) with the implementation of the encoder/decoder (flate2 / sile-libflate). I do not think this change warrants a new CompressionMethod.
I might be tempted to replace the old flate2 with this library, as this would ease things on multiple platforms.

I made it another CompressionMethod because I think some developers would prefer the flate2 backend. I did not consider the confusion and I acknowledge it now.
flate2 is working on support for wasm. I have no idea when that will be completed.
Adding libflate makes sense for me because I want to use zip-rs in my wasm projects. It is also a dependency in ~50 other registered crates on crates.io.
I can't speak to the performance differences. So far, the libflate CompressionMethod has been meeting my expectations in my personal projects.

The feature name libflate is fine, but I would rather have the enum values still be called Deflated (named after the algorithm) rather than Libflate (named after the implementation).
Also I would like the default features to include both compression methods.

Thanks for all the work!
I am going to review some more of the public interface before publishing the 0.5.0 version, but hope to do that soon!

Seeing as libflate is more 'self-contained' I think it would be beneficial to the project to use just that. This would also be a good time to remove all the (possibly confusing) features of different flate flavours.

@mvdnes while having a pure-rust implementation for deflate as a default is a step forward a clear no-brainer, removing optional flate2 backend, in my opinion, is suboptimal. Before that one could use flate2's capability to use and link to system zlib, now this is gone. Could we bring flate2 as an optional backend back?

@mvdnes

@mvdnes would you be interested in opening an issue for the plugin system? I am interested in following the progress and maybe helping if I can.


Request: Placeholder Layouts

"Placeholder" layouts for bricks should be supported, so that we can easily update bricks which have no data. For clarity, placeholder layouts would appear similarly to the layouts specified in https://github.com/tulios/placeholder_shimmer.
Currently, creating a nice placeholder layout requires a lot of manipulation of XML to get consistent UI in both the empty and full states.

This has been addressed by https://github.com/wayfair/brickkit-android/pull/89, closing


feat(frontend): toggle addresses

Motivation

Changes

Tests

Discussed offline we are not going to implement this now as the feature, filtering the addresses, lead to some other questions.


Try different encrypted bintray-related env variables for Travis

The initial ones failed for some reason.

@jonlee2 Can you try to re-run the build a second time to see whether the 2nd run still works?

@jonlee2 Can you try to re-run the build a second time to see whether the 2nd run still works?

The problem is that these encrypted env variables are used only during deploy (i.e., publishing artifacts) and running another build on PR doesn't really test anything. Moreover, PR builds remove those encrypted env variables for security reasons. Based on my understanding, whether it works or not can be only determined after the PR gets submitted and a new release is created.


Remove the special Docker relative links support

See https://github.com/docker/docker.github.io/issues/717

This issue has been automatically marked as stale because it has not been commented on for at least six months.
The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.


It is not working for sub-folders

Hello,
It seems it works only for the root folder of the repository. Is there a way to enable all readme.md to become index.html in all folders? (I'm using Github pages)

This is working for me (e.g. https://qwtel.com/hy-drawer/usage/ <--> https://github.com/qwtel/hy-drawer/tree/master/usage).
Problem could be that the subdir already has a index.html file in it?
I'm also using the remove original setting
readme_index:
  remove_originals: true

Hi @qwtel ! I'm a bit confused, it works in one of my subfolders, but not in all.  I tried adding the remove_originals option, it didn't make a difference. The only option which worked was hard-coding index.html in the permalink, but I guess that defeats the purpose ;)
This is the readme: https://github.com/haschdl/generative/blob/master/p5jsFlashlight/readme.md

Hello @qwtel
It worked only after I removed the front matter completely - including the double three dashes, which Githubs documentation says is required. Could you confirm this is the expected behavior?

That's probably due to jekyll-optional-front-matter which is activated on GitHub Pages by default.

I can also verify that this works for sub folders when one removes the front matter from the README.md file completely. Would anyone know what we could do to make this work with Front Matter?
Best Regards!


[BUG] Occassional STDERR Console Spam

What happened?

Once every hour or so I'll get the following error messages in my server console:
[01:46:44] [JDA MainWS-ReadThread/INFO] [STDERR]: [net.dv8tion.jda.internal.utils.SimpleLogger:write:277]: [JDA MainWS-ReadThread] WARN WebSocketClient - Got disconnected from WebSocket. Attempting to resume session
[01:46:46] [JDA MainWS-ReadThread/INFO] [STDERR]: [net.dv8tion.jda.internal.utils.SimpleLogger:write:277]: [JDA MainWS-ReadThread] INFO JDA - Successfully resumed Session!

What should happen?

Seeing as it's only a disconnect for a second or two, I'd rather it only notify me if it got disconnected and was not able to reconnect for at least a minute. Maybe make the time configurable?

Steps to reproduce

Boot up a server
Let it run for an hour or two
Error message about getting disconnected from WebSocket will appear and then a few seconds later it will say it successfully resumed session. (if you leave it running overnight you'll see the error messages 5-8 times)

Version
Minecraft 1.12.2
Forge <IP_ADDRESS>47
DiscordIntegration-1.1.15 (MC 1.12)
Config file
Discord-Integration.txt

There is no way for disabling that log as JDA has that hardcoded without any option to disable it.
This is where the log comes from:
https://github.com/DV8FromTheWorld/JDA/blob/master/src/main/java/net/dv8tion/jda/internal/requests/WebSocketClient.java#L473


refactor: remove hardcoded versions for PlayFabParty and DepotDownloader

As you've mentioned in #54, we may need an update for PlayFabParty, so this would make changing the versions for both PlayFabParty and DepotDownloader easier.

Thanks! 🥳 Could you drop the DepotDownloader bits? There's hopefully no need to differentiate how we download depots from Steam between the stable and beta branches.

Yeah, I didn't think that there would be need to differentiate how we download depots for both branches. But I thought about changing the version of DepotDownloader sometime due to https://github.com/SteamRE/DepotDownloader/issues/450. And with this it would involve only changing the version and hash once, instead of changing the version 9 times and the hash once.
But if you think that it's unnecessary, I will drop it.

Ah, that makes a lot of sense, all good! 🥳


Initial animation not working for AreaSeries

I've created a AreaSeries with initial data having y=0.
I'm looking to get a flat line on the lower side of the container initially which animates to the new data. (https://dribbble.com/shots/2663183-Allo-Transition)
Animation only seems to work if any y is different than 0.
initial data: [{x: 0, y: 0},
{x: 1, y: 1},
{x: 2, y: 0},
{x: 3, y: 0},
{x: 4, y: 0},
{x: 5, y: 0},
{x: 6, y: 0},
{x: 7, y: 0},
{x: 8, y: 0},
{x: 9, y: 0},
{x: 10, y: 0}],
};
later data: [{x: 0, y: 10},
{x: 1, y: 11.159580307617771},
{x: 2, y: 11.51571947405475},
{x: 3, y: 13.043424572745293},
{x: 4, y: 13.28371953411036},
{x: 5, y: 15.5829192197358},
{x: 6, y: 16.708165989757745},
{x: 7, y: 17.08147485826039},
{x: 8, y: 20.313219401650827},
{x: 9, y: 21.164376063787643},
{x: 10, y: 21.931676414677234}]

I think this might be a bug in the way that the animation component handles initialization. Bug noted!