Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is a MountPoint and what is it used for? #533

Closed
Think7 opened this issue Oct 28, 2017 · 15 comments

Comments

Projects
None yet
8 participants
@Think7
Copy link

commented Oct 28, 2017

Hello,

What is a MountPoint and what is it used for?

I see it referenced in the docs, specifically on this page regarding ACLs:
https://vernemq.com/docs/configuration/db-auth.html

but haven't been able to figure out what it is, what it is used for, or why i would want one.

If this information is in the docs somewhere PLEASE post a link to it as i haven't been able to find an explanation anywhere.

@ioolkos

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2017

Thank you @Think7 for bringing to our attention that the doc is not helpful.
I'll try to explain mountpoints here and then add this to the documentation:

Normally, a VerneMQ broker hosts one single topic tree. This means that all topics are accessible to all publishers and subscribers (limited by the ACL's you configured, of course).
Mountpoints are a way to host multiple topic trees in a single broker. They are completely separated. Clients from different topic trees cannot talk to each other in that case. This could be useful if you provide MQTT services to multiple separated use cases/verticals or clients, with a single broker.
Note that separated mountpoints are configured via different listeners. As a consequence, the MQTT clients will have to connect to a specific port to connect to a specific topic space (mountpoint).

Also note that currently VerneMQ implements a very restrictive version of mountpoints, somewhat modelled after RabbitMQ's vhost concept. Other MQTT brokers might implement a different model of mountpoints.

@Think7

This comment has been minimized.

Copy link
Author

commented Oct 29, 2017

Thank you! This is a great explanation.

I was considering running two separate brokers for security reasons. One that handles my applications communication between the different internal services and one that clients connect to. Mountpoints seem to solve this issue.

One other question:

I understand MQTT is a message broker that strictly handles pub / sub for real time data.

How is a situation handled where a client needs access to previous messages or historical data?

For example a chat application.

Let's say Client1 and Client2 are passing text messages on a topic. If Client2 disconnects and then joins back later, unless he has stored the conversation history locally, everything is gone. He will only have access to whatever new messages are sent.

The only MQTT specific solution I can think of is continually updating the topics retain message with the entire conversations history so that is sent when Client2 re subscribes. This feels very wrong though.

What about needing to select only specific parts of the conversation? Say within a specific date range. Or perform searches or other operations?

How should an application handle this case?
Does Vern have a solution or is there a general best practice?

@jeremylink

This comment has been minimized.

Copy link

commented Oct 30, 2017

I'd never seen a good explanation of mountpoints either - this sounds interesting.
Currently, I use the topics to filter for multi-tenancy; is there a discussion somewhere that covers the pluses/minuses of using mountpoints vs. topics for multi-tenancy?

@ioolkos

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2017

@jeremylink yeah, we had a discussion a while back here: #395
on the pro's and con's of IBM style mountpoints vs. our understanding. In an ideal case we could support both versions.
Regarding your remark, I think I have never seen a discussion of topics vs. mountpoints for multi-tenancy.

@jeremylink

This comment has been minimized.

Copy link

commented Oct 30, 2017

Good info - I didn't realize the difference when I was reading about other mountpoint implementations.

@siscia

This comment has been minimized.

Copy link

commented Jul 14, 2018

Hi guys,

Just got interested in the topic.

Would it be possible to set the mountpoint with a modifier on the client connection?

In particular on the auth_to_register hook?

This will allow a quite flexible and usefull model...

@dergraf

This comment has been minimized.

Copy link
Contributor

commented Jul 14, 2018

Hi there,
yeah that's possible... just return it as part of the subscriber_id modifier in auth_on_register. The subscriber ID takes the form of {Mountpoint::string(), ClientID::binary()}.
hope this helps.

@siscia

This comment has been minimized.

Copy link

commented Jul 14, 2018

Hey there!

Thanks for the extremely fast response.

I was browsing the documentation from mobile so I didn't dig too further into all the modifiers.

Thanks!

@1995parham

This comment has been minimized.

Copy link

commented Oct 3, 2018

Hi guys,

can I disable webhook authentication on a specific mountpoint? I want to authenticate all clients except those coming from my mountpoint.

@larshesel

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2018

Hi @1995parham, that's a feature we'll include in 2.0 - the idea is to have different plugin chains per listener (and hence mountpoint). Currently you'd have to rewrite the mountpoint in auth_on_register to work around this.

@1995parham

This comment has been minimized.

Copy link

commented Oct 4, 2018

Thanks for your reply, so I looking forward to version 2.

@puresilk

This comment has been minimized.

Copy link

commented May 12, 2019

After struggling to wrap my head around Erlang, and understanding how to pass the correct values with Lua, I have come up with the following blog post and code, to allow custom mountpoints from Lua & MongoDB. The code should be easily adjustable to MySQL / Redis / CockroachDB as it is mostly about the proper formatting of the return values.

For this purpose, I have modified mongodb.lua and it's auth_on_register function.

https://pi3g.com/2019/05/12/understanding-erlang-lua-luerl-for-vernemq-mongodb-auth_on_register-hook/

@larshesel I hope it is OK that I quote VerneMQ code to explain how it works for non-Erlang coders :-)

@dergraf

This comment has been minimized.

Copy link
Contributor

commented May 12, 2019

@puresilk cool stuff! Thanks!

@larshesel

This comment has been minimized.

Copy link
Contributor

commented May 13, 2019

Of course! this is really cool!

@larshesel larshesel added this to the 1.8.0 milestone May 14, 2019

@larshesel

This comment has been minimized.

Copy link
Contributor

commented May 14, 2019

We added the explanation above to the documentation: https://docs.vernemq.com/configuring-vernemq/listeners#mountpoints. Let us know if you have any ideas for improving! Cheers!

@larshesel larshesel closed this May 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.