# Emoncms and emonhub on Debian VM or Container

**URL:** <https://community.openenergymonitor.org/t/emoncms-and-emonhub-on-debian-vm-or-container/24222>\
**Category:** Emoncms\
**Tags:** emonhub\
**Created:** [22 August 2023 13:36 UTC](https://community.openenergymonitor.org/t/emoncms-and-emonhub-on-debian-vm-or-container/24222 "2023-08-22T13:36:23Z")\
**Posts on this page:** 1\
**Page:** 2

<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:** [24 August 2023 12:06 UTC](https://community.openenergymonitor.org/t/emoncms-and-emonhub-on-debian-vm-or-container/24222/21 "2023-08-24T12:06:48Z")

</div>

> [@fruit-offbeat-dastar](#):
>
> To my mind if the native tools (eg systemctl edit) don’t work to change configurable settings (eg system-specific variables) then it is broken?

At one time we scripted using `systemctl edit` but creating a dropin, symlinked, means an update to the dropin in GitHub is picked up automatically on a `git pull` and restarting the service.

> [@fruit-offbeat-dastar](#):
>
> The idea is that if you ever modify the unit file in a future update any changes I’ve made aren’t nuked

Yes. but you suggested the way the scripts did it was wrong, and it isn’t, as it is the lowest level of priority. So when we change this and add in the dropin it will not affect your install.

So what you did as the administrator is correct, what the script does is also correct.

> [@fruit-offbeat-dastar](#):
>
> I don’t need it but I didn’t see disabling it from installing in the config.ini but admittedly I didn’t look too hard!

Just disable that Repo from the list

> [@fruit-offbeat-dastar](#):
>
> Is there a sensible way to remove it from an installation?

Not really.

[Previous page](https://community.openenergymonitor.org/t/emoncms-and-emonhub-on-debian-vm-or-container/24222.md?page=1)