Hello, trying to follow the docs for setting up a server. I’m running the

fleet prepare db

command, but it doesn’t output anything, and looks like the tables are not initialised. Any tips?

# /usr/bin/fleet prepare db  --mysql_address=127.0.0.1:3306  --mysql_database=fleet  --mysql_username=root --mysql_password=REDACTED
#

mysql> use fleet;
Database changed
mysql> show tables;
+-------------------------+
| Tables_in_fleet         |
+-------------------------+
| migration_status_data   |
| migration_status_tables |
+-------------------------+
2 rows in set (0.00 sec)

mysql> select * from migration_status_data;
+----+------------+------------+---------------------+
| id | version_id | is_applied | tstamp              |
+----+------------+------------+---------------------+
|  1 |          0 |          1 | 2022-05-13 07:08:27 |
+----+------------+------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from migration_status_tables;
+----+------------+------------+---------------------+
| id | version_id | is_applied | tstamp              |
+----+------------+------------+---------------------+
|  1 |          0 |          1 | 2022-05-13 07:08:27 |
+----+------------+------------+---------------------+
1 row in set (0.00 sec)

Hi @Daniel Cross. From the migration tables content it does look like an uninitialized database... Couple of questions: 1. No output at all

/usr/bin/fleet prepare db

? (try adding

--logging_debug

) 2. What's the fleet version?

/usr/bin/fleet version

3. Have you set Fleet's MYSQL environment-variables/flags when running

/usr/bin/fleet prepare db

? (to connect to the

127.0.0.1:3306

instance)

Hi @Lucas Rodriguez 1. Absolutely nothing even when adding --logging_debug 2.

fleet version 4.14.0

3. I’ve set the flags as per docs (as pasted above)

--mysql_address 127.0.0.1:3306  --mysql_database=fleet  --mysql_username=root --mysql_password=XXX

Absolutely nothing even when adding --logging_debug

OK, let's try re-doing the following steps: (Assuming that you have no data to lost in MySQL

fleet

database.) 1. Run the following in a mysql prompt

drop database if exists fleet; create database fleet;

2. Run

/usr/bin/fleet prepare db --mysql_address=127.0.0.1:3306  --mysql_database=fleet  --mysql_username=root --mysql_password=REDACTED

. It should run for a couple of minutes and output

Migrations completed.

and exit cleanly. 3. Check the prepare command exited successfully:

echo $?

(should print

0

). 4. Log in again to mysql and run

use fleet

and run

select * from migration_status_tables;

.

This looks much better. So dropping the db and starting fresh helped here - I guess ‘prepare db’ hit something in those migration tables and silently failed 🤔

Glad it helped!

Anyone have this issue. This is on a Debian AWS (not container) instance. Every time I delete these entries they come back green for a minute then back offline.

Hi @James Wilburn! This is being fixed on next release of Orbit (issue: #9132) (should auto-update and fix automatically). Though you would need to remove the ghost entries manually one last time after the auto-update.

Awesome, because I'm sooooooooo out of idea's lol

Orbit should run with root privileges (it's not supported to run as non-root). That could be one cause of the issue. Another cause is linux distributions not having a

/sys/class/dmi/id/product_uuid

file.

I had an issue with the Security Onion Fleet (kolide) where the host_identified=uuid seemed to be hard coded and I had an issue with duplicate hostnames in my environment (a lot of identical hostnames). I moved to a stand-alone and then this, lol. Glad this problem is actually getting fixed. I like Fleet too much

@James Wilburn Hi! New Orbit should be released sometime this week.

Sweet. Thanks Sir