@kratkale Wow, so we’re still no worse for wear at least.

I don’t know why it’s saying unable to install ca certificate?

I"m assuming you set the “url” property during the installer to 192.68.0.196?

(I’m shooting int he dark a bit here so apologies.)

@kratkale said in Windows 11 | 65x HP Z2 Tower G1i | UPDATE -:

bei älteren installation ist die installation abgebrochen, wenn man den Foguser nicht entfernt hatte …
Jetzt ohne userdel habe ich wieder ein Web GUI
ich muss auf den client PC wieder einen neuen FOG Client installieren - sehe ich das richtig?

Possibly yes, if the fog server is brand new (had to create the CA SSL certificates and all).

Möglicherweise ja, wenn der Fog-Server brandneu ist (musste also die CA-SSL-Zertifikate und alles andere erst erstellen).

(Via google translate, I know not great but better than nothing )

@kratkale You’re not stuck in a loop

You didn’t follow the installer instructions and use the link the installer provided you for the database.

There’s a different url because to you security doesn’t matter, but to many others, it most certainly does.

As for the userdel fogproject, don’t do that, please:

That’s actually more likely why you were having ftp issues in the first place. In 1.5.10.x the installer tried to prevent anyone from ever using the fogproject user, but many did. If the account had been used, the only fix was to delete the user. Deleting that user could change the password for the account (and thus the password used on the storage node causing the likely first problem you had encounted).

In either case, this is not a loop, this is a URL on the display where you’re used to just doing it one way. That way changed (in an effort of security). It’s not hidden though, so please use that whole link for this stage or better yet, use the -y option.

@kratkale I want to fully understand:

this is after a fresh install/fresh update from the installer and your’e having all these issues?

it seems (at least at first glance) ftp isn’t liked very much.

As for the snapins I’m at a loss. If you’d be daring can you install the branch working-1.6?

This shifts from FTP in preference of actual SSH and might be better. Of course working-1.6 is more or less in “beta” so this is understandable to be hesitant, but at the same time, without enough testing and feedback, little can move the needle closer and closer to RC -> Master.

Even in the age of AI, there’s not enough data (for me at least) to feel comfortable moving it toward master/stable yet so if you’re daring please upgrade to working-1.6

I will highly recommend making a backup or snapshot pre-upgrade to it just in case something is significantly worse.

The error message you got (OOPS: cannot change directory) seems to indicate authentication is now working but ftp is failing because it cannot drop you to the users’ home directory. The why of that I do not know but I do believe this would be fixed in working-1.6 (or at least I’ll have more assistance to troubleshoot things with you as I’m generally working from that branch).

@Bristow-0 This is similar to how the other thigns worked in the past.

Every install is going to ask you to goto the link.

Not every install is going to have/require a schema update though.

All the change does is ensure that when you click the “Install Update” button (when it’s available) that it can do so successfully.

In short, if you go to the link and there is no ask to click isntall/update, you should be fine to hit enter.

@kratkale I don’t know why you’re telling me your password. (You probably will want to change that now.) and what isn’t working?

@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.