I am running Sitecore 8.2 with one CM server and 3 CD servers. On only one of our CD servers we keep getting the following error:
5396 2017:12:18 00:00:59 ERROR Cannot finish Analytics page tracking
Exception: Sitecore.Analytics.Exceptions.ContactLockException
Message: Failed to extend contact lease for contact e629daf6-1176-4c55-9c17-31b45292212c
Source: Sitecore.Analytics
at Sitecore.Analytics.Tracking.ContactManager.SaveAndReleaseContact(Contact contact)
at Sitecore.Analytics.Pipelines.EndAnalytics.ReleaseContact.Process(PipelineArgs args)
at (Object , Object[] )
at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, Boolean failIfNotExists)
at Sitecore.Analytics.Pipelines.EndAnalytics.EndAnalyticsPipeline.Run()
at Sitecore.Analytics.Pipelines.HttpRequest.EndAnalytics.Process(HttpRequestArgs args)
I confirmed I could telnet to Mongo. I compared the config files with what is on the other CD servers. Code base is exactly the same as other two environments as well. Does anyone have any suggestions on what to check next? I feel like I missed something on this one server since it is the only one having this issue.
You probably need to make sure that Analytics.ClusterName in (Sitecore.Analytics.Tracking.config) is unique per CD site, Sitecore uses this as unique identifier of the cluster that is locking the contact, When the user session requests travels between the 3 CD servers, xDB on CD1 for example might fail to release it if its locked on the other CDs (2&3).
What you can do is :
Make sure each CD server have unique domain or sub-domain (eg, prod1.mywebsite.com, prod2.mywebsite.com ..etc ), I dont usually make these unique domains publicly accessible (DNS) , but rather just make it accessible within the network, as long as each CD can talk to the other CD servers by their unique domains
Update Analytics.ClusterName on each CD server to the unique domain that you assigned to it.
CORRECTION:
I contacted sitecore support to get further details, and they told me that if you have single cluster for multiple CD servers, Then you should use the same Analytics.ClusterName for all CD servers, If you have multiple clusters and each cluster is using different session database, then CD servers within each cluster should have the same Analytics.ClusterName that is unique per cluster, So my above answer needed this correction.
Related
I have a Kubernetes cluster configured which builds perfectly when running via Docker Desktop, including invoking with successful endorsement via all three Chaincode containers in the network.
On the remote side, I'm using AWS EKS to deploy my nodes and I have more recently followed this guide on deploying a production ready peer. I already had EFS set up and in use as a k8s Persistent Volume, and this is populated each time I spool up a network with all the config. This means all the crypto materials, connection profiles, etc are mounted to the relevant containers and as per best practice the reference to these TLS certs is in this directory.
This all works as expected... my admin pods can communicate with my peers, the orderers connect, etcetera. I'm able to fully install chaincode, approve it and commit it to all three of my peers successfully.
When it comes to invoking the chaincode, my org1 container always succeeds, and successfully communicates with the peer in its organization.
I'm aware of the core.yaml setting localMspId and this is being overridden by the environment variable CORE_PEER_LOCALMSPID for each set of peers, such that in my org1 peer the value is Org1MSP, in org2 it's Org2MSP, etc.
When running peer chaincode invoke, the first container (org1) succeeds very quickly, the other two try to contact their peers and hang for the timeout period set in the default gRPC settings (110000ms wait). I also have set the env var of CORE_PEER_ADDRESS_AUTODETECT: "true" on my peer in order to ensure it doesn't try to resolve using the hostnames like peer0.org1 (this clearly works for org1 but not the other two).
The environment variables set for TLS in each of the containers corresponds to the contents of the ones I am passing (in correct order) with my invoke command:
peer chaincode invoke --ctor '${CC_INIT_ARGS}' --channelID ${CHANNEL_ID} --name ${CC_NAME} --cafile \$ORDERER_TLS_ROOTCERT_FILE \
--tls true -o orderer.${ORG}:7050 \
--peerAddresses peer0.org1:7051 \
--peerAddresses peer0.org2:7051 \
--peerAddresses peer0.org3:7051 \
--tlsRootCertFiles /etc/hyperledger/fabric-peer/client-root-tlscas/tlsca.org1-cert.pem \
--tlsRootCertFiles /etc/hyperledger/fabric-peer/client-root-tlscas/tlsca.org2-cert.pem \
--tlsRootCertFiles /etc/hyperledger/fabric-peer/client-root-tlscas/tlsca.org3-cert.pem >&invoke-log.txt
cat invoke-log.txt
That command is executed inside my container, and as mentioned, I have manually confirmed by inspecting all three containers, then cating the contents of the files, versus doing the same with the above paths, and they match exactly. That is to say the contents of /etc/hyperledger/fabric-peer/client-root-tlscas/tlsca.org1-cert.pem are equivalent to the CORE_PEER_TLS_ROOTCERT_FILE setting in org1, and so on per organization.
Example org1 chaincode container logs:
2022-02-23T13:47:07.255Z debug [c-api:lib/handler.js] [allorgs-5e707801] Calling chaincode Invoke(), response status: 200
2022-02-23T13:47:07.256Z info [c-api:lib/handler.js] [allorgs-5e707801] Calling chaincode Invoke() succeeded. Sending COMPLETED message back to peer
For org2 and org3 containers, once it finally finishes the timeout, it outputs:
2022-02-23T12:24:05.045Z error [c-api:lib/handler.js] Chat stream with peer - on error: %j "Error: 14 UNAVAILABLE: No connection established\n at Object.callErrorFromStatus (/usr/local/src/node_modules/#grpc/grpc-js/build/src/call.js:31:26)\n at Object.onReceiveStatus (/usr/local/src/node_modules/#grpc/grpc-js/build/src/client.js:391:49)\n at Object.onReceiveStatus (/usr/local/src/node_modules/#grpc/grpc-js/build/src/client-interceptors.js:328:181)\n at /usr/local/src/node_modules/#grpc/grpc-js/build/src/call-stream.js:182:78\n at processTicksAndRejections (internal/process/task_queues.js:79:11)"
2022-02-23T12:24:05.045Z debug [c-api:lib/handler.js] Chat stream ending
I have also enabled DEBUG logs on everything and I'm gleaning nothing useful from it. Any help or suggestions would be greatly appreciated!
The three peers share the same port. Is that even possible?
Also, when running invoke from the command line, I would normally use the following pattern, repeated for each peer.
--peerAddresses localhost:6051 --tlsRootCertFiles <path to peer on port 6051>
--peerAddresses localhost:6052 --tlsRootCertFiles <path to peer on port 6052>
not the three peers followed by the three TLS cert file paths.
I have a hosted zone created in Route53 and updated the NS records under the namespaces of the purchased domain.
Unfortunately the DNS check does not return or point to the new NS records instead gets resolved to old/ previously existing records.
I waited more than 72 hours and still i get "This site can’t be reached"failing with error DNS_PROBE_FINISHED_NXDOMAIN in the browser.
Below is a screenshot from the DNS check provided by https://mxtoolbox.com/,
It shows that the old NS records (First 4 rows with TTL to 48 hours) are present in the Parent and not in local whereas the newly updated records (The last 4 records) are present in the parent and not in the local.
Ping to the domain fails with Unknown host.
What are the next steps?
When you update the name servers for a domain, remove the old name server records.
Your TTL is set to 48 hours. That means any recursive resolver such as dns.google will not refresh for 48 hours after last update. For resolvers that have not cached your resource records, they might update immediately but might also get stale data from an upstream resolver. Wait a few hours so that you do not force a new cache load with old data and then check with an Internet tool such as dnschecker.org Change the selection box from A to NS to see the name server changes.
In general I recommend that it takes 48 to 72 hours for authoritative name server changes to propagate around the world.
Google DNS supports "Flush Cache". Wait an hour or two and then request that Google update their DNS cache. Flush Cache
Cloudflare also supports Purge Cache
Google and Cloudflare are very popular DNS resolvers.
Also, do not forget to flush your local computer's DNS cache:
Windows: ipconfig /flushdns
Linux: sudo service network-manager restart (ubuntu) or sudo /etc/init.d/nscd restart
macOS: sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder
I'm working towards through the AWS Build a Modern Web Application project and have come across a problem at Module 2B part 1C (Confusing but will make sense if you go to the link).
Command used:
$ docker push muhammad.h.mughal.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest
I can't seem to push the docker image I have created. The error reads:
The push refers to repository [muhammad.h.mughal.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service]
Get https://muhammad.h.mughal.dkr.ecr.us-east-1.amazonaws.com/v2/: x509: certificate is valid for *.dkr.ecr.us-east-1.amazonaws.com, not muhammad.h.mughal.dkr.ecr.us-east-1.amazonaws.com
I thought it would be a simple task however I have been stuck on this for a while now and am reaching out. If you need more information please let me know.
You're getting this error because the name you're using for the repository, muhammad.h.mughal, has . periods in it.
You'll note the host you're referring to is muhammad.h.mughal.dkr.ecr.us-east-1.amazonaws.com but the certificate is for *.dkr.ecr.us-east-1.amazonaws.com. * in this context ( ssl certificate Common Names) matches only one domain component. By adding a . in your naming, you've inadvertently created a domain name with 3 domain components (muhammad,h,and mughal), invalidating ssl certificate of ECR.
The solution, though drastic, is simple - delete the repo. That name will never work correctly, and now is the time to start over.
I've just had a bit of fun trying to connect to a new VM I'd created, I've found loads of posts from people with the same problem, the answer details the points I've found
(1) For me it worked with
<VMName>\Username
Password
e.g.
Windows8VM\MyUserName
SomePassword#1
(2) Some people have just needed to use a leading '\', i.e.
\Username
Password
Your credentials did not work Azure VM
(3) You can now reset the username/password from the app portal. There are powershell scripts which will also allow you to do this but that shouldn't be necessary anymore.
(4) You can also try redeploying the VM, you can do this from the app portal
(5) This blog says that "Password cannot contain the username or part of username", but that must be out of date as I tried that once I got it working and it worked fine
https://blogs.msdn.microsoft.com/narahari/2011/08/29/your-credentials-did-not-work-error-when-connecting-to-windows-azure-vms/
(6) You may find links such as the below which mention Get-AzureVM, that seems to be for classic VMs, there seem to be equivalents for the resource manager VMs such as Get-AzureRMVM
https://blogs.msdn.microsoft.com/mast/2014/03/06/enable-rdp-or-reset-password-with-the-vm-agent/
For complete novices to powershell, if you do want to go down that road here's the basics you may need. In the end I don't believe I needed this, just point 1
unInstall-Module AzureRM
Install-Module AzureRM -allowclobber
Import-Module AzureRM
Login-AzureRmAccount (this will open a window which takes you through the usual logon process)
Add-AzureAccount (not sure why you need both, but I couldn’t log on without this)
Select-AzureSubscription -SubscriptionId <the guid for your subscription>
Set-AzureRmVMAccessExtension -ResourceGroupName "<your RG name>" -VMName "Windows8VM" -Name "myVMAccess" -Location "northeurope" -username <username> -password <password>
(7) You can connect to a VM in a scale set as by default the Load Balancer will have Nat Rules mapping from port onwards 50000, i.e. just remote desktop to the IP address:port. You can also do it from a VM that isn't in the scale set. Go to the scale set's overview, click on the "virtual network/subnet", that'll give you the internal IP address. Remote desktop from the other one
Ran into similar issues. It seems to need domain by default. Here is what worked for me:
localhost\username
Other option can be vmname\username
Some more guides to help:
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-portal#connect-to-virtual-machine
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/connect-logon
In April 2022 "Password cannot contain the username or part of username" was the issue.
During the creation of VM in Azure, everything was alright but wasn't able to connect via RDP.
Same in Nov 2022, you will be allowed to create a password that contains the user name but during login it will display the credential error. Removing the user name from the password fixed it.
I have installed GitLab Omnibus Community Edition 8.0.2 for evaluation purpose. I am trying to connect Gitlab (Linux AMI on AWS) with our on-premise LDAP server running on Win 2008 R2. However, i am unable to do so. I am getting following error (Could not authorize you from Ldapmain because "Invalid credentials"):
Here's the config i'm using for LDAP in gitlab.rb
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'XX.YYY.Z.XX'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'CN=git lab,OU=users,OU=Service Accounts,OU=corp,OU=India,OU=Users,OU=UserId&Rooms,DC=india,DC=local'
password: 'pwd1234'
active_directory: true
allow_username_or_email_login: true
base: 'CN=git lab,OU=users,OU=Service Accounts,OU=corp,OU=India,OU=Users,OU=UserId&Rooms,DC=india,DC=local'
user_filter: ''
EOS
There are two users: gitlab (newly created AD user) and john.doe (old AD user)
Both users are able to query all AD users using ldapsearch command but when i use their respective details (one at a time) in gitlab.rb and run gitlab-rake gitlab:ldap:check command, it displays info about that particular user only and not all users.
Earlier, gitlab-rake gitlab:ldap:check was displaying first 100 results from AD when my credential (john.doe) was configured in gitlab.rb file. Since this was my personal credential, i asked my IT team to create a new AD user (gitlab) for GitLab. After i configured new user (gitlab) in gitlab.rb file and ran gitlab-rake gitlab:ldap:check, it only displayed that particular user's record. I thought this might be due to some permission issue for the newly-created user so i restored my personal credentials in gitlab.rb. Surprisingly, now when i run gitlab-rake gitlab:ldap:check, i get only one record for my user instead of 100 records that i was getting earlier. This is really weird! I think, somehow, GitLab is "forgetting" previous details.
Any help will really be appreciated.
The issue is resolved now. Seems like it was a bug in the version (8.0.2) i was using. Upgrading it to 8.0.5 fixed my issue.
Also, values of bind_dn and base that worked for me are:
bind_dn: 'CN=git lab,OU=users,OU=Service Accounts,OU=corp,OU=India,OU=Users,OU=UserId&Rooms,DC=india,DC=local'
base: 'OU=users,OU=Service Accounts,OU=corp,OU=India,OU=Users,OU=UserId&Rooms,DC=india,DC=local'