# emonSD next steps

**URL:** <https://community.openenergymonitor.org/t/emonsd-next-steps/10426>\
**Category:** emonSD\
**Created:** [18 March 2019 15:12 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426 "2019-03-18T15:12:03Z")\
**Posts on this page:** 20\
**Page:** 6

<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 April 2019 14:37 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/101 "2019-04-05T14:37:25Z")

</div>

> [@TrystanLea](#):
>
> Can you load a configuration file from a systemd service file?

Sort of, but it still ends up with a hard coded path.

The install/update script I have seen (and cannot remember what now), simply wrote the required text to a new file (having checked and deleted any existing file) direct to the required systemd folder (`/lib/systemd/system`) - no symlink required. Any paths can then be generated in the script before writing the text.

> [@TrystanLea](#):
>
> /opt/ looks like a better install location /opt/emon/

> [@TrystanLea](#):
>
> any views?

No views.

If you remember the Pauls (@pb66 @Paul) had a discussion suggesting a [data structure that accounted for multiple installations](https://community.openenergymonitor.org/t/move-data-settings-file-to-a-common-location/6464). This seemed to only cover the data though not the other bits.

---

<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 April 2019 14:47 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/102 "2019-04-05T14:47:26Z")

</div>

Thanks @borpin I like the ‘paths can be generated in the script’ approach. I have this now working for both the emonhub and demandshaper services, e.g: [https://github.com/emoncms/demandshaper/blob/master/install.sh#L20](https://github.com/emoncms/demandshaper/blob/master/install.sh#L20) - the install.sh script in the demandshaper module is called from emoncms\_modules.sh

Thanks for the link, that discussion did cross my mind when thinking about the /var/lib/phpfina etc locations. I will have a good read through again.

---

<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 April 2019 14:52 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/103 "2019-04-05T14:52:15Z")

</div>

> [@TrystanLea](#):
>
> I like the ‘paths can be generated in the script’ approach. I have this now working for both the emonhub and demandshaper services

That works. What I had seen was actually redirecting an echo output as the required file.

I would add a comment in though 😄

---

<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 April 2019 15:31 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/104 "2019-04-05T15:31:49Z")

</div>

Comment added 🙂

I’ve moved much of the emonhub installation process to the emonhub repo itself, replacing the existing install scripts that where emonpi specific. [emonhub/install.sh at emon-pi · openenergymonitor/emonhub · GitHub](https://github.com/openenergymonitor/emonhub/blob/emon-pi/install.sh)  
This script is then called from a much shorter script in the original installer directory.

Getting there.

---

<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 April 2019 15:54 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/105 "2019-04-05T15:54:42Z")

</div>

> [@TrystanLea](#):
>
> I’ve moved much of the emonhub installation process to the emonhub repo itself

Great. I raised a specific question there.

> [@TrystanLea](#):
>
> emonhub installation process to the emonhub repo itself, replacing the existing install scripts that where emonpi specific.

At one point there were different emonhub versions for the emonpi and other setups. Has this all been merged into one now?

[edit] Found the question I asked a while ago

> [@Which version of emonhub to use](https://community.openenergymonitor.org/t/which-version-of-emonhub-to-use/8626):
>
> I currently have the following version of emonhub that has been in use for a long time, possibly I got it from Noah. Pre-Release Development Version (rc1.2) Doing some system reorganisation and I want to reinstall it on a new Pi Zero W. I know there have been some developments so I’d rather bring it up to date. However, the [GitHub repository](https://github.com/openenergymonitor/emonhub) simply talks about the ‘emon-pi’ variant so I am wondering what I should install? The RFM module is the old RFM12Pi V2.6 which again I know needs some s…

---

<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:** [6 April 2019 09:31 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/106 "2019-04-06T09:31:55Z")

</div>

> [@TrystanLea](#):
>
> Reading:  
> [Filesystem Hierarchy Standard](http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY)

FWIW, that’s an obsolete version of the spec - fifteen years old. The current version is [Filesystem Hierarchy Standard](http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html)

/opt/package-name for code and move data directories to /var/opt/package-name for data after installation are reasonable places for external products to be placed. If a distro packages a product and releases it, then it will typically put it under /usr with data under /var/lib  
So the package should make sure it uses relative, and configurable paths to enable such changes. Ditto for its dependencies on other packages, which may live in different places on different systems. That also allows for multiple versions if the version number is in the path somewhere.

---

<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:** [6 April 2019 10:28 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/107 "2019-04-06T10:28:00Z")

</div>

Thanks @djh that is useful to know, looks like we are on the right track then moving to /opt. I will also move the data directories to /var/opt/emon/phpfina etc (configurable of course) thanks for the tip on that. Any objections?

I still need to look the idea of supporting multiple emoncms installations on one machine as suggested by @pb66 as part of this.

---

<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:** [6 April 2019 10:42 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/108 "2019-04-06T10:42:41Z")

</div>

> [@TrystanLea](#):
>
> I still need to look the idea of supporting multiple emoncms installations on one machine

I suspect that will simply be a need to configure the initial path layout so it is extensible.

Perhaps just offer a commented out alternative structure for a multi install environment as it is an edge case.

---

<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:** [6 April 2019 10:47 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/109 "2019-04-06T10:47:58Z")

</div>

> [@borpin](#):
>
> I suspect that will simply be a need to configure the initial path layout so it is extensible

I think that may well be the case, should be straightforward.

---

<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:** [8 April 2019 15:48 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/110 "2019-04-08T15:48:30Z")

</div>

A little more progress on this.

- There is now a wifiAP install script, with the access point tested and working.
- Default paths changed and configurable to: /opt/emon and emoncms data: /var/opt/emon/phpfina…
- changes to emonPiLCD script that make it path flexible merged into master

I’ve run the build script again from the start on a fresh raspbian strech and it works well (a final sudo reboot is required at the end).

Im going to review the remaining steps in post 92 above next, but will need to come back to it after attending to a number of other things first.

---

<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:** [9 April 2019 07:50 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/111 "2019-04-09T07:50:05Z")

</div>

Noting your comment here @borpin for inclusion [Unexpected output from git describe - #11 by borpin](https://community.openenergymonitor.org/t/unexpected-output-from-git-describe/10613/11)

---

<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:** [15 April 2019 14:04 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/112 "2019-04-15T14:04:33Z")

</div>

Further progress on the install script:

- Merged multienv branch of backup module into master branch to support flexible install path, update install script to pull in master branch.  
[Multi environment support for backup module by TrystanLea · Pull Request #23 · emoncms/backup · GitHub](https://github.com/emoncms/backup/pull/23)
- Sync module support for flexible install path  
[- auto detect background process script path · emoncms/sync@c391cd2 · GitHub](https://github.com/emoncms/sync/commit/c391cd2c6e0661d23351046ebe269353eefef34b)
- Post process module support for flexible install path  
[flexible path support · emoncms/postprocess@f3f698a · GitHub](https://github.com/emoncms/postprocess/commit/f3f698a5d8498599d471ca8eb90ff16ac9fb8976)
- Clean up of wifi.sudoers  
[cleanup wifi sudoers · openenergymonitor/emonpi@4345ccd · GitHub](https://github.com/openenergymonitor/emonpi/commit/4345ccd0aeb18fadd55486c800c6ac9979e5e980)
- Removal of setup sudoers  
[remove setup sudoers, cleanup install & update · openenergymonitor/emonpi@fc0ce0b · GitHub](https://github.com/openenergymonitor/emonpi/commit/fc0ce0bb9770c3c426d6297c67d8275a624bc8cb)
- Support for setting emoncms modules branch in config.ini:  
[support for setting repo branch in config.ini · openenergymonitor/emonpi@a654a18 · GitHub](https://github.com/openenergymonitor/emonpi/commit/a654a18f8ffc9fc47edc7e644522a5a3272cab2a)

I have made a start on documenting the install scripts here:  
[https://github.com/openenergymonitor/emonpi/blob/master/install/readme.md](https://github.com/openenergymonitor/emonpi/blob/master/install/readme.md)

Noted at the top are the items left to complete, which I have separated into releases. I hope to complete the first release this week.

**Todo 1st release**

- ext2 data partition, mount /var/opt/emon as ext2?
- review log2ram configuration, noting [https://community.openenergymonitor.org/t/emonsd-next-steps/10426/29](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/29)

**Todo 2nd release**

- fix flexible emoncms\_core install location (currently /var/www/emoncms symlinked to /var/www/html)
- review emoncms logfile location
- review /var/www/html/emoncms symlink

---

<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:** [16 April 2019 09:26 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/113 "2019-04-16T09:26:28Z")

</div>

6 posts were split to a new topic: [emonSD next steps: filesystem](https://community.openenergymonitor.org/t/emonsd-next-steps-filesystem/10693)

---

<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:** [19 April 2019 19:40 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/114 "2019-04-19T19:40:52Z")

</div>

😧 It’s annoying that after you split the topic, I no longer get notification emails to tell me there’s been any activity. Short of changing discourse to also split the notifications, can I suggest that as a courtesy whenever anybody splits a topic, they post a message to the original topic stating that that is what they have done? 😁

---

<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:** [25 April 2019 20:53 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/115 "2019-04-25T20:53:49Z")

</div>

> [@TrystanLea](#):
>
> The installation on a stock raspbian stretch image can be started with:

> [@emonSD next steps: filesystem & logrotate](https://community.openenergymonitor.org/t/emonsd-next-steps-filesystem-logrotate/10693/146):
>
> My draft readme for the install process is available in the folder here:

I’m not sure if you are using the latest Raspbian Lite image, but the readme for expanding the file system does not seem to match this image after first boot. I suspect the file system has already been expanded.

```auto
Disk /dev/mmcblk0: 14.5 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8b1df36f

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 96042 87851 42.9M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 30375935 30277632 14.4G 83 Linux

```

Trying to run the install and I fell at the first hurdle.

[edit] decided to run it anyway. Ran fine until here where it wanted some input.

> <https://github.com/openenergymonitor/emonpi/blob/cf7cac6bff569d7aa96ac57c1722824d37c1df6c/install/emonsd.sh#L13-L13>

```auto
rm: remove write-protected regular file 'log2ram/.git/objects/pack/pack-e60fc815bb6beda9136261e26e2b90e3e9bc867e.pack'?

```

Other than that seems to work 😄. Did an export/import - all OK.

---

<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:** [25 April 2019 21:09 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/116 "2019-04-25T21:09:48Z")

</div>

@TrystanLea, one other point as part of the install, I think this needs a 'default.config.ini` file that can be copied and changed for use but ignored by git.

At the very least a warning to the user that it is using the default config ‘do you want to continue’ type question.

---

<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:** [25 April 2019 22:16 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/117 "2019-04-25T22:16:24Z")

</div>

> [@borpin](#):
>
> I suspect the file system has already been expanded.

Raspbian images now resize automatically, If you look at a virgin cmdline.txt there is a entry like `init=/some/path/init_resize.sh`, if you delete that before putting into a Pi, it will not resize. I think it completes the full resize on the second reboot, but if you add a 3rd partition before that it might interfere with that process. I would need to look closer at it to be sure, I’m working from memory here. You won’t find the init= in cmdline.txt after it has resized though, it gets removed by raspi-config.

---

<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:** [26 April 2019 07:35 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/118 "2019-04-26T07:35:25Z")

</div>

> [@pb66](#):
>
> Raspbian images now resize automatically

For the install script I think we should work on the basis it has been resized so need to shrink first. Goes back to where we started - do we actually **need** to do so?

---

<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:** [26 April 2019 08:12 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/119 "2019-04-26T08:12:17Z")

</div>

> [@borpin](#):
>
> For the install script I think we should work on the basis it has been resized so need to shrink first.

I understand what you are saying and don’t disagree entirely. But you cannot make any assumptions and start moving partitions around unless you know the resize has run it course or you take control and block, complete or abort that resize.

I don’t know what error Trystan actually saw when he wrote [the steps to create 3rd partition](https://github.com/openenergymonitor/emonpi/tree/master/install#setup-ext2-data-partition)

```auto
sudo fdisk -l
Note end of last partition (5785599 on standard sd card)
sudo fdisk /dev/mmcblk0
enter: n->p->3
enter: 5785600
enter: default or 7626751
enter: w (write partition to disk)
fails with error, will write at reboot
sudo reboot

```

but it’s possible that error might have been caused by unsaved changes to the partition table or saved changes not applied by partprobe (or reboot).

It could be a game of chance or bit of wrestle between the install script and the default init\_resize.sh script to dictate the partitions unless the 2 are choreographed to play nicely together.

---

<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:** [26 April 2019 08:16 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/120 "2019-04-26T08:16:20Z")

</div>

> [@pb66](#):
>
> I understand what you are saying and don’t disagree entirely. But you cannot make any assumptions and start moving partitions around unless you know the resize has run it course or you take control and block, complete or abort that resize.

Absolutely.

> [@pb66](#):
>
> I don’t know what error Trystan actually saw when he wrote

And not sure what Raspbian version (new one recently).

Could you check if `init_resize.sh` has been deleted to see if it is complete?

Before we put too much effort into this has the the fundamental question been answered; do we **need** a data partition?

[Previous page](https://community.openenergymonitor.org/t/emonsd-next-steps/10426.md?page=5)

[Next page](https://community.openenergymonitor.org/t/emonsd-next-steps/10426.md?page=7)
