Posts made by Tom Elliott

@kylian001 Please provide your php-fpm error logs.

On redhat systems this is generally: /var/log/php-fpm/www-error.log otherwise it maybe the apache error logs.

@yannickF I’m working on using SSH vs FTP for file transfers and deletions as it’s more “natual” in today’s security conscious world.

If you’re able to allow SSH to the remote ends, this may help out with things.

I’ll have to change the text on these fields to remove “FTP” as the main parameter.

As, and this is very much just a guess, the Error is showing specifically teh SFTP subsystem is failing, I am guessing the remote side is not setup (properly) for SFTP, and is instead using the default sshd_config file.

I say this because there’s checks letting you know if you can connect, and if the sftp fails. Since connect has to happen first, that message tells me the configuration on the remote machine needs a minor update.

If you have admin access to that remote node (as well any node you need this to connect to)

Please open the relative machine’s /etc/ssh/sshd_config

Look for the line:
Subsystem sftp /usr/libexec/openssh/sftp-server

Replace it with:
Subsystem sftp internal-sftp

Restart sshd service:
sudo systemctl restart sshd.service

This should fix that particular error message.

@yannickF I suspect the upgrade itself, doesnt’ upgrade/retrigger upgrades to plugin tables unfortunately.

You can fix this issue with LDAP by mysql command into your database:

mysql -u fogmaster -p fog (find your fogmaster password in /opt/fog/.fogsettings

Run:

ALTER TABLE `LDAPServers` ADD COLUMN `lsGroupNamAttr` VARCHAR(255) NOT NULL AFTER `lsUserNamAttr`

@yannickF You really should state your issues.

If a feature isn’t available for whatever reason, we will tell you, but leaving us in “uh oh” isn’t really a good approach.

What issue are you having?

@yannickF I don’t understand what you are asking.

1.5.x also worked this way as it was intended to be a jump between of the older style (0.32 -> 1.4.x) versions of FOG, allowing us to work toward a reactive interface. It was not a perfect UI, just meant to get us the framework to a better system.

This is still in progress, if you’re willing to look at it and test it along side things.

Install FOG working-1.6 branch and i think you’ll see a vastly differently layout and operational structure.

It, in my opinion, is needing the testing. Functionally all the same things are present and operational, but much more suited for performance and hopefully ease of use.

To install it:

cd /path/to/foginstall # if git
git checkout working-1.6
git pull
cd bin
sudo ./installfog.sh -y

Should do all the things necessary for you.

@processor You set the replicator sleep time (and sleep time for all services.)

FOG Configuration -> FOG Settings -> FOG_IMAGEREPSLEEPTIME

It’s defaulted to 600 (10 minute cycles.)
If you set it to 86400, that should do the checks once per day.

@tiefel From what I can tell you hit enter on the part it asked you to go to the browser and actually submit the database insert/update process.

It literally needs the database to run.

So you can do this automatedly doing:
./installfog.sh -y Which will set all the default options and just make your involvment less involved. Of course if you’re not wanting to be that involved, please follow the on screen prompts as they occur.

Mind you if you go through the point of the install and while ti’s installing packages, the enter’s you press will translate as proper inputs later when you may not have intended them to occur, please take care and use patience.

@RogerBrownTDL So the installer always defaults to /tftpboot folder

you may need to make /srv/tftp a ln to this folder? Or edit the /etc/default/tftpd-hpa file to make TFTP_DIRETORY=/tftpboot

This occurs in:
echo -e "# /etc/default/tftpd-hpa\n# FOG Modified version\nTFTP_USERNAME=\"root\"\nTFTP_DIRECTORY=\"/ tftpboot\"\nTFTP_ADDRESS=\":69\"\nTFTP_OPTIONS=\"${tftpAdvOpts:+ $tftpAdvOpts }-s\"" > "$tftpconfigupstartdefaults"

Which effectively makes the (default) file look like:

# /etc/default/tftpd-hpa
# FOG Modified version
TFTP_USERNAME="root"
TFTP_DIRECTORY="/tftpboot"
TFTP__ADDRESS=":69"
TFTP_OPTIONS="-s'

@JJ-Fullmer -y does indeed automate the schema updates.

@pbriec Figured out, I think, the issue of your host-snapin-history-table:

It’s database entries have gone out of sync:

Please login to your mysql/mariadb on the server: (The password will be in your /opt/fog/.fogsettings file under snmysqlpass or something very similary, usually under the variable named snmysqluser=fogmaster

mysql -u fogmaster -p fog

It will prompt for your password, which you collected earlier and hit enter

in the mysql side you can run:

delete from snapinJobs where sjID not in (select stJobID from snapinTasks) or sjID=0;
delete from snapinJobs where sjHostID not in (select hostID from hosts) or sjHostID=0;
delete from snapinTasks where stJobID not in (select sjID from snapinJobs) or stJobID=0;

That should fix the host-snapin-history-table issue.

@processor Yes this is normal.

We are checking each file of an image independently to determine if it needs to be synced or not.

In the past, there was a simpler mechanism. if the data varied at all int eh folder the entire contents of the secondary nodw would be deleted and resynced for that image. As you can imagine, this worked, and logging was much less of course. That said,

imagine, a sfdisk (partition file that’s simply a few bytes of text) had somebody go in and delete a line. The whole 40GB of that image would’ve been deleted and resynced over the network.

By checking each file of an image independently, we can limit the about of network usage to check/sync data and provide (in my opinion) more information on exactly what’s happening during it’s regular process.

@pbriec I don’t know what you mean by waking up an old laptop. I’m assuming there’s a task that you’re not able to see in the UI, but that was an imaging type of task (those are the type that do WOL)

As to why your new laptop is not able to WOL, i do not know if it’s because of the passthrough vs the actual MAC address of the adapter. You could test, but adding the true mac address of the adapter to the host and tasking to see if it wakes up. This is because the magic packet needs to indicate the burned in address (to my knowledge) for the interface to actually respond and kick up the system. Then again, i don’t know how an externally but connected (USB-C/USB-A) wire would tell the laptop to wake up. I could imagine it working on USB-C, but still having a bit more difficultly than a natively board mounted network card.

As for the host-snapin-history-table, I’m aware of the issue, but I have not yet been able to replicate it.

I’ll see if I can do so today, by creating a false entry.

Thank you!

@RogerBrownTDL I believe the 24.04.3 LTS is supported by FOG in the Dev-branch.

If wanting to stick strictly to the 1.5.10 “latest official” release, I believe Ubuntu 22.04 is the latest supported.

@Tom-Elliott I think this post helps fix the issues:
https://forums.fogproject.org/post/154920

@pbriec

I have modified the init’s that should automate the fixing of mac address when there’s a passthrough (variance of ipxe -> init) noticed.

You will no longer need the domacset flag defined, it will just do the action of setting the mac address as appropriate:

https://github.com/FOGProject/fos/releases/tag/EXP_20240618

Replacing the init files as required shoudl fix this issue and as we get new versions happening, this will become a standard.

@Chris-Whiteley This is a table of FOG from the older “virus scan” capabilities. It was a storage point for if and what it found on machines it had scanned.

@processor You created a table in FOG called hostsIP?

Note: This isn’t a bad thing, I’m just trying to reference the information.

The way I understand this, you’re looking at the mutlicastSessions table, getting a group, and getting the name of the hosts.

You’re at least aware of the IPs which most others will not be, but just trying to think this through.

@simon said in probleme sur les taches planifiers pour une décente d'image:

j’ai bien fait cette configuration mais cela ne fonctionne toujours pas

Can you re-run the FOG installer or restart the FOG Services that deal with scheduled tasks?

This should force all existing services to reload, and I apologize for forgetting the services need restarting as well, just didn’t think about it.

You should have logs, that will show you the time that things are running, which will also help.

These can be seein in the UI under FOG Settings -> Logs, Scheduler I think.

---

Pouvez-vous réexécuter le programme d’installation de FOG ou redémarrer les services FOG qui gèrent les tâches planifiées ?

Cela devrait forcer tous les services existants à recharger, et je m’excuse d’avoir oublié que les services doivent également être redémarrés, je n’y ai tout simplement pas pensé.

Vous devriez avoir des journaux, qui vous montreront l’heure à laquelle les choses fonctionnent, ce qui sera également utile.

Ceux-ci peuvent être consultés dans l’interface utilisateur sous Paramètres FOG -> Journaux, Planificateur, je pense.

@simon Unfortunately I am not able to speak french natively nor read it, so I am stuck with using google translate, which may leave more questions than answers, but hopefully is close enough to understand at least the base problem.

In FOG there’s 2 methods to setting the timezone. One is as @luilly23 as described, but that works for things in the UI, not the system as a whole. The second place is the timezone for the local php.ini installation.

In your operating system’s php.ini file (on Debian based systems there may be 2 different versions (cli/apache2)

• This is just a synopsis, not necessarily exactly where you will find your file.
  /etc/php.ini
/etc/php/<phpver>/cli/php.ini
/etc/php/<phpver>/apache2/php.ini

set your timezone appropriately:

date.timezone = "Europe/Paris"

Restart php-fpm:
systemctl restart php-fpm

---

Malheureusement, je ne suis pas capable de parler français nativement ni de le lire, donc je suis obligé d’utiliser Google Translate, ce qui peut laisser plus de questions que de réponses, mais j’espère qu’il est suffisamment proche pour comprendre au moins le problème de base.

Dans FOG, il existe 2 méthodes pour définir le fuseau horaire. L’un est comme @luilly23 comme décrit, mais cela fonctionne pour les éléments de l’interface utilisateur, pas pour le système dans son ensemble. Le deuxième endroit est le fuseau horaire pour l’installation locale de php.ini.

Dans le fichier php.ini de votre système d’exploitation (sur les systèmes basés sur Debian, il peut y avoir 2 versions différentes (cli/apache2)

• Ceci n’est qu’un résumé, pas nécessairement l’endroit exact où vous trouverez votre fichier.
  /etc/php.ini
/etc/php/<phpver>/cli/php.ini
/etc/php/<phpver>/apache2/php.ini

définissez votre fuseau horaire de manière appropriée :

date.timezone = "Europe/Paris"

Redémarrez php-fpm :
systemctl redémarre php-fpm

@pbriec The team and I in the background have been doing a lot a bit of testing.

Would you be willing to install the latest working-1.6 branch (or dev-branch)? I know this is technically an alpha, and will take a moment to get used to using, but functionally it should operate like normal just with a new UI:

cd /path/to/fog/installer
git checkout working-1.6
git pull
cd bin
sudo ./installfog.sh -y

This should download latest inits which, to the best of our knowledge works to set the mac.

You would need the domacset=1 setting.

Effectively, what this does, is it sets a new variable as part of the bootup called setmacto as the same as the mac address of the net0 adapter. (Thank you @george1421) If domacset is configured and this variable is set, it will do the network startup, get dhcp, check if the network is up and available, and then set that device to the setmacto MAC address, and reaccomplish DHCP since the MAC changed.

I have added this code to dev-branch as well, but if you’re willing to test the working-1.6 it’s worth it in my opinion (of course I would say that lol).

Of course if you aren’t comfortable testing the alpha, but okay with the iterative development (dev-branch) change the checkout to use that branch.

This should work though it does require (on registration) the domacset=1 at a global level - which I think is fine.

Also, the installer I have the argument -y this just means to ‘Auto accept’ as it may ask questions. If you’re uncomfortable with that method, please just remove the -y argument.