I'm trying run a Chainlink node (from source) on the Avalanche Fuji testnet, it seems to start up okay but I'm getting a server error for generating the account addresses.
The error above the Account Addresses in the Key Management menu just states "Server error" and doesn't show any addresses.
It also seems that the node tries to use the Kovan address even though I've changed the ETH URL and chain ID to Avalanche Fuji. The error being "Error: while creating transaction: cannot send transaction on chain ID 43113; eth key with address 0x... is pegged to chain ID 42: task run failed"
I've tried disabling the chain in the Operator dashboard but the error persists.
Node configuration
Attempting to run a job
Below is my .env file for the node. I'm running the node and the postgres server on the same device. This setup (with different environment variables) has worked previously for me on the Kovan testnet.
ETH_URL=wss://avalanche--fuji--rpc.datahub.figment.io/apikey/API_KEY/ext/bc/C/ws
FEATURE_EXTERNAL_INITIATORS=true
LOG_LEVEL=debug
ETH_CHAIN_ID=43113
MIN_OUTGOING_CONFIRMATIONS=2
LINK_CONTRACT_ADDRESS=0x0b9d5D9136855f6FEc3c0993feE6E9CE8a297846
CHAINLINK_TLS_PORT=0
SECURE_COOKIES=false
ALLOW_ORIGINS=*
DATABASE_URL=postgresql://USER:PASSWORD#localhost:5432/elvis?sslmode=disable
DATABASE_TIMEOUT=0
FEATURE_FLUX_MONITOR=true
MINIMUM_CONTRACT_PAYMENT_LINK_JUELS=100000000000000000
CHAINLINK_DEV=true
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
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 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
Hello Stack Overflow community, I am encountering the following errors when I try to add a node to my local computer cluster using Microsoft HPC Pack 2016:
Could not contact node 'NODE-A08' to perform change. Identity check
failed for outgoing message. The expected DNS identity of the remote
endpoint was 'HEAD-NODE01' but the remote endpoint provided DNS claim
'NODE-A08'. If this is a legitimate remote endpoint, you can fix the
problem by explicitly specifying DNS identity 'NODE-A08' as the
Identity property of EndpointAddress when creating channel proxy.
Could not contact node 'NODE-A08' to perform change. The management
service was unable to connect to the node using any of the IP
addresses resolved for the node.
Ultimately I would like to write and test my own MPI programs while using HPC Pack as my cluster manager, but I cannot seem to get past this preliminary step of setting up my cluster.
Through my research in to the issue I have found "Identity check failed for outgoing message..." to be a well documented error related to Windows Communication Foundation (WCF). My understanding is that it occurs when the common name (CN) of the endpoint computer's certificate does not match its DNS identity.
The solutions that I found where lines of code for people writing their own programs, however those solutions do not apply to HPC Pack because I cannot access its source code directly.
Some additional information specific to my situation:
the certificates used by both the head node and the node were issued
individually by a trusted domain
all computers are connect to one enterprise network
the head node's PC name is 'HEAD-NODE01'
the node's PC name is 'NODE-A08'
these errors occur during the provisioning stage of adding a node
the errors are displayed in the provisioning log within HPC Pack
2016's user interface
I was successful in pinging each computer from the other
both computers display the proper DNS IP address when I use command
prompt
the head node is running Windows Server 2012 R2
the node is preconfigured to be a workstation node and is running
Windows 10 Enterprise
Any help would be greatly appreciated. I have looked for a few days and in a lot of places for an answer, but I have not been very successful. Thank you very much in advance!
Subject names of both SSL certificates must be identical
Problem
Enterprise Manager starts and then hangs.
Environment
RAC installation on Windows, comprised of two nodes, node1 and node2. Enterprise Manager is installed on node1. We are able to get dbconsole to run briefly and and then it fails.
emagent.trc from node1 shows what appear to be two sets of relevant errors.
The first set of errors regard an inability to connect to the EM repository (which is on the same node).
The second error is associated with the "Instance Health Check initialization failed".
emagent.trc (node1)
Thread-5548 ERROR fetchlets.healthCheck: GIM-00105: Shared memory region is corrupted.
Thread-5548 ERROR engine: [oracle_database,clustername_node1name,health_check] : nmeegd_GetMetricData failed : Instance Health Check initialization failed due to one of the following causes: the owner of the EM agent process is not same as the owner of the Oracle instance processes; the owner of the EM agent process is not part of the dba group; or the database version is not 10g (10.1.0.2) and above.
Thread-5668 WARN http: snmehl_connect: connect failed to (node1:1158): No connection could be made because the target machine actively refused it.
Thread-5668 ERROR pingManager: nmepm_pingReposURL: Cannot connect to https://node1:1158/em/upload/: retStatus=-1
Thread-5708 ERROR upload: FxferSend: Cannot connect to: https://node1:1158/em/upload/. retStatus=-1
Thread-5708 ERROR upload: Failed to upload file B0000109.xml, ret = -2
I would like to get advice about how to proceed to troubleshoot these two errors in hopes of getting EM to start and stay up.
Regarding the first error, how would one troubleshoot an inability to connect to a web page running on the same node? This would appear to rule out firewall issues, etc. as a cause.
Regarding the second error, dbconsole and agent were started manually from the command line using a domain account, whereas the Oracle service runs under Local System (dbconsole was configured to use Local System on startup but failed, and can only be restarted via emctl start dbconsole.)
This part of the errors is the most promising.
the owner of the EM agent process is not same as the owner of the Oracle instance processes; the owner of the EM agent process is not part of the dba group;
You should check if all accounts running oracle are part of the ora_dba group.
See: http://download.oracle.com/docs/html/B13831_01/ap_unix.htm#i634430