Channel configuration update for adding new orgs - [Policy] /Channel/Admins not satisfied - hyperledger

I am building a network where I need that nodes will join throuhgout the lifetime of the application and as first implementation I want to change the channel configuration in order to change the policies regarding who needs to sign a configuration change.
Therefore I have followed correctly the procedure where I fetch the latest configuration block, I am decoding it and I am able to edit it in a JSON format.
{
"channel_group": {
"groups": {
"Application": {
},
"Orderer": {
}
},
"mod_policy": "Admins",
"policies": {
"Admins": {
"mod_policy": "Admins",
"policy": {
"type": 3,
"value": {
"rule": "ANY",
"sub_policy": "Admins"
}
},
"version": "0"
},
"Readers": {
"mod_policy": "Admins",
"policy": {
"type": 3,
"value": {
"rule": "ANY",
"sub_policy": "Readers"
}
},
"version": "0"
},
"Writers": {
"mod_policy": "Admins",
"policy": {
"type": 3,
"value": {
"rule": "ANY",
"sub_policy": "Writers"
}
},
"version": "0"
}
},
"values": {
},
"version": "0"
},
"sequence": "8"
}
So I have the above output and I change the rule of Admins policy to ANY (as it is changed).
And after that I encode it back to envelope and start signing.
I have 4 organizations currently and since the default rule is to sign the Majority of Admins I sign one by one with all organizations.
If I sign with only one or two organization Admins and submit the update I get the following error:
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'channel': error authorizing update: error validating DeltaSet: policy for [Policy] /Channel/Admins not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Admins' sub-policies to be satisfied
Which is very reasonable.
After 3 signatures out of 4, as Majority rule exists I get the following change in update and submit:
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'channel': error authorizing update: error validating DeltaSet: policy for [Policy] /Channel/Admins not satisfied: implicit policy evaluation failed - 1 sub-policies were satisfied, but this policy requires 2 of the 'Admins' sub-policies to be satisfied
So as we can see 1 of the sub-policies were satisfied but at this point it needs 2.
And here is the point where I am not understanding. What is the second sub-policy? And since I have signed with all the Admins of each organization, who else needs to sign this configuration channel update?
Thank you

After continuous research I found out that for this kind of update, by default the policy says that a MAJORITY of peer admins need to sign, but also a MAJORITY of orderer admins. Therefore the 2 'Admins' sub-policies!
Since I have one orderer organization, I exported the following environment variables, and used the same command for signing as before. You should not get confused by using the 'peer' command as an orderer.
The peer is the node that sends to the orderer node and the orderer is who creates the block and distributes it. It is just as using another user with the peer command.
export ORDERER_GENERAL_TLS_ENABLED=true
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/network/organizations/ordererOrganizations/authorizer/orderers/orderer.authorizer/msp/tlscacerts/tlsca.authorizer-cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/network/organizations/ordererOrganizations/authorizer/users/Admin#authorizer/msp
This is what I have exported and used as an orderer user to sign.
After that signature is passed to the envelope, the policy is fulfilled!

Related

Why is the Azure Devops API telling me that I must have these parameters for my Push request when I already do?

I'm trying to make a Git push request to our Azure Devops server via the API. The address is https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1 and the body is as follows:
{
"commits": [
{
"comment": "Just a dummy commit",
"changes": [
{
"changeType": "edit",
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": "rawText"
}
}
]
}
],
"refUpdates": [
{
"name": "refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
I'm getting the following error:
Web Request Failed after 4 attempts. Request: https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1. Status: BadRequest. Response: Invalid status code [BadRequest]. Response: {"$id":"1","innerException":null,"message":"The parameters are incorrect. A posted push must contain exactly one commit and one refUpdate.\r\nParameter name: newPush","typeName":"Microsoft.TeamFoundation.SourceControl.WebServer.InvalidArgumentValueException, Microsoft.TeamFoundation.SourceControl.WebServer","typeKey":"InvalidArgumentValueException","errorCode":0,"eventId":0}
"A posted push must contain exactly one commit and one refUpdate" doesn't seem entirely reasonable as that's exactly what I have in my body. Does anybody know what might be going on here?
Note that I am having no issues making other web requests, such as creating branches or retrieving file contents.
I expected my web request to proceed smoothly, and to create a Push containing the specified commit to the specified refUpdate.
I have made a manual push for via the Azure Devops web interface and caught the network traffic, and I grabbed the following JSON request out of it:
{
"commits": [
{
"changes": [
{
"changeType": 2,
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": 0
}
}
],
"comment": "Just a dummy commit"
}
],
"refUpdates": [
{
"name": ""refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
This seems to be meaningfully identical to the Push I'm making from my code, other than the enum fields using numerical values instead of text. I have tried my code with numerical values for enums, but that didn't change anything about the error.
I found the issue. The web request from my application was being sent with UTF-16 encoding, whereas Postman had defaulted to UTF-8 encoding. I changed my application to use UTF-8 and it worked.

AzureBlobStorageOnIoTEdge: Error Target container connection not specified, upload turned off

My local blob storage is not uploading blobs to my cloud storage account. It reports back
"configurationValidation": {
"deviceAutoDeleteProperties": {
"deleteOn": {
"Status": "Success"
},
"deleteAfterMinutes": {
"Status": "Warning",
"Message": "Auto Delete after minutes value not specified, auto deletion turned off."
},
"retainWhileUploading": {
"Status": "Success"
}
},
"deviceToCloudUploadProperties": {
"uploadOn": {
"Status": "Success"
},
"cloudStorageAccountName": {
"Status": "Error",
"Message": "Target container connection not specified, upload turned off."
},
"cloudStorageAccountKey": {
"Status": "Error",
"Message": "Target container connection not specified, upload turned off."
},
"uploadOrder": {
"Status": "Success"
},
"deleteAfterUpload": {
"Status": "Success"
}
}
},
I am pretty sure that it should work. My desired properties are
"deviceToCloudUploadProperties": {
"uploadOn": true,
"uploadOrder": "OldestFirst",
"cloudStorageConnectionString": "DefaultEndpointsProtocol=https;AccountName=*****;AccountKey=******;EndpointSuffix=core.windows.net",
"storageContainersForUpload": {
"***": {
"target": "***"
}
},
"deleteAfterUpload": true
}
The container exists locally and on the cloud site. I copied the primary connection string from my local storage account into the configuration. The local storage is working, I can see that my container was created and contains data but it doesn't want to synchronize with the cloud. Why is it saying "Target container connection not specified, upload turned off."? It sounds like this part is missing
"storageContainersForUpload": {
"***": {
"target": "***"
}
},
but obviously it is not.
I'm using the latest docker image of this service. Is there any chance to use an older version? Some months ago I could make it work already. I tried to use a different version like mcr.microsoft.com/azure-blob-storage:1.4.0 but it doesn't accept any other tags than latest.
Thx!
The difference between my working version of the local blob storage module and my non working version was that the non working version was deployed by a deployment plan. In the deployment plan you cannot just paste the module twin settings of the documentation of the blob storage on IoT edge like https://learn.microsoft.com/en-us/azure/iot-edge/how-to-deploy-blob?view=iotedge-2020-11
You need to split the configuration into two parts where the first part looks like this
and the second part looks like that
And that totally makes sense. If you want to update your modules you probably want to keep your configuration because there might have been some changes which were made e.g. by a customer. This gives you the possibilty to add some properties to your inital configuration later without changing anything what was already configured. In fact every device can keep its individual configuration at any time.
My wrongly configured reported proterties were hidden in the suggested default path "properties.desired.settings" and thus the edge runtime could not find it.

Can't add Teams bot to a channel

This was originally a support ticket to Microsoft. However they told they don't do dev support without paying for it. They directed me to Stack Overflow, so here goes nothing.
I'm developing a Bot for Microsoft Teams. I have registered my bot with Azure Active Directory, & Bot Framework. I have uploaded my app to Team, without any errors. My bot is currently able to send direct messages to Teams users. However, when I try to add my bot to a Teams channel, I get unhelpful errors.
I click the dropdown under my app in the Apps tab:
I click "Add to a Team", then select a channel:
After clicking the button "Set up a bot", I get the following error message:
I have checked & rechecked my webApplicationInfo.id & webApplicationInfo.applicationPermissions numerous times, and I'm at a loss for what could be amiss. I don't see how either of these fields could be wrong given, I can authenticate with both the Microsoft Graph & Bot Framework apis using these values. Here's a slightly redacted version of my Teams app manifest:
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.8/MicrosoftTeams.schema.json",
"manifestVersion": "1.8",
"version": "1.0.15",
"id": "<TEAMS_APP_ID>",
"packageName": "ambition",
"developer": {
"name": "Ambition",
"websiteUrl": "https://ambition.com",
"privacyUrl": "https://ambition.com/privacy",
"termsOfUseUrl": "https://ambition.com/pages/terms"
},
"icons": {
"color": "logo_opaque_192x192.png",
"outline": "logo_transparent_32x32.png"
},
"name": {
"short": "Ambition",
"full": ""
},
"description": {
"short": "Motivate & Recognize",
"full": "Ask Marketing"
},
"accentColor": "#FFFFFF",
"permissions": [
"identity",
"messageTeamMembers"
],
"validDomains": [
"ambition.com"
],
"bots": [
{
"botId": "<AZURE_ACTIVE_DIRECTORY_CLIENT_ID>",
"scopes": [
"team",
"personal",
"groupchat"
],
"isNotificationOnly": true
}
],
"webApplicationInfo": {
"id": "<AZURE_ACTIVE_DIRECTORY_CLIENT_ID>",
"resource": "https://ambition.com",
"applicationPermissions": [
"Channel.ReadBasic.All",
"ChannelMessage.Send",
"Group.Read.All",
"Notifications.ReadWrite.CreatedByApp",
"Team.ReadBasic.All",
"User.Read",
"User.ReadBasic.All"
]
}
}
The webApplicationInfo section is really only for two things: Tab SSO, and Resource-Specific Consent. Are you trying to implement either one of those? If not, removing it is definitely the best option, as you've noted in your answer.
In addition, I see that the resource values you've put in there are Microsoft Graph Scopes, whereas the applicationPermissions section is expecting a different list of options (they look kind of similar, but their not the same thing). See here for more: https://learn.microsoft.com/en-gb/microsoftteams/platform/graph-api/rsc/resource-specific-consent#resource-specific-permissions
Don't really know why this works, but I compared my app manifest to the one generated by going through this tutorial: https://learn.microsoft.com/en-us/microsoftteams/platform/build-your-first-app/build-bot.
Removing the webApplicationInfo property from my manifest fixed the issue. Don't really understand why it was causing a problem in the first place.
https://learn.microsoft.com/en-us/microsoftteams/platform/resources/schema/manifest-schema#webapplicationinfo

Hyperledger Fabric Endorsement Policy checker failure

Based on peer roles and the order you might have a failure in the policy checker.
Peer roles:
org1peer1:member
org1peer2:member
org2peer1:admin
org2peer2:member`
Endorsement policy specified in node sdk e2eUtils.js
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['org1'].mspid }},
{ role: { name: 'member', mspId: ORGS['org2'].mspid }},
{ role: { name: 'admin', mspId: ORGS['org1'].mspid }},
{ role: { name: 'admin', mspId: ORGS['org2'].mspid }}
],
policy: {
'2-of': [
{ 'signed-by': 1},
{ 'signed-by': 3}
]
}
}
Invoke transaction with node sdk e2e func invokeChaincode in e2eUtils.js
send endorsement responses with order (Org2Member,Org2Admin) -> SUCCESS
send endorsement responses with order (Org2Admin, Org2Member) -> ENDORSEMENT_POLICY_FAILURE
only send proposal to Org2Admin, and make another copy of response from Org2Admin, to make it (Org2Admin, Org2Admin) -> SUCCESS
The problem is the order or adding peers matters. We would expect the order of adding peers should not affect endorsement results.
Endorsement Policy Checker
The behavior of the policy checker, when endorsement policy requires both the
"admin" and "member" principals of the same organization, certain valid
endorsements may fail the policy check.
To illustrate this let's use the following example:
You have two endorsements: endorser1 as a member in org1 (E1) and endorser2 as an admin in org1 (E2)
You have the endorsement policy: "AND (org1.member, org1.admin)"
or when specified in the JSON format used with the node.js SDK:
{
"identities": [
{ "role": { "name": "member", "mspId": "org1" },
{ "role": { "name": "admin", "mspId": "org1" }],
"2-of": [
{ "signed-by": 0 },
{ "signed-by": 1
]
}
The current behavior of the policy checker depends on the order
of the two MSP principals in the endorsement policy. Here's a description of
the current implementation:
If the policy is similar to the code illustrated above, where the "member"
role is put ahead of the "admin" role of the same organization. AND the
policy requires both roles to be satisfied. Then the policy check will fail.
If the order of the endorsements inside the ProposalResponsePayload is
flipped. Meaning that E2 comes before E1, then the policy check will succeed.
However, if the "admin" role is put ahead of the "member" role, then the
policy check always succeeds regardless of the order of the endorsements."
Work around
Always specify admin identity in the policy before the member identity of the
same org, which will always work regardless of the order of the endorsers.
Further technical detail can be located in
FAB-4248

how to get an openstack token and validate it?

I followed this guide: http://keystone.openstack.org/api_curl_examples.html
and it seemed that I got a valid token by ran:
curl -d '{"auth":{"passwordCredentials":{"username": "can", "password": "mypassword"}}}' -H "Content-type: application/json" http://url:35357/v2.0/tokens
and it returned:
{
"access":
{
"token":
{
"expires": "2012-05-21T14:35:17Z",
"id": "468da447bd1c4821bbc5def0498fd441"
},
"serviceCatalog": {},
"user":
{
"username": "can",
"roles_links": [],
"id": "bb6d3a09ad0c4924bf20c1a32ccb5781",
"roles": [],
"name": "can"
}
}
}
but when I came to the next few sections to validate this token, I encountered this magic number: X-Auth-Token:999888777666. At first I thought it's the token I got but I was wrong.
I think I may have missed something, so I read related sections in openstack documents( http://keystone.openstack.org/configuration.html and http://docs.openstack.org/api/openstack-compute/programmer/content/ ), but still no idea how the number comes from.
could anyone explain to me
what's the meaning of that magic number
how to get the right value of it so I can get a working token to manage other parts of openstack
That magic number (string really) is the admin_token setting in your keystone.conf file. Under the [DEFAULT] section in keystone.conf set
admin_token = abcd1234
If you don't use it for admin actions, you'll see something like
ubuntu#i-000004bc:~/devstack$ curl http://localhost:35357/v2.0/tenants
{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}}
If you do use it, you'll see something like
ubuntu#i-000004bc:~/devstack$ curl -H "X-Auth-Token: abcd1234" http://localhost:35357/v2.0/tenants
{"tenants_links": [], "tenants": [{"enabled": true, "description": null, "name": "demo", "id": "aee8a46babcb4e4286021c8f6ef996cd"}, {"enabled": true, "description": null, "name": "invisible_to_admin", "id": "de17fea45de148ada0a58e998e6c3e73"}, {"enabled": true, "description": null, "name": "admin", "id": "f34b0c8ab30e450489b121fbe723fde5"}, {"enabled": true, "description": null, "name": "service", "id": "fbe3e2e530fd47298cb2cba1b4afa3da"}]}
To get the list of tenants, in our current implementation, we authenticate with admin credentials and use the token returned to get list of tenants.
The implementation works smooth with the authentication token. It may work with admin_token but I have not verified.
If you see the examples you are referring to, there are 2 types of endpoints used
Endpoint pointing to port 5000 - public port
Endpoint pointing to port 35357 - admin port
In examples which are hitting admin port you would need to specify the "X-Auth-Token" header as the admin_token (specified in the keystone.conf file)
The token itself is in dict["access"]["token"]["id"] which is that part that will go in the header of subsequent HTTP requests, i.e
X-Auth-Token: 468da447bd1c4821bbc5def0498fd441
The value 999888777666 is from the curl example tutorial and will definitely not work.
As for the value of the token itself, it's randomly generated by the OpenStack service and shouldn't contain any useful information from your point of view.
(BTW, you probably shouldn't go pasting the tokens into forums as they're valid for 24 hours and anyone with a copy of the token and access to your compute endpoint can use it to impersonate you).

Resources