We are in the process of configuring AppDynamics for one of our applications. Since there are many instances of the application, we want to add nodename with agentId and hostName so as to identify the different instances.
Below is how we are trying to do, but it does not seems to work:
-Dappdynamics.agent.nodeName=CalculationEngine_${agentId}_${network.host}
Once I start the JVM the node name appears as CalculationEngine_null_null. I was hoping nodename to come CalculationEngine_3_a301-564.com where 3 being the agentid and a301-564 being the host name.
Also even if the host name parameter is not correct at least it should show CalculationEngine_3_null
What could be wrong here? Or is it not possible?
Related
I have 15 instances running with same security group, however I can SSH into some of them but not the others. I received "Permission denied (publickey)" message for those instances. I also confirm that all instances are using the same public key and I try to ssh into all of them with the same private key.
What do I miss?
Thank you for helping out!
If you are getting "Permission denied (publickey)", it is not a security group issue. It is most likely one of the following:
You didn't specify the public key to use when launching some of the instances.
There was a problem with the metadata service on some of the instances which meant that cloud-init was unable to retrieve the public key.
You are using the wrong credentials; e.g. the admin account name is different on the different instances. (The default is OS dependent.)
You have multiple keys in your ~/.ssh directory and they are being tried in the wrong order. If you have fail2ban set up on the server side, each time that the client supplies a key counts as a login attempt. You can hit the limit before you tried the key that is going to work.
If you look at the respective instance's console log from their first boot, you can see which public keys were actually used. This can be used to diagnose 1 and 2.
For 3, check the OS documentation.
For 4, try using the ssh command's -i option to specify the path to the private key file.
There are other possibilities; e.g. if you launched instances from a non-pristine image / snaphot.
Reference:
Troubleshooting SSH access to a NeCTAR instance
My apps using bonjour service to conversation with each other via local network.
I am facing a problem on Xcode12 with OS14 device.
A device publish a service with server type name depends on self device IP address
(example: 192.168.33.20 -> _1921683320._tcp)
B device searching a service with service type depends on A device IP address
(example: _1921683320._tcp)
According to apple document..From OS14~
https://developer.apple.com/documentation/multipeerconnectivity
Important
Apps that use the local network must provide a usage string in their Info.plist with the key NSLocalNetworkUsageDescription. Apps that use Bonjour must also declare the services they browse, using the NSBonjourServices key.
because my service type name is named by local network ip, it is changeable base on local network setting, so I am thinking about to using wildcard to define the service type name.
example: _*._tcp
but seems wildcard is not available on this definition.(I tried it)
I am also thinking about changing the naming method on A device
(example: 192.168.33.20 -> _20._tcp)
and add _1.tcp ~ _255.tcp to info-plist
But if I changed the naming method, B device could not find A device until version up.
Any idea for this problem? Please help.
I'm currently working through the same issue - Bonjour service name is dynamically created based off the iPad name to form a local mesh network. The conclusion that I have came to is com.apple.developer.networking.multicast is required for this to function without completely overhauling how all that logic is done. (More info here)
You will have to request permission from apple by filling out a form here. Let me know if this works for you!
The thing I am finding is, you "might" not be able to use a wildcard, but you can put multiple entries in the plist:
Item 0 _multicastapp0-p._tcp
Item 1 _multicastapp1-p._tcp
Item 2 _multicastapp2-p._tcp
Item 3 _multicastapp3-p._tcp
etc
Item N _multicastappN-p._tcp
So for some reason if you are trying to have multiple "Groups" of 8 or have a device have it's own "collection" i.e. be a server and have 3 devices connect to that, you can.
I haven't "fully" tested but I am going to be doing this in my apps, I did test using multiple keys tho, but not fully, no errors...
I have been using Openshift/Kubernates for some time and this has been the understanding.
For service to service communication
use DNS name of ${service-name} if they are under the same namespace
use DNS name of ${service-name}.${namespace}.svc.cluster.local if they are from different namespaces (network is joined)
Recently i was introduced with the topic of "we should add a dot after the svc.cluster.local to make it FQDN, for better DNS lookup speed". Done some testing and indeed with lookup is much faster with the dot. (~100ms without dot, 10ms with dot)
After some research, it was caused by the default dns setting from the kubernates
sh-4.2$ cat /etc/resolv.conf
search ${namespace}.svc.cluster.local svc.cluster.local cluster.local
nameserver X.X.X.X
options ndots:5
the ndots = 5 will perform a local search (sequential) if the dns name does not contain 5 dots.
In the case of ${service-name}.${namespace}.svc.cluster.local, the local search will be as such
${service-name}.${namespace}.svc.cluster.local + ${namespace}.svc.cluster.local // FAILED LOOKUP
${service-name}.${namespace}.svc.cluster.local + svc.cluster.local // FAILED LOOKUP
${service-name}.${namespace}.svc.cluster.local + cluster.local // FAILED LOOKUP
${service-name}.${namespace}.svc.cluster.local // SUCCESS LOOKUP
And for ${service-name}.${namespace}.svc.cluster.local., the local search will be as such
${service-name}.${namespace}.svc.cluster.local // SUCCESS LOOKUP
References
link
how to debug
Questions:
Since the ndots = 5 is the default setting for kubernetes, why ${service-name}.${namespace}.svc.cluster.local. is not documented on the official side ?
Should we change all service call to ${service-name}.${namespace}.svc.cluster.local. ? any potential downsides ?
Since the ndots = 5 is the default setting for kubernetes, why
${service-name}.${namespace}.svc.cluster.local. is not documented on
the official side ?
Well, it's a really good question. I searched through the official docs and it looks like this is not a documented feature. For this reason much better place for posting your doubts and also request for documentation improvement is the official GitHub site of Kubernetes DNS.
Should we change all service call to
${service-name}.${namespace}.svc.cluster.local. ? any potential
downsides ?
If it works well for you and definitely increases the performance, I would say - Why not ? I can't see any potential downsides here. By adding the last dot you're simply omitting those first 3 lookups that are doomed to failure anyway if you use Service domain name in a form of ${service-name}.${namespace}.svc.cluster.local
Inferring from lookup process you described and your tests, I guess if you use only ${service-name} (of course only within the same namespace), dns lookup should be also much faster and closer to those 10ms you observed when using ${namespace}.svc.cluster.local svc.cluster.local cluster.local. as then it is matched in the very first iteration.
Based on the latest document here, it states that that we should use ${service}.${namespace} to call a service from different namespace and expect to resolve on the second attempt
I've gotten pretty far into a deployment of my Meteor application on Distelli. Like, almost there. I've done everything as far as setting up the EC2 box, creating a user group [which didn't even seem necessary as I was able to SSH into the box with full rights without specifying my machine's IP], creating an elastic IP, successful build, and deployment to that box. But, I can't seem to check if Meteor is actually running (note: when I ssh in, there are active instances of Mongo and Node, so SOMETHING is running).
The problem has something to do with associating the elastic IP with my ROOT_URL and domain. I'm just not sure what to do at this step and can't seem to find any directions that are Meteor specific. Been using these guides:
https://www.distelli.com/docs/tutorials/how-to-set-up-aws-ec2
https://www.distelli.com/docs/tutorials/deploying-meteor-applications
http://gregblogs.com/tlt-associate-a-namecheap-domain-with-an-amazon-ec2-instance/
Recap: Distelli deployment is a success, but I get the follow error just before finishing:
Error: $ROOT_URL, if specified, must be an URL
I've set my ROOT_URL to my domain, and associated according to the previous guide. I can run traceroute on the IP, but like port 3000, so my inclination is the Meteor build is silently failing.
My manifest: https://gist.github.com/newswim/c642bd9a1cf136da73c3
I've noticed that when I point the CNAME record to my ec2 public DNS, NameCheap (aptly named) adds a . to the end of the record. Beyond that, I'm pretty much stumped.
How to create data base link in oracle 11 g to Access Tables.
You seem to have copied the example in the documentation without really understanding it.
The USING 'local' part of the statement is creating a link to 'the local database', where local is the service name of a database. (The example is a bit confusing, to be fair).
When the link is used it tries to interpret local as a service name, appending the current database's domain, as the docs say:
USING 'connect string'
Specify the service name of a remote database. If you specify only the
database name, then Oracle Database implicitly appends the database
domain to the connect string to create a complete service name.
Therefore, if the database domain of the remote database is different
from that of the current database, then you must specify the complete
service name.
If you're trying to create a link back into the same database - which would be a bit odd but I've seen it done in place of grant access across schemas, and that seems to be what the example is hinting at - then you can replace 'local' in the USING clause with the service name of your current database (e.g. USING 'orcl', or whatever).
You can also use a TNS alias; if your tnsnames.ora has an entry for SOME_DB which points to the SID or service name of another database, you can have USING'some_db'`. You should be able to use any connect string I think; certainly Easy Connect is allowed. There's more in the net services admin guide.