Why don’t you use the channel system built into snapcraft?
1 Like
We have got a few reasons to choose this way.
The first one is - we would like to provide our users with the possibility to install both Beta and Prod version at the same time in the system.
The second one is it’s very important for us to have different local data storages for Beta and Prod version. So we need to make sure that our Betas will not affect production data. As we understood, if we install snap from the stable channel and then refresh it to the beta channel, it still uses the same local data storage as stable used.
Also, we have a few small but important for us things like different app icons for Beta and Prod.
You appear to have 3 snaps in the store, one which is private termius and the two you mention termius-app and termius-beta.
Could you please detail how using the home interface to access user files isn’t sufficient. I tried termius-app on my laptop and was able to use the ssh part of the app just fine. Very nice in fact. I don’t quite understand why the application needs full arbitrary access to any file on my filesystem. Could you walk me through an example?
The “termius” snap is a legacy snap we used for tests. It can be deleted.
The local terminal we talk about is not an SSH connection to localhost. It’s similar to the terminal app in your system and it doesn’t require an SSH server to be running on your machine.
Similar is applicable for the SFTP feature. We want to provide users with the ability to transfer files from the machine to remote servers. This also should be possible without an SSH server on the local machine. So it needs full access to the file system.
Also, the local file system feature in the SFTP tab is working with the user’s file system directly.
Currently, the above features are available in our unsandboxed macOS and Windows apps (https://www.termius.com/mac-os). You may see it in the attached gif.
We would be happy if our Linux users could use these features too - a lot of them are asking to implement this.
1 Like
This sounds like it is both a shell interpreter (something we’ve not normally allowed, but have with powershell) and an sftp server, which is sorta like backups, but not quite.
While the requirements are understood, we’ve not yet allowed a snap for serving the hosts files to a remote site. I’m not a Termius user. Perhaps you could outline how these features are typically used?
@pedronis and @niemeyer - note there is another classic request for a shell here: Request classic confinement for bash
1 Like
Yep, that’s almost correct. I just want to emphasize that It’s not an SFTP server but SSH and SFTP client.
SFTP As a user, you might want to upload a file from your computer to a remote SFTP server. SFTP works over SSH which allows users to make transfers secure.
Without classic confinement, you can transfer files BUT you need a running SSH server on your local computer to initiate local SFTP connection and only then transfer files which makes the process slower and less friendly since you need to do additional steps to add the info about your computer in the app.
With the classic confinement, the app can get access to the file system and will allow users to transfer files almost immediately to their remote machines.
Local Terminal As you mention, it’s a shell interpreter. We actually just run the default shell that is already installed in your system. Our users asked a lot about this functionality, they want to be able to access both local and remote machines from one place (Termius) and currently then need to establish unnecessary SSH connections to localhost or use 2 separate apps for that (Termius + standard terminal).
Moreover, having an ssh connection to localhost is not the same as just using the standard shell since it doesn’t give you the same full access as your local terminal does and therefore you are working in the restricted environment.
Long story short The functionality we are requesting already works in our macOS app downloadable from the website and in our Windows app even from the Windows App Store.
The Mac App Store app is sandboxed and users struggle the same way there as with apps from Snap Store.
The difference is that we have an alternative for our users from the Mac App Store - they can go to the website and download the full version.
And the Snap Store can actually help our users by permitting the Classic Confinement since, currently, they don’t have an alternative and can’t get best out of Termius.
Really looking forward to hearing the good news from you 
1 Like
The SFTP usage case you outline above can be handled largely by the home and removable-media interfaces. While these don’t provide unrestricted access they do provide a large portion of what users (non root users) are likely to want to access to copy to a remote system. What they don’t provide is access to the system in places like /var or /etc.
Well, we outlined the most obvious cases. There are a lot of other cases as well.
The confinement needed not only for SFTP but for the terminal as well.
If we talk about particular folders like var and etc, users keep their logs in var by default. And if they want to transfer and back them up on a remote server they will need to create an sftp connection to localhost to get to the logs - that’s inconvenient.
When you are in sandbox mode it makes the UX unfriendly. From the technical perspective we can do this and that and provide users with wider functionality but still with restrictions. But those who spend a working day in a terminal always ask why you can’t do this obvious thing?! This is the behavior that is expected out of the box. And it’s restricted only because of the Snap Store rules.
We want our users to solve their problems easily
So just to recap, the way with restrictions is not a solution for our users. It’s just another problem for them to solve. And we want to solve the problem for them.
1 Like
If it’s not listening on a non-local port it would be technically ok to grant classic.
@Termius - does your snap open and listen on any ports? If so are those ports restricted to the loopback interface?
Just like OpenSSH client, we have Local and Dynamic Port Forwarding features that listen on a user specified port.
By default, when a user turns on a port forwarding rule we bind that port on 127.0.0.1, but he is able to specify any IP address available on network interfaces.
So, we don’t listen on any ports, but users can explicitly specify that.
1 Like
Thanks. This seems to meet the criteria @pedronis outlined.
@advocacy - can one of you perform the publisher vetting?
1 Like
Sorry, done. I am +1 on this from a publisher vetting PoV.
Granting use of classic. This is now live.
1 Like
Thanks, guys!
We’ve got a question about the auto update to classic mode.
Is there a way to update our current users to the classic mode automatically?
If we publish the new release with classic mode enabled will this mechanism https://docs.snapcraft.io/keeping-snaps-up-to-date update our current users from strict to classic in the background or not? If not, is there a way to refresh from strict to classic manually with CLI?
AIUI, snaps by design are allowed to automatically refresh from classic to strict but not the other way around. I believe the @advocacy team worked with a publisher or two on dealing with this. Perhaps they can comment here?
Guys, could you advice something?
Or our current users have to remove current Strict applications and install it with --classic again?
Thanks in advance.
This is a tricky one. I would consider doing the following - comments / suggestions welcome:
- Publish a classic build to the candidate channel only
- Publish a strict build to the stable channel, which has a zenity / yad / dialog popup which pops up before the application launches to explain you’re now classic confined, and to tell people to
snap refresh termius --candidate(and omit the--classicso they get to read the message that pops up when they try to refresh to the classic snap) - Monitor the snap metrics for your snap to see how many have moved from stable to candidate. Be accepting of the fact not everyone will, as not everyone will start your application and see the popup
- Once a chunk of users have moved over, promote the classic build to the stable channel and close the candidate channel
I can’t think of a better way to do it.
1 Like