# Any other way to cleanly shut down ElasticSearch other than CTRL+C on a console? **URL:** \ **Category:** Elasticsearch\ **Created:** [March 14, 2011, 3:15pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092 "2011-03-14T15:15:15Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Administrator\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/administrator_2/32/3211_2.png) [@Administrator\_2](https://discuss.elastic.co/u/Administrator_2)\ **Post date:** [March 14, 2011, 3:15pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/1 "2011-03-14T15:15:15Z")
``` I'm spawning ElasticSearch through a Process in .NET and I ``` want to shut it down gracefully (not just kill the process). ``` However, the Process class in .NET does not create a process ``` group which is what is required to use the API to send the console event. ``` That said, is there another way to cleanly shut down ES ``` without using CTRL+C on a console (btw, service installs are out as well, can't install the service on this machine). ``` Thanks in advance. - Nick ``` ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [March 14, 2011, 3:30pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/2 "2011-03-14T15:30:01Z")
Hi Nick > ``` > That said, is there another way to cleanly shut down > > ``` > > ES without using CTRL+C on a console (btw, service installs are out as > well, can’t install the service on this machine). You can use the shutdown API: > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. clint ---
**Author:** ![Administrator\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/administrator_2/32/3211_2.png) [@Administrator\_2](https://discuss.elastic.co/u/Administrator_2)\ **Post date:** [March 14, 2011, 3:49pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/3 "2011-03-14T15:49:56Z")
Clinton, ``` Thank you, that works. It brings up an interesting question. How is one supposed to secure access against things like this? I love ES (even though I can't even begin to get it to run how I want it to in Azure), but security seems to be a big gaping hole that's lacking. What I'd really like to see is a) basic authentication for the http transport coupled with b) setting a certificate for use for HTTPS Those two things would go a ^long^ way towards addressing the security issue. Or am I missing something? - Nick ``` -----Original Message----- From: Clinton Gormley [[mailto:clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)] Sent: Monday, March 14, 2011 11:30 AM To: [users@elasticsearch.com](mailto:users@elasticsearch.com) Subject: Re: Any other way to cleanly shut down Elasticsearch other than CTRL+C on a console? Hi Nick > ``` > That said, is there another way to cleanly shut down > > ``` > > ES without using CTRL+C on a console (btw, service installs are out as > well, can’t install the service on this machine). You can use the shutdown API: > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. clint ---
**Author:** ![Paul\_Loy](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@Paul\_Loy](https://discuss.elastic.co/u/Paul_Loy)\ **Post date:** [March 14, 2011, 4:06pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/4 "2011-03-14T16:06:41Z")
We proxy it. Only allowing safe operations to permiate through haproxy to the interwebs. The firewall stops direct access. Then, when we want to do admin things, we just ssh into the boxes. On Mon, Mar 14, 2011 at 3:49 PM, Administrator [admin@sf4answers.com](mailto:admin@sf4answers.com) wrote: > Clinton, > > ``` > Thank you, that works. > > It brings up an interesting question. How is one supposed to secure > > ``` > > access against things like this? I love ES (even though I can't even begin > to get it to run how I want it to in Azure), but security seems to be a big > gaping hole that's lacking. > > ``` > What I'd really like to see is a) basic authentication for the http > > ``` > > transport coupled with b) setting a certificate for use for HTTPS > > ``` > Those two things would go a ^long^ way towards addressing the > > ``` > > security issue. > > ``` > Or am I missing something? > > - Nick > > ``` > > -----Original Message----- > From: Clinton Gormley [[mailto:clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)] > Sent: Monday, March 14, 2011 11:30 AM > To: [users@elasticsearch.com](mailto:users@elasticsearch.com) > Subject: Re: Any other way to cleanly shut down Elasticsearch other than > CTRL+C on a console? > > Hi Nick > > > ``` > > That said, is there another way to cleanly shut down > > > > ``` > > > > ES without using CTRL+C on a console (btw, service installs are out as > > well, can’t install the service on this machine). > > You can use the shutdown API: > > [Elastic — The Search AI Company | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html) > > clint ## -- Paul Loy [paul@keteracel.com](mailto:paul@keteracel.com) [http://uk.linkedin.com/in/paulloy](http://uk.linkedin.com/in/paulloy) ---
**Author:** ![Paul\_Loy](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@Paul\_Loy](https://discuss.elastic.co/u/Paul_Loy)\ **Post date:** [March 14, 2011, 4:07pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/5 "2011-03-14T16:07:04Z")
(we use haproxy as it loadbalances too 😃 ) On Mon, Mar 14, 2011 at 4:06 PM, Paul Loy [keteracel@gmail.com](mailto:keteracel@gmail.com) wrote: > We proxy it. Only allowing safe operations to permiate through haproxy to > the interwebs. The firewall stops direct access. Then, when we want to do > admin things, we just ssh into the boxes. > > On Mon, Mar 14, 2011 at 3:49 PM, Administrator [admin@sf4answers.com](mailto:admin@sf4answers.com)wrote: > > > Clinton, > > > > ``` > > Thank you, that works. > > > > It brings up an interesting question. How is one supposed to > > > > ``` > > > > secure access against things like this? I love ES (even though I can't even > > begin to get it to run how I want it to in Azure), but security seems to be > > a big gaping hole that's lacking. > > > > ``` > > What I'd really like to see is a) basic authentication for the http > > > > ``` > > > > transport coupled with b) setting a certificate for use for HTTPS > > > > ``` > > Those two things would go a ^long^ way towards addressing the > > > > ``` > > > > security issue. > > > > ``` > > Or am I missing something? > > > > - Nick > > > > ``` > > > > -----Original Message----- > > From: Clinton Gormley [[mailto:clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)] > > Sent: Monday, March 14, 2011 11:30 AM > > To: [users@elasticsearch.com](mailto:users@elasticsearch.com) > > Subject: Re: Any other way to cleanly shut down Elasticsearch other than > > CTRL+C on a console? > > > > Hi Nick > > > > > ``` > > > That said, is there another way to cleanly shut down > > > > > > ``` > > > > > > ES without using CTRL+C on a console (btw, service installs are out as > > > well, can’t install the service on this machine). > > > > You can use the shutdown API: > > > > [Elastic — The Search AI Company | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html) > > > > clint > > ## -- > > Paul Loy > [paul@keteracel.com](mailto:paul@keteracel.com) > [Paul Loy - Amihan Entertainment | LinkedIn](http://uk.linkedin.com/in/paulloy) ## -- Paul Loy [paul@keteracel.com](mailto:paul@keteracel.com) [http://uk.linkedin.com/in/paulloy](http://uk.linkedin.com/in/paulloy) ---
**Author:** ![Ivan\_Porto\_Carrero](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ivan_porto_carrero/32/3257_2.png) [@Ivan\_Porto\_Carrero](https://discuss.elastic.co/u/Ivan_Porto_Carrero)\ **Post date:** [March 14, 2011, 4:13pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/6 "2011-03-14T16:13:06Z")
Similar here but an SSL connector would be nice so that the transport inside the datacenter can be secured. - - On Mon, Mar 14, 2011 at 4:06 PM, Paul Loy [keteracel@gmail.com](mailto:keteracel@gmail.com) wrote: > We proxy it. Only allowing safe operations to permiate through haproxy to > the interwebs. The firewall stops direct access. Then, when we want to do > admin things, we just ssh into the boxes. > > On Mon, Mar 14, 2011 at 3:49 PM, Administrator [admin@sf4answers.com](mailto:admin@sf4answers.com)wrote: > > > Clinton, > > > > ``` > > Thank you, that works. > > > > It brings up an interesting question. How is one supposed to > > > > ``` > > > > secure access against things like this? I love ES (even though I can't even > > begin to get it to run how I want it to in Azure), but security seems to be > > a big gaping hole that's lacking. > > > > ``` > > What I'd really like to see is a) basic authentication for the http > > > > ``` > > > > transport coupled with b) setting a certificate for use for HTTPS > > > > ``` > > Those two things would go a ^long^ way towards addressing the > > > > ``` > > > > security issue. > > > > ``` > > Or am I missing something? > > > > - Nick > > > > ``` > > > > -----Original Message----- > > From: Clinton Gormley [[mailto:clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)] > > Sent: Monday, March 14, 2011 11:30 AM > > To: [users@elasticsearch.com](mailto:users@elasticsearch.com) > > Subject: Re: Any other way to cleanly shut down Elasticsearch other than > > CTRL+C on a console? > > > > Hi Nick > > > > > ``` > > > That said, is there another way to cleanly shut down > > > > > > ``` > > > > > > ES without using CTRL+C on a console (btw, service installs are out as > > > well, can’t install the service on this machine). > > > > You can use the shutdown API: > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html) > > > > clint > > ## -- > > Paul Loy > [paul@keteracel.com](mailto:paul@keteracel.com) > [http://uk.linkedin.com/in/paulloy](http://uk.linkedin.com/in/paulloy) ---
**Author:** ![Daniel\_Maher](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@Daniel\_Maher](https://discuss.elastic.co/u/Daniel_Maher)\ **Post date:** [March 14, 2011, 4:29pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/7 "2011-03-14T16:29:13Z")
On Mon, 2011-03-14 at 16:06 +0000, Paul Loy wrote: > We proxy it. Only allowing safe operations to permiate through haproxy > to the interwebs. The firewall stops direct access. Then, when we want > to do admin things, we just ssh into the boxes. > > On Mon, Mar 14, 2011 at 3:49 PM, Administrator [admin@sf4answers.com](mailto:admin@sf4answers.com) > wrote: > Clinton, > > ``` > Thank you, that works. > > It brings up an interesting question. How is one > supposed to secure access against things like this? I love ES > (even though I can't even begin to get it to run how I want it > to in Azure), but security seems to be a big gaping hole > that's lacking. > > What I'd really like to see is a) basic authentication > for the http transport coupled with b) setting a certificate > for use for HTTPS > > Those two things would go a ^long^ way towards > addressing the security issue. > > Or am I missing something? > > ``` Hello, I'm not sure that ES needs to have any sort of authentication or SSL features; as Paul Loy pointed out, it's trivial to proxy ES through a mechanism that is already designed to do those sorts of things, so what would be the interest in bogging down the ES code base with superfluous functionality ? -- Daniel Maher « can't talk, too busy calculating computrons. » ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [March 14, 2011, 4:42pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/8 "2011-03-14T16:42:59Z")
> Hi Daniel > I'm not sure that ES needs to have any sort of authentication or SSL > features; as Paul Loy pointed out, it's trivial to proxy ES through a > mechanism that is already designed to do those sorts of things, so what > would be the interest in bogging down the ES code base with superfluous > functionality ? I both agree and disagree 🙂 I agree: the ES code shouldn't be bogged down by authentication as a standard. However, this is a frequently requested piece of functionality, (especially given that ES is supposed to run in the cloud). While proxying it is easy, the user still has to figure out which proxy they want to use, how to configure it, then they have two run two separate services. I think making authz/authen available as a plugin would be very useful. clint ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [March 14, 2011, 5:45pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/9 "2011-03-14T17:45:33Z")
Heya, Transport level encryption is actually not that difficult to add (SSL). The more complex feature is authentication / authorization. Once we implement that, then we need to have role base support (admin can call shutdown, while other user roles can not), and of course, where is all this info stored (and probably, integration with external user management systems). I don't think proxiying is that difficult to do, and even if elasticsearch supports SSL, I personally will probably proxy it with another system that does the SSL. The fact that it can run in the "cloud" does not mean that it needs to have those features. -shay.banon On Monday, March 14, 2011 at 6:42 PM, Clinton Gormley wrote: Hi Daniel > > I'm not sure that ES needs to have any sort of authentication or SSL > > features; as Paul Loy pointed out, it's trivial to proxy ES through a > > mechanism that is already designed to do those sorts of things, so what > > would be the interest in bogging down the ES code base with superfluous > > functionality ? > > I both agree and disagree 🙂 > > I agree: the ES code shouldn't be bogged down by authentication as a > standard. > > However, this is a frequently requested piece of functionality, > (especially given that ES is supposed to run in the cloud). > > While proxying it is easy, the user still has to figure out which proxy > they want to use, how to configure it, then they have two run two > separate services. > > I think making authz/authen available as a plugin would be very useful. > > clint ---
**Author:** ![IvanBrusic](https://avatars.discourse-cdn.com/v4/letter/i/ecae2f/32.png) [@IvanBrusic](https://discuss.elastic.co/u/IvanBrusic)\ **Post date:** [March 14, 2011, 6:01pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/10 "2011-03-14T18:01:26Z")
On Mar 14, 12:29 pm, Daniel Maher [dma...@milestonelab.com](mailto:dma...@milestonelab.com) wrote: > Hello, > > I'm not sure that ES needs to have any sort of authentication or SSL > features; as Paul Loy pointed out, it's trivial to proxy ES through a > mechanism that is already designed to do those sorts of things, so what > would be the interest in bogging down the ES code base with superfluous > functionality ? I am also in agreement that ES does not need its own authentication as a first-class requirement. Perhaps as a plugin. Many alternative datastores/frameworks, such as Hadoop and MongoDB, do not have authentication built-in. Having security provided at the machine/network level is not only an acceptable use-case, but perhaps might become the dominant one. Ivan ---
**Author:** ![Administrator\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/administrator_2/32/3211_2.png) [@Administrator\_2](https://discuss.elastic.co/u/Administrator_2)\ **Post date:** [March 14, 2011, 6:17pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/11 "2011-03-14T18:17:09Z")
Shay, ``` Respectfully, I think that you understate the last point about running in the cloud; yes, if you are proxying ES then SSL isn’t that much of an important feature, you just have to harden it from access from other computers in the same subnet. However, if you wanted to have a direct-facing instance of ES hosted in the cloud, then SSL would most definitely be a requirement., In regards to authentication, there is a bit of confusion here. The HTTP 1.1 spec (see: http://www.ietf.org/rfc/rfc2616.txt section 14.8 ) is titled “Authorization”. However, this is a bit of a misnomer, IMO. It should really be titled “Authentication” as it relates to credentials and how the user identifies itself to the server according to the HTTP protocol. Authorization is dependent on authentication (you have to know whom you are dealing with), but authentication is not based on authorization. That said, when I refer to “Basic Authentication”, I’m really referring to the Basic Authentication Scheme in HTTP (http://www.webdav.org/specs/rfc2617.html#rfc.section.2), not custom authorization schemes based on authentication. Now if both SSL and Basic Authentication were provided (as per the HTTP specification), it would harden up a direct-facing instance of ES quite nicely; you could use a username/password combination, as well as a certificate to encrypt everything that is passed between the endpoints. Yes, the weak point is the username/password combo, but at least it wouldn’t be able to be viewed in plain text going across the wire, and you could block out anyone who doesn’t have it. Note, I’m not asking for anything other than what the HTTP protocol specifies in these two very specific areas; custom authorization (and authentication as well) is a PITA, many people have many different views on how this should be done and there will be no one-size-fits-all solution. - Nick ``` From: Shay Banon [[mailto:shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)] Sent: Monday, March 14, 2011 1:46 PM To: [users@elasticsearch.com](mailto:users@elasticsearch.com) Subject: Re: Any other way to cleanly shut down ElasticSearch other than CTRL+C on a console? Heya, Transport level encryption is actually not that difficult to add (SSL). The more complex feature is authentication / authorization. Once we implement that, then we need to have role base support (admin can call shutdown, while other user roles can not), and of course, where is all this info stored (and probably, integration with external user management systems). I don't think proxiying is that difficult to do, and even if elasticsearch supports SSL, I personally will probably proxy it with another system that does the SSL. The fact that it can run in the "cloud" does not mean that it needs to have those features. -shay.banon On Monday, March 14, 2011 at 6:42 PM, Clinton Gormley wrote: Hi Daniel I'm not sure that ES needs to have any sort of authentication or SSL features; as Paul Loy pointed out, it's trivial to proxy ES through a mechanism that is already designed to do those sorts of things, so what would be the interest in bogging down the ES code base with superfluous functionality ? I both agree and disagree 🙂 I agree: the ES code shouldn't be bogged down by authentication as a standard. However, this is a frequently requested piece of functionality, (especially given that ES is supposed to run in the cloud). While proxying it is easy, the user still has to figure out which proxy they want to use, how to configure it, then they have two run two separate services. I think making authz/authen available as a plugin would be very useful. clint ---
**Author:** ![Berkay\_Mollamustafao](https://avatars.discourse-cdn.com/v4/letter/b/22d042/32.png) [@Berkay\_Mollamustafao](https://discuss.elastic.co/u/Berkay_Mollamustafao)\ **Post date:** [March 14, 2011, 6:34pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/12 "2011-03-14T18:34:58Z")
Nick, I think the issue is that simple HTTP authentication does not solve many of the use cases and immediately other requirements come into play. For example, there are destructive API calls, you want to authenticate users but likely would never want to allow users to do these type of operations hence the need to have users, groups, roles, etc. In the use cases we've seen so far, you always need to front ES with another system to provide these capabilities. It is definitely an option to add them to ES, but them you have bloat, etc. and as you mention, hard to find consensus and provide full functionality. Regardless of whether you run ES in the cloud or inside the firewall, currently best practice is to have another system to provide non-search related functions, including authentication and authorization. Implementing it as a plugin would be a good approach provided that it is technically viable. I think what other people are saying is that we rather have Shay work on core features than build the peripheral functionality. Regards, Berkay Mollamustafaoglu mberkay on yahoo, google and skype On Mon, Mar 14, 2011 at 2:17 PM, Administrator [admin@sf4answers.com](mailto:admin@sf4answers.com) wrote: > Shay, > > ``` > Respectfully, I think that you understate the last point > > ``` > > about running in the cloud; yes, if you are proxying ES then SSL isn’t that > much of an important feature, you just have to harden it from access from > other computers in the same subnet. > > ``` > However, if you wanted to have a direct-facing instance of > > ``` > > ES hosted in the cloud, then SSL would most _definitely_ be a > requirement., > > ``` > In regards to authentication, there is a bit of confusion > > ``` > > here. > > ``` > The HTTP 1.1 spec (see: http://www.ietf.org/rfc/rfc2616.txt > > ``` > > section 14.8) is titled “Authorization”. However, this is a bit of a > misnomer, IMO. It should really be titled “Authentication” as it relates to > credentials and how the user identifies itself to the server according to > the HTTP protocol. Authorization is dependent on authentication (you have > to know whom you are dealing with), but authentication is _not_ based on > authorization. > > ``` > That said, when I refer to “Basic Authentication”, I’m > > ``` > > really referring to the Basic Authentication Scheme in HTTP ( > [HTTP Authentication: Basic and Digest Access Authentication](http://www.webdav.org/specs/rfc2617.html#rfc.section.2)), not custom _authorization > schemes based on authentication._ > > ``` > Now if both SSL and Basic Authentication were provided (as > > ``` > > per the HTTP specification), it would harden up a direct-facing instance of > ES quite nicely; you could use a username/password combination, as well as a > certificate to encrypt everything that is passed between the endpoints. > Yes, the weak point is the username/password combo, but at least it wouldn’t > be able to be viewed in plain text going across the wire, and you could > block out anyone who doesn’t have it. > > ``` > Note, I’m *not* asking for anything other than what the > > ``` > > HTTP protocol specifies in these two very specific areas; custom > authorization (and authentication as well) is a PITA, many people have many > different views on how this should be done and there will be no > one-size-fits-all solution. > > ``` > - Nick > > ``` > > _From:_ Shay Banon [[mailto:shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)] > _Sent:_ Monday, March 14, 2011 1:46 PM > > _To:_ [users@elasticsearch.com](mailto:users@elasticsearch.com) > _Subject:_ Re: Any other way to cleanly shut down Elasticsearch other than > CTRL+C on a console? > > Heya, > > Transport level encryption is actually not that difficult to add (SSL). > The more complex feature is authentication / authorization. Once we > implement that, then we need to have role base support (admin can call > shutdown, while other user roles can not), and of course, where is all this > info stored (and probably, integration with external user management > systems). > > I don't think proxiying is that difficult to do, and even if > elasticsearch supports SSL, I personally will probably proxy it with another > system that does the SSL. The fact that it can run in the "cloud" does not > mean that it needs to have those features. > > -shay.banon > > On Monday, March 14, 2011 at 6:42 PM, Clinton Gormley wrote: > > Hi Daniel > > I'm not sure that ES needs to have any sort of authentication or SSL > features; as Paul Loy pointed out, it's trivial to proxy ES through a > mechanism that is already designed to do those sorts of things, so what > would be the interest in bogging down the ES code base with superfluous > functionality ? > > I both agree and disagree 🙂 > > I agree: the ES code shouldn't be bogged down by authentication as a > standard. > > However, this is a frequently requested piece of functionality, > (especially given that ES is supposed to run in the cloud). > > While proxying it is easy, the user still has to figure out which proxy > they want to use, how to configure it, then they have two run two > separate services. > > I think making authz/authen available as a plugin would be very useful. > > clint ---
**Author:** ![IvanBrusic](https://avatars.discourse-cdn.com/v4/letter/i/ecae2f/32.png) [@IvanBrusic](https://discuss.elastic.co/u/IvanBrusic)\ **Post date:** [March 14, 2011, 7:03pm UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/13 "2011-03-14T19:03:27Z")
Forgot to add a link regarding (lack of) authentication: [http://pl.atyp.us/wordpress/?p=2988](http://pl.atyp.us/wordpress/?p=2988) I am not a Windows users, but on \*nix, I use kill -2 to kill an non- service Elasticsearch process. On Mar 14, 2:01 pm, Ivan Brusic [ivan\_bru...@yahoo.com](mailto:ivan_bru...@yahoo.com) wrote: > I am also in agreement that ES does not need its own authentication as > a first-class requirement. Perhaps as a plugin. > > Many alternative datastores/frameworks, such as Hadoop and MongoDB, do > not have authentication built-in. Having security provided at the > machine/network level is not only an acceptable use-case, but perhaps > might become the dominant one. > > Ivan ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:10am UTC](https://discuss.elastic.co/t/any-other-way-to-cleanly-shut-down-elasticsearch-other-than-ctrl-c-on-a-console/4092/14 "2017-07-06T04:10:06Z")