The flag cluster.system-replication-factor doesn't seem to be available in 3.4.2 , can anyone help with this
arango starter command
We have tried the above command (click on the above link) in our arangoserver which runs with arangodb 3.4.2 version
--cluster.system-replication-factor is an arangod option, it has to be passed to an ArangoDB Server.
https://docs.arangodb.com/3.4/Manual/Programs/Arangod/Options.html#cluster-options
Options for arangod that are not supported by the starter (arangodb) can still be passed to the database servers using a pass through option. Every option that start with a pass through prefix is passed through to the commandline of one or more server instances.
https://docs.arangodb.com/3.4/Manual/Programs/Starter/Options.html#other-database-options
Therefore the following option has to be specified:
arangodb --all.cluster.system-replication-factor=<uint32-value>
Related
Is it possible to generate a new foxx app in an arbitrary location?
foxx-manager install EMPTY /some-app
creates and installs some-app from the default /var/lib/arangodb-apps location. I'm running ArangoDB 2.7.1. I've tried the --javascript.app-path switch, but it isn't recognized as an option even though it's referenced here
The javascript.app-path switch should work (alternatively you can try using the app-path setting in the javascript section of your arangod.conf) but it will be used for all Foxx apps. However this is an option of the arangod server (which performs the actual installation of Foxx apps), not of the foxx-manager CLI (which just tells the server what to install).
There's no way to install a Foxx app outside the app-path. Mount paths are always translated to paths that are relative to the app-path.
You're saying the switch isn't recognized. Can you give an example of how you tried to use it and the error message you received? Are you running arangod directly? And have you made sure there isn't already a daemonized version of arangod running in the background?
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.
Is is possible to run Protractor in any other way except using CLI?
Is there an API call which will simulate the command: 'protractor config file.js'?
I would like to start a test through a node-webkit application, and even though I can connect directly to the ChromeDriver through the directConnect parameter, this is no use if I can't run protractor from inside the script.
Of course, this is in an environment where Node and Protractor aren't available from CLI... simulating a distribution environment where the user doesn't have to install additional apps apart from my node-webkit (hence the node-webkit usage).
Thank you in advance for any pointers!
The protractor command line script boils down to invoking lib/cli.js which mostly deals with parsing commmand-line arguments and then invokes lib/launcher.js to actually start protractor.
I don't think any special concessions have been made in these files to be directly invoked programmatically, but I don't see any particular hurdles either.
I'm working on extending the puppetlabs-mongodb module to allow for user authentication. The challenge is that mongo changed its mechanism for enabling user authentication between version 2.2 and version 2.4 and so distinct code must be run in order to give a user authentication credentials to a database.
My initial thought was to create a custom facter fact that basically captured the output of mongod --version, but it appears that facter facts are loaded before the puppet manifest is executed. Is there a way to execute arbitrary code at run time during puppet execution so that I can access mongod --version and decide which method to use to enable user authentication?
Note: One approach would be to have puppet run a single script to create user credentials and have the script detect the mongod --version at runtime. This doesn't seem like a very puppet-y way of doing things, but perhaps I am off base on that. What is the best way to handle the need for accessing variables dynamically in puppet/facter?
The word from #puppetlabs is that you can not run ruby code (or any other code) dynamically during a puppet run. The "right" way to do this is in the note above with an exec statement that dynamically checks for the mongodb version. For details on the implementation, see manifests/add_user.pp and the associated templates/add_user*.erb.
If anyone has a more "puppety" method for accomplishing this, I'd love to learn about it!
Just put your Ruby code in a ERB template and use template("${module_name}/templ.erb") to return your version string.
We are trying to use node.js app to connect to Oracle 11g server (Enterprise Edition 11.2.0.1.0 - 64bit production) from an Ubuntu 12.04.1 LTS server. We are running Node v0.10.12 and the nearinfinity node-oracle module 0.3.1. There are other posts here on stackoverflow that talk about the other node oracle module node-db-oracle, but that version is no longer maintained and cannot be built with Node 0.10.12 due to node-waf being deprecated.
Even the tiniest Node program will not connect even though using the same connection info we can connect from the sqlplus64 client and a simple 3 line PHP program. We have tried all the different options for connecting, such as specifying all the connection info in the json passed to connect function, specifying just user, password, and referencing a connection string in the oracle tnsnames.ora file, or even passing the connection string directly to the json. We get one of two errors:
Error: ORA-12154: TNS:could not resolve the connect identifier specified
or if we change the parameters a bit:
Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
I have tried connecting to different Oracle servers in our datacenter: one single server using the SID=databasename convention and a RAC system using the SERVICE_NAME=database_servicename convention. Same story both cases.
I have looked at all the other Node.js/Oracle posts here and have tried everything they speak of. Firing up sqlplus64 username/password#SID_NAME connects immediately. I am beginning to conclude that the combination of versions I am using simply do not work together. Any ideas?
The solution was to use a recent patch to the module that hasn't been released yet. The current release is 0.3.1 of node-oracle. That version does not have the TNS support fix. If you check out the latest code for the module from github to a new directory and build it there ('npm link' in that directory) and then do npm link oracle from your project directory you will get the new version with the fix. We had to work through a number of permission problem which are most likely platform specific so I won't delve into those here. I have requested that the authors of the module release this patched version soon presumable as 0.3.2.