@Jamaal I’m not sure I follow? The database isn’t insecure, it was being able to download the database, or force an upgrade without authorization that was the piece being secured, nothing about the normal day to day operation of the database changed.

@Jamaal @Jab98

If you’re doing upgrades (if you trust the base defaults of a fresh install)

You can also run the sudo ./installfog.sh with the -y argument and it will “just do all the work” so you don’t have to do the "open a browser -> click the button -> return to the installer, press enter.

Just trying to help. By no means is this a requirement (of course) but it may help in the future, and this method would also perform the update of the core database elements automatically for you. (This was a part of the addition of the token too. - To make the upgrade process more autonomous and secure.)

@Jamaal So if you go to that URL and click the button to install, you should be successful.

@Jab98 Please see the message to Jamaal as well.

Yes a security based change was added recently because anyone could force the updates and could export the db without any type of authorization.

@Jamaal

That token is generated on every run so you seeing what I see doesn’t matter, but it should showup like what you’re seeing here.

@Jamaal What’s the url that is displayed for you to goto for that on the output of the command telling you where to go?

It should contain a tokenization embedded for you to goto.

@Jab98 You’re running 1.5.5 and 1.5.10

are you able to update your machines to the latest working-1.6 or dev-branches by chance?

I suspect the isseu you’re seeing is related to the version mismatches (while we do try to maintain compatibility sometimes such things just aren’t reasonable.)

I’m not seeing anything that would be specifically breaking things, but with the age of your Servers/Nodes, it’s difficult to troubleshoot.

I mean Debian 9 is also fairly ancient now, and might just be throwing issues because of its own age.

I don’t know what the right answer is just trying ot get something more updated so we can help you with the latest and greatest of things we’ve been working on and know much more about.

@kratkale It’s already not working, so you updating the value on the Storage NOde (your second image there)

Isn’t going to hurt anything.

@Nono Edit your /opt/fog/.fogsettings file and replace entries of ‘mysql-client’ with ‘mariadb-client’

I suspect they’ve updated the repo to solely exist for mariadb-client, but you had it before that package switch/change occurred so your fogsettings file is just expecting mysql-client always.

I might also recommend removing the existing mysql-client package just to ensure clean flow, though of course get a backup before any such actions.

@kratkale Please update the latest dev-branch. Yes I pushed something that had broken this, and then when it was brought to my attention we fixed the problem. To my knowledge this is working again.

As for the actual snapin upload, I’m not aware of any issues there so you may need to look at your username/password for the storage node.

I suspect there’s a special character that got encoded incorrectly, though I’m not 100% sure. This (too) could be a problem we introduced trying to fix a bunch of XSS issues (for security reasons) but you might be able to more simply fix this by just setting the value on the username/password out of the storage node’s fogsettings username/password inforrmation.

@Bristow-0 You will need to upgrade to either dev-branch or wait until later today/tomorrow and update to stable. I backported this into the dev-branch as well the working-1.6 branch for consistency and ease.

@Bristow-0 I’m working on a fix for this, however it will likley mean you need ot setup and get your api token and user api token.

Basically, my thought is to create an API endpoint that allows you to get the database backup, but securely.

The reason:

All your AD and username secrets are stored in the database, so anyone who can download the database now has all the access credentials to all the data in your environment.

I think you can imagine the repercussions this could cause and I apologize we even had this open wide gap for any period of time.

I want this to continue to work for you, but we need this to be secure too, working on it now:

The issue is documented as well the api endpoint documentation:
https://github.com/FOGProject/fogproject/issues/827

Hope this helps.

Testing this I did:

curl -ik -X GET "https://10.255.20.1/fog/system/export" -H "fog-api-token: $FOG_API" -H "fog-user-token: $FOG_USR" -o 'test_db.sql'

Of course changing the IP to yours and setting your variables where required would make sense.

Your script would be adjusted to:

#!/bin/bash

fogServerAddress="172.X.Y.Z"  # Change to actual FOG server address

fogApiToken="YOURFOGAPITOKEN" # Change to FOG Configuration -> Settings -> FOG API Token (ensure api is enabled for global access)
fogUsrToken="YOURFOGUSERAPITOKEN" # Change to User -> API Token (ensure api is enabled for user.)

backupDate=$(date +"%Y%m%d")

backupDir="/mnt/FOGBackups/$backupDate"
backupDirImages="/mnt/FOGBackups/images"

snapinLocation="/opt/fog/snapins"
reportLocation="/var/www/fog/lib/reports"
imageLocation="/images"

failedBackupDB=0
failedBackupSnapins=0
failedBackupReports=0
failedBackupImages=0

[[ ! -d $backupDir ]] && mkdir -p $backupDir/{mysql,snapins,reports,logs} >/dev/null 2>&1
[[ ! -d $backupDir/mysql || $backupDir/snapins || $backupDir/reports || $backupDir/logs ]] && mkdir -p $backupDir/{mysql,snapins,reports,logs} >/dev/null 2>&1

backupDB() {
    curl -ik -X GET "http://$fogServer/fog/system/export" -H "fog-api-token: $fogApiToken" -H "fog-user-token: $fogUsrToken" -o $backupDir/mysql/fog.sql 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1
    stat=$?
    if [[ ! $stat -eq 0 ]]; then
        echo "Failed to backup database!"
        failedBackupDB=1
    else
        echo "Database backed up."
    fi
}

backupSnapins() {
    cp -r $snapinLocation $backupDir/snapins/ 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1
    stat=$?
    if [[ ! $stat -eq 0 ]]; then
        echo "Failed to backup snapins!"
        failedBackupSnapins=1
    else
        echo "Snapins backed up."
    fi
}

backupReports() {
    cp -r $reportLocation $backupDir/reports/ 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1
    stat=$?
    if [[ ! $stat -eq 0 ]]; then
        echo "Failed to backup reports!"
        failedBackupReports=1
    else
        echo "Reports backed up."
    fi
}

backupImages() {
    rsync -auv $imageLocation $backupDirImages 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1
    stat=$?
    if [[ ! $stat -eq 0 ]]; then
        echo "Failed to backup images!"
        failedBackupImages=1
    else
        echo "Images backed up."
    fi
}

checkForFailures() {
    echo "Running checkForFailures()"
    if [[ $failedBackupDB -eq 1 ]]; then
        message="$message \nFailed to backup database."
    fi

    if [[ $failedBackupSnapins -eq 1 ]]; then
        message="$message \nFailed to backup snapins."
    fi

    if [[ $failedBackupReports -eq 1 ]]; then
        message="$message \nFailed to backup reports."
    fi
    if [[ $failedBackupImages -eq 1 ]]; then
        message="$message \nFailed to backup images."
    fi
}

sendNotif() {
	echo "Running sendNotif()"
    if [[ ! -z $message ]]; then
        {
            curl -d "FOG Backup Failed\n $message" ntfy.sh/XYZATEHFJICH
		}
	else
		curl -d "FOG Backup Successful!" ntfy.sh/XYZATEHFJICH
	fi
}

backupDB
backupSnapins
backupReports
backupImages

checkForFailures
sendNotif

@Infojoe Confirmed, I’m able to create a host without issue at least at 1.5.10.1867 it seems.

@Tom-Elliott Should be addressed in latest dev-branch. Thanks.

@Infojoe I believe I pushed a fix for this already, but I’ll have to check again tomorrow morning.

@Infojoe right now this is understood (they typo I’ll get fixed in the morning, but the auth check is preventing inventory from sending, so fixing will be more likely deleting the auth check entirely again. This is where which side of the coin is needed. I’ll probably remove the line so things just work as they once did. Thanks for letting me know.

@kratkale So things are working under the latest with dev-branch?

@kratkale Install using dev-branch

@kratkale I’m confused what you mean their serial numbers are erased?

FOG isn’t overwriting the serial numbers on these devices.

Furthermore, Serial numbers aren’t stored directly on the host, they’re stored on the inventory table.

That column (hostDevice) is about storing what device a host will be using to image against.

If somebody is updating the group, the empty hostDevice (Group device for groups) would likely be overwriting it.

I’ve pushed a code change to hopefully address this particular issue in the latest dev-branch.

@Chandlerbing Can you do a look for all files that contain:

grep -r 'display_errors' /etc | grep -v '#'

This should only display things where display_errors is defined directly.

I suspect there’s one that is doing this for you natively.