azure::storage provides a class operation_context which has set_proxy() and set_default_proxy() methods. However, I could not find any info on how to use it.
For example, how do I make sure that a cloud_blob_client created afterwards will use the operation?
I'm assuming that the static version of the method (i.e. set_default_proxy()) will affect all instances of operation.
Will all cloud_blob_client instances use it?
Usage of web::http::client::http_client with proxy is more obvious. I can use the following code to configure the client with a proxy:
http_client_config config;
config.set_proxy(web_proxy(web_proxy::use_default));
http_client(uri, config);
set_default_proxy() worked for me as long as web_proxy was configured with a proxy address. That is, web_proxy::use_default and web_proxy::use_discovery did not work although I had proxy settings defined for current user on Windows.
Related
We have a number of (developer) existDb database servers, and some staging/production servers.
Each have their own configuration, that are slightly different.
We need to select which configuration to load and use in queries.
The configuration is to be stored in an XML file within the repository.
However, when syncing the content of the servers, a single burnt-in XML file is not sufficient, since it is overwritten during copying from the other server.
For this, we need the physical name of the actual database server.
The only function found, request:get-server-name that is not quite stable since a single eXist server can be accessed through a number of various (localhost, intranet or external) URLs. However, that leads to unnecessary duplication of the configuration, one for each external URL...
(Accessing some local files in the file system is not secure and not fast.)
How to get the physical name of the existDb server from XQuery?
I m sorry but I don't fully understand your question, are you talking about exist's default conf.xml or your own configuration file that you need to store in a VCS repo? Should the xquery be executed on one instance and trigger an event in all others, or just some, or...? Without some code it is difficult to see why and when something gets overwritten.
you could try console:jmx-token which does not vary depending on URL (at least it shouldn't)
Also you might find it much easier to use a docker based approach. Either with multiple instances coordinated via docker-compose or to keep the individual configs from not interfering with each other when moving from dev to staging to production https://github.com/duncdrum/exist-docker
If I understand correctly, you basically want to be able to get the hostname or the IP address of a server from XQuery. If the functions in the XQuery Request module are not doing as you wish, then another option would be to set a Java System Property when starting eXist-db. This system property could be the internal DNS name or IP of your server, for example: -Dour-server-name=server1.mydomain.com
From XQuery you could then read that Java System property using util:system-property("our-server-name").
Can I use IBM IIB mqsichangeproperties to change SOAPRequest WebService URL. This will help in avoiding a redeployment when the URLs change slightly without any change to the XSDs. Also helps when migrating from test to production
I think not, normally the command can affect SOAPInput SOAPReply nodes and to modify in SOAPRequest I would use mqsiapplybaroverride, verifying exactly as it is called in the URL bar with mqsireadbar. The downside is you have to redeploy.
mqsichangeproperties would help you change the hostname of IntegrationNode. The hostname will change for different environments from test to PROD as you will have different Integration Nodes for each of em.What you will change is the suffix like in the URI
http://hostname:7080/ProductDetails_v3
Which you could do by overriding it using a properties file with mqsiapplybaroverride or you can fetch the suffix from a DB store it in some variable & provide it in LocalEnvironment before making the request.
Please refer the link for LocalEnvironment Overrides for SOAPRequest Nodes
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac56192_.htm
I need to install multiple iDempiere instances in one server. The customized packages are different in build and the db they are using. Is there any way to deploy both of it in one server and access like localhost:8080/client1, localhost:8080/client2 . Any help appreciated.
When I want to reference several application servers I need to copy the path of various installations
and change the database name and port of each application :
/opt/idempiere-server-production/ (on port 8080 for example) for production
And
/opt/idempiere-server-test/ (on port 8081 for example) for test
the way you said is not possible, because the idempiere server for webapp is known as
http://hostname:port/webui
Running multiple instances of idempiere on a single server is not too difficult.
Here is what you need to take care of:
Install the instances into different directories. The instances do not need to share any common files. So you are just fine making a full installation for each instance.
Make sure each instance uses its own data base. Use different names for the instance data bases.
Make sure the idempiere server instances use different tcp ports.
If you really should need to use a single port to access all of the instances you could use a http server like apache or ngnix to do define virtual hosts. Proxying or use of rewrite rules will then allow you to do the desired redirections. (I am using subdomains and apache mod_proxy to do the job)
There is another benefit to using subdomains for browser access: If all your server instances use the same host name the client browser will sometimes not be able to keep cookies from different instances apart, which can lead to a blocked session as discussed here in the idempiere google group.
Use different DB user names. The docs advise not to change the default user name Adempiere and this is ok for a single instance installation. Still if you use a single DB user for all of your instances you will run into trouble once you need to restore a database from a backup file. The RUN_DBRestore.sh will delete and recreate the DB user which is not possible when the user owns more than one DB.
You can run all of your instances as services in parallel. Before the installation of another instance rename the service script: sudo mv /etc/init.d/idempiere /etc/init.d/idempiere-theInstance. Of course you will need to do some book keeping work wth the service controller of your OS to ensure that the renamed services are started as desired.
The service controller talks to the iDempiere server via the OSGI console. For this to work without problems in a multi instance environment you need to assign a different telnet port number to each of the instances: in the editor of your choice open the file /etc/init.d/iDempiere. Find the line export TELNET_PORT=12612 and change the port number to something else.
Please Note:
OS specific descriptions in this guide are for Ubuntu 16/18 or Debian, if on another OS you need to do some research.
I have been using the described approach to host idempiere versions 5 and 6 for some time now and did not have any problems so far. Still make sure you do your own thorough tests if you want to go that route.
If you run into any problems (and maybe even manage to solve them) please report back to the community. (by giving your own answer to this question or by posting to the idempiere google group) Thanks!
You can have as many setups on your server as you like. When you run the setup to create your properties, simply chose other web ports for each installation. You also may need to slightly change the webservers configuration if they have some default ports.
I wrote simple function for my puppet module. It makes some requests using puppetdb API and I need IP address of puppetdb server. Is there correct way to get settings of connection PuppetMaster to puppetdb to get address of puppetdb server or I should parse puppet.conf by hand?
Parsing puppetdb.conf by hand would be the least desirable way to go about it.
Looking at the code that loads the config, it should be possible to access it using
settings_value = Puppet::Util::Puppetdb.config['main'][setting_name]
for configuration options from the [main] section.
Looking at even more code, you should even be able to use
Puppet::Util::Puppetdb.server
Puppet::Util::Puppetdb.port
I'm not entirely sure whether those APIs are available from parser functions, but it's worth a shot.
I have an rspec testsuite that I use to test our internal and public facing API. Usually all I have to do to test the service is setup my parameters (e.g test urls) and from there the tests connect to the required service and do their thing.
My question is, how to I get ruby to honor my host file entries? In this specific scenario I'm trying to hit our pre-live servers, which use the same urls as our live environment, but obviously are on an entirely different IP cluster.
Unless you are doing some very low-level stuff, Ruby will not perform DNS name resolution by itself, it will simply call the appropriate OS API. So, you need to figure out how to configure your operating system to use a local hosts file.