Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Use run_command to execute iptables #1944

Merged
merged 4 commits into from
Jul 14, 2020
Merged

Conversation

narrieta
Copy link
Member

iptables was using the deprecated run/run_get_output functions

@codecov
Copy link

codecov bot commented Jul 13, 2020

Codecov Report

Merging #1944 into develop will increase coverage by 0.05%.
The diff coverage is 85.13%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1944      +/-   ##
===========================================
+ Coverage    69.56%   69.62%   +0.05%     
===========================================
  Files           85       85              
  Lines        11907    11926      +19     
  Branches      1673     1667       -6     
===========================================
+ Hits          8283     8303      +20     
- Misses        3252     3254       +2     
+ Partials       372      369       -3     
Impacted Files Coverage Δ
azurelinuxagent/common/osutil/default.py 58.92% <85.13%> (+1.02%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5aaf880...420a47d. Read the comment docs.

rc = shellutil.run_command(rule)
except CommandError as e:
if e.returncode == 1:
return
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is a returncode of 1 not an error? Should we document this as a comment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I image the code was written like this to avoid flagging an error if the rule does not exist, though this is not very robust.
I was tempted to change the logic, but at the end decided against it. I am not sure about the intention of the loop either.

FIREWALL_DROP = "iptables {0} -t security -{1} OUTPUT -d {2} -p tcp -m conntrack --ctstate INVALID,NEW -j DROP"
FIREWALL_LIST = "iptables {0} -t security -L -nxv"
FIREWALL_PACKETS = "iptables {0} -t security -L OUTPUT --zero OUTPUT -nxv"
FIREWALL_FLUSH = "iptables {0} -t security --flush"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happened to this command?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see it's not being used anywhere else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

# Transient error that we ignore. This code fires every loop
# of the daemon (60m), so we will get the value eventually.
return 0
logger.warn("Failed to get firewall packets: {0}", ustr(e))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We didn't use to log in this case. Can this be too verbose?

Copy link
Member Author

@narrieta narrieta Jul 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we did: run_get_output logs by default (that's why I had to add the "expected_errors" stuff in the old function)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I saw log_cmd=False in the old function and interpreted it as not logging the error, whereas that's the chk_err flag.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, those 2 flags are confusing

])
self.assertFalse(osutil._enable_firewall)
with TestOSUtil._mock_iptables() as mock_iptables:
delete_conntrack_accept_command = mock_iptables.set_command(osutil._get_firewall_delete_conntrack_accept_command(mock_iptables.wait, mock_iptables.destination), exit_code=2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this an invalid rule? It's the one we phased out after 2.2.25?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is confusing, I'll add a comment.

The test tries to hit the path where we check for exit code 2 (invalid rule), but the agent uses only only valid rules, so the mocked command specifies a valid rule, but the return code indicates invalid. When I ported the tests I thought this was odd; should have added a comment then.

Copy link
Member Author

@narrieta narrieta Jul 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, in the previous version of the code this was not apparent, since the mock was using magic (deep knowledge of the impementation) and mocks like this:

        mock_run.side_effect = [2]	
        mock_output.side_effect = [(0, version), (1, "Output")]

''')]
dst = '168.63.129.16'
''')
self.assertEqual(32, osutil.DefaultOSUtil().get_firewall_dropped_packets('168.63.129.16'))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should use 'destination'

Copy link
Contributor

@larohra larohra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the code refactoring and test improvements!

@narrieta narrieta merged commit 0edea53 into Azure:develop Jul 14, 2020
@narrieta narrieta deleted the iptables branch July 14, 2020 23:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants