You set the IP or FQDN of the FOG server when you install the FOG client. That is stored in a config file inside the FOG client install directory. I can’t remember the path off the top of my head but it’s something like C:\Program Files (x86)\FOG\etc\config.ini …or something like that.

Works great for me.
What does the C:\fog.log on the client say? Did you remember to encrypt the password with FOGCrypt? Are you using “domain/username” or just “username”? …etcetera, etcetaera.

[quote=“Corey Cochran, post: 4932, member: 1582”]Hi, I am having the same issues you have with only being able to multicast one client. I am not versed well in php. Can you send me a little more details about where in the file you inserted the address and maybe a screenshot.[/quote]

Er, how to make it clearer? Let’s say your FOG server’s IP address is 192.168.1.1. Udp-sender will use [B]232[/B].168.1.1 as the data address by default. Something like [B]239[/B] might work better on your network. You can test it from the command line with something like this on your FOG server: [CODE]udp-sender --file /opt/fog/log/multicast.log --ttl 32 --mcast-data-address 239.168.1.1 --min-receivers 2[/CODE] and the following on each of your two clients: [CODE]udp-receiver --mcast-rdv-address 192.168.1.1[/CODE]

IF that works, you could add the “–mcast-data-address 239.168.1.1” to all four udp-sender commands in [B]/opt/fog/service/common/lib/MulticastTask.class.php [/B]with whichever text editor makes you happy. The four modified lines will look something like this but, the only change was adding “–mcast-data-address 239.168.1.1”: [CODE]$cmd .= “gunzip -c “” . $strSys . “” | " . UPDSENDERPATH . " --min-receivers " . $this->getClientCount() . " --portbase " . $this->getPortBase() . " " . $interface . " --mcast-data-address 239.168.1.1 $wait --half-duplex --ttl 32 --nokbd;”;[/CODE]
Eventually I want to add some code to define the 239.168.1.1 dynamically (in case the server IP ever changes) instead of statically assigning it but, it’s pretty low on my list right now.

Yeah, the snapin agent is hard coded to wait 350-500 seconds in [B]fog_0.32/FOG Service/src/FOG_SnapinClient/MOD_SnapinClient.cs:[/B]
[CODE]126 try
127 {
128 Random r = new Random();
129 int intSleep = r.Next(350, 500);
130
131 log(MOD_NAME, “Sleeping for " + intSleep + " seconds.”);
132 System.Threading.Thread.Sleep(intSleep * 1000);
133 }[/CODE]
There’s a good posting on this at [URL=‘http://www.edugeek.net/forums/o-s-deployment/92417-how-modify-snapin-client-sleep-timer.html’]edugeek.net[/URL]

We had a problem with some Dell Optiplex 780’s that would hang at the following message after imaging:
[code]* Task complete, the computer will now restart
Restarting system[/code]
we fixed it by adding “[B]reboot=bios[/B]” as a kernel option in [B]Other Information -> FOG Settings -> General Settings -> FOG_KERNEL_ARGS[/B]
…If that’s the same issue you are having.

I vaguely recall some posts about certain versions of Windows ISO’s (Windows 7? XP?) not playing nice with PXE boot/memdisk when attempting to do what you are …but, I can’t seem to find 'em right now.

RAM …thats the memdisk part of the “[FONT=Consolas]kernel fog/dell/memdisk” line in [/FONT][SIZE=3]/tftpboot/pxeconfig.cfg/default from [/SIZE][FONT=Consolas]your linked example.[/FONT]

[FONT=Consolas]Also see [url]http://fogproject.org/forum/threads/how-to-modify-the-pxe-boot-menu-to-allow-the-booting-of-iso-files.154/[/url][/FONT]

[QUOTE]I think this is fixed in 0.33 code (revision 877) by looking at [URL=‘http://freeghost.svn.sourceforge.net/viewvc/freeghost/trunk/packages/web/management/includes/hosts.upload.include.php?revision=877&view=markup’][COLOR=#555555]http://freeghost.svn.sourceforge.ne…s.upload.include.php?revision=877&view=markup[/COLOR][/URL][/QUOTE]
Awesome! Thank you very much!

I’m not sure exactly what you mean on your second post but, line 48 in the 0.32 [URL=‘http://freeghost.svn.sourceforge.net/viewvc/freeghost/tags/0.32/packages/web/management/includes/hosts.upload.include.php?revision=877&view=markup’]hosts.upload.include.php[/URL] checks*, I think, that the ImageID is valid with this**:
[CODE]$img = $core->getImageManager()->getImageById( $data[5] );[/CODE] …but, it then does nothing with the [SIZE=4][FONT=sans-serif][COLOR=#19177c]$img[/COLOR][/FONT][/SIZE] variable e.g. it never assigns it to the host with out the line I added …or the far prettier method in 0.33.

• Also see [URL=‘http://freeghost.svn.sourceforge.net/viewvc/freeghost/tags/0.32/packages/web/lib/fog/ImageManager.class.php?revision=796&view=markup’]ImageManager.class.php[/URL]
  ** [SIZE=4][FONT=sans-serif][COLOR=#000000][COLOR=#19177c]$data[/COLOR][/COLOR][/FONT][/SIZE][SIZE=4][FONT=sans-serif][COLOR=#000000][[/COLOR][/FONT][/SIZE][SIZE=4][FONT=sans-serif][COLOR=#000000][COLOR=#666666]5[/COLOR][/COLOR][/FONT][/SIZE][SIZE=4][FONT=sans-serif][COLOR=#000000]][/COLOR][/FONT][/SIZE] is the Image ID in the CSV

FWIW, you could schedule a Disk Wipe and then an image deployment from the FOG manager.

When I upload a hosts CSV file such as this one:
[CODE]“DE:AD:BE:EF:CA:FE”,“myHostName”,“10.0.0.1”,“Test Host - Does not exist”,“5”,“6”[/CODE]
Based on the template:
[CODE]“MAC Address (ie: 00:11:22:33:44:55)","Hostname”,“IP Address”,“Description”,“Operating System ID”,“Image ID”[/CODE]
The [B]Image ID[/B], “6”, is ignored. Everything else loads up correctly but the [B]Host Image[/B] is blank.

It looks like this is a bug in [COLOR=#0000ff][B][FONT=Consolas]${webdirdest}/fog/management/includes/management/includes/hosts.upload.include.php[/FONT][/B][COLOR=#000000] which could be fixed by inserting the following line [U]below line 50[/U]:[/COLOR][/COLOR]
[CODE]$host->setImage( $img );[/CODE]

[B]Fixed Version[/B]
Here is lines 48-51 (Line numbers shown and with 51 being the new line) of [B][FONT=Consolas][COLOR=#0000ff]${webdirdest}/fog/management/includes/management/includes/hosts.upload.include.php [/COLOR][/FONT][/B]that would fix this problem:[CODE]48 $img = $core->getImageManager()->getImageById( $data[5] );
49 $mac = new MACAddress($data[0]);
50 $host = new Host(-1, $data[1], $data[3] . " “._(“Uploaded by batch import on”).” " . date(“F j, Y, g:i a”), $data[2], null, $mac, $data[4]);
51 $host->setImage( $img );[/CODE]

Not from FOG that I’ve found.
You can write a little shell script to update the mysql database automatically if you’d like. Here’s an extremely lame script off the top of my head that would associate every snapin with every host in the FOG database:
[CODE]#!/bin/bash

Store all host IDs

HOST_IDs=$(/usr/bin/mysql -u root -Dfog --batch --skip-column-names
-e “SELECT hostID FROM hosts;”)

Store all Snapin IDs

SNAPIN_IDs=$(/usr/bin/mysql -u root -Dfog --batch --skip-column-names
-e “SELECT sID FROM snapins;”)

Clear out any existing associations

/usr/bin/mysql -u root -Dfog --batch --skip-column-names
-e “TRUNCATE TABLE snapinAssoc;”

Add every snapin to every host

for HOST in $HOST_IDs
do
for SNAPIN in $SNAPIN_IDs
do
/usr/bin/mysql -u root -Dfog --batch --skip-column-names
-e “INSERT INTO snapinAssoc (saHostID, saSnapinID) VALUES($HOST, $SNAPIN);”
done
done[/CODE]

Ah, you didn’t want the script to update both config files - you just wanted a better warning.
You could change the following in fog_0.32/lib/ubuntu/functions.sh with whatever sounds good to you:
[CODE] 542 echo " We are about to install MySQL Server on “;
543 echo " this server, if MySQL isn’t installed already”;
544 echo " you will be prompted for a root password. If";
545 echo " you don’t leave it blank you will need to change";
546 echo " it in the config.php file located at:";
547 echo " “;
548 echo " ${webdirdest}/commons/config.php”;[/CODE]
Say, change “file” to “files” in line 546 insert another line below 548 listing the second config file.

…Although, it looks like the install script is supposed to update /opt/fog/service/etc/config.php so, in truth the only config file you have to update manually during install is ${webdirdest}/commons/config.php. So, the message is correct - it just would be better, IMO, if the script updated both files (or neither I suppose).

It looks like the images are defined in [COLOR=#ff0000]<[I]your_webroot[/I]>[/COLOR][B]/fog/mobile/includes/hosts.include.php[/B], [B]mainmenu.include.php[/B] and [B]tasks.include.php[/B] for the mobile site. You could just add the alt or title tags yourself if you know any html - you just need to escape the quote characters with backslashes to make 'em PHP happy e.g.

[B]Change lines like this from[/B] [CODE]<img src=“./images/force.png” border=0 class=“task” />[/CODE]
[B]To[/B] [CODE]<img src=“./images/force.png” border=0 class=“task” alt=“Force” />[/CODE]

A quick grep suggests that you’d only need to update it in 7 places.

Yeah, it would be so easy to fix:

Original fog_0.32/lib/ubuntu/functions.sh (with line numbers shown):
[CODE] 459 define( “MYSQL_HOST”, “localhost” );
460 define( “MYSQL_DATABASE”, “fog” );
461 define( “MYSQL_USERNAME”, “root” );
462 define( “MYSQL_PASSWORD”, “” );[/CODE]

Fixed fog_0.32/lib/ubuntu/functions.sh (with line numbers shown):
[CODE] 459 define( “MYSQL_HOST”, “${snmysqlhost}” );
460 define( “MYSQL_DATABASE”, “fog” );
461 define( “MYSQL_USERNAME”, “${snmysqluser}” );
462 define( “MYSQL_PASSWORD”, “${snmysqlpass}” );[/CODE]
…or something like that. I haven’t checked to make absolutely sure that those variables are defined when the configureHttpd() function s is called during install.

The same change should be made for fog_0.32/lib/redhat/functions.sh only on lines 433-436.

Can we submit a diff or anything to fix this? …Assuming it’s not fixed in 0.33 when it comes out.

I was playing with firewall rules and I could get this problem to happen if I blocked the “transfer ports” on the server:
[code]kernel: IPTABLES-DUMPED: IN=eth0 OUT= MAC=52:54:00:48:19:60:00:26:98:09:b5:c1:08:00 SRC=<CLIENT IP> DST=<SERVER IP> LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=39674 DF PROTO=TCP SPT=822 DPT=34044 WINDOW=14600 RES=0x00 SYN URGP=0[/code]

We just cancelled all the jobs and rebooted the clients. You could delete the [B]/tftboot/pxelinux.cfg/<MAC ADDRESS>[/B] file on the FOG server as well.

I saw that every once in awhile during FOG testing. I assumed it was from canceling a job (or any other FOG torture) as the client was rebooting e.g. the [B]/tftboot/pxelinux.cfg/<CLIENT MAC ADDRESS>[/B] file was deleted before the client had a chance to read the instructions.

[B]udp-sender[/B] automatically derives a multicast address from its own IP (by keeping the last 27 bits of the IP and then prepending 232). I would like to be able to change that address block from FOG.

232/8 is reserved as the Source Specific Multicast (SSM) Block and, in our case, was blocked by our WAN (see [URL=‘http://tools.ietf.org/html/rfc3171’]RFC-3171[/URL]). Our WAN folks could explain in great detail as to the hows and why and, judging by the forums, we are not the first people to come across this problem. This is frequently demonstrated by clients waiting forever to join a multicast and these kind of messages:
[code]# udp-sender --file /var/log/messages --ttl 32 --nokbd --min-receivers 2
Udp-sender 2007-12-28
Using mcast address 232.<LAST 3 OCTETS OF SERVER>
UDP sender for /var/log/messages at <SERVER IP> on eth0
Broadcasting control to 224.0.0.1
New connection from <CLIENT_0 IP> (#0) 00000009
New connection from <CLIENT_1 IP> (#1) 00000009
Starting transfer: 00000009
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
…[/code]

The 239/8 Administratively Scoped Block , on the other hand, works fine and is specifically reserved for private multicasts (see [URL=‘http://tools.ietf.org/html/rfc2365’][COLOR=#555555]RFC-2365[/COLOR][/URL]).

I dunno, say [B]Other Information -> FOG Settings -> Multicast Settings -> FOG_MULTICAST_DATA_BLOCK [/B] and, if defined, will add the [B]–mcast-data-address [/B]command line parameter to the[B] udp-sender [/B]command with the defined block and the last three octets of the server IP. …or you could dust define the entire address.

I suppose that adding an option to change the Broadcast Control address from 224.0.0.1 to something else with the [B]–mcast-rdv-address[/B] parameter on the sender would be nice too.

…not that trying to handle every possible UDPCast parameter is necessarily a good goal but, just a few more would be very helpfull.

[COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtmlhttp://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR][COLOR=#000000][FONT=arial] - [URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’]Cisco Guidelines for Enterprise IP Multicast Address Allocation[/URL][/FONT][/COLOR]

Ditto!

Ditto!