Linux users: Request for information and feedback

[pollux]

3) Do you actually need sudo after installation is done? Could you just define user (or user group) that owns Fantasy Grounds directories and application is run as that user?

If we're considering chowning files in a system location as writeable to a specific user, that's effectively a $HOME install. We should do the $HOME install properly instead.

If we're considering chowning to a group, making files in a system-location writeable to that group (without privilege escalation), and putting so-chowned binaries in the system $PATH so they're executable by any user... that's a pretty questionable security policy. It's a pretty reasonable hack for a system owner to do if all the users know and trust each other, but as the official install layout for a software vendor it invites a vulnerability report from a security researcher.

[notrealdan]

As mentioned by Doug earlier, other than initial installer, I doubt we'll be able to use any of the standard Linux distribution methods. We have to run our own update program in order to deliver purchased content. However, I will have Ryan review all the options before deciding how we will deliver installer and update program.

Regards,
JPG

I understand and agree with this for purchased content (stuff the updater delivers to the "Data Directory" as referred to in Settings) since it needs to be able to check what the user has purchased and is entitled to. Thankfully none of that should need privilege elevation in the OS to install/update if it's stored in the user's home directory.

However, using the standard tools to distribute the program files themselves (stuff delivered to the "App Directory") could help avoid some customer support load, since it would be tools and methods already very familiar to the users. In my experience, custom installers are more prone to problems than package-based installations. If there are any dependencies needed to run FGU, a package manager would typically also handle that for you.

I know that would be very different from how installation and updating has been handled in the past for FG, and would make the Linux version even more different than other versions. That's also worth considering. I'm sure you guys will make the right call.

[Moon Wizard]

I think one of the challenges is that the updater is meant to be a one-stop shop to deliver both application and data content to our users. In that vein, the updater is actually written as a cross-platform tool that delivers content to the app/data directories using a program written once on Unity for cross-platform support. If we change that assumption, it means having to actually change even more with the updater tool to get Linux to install/update and make it behave differently between platforms, not to mention the long term maintenance of building whichever Linux package formats (maybe multiples needed). Doesn't seem like a good choice to go that route, as it would create more delays for delivering Linux builds and more work long term.

While we're not Linux experts, we're trying to thread between offering a consistent and easily maintainable experience for all platforms, while having our installation/update process use standards for Linux locations. We may have to go with all application/data in home directory to deal with permissions; but it doesn't fit in with the FHS I've read about (https://en.wikipedia.org/wiki/Filesy...archy_Standard).

Regards,
JPG

[pollux]

We may have to go with all application/data in home directory to deal with permissions; but it doesn't fit in with the FHS I've read about (https://en.wikipedia.org/wiki/Filesy...archy_Standard).

The FHS doesn't really have anything to say about user home directories. It doesn't preclude installing software there, it's just silent on the matter and leaves it as undefined behavior. All the stuff the FHS does have to say about software locations pertains to system-wide software, but doesn't exclude per-user software in $HOME. In order to have SOMETHING to say about homedirs, the FHS 3.0 does reference the XDG specification (https://specifications.freedesktop.o...ec-latest.html), but my sense is that XDG doesn't have nearly the traction that the FHS itself does and it doesn't really help us anyway because the XDG spec doesn't define a place for per-user binaries either ($XDG_RUNTIME_DIR sounds promising but that's for ephemeral runtime state and is cleaned upon logout/reboot, so not useful for persistent installs).

I think if you enter the realm of per-user installs in $HOME, you won't have a well-specified standard to lean on like the FHS. The best guidance available is probably the precedents set by successful projects. Linuxbrew (https://www.varstack.com/2015/06/26/Linuxbrew/) comes to mind as offering non-root homedir based installs of a lot of stuff. If Ryan is developing on OSX, he's probably familiar with "brew" there, and that project has a Linux offering as well that works similarly. They dump stuff in ~/.linuxbrew/bin/ and similar subdirs off the ~/.linuxbrew/ prefix. I realize they're focused on developer tooling where people forgive complex and terminal-based UX, but I can't really think of any examples of people shipping consumer software on Linux with your constraints that prevent leaning on the package-manager.

As I think about this more, what starts to coalesce for me is:

1. Steer clear of official packaging formats like deb, rpm, and snap. The intermingling of base software and licensed content in your update process makes that too weird. In the future, the same choices causing you to align poorly with Linux software distribution patterns may cause you headaches trying to distribute through the MS, Apple, or Android app stores with their opinionated update mechanisms and restrictive security policies. But that's tomorrow's problem, not something to sort out today for Linux support. For today, stick with your own installer (or something like Bitrock which automates building cross-platform installers, or something similar from the Unity ecosystem).
2. Have your installer be capable of installing to any prefix directory. The install should be self-contained to a single directory (mostly, except for the data-dir and maybe a ~/.fantasy-grounds.conf dotfile to remember what the install-prefix and data-dir are when people choose something weird that isn't in your default list of places to check).
3. If you want to do a system install (like on OSX), then the default prefix-dir should probably be /opt/smiteworks/ or something similar. To make this work, you'll need to get privilege escalation for the updater working via polkit or documenting the requirement to invoke it via sudo (and having the existing update buttons pop-up a message explaining how to update on Linux). I haven't worked with polkit myself and I don't know if it's dead easy or a pile of headaches due to inconsistent behaviors across different desktop environments and distros. As a modular standard, headaches are definitely a possibility... but I kind of get the sense that it's widely adopted.
4. If you don't want to deal with privilege escalation, then you're down to homedir installs. The default prefix then becomes ~/.smiteworks. Beyond choosing the install layout, I don't think homedir installs present any complications. You won't be able to drop binaries in the $PATH by default, but ~/.smiteworks/bin/ and maybe symlinking to ~/bin/ if that directory exists isn't a bad start, anyone who wants can easily add those dirs to their $PATH. And most people probably will use menu icons anyway. So not being in the $PATH by default probably doesn't matter at all.
5. Regardless of whether you default to /opt/ or $HOME, the installer should probably support arbitrary prefixes like /mnt/my-drive/FG/ or /opt/fantasy-grounds/. It's ok to require that weird prefixes be pre-existing or have specific ownership/permissions pre-reqs. The error-handling in the updater around insufficient permissions should be very tight, and pop up a very helpful message pointing to a wiki page or something for more info about how to handle updates/permissions or steering people onto a more "normal" install layout if they're not experts.

Maybe there are hidden gotchas I haven't considered, but that feels like something that's a reasonable variation on what you're already doing, and is credibly idiomatic on Linux.

[Moon Wizard]

You're echoing a lot of what I've been thinking about, based on feedback as well as what we need and what is easiest to maintain. We'll have to see how easy it is for an installer to determine permissions, and request elevation, on Linux; or just force to home directory. We'll probably make a final decision next week, so we can push forward with implementation. Thanks for the feedback so far.

Regards,
JPG

[exocore]

Haven't been checking the forum quite often lately so sorry for the late reply.

Maybe it also helps to give some examples of other proprietary software:

• Microsoft maintains their own ppa for Skype, providing the package in the snap format. The installer registers it to the package manager and updates are just rolled out via apt. The internal "updater" only informs that a new version is available and asks the user to run system updates.
• Similar for JetBrains IDEs like CLion, PHPStorm or IDEA Ultimate. Plugins are installed and updated via their own internal update system.
• Autopano (a software for stitching panoramic images images) is available as a *.dep and *.tar.gz archive and is installed to /opt/AutopanoGiga while the key authentication happens during startup based on the data from /home/<USER>/.config/Kolor/...
• Photomatix for Linux is also provided as a *.deb file
• Steam can be installed directly via apt. By default it installs all games in it's config folder /home/<USER>/.steam. However it is possible to configure a different directory, so I'm having everything installed to /opt/steam.

Imho, running installation and updates through the system's package manager as the first two are doing is the most convenient way as a Ubuntu user.
Personally I would probably go tor a snap package for the "raw" FGU environment, as it is distribution independent and store all userdata including license keys and plugins somewhere in /home (e.g. /home/<USER>/.fgu), similar to the FG2 windows version putting everything to appdata (not sure whether FGU still does it the same way).

Best,

exo

[pollux]

Maybe it also helps to give some examples of other proprietary software

This is a really good list of precedents, but I'm not sure it changes my own recommendation to favor a proprietary installer.

• MS charts an interesting course by gutting their updater and leaving just the shell that checks if an update is available. It didn't occur to me previously, but Chrome and Firefox take this approach as well. On Windows and OSX, when installed via their "traditional" installer (rather than desktop app stores), both Chrome and Firefox have auto-updaters for security reasons. On Linux, they disable those (or just mention that an update is available) and delegate updates to the package-manager. This is a good approach in general, but it doesn't work for Smiteworks because their "updater" handles both program updates and licensed content updates. One might reasonably question whether that's a good idea (I think it's not, and that other platforms would benefit from the separation of program and content updates... most especially if Smiteworks aspire to someday deliver an Android/iOS app there is no chance of bringing the current updater strategy to those platforms), but it's the current reality and as a small company with big ambitions it's not likely to be something that Smiteworks can sort out on all platforms immediately.
• Jetbrains has the separation between program updates (the base software) and content updates (plugins) to enable them to take this approach. Smiteworks has work to do before this approach is viable for them. Though I do like the idea of over time moving the content updates out of the updater and into FG itself (which would require sorting out hot-reload of modules, or just restarting anytime an update was needed), and leaving the updater as a much simpler thing that COULD be gutted down to an update checker that delegates base-software updates.
• I'm not familiar with Autopano and Photomatrix, but I'd guess they have no updater functionality and rely on the package-manager, or fall into one of the above categories.
• Steam is the the most relevent example here, because they DO intermingle software updates and licensed content updates in a very similar way to Smiteworks. I think it's no accident that they install to $HOME by default. As you note, they offer other install-location options... via a prefix-strategy not all that different from what I proposed earlier (and which shares the same permissions challenges if you install outside of $HOME). They do offer a deb install package, but it's not a "normal" deb that installs Steam itself... it's only 2.7MB. I haven't analyzed what's in it, but I also can't ever remember seeing the package get upgraded on my system. It's definitely some kind of relatively simple bootstrapper that gets things going and doesn't do all that much afterward. A deb that does nothing but install a bootstrapping installer to a system location, and then having the bootstrapping installer place the updater in $HOME is a nice UX for Linux users, but it's more complexity and packaging work for Smiteworks that provides only a very small incremental improvement in experience over a proprietary installer. I'd generally rather simplify the linux packaging and have them spend their time on product features and fixes. Especially since people can always install FG through Steam to get this deb-bootstrapped experience.

[exocore]

This is a really good list of precedents, but I'm not sure it changes my own recommendation to favor a proprietary installer.

In-App management of content would be indeed nice, but I don't think it's a requirement for system based installation and upgrades of FG. As I expect there to be quite a bunch of third party plugins and other content, the roll out of updates of the major version and content won't be synchronized in the long run. This means the installer will anyway need a functionality to determine and select the compatible content versions based on the installed FG version. Thus the only change required for a snap package would be, to blacklist the FGU "core" from its internal upgrade process.

Also for Steam the situation would be comparable, as I'd expect it to update only FG but not the user-specific extension modules (unless SmiteWorks is planning to sell and distribute them via Steam as well).

Edit: going through a standard system installation would also resolve the problem of elevating privileges, as the package manager is already running with root permissions.

[Shazburg]

Just another voice chiming in about not cluttering my home directory. Please keep configuration, settings, and other cruft under a $HOME/.local/share/foobar path.

As for the installer, a Smiteworks hosted repo would be best imho.

[javierrivera]

1) What is the expected experience for installing our software?

Using the distro package manager. Either by direct packaging by the distro or extension system (PPA, AUR, etc...). After that distro-agnostic systems like Flatpack or Snaps.

A homebrew system, closer to the way Mac and Windows work, could be faster to implement, but it'll be totally alien to normal linux workflow

2) What are the expected "default" installation/data directories.

You're places are as good as any, but if you go by "your own installer" route, please install to /opt/ to avoid conflicts with package managers.

If you are going to install to the home dir, please keep things under ~/.local/ , as other people requested.

3) What is the expected procedure for elevating permissions?

You shouldn't elevate unless you are doing system maintenance tasks. If you should do it, please do it only when inevitable (updating the program) and use policy-kit for the higher compatibility.

Anyway, I (and likely most linux users) understand that FG is a Windows first program ported. As soon as it works it will be ok, after all I'm using it with wine and this is really much more alien that not following the above guidelines.