https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162016-08-18T21:12:22ZpfSense bugtrackerpfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=286512016-08-18T21:12:22ZMatt Williams
<ul></ul><ul>
<li>Amending previous post to remove item number 3, reducing FR to one correction and one enhancement. API will only attempt to change fields in request, so geolocation configuration is not required and does not belong in the application; this will remain an AWS configuration item.</li>
</ul>
<p>However, SetIdentifier is still required to perform a successful record set lookup and update.</p>
<p>M</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287162016-08-25T21:05:06ZJason McCormick
<ul></ul><p>I'm interested in this bug now too as I've just discovered that 2.3.2 + AWS Route53 is inoperable. With 2.3.2 I can no longer use AWS Route53 for dynamic DNS at all. I am assuming that the old API the r53.class file is using is no longer present but there doesn't seem to be any debugging output I can enable to verify that. However /etc/rc.dyndns.update will not create a new record nor will it update one. But in both cases, the system believes that it did.</p>
<p>I'd be happy to test any code that fixed this, either as part of this issue or <a class="issue tracker-1 status-3 priority-5 priority-high4 closed" title="Bug: Route 53 dynamic DNS provider fails to update record (Resolved)" href="https://redmine.pfsense.org/issues/3973">#3973</a>.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287172016-08-25T21:07:01ZJason McCormick
<ul></ul><p>Also, I think this tracker type should be bug not feature? I see it tagged for 2.3.3 but as "Feature". In my testing, DynDNS + AWS Route53 is broken.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287182016-08-25T21:20:10ZMatt Williams
<ul></ul><p>The previous version works for me on a non-policy subdomain. What type of permission policy do you have set in IAM for the update user?</p>
<p>Here's the wrench; the r53.class uses the 10-1-2010 API version, which doesn't support recordset modification with the SetIdentifier attribute. See link for details:</p>
<p><a class="external" href="http://docs.aws.amazon.com/Route53/latest/APIReference/api-change-resource-record-sets-old-versions.html">http://docs.aws.amazon.com/Route53/latest/APIReference/api-change-resource-record-sets-old-versions.html</a></p>
<p>I've already made the change to include the UPSERT action, which handles creation and updates. Need someone from pfsense to speak up here and give some guidance on external open source implementations so I don't have to reinvent the wheel. Once the class is updated, I can include the secondary enhancement. Otherwise, I will reduce scope here and only request the UPSERT action.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287192016-08-25T22:31:45ZJason McCormick
<ul></ul><p>Matt Williams wrote:</p>
<blockquote>
<p>The previous version works for me on a non-policy subdomain. What type of permission policy do you have set in IAM for the update user?</p>
</blockquote>
<p>The IAM user has full Route53 permissions (AmazonRoute53FullAccess). If I look at the IAM users' API key, it will not mark as having been used whenever I click on the force update.</p>
<p>Matt Williams wrote:</p>
<blockquote>
<p>I've already made the change to include the UPSERT action, which handles creation and updates.</p>
</blockquote>
<p>I tried to hand-edit the file as listed in <a class="issue tracker-1 status-3 priority-5 priority-high4 closed" title="Bug: Route 53 dynamic DNS provider fails to update record (Resolved)" href="https://redmine.pfsense.org/issues/3973">#3973</a> but it did not work for me. Do you have example code/diff I could try?</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287202016-08-25T22:50:28ZJason McCormick
<ul></ul><p>Just to confirm my issue was not an IAM Policy problem, I gave my IAM user full permissions and created a new record in PFsense that didn't exist before and still no access. The IAM access time for the API key did update in the interim (and sans Admin access) but it matches a timestamp for updating the existing record not making any modifications (forced or otherwise).</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287282016-08-27T21:08:58ZMatt Williams
<ul></ul><p>Diff file:</p>
<p><a class="external" href="https://github.com/williamsmt/pfsense/commit/d96a547cc722d04880d50f7b6a1308c0d9575123">https://github.com/williamsmt/pfsense/commit/d96a547cc722d04880d50f7b6a1308c0d9575123</a></p>
<p>This works for me as of this evening. I will continue development before requesting a pull, but it should get you and going. For reference, this is what your IAM security policy should look like:</p>
<p>{<br /> "Version": "2012-10-17",<br /> "Statement": [
{<br /> "Effect": "Allow",<br /> "Action": [<br /> "route53:ListResourceRecordSets" <br /> ],<br /> "Resource": "arn:aws:route53:::hostedzone/{zone}" <br /> },
{<br /> "Effect": "Allow",<br /> "Action": [<br /> "route53:ChangeResourceRecordSets" <br /> ],<br /> "Resource": "arn:aws:route53:::hostedzone/{zone}" <br /> },
{<br /> "Effect": "Allow",<br /> "Action": [<br /> "route53:GetChange" <br /> ],<br /> "Resource": "arn:aws:route53:::change/*" <br /> }<br /> ]<br />}</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287292016-08-27T21:09:51ZMatt Williams
<ul></ul><p>Looks like formatting messed up the JSON encoding on that policy; be sure syntax is correct before using; {zone} = your ZONE ID</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287402016-08-29T19:48:46ZJason McCormick
<ul></ul><p>Does this require an updated r53.class file? Keeping what looks like an unmaintaned (upstream) legacy file seems like the wrong way to solve this permanently, especially since it's using the very old API and maintains a lot of methods that are unnecessary to pfSense. Doing a single UPSERT action and checking the response is a trivial amount of code that could really clean up the r53.class.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287412016-08-29T21:52:57ZJason McCormick
<ul></ul><p>I started looking through the dyndns.class and the Route53 is really non-standard for how pfSense is trying to do this. I forked a copy of the code and am rewriting it clean to live within dyndns.class. I'll post results when I finish it (hopefully tomorrow). Have the code written but need to test now.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287432016-08-30T15:41:33ZMatt Williams
<ul></ul><p>I agree; r53.class is overkill compared to the updated API. I've been busy at work and haven't finished rewriting. If you want someone to test it with you, I'll volunteer.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287442016-08-30T18:34:27ZJason McCormick
<ul></ul><p>Okay. I'm hoping to finish the original replacement code tonight and I will pass along a GitHub repo. I guess a different issue would be in order for replacing the class and fixing the current issues and leave this as the feature add?</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287452016-08-30T21:10:42ZJason McCormick
<ul></ul><p>The code is at <a class="external" href="https://github.com/jxmx/pfsense/commit/cc5adcaa679686e54e4035fa5bc283b1cac085a2">https://github.com/jxmx/pfsense/commit/cc5adcaa679686e54e4035fa5bc283b1cac085a2</a>. The code has an AWS signing key error. Getting the AWS keys to work is finicky. I also opened a new issue for replacing the r53.class.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=287472016-08-30T21:51:57ZJason McCormick
<ul></ul><p>Figured out my bug and an XML tag error. This now works so far in my testing - <a class="external" href="https://github.com/pfsense/pfsense/compare/master...jxmx:6751_route53">https://github.com/pfsense/pfsense/compare/master...jxmx:6751_route53</a>. I've opened 6751 for the replacement of r53.class.</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=289322016-09-23T10:23:06ZJim Pingle
<ul><li><strong>Target version</strong> changed from <i>2.3.2-p1</i> to <i>2.4.0</i></li></ul> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=298002016-12-07T07:45:48ZRenato Botelhorenato@netgate.com
<ul></ul><p>Matt, you mentioned you submitted a Pull Request, what is the #?</p> pfSense - Feature #6728: Route53 API mod and Geolocationhttps://redmine.pfsense.org/issues/6728?journal_id=300252016-12-20T10:35:15ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Needs Patch</i></li><li><strong>Target version</strong> changed from <i>2.4.0</i> to <i>Future</i></li></ul><p>Target to future while we wait for the patch</p>