Creating a bug report/issue
Required Information
- DietPi version | 8.19RC1
- Distro version | bullseye 1
- Kernel version | Linux DietPi 6.1.21+ #1642 Mon Apr 3 17:19:14 BST 2023 armv6l GNU/Linux
- Architecture | armhf
- SBC model | RPi Zero W (armv6l)
- Power supply used | 5V 1A
- SD card used | UHS 3 256GB SD Card
Additional Information (if applicable)
- Software title | Ampache
- Freshly installed
- This issue be replicated on a fresh installation of DietPi.
Steps to reproduce
- On DietPi:
- Start a fresh install of DietPi on RPi Zero W.
- ssh into root
- complete setup without installing anything (basically leaving everything at default and not installing any software) and ssh out
- ssh into dietpi
- perform sudo dietpi-software to install Ampache with lighthttpd.
- On any other computer with browser on LAN:
Expected behaviour
Should be greated with Ampache setup or Login page
Actual behaviour
Webpage shows the following:
Ampache Update
This page handles all database updates to Ampache starting with 3.3.3.5. Your current version is 5.6.2-release with database version 5.0.0 Build: 003
The following updates need to be performed:
Extra details
I tried performing config changes according to this post (Ampache Changes) from a year ago because the behaviour is similar but the problem still persists.
I assume that this bug is because of the prebuilt Ampache database that is imported to the machine when performing dietpi-software install
. The database is available here (https://dietpi.com/downloads/mysql_databases/ampache_mysql_3.8.2-v6.0.zip).
The ampache database scheme has had several changes in schema ever since 3.8.2-v6.0. I wonder if those are to blame for breaking the software?
Normally this is expected and it should be possible to update the database by clicking on the āUpdateā button at the bottom of the update page. But it looks like this does not work when we use our database dump actually.
Incidentally, Ampache itself does not provide a more up-to-date database dump either. However, it seems that using Ampacheās own dump allows the update:
cd /tmp
mysql -e "DROP DATABASE ampache;"
curl -sSfL https://raw.githubusercontent.com/ampache/ampache-debian/master/sql/ampache.sql -o ampache.sql
/boot/dietpi/func/create_mysql_db ampache ampache <your_db_password>
mysql ampache < ampache.sql
rm ampache.sql
You would need to replace <your_db_password>
with the password configured within ampache.cfg.php
. Can be checked as follow
cat /mnt/dietpi_userdata/ampache/config/ampache.cfg.php | grep database_password
Now, you should be able to open Ampache page again and perform the database update
Can confirm this method works!
Additionally, it would be awesome if this method made itās way to dietpi-softwareās script so that it doesnāt rely upon a outdated database dump.
I am testing dietpi-software with the database url string changed but it currently seems inadequate.
Also, the dietpi software docs stating that the username and passowrd to be ārootā and ādietpiā is no longer true this way.
Neither does any user named ārootā or ā dietpiā exists.
However, using this link http://XXX.XXX.XXX.XXX/ampache/install.php?action=show_create_account&htmllang=en_US&charset= will work to create a new admin account!
Yes, this is a small disadvantage because the workaround uses an empty database from Ampache. Therefore our user could not exist at all
Need to talk to @MichaIng how we are going to work around.
So we need to update our database dump. Since on Buster Ampache v4.4.3 is installed, we probably need to provide two dumps, if the v4 dump cannot be upgraded to v5 either.
Itās nasty there there is not API to do the database changes. Doing it manually wouldnāt be maintainable due to the regular changes.
@MichaIng
Probably a better option, we use the default Ampache SQL dump located at /mnt/dietpi_userdata/ampache/resources/sql/ampache.sql
as base to build the databse initally. This way no DB update is needed at all
Once done, user can open following link to create initial admin user.
Benefit, every user can create own user/password and we donāt use a default anymore. Furthermore, we donāt need to deal with maintaining the DB dump anymore.
1 Like
Probably you are right. The only other thing we might want to adjust is the music directory, but this can be done safely via sed
on the SQL file, I guess.
@MichaIng Iām not sure but I guess we never finished this discussion? right?