Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DietPi-Software | homeassistant: Add a soft link for config folder at install #1308

Closed
borpin opened this issue Dec 16, 2017 · 6 comments
Closed

Comments

@borpin
Copy link

borpin commented Dec 16, 2017

Feature Request

Background

Same as issue #1256
Homeassistant users expect to find their configurations etc in a folder ~/.homeassistant. DietPi uses the folder /mnt/dietpi_userdata/homeassistant.

Solution

Add a soft link at install time from ~/.homeassistant to /mnt/dietpi_userdata/homeassistant

@MichaIng
Copy link
Owner

MichaIng commented Sep 3, 2018

@borpin
Ui, this topic has been forgotten it seems, sorry for that 😅.

Very easy to implement, otherwise depending on if the user logs into the system via "root" or "dietpi" or an own created user name, ~/.homeassistant is a different location, whereas dietpi-software would always take it as /root/.homeassistant.

We install and configure homeassistant system wide and not per-user. A config location inside the user home directory could be interpreted wrong and users might wonder why changes with one user affect the others as well.

So finally, if we aim to keep a system wide configuration, I would leave it at /mnt/dietpi_userdata/homeassistant only.
But we should at least add info about that to: https://dietpi.com/phpbb/viewtopic.php?p=10416#p10416


The issue would be the same for ~/.nzbdrone and some other software titles, where we lately moved systemd working dir, which is then often used as config dir (instead of user home/.title).
Whatever we do, we should do it consistent for all software titles.

@Fourdee
What do you think?

@borpin
Copy link
Author

borpin commented Sep 4, 2018

This is really old - was it before V6?

I think it is likely that the user would use HA from the same user account as they installed it from (unless unattended). Adding it to that users home folder would help new users.

Perhaps an item in the install instructions would be sufficient.

@MichaIng
Copy link
Owner

MichaIng commented Sep 4, 2018

@borpin
Jep, it's pre v6.0.

I think it is likely that the user would use HA from the same user account as they installed it from (unless unattended). Adding it to that users home folder would help new users.

The issue is that dietpi-software either needs to be executed as root or via sudo, thus it always uses the root user home directory, if not adjusted.
So if end users use the dietpi user or an own to login the system, install HA via sudo dietpi-software which places a symlink to ~/.homeassistant, after the install finished, users will not find ~/.homeassistant, just /root/.homeassistant (without having non-sudo access). We would either need to find a way to check the initial login user, and I don't know if this is even possible within a sudo execution, or we need to place symlinks in all users home directories, which brings the above mentioned wrong illusion, that we have a per-user install.

Perhaps an item in the install instructions would be sufficient.

At least this is easy and uncritical. About other solutions we have to think carefully first and find a way that works well for all applications that usually use the users home dir.


What I just found:

  • Config folder within the install steps is placed to /home/homeassistant/.homeassistant, thus the run users home dir. From there it is symlinked to /mnt/dietpi_userdata/homeassistant:
local ha_user="homeassistant"
local ha_userroot="/home/$ha_user"
...
echo "hass -c \"$ha_userroot/.homeassistant\"" >> $ha_srvroot/homeassistant-start.sh
...
ln -sf $G_FP_DIETPI_USERDATA/homeassistant /home/homeassistant/.homeassistant

Just added a hint to the forum page: https://dietpi.com/phpbb/viewtopic.php?p=10416#p10416

@borpin
Copy link
Author

borpin commented Sep 4, 2018

By configuring HA to use /mnt/dietpi_userdata/homeassistant as the configuration dir, is there a risk if 2 users use HA on the same device that they will both point to the same config files? Would they both have the same permissions?

Should /mnt/dietpi_userdata/homeassistant actaully be /mnt/dietpi_userdata/<user>/homeassistant?

Again, if this is a specific design/setup decision (not saying it is the wrong decision), that should be explained to a user in the notes. Ultimately, could you offer the choice between per user or global setup?

Do the same sort of issues appear with node-red (not tried it recently)?

@MichaIng
Copy link
Owner

MichaIng commented Sep 4, 2018

@borpin
Indeed from the ground up DietPi was designed as a single user (let's say single login) system. We just recently adjusted some installs to place data and config folders inside /mnt/dietpi_userdata/, on the one hand because this can be easily placed onto external drives (to reduce SDcard I/O and/or speed up file transfer), on the other hand because it makes it easier to backup and restore the system with application data.

But this does not include all software titles or packages. E.g. htop places a config dir/file into the users home dir right on execution and many other packages/software title will do it similar. Only for software that is either started via systemd unit/init.d service or allows to change config/data dir via command argument/settings file, this is possible.
Need to check if/how we handle it with node-red.

By configuring HA to use /mnt/dietpi_userdata/homeassistant as the configuration dir, is there a risk if 2 users use HA on the same device that they will both point to the same config files? Would they both have the same permissions?

Installing Homeassistant via dietpi-software places a single systemd unit with a separate run user to start it on boot. Thus there is just one instance for all users and nothing else makes sense. The instance runs as it's own separate unix user homeassistant with it's own config dir, symlinked to dietpi_userdata. Other unix users need to be in dietpi group to have direct access to this config folder.
But just to clarify: This does not necessarily has to do something with the users that can login the homeassistant application UI. Sorry as I never used it, I would need to check the UI etc. how this is handled, but different end users can use the same homeassistant instance that runs under a separate unix user. Per-HAuser configuration should be stored all within the same config folder/file. But again, I need to check.

@Fourdee
Copy link
Collaborator

Fourdee commented Sep 9, 2018

@borpin

@MichaIng Has pretty much covered the original questions, however, i'll add a little to this aswell, try to clarify.

By configuring HA to use /mnt/dietpi_userdata/homeassistant as the configuration dir, is there a risk if 2 users use HA on the same device that they will both point to the same config files? Would they both have the same permissions?

The config file is a single item required by the program, regardless of the amount of users on HA. To prevent additional users from making changes to the HA config files, it would require HA to implement a user login system. Its not something we can do our end, as running multiple HA servers, via multiple unique install directories, is not a solution.

Again, if this is a specific design/setup decision (not saying it is the wrong decision), that should be explained to a user in the notes. Ultimately, could you offer the choice between per user or global setup?

DietPi follows the standard rules of process execution, in that:

  • A service is created to run the application
  • That service has a user and group run level (which are under privileged)
  • Past this point, the program itself would need to implement its own user account system. EG: I believe NextCloud allows for adding additional users, with unique permissions.

Another example is a forum (PHPBB3), which allows for permission control, via user and group accounts, in the software title itself.

I hope this answers your questions, I'll mark this as closed, however, please reopen if required.

@Fourdee Fourdee closed this as completed Sep 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants