awesome. Thanks for starting flohmarkt and this Yuno package
I’ve probably found a bug. When I enter a wrong password with an existing user, there is no message telling me that it’s wrong. It just doesn’t login. With username that is not in the user database, I do get a proper error message. But that should also do with an existing user.
One more: When I try to login with a fediverse account, the format of the log-in e-mail address needs to be perfect, otherwise no login is possible. There’s no message or anything after a failed login attempt, that would indicate that something is wrong and what it may be. I did copy my username but it also copied trailing whitespaces and it took me some time to figure out why I can’t login.
It would be nice if whitespaces (at the beginning or trailing) would be automatically removed or not considered during log-in.
On the way trying to replace calls directly to curl by ynh_local_curl made me look at that code and ynh_handle_getopts. I extended the first one to deliver features needed to use it to handle couchdb and nearly re-wrote the second one to make it possible to get the command line options I wanted.
The code is included in _common.sh which leads to some linter warnings and available as PRs for testing and discussion:
There are still features that could be improved and probably some rough edges, but I’d say we’re getting close to a nice integration.
The newer version will soon be available on the app store. Feedback like always is very welcome!
Just installed the ynh8 yunohost app integration on my flohmarkt.
I added an hourly check of the user database of flohmarkt to send out an email notification for changes.
To enable admins through the web gui to change the address I added a configuration panel and while at it I put the setup URL for the initial setup of a new flohmarkt installation on the configuration panel, too.
Now it should be easy to install and initialize a flohmarkt instance by only using yunohosts web gui.
I just went over the logs briefly to look at a possible change of architecture, but there is no hint it could be that. Did your architecture change (e.g. arm64 vs amd64)?
It looks like couchdb can’t be access in your attempt to re-install:
```
2026-02-13 00:52:47,506: DEBUG - + timeout 45 python3 initialize_couchdb.py **********
2026-02-13 00:52:48,468: DEBUG - Using config in: ./flohmarkt.conf
2026-02-13 00:52:48,469: DEBUG - Attempting to connect to DB at: http://127.0.0.1:5984
2026-02-13 00:52:48,469: DEBUG - Trying to create user DB
2026-02-13 00:52:48,469: DEBUG - HTTP Error 401: Unauthorized
```
I’d clean up couchdb (all data will be lost, be sure to have backups of any db that might be stored in couchdb) `/var/lib/couchdb/*` and then attempt a new install.
Quoting from memory:
couchdb stores the password inside its database located in that directory. On uninstall the directory might not get emptied/purged (to protect against unexpected database loss).
On a new install the database is neither deleted and the old password applies.
So it might be worth a try to remove flohmarkt, then remove that directory (or move its content elsewhere - look for hidden files `ls /var/lib/couchdb/.*`) and then try a re-install.
I’m very short on time atm and it would be a great help for me if you could open this as an issue on codeberg containing a detailed description of what you did to get into this state. You could look at your `history` to remember which steps you took.
I remember I already put some time and thought into handling the situation where database leftovers lead to errors during later installs or backup recoveries.
Hi, thanks for your quick and elaborate reply, especially as you are short on time!
There is no change of architecture involved: from one VPS (Xeon based virtualization) to another VPS (Ryzen based)
Migration steps, in short:
old VPS:
full YNH backup
new VPS:
new Debian 12 installation
install YNH on top, no postinstall
scp backup_old.tar and backup_old.info.json from old VPS to new VPS
new VPS:
yunohost backup restore backup_old
With the old server still available, I made a new backup of flohmarkt on old, restored on new’, and compared /var/www/flomarkt* on both of them. Observations:
Old VPS:
/var/www/flohmarkt_sub.domain.tld is a symlink → var/www/flohmarkt, owned by root
/var/www/flohmarkt/ is the actual app directory, owned by flohmarkt
New VPS:
/var/www/flohmarkt_sub.domain.tld is a symlink → var/www/flohmarkt, owned by root
/var/www/flohmarkt/ is the actual app directory, owned by …. a non existing user!
That explains ‘permission denied’. Thinking about it, it is not very surprising that system user id’s drift after several (re)install cycles, but it would not explain the same problem in the first place (initial full restore).
My next steps:
Investigate whether I can recreate user ‘flohmarkt’ with the correct (old) user id
Besides recreating the user, I also need to check whether the restore process created coucddb and other services under the old, or under the nwe ID
Or chownthe incorrectly owned files to the new flohmarkt user
Maybe time consuming, because some things are owned by root, others by flohmarkt, so it’s not a simple chown -R
Good you found the reason and thanks for publishing the solution here.
Yes, I’d say so. I’d think that the scripts for restore need to be extended to set the correct ownership for the files.
I can’t say whether it is a fault in using the functions for backup/restore offered by yunohost or if it is generally expected from restore scripts to do this.
Opening an issue would be good to make me remember to improve this the next time I’ll be changing the package (a merge request is also welcome).