I am able to discover and login into the Target from the iscsi client and CHAP is also configured to authenticate to/from the ISCSI Initiator client.
I am getting the following error when trying logging out from the target to check if the CHAP config is working as expected while log back in,
[root#ltolx2020 ~]# iscsiadm --mode node --target iqn.1992-08.com.redhat:sn.120f265e82be345ecb111d039ea331262:vs.14 --portal 10.85.64.270 --logout
Logging out of session [sid: 1, target: iqn.1992-08.com.redhat:sn.120f265e82be345ecb111d039ea331262:vs.14, portal: 10.85.64.270 ,3260]
iscsiadm: Could not logout of [sid: 1, target: iqn.1992-08.com.redhat:sn.120f265e82be345ecb111d039ea331262:vs.14, portal: 10.85.64.270,3260].
iscsiadm: initiator reported error (9 - internal error)
iscsiadm: Could not logout of all requested sessions
Related
I was hoping someone here could help me out. We are currently evaluating JFrog's Artifactory - Container Registry running as a Docker service and for the life of me I cannot get this thing to work properly with our Active Directory instance. I had it working fine in version 6 but with the release of version 7, decided to start new with the new version.
So I have artifactory-jcr:7.3.2 up and running in our swarm. Go into administration -> security -> LDAP and create a new LDAP settings profile with the following fields:
LDAP URL: ldap://mydc.company.net:389/DC=company,DC=net
User DN Pattern: blank
Email Attribute: mail
Search Filter: (sAMAccountName={0})
Search Base: OU=Company Users
Search Sub-Tree: checked
Manager DN: CN=_svcAccount,OU=Service Accounts,OU=Company Users,DC=company,DC=net
Manager Password: Correct Password
The Manager DN is correct and the password has been verified and tested. I can log in with the service account from any machine and successfully query the directory using ADExplorer and issue a query for my account using only my sAMAccountName which returns my user object. So I know the service account's password is correct, permissions for it are correct and it can successfully issue queries.
But when trying to test an account from the LDAP settings profile page, I get a generic error message popup stating "Error connecting to the LDAP server:"
For the log, I am looking at the /var/opt/artifactory/artifactory-service.log file.
Here's the entry immediately following a failed 'test account' attempt:
2020-04-03T17:16:46.714Z [jfrt ] [ERROR] [7faa71d56a50ef2b] [o.a.s.l.AbstractLdapService:67] [http-nio-8081-exec-4] - Error connecting to the LDAP server:
org.springframework.security.authentication.AuthenticationServiceException: User myuseraccount failed to authenticate
at org.artifactory.security.ldap.ArtifactoryBindAuthenticator.authenticate(ArtifactoryBindAuthenticator.java:166)
at org.artifactory.security.ldap.LdapServiceImpl.testLdapConnection(LdapServiceImpl.java:77)
at org.artifactory.security.SecurityServiceImpl.testLdapConnection(SecurityServiceImpl.java:3193)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:205)
at com.sun.proxy.$Proxy156.testLdapConnection(Unknown Source)
at org.artifactory.ui.rest.service.admin.security.ldap.ldapsettings.TestLdapSettingsService.testLdapConnection(TestLdapSettingsService.java:76)
at org.artifactory.ui.rest.service.admin.security.ldap.ldapsettings.TestLdapSettingsService.execute(TestLdapSettingsService.java:63)
at org.artifactory.rest.common.service.ServiceExecutor.process(ServiceExecutor.java:38)
at org.artifactory.rest.common.resource.BaseResource.runService(BaseResource.java:92)
at org.artifactory.ui.rest.resource.admin.security.ldap.LdapSettingResource.testLdapSetting(LdapSettingResource.java:90)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:76)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:148)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:191)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:200)
2020-04-03T17:16:46.732Z [jfrt ] [ERROR] [7faa71d56a50ef2b] [o.a.s.l.AbstractLdapService:68] [http-nio-8081-exec-4] - Error connecting to the LDAP server:
2020-04-03T17:17:57.524Z [jfrt ] [WARN ] [81a5689d90762c9 ] [o.a.s.l.LdapServiceImpl:179 ] [http-nio-8081-exec-8] - Unexpected exception in LDAP query:for user myuseraccount vid LDAP: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580]
2020-04-03T17:17:57.547Z [jfrt ] [INFO ] [81a5689d90762c9 ] [o.a.s.l.LdapServiceImpl:129 ] [http-nio-8081-exec-8] - Couldn't find user named "myuseraccount" in ADsettings
From the login ui, I try to use my sam account name only I get a message above the login form stating: "Username or password is incorrect"
Here's the log entry that's generated at the time:
2020-04-03T17:05:12.060Z [jfrt ] [WARN ] [77c816e57e51530 ] [o.a.s.l.LdapServiceImpl:179 ] [http-nio-8081-exec-8] - Unexpected exception in LDAP query:for user admin vid LDAP: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580]
I am only using the sam account name for the login, not the user principal name. I am also leaving off the netbios domain name portion of the login. If I try to add in the full SAM Account name to include the domain, "companyname\myuseraccount" I get a Status 500 error page.
Can anyone tell me what I'm doing wrong here?
Thanks for any help!
Shortly after posting this question, I decided to shell into the running jcr container and copy and install the necessary rpm files and to get openldap working. Then used ldapsearch from the container to query our domain controller using the settings I had provided the artifactory UI. And viola! The issue was the bind DN. I thought the the Manager DN form field was supposed to be the full distinguished name of the binding user account used to query the directory but ldapsearch was returning object not found errors.
I changed the binding account to the service account's SAM account name ("_svcAccount") and got a result back. I've since gone back into the artifactory settings and update the Manager DN to be "_svcAccount" and everything is working.
Jfrog should change the description of the Manager DN field. A distinguished name consists of the full LDAP path to the object. Which doesn't work, at least not in my particular situation. Other Java based products we use like SonarQube, use the classic full distinguished name for the bind account. Jfrog Container Registry apparently does not.
-Update -- I ended up having to use the NetBIOS domain as part of the Manager DN account to get it to authenticate. So, instead of "_svcAccount" as the Manager DN, I had to use "mycompany\_svcAccount" as the Manager DN. However, Active Directory users do not use the NetBIOS domain when logging into the Container Registry, just the SAM account name. (i.e. "myAccount" vs. "mycompany\myAccount")
I am using CKAN 2.7.2.
I have added the following configurations in my development.ini file of ckan:
ckan.oauth2.authorization_endpoint = https://wso2IP/oauth2/authorize
ckan.oauth2.token_endpoint = https://wso2IP/oauth2/token
ckan.oauth2.profile_api_url = https://wso2IP/userinfo
ckan.oauth2.client_id = *client-id*
ckan.oauth2.client_secret = *clientsecret*
ckan.oauth2.profile_api_user_field = abc
ckan.oauth2.profile_api_mail_field = abc#gmail.com
Also, have exported the following while running ckan using paster serve :
export OAUTHLIB_INSECURE_TRANSPORT=True
Also, I have added an application (ckan provider) in WSO2 Identity Server also with callback URL = (http://ckan-url:5000/oauth2/callback) where the CKAN instance is running (i.e a private IP of 172.30.66.XX type running on port 5000).
So, what configuration need to be done in WSO2 Identity Server and ckan development.ini file?
Also, configuring on both sides, I get the error Client authentication Failed in CKAN GUI.
I am using Ckan 2.7.2 , WSO2-IS 5.1 and ckanext-oauth2 (oauthlib==0.8.0)
will it be giving a problem in authentication process??Can it be a version dependency issue??
I have followed the given steps. Kindly correct if I am missing or doing something wrong:
I have used API store and published ckan application.
Entered the ckan callback url as http://oauth2/callback
Entered the generated client ID and client secret from step 1 in ckan configuration.
Also, made the given changes mentioned by you regarding claim configurations and ckanext-oauth2 configurations.
Now, it gives above error.or sometimes Invalid Client (Client Authentication Failed)
Inbound settings:
enter image description here
Error Logs :
[2018-07-25 19:29:25,432] INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin#carbon.super [-1234]' logged in at [2018-07-25 19:29:25,431+0530]
[2018-07-25 21:55:15,930] INFO {org.wso2.carbon.identity.application.authentication.framework.store.OperationCleanUpService} - Session Operation Data cleanup task is running successfully for removing expired Operation Data
[2018-07-25 23:40:15,929] INFO {org.wso2.carbon.identity.application.authentication.framework.store.SessionCleanUpService} - Session Data cleanup task is running successfully for removing expired Data
[2018-07-26 09:21:18,948] INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin#carbon.super [-1234]' logged in at [2018-07-26 09:21:18,948+0530]
[2018-07-26 09:21:39,307] INFO {org.wso2.carbon.core.services.authentication.AuthenticationAdmin} - 'admin#carbon.super [-1234]' logged out at [2018-07-26 09:21:39,0306]
[2018-07-26 09:55:15,975] INFO {org.wso2.carbon.identity.application.authentication.framework.store.OperationCleanUpService} - Session Operation Data cleanup task is running successfully for removing expired Operation Data
After configuring the settings I receive the following Message:
Your application settings at WSO2-IS seems to be correct. The only thing to take into consideration, it is that ckanext-oauth2 is only able to use the Code and, the Refresh Token grant types, so only those types need to be allowed.
Using this configuration for ckanext-oauth2:
ckan.oauth2.authorization_endpoint = https://wso2IP/oauth2/authorize
ckan.oauth2.token_endpoint = https://wso2IP/oauth2/token
ckan.oauth2.profile_api_url = https://wso2IP/userinfo
ckan.oauth2.client_id = *** OAuth Client Key from the Inbound Authentication Configuration at WSO2 ***
ckan.oauth2.client_secret = *** OAuth Client Secret from the Inbound Authentication Configuration at WSO2 ***
ckan.oauth2.scope = all_info openid
ckan.oauth2.profile_api_user_field = email
ckan.oauth2.profile_api_fullname_field = name
ckan.oauth2.profile_api_mail_field = email
and using your claim mapping configuration (http://wso2.org/claims/fullname and http://wso2.org/claims/emailaddress); I was able to sign in into CKAN. I have tested using CKAN v2.7.4, v2.8.0 and v2.8.1; ckanext-oauth2 v0.6.1 and WSO2-IS v5.5.0 (although it should work using WSO2-IS v5.1).
When trying to execute docker container with gatewayid & sectoken, it fails with error "The Secure Gateway gateway ID was either not recognized or requires a security token to connect, error was: 401". And yet when I manually add via the CLI, it's successful.
I suspect it's because my security token has '--' in it. I tried '', "", and escaping characters on command line. but nothing worked. Fails in both Win10 and RHEL7.
Here's the console:
C:\Users\DebraJohnson>docker run -p 9023:9003 -it ibmcom/secure-gateway-client <gateway_id> --t <sectoken>
IBM Bluemix Secure Gateway Client Version 1.8.0fp4
....
<press enter for the command line>
[2018-04-16 09:12:17.993] [INFO] (Client ID 1) No password provided. The UI will not require a password for access
[2018-04-16 09:12:18.008] [WARN] (Client ID 1) UI Server started. The UI is not currently password protected
[2018-04-16 09:12:18.009] [INFO] (Client ID 1) Visit localhost:9003/dashboard to view the UI.
cli> [2018-04-16 09:12:18.327] [INFO] (Client ID 13) Setting log level to INFO
[2018-04-16 09:12:18.665] [ERROR] (Client ID 13) The Secure Gateway gateway ID was either not recognized or requires a security token to connect, error was: 401
cli> [2018-04-16 09:12:18.671] [INFO] (Client ID 13) Process exiting without errors due to user or server request
cli> sectoken <sectoken>
cli> connect <gateway_id>
cli> [2018-04-16 09:12:43.095] [INFO] (Client ID 27) Setting log level to INFO
[2018-04-16 09:12:43.774] [INFO] (Client ID 27) The Secure Gateway tunnel is connected
[2018-04-16 09:12:43.868] [INFO] (Client ID xxxxxxxxxxx_Hsu) Your Client ID is xxxxxxxxxxx_Hsu
xxxxxxxxxxx_Hsu>
Thanks
Having a -- as part of the security token could be the reason why you got 403 error. Can you please try regenerating the security token and connect the gateway again.
If you still have issues please open a support ticket (https://console.bluemix.net/docs/get-support/howtogetsupport.html#getting-customer-support) where you can provide the gateway id for us to look further into this.
I followed this tutorial to setup myorg/composer-rest-server and everything was working fine till I import card but when I make a GET request to /api/system/ping it returns 500 Error:
{"error":{"statusCode":500,"name":"Error","message":"Error trying login and get user Context. Error: Error trying to enroll user or load channel configuration. Error: Calling enrollment endpoint failed with error [Error: connect ECONNREFUSED 127.0.0.1:7054]","stack":"Error: Error trying login and get user Context. Error: Error trying to enroll user or load channel configuration. Error: Calling enrollment endpoint failed with error [Error: connect ECONNREFUSED 127.0.0.1:7054]\n at client.getUserContext.then.then.catch (/home/composer/.npm-global/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:393:34)\n at <anonymous>\n at process._tickDomainCallback (internal/process/next_tick.js:228:7)"}}
So I checked the logs for rest container, it can't seem to find 127.0.0.1:7054. Here is the error log.
Unhandled error for request GET /api/system/ping: Error: Error trying login and get user Context. Error: Error trying to enroll user or load channel configuration. Error: Calling enrollment endpoint failed with error [Error: connect ECONNREFUSED 127.0.0.1:7054]
at client.getUserContext.then.then.catch (/home/composer/.npm-global/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:393:34)
at <anonymous>
at process._tickDomainCallback (internal/process/next_tick.js:228:7)
So I checked the logs for the container ca.org1.example.com, and it is listening to port 7054
2018/04/01 09:57:25 [DEBUG] CA initialization successful
2018/04/01 09:57:25 [INFO] Home directory for default CA: /etc/hyperledger/fabric-ca-server
2018/04/01 09:57:25 [DEBUG] 1 CA instance(s) running on server
2018/04/01 09:57:25 [INFO] Listening on http://0.0.0.0:7054
I think i need to change 127.0.0.1 to 0.0.0.0 but not sure how to do it the right way. Could also be a firewall issue?
Here's my .composer/cards/restadmin#myserver/connection.json
{"name":"hlfv1","x-type":"hlfv1","x-commitTimeout":300,"version":"1.0.0","client":{"organization":"Org1","connection":{"timeout":{"peer":{"endorser":"300","eventHub":"300","eventReg":"300"},"orderer":"300"}}},"channels":{"composerchannel":{"orderers":["orderer.example.com"],"peers":{"peer0.org1.example.com":{}}}},"organizations":{"Org1":{"mspid":"Org1MSP","peers":["peer0.org1.example.com"],"certificateAuthorities":["ca.org1.example.com"]}},"orderers":{"orderer.example.com":{"url":"grpc://orderer.example.com:7050"}},"peers":{"peer0.org1.example.com":{"url":"grpc://peer0.org1.example.com:7051","eventUrl":"grpc://peer0.org1.example.com:7053"}},"certificateAuthorities":{"ca.org1.example.com":{"url":"http://ca.org1.example.com:7054","caName":"ca.org1.example.com"}}}
I'm using AWS EC2
OS: Ubuntu 16.04.3 LTS,
Docker: 17.12.0-ce,
Composer: v0.19.0
Fabric: v1.1
Which card have you imported? If it is the restadmin card, I think you may have imported a Card containing an expired One-Time secret. After the rest admin card was used to start the REST server (in the container) the secret was replaced with certificates - so if you export the restadmin card again with a different name composer card export -c restadmin#trade-network -f restadmin-cert.card you will see that it is a larger file because of the certificates. You should be able to import and use this new .card file.
(If you were using a different card e.g. jdoe - did you run the sed command for this card to correct the addresses?)
I'm trying to deploy car auction sample .bna file to HLF v0.6 service on Bluemix and getting different errors.
My connection profile for Bluemix:
{
"type": "hlf",
"membershipServicesURL": "grpcs://1c0b2dabbb834804ae3d284fed9059f4-ca.us.blockchain.ibm.com:30002",
"peerURL": "grpcs://1c0b2dabbb834804ae3d284fed9059f4-vp0.us.blockchain.ibm.com:30002",
"eventHubURL": "grpcs://1c0b2dabbb834804ae3d284fed9059f4-vp0.us.blockchain.ibm.com:31002",
"keyValStore": "/Users/me/.composer-credentials",
"deployWaitTime": "3000",
"invokeWaitTime": "1000",
"certificate": "-----BEGIN CERTIFICATE-----\nMIID6TCCA26gAwIBAgIQCiYEWw1faoRpM2xufaiPLTAKBggqhkjOPQQDAjBMMQsw\nCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp\nQ2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xNjA2MDcwMDAwMDBaFw0xOTA2\nMTIxMjAwMDBaMIGJMQswCQYDVQQGEwJVUzERMA8GA1UECBMITmV3IFlvcmsxDzAN\nBgNVBAcTBkFybW9uazE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBN\nYWNoaW5lcyBDb3Jwb3JhdGlvbjEgMB4GA1UEAwwXKi51cy5ibG9ja2NoYWluLmli\nbS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARTKAZypDOqw34HWujQeL82\nj1e9rN1inpN6ngrq49+OpYIe8ckHnJhsWPpf+zeIQePboDQVUTDtYXh7212BsVoX\no4IB8jCCAe4wHwYDVR0jBBgwFoAUo53mH/naOU/AbuiRy5Wl2jHiCp8wHQYDVR0O\nBBYEFK+1RoBnUnb8nr2hNtkUu3FRrbYuMDkGA1UdEQQyMDCCFyoudXMuYmxvY2tj\naGFpbi5pYm0uY29tghV1cy5ibG9ja2NoYWluLmlibS5jb20wDgYDVR0PAQH/BAQD\nAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6g\nLKAqhihodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6g\nLKAqhihodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwG\nA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3\nLmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggr\nBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlo\ndHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2\nZXJDQS5jcnQwDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA7LViaN74\nOwIp/zqfwSRvURg965+m73/edCeNKrsLf6GuE0sLwpX6pQNnDlr6SzGnAjEA+qk0\nsYRnd2gCQeD9fWbCJIw0vJDqeZr1WJ64aVoJ8kyASzY/yoarSm2wqujXJwEf\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIDrDCCApSgAwIBAgIQCssoukZe5TkIdnRw883GEjANBgkqhkiG9w0BAQwFADBh\nMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3\nd3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD\nQTAeFw0xMzAzMDgxMjAwMDBaFw0yMzAzMDgxMjAwMDBaMEwxCzAJBgNVBAYTAlVT\nMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxJjAkBgNVBAMTHURpZ2lDZXJ0IEVDQyBT\nZWN1cmUgU2VydmVyIENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE4ghC6nfYJN6g\nLGSkE85AnCNyqQIKDjc/ITa4jVMU9tWRlUvzlgKNcR7E2Munn17voOZ/WpIRllNv\n68DLP679Wz9HJOeaBy6Wvqgvu1cYr3GkvXg6HuhbPGtkESvMNCuMo4IBITCCAR0w\nEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEE\nKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQgYDVR0f\nBDswOTA3oDWgM4YxaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0R2xv\nYmFsUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYc\naHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUo53mH/naOU/A\nbuiRy5Wl2jHiCp8wHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUwDQYJ\nKoZIhvcNAQEMBQADggEBAMeKoENL7HTJxavVHzA1Nm6YVntIrAVjrnuaVyRXzG/6\n3qttnMe2uuzO58pzZNvfBDcKAEmzP58mrZGMIOgfiA4q+2Y3yDDo0sIkp0VILeoB\nUEoxlBPfjV/aKrtJPGHzecicZpIalir0ezZYoyxBEHQa0+1IttK7igZFcTMQMHp6\nmCHdJLnsnLWSB62DxsRq+HfmNb4TDydkskO/g+l3VtsIh5RHFPVfKK+jaEyDj2D3\nloB5hWp2Jp2VDCADjT7ueihlZGak2YPqmXTNbk19HOuNssWvFhtOyPNV6og4ETQd\nEa8/B6hPatJ0ES8q/HO3X8IVQwVs1n3aAr0im0/T+Xc=\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh\nMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3\nd3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD\nQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT\nMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j\nb20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB\nCSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97\nnh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt\n43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P\nT19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4\ngdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO\nBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR\nTLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw\nDQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr\nhMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg\n06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF\nPnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls\nYSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk\nCAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=\n-----END CERTIFICATE-----\n",
"certificatePath": "/certs/peer/cert.pem"
}
I'm executing the following command:
composer network deploy -p bluemix -a sample-networks/packages/carauction-network/carauction-network#0.0.7.bna -i admin -s PASSS
I tried this many times and I'm getting one of the following errors:
I. Security handshake:
$ composer network deploy -p bluemix -a sample-networks/packages/carauction-network/carauction-network#0.0.7.bna -i admin -s 97b116b3c4
Deploying business network from archive: carauction-network/carauction-network#0.0.7.bna
Business network definition:
Identifier: carauction-network#0.0.7
Description: Car Auction Business Network
E0528 10:59:18.962200000 123145570217984 handshake.c:128]
Security handshake failed:
{"created":"#1495940358.962177000","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1495940358.962172000","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_poll_posix.c","file_line":427}]}
Error
Command failed
II. Unhandled 'error' event:
$ composer network deploy -p bluemix -a sample-networks/packages/carauction-network/carauction-network#0.0.7.bna -i admin -s 97b116b3c4
Deploying business network from archive: carauction-network/carauction-network#0.0.7.bna
Business network definition:
Identifier: carauction-network#0.0.7
Description: Car Auction Business Network
events.js:160
throw er; // Unhandled 'error' event
^
Error: unknown service protos.Events
at ClientDuplexStream._emitStatusIfDone
(/usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._receiveStatus
(/usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:169:8)
at /usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:634:14
III. Identity or token does not match:
$ composer network deploy -p bluemix -a sample-networks/packages/carauction-network/carauction-network#0.0.7.bna -i admin -s 97b116b3c4
Deploying business network from archive: carauction-network/carauction-network#0.0.7.bna
Business network definition:
Identifier: carauction-network#0.0.7
Description: Car Auction Business Network
Error: Identity or token does not match.
Command failed
I feel "SSL Handshake problem" (I) and "Unhandled 'error' event" (II) are related to the old issue with HFC not handling properly GRPC disconnects Is it correct?. What I can't figure out is what's causing "Identity or token does not match" (III). My current guess is that admin user does not have a wallet created yet (can't see it in my ~/.composer-credentials folder). Is composer deploy supposed to create wallet automatically if it does not yet exists?
Ok, I did some more experiments, and here is what I've learned:
It was a problem in my profile's connection.json. When I copied and modified one from the answer to this question: Fabric composer integration with Bluemix blockchain service it start working.
I was setting long timeouts in connection.json, but CLI command still ends with the following error:
events.js:160
throw er; // Unhandled 'error' event
^
Error: {"created":"#1496109180.720017000","description":"Secure read failed","file":"../src/core/lib/security/transport/secure_endpoint.c","file_line":157,"grpc_status":14,"referenced_errors":[{"created":"#1496109180.720007000","description":"OS Error","errno":54,"file":"../src/core/lib/iomgr/tcp_posix.c","file_line":229,"os_error":"Connection reset by peer","syscall":"recvmsg"}]}
at ClientDuplexStream._emitStatusIfDone (/usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._receiveStatus (/usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:169:8)
at /usr/local/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:634:14
At the same time chaicode gets deployed. Still not sure what is causing it.
Since composer's deployment command is finished with error, the mapping between composer's network ID and deployed chaincode ID isn't added to. Which means, it needs to be added manually, by adding something like this to a respective connection.json:
"networks": {
"carauction-network": "8f637b9886357fb3e24864cfa36f9cdae84e587028a08074d856e9b6635afa76"
}