Errors on non-pi systems

[borpin]

Hi @TrystanLea Just installed on an Ubuntu system. had an error because of hardcoded user name so tried again with the user pi created.

1. No log window

2. Demandshaper not in menu

Just realised it has moved 🤦‍♂

3. Dashboards not imported

4. Cannot create new dashboards

[andyjbm]

Hi,
Also tried to install on a non-pi system (debian based).
Exec summary of issues: mainly hard coded user pi and hardcoded /var/www/emoncms.
Also updater not honouring choices made in install/config.ini at install time.

So this is a quick keyboard bash just to list them before I forget and have to rediscover them next time i do this!

It appears that convention defines webroot in $emoncms_www from the config.ini file but there are places where this is not honoured.

My emoncms webroot is not at /var/www (because this serves another application) its at /srv/dev-disk-by-label-SSD/webroot/emoncms. Now I could create a symlink /var/www/emoncms to point to /srv...etc but...

Seeing the option to define it in install/config.ini in $emoncms_www I thought this was the way to go rather than mucking about with symlinks but there are places where this is not honoured eg the service unit files that point back to the .php and .py files that are the services.

In emoncms/scripts/services/feedwriter/feedwriter.service:

• Hardcoded user pi
• Environment='USER=pi' single quotes should not be there. ie should be Environment=USER=pi
• chown statement failing. Did it manually then commented it out.
• Hardcoded webroot as /var/www/emoncms and not referencing $emoncms_www
• Hardcoded Log path as /var/log/emoncms

feedwriter service fails to start unless feeds redis low write mode is enabled. So is this only for SDcard based installs? Do i not need it then? Do I need to install it?

In emoncms/scripts/services/service-runner/service-runner.service

• User hardcoded as pi
• webroot hard coded as /var/www/emoncms and not referencing $emoncms_www

In emoncms_core.sh updater:

• Only checks for settings.php user changes - not settings.ini. Does this matter? I used settings.ini thinking that was the new way - is this not ready yet? Should I stick with settings.php?

• Reinstall of feedwriter and service runner services will break them because of hardcoded /var/www/emoncms path in the service units.

• The updater will install the mqtt service even if it wasn't installed by the installer (set false in install/config.ini). (Same for feedwriter and service-runner I guess)

All for now..

Thanks, Andy

[borpin]

@andyjbm - it should be better than this.

Just to confirm, you edited the config.ini to set the www path and set the emonSD_pi_env = 0

EmonScripts/install/emonsd.config.ini

Line 6 in 3359f9b

emonSD_pi_env=1

[borpin]

• Hardcoded user pi

This is solved by the use of a drop-in for non-pi users.

EmonScripts/install/emoncms_core.sh

Line 87 in d03d8e1

if [ "$user" != "pi" ]; then

• chown statement failing. Did it manually then commented it out.

It will if the USER is wrong.

feedwriter service fails to start unless feeds redis low write mode is enabled.

Yes Feedwriter, service-runner and emoncms_mqtt all need REDIS - it is a wants in the service file.

I think this is the source of your issues as these services are not installed by the installer unless REDIS is installed.

EmonScripts/install/emoncms_core.sh

Line 78 in d03d8e1

if [ "$install_redis" = true ]; then

• Environment='USER=pi' single quotes should not be there. ie should be Environment=USER=pi

Not according to the docs https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=

[borpin]

• Only checks for settings.php user changes - not settings.ini.

Because the newer 'ini' mechanism is hierarchical, it doesn't need to. In the 'old days' if a new setting was added, the user had to regenerate the settings.php file to include the new setting.

• Reinstall of feedwriter and service runner services will break them because of hardcoded /var/www/emoncms path in the service units.

Depends how you reinstall them. Again, if the emonscripts config is correct, I think it is fine as it passes a $servicepath variable to the service installer.

• The updater will install the mqtt service even if it wasn't installed by the installer (set false in install/config.ini). (Same for feedwriter and service-runner I guess)

That could be a bug. Can you point me to where this may be happening? (I think you are right #96 )

[andyjbm]

Just to confirm, you edited the config.ini to set the www path and set the emonSD_pi_env = 0

@borpin Yes I did all of that. I more or less single stepped through the installer to see what was happening.

[andyjbm]

@borpin

• chown statement failing. Did it manually then commented it out.

It will if the USER is wrong.

I modified the service-runner.service file with USER=root and it still failed: eg:

Environment=USER=root
Environment=LOG_PATH=/var/log/emoncms
PermissionsStartOnly=true
ExecStartPre=/bin/mkdir -p ${LOG_PATH}
# ExecStartPre=/bin/chown ${USER} ${LOG_PATH}
ExecStartPre=/bin/chmod 666 ${LOG_PATH}/emoncms.log

• Environment='USER=pi' single quotes should not be there. ie should be Environment=USER=pi

Not according to the docs https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=

It didn't appear to make any difference actually. I came across more examples without quotes than with.
I tried something like:

touch /var/log/emoncms/$(USER).txt

to see what was happening and the file created was always wrapped in single quotes thus 'root'.txt

At that point life became too short and I just wanted to get the install working.

As an aside I would suggest migrating to a user eg emoncms for the services and for emoncms in general which would make it pi agnostic. In hindsight I wish I'd done that rather than setting them up as root.

Andy.

[andyjbm]

@borpin

feedwriter service fails to start unless feeds redis low write mode is enabled.

Yes Feedwriter, service-runner and emoncms_mqtt all need REDIS - it is a wants in the service file.
Yes the redis service was up and running, in settings.ini redis=true was set but low write was false. Isn't there a distinction between using feedwriter for low write mode feed updates and using redis to communicate to service-runner to execute backups and postprocess?

So I don't actually need feedwriter if I don't want low write functionallity but service-runner will still work?
I'm really wanting backups to work from the webgui which needs redis & service-runner to work. I've sussed that much but not sure on the settings.ini that is required.

I think this is the source of your issues as these services are not installed by the installer unless REDIS is installed.

This was actually an upgrade from V9.8 (2017). So nginx, php, Redis were all installed and up.

I basically renamed my old "/var/www/emoncms" and started again, also moving feed data files from /var/lib to /var/opt/emoncms etc as I could see this is the direction you were headed.
In the new settings.ini I had:

[redis]
enabled = true
...
[feed]
redisbuffer[enabled] = false

And saw that /var/www/emoncms/scripts/feedwriter.php also needed redisbuffer[enabled] = true to work.

Yes Feedwriter, service-runner and emoncms_mqtt all need REDIS - it is a wants in the service file.

It wasn't the service unit. See here, this is what stopped me:

https://github.com/emoncms/emoncms/blob/28fb790b1aba5445f0b6c984e555e5502e491af2/scripts/feedwriter.php#L19

I think I misunderstood whether I needed feedwriter. I'm guessing I don't now.

Andy

[andyjbm]

@borpin

• Only checks for settings.php user changes - not settings.ini.

Because the newer 'ini' mechanism is hierarchical, it doesn't need to. In the 'old days' if a new setting was added, the user had to regenerate the settings.php file to include the new setting.

Ok. So I needn't worry about this.

[andyjbm]

@borpin

• Reinstall of feedwriter and service runner services will break them because of hardcoded /var/www/emoncms path in the service units.

Depends how you reinstall them. Again, if the emonscripts config is correct, I think it is fine as it passes a $servicepath variable to the service installer.

I was thinking I saw a git pull over the top of the emoncms folder in the update script which will overwrite the now modified service-runner.service file in emoncms/scripts/services/service-runner?
As this is symlinked to from /lib/system/systemd the service would not start as the path to the service executable in the .service file is now pointing to a hardcoded base of /var/www/emoncms... etc. (My webroot is not /var/www...)

[andyjbm]

@borpin

• The updater will install the mqtt service even if it wasn't installed by the installer (set false in install/config.ini). (Same for feedwriter and service-runner I guess)

That could be a bug. Can you point me to where this may be happening? (I think you are right #96 )

hardcoded at Lines 90 and 103 in /opt/openenergymonitor/EmonScripts/update/emoncms_core.sh:

for service in "feedwriter" "emoncms_mqtt" "emonhub"; do

EmonScripts/update/emoncms_core.sh

Line 90 in 3359f9b

for service in "emoncms_mqtt" "feedwriter" "service-runner"; do

EmonScripts/update/emoncms_core.sh

Line 103 in 3359f9b

for service in "feedwriter" "emoncms_mqtt" "emonhub"; do

So as they will be present in the /var/www/emoncms folder but not necessarily required or installed as services they will get installed and started when the update is run. The inistall/config.ini settings are not honoured.

Thanks for your help in understanding.
Andy.

[borpin]

As an aside I would suggest migrating to a user eg emoncms for the services and for emoncms in general which would make it pi agnostic.

Happy to accept the PR 😁

I was thinking I saw a git pull over the top of the emoncms folder in the update script which will overwrite the now modified service-runner.service file in emoncms/scripts/services/service-runner?

Yes and that is deliberate. In general it is a bad idea to edit any service file as there is always a risk a package update will overwrite it. Either create your on drop-in or use sudo systemctl edit to create the drop-in then any changes you make survive a service file update.

Feedwriter is a buffering system that reduces disk writes. It costs nothing to run in reality and probably de-stresses any system.

I modified the service-runner.service file with USER=root and it still failed

With what error?

I've successfully installed on Debian with a different user but not with a modified www location.

[borpin]

I'm really wanting backups to work from the webgui which needs redis & service-runner to work.

Ah, did you run the install script with REDIS enabled? It does a number of different things as there are 3 separate bits of REDIS (server, PHP & Python).

[andyjbm]

As an aside I would suggest migrating to a user eg emoncms for the services and for emoncms in general which would make it pi agnostic.

Happy to accept the PR

We'll see how much is left of lockdown when I've got this working... You never know! My weakness is github - I don't use it enough. Lots of one off projects. Now how the heck did you post that smiley emoji? ;-)

I was thinking I saw a git pull over the top of the emoncms folder in the update script which will overwrite the now modified service-runner.service file in emoncms/scripts/services/service-runner?

Yes and that is deliberate. In general it is a bad idea to edit any service file as there is always a risk a package update will overwrite it. Either create your on drop-in or use sudo systemctl edit to create the drop-in then any changes you make survive a service file update.

Indeed. Not come across this situation before. /var/www... seems an unusual place for a service file?? (yeah yeah all PRs appreciated!) And it has hardcoded references. systemctl edit - ok will do it that way.

Feedwriter is a buffering system that reduces disk writes. It costs nothing to run in reality and probably de-stresses any system.

Ok so worth it then. But just to be clear this is just for feeds and not for service-runner messages? I'm seeing that now.

I modified the service-runner.service file with USER=root and it still failed

With what error?

I will try and reproduce and get back to you.

I've successfully installed on Debian with a different user but not with a modified www location.

TBF the different /var/www was the real headache. and moving from /home/pi/data to /var/opt/emoncms was a good step.

[andyjbm]

I'm really wanting backups to work from the webgui which needs redis & service-runner to work.

Ah, did you run the install script with REDIS enabled? It does a number of different things as there are 3 separate bits of REDIS (server, PHP & Python).

I didn't run the install script directly no.
Yes - it was all straightforward enough - php mod for redis, redis for python etc. Followed the install script and executed the commands I needed for what I was missing.

I've mentioned somewhere that this was really an upgrade from V9.8 ish (2017) with a goal of being able to do backup from the gui.
So I started by manually moving /var/www/emoncms (not really where it is but...) and pulling V10. I then manually moved the feed data location and got core working.
So then I needed components to get backup working: I needed Emonscript for backup and saw the installer & update and used the scripts to find out what I needed.
As this isn't a test system I manually worked my way step by step through the installer rather than blindly hitting go as I didn't want to trash what i had.

It wasn't immediately clear what the dependencies were (I've learned a lot in the last couple of days) - ie backup button in gui, backup_controller.php pushes to redis, service-runner polls redis (there's another bug: emoncms/backup#64 ) which then calls the backup script.

I've got it as far as launching a fake backup script so I could validate the paths are all correct. So tomorrow I'll try it for real.

[andyjbm]

@borpin
As promised,

I modified the service-runner.service file with USER=root and it still failed

With what error?

I will try and reproduce and get back to you.

Uncommented the chown command and tried to restart the service.
First off the feedwriter service starts.
It was possibly the issue with redis low write mode not being enabled which meant the feedwriter.php exec would quit making me think the chown issue was preventing the service from starting.
Anyhow the output from systemctl status feedwriter.service is:

root@omv4:/srv/dev-disk-by-label-SSDSpace/webroot-SSD/emoncms/scripts/services/feedwriter# systemctl status feedwriter.service
● feedwriter.service - Emoncms feedwriter script
   Loaded: loaded (/srv/dev-disk-by-label-SSDSpace/webroot-SSD/emoncms/scripts/services/feedwriter/feedwriter.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/feedwriter.service.d
           └─override.conf
   Active: activating (auto-restart) (Result: exit-code) since Wed 2020-06-24 23:45:42 BST; 5s ago
     Docs: https://github.com/emoncms/emoncms/blob/master/scripts/services/install-service-feedwriter.md
  Process: 20035 ExecStartPre=/bin/chown ${USER} ${LOG_PATH} (code=exited, status=1/FAILURE)
  Process: 20031 ExecStartPre=/bin/mkdir -p ${LOG_PATH} (code=exited, status=0/SUCCESS)
 Main PID: 19998 (code=exited, status=0/SUCCESS)

Jun 24 23:45:42 omv4 systemd[1]: feedwriter.service: Unit entered failed state.
Jun 24 23:45:42 omv4 systemd[1]: feedwriter.service: Failed with result 'exit-code'.
root@omv4:/srv/dev-disk-by-label-SSDSpace/webroot-SSD/emoncms/scripts/services/feedwriter#

So the chown command fails but ps -x | grep feedwriter shows the service did start.
I'm not much into systemd but are the mkdir and chown commands being launched simultaneously?
Race condition? mkdir has the dir locked so chown fails? Answer no, I commented out the mkdir and the chown still fails.

Andy.

[andyjbm]

YAY! Found it.

So this line in EmonScripts/install/emoncms_core.sh:

EmonScripts/install/emoncms_core.sh

Line 99 in 3359f9b

echo $'[Service]\nEnvironment="USER='$user'"' > feedwriter.conf

Is where it all went wrong. It creates a drop-in (before I knew what one of those was) .
This then overrides any changes to feedwriter.service I'm trying to make. (You'd know that.) It sets USER to ='root' including single quotes.

The line in the dropin created by the script looked like this:

Environment="USER='root'"

With both the double and single quotes.
Also systemctl show feedwriter.service would show the line:

Environment=USER='root' LOG_PATH=/var/log/emoncms

Once I deleted the Environment line from the dropin with
systemctl edit feedwriter.service
the changes I made in the service file were taking effect. So now this in the service file:

Environment=USER=root
Environment=LOG_PATH=/var/log/emoncms

works and the chown executes, no drop in.

Tomorrow I might try adding it to the drop in without any quotes at all and see if that works as well.

If there is anything else you'd specifically you'd like me to test? I'm not sure if the issue is the drop in, the fact that it's root, the single quotes or a combination of all three.

Andy.

[borpin]

My weakness is github - I don't use it enough.

Initial setup is to create a fork, clone the fork locally and create a new branch for your feature. Then code to your hearts content - VSCode has good integration now for Git.

Now how the heck did you post that smiley emoji?

colon rofl

And it has hardcoded references.

Those should get changed via the SED command during install to the $emoncms_www locations.

Feedwriter is a buffering system that reduces disk writes. It costs nothing to run in reality and probably de-stresses any system.

Ok so worth it then. But just to be clear this is just for feeds and not for service-runner messages? I'm seeing that now.

Depends what 'this' is - service-runner and emoncms-mqtt are triggered via REDIS messages (as you have worked out).

YAY! Found it.

Great - yes that is what it does 😁

The line in the dropin created by the script looked like this:

Environment="USER='root'"

With both the double and single quotes.

That should work despite the funny quotes - I don't think systemd is fussy.

Are you saying the way the dropin is created by the script is not working? - If so can you open a fresh issue please.

To save grief when an update is done, you need to set the service file back to where it was and include a drop-in. Do a git pull to make sure the repo doesn't have any changes else further updates will get blocked.

[andyjbm]

And it has hardcoded references.

Those should get changed via the SED command during install to the $emoncms_www locations.

I didn't see where the /var/www reference in the .service files got changed. Here:

https://github.com/emoncms/emoncms/blob/28fb790b1aba5445f0b6c984e555e5502e491af2/scripts/services/service-runner/service-runner.service#L49

And the same for feedwriter.service.

Are you saying the installer uses an sed to change the /var/www reference there to $emoncms_www contents? I missed that. I don't think it does. But that would also mean a change to the service file would not be overwritten on an update too? Because sed changed it? The updater would have to recognise an update was ok to do and also have to sed again after the update.

The line in the dropin created by the script looked like this:

Environment="USER='root'"

With both the double and single quotes.

That should work despite the funny quotes - I don't think systemd is fussy.

I agree it's not systemd that's fussy, it's the chown command that's fussy. But if you put the literal in the service file thus:

 ExecStartPre=/bin/chown 'root' ${LOG_PATH}

it works but the evaluation of ${USER} to 'root' (incl single quotes) does not.

Are you saying the way the dropin is created by the script is not working? - If so can you open a fresh issue please.

The dropin creation is working if what it creates is correct. We end up with $[USER} being set to 'root' (incl quotes). But the chown command doesn't like it and doesn't execute. (the /var/log/path ownership is not changed) but the service does start (once both redis and redis low write are enabled).

I think the drop in line in the installer here:

EmonScripts/install/emoncms_core.sh

Line 99 in cff186a

echo $'[Service]\nEnvironment="USER='$user'"' > feedwriter.conf

Should look like:
echo $'[Service]\nEnvironment="USER=$user"' > feedwriter.conf
But I really need to set up another box to test it from scratch as there is only so much I should be doing on this production box really.
I can open another issue for this specifically for now?

To save grief when an update is done, you need to set the service file back to where it was and include a drop-in. Do a git pull to make sure the repo doesn't have any changes else further updates will get blocked.

Yes. Understood now. But what about the change of /var/www path mentioned above? I have to do that. If I git pull then the service file has the wrong path to the executable as I'm not using /var/www... My only solution would be an emoncms symlink in /var/www to where my emoncms folder really is but that then needs hiding from what is using the real /var/www. Could be a solution... But that defeats the effort of $emoncms_www as a reference to the real /var/www if I'm just going to solve it with a symlink.

Should/can the change of /var/www path be a drop-in too? What if the names/locations of the feedwriter.php and service-runner.py files change? The drop-in will always override those changes.

I'm not convinced this is resolved but this has moved from getting my production system upgraded into development now so I need to get another box spun up to pursue it further. Ironically I have plenty of PIs available but nothing vanilla debian to hand.

I'll come back to it with some answers when I'm a bit more prepared.

Thanks for your patience so far.

Andy.

[borpin]

You are right, the execution path is hard coded in the service files. I though we had solved that somewhere.

Yes the way to do it is to create a drop-in to override the EXEC when it is a non-standard (non-pi) setup. So where the dropin for the user is created, just create a drop-in for the EXEC path. It might as well always do it, non-pi installs are pretty rare.

Actually I think an environment variable for the emoncms_www path will be the best route.

Could you raise a PR for that and a second one for the $USER issue please?

• Environment='USER=pi' single quotes should not be there. ie should be Environment=USER=pi

Not according to the docs https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=

Actually, when I went back and looked again it can be one of 3 formats (as you had said).

Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"

I'd leave the quotes out altogether.

[andyjbm]

Environment='USER=pi' single quotes should not be there. ie should be Environment=USER=pi

Not according to the docs https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=

The problem is not so much as what systemd allows as what is ultimately being passed to chown and what chown is happy with.
As the code stands now the installer puts:
Environment="USER='root'"
In the dropin. Which means USER evaluates to: 'root' single quotes and all. And systemd is happy thus far. Now this USER is what gets passed to chown.

The issue appears more to be with chown than the systemd nomenclature although as they say put quotes in, get quotes out.
I don't yet understand why chown accepts a literal hardcoded

chown 'root':user /mypath

with quotes however unusual but will fail when it is evaluating essentially the same from ${USER}. Is that systemd or chown being hinky? I've no idea. But either way definitely something hinky going on there as Abby would say.

Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"

I'd leave the quotes out altogether.

...and chown and I would agree with you also - because it works. Still not sure on systemd's opinion. I don't think it cares.

I'll try with the PR sometime next week when I've got a dev env up and a bit more time. It will be my 1st on github so be patient!

A.

[andyjbm]

You are right, the execution path is hard coded in the service files. I though we had solved that somewhere.

Yes the way to do it is to create a drop-in to override the EXEC when it is a non-standard (non-pi) setup. So where the dropin for the user is created, just create a drop-in for the EXEC path. It might as well always do it, non-pi installs are pretty rare.

Actually I think an environment variable for the emoncms_www path will be the best route.

I'm not sure that /var/www is the best place for a service file and its executable in the 1st place? I appreciate how emoncms has evolved from a purely web based implementation and how that location makes for an easy git pull update but moving away from the pi domain SDCard image deployment which you have complete control over to "grown up" platforms which emoncms is surely worthy of I think service files and executables need to be outside of /var/www. (Wherever that should be). /opt?

But that is quite an architectural change from the current emoncms deployment from an installer point of view.

As I understand it software (debian perspective) that has no dpkg management goes in /opt. But then I'm a windows chap for my sins. And really electronics hardware 1st. So when it comes to linux environment I can tell you what's wrong and how I made it work for me but not necessarily the best practice way to fix it. But I'm keen. ish.

What do you think?

A.

[borpin]

The problem is not so much as what systemd allows as what is ultimately being passed to chown and what chown is happy with.
As the code stands now the installer puts:
Environment="USER='root'"
In the dropin. Which means USER evaluates to: 'root' single quotes and all. And systemd is happy thus far.

Agreed but systemd is doing what it is being asked to do, set the USER to 'root' 😁.

But either way definitely something hinky going on there as Abby would say.

🤣

I'm not sure that /var/www is the best place for a service file and its executable in the 1st place?

You are not going to change that anytime soon! - @TrystanLea

It was quite a move to put most of the executable stuff in /opt and symlinking the service files - yes the next logical solution is to move the service files into opt but right now it works and we have slightly bigger fish to fry such as migrate fully to Python3!

but not necessarily the best practice way to fix it. But I'm keen. ish.

That's fine, but this one probably needs to be left alone for now (in terms of exe location) and just fix the www and the USER issues to make it actually work.

It will be my 1st on github so be patient!

No bother, got to start somewhere. DM me or start a thread on the community.

[andyjbm]

Hi @borpin,
Still resolving issues after the upgrade to my emoncms and something else I've come up against that I'd like to run by you.

I apologise 1st for another long post but hopefully it is worth it.

So my previous install did not have any of the symlinked modules installed. I added the backup module and the postprocess module (in the install/config.ini file) as they looked useful to me.

So at first trying to get postprocess to work from the webgui it would just "stop" after the create process button was pressed because (after much faffing) I discovered that the postprocess table was not created in the emoncms mysql database.

This is partly my bad because I did not run this line:

EmonScripts/install/emoncms_modules.sh

Line 52 in cff186a

php $openenergymonitor_dir/EmonScripts/common/emoncmsdbupdate.php

from the command line. Instead I performed a database update from the webgui admin page.

But this did not create the postprocess table because at that point the directory /opt/emoncms/modules/postprocess had ownership root:root whereas running the line 52 above would have updated the database (I trust). Hands up - my fault so far... but I did not know this at this stage.

Going back to EmonScripts/install/emoncms_modules.sh (because I ran it as root) I still end up with a folder /opt/emoncms/modules/postprocess symlinked into /var/www that has chown root:root ownership and can't be seen by www-data which is what my nginx and php services are running as.
At some point when I couldn't see postprocess in the gui I would have seen the directory ownership root:root, gone "ahh" and chowned everything in /opt/emoncms to www-data:users and thought I was done with it. This is how I got to the state of a "working" web interface but missing the database update to the postprocess table.

Once I discovered this was the case I went back to the web admin and lo and behold there were the database updates waiting to be committed. Of course now the webgui could see the module directories now I had chowned them www-data:users.

So I started to dig a bit into the install process again:
From what I can tell the intention is that install/init.sh is called as pi user according to here:
https://github.com/openenergymonitor/EmonScripts/blob/master/install/readme.md#install-the-emoncms-installation-scripts

Then init.sh calls main.sh which loads the user from config.ini and eventually calls emoncms_modules.sh

In emoncms_modules.sh the symlinked modules are git pulled but the ownership of these directories are never modified.
As I ran this as root, that's what the ownership became. On a pi I'm guessing the ownership would be pi and your php/nginx (or apache) is running as pi? so this won't be a problem? I dunno - 2015 since I last ran emoncms on a pi.

So starting here:

EmonScripts/install/emoncms_modules.sh

Line 19 in cff186a

if [ ! -d $emoncms_dir ]

1. The /opt/emoncms is created and chowned if it doesn't exist but NOT chowned if it already exists. It's chowned to the user set in installs/config.ini which for me was root.

2. Next the modules directory is created if it does not exist but not chowned. Mine was created as root.

3. Then we iterate through the modules, get them from github and symlink to them and run their installers if they have one.
   But no chowning of these directories or contents. They get the ownership of the user that called init.sh

4. Finally the database update runs as the user that runs init.sh

So in conclusion lots of questions.

A. What users would you expect nginx and php to be running as? www-data or pi or something else?

B. I will confirm once I'm done with this live system upgrade and have time for dev but I think I'm right in that a fresh install run as root would leave you with /opt/emoncms chowned to the user set in config.ini but modules dir and each modules/module1-module etc dir chowned as the user that ran the ./init.sh

C. I'm thinking these should all be accessible to www-data? But that's because that's what my php is executing under.

Thanks once more,
Andy.

[borpin]

Hi @andyjbm, realised I'd never responded.

You are right, the scripts started off from a very 'pi' orientated base - on Ubuntu, I create a user pi and use that!

The scripts also expect Apache not nginx and it is unlikely we would modify the scripts to meet that requirement.

[borpin]

I think this can now be closed.