@cleric.marcos Lets understand what you are doing before you jump and do something. This may avoid a lot of extra work for you.
If you manage the local dhcp server, can you change/set dhcp options 66 and 67?
@cleric.marcos Lets understand what you are doing before you jump and do something. This may avoid a lot of extra work for you.
If you manage the local dhcp server, can you change/set dhcp options 66 and 67?
Please stick with me, but I don’t know version 3511??
Is that FOG 1.2.0 or a trunk version of FOG?
The question more on point, what version of the FOS engine are you using (bzImage). My intuition is telling me you are using an old version of FOG/FOS and it doesn’t have the drivers required for that new hardware.
FWIW: FOG 1.3.4 (stable) is SVN 6066.
@dws88 Yes if its a clean install. When you run the installer script for the first time it will ask you for the interface to use (it will default to the first found network interface - eno1). Make sure you pick eno2 there. It will also ask you about the dhcp server, and you only want to bind it to eno2.
If you are going to do a clean install, I also suggest that you jump straight to 1.3.5RC13 or RC14 which ever is current. That (dev) branch has quite a few fixes you will probably need.
@cleric.marcos OK I’m a bit lost where exactly we are in this thread. Because we’ve jumped around a bit.
I just want to reconfirm everything here.
This is currently what you have setup?
@michaeloberg Nice job. When you get to your new production fog server you will be in a better state to support new hardware and operating systems. Those NVMe disk are becoming more popular so you will have to migrate sooner or later. Plus the 1.3.x branch of fog is quite a bit faster with unicast deployments than 1.2.0 was. To get the faster deployment speeds you need to deploy a 1.2.0 image and then turn around and recapture it with 1.3.x. If you install the dev branch 1.3.5RC14 (at the time of this post) they have included a newer and faster compression/decompression function.
@IhaveNoIdea said in Help with school project:
And now i got another question, i have movable hard drive where i have installed linux and fog. The main hard drive in computer is win 7 and can fog clone it and make image off it?
If I understand this correctly, you have FOG running as a virtual machine on your windows computer. Are you asking if you can image the host windows computer with FOG, where fog is running inside the vm? The answer is no. You need fog running to be able to image, but the target computer (which is running fog in the VM) needs to be stopped for fog to image.
As for the second question. Yes you can save and load images for each student. If you can use ghost for this today, FOG will do the same thing for you tomorrow.
Secondly can i upload an image to fog management and use it as booting computers
I know where you want to go with this statement, but FOG is not a VDI solution. You can not directly boot a captured image with FOG, you must deploy it to target hardware then you can boot the image on that target hardware.
@cleric.marcos Yes for sure. You MUST change the iPXE boot file to undionly.kpxe for legacy (bios) hosts or ipxe.efi for uefi systems. Pxelinux.0 will cause the exact error message you are seeing. That image is old and only left in fog for a highly specific reason (which you don’t need).
@cleric.marcos for legacy/bios systems yes that is correct.
samaccountname is essentially the NT style account name.
According to the error message the search DN MyDN
(which I assume has been obfuscated) didn’t contain the user arparker
Make sure you have the search scope setup correctly of subtree and below
@cleric.marcos Wait, you never said you were running dnsmasq. We need all info or we make assumptions based on what we think you have.
Please post your dnsmasq configuration here.
@cajos001 I think I would be hard pressed to move back to 0.32 if you ever plan on supporting current hardware. I would surely explore how to improve the deployment process for these usb printers.
Can you tell us a bit more on how you deployed these printers last November? I assume these are local printers physically attached to these computers. How did you get the drivers installed on the hardware last November?
I am not speaking for the developers here, but you need to understand that the focus of FOG is very imaging built on opensource software and commodity hardware. PCI or what ever compliance you are trying to achieve is not in scope of the project. Depending on your compliance exposure you should be able to justify that FOG does not contain CC/HIPAA/Whatever
With that said if you take each of the audit observations in hand you can do certain mitigation steps.
In the case of NFS you can restrict access to the NFS shares by updating your exports config file. Here is the default exports. You can restrict who can mount the share by replacing the wild card star ( * ) with a CDIR network format.
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
would become
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev 192.168.2.0/255.255.255.0(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
To only allow hosts on the 192.168.2.0/24 subnet to access the NFS share for image uploading to the FOG server
As for FTP you can do something similar by using TCP Wrappers that use hosts.allow and hosts.deny to filter the vsftpd access.
tcp_wrappers=YES
vsftpd: ALL
vsftpd:192.168.2.0/24
That should restrict FTP server access to only subnets that will upload to FOG
As for the MYSQL server if you don’t have a storage node, then you can disable external access to MYSQL via the mysql config file or by setting up iptable rules as Wayne mentioned.
@kleanthis it would be interesting (again) to setup a debug deploy/capture to get access to the FOS engine command line. I’m suspecting that FOS is setting the eth0, eth1, eth2 order based on hardware discovery order, which seems to be inconsistent with what the iPXE kernel is doing.
@kleanthis Its simple. Just schedule another capture/deploy to the same target. Since you have LAN3 working use that interface. But before you submit the task select the check box that says debug.
This tells FOS to not start the task automatically but drop the user to a linux command line. This is what the developers use to debug the FOS engine.
@george1421 When you get to the FOS command line, if you give root a password, you can connect to the FOS engine via putty to help with any copy paste operations you need.
at the FOS command line key in ip addr show
to get the device’s IP address
then key in passwd
and give root a password. It doesn’t matter what password you give it, as long as its not blank. From there you can connect to the FOS engine using putty and login as root
and what ever password you give it. Then you can run the debugging commands from there.
Just be aware that IPMI is not the same a WOL. And not all servers support WOL and / or IPMI. For the R610, you either need to have the BMC programed to respond to IPMI commands or have a drac card installed to respond to IPMI. I have not personally tested to see if WOL actually works with a R6x0 system. I seem to remember something about it only working on eth0 (or the first built in network adapter).
To remove FOG from the equation, get a third party WOL program and see if you can wake up the R610 externally.
Solarwinds free WOL
http://www.solarwinds.com/free-tools/wake-on-lan
Or free version of Emco Wake on lan
https://wake-on-lan.net/
The key here is to first establish that you can’t wol these servers. I’m aware that some devices will respond to different magic packets, so that also comes into play.
It “might” be interesting to see if FOG could send ipmi messages at some point in the future, hint, hint…
@oraniko Did you install the FOG service in your reference image before you captured it?
Also be aware that when you add the fog service to the reference image, you set the service to disabled, syssprep, then capture the image, and then during OOBE setup the setupcomplete.cmd to re-enable the fog server. This way the fog service doesn’t start too early in the OOBE process.
Just for clarity, you created a new fog server then moved your images from old fog server to new fog server, but you can not see the images in the FOG management GUI?
If that is the case the move is 2 parts.
The image + metadata on new fog server will make everything right again. If you have FOG 1.2.0 (trunk) you can export the image definitions from the FOG management GUI and then import them into the new FOG server via the management gui on the new FOG server.
@NayanaAdassuriya The wiki page you referenced is for a very old version of FOG. What version of FOG are you trying to install?
There is a wiki for installing FOG on Centos 7: ps://wiki.fogproject.org/wiki/index.php?title=CentOS_7
@jc35 Now that I’m aware of what you are trying to do, then this post will give you the background: https://forums.fogproject.org/topic/6463/expose-fog-host-and-image-properties-to-post-install-scripts/10
In your fog post install script you need to add this code
. /usr/share/fog/lib/funcs.sh;
wget -q -U '' -O /tmp/hinfo.txt "http://<fog_server_IP>/fog/service/hostinfo.php?mac=$mac"
. /tmp/hinfo.txt
rm -f /tmp/hinfo.txt
Once you stat the hinfo.txt file ( . /tmp/hinfo.txt
) the following variables will be added to your postinstall bash shell.
$hostname == name of the host (should overwrite existing $hostname)
$hostdesc == Description of host
$imageosid == Operating System ID (should be the same as $osid)
$imagepath == The root path of the image(should also be the image name)
$hostusead == 1 or 0 to add host to AD
$hostaddomain == host domain name
$hostadou == host target ou
$hostproductkey == host product key
$primaryuser == Value from Primary User field
$othertag == Value from OtherTag field
$othertag1 == Value from OtherTag1 field
$location == Location Name from location plugin
$sysman == System Manufacturer from smbios
$sysproduct == System Product Name from smbios (from full registration)
$sysserial == System Serial Number from smbios (from full registration)
$mbman == Motherboard Manufacturer from smbios (from full registration)
$mbserial == Motherboard Serial Number from smbios (from full registration)
$mbasset == Motherboard Asset tag from smbios (from full registration)
$mbproductname == Motherboard Product Name from smbios (from full registration)
$caseman == Case Manufacturer from smbios (from full registration)
$caseserial == Case Serial Number from smbios (from full registration)
$caseasset == Case Asset tag from smbios (from full registration)
From there once you have these bash variables you can use them in your post install script. This document shows you what could be done with a post install script: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
more precisely you can use the variables with sed to replace settings in your unattend.xml file. Such as changing the computer name to what was collected from the hostinfo.php page.
sed -i -e "s#<ComputerName>\([^<][^<]*\)</ComputerName>#<ComputerName>$hostname</ComputerName>#gi" $unatendfile