# emonSD issues created using new scripts + emonhub environment file

**URL:** <https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918>\
**Category:** emonSD\
**Created:** [11 May 2019 09:45 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918 "2019-05-11T09:45:32Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [29 May 2019 15:30 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/101 "2019-05-29T15:30:33Z")

</div>

> [@pb66](#):
>
> I’m really not sure whats being proposed!

The proposal is to apply these changes to the emonhub service (as discussed above) [https://github.com/openenergymonitor/emonhub/compare/env\_example](https://github.com/openenergymonitor/emonhub/compare/env_example)

The .env file is loaded from /etc/emonhub/emonhub.env and contains the content:

```
EMONHUB_SRC=/opt/emon/emonhub/src
EMONHUB_CONF=/etc/emonhub
EMONHUB_LOG=/var/log/emonhub

```

The default .env file is copied from the emonhub service directory (not symlinked). Most users dont need to change it, but users who wish to use different paths can change it.

The service runs emonhub directly from the install directory (/opt/emon/emonhub/src) without a symlink via /usr/local/bin. Rationale behind this approach is given by @djh that /usr/local/bin and /usr/share are not suitable install locations.

---

<div class="post-metadata">

**Author:** ![alexandrecuer](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/alexandrecuer/32/9158_2.png) [@alexandrecuer](https://community.openenergymonitor.org/u/alexandrecuer)\
**Post date:** [29 May 2019 16:12 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/102 "2019-05-29T16:12:52Z")

</div>

@borpin : i did not install anything from the dietpi software, just a raw install  
Then installed everything with the new scripts from apache2 to emoncms\_modules…All seemed to be fine…managed to create 1st user…anyway after rebooting the VM, redis-server did not start and i had To create /var/log/apache2 by hand  
Then i removed redis and reinstall with apt…now it is ok even after some reboots…  
I wanted to try dietpi cause the img is smaller than raspbian

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [29 May 2019 16:21 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/103 "2019-05-29T16:21:24Z")

</div>

> [@alexandrecuer](#):
>
> i did not install anything from the dietpi software, just a raw install

The bit that may well cause an issue is the use of Log2Ram. I would disable that in the install scripts and, if on an SDCard, use DietPi’s own RAM logging system.

However, it looks like you are on a VM (HDD?) so there is absolutely no reason to use a tmpfs location for the log folder.

You can change what is installed in the `config.ini`.

> [@alexandrecuer](#):
>
> Then i removed redis and reinstall with apt

Any particular reason to do this?

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [29 May 2019 16:35 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/104 "2019-05-29T16:35:06Z")

</div>

> [@borpin](#):
>
> Does it work on Jessie or are you dropping support for that distro?

Testing here on jessie based emonSD-07Nov16, it works fine.

> [@borpin](#):
>
> How will you manage the file?

yes I think use a default that is copied to /etc/emonhub/emonhub.env

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [29 May 2019 16:39 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/105 "2019-05-29T16:39:47Z")

</div>

> [@alexandrecuer](#):
>
> Maybe env variables could be set up in the admin module

Thanks @alexandrecuer, to start with I only wish to use the .env file for this minor task of setting the emonhub paths. I think your suggestion could fit in the hierarchical settings discussion but I would like to come back to that one after reaching the first release of the image build scripts.

> [@alexandrecuer](#):
>
> Nice job…working fine on Ubuntu, still could not make them work on a dietPI…

Thanks, emonhub should be failing at the moment as it needs these changes for the paths to work but its getting there!

---

<div class="post-metadata">

**Author:** ![alexandrecuer](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/alexandrecuer/32/9158_2.png) [@alexandrecuer](https://community.openenergymonitor.org/u/alexandrecuer)\
**Post date:** [29 May 2019 16:49 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/106 "2019-05-29T16:49:30Z")

</div>

Thanks @borpin  
Sure I did not install log2ram…I put the emonSD var to 0 in the config.ini  
and I did not install emonhub as @TrystanLea is modifying settings and proceeding to experiments…

> emonSD\_pi\_env=0  
> install\_emonhub=false

As far as redis is concerned, I have no rational explanation why it did not want to start but it was a log problem…there was no redis folder in /var/log  
now there is one and it belongs to the user redis / group redis

---

<div class="post-metadata">

**Author:** ![alexandrecuer](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/alexandrecuer/32/9158_2.png) [@alexandrecuer](https://community.openenergymonitor.org/u/alexandrecuer)\
**Post date:** [29 May 2019 16:56 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/107 "2019-05-29T16:56:45Z")

</div>

@djh I was thinking about that for the modules…once emoncms core and its admin interface are running, it would be very interesting to have control over the module configuration from the admin interface…my subject was just this one…

---

<div class="post-metadata">

**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\
**Post date:** [29 May 2019 22:53 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/108 "2019-05-29T22:53:50Z")

</div>

> [@TrystanLea](#):
>
> > Does it work on Jessie or are you dropping support for that distro?
> 
> Testing here on jessie based emonSD-07Nov16, it works fine.

I don’t know how many folks here are aware of this, so I thought I’d mention it…

From: [https://news.softpedia.com/news/debian-gnu-linux-8-jessie-will-reach-end-of-security-support-on-june-17-2018-521216.shtml](https://news.softpedia.com/news/debian-gnu-linux-8-jessie-will-reach-end-of-security-support-on-june-17-2018-521216.shtml)

- According to a [security advisory](https://lists.debian.org/debian-security-announce/2018/msg00132.html) posted by developer Moritz Muehlenhoff on the [Debian](https://linux.softpedia.com/downloadTag/Debian%20Linux)-security-announce mailing list, the Debian GNU/Linux 8 “Jessie” operating system series will no longer receive regular security updates as of June 17, 2018. However, a limited number of packages will still be updated for a while.

**LTS support to be provided until June 6, 2020**

After June 17, 2018, the Debian Long Term Support (LTS) project will continue to provide support for various essential packages and architectures for two more years, until June 6, 2020, when the Debian GNU/Linux 8 “Jessie” operating system series will reach end of life and it won’t be available to download anymore.\*

Among the supported hardware architectures, we can mention 32-bit (i386), 64-bit (amd64), Armel, and ARMhf. However, those who still want to use Debian GNU/Linux 8 “Jessie” on their computers should keep in mind that Debian LTS support is provided by a group of volunteers, not by the Debian Security team.

* * *

So it looks like we’ve got about one more year until it’s totally unsupported / gone.

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [30 May 2019 11:17 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/109 "2019-05-30T11:17:33Z")

</div>

Thanks @Bill.Thomson this is a good point and its a good reason to do a full image update (with an export/import of data) rather than use the emonpi updater for updates that are more than 1-2 years.

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [4 June 2019 16:47 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/110 "2019-06-04T16:47:34Z")

</div>

Following from [emonSD next steps: filesystem & logrotate - #192 by TrystanLea](https://community.openenergymonitor.org/t/emonsd-next-steps-filesystem-logrotate/10693/192)

The merge of the emonhub.env version of emonhub is ready to go, the update procedure to install the emonhub.env file is now live in the latest emonpi repository: [add emonhub.env settings file and install as part of update · openenergymonitor/emonpi@693ebd7 · GitHub](https://github.com/openenergymonitor/emonpi/commit/693ebd7d48dff90077f38612f81c14ec1b2c994d)

The final step is to merge the following emonhub pull request [Use emonhub.env to set emonhub path names by TrystanLea · Pull Request #82 · openenergymonitor/emonhub · GitHub](https://github.com/openenergymonitor/emonhub/pull/82/files). I will merge this tomorrow unless there are any final objections

---

<div class="post-metadata">

**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\
**Post date:** [4 June 2019 22:52 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/111 "2019-06-04T22:52:02Z")

</div>

I have to say that I’m still not sold this yet. I want to be on the same page but I must be missing something as I can see no great benefit, in fact I see it as restricting the flexibility and choice of paths.

There are 3 paths defined in the env file supposedly to make them configurable.

```auto
EMONHUB_SRC=/opt/emon/emonhub/src

```

This path to the executable is unlikely to change because the source is currently expected to always be installed to `/opt/emon/emonhub`.

```auto
EMONHUB_CONF=/etc/emonhub

```

Since the location of the env file itself is hardcoded in the service unit to this same path, it seems unlikely that any user is likely to install emonhub.conf anywhere else but here.

```auto
EMONHUB_LOG=/var/log/emonhub

```

Of the 3 this, I thought was the least likely to be moved. If the user was to consider another log location, I would assume that location might well be syslog, alas changing this path will not facilitate logging to syslog. For that to happen the `--logfile` arg needs to be removed entirely.

So whilst i see having an env file does breakout 3 paths to be user configurable, it doesn’t really add much flexibility in practice. What it does add is an extra configuration file and the associated installer lines

This additional config file just adds complexity for all users to provide a narrow avenue of flexibility to a few but not all users. This option came about due to not agreeing about where the executable should be installed/symlinked, but you have opted for using the cloned source path directly, that decision alone removes the larger share of any potential ambiguity over paths.

Since these same 3 paths will be used in a majority of cases, there seems no point having the env file there for all users, especially sat in the same folder as the emonhub.conf we encourage users to edit, that’s just too tempting for some tinkerers.

If the service unit was hardcoded with the same paths, it would be cleaner and simpler for the majority of users. When an alternative configuration is needed a simple drop-in can be added either via `systemctl edit` or by adding the file directly.

That drop-in has the ability to edit any of the same variables as the env file approach, but it also has the ability to revert to syslog, change the executable or python version and doesn’t demand another hardcoded path to the env file. Yes the drop-in file path is fixed, but we are already tied to the systemd paths anyway.

With the word “final” being used in the last paragraph not once but twice, I thought I ought to go on record with my opinion rather than waiting until we are evaluating and testing. I get the impression that the move from here to delivered is likely to be quite swift.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [5 June 2019 07:11 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/112 "2019-06-05T07:11:38Z")

</div>

> [@pb66](#):
>
> I can see no great benefit, in fact I see it as restricting the flexibility and choice of paths.

> [@pb66](#):
>
> Since the location of the env file itself is hardcoded in the service unit to this same path, it seems unlikely that any user is likely to install emonhub.conf anywhere else but here.

I think I am probably in agreement here. Remind me, what problem was the ENV file trying to solve? IIRC it was around using the home folder as the install location. If this is no longer being used, what advantage does it give?

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [5 June 2019 11:32 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/113 "2019-06-05T11:32:26Z")

</div>

The key problem that this .env file solves is the issue of the emonhub src path. Yes your right the log file and config location are not strictly needed and are unlikely to be changed, but the configurability of the emonhub src path will be used straight away, it solves the problem of supporting emonhub on the existing emonSD images where the src path is /usr/share/emonhub and the new build script where the src path is /opt/emon/emonhub.

@djh made a clear point about the unsuitability of /usr/share and /usr/local/bin for emonhub installation or symlink above. The .env file provides flexibility.

An alternative could be to fix on /opt/emon/emonhub as the install path and move emonhub to this location on older images as part of the update process. Personally I like the .env approach, it works.

---

<div class="post-metadata">

**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\
**Post date:** [5 June 2019 12:06 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/114 "2019-06-05T12:06:13Z")

</div>

> [@TrystanLea](#):
>
> it solves the problem of supporting emonhub on the existing emonSD images

Ah yes.

---

<div class="post-metadata">

**Author:** ![alexandrecuer](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/alexandrecuer/32/9158_2.png) [@alexandrecuer](https://community.openenergymonitor.org/u/alexandrecuer)\
**Post date:** [5 June 2019 19:51 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/115 "2019-06-05T19:51:46Z")

</div>

personally, I find the approach very attractive for code maintenance…it will throw the config out of the code which is clever…

If I understand correctly, the log files would all be in  
`/var/log/<module_name>` and the conf files in `/etc/<module_name>`

so the PHP controllers should be able to access environment variables in a fairly simple way with a file\_get\_contents for example…

@TrystanLea: would you be interested in a proposal like this for the config module ?

```auto
if ($env = file_get_contents("/etc/emonhub/emonhub.env")){
    preg_match_all("/([\w_]+)=([\/\w]+)\n/",$env,$vars);
    $ehenv=array_combine($vars[1],$vars[2]);
    $emonhub_config_file=$ehenv["EMONHUB_CONF"];
    $emonhub_logfile=$ehenv["EMONHUB_LOG"];
}

```

probably the best would be to implement this in settings.php and to use global vars in modules controllers…

---

<div class="post-metadata">

**Author:** ![djh](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/e36b37/32.png) [@djh](https://community.openenergymonitor.org/u/djh)\
**Post date:** [5 June 2019 21:27 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/116 "2019-06-05T21:27:05Z")

</div>

Along time ago in a galaxy far, far away I mentioned:

> [@djh](#):
>
> It looks like the best way to read them into a PHP environment is with the dotenv package as described at [https://scotch.io/tutorials/how-to-use-environment-variables#toc-getting-environment-variables-with-php](https://scotch.io/tutorials/how-to-use-environment-variables#toc-getting-environment-variables-with-php) . There’s also a python-dotenv package that does something similar.

---

<div class="post-metadata">

**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\
**Post date:** [5 June 2019 22:10 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/117 "2019-06-05T22:10:28Z")

</div>

Thanks @alexandrecuer probably the best place for this would be in process\_settings.php with the .env path settable in settings.php . I think it would also be good to come back to this as part of the hierarchical settings discussion.

---

<div class="post-metadata">

**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\
**Post date:** [6 June 2019 00:56 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/118 "2019-06-06T00:56:07Z")

</div>

> [@djh](#):
>
> Along time ago in a galaxy far, far away I mentioned:

Use _The Force,_ Luke, er Dave. 😀  
Sorry. Couldn’t resist. 😉

---

<div class="post-metadata">

**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\
**Post date:** [6 June 2019 12:10 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/119 "2019-06-06T12:10:31Z")

</div>

> [@TrystanLea](#):
>
> but the configurability of the emonhub src path will be used straight away, it solves the problem of supporting emonhub on the existing emonSD images where the src path is /usr/share/emonhub

As does adding a drop-in with an adjusted ExecStart line like so

```bash
sudo mkdir -p /etc/systemd/system/emonhub.service.d/
printf "[Service]\nExecStart=\nExecStart=/usr/share/emonhub/emonhub.py --config-file=/etc/emonhub/emonhub.conf --logfile=/var/log/emonhub/emonhub.log" | sudo tee /etc/systemd/system/emonhub.service.d/override.conf > /dev/null

```

I do not see this as any harder than editing the default env file for use on the existing emonSD’s.

Adding an env file is not necessary just to accommodate the old path on existing emonSD’s, however if you were adding an env file, the correct location would be `/etc/default/emonhub` IMO, there is already a file there that contains the default paths for the previous init.d script.

> [@TrystanLea](#):
>
> the new build script where the src path is /opt/emon/emonhub.

I disagree with that choice too, but will come back to that

> [@TrystanLea](#):
>
> @djh made a clear point about the unsuitability of /usr/share and /usr/local/bin for emonhub installation or symlink above.

He did indeed offer some wise words. Firstly `/usr/share`

> [@djh](#):
>
> BTW, the symlink to /usr/share is not something I would allow on my machine. That’s a distro-only directory so I’d want to change it to something else.

This path has always been wrong for the emonSD, it was originally used in my separate “for development” install script which purposely mimicked a Debian package as that’s what we were developing for at that time. It was never intended and should never have been included in the emonpi emonhub repo as a mainstream installer. I have already pointed out more than once (even in this same thread) this path is not right.

> [@pb66](#):
>
> The current emonhub path ( `/usr/share/emonhub/emonhub.py` ) was based on an expectation for emonhub to be a debian package one day, the original emonhub install script I wrote was called “[dev-emonhub](https://github.com/emonhub/dev-emonhub)” as it installed the repo and symlinked to the correct debian package location’s _for the **dev** elopment of emonhub_ , the content of that script was taken into the emonpi variant of emonhub’s repo. Although I think the concept is right, the paths may need tweaking inline with the linux FHS if not going to be debian packaged.

> [@pb66](#):
>
> besides, /usr/share was the proposed location for when emonhub was to be Debian packaged, I think /usr/local/bin/ might be more suitable for emonhub.

Secondly . . .

> [@djh](#):
>
> > is the same true for /usr/local/bin as @pb66 suggested?
> 
> No, but . . .

and provides further explanation of why both the exectable and conf paths should include `/opt` as per the FHS if the repo is **installed** to `/opt`.

Whilst I do not disagree with the exact interpretation of the FHS, I reiterate that _my_ suggestion to use `/opt` was purely for a convenient place to **clone** the repo’s, so that we could **install** via symlinks to the various distro specific locations.

So if understand correctly the 2 different strategies seem to be

1. clone the repo’s to some arbitrary location and then (on Debian/Raspbian) use more familiar paths such as /etc/emonhub and /usr/local that are also configurable to the various distro’s, using symlinks to the cloned source where appropriate, much like to the service units and various other files are already. For the record, this doesn’t _need_ to be cloned to `/opt` specifically it can be anywhere, and the exact /usr/local path can be tweeked if there is a better (non-opt) suggestion.

2. install the repo’s to /opt and adhere to the FHS by installing the conf files to an `opt` path too. I presume embracing this strategy would also involve serving the emoncms www files from and opt path too? This will obviously not avoid the use of symlinks for many things such as service units and conf drop-ins and it presents a new fixed set of (opt) paths rather than a universal staging poimnt from which various distro’s can be accommodated.

Your current implementation doesn’t follow either of these, instead you have chosen to use the `/opt` executable path in the service units whilst keeping the conf files in the general FS. This (IMO) seriously reduces flexibility, confuses strategies and offers very little consistency. Using (for example) a symlink at `/usr/local` is in keeping with using /etc/emonhub, consistent with symlinking the service unit etc and detaches the front line paths from the cloned repo paths, offering a layer of flexibility.

Imagine for a moment the emonSD image wasn’t already using the wrong path, say it had always used or perhaps gets repaired in an update using something like

```auto
if [-h /usr/share/emonhub]; then sudo ln -s /home/pi/emonhub/src /usr/local/bin/emonhub; sudo rm /usr/share/emonhub; fi

```

(rolled out the same time as the new service unit!)

then the same path would be portable across images regardless of whether the source is cloned to `/opt/emon`, `/home/pi` or `/on/the/moon` and we wouldn’t need to be having a env file just to accommodate a previous error that can be resolved in so many other ways that would just disappear with the old images as they disappear rather than being stuck with an env file for eternity for the wrong reasons.

Just to be clear here, I’m not entirely against using an env file(s) for the wider project, that’s why I was biting my tongue earlier and hoping for the use of the env file to evolve into something else, to justify it’s existence. IMO there is a good reason to have a system wide env file (or directory of drop-in files) of paths for use at the install/update stages, but they would not be used in normal running.

For example, if the installer had no hardcoded paths at all and used a env file to set the systemd paths, the cloned repo paths, the log paths, the config paths etc etc etc, then at install time, regardless of where the repos were cloned, it would create the symlinks as prescribed by the “debian” env file, or alternatively the “opensuse” env file (for example). These env files would only be used during “install” and “update” and would promote an easy route to installing to any (systemd) distro as users/devs can create their own env files (and submit them!).

In short, there are 2 methods provided above to accommodate the old images and I can think of several more, none of which have a lasting effect beyond the existence of the old emonSD images, this is not a good reason for the env file, there are however, other good reasons for a env file, but not in it’s current form. And we really should try to remove ALL hardcoded paths from the installer.

If the use of `/opt` is muddying the waters, lets use something else eg `/repos` or `/emon` in the root of the fs?

PS as a side note, when I suggested using ‘/opt’ I actually envisaged `/opt/emoncms/<repo>` and `/opt/openenergymonitor/<repo>` (not `/opt/emon`) being used so that it was clear where the source was to be found on github and how the emoncms modules were in separate repo’s and the various FW repo’s etc. Since it’s arbitrary where the repo’s are installed as long as they are all together and fairly separate from the main FS, putting them in \<git-organistation\> subfolders provides additional info to the user regards navigating the repos, both locally and at github.

---

<div class="post-metadata">

**Author:** ![djh](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/e36b37/32.png) [@djh](https://community.openenergymonitor.org/u/djh)\
**Post date:** [7 June 2019 19:09 UTC](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918/120 "2019-06-07T19:09:02Z")

</div>

The point of .env files is that they can be read and used by all programs written in whatever language. So there can/should be no hard-coded paths anywhere in the system. The only hard-coded paths should be the env files and paths within them. Then there’s some chance of portability.

Although there’s still the question of service names for e.g. the redis service. Those can go in the env files or separate conf files, but should not be hard-coded throughout the system.

[Previous page](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918.md?page=5)

[Next page](https://community.openenergymonitor.org/t/emonsd-issues-created-using-new-scripts-emonhub-environment-file/10918.md?page=7)