@sebastian-roth said in FOG-Client suddenly stopped working:

Is the srvpublic.crt still valid?

Was the first thought, but no, its valid.

Sorry for the late answer, very busy at the moment.

@tom-elliott said in Persistent Groups - Snapins added to host but not deployed:

e host is joined to a group it should automatically deploy he snapins to the newly joined host?

The short answer is, Yes.

The bit longer answer is still, Yes.

While I surely don’t need to repeat the concept of persistent groups to you, I’ll explain it for those who may find this thread in the future.

The intent of a persistent group is to create a model/ideal/template host in FOG. That host may have specific kernels, inits, parameters, printers, snapins, etc. defined in that group. We might call that our baseline configuration for any new host we would add to that group.

So lets expand this a bit, lets say we have 2 FOG Groups, Finance and Purchasing. Each department uses the same computer hardware, but have different application requirements and different local printers. Now lets say I’m staging a new computer for the Finance department. When FOG is done imaging the computer and doing any post install things via the FOG Client, I want that new computer to look exactly like the other computers in the Finance department with its baseline applications and default printers defined (just for full disclosure I don’t use the snapin or printer subsystems of FOG so I might overstate the capabilities of each). So when I’m running through the full registration, one of the questions the registration script asks is if I want to associate the host with a specific group. At this point I would say Finance, and proceed with imaging.

With the current persistent group trigger, if the template host had Finance application snapins associated with the template host those associations would be copied over to the snapin association table like defined. But at the end of the imaging and FOG Client actions the applications would not be installed on the target computer. The snapin association was made, but the client was never told to install the software. This is the problem in the OP of this thread.

We are missing the step to tell the FOG Client to install the associated snapins.

Now with that said, I can also see a problem with this new approach in that its possible to deploy an already installed application to the same target host.

Side note is that while the focus is on Snapins, the Printers module also suffers from the same condition in that the associations are created but the client is never told to do the install.

@seppim Your Ubuntu install was setup with LVM but FOG does not support capturing the filesystem within the LVM yet. So FOG will capture as RAW - takes very long and image files in FOG server is huge.

Do you need the LVM setup? Or did you just blindly skip through the partition setup when installing Ubuntu.

The other question arising is, why would /boot have to be 398 GB? That doesn’t make sense at all.

@tom-elliott said in FOG 1.5.9.57 on Debian 10 mysql root password is blank:

We are a fully clean install. Meaning no packages except git are installed. No Apache, php, or MySQL. Why should the installer ask for root password here? It has never been setup before this point. There would be no password. FOG, in my opinion, should not be defining the root user password here either.

I think it should force the user to have a DB root password unless it’s a setup with local socket access as described below. That was one of the major points of re-writing that part of the installer. I tested a lot and would hope that the installer does what I say on all officially supported systems.

@danieln said in Clients imaging despite recieving "Read ERROR: No such file or directory" and "ata1.00: failed command" errors:

However, just for my own clarification, those two checksum outputs should be the same if it replicated correctly?

Exactly!

@julio You need to look into who installing those programs on Ubuntu/Debian is possible at all. For example, Notepad++ is a native Windows program and seems like you need to use snap (on Ubuntu) or even manually install wine to be able to run Notepad++ on Linux: https://itsfoss.com/notepad-plus-plus-linux/

Visual Studio Code seems to be available for Linux: https://code.visualstudio.com/download

Putty is available as official package on Ubuntu and Debian as far as I found.

An so on. This is well beyond what we can do for you! You need to figure out how the installations work or ask in different forums specific to that software you want to install. Start by searching the web.

As soon as you figured out how to install each software you can use bash scripts (mentioned below) to do the job for you.

@boriquaboy115 Should be able to fix that without re-install. Go to the directory where you extracted the FOG installer (or cloned it via github). If you don’t have that anymore you can re-download it. Best to use the same version you installed before: https://github.com/FOGProject/fogproject/releases

Change to root user (e.g. sudo -i or su -) and navigate to the subdirectory utils/FOGiPXE/ within the FOG installer dir. Then run the iPXE buildscript and copy over the new binaries that were generated by the build script:

./buildipxe.sh cd ../../packages/tftp/ find -type d -exec mkdir -p /tftpboot/{} \; find -type f -exec cp -fv {} /tftpboot/{} \;

See if you clients are able to PXE boot again.

Edit the file /opt/fog.fogsettings and replace the IP address there.

Then edit the /tftpboot/default.ipxe file

in the fog settings and default storage node change the IP there.

Finally rerun the fog installer once again to fix the rest of the bits.

@sckendall said in Fog ProxyDHC with Fog and Pfsense on the same network:

Well, the question is whether it is possible to have two independent fog servers on the same network.

Well this sentence changes everything.

If you want to pxe boot on your laptop you will need an isolated network or if you are running a hypervisor on your laptop then you can create an internal network.

I just think of an idea. Its possible if on your main FOG server, you create a custom FOG iPXE menu that links the fog server on your laptop. Then normal pxe booting to main fog server, then chain (ipxe command) to your FOG server. That is possible.

@george1421 Scratch that. I was confused about how this works, my apologies.

The Windows 10 installation I used to create my image is using an MBR, aka Legacy boot.

Thanks again for the quick reply.

@klisza1993 said in Fresh FOG installation and no Client detected:

Middleware::Communication ERROR: Communication ERROR: Request Aborted: Unable to create SSL / TLS secure channel.

I have never seen this error before and I am not sure where it might come from yet. In your first post you said you didn’t enable HTTPS when running the installer but you later post says you are using HTTPS as well. So I would imagine that a request to the HTTP URL is being redirected to HTTPS (default when you enable HTTPS with the installer) and the error stems from an issue with the server certificate.

Did you manually change the webserver configuration?

During troubleshooting, what i have discoverd, tah i can get communication with Server pasting this link into browser.:
https://192.168.205.132//fog/service/register.php?hostname=rk-test&mac=D6:C8:93:84:8B:24&newService&json
From my poinf of view its NOT SECURE.

Surely not ideal but you need to consider that FOG is not a secure product. Very few people help working on the code to find and fix bugs. You are more than welcome to join the force and get this out of the way.

@cyannella Hmmm, its been a while since I looked at that. It still should be technically possible to do.

@mrawesome987 Ok just a few questions and I think we can rule out an external actor.

In the last picture the dhcp OFFER, the redacted IP address IS that of your main dhcp server?

If that is the case we now know that we don’t have some outside dhcp server messing with the pxe booting process so you know the problem IS IN your main dhcp server and not someplace else.

In your new vendor class the “:UNDI:003016” part should not be there because its too specific. It should stop in the binary code at “007”

As you see in dhcp option 93, the client IS saying that its an EFI x64 (class 00007). So that part is working right.

In wireshark in the OFFER from the dhcp server, in the ethernet header there should be something like your IP address. That is the dhcp server saying to the client this is your new ip address. That your address, the IP address that IS from the scope where you have the policies defined?

On the surface, this should be working. All of the bits are in place.

hello,
I found the solution.
looking at the databases, there are 5 fields on the fog 1.2.0 base and there are 9 fields for version 1.5.9.
so the hots don’t appear.
by importing the database on the new server and importing the csv host everything is ok.
the export of the csv on the 1.2.0 server was with the separator ,
I reworked the file with free office to put it in ;
it works.
I leave the solution here for old fogs who want to migrate to a new machine

[push]

Maybe someone has in idea whats wrong?

@george1421 That did the trick!

I had previously added the images2 *(ro etc;etc;etc;) but did not run the sudo -exportfs -a command.

I knew it was something simple. Thanks so much for your help!

@dominique said in Database engine MyISAM - upgrade FOG?:

Any idea when 1.6.0 will be general available?

There is no timeline for this yet. Many people use FOG but very few help working on it. So things are going very slow at the moment. We’ll bring out a last 1.5.x release (1.5.10) to finish up that line and then the next will be a first 1.6 release (months down the road).

If you are keen to get InnoDB earlier you can follow the topic Goerge posted. From my point of view this should be possible in 1.5.x setups as well. But we won’t officially support this and don’t want to push out for a major change in the 1.5.x branch anymore.

@palloquin said in fog client no longer rebooting system to deploy, where to start?:

21/01/2021 11:26 Middleware::Communication URL: http://172.16.1.2/fog/management/index.php?sub=requestClientInfo&mac=00:FF:3E:84:3E:C1|40:A8:F0:61:47:B3&newService&json
21/01/2021 11:26 Middleware::Communication ERROR: Could not contact FOG server
21/01/2021 11:26 Middleware::Communication ERROR: The remote server returned an error: (500) Internal Server Error.

Those are the relevant lines frm the log. Please check the apache and PHP-FPM error logs (see my signature) to find out what is causing the HTTP 500 internal server error.