@sega said in FOG Multicast on different VLANs:

Is there something that I can look up, to see where the problem is?

Well your router supporting PIM is a good sign. Some routers have a service called igmp proxy or igmp relay, or even igmp snooping (you will find this more on switches, but check). This service typically has a number of interfaces to listen on and then a master interface where your multicast source lives. Its job is to relay the multicast requests to the proper interface.

PIM has two modes sparse and dense, that may be just for switches, I don’t remember. Sparse mode only sends the multicast traffic to the subscriber’s port, where dense just blasts out the muticast to all ports. You want sparse mode if possible, that way only the ports with a multcast receiver will see the traffic and not flood your network.

@george1421 I would need help with where I can edit and which files to add a script for quick inventory.

To add to this, we’ve been imaging a variety of desktop and laptops to Windows 11 last week and we’ve had three occasions where FOG has imaged to a connected portable hard drive rather than the local hard drive. I don’t remember it doing this before.

My technicians are on the lookout and are trying to remember to disconnect portable drives ongoing before a deploy but has something in Windows changed recently? We’re on FOG Version 1.6.0-beta.2233

@mrowand The whole point of the checkAuthAndCSRF is to prevent unauthorized access. Based on the message I’m seeing, the 403 forbidden is happening because it’s crossing origin to get the data or the CSRF token isn’t passing correctly:

Here’s the code that validates:

// Optional defense-in-depth: Origin/Referer check for state-changing requests public static function checkOrigin(array $allowedOrigins): void { $method = strtoupper($_SERVER['REQUEST_METHOD'] ?? 'GET'); if (!in_array($method, ['POST','PUT','PATCH','DELETE'], true)) { return; } $origin = $_SERVER['HTTP_ORIGIN'] ?? null; $referer = $_SERVER['HTTP_REFERER'] ?? null; if ($origin) { foreach ($allowedOrigins as $allowed) { if (stripos($origin, $allowed) === 0) { return; } } http_response_code(403); echo _('Forbidden (disallowed Origin)'); exit; } elseif ($referer) { foreach ($allowedOrigins as $allowed) { if (stripos($referer, $allowed) === 0) { return; } } http_response_code(403); echo _('Forbidden (disallowed Referer)'); exit; } // If neither header is present, you can decide to be strict or lenient. // Often lenient to avoid breaking weird client setups. }

I suspect your console has more information leading to the specific error that was hit.

ultimately the code is working as expected and there’s something in your environment causing the issue. Now, to be fair, you said you installed Stable, and Dev-branch has a fix of which I admit I missed.

If you’re willing/able to install the dev-branch I suspect you’ll see this is working much better.

@boombasstic This is known and will be fixed automatically on the 15th, but please if you need to switch to the dev-branch and install it. Then you should be able to export reports.

@phant0mbot said in Dell OptiPlex 3000 Thin Client:

have tried both SAN and GRUB exit options

boot loader == snponly.efi

These are in contradiction with each other. SAN boot and Grub are bios boot methods. snponly.efi is a uefi boot loader. Since you are getting into the fog iPXE menu we can assume the hardware IS uefi based since it is booting snp.efi. Try a uefi exit mode of rEFInd (refind) to see if that will boot from the hard drive. The default value can be set globally in the fog configuration->fog settings page. Don’t force a bios attempted boot from a uefi booted computer, that never works.

@Jchinn412 The answer is it depends on how you have your disk structure setup

Post the results of these two commands.

lsblk
df -h

It maybe easy or harder (but not impossible) depending on how you have the disk created.

@ecoele The fact that dev-branch is in 1700’s this informatino seems to indicate your’e still running the latest stable.

Once you switch to dev-branch you need to pull in the changes:

cd /your/path/to/fogproject git checkout dev-branch git pull cd bin sudo ./installfog.sh -y

Should get you installed.

You may also need to (from the browser) do a “CTRL + SHIFT + R” to do whats called a hard refresh in the browser to get all the latest/new javascript information.

@Tom-Elliott Thanks, going to switch back to 1.6 very soon.

@Fog_Newb Yep, it’s as I suspected:

The Line:

Subsystem sftp /usr/lib/openssh/sftp-server

should be changed to:

Subsystem sftp internal-sftp

Then restart ssh services: systemctl restart sshd

Then your Storage Node testing should succeed!

@rhysb92 We need more information.

i ask because I have just built a new VM, and installed dev-branch/stable and it completed and I was indeed able to login with the fog/password combination where i then changed the PW.

So I feel like we’re missing some key information.

Thank you for the information. I used a bare metal machine. I started with a VM but then just used a old pc. I tried it with Fedora then Ubuntu but did not have any luck. I did not get any errors when installing with the install script.

I will take a look at the information you gave me and see if I can get anything working.

@Petrushka hello!!

In our firewalld rules we have

services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

@BrightPipe Can you post the snapin?

This isn’t something FOG is doing, though you already suspect that as well.

So seeing the snapin file, I’m guessing it’s using some method that’s effectively saying “set all the things” and the snapin is set to only set “specific” things.

Since the action is effectively “setting all the things” it’s resetting the other things you didn’t intend.

Seeing the snapin and the actions involved will be most beneficial at least to understand what’s happening. We may not be able to fix the issue but at least we could all better understand the problem and maybe think of ways to troubleshoot and hopefully narrow down whats wrong.

At cursory glance, it feels like the snapin is misconfigured in someway. Thought you did say it worked in Windows 10, but not in Windows 11, so it’s also just as possible there’s some functional difference that needs to be adjusted for in the Windows 11 side of things.

I completly reinstalled the dev_branch software in an new Debian 12 guest and now it seems to work fine.
Thank you