FOG, NFS and FTP



  • I have having troubles with FOG connecting to my NAS. I have created this thread here instead of FOG Problems, because I am curious as to how FOG works, and want to understand this before trying to fix my problems. I am relatively new to *nix, especially when dealing with permissions, and completely self taught. I have no one and nothing but the internet (and some books) to learn from. There is no one locally I can ask to clearify or explain some concept to me. Please excuse holes and lapses in my understanding.

    [U]My setup[/U]
    [LIST]
    []FOG Server - 192.168.15.72 - (dual core Xeon, 2GB RAM, 500GB HDDs in RAID 1) - Ubuntu 11.04 (natty)
    [
    ]FreeNAS Server - 192.168.15.15 - (quad core Xeon, 24GB RAM, 62TB HDDs in RAIDZ1) - 8.3.1-RELEASE-p2-x64
    [
    ]Cat5e patch cables
    []24 port unmanaged Gigabit switch
    [
    ]Client machines
    [/LIST]

    No AD, no DNS, no internet, nothing else connected.

    FOG Server handles for the network DHCP and TFTP.
    FreeNAS has a NFS share with NFS and FTP services running.

    There is a mount for FreeNAS into the /images directory. /images and /images/dev are owned by fog:root, with full user/group/other permissions. My goal is to make this as open as possible until I understand it and narrow the permissions down later for security.

    I can see FreeNAS mounted in my file system on the Ubuntu server. I can read and write to this directory. I can register a host, and create an image. The image successfully moves from /images/dev to /images and is renamed with the image name. I can even deploy to that unit/MAC address with no trouble.

    My problem comes into play when I try to image the unit with Capone. For those that have not read about Capone, it is a supported plugin that removes the need for the client to have a MAC address when deploying an image. Instead, it pulls DMI data from the client computer and matches that to definitions that are set within the plugin. This plugin is essential to what I am using FOG for. When I try to image a computer using the Capone plugin, the system fails to mount the NFS share. For clarity, I am posting in the code below, the output on the client machine. For reference, this is an IBM T400 with Windows 7, imaged as multiple partition, single disk. The DMI key used in 6475MC2, which is shared across this model.

    [code]* Loading Capone…

    • Looking up DMI field…Done

    • Using Key Value: 6475MC2

    • Looking for images…Done
      ID 1) OS: Windows 7 Image: IBMT400

    • Setting up environment to deploy image…

    • Checking Operating System…Windows 7

    • Checking CPU Cores…2

    • Send method…NFS

    • Mounting File System…Failed

    • mount: mounting 192.168.15.72/images on /images failed: No such file or directory

    Error during failure notification: Unable to find a valid task ID or host ID based on the clients mac address of : 00:00:00:00:00:00
    Unable to find a valid task ID or host ID based on the clients mac address of: 00:00:00:00:00:00
    [/code]
    Note, that I can deploy an image to this machine with no trouble if I do it as a task within the FOG management console.

    All this leads me to the questions of;
    [LIST]
    []How does FOG connect to a separate NFS and FTP server?
    [
    ]What user/group does it assign to a client so that it can talk to the system?
    []How does FOG manage NFS shares and FTP access?
    [
    ]How is the data for creating an image routed, does each bit move through the FOG server, or does it hand the connection off to the client and NFS?
    []Is this different from when it deploys an image?
    [
    ]How does deploying with Capone change that?
    [*]Capone seems to assign a MAC address of 00:00:00:00:00:00, how does this affect the ability of FOG to deploy?
    [/LIST]
    If there are any Capone/FOG experts out there, I would love to hear any additional notable nuggets of information that I missed as well.



  • So I figured it out. Capone adds an option to the PXE boot menu, which is great, but my menu is not stock, and the automatic entry it adds was failing. Fix that and it boots fine.

    So, it is possible to set Capone to use a different NFS/TFTP/Web server if you want to. The script calls on what is defined in the PXE boot option, not what FOG uses for settings.



  • I believe that the Capone script is finishing as it should, because it looks like it runs the fog script at the end, “fog”.

    Opening up the fog script, I tried to read through it following along with what the client outputs on the screen and got to Line 122

    [code]echo -n " * Mount File System…";
    mkdir /images $debugstring 2>/dev/null;
    mount -o nolock, proto=tcp $storage /images 2>/tmp/mntfail
    mntRet="$?";
    if [ ! “$mntRet” = “0” ]
    then
    blame=wget -q -0 - "http://${web}service/blame.php?mac=$mac" 2>/dev/null
    if [ ! “$blame” = “##” ]
    then
    echo “Failed”;
    echo “”;
    echo -n " * ";
    cat /tmp/mntfail
    echo “”;
    echo “Error during failure notification: $blame”;[/code]

    And so on.

    The mount is failing. What makes Capone deploy differently? The mount should be the same. It loads and selects an image, then loads the FOG script. I don’t understand why it would work through task management but not through Capone…

    Anyone know what tmp/mntfail is referring to?


  • Developer

    I wish I could help :( I hope someone who does understand Capone and uses it steps in, good luck!



  • You are correct in me not wanting to use MAC addresses. The goal is to plug a computer in, have Capone decide which image to send, and push it as fast as possible. Then move onto the next unit. Registration is not used at all in my deployment. Only to create the master image.

    I’m running into such confusion because I know Capone works, and well, as I have tested it with the previous build of this system. That was when the FOG server controlled everything though. There is some hiccup between the FOG server, client and/or FreeNAS system during deployment, which leads me to believe that the hand off is different, or Capone changes the way it works.

    There is such great documentation on FOG and FreeNAS, but only a few lines for Capone, and I can’t seem to find anyone else who uses it…

    EDIT:

    I found the script for Capone. I don’t know bash(?), I can’t read the script beyond the general idea of what it does. The script is wherever fog was extracted then
    [code]fog_0.32/src/buildroot/package/customize/fog/scripts/bin/fog.capone[/code]

    The script runs almost to the end, I pasted the from last echo that shows on the client machine to the end of the script.

    [code]echo " * Setting up environment to deploy image…";
    export type=down
    export mac = “00:00:00:00:00:00”; #Not important for Capone
    export img;
    export osid;
    export imgType;
    sleep 2;

    clearScreen;
    fog[/code]


  • Developer

    From my little understanding your problem is coming from the fact that you don’t want to use the mac address to image with.

    FOG creates a file based on the mac address of the unit. The unit boots, it looks on the server for it’s file if it finds it then it goes on about it’s business with FOG, if not then it proceeds to boot from the next specified device.

    Take a look at this below from: [url]http://www.fogproject.org/wiki/index.php?title=FOGUserGuide[/url] abotu half way down the page, I hope this clears up some questions you were asking, sorry I can’t be of more service to you, we do not use Capone and I am not familiar with it :(

    [SIZE=4][B][FONT=sans-serif][SIZE=17px][COLOR=#000000]Tips[/COLOR][/SIZE][/FONT][/B][/SIZE]

    [LIST=1]
    []FOG requires that all hosts be entered in the FOG Database for imaging. [B]The most important part is getting the MAC address of the host right[/B]. [B]FOG uses the MAC for targeting image installs and acquires[/B]. [B]Using the wrong MAC could result in unpredictable results, including the complete erasure of the wrong pc[/B]! The IP address isn’t that important, and the ‘name’ field is more for the user. Mac address format is 00:12:3F:C4:57:0C . Using dashes, spaces, or no items at all will result in the GUI not accepting the host.
    [
    ]After hosts are entered, it is wise to group them together by function, hardware, or common image. The image will be shared among all members of a particular group. This occurs within the ‘hosts’ screen, and NOT on the groups screen. This is a little confusing, so it helps to think of the ‘groups’ screen as a task generator, rather than controlling group memberships.
    []For importing hosts in a .csv file follow the format below: 1 line per host:
    [FONT=monospace]“00:c0:4f:18:62:63”,“Hostname”,“1.1.1.1”,“Your description”,“XP/Vista”,“Image filename to use”[/FONT]
    [
    ]Hosts are then configured to boot via PXE boot by going into the BIOS. Make sure PXE boot is the FIRST option, NOT the hard disk, or things won’t work.
    [*]Configure your ‘master’ pc for the first image. Probably a good idea to run ‘[URL=‘http://support.microsoft.com/kb/302577’][COLOR=#3366bb]sysprep[/COLOR][/URL]’ prior to imaging, but not necessary. Sysprep will make your imaging life easier, if hardware is different, etc. See Microsoft.com for more details on using sysprep.
    [/LIST]

    but then further down the page I see

    [SIZE=5][B][FONT=sans-serif][SIZE=19px][COLOR=#000000]FOG Plugins[/COLOR][/SIZE][/FONT][/B][/SIZE]

    [FONT=sans-serif][COLOR=#000000]Plugins enhance FOG’s functionality.[/COLOR][/FONT]
    [LIST]
    [*]The Capone plugin allows FOG to recognize similar hardware platforms and push your specified image to them with minimal (or no) interaction.
    [/LIST]
    [FONT=sans-serif][COLOR=#000000]See [URL=‘http://www.fogproject.org/wiki/index.php/Plugins’][COLOR=#5a3696]Plugins[/COLOR][/URL] to activate and manage plugins.[/COLOR][/FONT]
    [FONT=sans-serif][COLOR=#000000] [/COLOR][/FONT]
    [FONT=sans-serif][COLOR=#000000]so I have no clue :)[/COLOR][/FONT]


Log in to reply
 

394
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.