I am on composer 0.16.0 and Fabric 1.0.4
While experimenting with Historian queries via composer-client consistently run into a situation when the network becomes non-responsive and the only way to reanimate it seems to be restarting the Fabric and redeploying the network.
The error follows:
>
Error: Error trying to ping. Error: Error trying to query business network. Error: chaincode error (status: 500, message: Error: The current identity has not been registered: admin)
>
So, the questions are:
1. Is this a known issue and is there a workaround? Happy to do more diagnostics and file it properly if that helps.
2. Any way to reboot the network without restarting the Fabric?
Thank you!
so the error "The current identity has not been registered: admin" is fundamentally caused by the fact you are restarting your CA server each time - ie a new CA server, a new authority issuing new credentials effectively for 'admin' (and hence your present admin credentials from 'previous' in your card store are not recognised by the new CA server).
Suggest to
1) clear out old admin cards from your card store eg. composer card delete --name admin#tutorial-network
2) re-import your 'admin' card through playground or CLI - and do a composer network ping to retrieve credentials to the card store.
3) Reduce your Historian queries result sets by adding selection criteria
Note: To restart your existing Dev Fabric - just use docker stop to stop your containers - and docker start you can restart them from the same state (or use docker-compose stop and docker-compose start if you're familiar with that command). Else, use docker persistence to persist your data.
https://hyperledger.github.io/composer/tutorials/developer-tutorial.html
Probably good to
Related
I want to start using Vault to rotate credentials for mssql databases, and I need to be able to use a gMSA in my mssql connection string. My organization currently only uses Windows servers and will only provide gMSAs for service accounts.
Specifying the gMSA as the user id in the connection string returns the 400 error error creating database object: error verifying connection: InitialBytes InitializeSecurityContext failed 8009030c.
I also tried transitioning my vault services to use the gMSA as their log on user, but this made nodes unable to become a leader node even though they were able to join the cluster and forward requests.
My setup:
I have a Vault cluster running across a few Windows servers. I use nssm to run them as a Windows service since there is no native Windows service support.
nssm is configured to run vault server -config="C:\vault\config.hcl" and uses the Local System account to run under.
When I change the user, the node is able to start up and join the raft cluster as a follower, but can not obtain leader status, which causes my cluster to become unresponsive once the Local System user nodes are off.
The servers are running on Windows Server 2022 and Vault is at v1.10.3, using integrated raft storage. I have 5 vault nodes in my cluster.
I tried running the following command to configure my database secret engine:
vault write database/config/testdb \
connection_url='server=myserver\testdb;user id=domain\gmsaUser;database=mydb;app name=vault;' \
allowed_roles="my-role"
which caused the error message I mentioned above.
I then tried to change the log on user for the service. I followed these steps to rotate the user:
Updated the directory permissions for everywhere vault is touching (configs, certificates, storage) to include my gMSA user. I gave it read permissions for the config and certificate files and read/write for storage.
Stopped the service
Removed the node as a peer from the cluster using vault operator raft remove-peer instanceName.
Deleted the old storage files
Changed the service user by running sc.exe --% config "vault" obj="domain\gmsaUser" type= own.
Started the service back up and waited for replication
When I completed the last step, I could see the node reappear as a voter in the Vault UI. I was able to directly hit the node using the cli and ui and get a response. This is not an enterprise cluster, so this should have just forwarded the request to the leader, confirming that the clustering portion was working.
Before I got to the last node, I tried running vault operator step-down and was never able to get the leader to rotate. Turning off the last node made the cluster unresponsive.
I did not expect changing the log on user to cause any issue with node's ability to operate. I reviewed the logs but there was nothing out of the ordinary, even by setting the log level to trace. They do show successful unseal, standby mode, and joining the raft cluster.
Most of the documentation I have found for the mssql secret engine includes creating a user/pass at the sql server for Vault to use, which is not an option for me. Is there any way I can use the gMSA in my mssql config?
When you put user id into the SQL connection string it will try to do SQL authentication and no longer try windows authentication (while gMSA is a windows authentication based).
When setting up the gMSA account did you specify the correct parameter for who is allowed to retrieve the password (correct: PrincipalsAllowedToRetrieveManagedPassword, incorrect but first suggestion when using tab completion PrincipalsAllowedToDelegateToAccount)
maybe you need to Install-ADServiceAccount ... on the machine you're running vault on
Long time back I have created a composer network by using composer version 0.19.0. Now when I am trying to ping the network using following command getting this error.
composer network ping --card admin#tutorial-network
output :Error: Error trying to ping. Error: 2 UNKNOWN: identity expired
Please help me how to resolve this issue.
Do you have any other identities registered (and thus have cards in your card store) with your business network which haven't expired ? If you don't then you are locked out of your business network. If you do but they don't have the appropriate ACLS to perform things like identity management (composer identity issue/bind etc) then so long as you have a card that doesn't have an expired identity that can perform install/upgrade you could upgrade your business network to provide required ACLs for that participant to be able to do identity management.
I had same issue today and solved like below.
First you need to delete that card using this command.
composer card delete
Then you can add a new card. (You have a .bna file at the same directory) Use this command below for importing new card.
composer card import --file networkadmin.card
You can ping successfully.
composer network ping --card admin#cardName
I hope this will solve your problem. Then you can start the rest server with below code.
composer-rest-server
I had a composer-rest-server running on a host. Due to some reason I had to reboot my aws instance. So I stopped all the fabric docker containers except the chaincode and also stopped the composer rest server.
After rebooting the machine, I restarted all the containers. At this time the chaincode container did not start. However, I issued a ping command with admin identity card and the chaincode container too started.
Next, I restarted the composer rest server with the same admin identity. However, when I tried to issue an "identitiy request" command for a participant it resulted in:
Unhandled error for request POST /api/system/identities/issue: Error: fabric-ca request register failed with errors [[{"code":20,"message":"Authorization failure"}]]
Does it mean the old admin identities are invalidated after a system restart?
This is occurring because when the AWS instance reboots, the identity data within the fabric-ca container is cleared (the container uses sqlite for an ephemeral data store).
If you instead setup the fabric-ca container to use a mysql or postgresql db container, you will be able to persist the identity data even after machine/container restarts.
This question also pertains to your situation as well Hyperledger Composer Identity Issue error after network restart (code:20, authorization failure)
This error is usually seen when you try and Issue a New Identity whilst using an Identity that does not have the rights to do so.
(If you are in single user mode the card you started the REST server with does not have the rights, or if in Multi-User mode the card currently being used in the Wallet does not have the rights.)
The Network Admin card initially created to administer the network has the rights to Issue New identities, and if you want to create additional Identities (Cards) that have the right you need to give them issuer rights when you create them. This is an option you use when Issuing an identity. On the CLI you would use a command such as composer identity issue -c admin#my-network --issuer -u mynewuser ...
On the REST server you would include an option in the JSON data e.g.:
{
"participant" : "org.acme.mynetwork.Manager#MGR02",
"userID" : "BrianM",
"options": {"issuer":true}
}
I have multiple RabbitMQ nodes running on different machines. After installing each node I failed to specify a common cookie for each of them to use so I had to go back and manually change the file .erlang.cookie . My issue is that after doing this I get conflicting error messages. If i do rabbitmqctl status
I get the following error:
DIAGNOSTICS
attempted to contact: ['rabbit#nc-mso-test01']
rabbit#nc-mso-test01: * connected to epmd (port 4369) on
nc-mso-test01 * epmd reports node 'rabbit' running on port 25672 *
TCP connection succeeded but Erlang distribution failed
Authentication failed (rejected by the remote node), please check
the Erlang cookie
current node details:
- node name: 'rabbitmq-cli-45#nc-mso-test01'
- home dir: C:\Users\jol
- cookie hash: 9/Hx6l+wLQv3NkmSDFqBog==
Whatever script I call, I get the same error. I tried restarting the service, removing and installing it through rabbitmq-service. The error persists. From what I can gather from other posts, the reason might be that the node and the erlang broker are running on separate users and each of them have a different version of the cookie, one is stuck with the old one.
How can I make the server and node restart, so that both of them use the new cookie file?
I solved my issue. I missed the fact that the RabbitMQ setup has two cookie files, one in c:\Windows for the erlang component, and one in C:\Users\%USER%. From what I understand, if the erlan VM is started on it's own application user and the RabbitMQ node is started on a different user, which would have been my case, then the two cookie files were different and I had to sync those up before syncing the cluster cookies.
Documentation says:
The cookie file used by the Windows service account and the user running CLI tools must be synchronised. RabbitMQ-Clustering Guide
On Erlang versions starting with 20.2, the cookie file locations are:
For user running CLI tools - usually C:\Users\%USERNAME%\.erlang.cookie for user %USERNAME%
For the RabbitMQ Windows service - %USERPROFILE%\.erlang.cookie
(usually C:\WINDOWS\system32\config\systemprofile)
On Erlang versions prior to 20.2 (e.g. 19.3 or 20.1), the cookie file locations are:
For user running CLI tools - usually C:\Users\%USERNAME%\.erlang.cookie for user %USERNAME%
For the RabbitMQ Windows service - %WINDIR%\.erlang.cookie (usually C:\Windows\.erlang.cookie)
I am trying to set up Jappix on amazon ec2. I have followed this guide and setup everything.
https://github.com/jappix/jappix/wiki
https://project.jappix.com/
I ran into this problem while setting up and solved it.
lua-sec-prosody Unable to locate package
Now after everything is set up(modifying config files etc) I am not able to create an account.
When I try to register from my custom installation of jappix, It shows "Service unavailable".
I also tried to point Pidgin to my instance and tried to create an account but failed. However, it is able to connect because I verified that by
service metronome stop
and
service metronome start
Now I tried to use the admin interface through telnet
telnet localhost 5582
and tried to create a user. I got this error
Error: /usr/local/lib/metronome/core/usermanager.lua:80: attempt to index field '?' (a nil value)
Is there anything that I am missing?
PS: I have enabled the required ports on my ec2 instance.
That ominous message means, you're trying to create a user on an unexistant or unactivated host.
(That's fixed in latest tip btw)