Cant deregister a service with management token

[John F]

I have a service in the catalog that was registered by a consul client agent. The client no longer exists. The vm it was running on has been destroyed. From a consul server node I am unable to delete the service entry, the answer I get from consul services deregister -id=api -token=<randommanagementtokenhere> is "service does not exist". However, the service and the node are listed in the catalog in the gui and marked as down because the box doesn't exist and the check is failing. Does anyone have any advice for me in this situation?

[Matthew Keeler]

The consul services deregister command uses the agent API to deregister a service from a particular agent. The GUI and the consul services CLI command are using the catalog APIs to get the service listings which is why there is that discrepancy. There isn’t a corresponding CLI to manually deregister a service from the Catalog but you can curl the API like:

curl -X PUT -H “X-Consul-Token: <your token>” <consul address>/v1/catalog/deregister -d  ‘{“Datacenter”: “<datacenter of the deleted vm>”, “Node”: “<node name of the delete vm>”, “ServiceID”: “<service id of the service to delete>”}’

If you don’t specify the service id in the payload then it will remove that node from the catalog and all services associated with it.

The docs for that API are here: https://www.consul.io/api-docs/catalog#deregister-entity

Matt Keeler

On May 18, 2020 at 3:00:20 PM, John F (johnfo...@gmail.com) wrote:

I have a service in the catalog that was registered by a consul client agent. The client no longer exists. The vm it was running on has been destroyed. From a consul server node I am unable to delete the service entry, the answer I get from consul services deregister -id=api -token=<randommanagementtokenhere> is "service does not exist". However, the service and the node are listed in the catalog in the gui and marked as down because the box doesn't exist and the check is failing. Does anyone have any advice for me in this situation?

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
Community chat: https://gitter.im/hashicorp-consul/Lobby
---
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/8a984bf4-b288-413f-8ae4-277a572e1f67%40googlegroups.com.

[John F]

Thanks Matt! That was exactly what I needed.

As a followup question can you enumerate the minimum acl permissions a client agent would need in order to deregister its own service? I've got a client holding a token with the following acl:

{"node": {"testnode": {"policy": "write"}}, "query_prefix": {"": {"policy": "read"}}, "node_prefix": {"": {"policy": "read"}}, "service_prefix": {"": {"policy": "write"}}}

and if I try to deregister a service from this node by removing the service check I get a permission denied error.

To unsubscribe from this group and stop receiving emails from it, send an email to consu...@googlegroups.com.

[Matthew Keeler]

When deregistering a service from a node in the catalog it should only require write privileges on the service name. The service_prefix rule in the policy below should work. Are you using legacy ACLs (rules in the tokens) or are these rules in an ACL policy linked with some token?

If using legacy ACLs the *_prefix rules do not exist but rather all rules are prefix matching and I think it probably will silently ignore the extra unknown keys (probably should be fixed).

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/4413fcd4-0431-4e38-aeb8-b330949b95c0%40googlegroups.com.

[John F]

In this case I am using rules in ACL policies linked to a token (the post-v1.4? way)

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/4413fcd4-0431-4e38-aeb8-b330949b95c0%40googlegroups.com.

[Matthew Keeler]

Could you elaborate a little on the various entities and APIs in use here. Is the “client” a Consul Client Agent or just another application that can use the Consul API? Are you seeing any permission denied errors in the logs regarding RPCs?

To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/7d432c63-08b4-4e5f-ba1f-203bddcad1cc%40googlegroups.com.