make DESTDIR=xxx fails - Githubissues

gene-git commented 10 hours ago

Did you read the guide?

Yes

What is the base version number of MotionPlus being used?

0.2.x

What was the install method?

Built from source code

What is base architecture?

x86/x64

What is the distro being used?

Other

Disto version number

Arch linux

Camera/Sound type(s) being used?

Network camera with RTSP

Describe the issue/problem and steps to reproduce

git master as of 55026768f44fafc8910a0a86559597c5554c69dd

make DESTDIR=xxx install

is now failing with:

cp: cannot stat '/usr/var/lib/motionplus/motionplus-dist.conf': No such file or directory
make: *** [Makefile:1007: install] Error 1

Error message is also a bit strange - /usr/var ?

Config was set using:

 autoreconf -fiv
    ./configure --prefix=/usr --without-pgsql --without-mysql --sysconfdir=/etc  --with-webp --with-ffmpeg --enable-dependency-tracking

Relevant MotionPlus log output (at log_level 8)

N/A

Mr-Dave commented 5 hours ago

I'll try to determine what is happening with DESTDIR but also would invite your feedback.

The historical location for configuration files was in /etc/motionplus. But this location poses problems because the application can not change/revise the parameters. It effectively forces the running of the application as sudo (which is strongly discouraged) and also doesn't provide a "working and persistent" location for things such as a sqlite3 database.

To solve this, I reviewed the GNU standards (and what other applications were using) and selected the $(localstatedir)/lib/@PACKAGE@ location. Upon use of a deb package, this would be /var/lib/motionplus and if installing as /usr prefix, it would be /usr/var/lib/motionplus.

The GNU standards were not however entirely clear. User changed configuration files are indicated to be in 'sysconfdir' or 'datadir' but data changed by applications is in 'localstatedir' and shouldn't be modified directly by the user. With this contradiction in options and requirements, I choose the localstatedir since it needed to be read/write.

Looking at the big picture, this directory change is to allow for the creation of a better user interface and setup with Motionplus. Users would be able to use the web interface by default to set up the cameras and also Motionplus would create a simple sqlite3 database so all the functionality would be available.

gene-git commented 4 hours ago

Right gotcha.

thanks for checking on DESTDIR likely being dropped somewhere.
"/usr/var" is obviously weird and should never be used.
- Solution is for the packager (me) is simply to set the configure opt:
- localstatedir=/var

Now onto Settings - where & how to save.

I understand the /etc/xxx vs /var/lib/xxx question reasonably well I think.

And I agree with you that dynamic or programmatic settings should be in /var/lib not /etc.

Now I would encourage building a standalone 'tool' which does settings via command line; and that any GUI (web or other) either use that tool or share a common core library. GUI is not always ideal from a sys admin perspective (though it can be for some) - and it is often preferred by home users. A clear separation of UI from underlying function is a good approach in my view, so I would still prefer both CLI and GUI to manage configurations.

Now on to 'where' to save such configuration settings.

Bottom line:

I vote for a combination of /etc/ (read only) configs and /var/lib/:
- /etc/motionplus for read only static configs (camera definitions possibly, access permission, database passw etc)
- /var/lib/motionplus for those dynamic and writable by motionplus user/group.

I would not have the tool overwrite any of the static settings which is live in /etc. But perhaps in your thinking you might prefer to read /etc first and then allow the tool to over write things into /var/lib - which would be fine too provided there is a simple way to see all the configs which have been overridden.

Off the cuff, my thinking is driven by what is typically done by the majority of applications.

Most commonly, they use a sequence of directories with a documented hierarchy order.

Applications which have built in (static) defaults (.e.g systemd) typically follow the hierarchy from lowest to highest priority as : /var/lib, /etc, /home/xxx/yyy. With /home being the final winner.

Some Applications that use programmatic settings do the same - e.g. gui settings (kde, or gnome).

Other applications (e.g. iwd or network manager) essentially use a command line tool for specific settings (networks in this example) and save result in /var/lib - and again users are allowed to have networks in /home/xxx/.config/xxx . In addition other settings remain /etc - in this case non-networks.

I'll also mention keycloak - this uses /etc/ and /var/lib - has a web gui and offers a command line tool. /etc/ config includes database access info (type, user, password), the certs for webserver to use etc - the database itself is in /var/lib.

My preference would be to keep /etc as the base config, and the tool would then start with /etc. This kind of makes sense as:

there may be some things which seldom change - e.g. list of and definitions of cameras possibly
it allows users to keep using /etc and still get benefit of programmatic things.
and other things may be more dynamic and better suited to tool.
for remote admin, CLI would then be heplful to work with /var/lib - simpler than using vpn + browser anyway which may or may not be possible.

While I can kind of imagine using /home for the motionplus user I definitely prefer to stick with /etc + /var/lib, as I favor keeping /home for humans.

Thanks again

gene-git commented 4 hours ago

Another (obvious) point.

From a security perspective things in /etc/ should be read only and not changeable by the lower privilege running application/tools. So any config in /etc/ should not be changeable and not be overridden into /var/lib either.

Mr-Dave commented 2 hours ago

I found the issue causing the problem with DESTDIR. The revised install is creating a motionplus.conf and camera1.conf and did not include the DESTDIR.

For the configuration files, the option to revise these via the CLI will continue. Webcontrol of the parameters is an option, not a requirement. I just want to make this more user friendly for non-technical users.

Regarding keeping some parameters as read only and in /etc/motionplus while others are in the /var/lib/motionplus I had not thought of that. On the surface it sounds good but as I think through what would go where, it seems that there is actually only one parameter (webcontrol_params) that is read only. All the other parameters are available so users can just install Motionplus and do all the configurations(including adding cameras) via the webcontrol. With it just being the one parameter, it seems like it would be overkill to create a directory and file just for that. (It would also probably confuse some users with the different location just for that one parameter).

gene-git commented 1 hour ago

Right makes sense - I guess no database password or ssl certs - about all I can think of offhand that might be /etc/ worthy - otherwise sounds good.