Help

Ended up having to manually upload the pialert.conf and pialert.db with the name changed to app.conf and app.db to the folder when the app was starting. If i added it with the docker on exited/paused, it auto-reseted on the previous app.db. Well, i think it's all right now, but it shouldn't be like this, feels dirty

I am getting the same exact issue after changing the folders as described and launching netalert i noticed that I had no devices listed and all the settings disappeared, @catalans1980 would it be possible to let me know how you managed to get it to work exactly? I am abit new to this so I appreciate your patience 😁, thanks.

I'm seeing the same issue and would appreciate instructions on how to fix it.

ok, so what i did was i renamed all pialert files in config and db to app and that worked.

The mount points should be renamed/moved only after the new image is launched. What happens is:

1. The app starts
2. Check if there is a /home/pi/ folder with old files
3. If yes, moves them in the new location + renames the files

If you change the mount points beforehand the app can't find your old files. That's what I assume is happening. I will explicitly say in the migration guide to only do that after the app was first launched. Hope this will prevent these issues.

Docs updated: https://github.com/jokob-sk/NetAlertX/blob/main/docs/MIGRATION.md

I hope this prevents future issues,
j

The Unraid container seems to have things mapped to the old locations and doesn't seem to copy anything to new file names/locations/etc. What's the intent for migrating there (and getting the message at the top saying "Follow these directions to migrate", which suggest changing the container paths in the config but doing that just gets you a clean/wiped setup.

I made the above guide even more explicit, please let me know how to adjust the guide further to clarify any misunderstandings:

https://github.com/jokob-sk/NetAlertX/blob/main/docs/MIGRATION.md

What you added seems to conflict with this:
In short: The application will auto-migrate the database, config, and all device information. A ticker message on top will be displayed until you update your docker mount points. Even so, it's always good to have a backup strategy in place.

That says it will rename the files automatically, but the new instructions say to do it manually. Either way is fine, just make it explicit that you have to do XYZ or people will get confused.

Also, is there any reason not to just rename the files and use the new docker/paths? Is something getting changed in the files themselves (paths in the DB or something) or is it just naming/location that changed? Basically, it's not clear why you need to run the docker once before migrating.

Also, ONLY the pialert.db and pi-alert.conf need to be renamed, right? There are other files in the directories (device lists in csv and backups, etc.) - nothing critical there?

Ok. That worked - manually renaming the two files and changing the mapped folders.

Not sure if something needs it to be run using the old mapping first, but it definitely makes it more confusing (on Unraid at least).

Glad to hear that the updated guide makes things clearer. And yes, the db and config are the only files that are needed to bring everything over.

Unfortunately I don't run unraid and I will always have to rely on the community to provide feedback for their specific setups. So this feedback is really great to improve things for everyone.

Thanks for the patience and help,
J

This worked for me momentarily, after renaming the app.conf and app.db and placing them in their respective folders in the host path, I restarted the site, and did not see the ticker telling me that the config and db are in the old paths so I assumed it is ok however if I do a docker compose down and docker compose up the site does not even load now :( I get 09:10:32 [Database] - Open DB Error: database disk image is malformed
do i have to paste the app.conf and app.db in the container path too?
Can anyone help me out please?
Thanks.

The mount points should be renamed/moved only after the new image is launched. What happens is:

1. The app starts
2. Check if there is a /home/pi/ folder with old files
3. If yes, moves them in the new location + renames the files

If you change the mount points beforehand the app can't find your old files. That's what I assume is happening. I will explicitly say in the migration guide to only do that after the app was first launched. Hope this will prevent these issues.

Docs updated: https://github.com/jokob-sk/NetAlertX/blob/main/docs/MIGRATION.md

I hope this prevents future issues, j

I don't think this happens, or not exactly how you have detailed it. I had my pi folders (db, logs, config) mapped to the old image volumes, and i remapped to the new:

• /volume2/docker/pialert/config:/app/config:rw
  • /volume2/docker/pialert/db:/app/db:rw
  • /volume2/docker/pialert/logs:/app/front/log:rw

I didn't have any /home/pi, just pialert/db, pialert/config, pialert/logs. Ended up with the pialert.db in the same folder than app.db, pialert.config in the same folder than app.config. And if i started the container after replacing the app.db with the previous pialert.db (with its name changed), it overwrote with the previous and new app.db. Same with config. Ended up overwritting while the app was starting, and seems to work fine.

I copied the app.conf and app.db files once again and put the image down and up again using docker compose. I dont know if it was the copy and paste or putting the site down and up again, but this seemed to solve my issue. Site is back up and running using the new paths.
It certainly was not straightforward for me but at least I did not lose my devices and settings.
Thanks.

Thanks for all the input.

1. The app starts
   

2. Check if there is a /home/pi/ folder with old files
   

3. If yes, moves them in the new location + renames the files
   

The code responsible for creating symlinks is the one below:

# 🔻 FOR BACKWARD COMPATIBILITY - REMOVE AFTER 12/12/2024

# Check if pialert.db exists, then create a symbolic link to app.db
if [ -f "${INSTALL_DIR_OLD}/db/${OLD_APP_NAME}.db" ]; then
    ln -s "${INSTALL_DIR_OLD}/db/${OLD_APP_NAME}.db" "${FULL_FILEDB_PATH}"
fi

# Check if ${OLD_APP_NAME}.conf exists, then create a symbolic link to app.conf
if [ -f "${INSTALL_DIR_OLD}/config/${OLD_APP_NAME}.conf" ]; then
    ln -s "${INSTALL_DIR_OLD}/config/${OLD_APP_NAME}.conf" "${INSTALL_DIR}/config/${CONF_FILE}"
fi
# 🔺 FOR BACKWARD COMPATIBILITY - REMOVE AFTER 12/12/2024

so yes, the last point is not correct:

If yes, moves them in the new location + renames the files

it should say:

3. If yes, creates the symlinks to files the new /app/ folders

So...given it's a container...why does it matter where on host it's linked?

Theoretically, if the person maps in their pialert directories, NetAlertX should just detect the files are there (and named pialert.conf vs. app.conf, etc.), rename/convert them, and done. No need for further modification.

Again, I may be missing something though.

(And appreciate you're openness to feedback - realize tone/intent is sometimes lost in text back and forth, all is coming from a desire to help! :))

I'll try to explain my thinking.

Where the files on the host are linked doesn't matter, agree. What matters are mappings inside of the container. Sooner or later I will retire the mapping code and the old images. This migration is to get users to start using the new setup, container, and locations. So although a bit painful in the short term, it should make maintenance and development easier in the long term. The migration itself is automatic if you don't mind the ticker, if you do then you are prepared to spend some time to migrate to the new locations.

As I understand I can't just rename files on the host if someone maps files directly, instead of the whole folders.

As on feedback.

And yes, sometimes it's hard, but I'm trying to take the feedback positively (especially when looking at some of the unedited/deleted email notifications I am getting, it can be a challenge to keep my cool - BTW - posted on reddit on this topic before :) )

Anyway, open to feedback and especially help if someone wants to contribute - there are a lot of things always to improve 😅:

#532 #624

I think the migration process makes sense - just wasn't sure about what was intended to happen automatically vs. manual so that's the key difference. And good point re: the mapping files directly - that itself seems like a bad idea (as you note) but...guess some people would still do it!

And it's always good to assume the best - least, I try to. (And I think one of the unedited deleted was prob. one of mine - re-read it after submitting and realized "Huh, this doesn't read the way I want to to and I sound like a jerk.").

Thank you for the feedback @necromancyr - glad it makes sense now.

Appreciate the honesty and message. Looking forward to collaboration on this project if you decide to feedback or even help out 😉

released/workaround provided -> closing for now