awless show error: invalid literal object

[taraspos]

Hello, I'm trying to describe CloudFormation stack with awless show <arn> and getting next error:

[error] file '/Users/<user>/.awless/aws/rdf/default/us-east-1/cloudformation.nt': lenient parsing: line 1: invalid literal object

[simcap]

@Trane9991 thanks for reporting. Can you give me the content of:

head /Users/<user>/.awless/aws/rdf/default/us-east-1/cloudformation.nt

... basically the beginning of the file that causes the parsgin issue. I know where it comes from, I just need to see the content to be able to have a fix.

[taraspos]

Hey here is the output of head with some values replaced:

<arn:aws:cloudformation:us-east-1:000000000000:stack/name-1/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx> <cloud:outputs> <faffb762> .
<faffb762> <cloud:value> "vpc-xxxxxxxx" .
<452f83d7> <cloud:keyName> "KeyName" .
<f1c2b067> <rdf:type> <cloud-owl:KeyValue> .
<arn:aws:cloudformation:us-east-1:000000000000:stack/name-2/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx> <cloud:outputs> <799fcb0d> .
<us-east-1> <rdf:type> <cloud-owl:Region> .
<79a81f3e> <cloud:keyName> "ALBListener80" .
<79a81f3e> <cloud:value> "arn:aws:elasticloadbalancing:us-east-1:000000000000:listener/app/name/xxxxxxxxxx/xxxxxxxxx" .
<76050a0e> <cloud:keyName> "ECSCluster" .
<8f401d09> <rdf:type> <cloud-owl:KeyValue> .

[simcap]

Actually you would need to leave all the characters as they are - especially the non letter's ones - with no replacement since this will be a special character that will causes the issue. So far I am able to parse the first line fine.

So if it is not sensitive information just leave as it is (otherwise replace all letters by an random letter if needed).

[taraspos]

@simcap hey, actually I was able to determine the problem. It is multiline string created in CloudFromation Output

<39c1e0c6> <cloud:value> "AWS_ACCESS_KEY_ID=some-test-key
AWS_SECRET_ACCESS_KEY=some-secret-test-key
AWS_REGION=us-east-1" .

CloudFormation lines causing this:

Outputs:
  TestUserKeys:
    Value: !Sub |
          AWS_ACCESS_KEY_ID=${TestKey}
          AWS_SECRET_ACCESS_KEY=${TestKey.SecretAccessKey}
          AWS_REGION=${AWS::Region}

[simcap]

Nicely spotted.

Our library triplestore is very lenient on the parsing to allow a large range of input usually created on cloud entries.

But the RDF NT (triples) format does not support multi-line as content. So not sure what to do yet.

[taraspos]

@simcap maybe newlines could be escaped?

Example:

<39c1e0c6> <cloud:value> "AWS_ACCESS_KEY_ID=some-test-key\nAWS_SECRET_ACCESS_KEY=some-secret-test-key\nAWS_REGION=us-east-1" .

[simcap]

Yes that is the main solution. I will have to look at it more closely, starting tomorrow.

[varunchandak]

Even I am facing this issue:

root@varun-automation: ~:# awless -p XXXXX -r ap-south-1 show i-iwyf92384g8274
[error]   file '/root/.awless/aws/rdf/XXXXX/global/cdn.nt': lenient parsing: line 443: invalid literal object
root@varun-automation: ~:#

[mindw]

Same here:

<arn:aws:cloudformation:eu-west-1:[[removed>]]stack/[[removed]]> <cloud:description> "AWS CloudFormation template to create a new VPC or use an existing VPC for ECS deployment in Create Cluster Wizard. Requires exactly 1 Instance Types for a Spot Request.
" .

Will cause the error. deleting the newline before ". solves the issue.

[simcap]

@mindw @varunchandak @Trane9991

Ok. Thanks. I should get on it. I had other priorities last week, but I will try to upgrade our triplestore library so that it takes into account new lines in literal string object.

[varunchandak]

What i observed in my case (cloudfront) was the comment in 1 distribution had only 1 line, but multiple enter keys (or carriage returns), resulting in three lines.

Probable Example:

test comment in cloudfront

[simcap]

Ok. Thanks @varunchandak . If this value is a string literal object in the triple line this should be covered by the fix.

[simcap]

@mindw @varunchandak @Trane9991 A fix in now in master: RDF string literal object (the last part of a triple basically) now escape/unescape new lines.

1. Install the latest master with a go get -u github.com/wallix/awless or else
2. Perform a manual sync awless sync in the region and/or profile where you had the corrupts records. (You can either first awless switch ... to the region/profile or do it on the fly with awless sync -r my_region {-p my_profile]
3. The sync should have then overriden all records and you are now able to read properly every records and display all data correcly.

Let me know if that fixes the issue! Thanks.