indeed you dont really need to “detect denials” but just check if you have the expected access to a file, device or whatever the interface normally provides.
#! /bin/sh
[ -r "/var/log/syslog" ] || echo "please connect log-observe !!"
1 Like
I would like to found out how to assert plugs/slots and plugs & slots with attributes in this topic.
This topic used to have all the undocumented and new interfaces which are not yet updated in https://docs.snapcraft.io/reference/interfaces . I see they are no longer available here as well. Could you please add a link where we can find the updated interfaces list ?
1 Like
We’re currently working on the Interfaces pages and we’ll definitely be adding the interface list back (likely today), along with a reference to each interface. Sorry this isn’t clear - when something like this affects the docs again, I’ll leave a ‘Work in progress’ note with an explanation.
1 Like
The interface section is still not available. When can we expect it to be back ?
Have you seen Supported interfaces? It should include all the details there were previously in this topic, but let me know if there’s something missing.
2 Likes
Still broken here (18.04 LTS). The above steps do not resolve it.
The snap was ‘postman’ and my home folder is /home/local/SOMETHING/myname
So this page doesn’t seem to teach you how to add interfaces to your snapcraft file, and neither does:
The latter tells you what interfaces are supported, but neither of these docs seem to be linking me towards, as an author, how to do a strict mode snap and have it request interfaces.
The Go examples are both “devmode” snaps, and thus don’t do confinement (AFAICT).
Some of that seems to be described in:
https://docs.snapcraft.io/the-snap-format/698
but if you just start with “Creating a Snap” it seems to direct you immediately to the language-specific details, which at least for the Go ones, doesn’t direct you back.
We’re missing a huge chunk of the snapcraft lifecycle, including installation (in a central place), command syntax, confinement, adding interfaces, using plugins, tracking down dependencies, build override examples, scriptlets, troubleshooting and publishing.
All of the above are high priority (and what I’m currently working on), so we’ll have something published on here soon.
2 Likes
As a snap package creator, I am interested in what precisely a particular interface provides, in technical terms. Some interfaces are pretty intuitive, like ‘home’. Some others are rather obscure: for example, what precisely does plugging into ‘avahi-control’ enable? How exactly does it affect my C program which uses the avahi-client library? And If I want to provide a slot for an interface, what precisely must I do in my snap?
I assume it ultimately all comes down to the basic Linux kernel and IPC interfaces: files, system calls, etc. It would be helpful if the interfaces were described in terms of those primitives. Given that there is just a few of those basic primitives, I also wonder why there are very specific interfaces such as ‘avahi-control’? Why is something related to an application like Avahi part of the basic snap system? Would it make sense for any snap other than ‘avahi’ to provide the avahi-related slots? What happens if multiple snaps provide this slot? As another example, the ‘docker’ interface begs the same questions.
Furthermore, if the interfaces are intended to be so application specific, then it seems essential for a snap application developer or an embedded system developer to also be able to implement their own interfaces, without hacking the snap system itself. Is that possible or is it part of the vision?
2 Likes
This does not seem right. Which is the previous output? Things do not match with the previous output. Perhaps something was moved round?
1 Like
You’re absolutely right! Thanks for mentioning this. snap connections has a different output, but we didn’t change the text to explain this. I’ll fix it now.
1 Like
Wording taken by documentation to refer to interface is used in somehow inconsistent way which makes the learning curve steeper yet raises irritations while reading stuff.
Please start with picture provided in Interface Management documentation, by which interface is explained illustratively. According to picture and surrounding text an interface is the connection between plug and slot, cit. " An interface consists of a connection between a slot and a plug .".
Most will guest interface connects snap A with snap B, in some edge cases interface’s plug and slot connected by one single interface might be provided by one single snap - if such case is supported at all - please put this point aside for this discussion.
So, if to go back to stuff learned from mentioned picture every interface has plug-end and slot-end. To be consequent all documentation and snap CLI should account for this property. This is however not the case. At several locations documentation uses the phrase “connect to interface”. Hence in end-result it expands to “connect to connection between snap A and snap B”. I don’t believe this is the goal. I see only one possible use-case for connecting to connection which is logging. However I don’t believe several locations in documentation with phrase “connect to interface” be used really mean debugging, cause those locations in documentation address snap basics (logging is no part of basics).
By the same argumentation documentation article with all known interfaces listed should specify also both ends for each interface: plug and slot. I know this is not possible however one can see which weird conclusion might raise from present documentation form.
CLI needs also to adhere to consistent wording too, e.g. see output of snap interface <app-snap-name>.
It can well be documentation authors mean “connect to snap” when “connect to interface” is used. This way words snap and interface would be have interchangeably by arranged conventions. This also doesn’t help documentation to not be weird cause latter one doesn’t mention conventions.
Existing inconsistency makes hard further documentation reading as with each next section matters escalate. It makes also for reader harder to draw own conclusions, because documentation can’t deliver this way confirmation for reader’s conclusion truthfulness.
Please feel-in in reader’s position, if they are snap newbies they can’t rely on own snap knowledge. While reading they can easily take different point of stand and view than Author’s one.
For instance when encountering an explanation where “connect to interface” is used they may wonder if function provider snap is connecting to consumer’s plug or vice-verse if a snap consuming some common resource is connecting to provider snap’s slot, this makes learning harder.
Hello! Thanks so much for taking the time to leave this feedback. And you’re right about the way we mix interface terminology - we can see how this can be confusing.
We’re going to give this problem some thought and try to improve our use of the term - first here in the documentation where we’ll try to make its scope clearer and less confusing.
Running this on Ubuntu 22.04 so that might make a difference but a couple things.
If you mention running “snap interface”, might be worth mentioning “snap interface --all”.
Also, “snap help interface” mentions the “–attrs” option to allegedly “show interface attributes”, but using it doesn’t seem to add anything to the output. What should I expect to see in the way of attributes?
try snap interface content with and without --attrs.
with the option it should show the paths where the interface provides the content (i guess system-files and serial-port are some others where you could see attributes) … interfaces with attributes are simply relatively rare …
1 Like
Ah, quite so, thanks.
I might be tempted to add a couple more lines to this page. First, it could be worth adding the variations:
$ snap connections
$ snap connections --all
And perhaps that both connect and disconnect take the “–no-wait” option. None of that is critical, but given that all of that would add only a few extra lines, maybe it’s worth throwing in for completeness.
Thanks for the suggestions. I’ve updated the doc to include them all.
I don’t care for this definition, “An interface consists of a connection between a slot and a plug.” I like to see this as that an interface is an abstraction that defines a certain level of access to resources; a connection is a specific instance of a plug/interface/slot combination. It’s like object-oriented classes – you can have a single class definition, but numerous instantiations of that class. Does that make sense?