search

rgleason / watchdog_pi

watchdog plugin for opencpn
GNU General Public License v3.0
1 stars 10 forks source link

In flatpak, Watchdog doesn't create .var/org.opencpn.OpenCpn/config/opencpn/plugins/watchdog #16

Closed filochard closed 3 years ago

filochard commented 3 years ago

Inside flatpak watchdog can't write user's owned files in the right place because there is no /home/username/.var/org.opencpn.OpenCpn/config/opencpn/plugins/watchdog directory

If there's a classical linux installation besides flatpak installation, the user's created files are wrongly written in the linux directory : /home/username/.opencpn/plugins/wathdog !!! NB The readonly data files are in the right place : /home/username/.var/app/org.opencpn.OpenCPN/data/opencpn/plugins/watchdog_pi/data/

That was found by investigating an issue of an other plugin https://github.com/rgleason/LogbookKonni_pi/issues/6#issuecomment-830917980

This may concern other plugins OpenCPN/OpenCPN#2256

rgleason commented 3 years ago

I recently updated Watchdog frontend and tested with Windows and it works properly and saves configurations.

So why would Alex write: "Basically, writing in the installation data directory is a bug on all platforms although only legacy Linux plugins have full operating system support to enforce this."

Is he just trying to simplify this for the Plugin Dev? I wish I had known about this function a long time ago.

I understand now that watchdog does not work in other builds and I wonder why I have not heard about this earlier. Perhaps nobody is using the plugin and I should just stop updating it?

filochard commented 3 years ago

Hi Rick Flatpak opencpn and its plugins are not yet ready to use... not as stable and mature as Windows or MacOs nor Linux packages based version It may be considered as a work in progress, and I think there are few people trying to install and test this There's only one version for Windows and one for MacOs ... but every linux distribution is working on its own packages, multiplying efforts adding specific patches : that looks like a waste of time if we consider that flatpak would create a universal version for all the Linux distributions (even if it implies to download lots of libs in the flatpak box that are already provided by the Linux distribution but which flatpak can't have access to)

Some issues are flatpak specific and didn't appear before for the opencpn plugins

Nevertheless some plugins are already OK for flatpak and don't need to be modified (for instance climatology, weatherfax, weather_routing work well, creating their config subdirectory and storing there their user's created files) It's a good thing : they give the possibility to dig and compare why they work inside flatpak and why some others don't

filochard commented 3 years ago

PS Watchdog, logbookkonni, celestial-navigation work perfectly for Linux if I use the rpm based version The new issues appeared only for flatpak that I am testing, hoping this will help to get a perfectly useable opencpn that will simplify the use of it (the Plugin Manager is really an improvement but it would be lots of work to deploy for each Linux distribution)

As an example of the limits of flatpak access to the system : I have already some charts on my computer but flatpak opencpn can't access to them with this simple command :
"flatpak run org.opencpn.OpenCPN" I have to allow the access with this : "flatpak run --filesystem=/mnt/Seagate/CD_ISOS/cartes-marines/ org.opencpn.OpenCPN" And for security this access is read only

There's a real problem with the flatpak watchdog that got access to the place where I stored the personal files of the linux version of opencpn https://github.com/rgleason/LogbookKonni_pi/issues/6#issuecomment-830917980

rgleason commented 3 years ago

Once I can get one plugin fixed, I think the others will be easier. Thanks for letting me know. The problems with charts is concerning but not something I can fix.

filochard commented 3 years ago

Hi Rick

The charts problem is not a problem, but it's the consequence of the fact that installing a flatpak program must be safe for the system you use and give limited access to it

The possibility to access some parts of his system must be explicitly given by the user ... this has not to be fixed in anyway for flatpak The workaround that I show is only useable by me and for the particular tree of my computer... If needed, anyone can modify and adapt this command line (it's well explained in flathub docs)

rgleason commented 3 years ago

I think this command needs to go into the User Manual under Flatpak.

filochard commented 3 years ago

It 's already in flatpak documentation : https://docs.flatpak.org/en/latest/sandbox-permissions.html

Filesystem access

It is common for applications to require access to different parts of the host filesystem, and Flatpak provides a flexible set of options for this. Some examples include:

--filesystem=host - access normal files on the host, not including host os or system internals described below
--filesystem=home - access the user’s home directory
--filesystem=/path/path - access specific paths
--filesystem=xdg-download - access a specific XDG folder

As a general rule, Filesystem access should be limited as much as possible. This includes:

Using portals as an alternative to blanket filesystem access, wherever possible.
Using read-only access wherever possible, using the :ro option.
If some home directory access is absolutely required, using XDG directory access only.
filochard commented 3 years ago

Hi Rick Now that you have found the solution for logbookkonni it maybe be not so hard to obtain that watchdog create the good path inside flatpak : /home/yourusername/.var/app/org.opencpn.OpenCPN/config/opencpn/plugins/watchdog where to store the personnal writeable WatchdogConfiguration.xml file (instead of using an already existing place normally dedicated to a rpm installed version of opencpn, that it finds, but which is wrong for the flatpak version : it uses the linux path => something to modify with the GetPrivateApplicationDataLocation )

filochard commented 3 years ago

PS As there is no way to write issues for the celestial_navigation_pi plugin, and knowing that you develop it too, I inform you that the same problem exists for it to obtain that celestial_navigation create the good path inside flatpak : /home/yourusername/.var/app/org.opencpn.OpenCPN/config/opencpn/plugins/ celestial_navigation where to store the personnal writeable Sights.xml file

Same thing perhaps for polar_pi ?

filochard commented 3 years ago

NB squiddio already creates its own writeable directory int the right place

rgleason commented 3 years ago

Good. Have added watchdog, celestial_nav, weatherfax, working on logbook. Any others that you know about? Thanks.

NB squiddio already creates its own writeable directory int the right place

filochard commented 3 years ago

Hi Rick There is no problem for weatherfax : it creates the good path to store user's files inside flatpak /home/yourusername/.var/app/org.opencpn.OpenCPN/config/opencpn/plugins/weatherfax/ where you may find the downloaded faxes (.png or .tif)
and the .xml files (WeatherFaxInternetRetrieval.xml WeatherFaxSchedules.xml and CoordinateSets.xml)

Some other problems : The SAR icon doesn't appear in the icons tray the Objsearch icon doesn't appear in the icons tray the AISview icon doesn't appear in the icons tray (even if, in preferences, you set it to show its icon )

rgleason commented 3 years ago

Are you using SAR 2.6.20.0 updated Mike R. {Rasbats]. He has done a wonderful job improving it to make it a real useful tool. The helocopter icon shows for Windows. Please report any problem to him after you have checked. What OS again? Linux? or is this for Flatpak? Maybe that is the problem, it needs to use getpPrivateApplicationDataLocation? That is for Mike who is the maintainer here ... https://github.com/Rasbats/sar_pi , I will ask him if he can add Issues and add that he is maintainer in the readme.

rgleason commented 3 years ago

Obj_Search is maintained by Pavel, you can reach Issues from here. Please identify your OS and the version number of the plugin and how you installed it when you report to him. Thank you. https://github.com/nohal/objsearch_pi

rgleason commented 3 years ago

I am maintainer of AISradar here. https://github.com/rgleason/AISradar_pi I have opened Issues there now. In windows the icon shows. Is this for flatpak, please report in Aisradar issues. Thanks.

rgleason commented 3 years ago

filochard wrote: Hi Alec and Rick You may add watchdog plugin https://github.com/rgleason/watchdog_pi the plugin data are in the right place but the user's created files don't see rgleason/LogbookKonni_pi#6 (comment)

filochard commented 3 years ago

Obj_Search is maintained by Pavel, you can reach Issues from here. Please identify your OS and the version number of the plugin and how you installed it when you report to him. Thank you. https://github.com/nohal/objsearch_pi

Indeed objsearch is not yet provided by the plugin manager, so it may not been installed inside flatpak

filochard commented 3 years ago

I am maintainer of AISradar here. https://github.com/rgleason/AISradar_pi I have opened Issues there now. In windows the icon shows. Is this for flatpak, please report in Aisradar issues. Thanks.

issue reported https://github.com/rgleason/AISradar_pi/issues/5#issue-887584845

filochard commented 3 years ago

Are you using SAR 2.6.20.0 updated Mike R. {Rasbats]. He has done a wonderful job improving it to make it a real useful tool. The helocopter icon shows for Windows. Please report any problem to him after you have checked. What OS again? Linux? or is this for Flatpak? Maybe that is the problem, it needs to use getpPrivateApplicationDataLocation? That is for Mike who is the maintainer here ... https://github.com/Rasbats/sar_pi , I will ask him if he can add Issues and add that he is maintainer in the readme.

version 2.6.20 inside flatpak the issue is here : https://github.com/Rasbats/sar_pi/issues/5?_pjax=%23js-repo-pjax-container#issuecomment-838702204

rgleason commented 3 years ago

Line 595 of watchdog_pi.cpp has "wxString watchdog_pi::StandardPath()" which I think is where the paths are set for various OS. This procedure is somewhat different than what the other plugins use and I would like to get this right. Please see the attached txt file for the full procedure watchdog-standardpath.txt

  1. Windows is working as it is but could use the %localappdata%/opencpn/plugins/watchdog/data/ directory
  2. Flatpak is not working
  3. OSX is not working
  4. Ubuntu is not working as far as I know.

In any case, we need to change this to use get as in this note

I have been using this standard for all OS as I have been changing the plugins, but I suppose we could just use GetpPrivateApplicationDataLocation for just the problematical OS, using ifdef statements.

rgleason commented 3 years ago

Logbook_pi.cpp line 725 has

wxString logbookkonni_pi::StandardPath( void )
        {
            wxString s = wxFileName::GetPathSeparator();
            wxString stdPath  = *GetpPrivateApplicationDataLocation();
            stdPath += s + _T("plugins");
            if (!wxDirExists(stdPath))
              wxMkdir(stdPath);
            stdPath += s + _T("logbook");
            if (!wxDirExists(stdPath))
                wxMkdir(stdPath);
            return stdPath;
        }
rgleason commented 3 years ago

In the attached revised file are all the testing ifdef necessary? Can I just substitute/modify the code from logbook? watchdog-standardpath.txt

rgleason commented 3 years ago

Mike R. [Rasbats] was a big help fixing this. Thanks Mike! https://github.com/rgleason/watchdog_pi/commit/352c29f99dc2efedf1f986afb7fec8e4122cc3e1

Will soon push to PIM, but Jon G. has redone android so it will builds, and hopefully it will also work under android.