Panel: Panel php artisan migrate --seed fails using remote database

Created on 21 Apr 2020 · 11Comments · Source: pterodactyl/panel

Background (please complete the following information):

Panel or Daemon: Panel
Version of Panel/Daemon: v1.0.0 Beta 1
Server's OS: Ubuntu 18.04.4
Your Computer's OS & Browser: Windows 10, Firefox 75.0

Describe the bug
When attempting to run the php artisan migrate --seed command after configuring a remote database, it fails partway through. It appears that in the migration it is hard coded to expect the username [email protected] instead of reading the value stored in the .env file. Log output of the failure and a screenshot is below:

migrate_error
https://bin.ptdl.co/gsyfb/

FYI: Commands are running as the root user because the server is a LXC container run in a Proxmox VE system and that is the user created when the container is configured.

To Reproduce
Steps to reproduce the behavior:

Go to https://pterodactyl.io/panel/1.0/getting_started.html
Follow the installation guide as follows. When asked to input a database, enter a database running on different server.
When you get to the Database Setup step, run the php artisan migrate --seed command and the error should appear.

Expected behavior
Expected behavior is that the command should complete without an error as it should read the connection details from the .env file that were stored there in the php artisan p:enviroment:database command.

Source

brandan-schmitz

All 11 comments

I'm guessing you're not using a supported version of MariaDB, Could you get us the output of mysql -v?

AreYouRlyScared on 21 Apr 2020

That was my original thought however when I checked I am using version 10.4.12 on both the remote server and local and system requirements shows a need of 10.2.x or higher. I can get it to to run when using a local database but not the remote. The remote server is also a Ubuntu 18.04.4 LTS LXC container containing nothing but MariaDB, PHPMyAdmin and their dependencies.

root@db-04:/etc/systemd# mysql -v
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 64
Server version: 10.4.12-MariaDB-1:10.4.12+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Reading history-file /root/.mysql_history
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

brandan-schmitz on 21 Apr 2020

So I can properly test this, MariaDB is on a remote machine, sperate from the panel install?

AreYouRlyScared on 21 Apr 2020

That is correct. I run a Proxmox VE cluster that it runs on. Right now I have two LXC containers, both are Ubuntu 18.04.4 LTS containers.

The panel runs on one container while the database runs on the other. This database server is the same one that runs my current production Pterodactyl install, and I just upgraded the DB server to the version seen above earlier this month in preparation for testing the new panel.

brandan-schmitz on 21 Apr 2020

Okay, I'm setting up two VPS servers running ubuntu 18.04, one will have the panel and another will have just MariaDB, Using the same version you're using for the DB.

AreYouRlyScared on 21 Apr 2020

👍1

So I was not able to EXACTLY reproduce your issue, as that migration succeded

However I did run into an issue with another migration, 2020_04_10_141024_store_node_tokens_as_encrypted_value
SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT trans2 does not exist

@DaneEveritt This looks like a larval issue and using DB::transaction. I see it's used in older migrations. not sure why this one failed.

Noted that I am using MariaDB version 10.4.12, I didn't get this error on my install using MySQL 8.

AreYouRlyScared on 21 Apr 2020

😕1

That is just strange. I am creating a fresh LXC container with a fresh DB server install with MariaDB so I will try that and see if maybe there is just something don't remember setting on the original server messing with things.

brandan-schmitz on 21 Apr 2020

If possible, until this last migration gets fixed/figured out, You could use MySQL 8.

AreYouRlyScared on 21 Apr 2020

👍1

Yeah that first error looks like your database didn't support the JSON field type. And neither of those errors make any sense, all of the migrations have run fine on plenty of other machines, there is nothing crazy in them.