In creating plugins, I had introduced some bugs into eisy that not only caused problems in the plugin itself, but caused eisy ui backup to fail. I would think that a backup system should be immune to bugs in a plugin. The plugin bugs prevented the entire eisy backup from succeeding with an error 500.

There were two node-server file-permission issues that caused the native eisy-ui system backup endpoint ( /api./system/backup/create) to return HTTP 500.

1. SmartLife/Tuya: The plugin's web_auth.txt file lacked the FreeBSD ACL permissions needed by the eisyui service account. Repairing the ACL resolved the problem. Subsequently added automatic ACL repair during plugin startup.

2. eisy Backup: The plugin's persist/backup_hisotry.json file could be updated or atomically replaced without preserving the required ACL. This caused an EACCES error during native backup. Corrected the file-permission handling in version 1.1.1. This bug only showed up in 1.4.9, not 1.4.8

Both problems demonstrate that files created or replaced by node servers can interfere with system backups if the eisy-ui backup process lacks sufficient filesystem access.

It may be useful for the native backup process to identify the offending file and return a more descriptive error instead of a generic HTTP 500. It may also be worth reviewing whether the backup process should require access to every file in a plugin's persistent directory.

@apostolakisl

Thank you very much for the feedback. The #2 backup issue is not related to the bugs in the plugins. The backup issue is related to file permissions.

For #1, I need to understand more. What do you mean by ACL permissions. Do you mean regular owner:group mode permissions? Where is this web_auth.txt located?

With kind regards,
Michel

The permissions issue involved FreeBSD NFSv4 ACLs, not simply the traditional Unix owner/group/mode permissions.

The web_auth.txt file is located at:

/var/eisyui/ns/plugin_<your slot number here>/data/web_auth.txt EDIT: just to be clear talking about eisy_Baciup plugin

The file contains the plugin's web interface authentication credentials and is intentionally created with restrictive permissions (600) to prevent unauthorized access.

However, the eisyui service runs under a different user account and could not read the file during a native system backup.

It appears when a backup tries to access a restricted file, included in a plugin, it crashes the entire backup. Instead I would propose that the backup has fault tolerance. .. moves on excluding whatever it couldn't get access to and then logs an error that is as detailed as possible. The backup would presumably be restorable minus the restricted files.

Edited Monday at 08:26 PM2 days by apostolakisl

HI Lou,

Thanks for the details. We're working on the backup fix. Regarding running your webserver inside the plugin, we are trying to figure out the best way to give you that functionality while preventing webservers running inside a plugin (huge security risk).

With kind regards,
Michel

14 hours ago, Michel Kohanim said:

HI Lou,

Thanks for the details. We're working on the backup fix. Regarding running your webserver inside the plugin, we are trying to figure out the best way to give you that functionality while preventing webservers running inside a plugin (huge security risk).

With kind regards,
Michel

At present I can just pick any unused port and run a webserver which you deam a security risk and I don't doubt it.

Perhaps you have a developer request form where developers request for a port to be opened. At present there is nothing stopping duplicate use of ports, so if someone else made an html page and by dumb luck picked a port some other plugin is already using there would be issues. The part that might hang you up is limiting use of that port to the specific plugin?

Having port access in a plugin to run an interactive page is something that really takes plugin functionality and user experience up dramatically. I suspect I have just begun to touch its potential. Configuration of some plugins on eisy config page can really be intimidating. I suppose someone could make a helper app or html server separate from eisy that spits out a json file for upload to eisy config, but for something like ioxlogger nothing works but actually having a webserver on eisy. And if it is a config helper webserver hosted not on eisy and people put credentials in for whatever random thing, that is a different security issue. Plus it is just one more thing to confuse people or have issues.

Am not sure if this is related or not, but I created my first plugin using Eisy-AI last night. See post https://forum.universal-devices.com/topic/47495-first-experience-with-eisy-ai-success/

Ever since then, I also cannot get the backups to work unless I restart the UI Service.

Error--> Request failed with status code 500

@dbwarner5 ,

It's already fixed and will be in the next release of eisy-ui.

With kind regards,
Michel

1 hour ago, dbwarner5 said:

Am not sure if this is related or not, but I created my first plugin using Eisy-AI last night. See post https://forum.universal-devices.com/topic/47495-first-experience-with-eisy-ai-success/

Ever since then, I also cannot get the backups to work unless I restart the UI Service.

Error--> Request failed with status code 500

I would say very nearly 100% chance.

47 minutes ago, Michel Kohanim said:

@dbwarner5 ,

It's already fixed and will be in the next release of eisy-ui.

With kind regards,
Michel

Good deal. Does this mean a permissions issue in a plugin gets ignored and everything else backs up, but the particular plugin does not get backed up? And if so, do you still get an error to know you need to fix something?

3 minutes ago, apostolakisl said:

I would say very nearly 100% chance.

Good deal. Does this mean a permissions issue in a plugin gets ignored and everything else backs up, but the particular plugin does not get backed up? And if so, do you still get an error to know you need to fix something?

The plug in that I created is local, so my understanding is that it does NOT get backed up. This required a laborious method of downloading to GitHub repository so I would have a copy if needed.

@Michel Kohanim Will this be changed in the future? Seems like the backup process should grab EVERYTHING.

Thanks

1 hour ago, dbwarner5 said:

The plug in that I created is local, so my understanding is that it does NOT get backed up. This required a laborious method of downloading to GitHub repository so I would have a copy if needed.

@Michel Kohanim Will this be changed in the future? Seems like the backup process should grab EVERYTHING.

Thanks

Yes, local plugins aren't part of a backup so I would assume that it would not mess up a backup. I have seen the 500 error twice and both times it was my fault because of something in my plugin. But the first I only discovered from a user of my plugin since I had it installed local on my system. I have switched now to developing my plugins via store installs. I start the plugin locally, push it to github and then post it to the store as "new" so it is not visible to the general public, then I push all my changes to github and do "reinstalls" as I work through the development.

Just a clarification here.

The Local plugin folder is indeed not backed up.

However, the eisy-ui database is backup, which includes the plugin configuration, customparams, nsdata... basically all the data that the plugin sends to PG3/eisy-ui.

But the code or data files are not saved.

The code is not backed up as this would make the backup much bigger. The code should be stored in a github repository.

What could be backed up, but is not today, are the data files. Production plugins backup includes these folders: data, persist, config and sounds.

We could argue that for local plugins, those folders should be backed up as well, which is a very valid point. But the challenge is this: file permissions. If the plugin is in let's say /home/admin/dev/my-plugin, the owner would typically be admin, with the group admin. To back this up, it needs public r. And to be able to restore as well, it needs public rw.

So in most cases, by default, it will fail.

So ideally, local plugins should not store anything on the file system. If it has to store something, it should use nsdata, and that will be backed up.

To keep my life simpler and have my system backups be full drop in backups, I am installing all of my plugins from the store, even ones that are just for me. Initially I get something going as a local plugin, then I push it to github and put it in the store with status "new". "New" is not exactly the best word to describe what is really a development plugin, one that is only accessible to the developer. So while it is in the store and when installed on Eisy looks like any other store plugin, it doesn't appear in the public store. The installation of these is done from the developer section purchase options configuration page. Also, when I'm testing a plugin, it is nice to have it installed in folders with the same permissions that the public will end up with. I have had permission issues before where the plugin worked as a local plugin, but had permission problems when installed from the store.