For some reason, neither Multicast nor scheduler nor imagereplication services were up and wouldn’t start. Last log activity from them was on the 13th. They wouldn’t start with only start argument, but had to be stopped first even though they weren’t anywhere on process list and the command itself showed there was nothing to kill (no such process).

Now that I manually started all those services, multicasting works like a charm. Need to fix them not starting on boot in the first place…

Thanks for the reply.

Weirdly enough the process wasn’t running with two jobs waiting to be started on gui. Will update when I can get the test hosts back on the table.

Fog works fine for unicast, but it seems my network configuration is not entirely correct for multicast.

Fog server:
Debian 7.7 Wheezy fresh install with Fog 1.20 fresh install. Dependencies like mysql set up by Fog config.

Separate DHCP/name server running Wheezy as well.
next-server pointed at my tftpboot, pxe in itself works fine, coupled with WoL.

Separate Samba server with no LDAP running.

we’re using 255.255.255.0 range with address space quite filled right now (have about 15 dynamic addresses available with people using them often), need to get on a wider range.

There’s a minimum of two switches between every host and the dhcp server.

Fog server’s hosts file where king is the fog server:
[QUOTE]127.0.0.1 localhost
192.168.7.6 king

The following lines are desirable for IPv6 capable hosts

::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters[/QUOTE]

config.php (it’s a little empty, is there something missing I should have?):

[QUOTE]<?php

define( “WEBROOT”, “/var/www/fog” );
?>
[/QUOTE]

The steps I have taken:

Bringing test hosts on the same subnet, plugged in the same switch as the fog server.

Run all steps in [url]http://www.fogproject.org/wiki/index.php/Multicasting[/url] Troubleshooting section, everything working til Something else to try, where I get the connection and everything’s ready to send, but when I hit enter, the server shows both cliekala@king:~$ gunzip -c “/images/w72015pohi/d1p1.img” |

The udp defaults are the following:
[QUOTE]kala@king:~$ gunzip -c “/images/w72015pohi/d1p1.img” | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface eth0 --half-duplex --ttl 32
Udp-sender 20120424
Using mcast address 232.168.7.6
UDP sender for (stdin) at 192.168.7.6 on eth0
Broadcasting control to 224.0.0.1[/QUOTE]

I seem to have a problem with domain registration as well (we use samba), although without any errors and there’s nothing about it in the log and I can’t find FOG_NEW_CLIENT in settings.
In addition activation is not working with manually entered product key either.

Thanks again!

However I noticed there’s = replacing the last character of every base64 encoded product key in Fog database (which I had inserted manually via web interface thus far).
When writing the script to encode all the keys I have, I got a similar result with two ==s appended in the end, but because the file was created in windows. Replacing Windows newlines with Unix’s by dos2unix gave a clean result, of course.
Now I’m just wondering if this is a oversight in the php portion and I should replace the last character of they keys with it as when writing all the keys straight to the Fog database, or is there something going on beyond the initial php input form on web interface that would change data already in the database even if I’d append cleanly encoded keys?

Couldn’t find anything relevant in the files, I’m not too php/java savvy.

Thanks for your time, yet once again…

Hello

Loving Fog thus far, but I’d like to batch import a few hundred Windows product keys… I found the entry in the database, but it seems to be encrypted. Is there anyone who could shed some light on that matter, so I could just import them straight into the database, since the csv import format doesn’t seem to support importing them?

P.S. if I leave the group product key empty and have keys entered for each individual host, will imaging by group use the individual ones or not perform activation at all?

Having the same problem. Images upload and download nicely, just no luck with getting hosts to reboot with instant image task scheduled. Reboot service is enabled everywhere and client installed. WoL is not working either, even though it’s enabled in bios and Windows drivers.

[quote=“Tom Elliott, post: 40774, member: 7271”]Are you speaking on dog 1.2.0 from the image management page? If so this is already known about and fixed in SVN.[/quote]

Oh, thanks. This is getting better and better.

Hello

I just set up Fog in a test environment and love it thus far, especially after coming from a configuration fiasco of Opsi.

Passwords for different Fog users took a bit fiddling, but after that I was able to both tftp boot and upload and deploy an image without problems. Howerver there’s one thing that strikes me as odd - Image size displayed on Fog’s web gui shows as 2.x GB, while in the actual folder it’s around 9GB.

Don’t get me wrong, 9 is a great number, but it would still be nice to see the right figures on gui.