Posts made by george1421

In this part we’ll install dnsmasq to augment the information being supplied by the local dhcp server. In many smaller or home locations the dhcp servers that are in use are soho routers that supply internet access as well as dhcp and dns forwarding to the local lan. These soho routers provide the basics of dhcp without the ability to modify some of the dhcp options required for pxe booting. Also if we are using our Pi as a mobile FOG server we can’t rely on the foreign network to have the facilities to support our pxe booting requirements. To that end we will install dnsmasq on our Pi to allow us to manage and supply the missing dhcp information.

To install and configure dnsmasq please do the following.

1. Login into the Pi console either directly or via ssh.
2. Ensure we have the latest apt cache information and then install dnsmasq
   sudo apt-get update
sudo apt-get install dnsmasq
3. Now we need to configure our FOG dhcp settings in dnsmasq. Lets create the following file with our favorite text editor.
   sudo vi /etc/dnsmasq.d/ltsp.conf
4. Insert the following section into the ltsp.conf file.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly

# UEFI is not supported in this version of dnsmasq if it were you 
# could uncomment the following line and the ipxe kernel would be delivered
# to uefi clients automatically
#pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe

dhcp-range=<fog_server_ip>,proxy

5. Edit the above text replacing <fog_server_ip> with the IP address of your FOG-Pi server.
6. Save and exit the text editor
7. The dnsmasq group has made pretty good strides with updating dnsmasq to support uefi systems. Unfortunately most linux distributions have not been updated to the latest code released by Simon Kelley. The version of dnsmasq from the Raspbian site is version 2.72 (which is in line with what Debian Jessie ships). The version of dnsmasq that supports uefi systems is 2.76. You must upgrade to 2.76 to support uefi pxe booting. This is not a limitation of FOG but of the version of dnsmasq offered by distribution repositories.
8. Now we need to create a symbolic link between the name that dnsmasq sends out and our iPXE kernel. I like to use symbolic links instead of just creating a static copy of these iPXE kernels. This way (with the symbolic link) if the iPXE kernel files get updated so will the files named by dnsmasq.
   sudo ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
sudo ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0
9. Since Debian Jessie is a sysemd based we need to use systemctl to restart and enable the dnsmasq service.
   sudo systemctl restart dnsmasq.service
sudo systemctl enable dnsmasq.service
10. To confirm dnsmasq is running in memory we can use the ps command
    ps aux|grep dnsmasq
11. The output of the above command should look similar to this:

dnsmasq   6340  0.0  0.1   6296  1436 ?        S    19:31   0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
pi        6534  0.0  0.2   4276  1948 pts/0    S+   19:32   0:00

12. We can also confirm that dnsmasq is listening for proxy dhcp requests by running the following command
    netstat -an|grep 4011
13. The output should look like this

udp        0      0 0.0.0.0:4011            0.0.0.0:*

Now that we’ve confirm that dnsmasq is setup and litening its time to pxe boot our first bios (legacy client)

Things still to document

1. Integration of Wayne’s mobile fog scripts
2. Performance testing as it were

(place holder)

(place holder)

Let me preface this with the following: Just because you can do something, it doesn’t mean you should.

I’ll repeat that again: Just because you can do something, it doesn't mean you should.

Please understand installing FOG on a Raspberry Pi is NOT recommended by the Developers of FOG. If you ask them for help they will only smile politely and tell you to move on, what you are doing is not supported. So don't ask them for help.

I’ve wanted to for a while see if I could install fog on a Raspberry Pi. In my case I have a Raspberry Pi that my brother gave me. It is currently running my home voip PBX. I took it down for a bit to prove this project out. If I was to build a FOG-Pi mobile deployment server I would not use the Pi-2b that I currently have. This system has an OK processor but the network interface is 100Mb/s, which will clamp my overall throughput to 12MB/s. If given a choice I would use a Pi3 for the demo project. An $80 complete mobile FOG deployment server does have its allure.

But in reality given a choice I would not use a Raspberry Pi, I would use a dual core Intel NUC with an built in SSD drive for about $280USD. Because of the scope of this project we’ll stick with a Pi2b.

In addition to the Raspberry Pi you will need to pick up a decent micro SD card that will be used for storage. Depending on the size of your images a 32GB Samsung EVO Class 10 costs about $12USD from amazon. A 64GB EVO will cost you about $20USD from Amazon.

For this project I used Raspbian Jessie downloaded from the official Raspberry Pi site: https://www.raspberrypi.org/downloads/raspbian/

Follow the instructions on the following page to write the downloaded image file onto the micro sd card: https://www.raspberrypi.org/documentation/installation/installing-images/README.md

After the image as been written to the micro sd card, move the card to the Pi and boot it up. You can either use the console to key in the remaining commands or you can use ssh and remote into the Pi once you determine its IP address.

Before we start installing FOG, we need to execute a few steps to prepare the Pi.

1. Run the Raspbain configuration tool sudo raspi-config
2. Change these settings:

1) expand filesystem to fill the storage device
2) Change user password
3) Boot options B1
5) Internationalisation Options I1 *uncheck en_GB.UTF-8) check en_US.UTF-8 -> UTF-8 
5) Internationalisation Options T2 Timezone
5) Internationalisation Options T3 Keyboard layout 
9) Advanced Options A2 Hostname

3. Reboot the Pi
   reboot
4. Log back in
5. Update the Raspbian apt cache
   sudo apt-get update
6. Install all of the current updates
   sudo apt full-upgrade
7. By default Raspbian will boot into graphical mode. Since there is only 1GB of memory we need to conserve as much ram as possible. Execute the follow command to tell the Pi to boot into console mode.
   sudo systemctl set-default multi-user.target
8. Reboot the Pi again to use the latest kernel and to boot into console mode.
   reboot
9. The following directory is missing from the default Raspbian install that FOG uses, so we’ll create it so the installer doesn’t complain.
   sudo mkdir /usr/lib/systemd/system
10. Now we need to install a couple default packages not installed by Raspbian by default
    sudo apt-get update sudo apt-get install git bc
11. Now install FOG from the git repository
    sudo git clone https://github.com/FOGProject/fogproject.git /opt/fogproject

For NVMe drives you MUST use either 1.2.0-trunk (which doesn’t exist any more) or 1.3.0-RCx series. FOG 1.2.0 doesn’t understand the NVMe disk naming structure (nvme0n1p1) properly. This is outside the use of the kernel this is actually the changed in the code on the virtual hard drive (init.xz). And you can’t use the new kenrel and the new inits with fog 1.2.0 stable.

The issue is 1.2.0 only understand the older disk structure of /dev/sdX1 and it used the alpha parts to defined the disk and the number parts to define the partition. The NVMe disks broke that logic. Because there are numbers as part of the disk identifier so the internal logic broke down. The developers worked on this issue for several weeks to get it fixed in the trunk build.

@Wayne-Workman There is a command line utility for configuring the network adapter too. I just can’t remember it off the top of my head. I typically just brute force change the setting in the /etc/sysconf/network-scripts directory to what I want. But the cli menu program works pretty good too.

[edit] its nmtui and here is a howto http://www.krizna.com/centos/setup-network-centos-7/

I can tell you that fog is not a build on your own project. I understand moving from the windows world to the linux world is a bit like moving to a remote country and trying to understand the language. I can say the last time I installed FOG it ran pretty smoothly. I’m going to spin up a new centos 7.2 instance in my lab to confirm that the installer still works as expected. With both Ubuntu 14.04 and Centos 7 the install should be smooth and solid.

Ok lets first remove the obvious. This issue has nothing to do with the iPXE kernel files (undionly.kpxe). The FOS Engine (the linux OS that captures and deploys images on the target computer) is making it to the target computer because you are able to run the compatibility test which is built into the FOS Engine.

The issue is with FOS engine not having the current drivers for your hardware. What kernels (versions) have you tried. Just recently the developers have made the current kernels (v4.7.x) compatible with the older version of FOG. There was a gap between 4.3.x and 4.6.x where those newer kernels were not compatible with FOG 1.2.0 stable. I can say I ran FOG 1.2.0-trunk and now 1.3.0-rcX series and that network adapter is supported.

If you were running fog 1.3 or the 1.2.0 trunk release I would ask you to manually register that computer then schedule a debug capture of that computer. I think fog 1.2.0 had this but you had to access it via the advanced menu on the host registration page (stated from memory). Then you pxe boot that target computer. The FOS engine should be transferred to the target computer and then display some instructions on the screen. After several presses of the enter key it should drop you to a command prompt. From there we can start debugging.

One last thing I can think of is if your building switch has spanning tree turned on you must use one of the fast STP protocols like (fast stp, rstp, or port fast). As the target computer boots it winks (momentarily drops the network link) as the iPXE kernel (undionly) hands over control to the FOS Engine. This momentary wink causes spanning tree to not forward data for 27 seconds. By the time spanning tree starts to forward data the FOS Engine has already given up. A quick check to see if this is a spanning tree issue is to place a unmanaged switch between the building switch and the booting target computer. The unmanaged switch will keep the building switch port from winking as the FOS Engine starts.

Here is a screen shot of what is expected.

@JJ-Fullmer The documentation hasn’t been written just yet because our approach changed overnight. Let me refresh my server and I’ll post something here to get you started. I can’t guarantee it works until I update my server and test it.

@JJ-Fullmer I’m not sure I fully understand your question.

In rc11 it may or may not show the bind dn just yet. That code is in a state of flux a bit.

But in general we will switch over to using a bind DN (which needs to be in full ldap format) to initially connect to the ldap server to look up the user’s cn (in full ldap format). We were using just the short form of the user’s credentials (user@domain.com) to bind to ldap, but that only appears to work reliably with AD.

Tom and (or at least I) will have another coding session tonight to see if we can get this wrapped up. All of the parts work independently now we just need to get them to work together.

@zingaro The key is to have the ftp user home directory set up to the images folder root.

I did write a proof of concept tutorial on how to make a windows server storage node for FOG. It doesn’t directly relate to your buffalo device, but you can draw some parallels between the two. https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog

@Quazz said in Force Windows Update once image loaded:

@george1421 Wouldn’t it be better to let WSUS take care of the rebooting, since it sometimes needs to reboot in before it can install other updates?

IMO The best choice is to use WSUS for windows updates.

If you can’t use WSUS for some reason then an opensource group (similar to the FOG Project) created a utility called “WSUS Offline” that will download updates from M$ and cache them in a directory for you. Then you can run a second cmd file to install the software on the target computers. It is a pretty nice tool. I use it as a source for slipstreaming windows updates into the master windows wim file.

But you are right too, some updates can only be applied before you must reboot the computer for the next round to be installed. We rebuild our master image once a quarter with the latest updates then post deployment there are only a few updates that is needed to be pushed out by wsus.

@ABane OK now that I had my first cup of coffee I can see where I misunderstood.

In your case, I would use the wsus server if you have it.

If you don’t have it you can use wsus off-line and the first run section of your unattend.xml file. You will have to configure your unattend.xml file to log in as a workstation administrator ( 1 ) time to run the first run commands. But then you can connect to the remote share where wsus offline is stored and run the cmd file. Once wsus offline completes then issue a shutdown.exe -r -t 10 to reboot the computer and it will be fully updated.

In my tutorial I linked below this is the order of command execution

initrd http://<fog_server_ip>/isoimg/LiteTouchPE_x86.iso
chain memdisk iso raw

Also make sure permission on the file is world readable.

@x23piracy If that is the case, then the OP should setup a WSUS server then windows updates will be deployed automatically.

There is another option is to use a tool called wsus offline. http://download.wsusoffline.net/ WSUS Offline can be run from a command prompt against a network share. The OP would refresh the repository once a month and then deploy a FOG snapin that would call the wsus offline installer to update the windows updates on the target computers.

I can say in my environment I use Microsoft MDT to create my reference image using the lite touch method. Then I sysprep the image, capture with FOG, and then deploy from FOG. With FOG deployment once I start the deployment I don’t touch the workstation until the install is done and its ready to move to the user’s work site. This system is fully configured with all applications and settings. It took me about 2 weeks to perfect this process using a combination of Microsoft and FOG technology to complete.

Typically you would install windows updates, .exes, packages, etc in your reference image before you captured it into FOG. But there are ways to do this post image install too. If you sysprep your reference image there is a windows batch file you can create called setupcomplete.cmd where you can call scripts. This batch file is executed after oobe is complete and just before the login window appears for the first time. This is a function of windows and not FOG.

There is also a second place where you can place commands to execute. If you again sysprep your reference image and use an unattend.xml file you can tell windows to log in as an administrator and execute a first run section of your unattend.xml file.

There is a third way to install applications (the FOG way), is to create snapins which are software packages that are called and installed post imaging from FOG. These snapins deliver the install packages to the target computers and then call the application silent installers to install the applications.

Progress is going very well with the ldap plugin. But we found that when we start bringing in other ldap serves to test, some of the shortcuts that worked for M$ did not work so well with other ldap servers. To that end, I wrote another proof of concept code using the long way to get a user’s ldap attributes. In this method I have to use an authorized read only user to query the ldap server to locate the user’s ldap account, then I use that ldap account to relogin to the ldap server to pick up the user’s group associations.

<?php

    // the user we are going to authenticate
    $user = 'user1234';
    $pass = 'Password';

    // IP address or fqdn of ldap server
    $server = '192.168.1.5';

    // credentials that have read access to the LDAP server
    $bindDN = 'cn=Bob Jones,ou=Users,ou=nyc,dc=domain,dc=com';
    $bindPass = 'Password.2';

    // How deep in ldap from search base are we going to look for the user
    $searchScope = 2;

        // clean up user name we only want the user's short name without any domain component
        // note I did not try to understand the regex expression but I expect there to be
        // issues with non-us english characters, just saying.
        $user = trim(preg_replace('/[^a-zA-Z0-9\-\_@\.]/', '', $user));

        // open connection to the server
        $ldapconn = ldap_connect($server,389);
        ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3);
        ldap_set_option($ldapconn, LDAP_OPT_REFERRALS, 0);

        $accessLevel = 0;
        $userSearchDN = 'ou=nyc,dc=domain,dc=com';
        $adminGroup = 'FoG_Admins';
        $userGroup = 'FOG_Users';
        $grpMemberAttr = strtolower('memberOf');

        if ( ldap_bind($ldapconn, $bindDN, $bindPass) ) {
            // for the filter we are searching for a person with an NT style account like the contents of $user
            $filter = sprintf('(&(objectCategory=inetOrgPerson)(%s=%s))', 'sAMAccountName', $user);

            // we want to return the user's DN so that we can bind as the user
            // we will get his DN based on his samaccountname for AD
            $attr = array( 'dn' );

            switch ($searchScope) {
                case 1:
                    // LDAP_SCOPE_ONELEVEL search one level down but not base
                    $result = ldap_list($ldapconn, $userSearchDN, $filter, $attr);
                    break;
                case 2:
                    // LDAP_SCOPE_SUBTREE search base + all subtree (OUs) below
                    $result = ldap_search($ldapconn, $userSearchDN, $filter, $attr);
                    break;
                default:
                    // LDAP_SCOPE_BASE search base only and don't look any deeper
                    $result = ldap_read($ldapconn, $userSearchDN, $filter, $attr);
            }

            // count the number of entries returned
            $retcount = ldap_count_entries($ldapconn, $result);

            if ($retcount == 1) {
                // great we only returned one entry
                $entries = ldap_get_entries($ldapconn, $result);
                // pull out the user dn from the entries
                $userDN = $entries[0]['dn'];
            } else {
                $userDN = '';
            }

        }

        // if user dn is populated then attempt to connect (bind) to ldap as user
        if (!$userDN =='') {
            // Now rebind as the user we just found
            if ( ldap_bind($ldapconn, $userDN, $pass) ) {
                // If we get to here the user is authorized, now lets get the group membership

                // This time since we know the user DN (fully qualified ldap path) we can look up the user based on that
                // this filter just matches all objects (cheat)
                $filter = '(objectclass=*)';

                // get what groups this user is a member of
                $attr = array( $grpMemberAttr );
                
                // read in the attributes of this user
                $result = ldap_read($ldapconn, $userDN, $filter, $attr);


                // count the number of entries returned
                $retcount = ldap_count_entries($ldapconn, $result);

                if ($retcount > 0) {
                    $entries = ldap_get_entries($ldapconn, $result);

                    // check groups for membership
                    foreach($entries[0][$grpMemberAttr] as $grps) {
                        // is admin user, set level and break loop
                        if(strpos( $grps, $adminGroup )) { $accessLevel = 2; break; }

                       // is user, set level and keep looking just incase user is in both groups
                       if(strpos( $grps, $userGroup )) $accessLevel = 1;
                   }
                }

                // close our connection as bindDN
                ldap_unbind( $ldapconn );

                echo $accessLevel;

            } else {
                print 'unable to bind using user info, user is not authorized in ldap';

            }
     } else {
          echo 'User not found in LDAP';
     }
 ?>