I installed nextcloud-client in my fedora-36 template. Now, as soon as I start any appVM based on the template (or starting the template itself), Nextcloud does start as well and shows it’s first setup window asking for credentials.
This is quite annoying, since I want to use Nextcloud only in one appVM with this autostart, and the others shouldn’t do anything with nextcloud.
I tried to change some settings, without effect: The ‘Launch on system startup’ is anyways deactivated by default, and also deactivating the automatic update check deactivation did not change things.
There also seems to be no autostart file created, so what triggers then the nextcloud client start?
Probably the best thing to have done was create a different template for just that one virtual machine. Can you uninstall it, make the clone, and reinstall only on that clone?
Qubes doesn’t tend to be about consolidating things onto fewer virtual machines. It’s usually about “compartmentalizing.”
In fact, it can get very extreme on compartmentalizing. There are people here who literally install one application per template, so that they end up with a menu that lists applications (but each one is in its own VM). That does mean they do a lot of copying and pasting between VMs, but that’s not bad at all. I’m fairly new to this and I don’t think I’ll go quite that far [but then again, who knows?], but I did just split a VM I own into two, one with stuff to develop software on it, the other to look at things, process photographs, and write documents on. The two activities never cross over, so there was no reason to keep them together (and oftentimes, the less stuff on a VM, the faster it boots). That latter VM still seems like a bit of a grab bag of things, so I will probably break it up at some point, as well.
I did do a lot of planning to try to ensure I wouldn’t ever install the same piece of software twice (and I got to the point where there was exactly one case of doing it twice, but it was something very small); perhaps that’s what you mean by “consolidation.” If, for existence you often use a draw program with a word processor, and also often use it with a powerpoint like program, but you never use the word processor and the powerpoint program together, you could: 1) clone a template, call it A, 2) install the draw program on A. 3) clone A to B. 4) install the word processor on A, and then 4) install the powerpoint-like program on B. You’ve installed each program once, but have two different VMs. That keeps your powerpoint and wordprocessor activities separate, but lets you consolidate a little (and without redundant installs).
I’ll make one more suggestion: Keep a clean copy of your Fedora template somewhere, so you can always base new VMs off of it, rather than the last thing you did.
And I just realized I didn’t answer you closing question…and that’s because I don’t know anything at all about Nextcloud and how it’s configured. I had never heard of it until you asked.
thanks for the explanations, and I understand the security aspects of the compartmentalizing. My main concern with ‘consolidation’ is: When I would have my 30+ templates created and I want to update to fedora 37, then I have to update all 30 templates separately, right? Hence I like the appVM solution, where I can simply upgrade ( or better clone + upgrade ) my template, and when that was successful change all appVMs from Fed36-template to the Fed37-template.
Or how does the upgrade process look like on your system?
That is indeed a good idea to look for other clients. ‘Mounting’ implies for me that the files are not saved locally, but only available with a network connection, or am I wrong?
I was alread looking into Rclone, since I also will have to use a dropbox somewhere That should work with Nextcloud as well…
Actually, when it comes time for me to move up, I expect that I will simply start with the basic template, upgrade it, and regenerate all templates from it, as I did this time around.
I wrote scripts to generate all of my templates. Yes, I will have to reinstall all apps once (twice in a couple of cases) and wait on a lot of cloning, but I expect it to be a fairly straightforward process. People like sven have so fully automated their systems that they can kick a process like this off at night and go to bed. I do have to attend the process, some, because I’ve not completely automated the process of getting an AppVM to not depend on a template I want to rebuild. But hoefully by the time Debian-11 is obsolete, I’ll have it knocked.
So at that point all I will have to worry about are the (inevitable) incompatibilities.
A bigger issue for me is the fact that if some minor update comes out, it will want to be applied to each template individually. However there’s an answer for that too; it’s possible to set up your firewall qube to cache the updates, so that you at least won’t have to download the same patch over and over again. (I have not done this yet; it’s on my to-do list.)
Alright, finally I got it figured out…
First, I have to correct myself: the nextcloud client starts only when starting the Files / Nautilius in the appVM, not by any application. This led me to that github issue: https://github.com/nextcloud/desktop/issues/1982
So nextcloud integrates itself in Nautilius and then starts every time with it. As rysiekpl describes in his post, it’s quite annoying, especially under qubes.
I am currently experimenting with rclone and will drop the nextcloud-client eventually.
That should work with Nextcloud as well…