I am trying out Shield as a security measure for my Kibana and Elasticsearch. Running on Mac OS X 10.9.5
Followed the documentation from Elastic. Managed to install Shield. Since my Elasticsearch is running automatically, I skipped step 2(start elasticsearch).
For step 3, I tried adding an admin. Ran this following command on my terminal. bin/shield/esusers useradd admin -p password -r admin.
Unfortunately I'm getting this error.
Error: Could not find or load main class org.elasticsearch.shield.authc.esusers.tool.ESUsersTool
Below are the additional steps I took.
Double checked that the bin/shield esusers path existed and all.
Manually starting elasticsearch before adding users
Tried a variety of different commands based on the documentation.
bin/shield/esusers useradd admin -r admin and
bin/shield/esusers useradd es_admin -r admin
Ran those commands with sudo
Same error generated. Can't seem to find the problem on google as well. Not really sure what I'm missing here as the documentation seems pretty straightforward.
You must restart the node because new Java classes were added to it (from the Shield plugin) and the JVM behind Elasticsearch needs to reload those classes. It can only do that if you restart it.
Kill the process and start it up again, or use curl -XPOST "http://localhost:9200/_shutdown" to shut the cluster down.
Also, the Shield plugin needs to be installed on all the nodes in the cluster.
Related
I am running Elasticsearch and kibana, I am not sure of the status of my elasticsearsh cluster (if its red, yellow, or green) but it seems I need to get a token generated by elasticsearch as in the screenshot when I ran bin/elasticsearch-create-enrollment-token --scope kibana from the right directory it errors out ERROR: Failed to determine the health of the cluster..
According Ioannis Kakavas in discuss.elastic, "CLI tools extending BaseRunAsSuperuserCommand should only connect to the local node". When I run in a local node, it works. But when I run in the elasticsearch container in a cluster, it doesn't work. The solution was execute the elastic-search-reset-password and elasticsearch-create-enrollment-token scripts, respectively, like this (inside the elasticsearch container):
/usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic --url https://localhost:9200
/usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana --url https://localhost:9200
I encountered the same problem, and I just redid the process - unzipped the ES and kibana zip files again, and ran bin/elasticsearch in the newly created directory. Look for a message that is encapsulated in a formatted box that contains both the password for the elastic user, and the enrollment token for Kibana (the token is only valid for 30 minutes). This message will only appear once, the first time you run elasticsearch.
I proceeded to run bin/kibana for Kibana and configured it in the browser, and everything worked out from there. Hope this helps!
I have the exact issue:
$ sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic
ERROR: Failed to determine the health of the cluster.
But after I restart the elasticsearch service:
$ sudo systemctl restart elasticsearch.service
then it works:
This tool will reset the password of the [elastic] user to an autogenerated value.
The password will be printed in the console.
Please confirm that you would like to continue [y/N]y
Password for the [elastic] user successfully reset.
New value: xxxxxx
Two possible solutions:
Make sure that you have enough disk space.
Your VPN might be causing the issue.
The enrollment Token will be present in the terminal itself. You just need to scroll up till you find it when you are installing.
The reason for the error - ERROR: Failed to determine the health of the cluster is due to the fact that Elastic has not been installed yet and running that command is like calling a function without defining it.
I'm a student working on a test cluster, consisting of around 25 hosts. We installed using Ambari and have FreeIpa running on a host as a dns and ldap server. The rest are typical Hadoop
infrastructure. Hive was failing and I wondered whether the db connection parameters used during the Ambari installation were incorrect and I tried to find a way to re-run the db connection process. I didn't get anywhere and it was late so I left it, ambari interface working.
Next morning, ambari webUI seems to be down. I thought that maybe the webserver needed restarted so I tried the following:
[akidd#dw ~]$ sudo ambari-server start
Using python /usr/bin/python
Starting ambari-server
ERROR: Exiting with exit code 1.
REASON: Unable to detect a system user for Ambari Server.
- If this is a new setup, then run the "ambari-server setup" command to create the user
- If this is an upgrade of an existing setup, run the "ambari-server upgrade" command.
Refer to the Ambari documentation for more information on setup and upgrade.
Can anyone help me to understand what could have happened?
If I run ambari-server setup will the existing cluster be ok assuming I create everything like for like with how it was originally?
Thanks for your help!
#user3535074 You should try to start it with the user that installed it.
If you do run ambari-server setup as current user, remember to choose No the following options:
Customize user account for ambari-server daemon [y/n] (n)? n
Do you want to change Oracle JDK [y/n] (n)? n
Enter advanced database configuration [y/n] (n)? n
More info on the following post, including how to backup ambari database before running setup again:
https://community.cloudera.com/t5/Support-Questions/Ambari-server-failed-to-start-after-system-reboot-Below-is/td-p/203806
How to spin up a local version of Spinnaker? This has been answered and addressed in detail here.
https://github.com/spinnaker/spinnaker/issues/1729
Ok, so I got it to work, but not without you valuable help! #lwander
So I'll leave the steps here for posterity.
Each line is a separate command in the command line, I've installed this on a virtual machine with a freshly installed Ubuntu 14.04 copy with nothing else than SSH. Then SSH as root, You will need to configure sshd on your console to allow root access.
https://askubuntu.com/questions/469143/how-to-enable-ssh-root-access-on-ubuntu-14-04
> curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/stable/InstallHalyard.sh
created a user account member of the adm and sudo groups (is this necessary???)
then Install Halyard:
bash InstallHalyard.sh
Verify that HAL is installed and validate its version.
hal -v
Tell Hal that the deployment type will be as a local instance (this will publish all services in localhost which will be tricky later in order to access them, but I have a turnaround so keep reading)
hal config deploy edit --type localdebian
Hal will complain that a version has not been selected, just tell HAL which version:
hal config version edit --version 1.0.0
The tell HAL which storage you are going to use, in my case and since it is local I want to use redis.
hal config storage edit --type redis
So now we need to add a cloud provider to HAL, we use AWS so we add it like this:
hal config provider aws edit --access-key-idXXXXXXXXXXXXXXXXXXXX--secret-access-key
I created a user on AWS and added access keys to the user inside IAM on the user security credentials tab. Obviously my access-key-idis not XXXXXXXXXXXXXXXXXXXX, I edited it. You do not need to enter the secret-access-key because the command will prompt for it.
Then you need to create a username relative or that will only concern you spinnaker installation however this will get related to you AWS Account-ID, so in MY spinnaker local installation I chose the username spinnakermaster you should choose yours!. And my AWS Account ID is not YYYYYYYYYYYY, I've edited too.
All the configurations and steps that you'll need to do inside AWS for this to work are really well documented here:
[https://www.spinnaker.io/setup/providers/aws/](https://www.spinnaker.io/setup/providers/aws/
)
And to tell HAL of of the above here's the command:
hal config provider aws account add spinnakermaster --account-id YYYYYYYYYYYY --assume-role role/spinnakerManaged
And after all that and if everything went according to plan we can ask HAL to deploy our brand new spinnaker installation.
hal deploy apply
It will begin a long installation downloading and configuring all the services.
Once it has finished you may do whatever you like but in my case I created a monitoring script like the one described here:
https://github.com/spinnaker/spinnaker/issues/854
Which can be launched on a recursive manner as this:
watch -n1 spinnaker-status.shor until toctrl+Cit!.
then to be able to access your local VM spinnaker copy you can either setup a reverse proxy with the proxy server of your choice to forward all the requests to localhost or you can simply ssh the SH** out of this redirecting the ports;
ssh root#ZZZ.ZZZ.ZZZ.ZZZ -L 9000:127.0.0.1:9000 -L 8084:127.0.0.1:8084 -L 8083:127.0.0.1:8083 -L 7002:127.0.0.1:7002 -L 8087:127.0.0.1:8087 -L 8080:127.0.0.1:8080 -L 8088:127.0.0.1:8088 -L 8089:127.0.0.1:8089
Where obviously theZZZ.ZZZ.ZZZ.ZZZ is not an actual IP Address.
And finally to begin having fun with this cutie you have to go to your browser of choice and type into the address bar:
http://127.0.0.0:9000
Hope this helps and saves some time to everybody!.
Cheers.
EN
I am trying to setup a CouchDB cluster with some Raspberry Pi for a edge computing project. But all I did until now wasn't successful. I don't get a cluster working correctly.
This is what I did:
I followed the setup guide from
http://docs.couchdb.org/en/2.0.0/install/unix.html#
in combination with:
https://medium.com/linagora-engineering/setting-up-a-couchdb-2-cluster-on-centos-7-8cbf32ae619f#.eopseqi4h
Installing the dependencies - worked without error
./configure - worked without error
make release - worked without error
Following the guide: Add couchdb user:
adduser --system --no-create-home --shell /bin/bash --group --gecos
"CouchDB Administrator" couchdb
worked without error
mv rel/couchdb /usr/local/ - worked without error
chown -R couchdb:couchdb /usr/local/couchdb - didn't work in first place - no usergroup couchdb - added usergroup
changed node-name in /usr/local/couchdb/etc/vm.args: -name n1.couch.local added -kernel inet_dist_listen_min 9100and
-kernel inet_dist_listen_max 9200 - didn't work - changed back to couchdb#localhost
staring db
su - couchdb
cd /usr/local/couchdb
./bin/couchdb
-didn't work for me in first place, su pw - Authentication failed - switched user by sudo su and su - couchdb
db starts - runs, but throws error (ignored error for now, because db is running):
[error] 2017-02-17T12:34:26.672758Z couchdb#localhost emulator ------
-- Error in process <0.354.0> on node 'couchdb#localhost' with exit
value: {database_does_not_exist,
[{mem3_shards,load_shards_from_db,"_users",
[{file,"src/mem3_shards.erl"},{line,327}]},
{mem3_shards,load_shards_from_disk,1,[{file,"src/mem3_shards.erl"},
{line,315}]},{mem3_shards,load_shards_from_disk...
[notice] 2017-02-17T12:34:26.672918Z couchdb#localhost <0.353.0> ----
---- chttpd_auth_cache changes listener died database_does_not_exist
at mem3_shards:load_shards_from_db/6(line:327) <=
mem3_shards:load_shards_from_disk/1(line:315) <=
mem3_shards:load_shards_from_disk/2(line:331) <=
mem3_shards:for_docid/3(line:87) <= fabric_doc_open:go/3(line:38) <=
chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <=
chttpd_auth_cache:listen_for_changes/1(line:134)
prepared two Raspberry Pi (2 CouchDB nodes) for cluster mode:
curl -X PUT http://127.0.0.1:5984/_node/couchdb#localhost/
_config/admins/admin -d '"conmonmrp"'`
answer:
"-pbkdf2-9ec43ace4195ee45a37773c9dfc2aba9380468cb,
cddfb98dd1b2416dea2b53dc9fe9a31b,10"
and
`curl -X PUT http://127.0.0.1:5984/_node/couchdb#localhost/
_config/chttpd/bind_address -d '"0.0.0.0"'`
answer: "0.0.0.0"
seems like commands have been accepted
Went on localhost:5984/_utils/ and tried to setup cluster - entered credentials (did not change IP and port) and added another node by IP (network IP, i.e. 10.228.101.210), created cluster to finish setup - fauxton accepted that without an error.
trying to get all nodes in the cluster by localhost:5984/_membership/ results in:
{"all_nodes":["couchdb#localhost"],"cluster_nodes":
["couchdb#10.228.101.210","couchdb#localhost"]}`
trying to add a database on one node and see it on another one doesn't work
I'am really new to that CouchDB thing at all, but I need to get that cluster running. I hope, my discription helps to find the problem. Altogether I got the feeling, that I am missing or missunderstandig an important point on that.
Best regards from Hamburg, DE
After having some trouble with setting up the cluster, a friend found the problem. It is necessary to change the name of the node in the /couchdb/etc/vm.args file. As I read in another post it is illegal to name it #localhost. I changed that to the IP-address of the device.
After that, everything works fine for me now.
Remember also, when setting up a cluster and finding issues when adding or restarting, etc... Make sure your "cookie" doesn't have spaces.
Installing MarkLogic 8 on CentOS 6.7 x64 via DigitalOcean
Okay so I downloaded the rpm file from:
https://developer.marklogic.com/download/binaries/8.0/MarkLogic-8.0-3.2.x86_64.rpm
I installed it with:
sudo yum install MarkLogic-8.0-3.2.x86_64.rpm
Started it:
sudo /etc/init.d/MarkLogic start
Went to admin interface:
my_ip_address:8001
I skip joining a cluster
I type in admin for user
Type in a password and confirm it
Realm is public
I click OK and...
I get redirected to:
my_ip_address:8001/security-install-go.xqy
And get this:
No data received
ERR_EMPTY_RESPONSE
Hide details
Unable to load the webpage because the server sent no data.
Reload this webpage
Press the reload button to resubmit the data needed to load the page.
Okay I got it to work.
The only difference I can see this time around was I followed this script (save the nginx stuff):
https://github.com/jmakeig/marklogic-bootstrapping/blob/master/digitalocean/bootstrap.sh
Actually, someone else ran into this and after investigating everything else I tried, this was the answer:
http://developer.marklogic.com/pipermail/general/2015-January/016311.html
The MarkLogic data directory /var/opt/MarkLogic wasn't owned by the daemon user