@x23piracy Are you currently using ldap authentication today? I think I found a good example code that I can upgrade the bits in the plugin. I just want to make sure the upgraded bits don’t break what you are using.
Posts made by george1421
-
RE: LDAP Plugins in FOG 1.3.0 RC 8
-
RE: Modifying Boot Menu
@mbarker Ok the next step is to ensure that we have the proper boot kernels.
https://fogproject.org/inits/init.xz
https://fogproject.org/inits/init_32.xz
https://fogproject.org/kernels/bzImage
https://fogproject.org/kernels/bzImage32These links will download the latest (current) kernel and inits. They go in /var/www/html/fog/service/ipxe
Also when ipxe loads there is a version number and a hex number in parentheses, what is that hex number.
Just for clarity what device are you trying to pxe boot into fog? Is it configured for uefi or bios (legacy) mode?
I feel you have the dnsmasq part setup right now so we can rule that out as long as you have your links correct as I have defined them in the tutorial.
-
RE: Modifying Boot Menu
@mbarker Yeah, I would review my config file when you have a chance, but this line jumped out at me right way.
dhcp-boot=undionly.kpxe,,<fog_server_IP>
The fog server IP address should appear twice in your config file, you missed this one.
-
RE: Modifying Boot Menu
I wrote a tutorial a while ago about my experience with dnsmasq. I did not follow the one from the official fog wiki page but arrived at a working solution. In my case I did this with my home kit using my home firewall as the dhcp server and the fog server running dnsmasq. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7
The efi section of my dnsmasq config file will only work if you are running the lastest dnsmasq.Since then the dnsmasq group (not FOG) made upgrades to dnsmasq so that dnsmasq will deliver the proper boot file (undionly/ipxe.efi) depending on the computer asking for dhcp proxy info. This version of dnsmasq hasn’t made it into the linux distribution chains just yet. But right now you need to walk before you run.
-
RE: Modifying Boot Menu
@mbarker dude, I said not to use pxelinux.0
Is this what you created the sym links to?
I have some paperwork (sorry real job) to take care of but I’ll be back soon to dig a bit deeper.
-
RE: Modifying Boot Menu
@mbarker said in Modifying Boot Menu:
I tried with both the 32 bit and the 64 bit version of bzImage/init.zx and the same error still comes up.
This concerns and confuses me a bit. You should not have to mess with these files. I’m going to recommend that you go back to the 1.3.0 files that you downloaded and rerun the bin/installfog.sh install script again to resync everything.
Also please post your config file from dnsmasq, again the only time I’ve see this get messed up is when the kernel doesn’t match the vhd file or pxelinux.0 or an old version of iPXE is being used.
And your symbolic links are to the current ipxe files of undionly.kpxe and ipxe.efi? The dnsmasq program always tags a .0 (dot zero) on the end.
-
RE: Modifying Boot Menu
@george1421 said in Modifying Boot Menu:
Now when you select a iPXE menu item it then “should” transfer the bzImage (kernel) and init.zx (the virtual hard drive) to the target computer. That error message you posted is the kernel not understanding the format of the virtual hard drive.
You have to understand that imaging with FOG is a complex dance between 4 different technologies and you went to hard mode right away. This does work we just need to identify what happened.
edit: The bzImage and init.zx are the 64 bit images and bzImage32 and init32.xz are the 32 bit images they are a match pair. If somehow these pairings got messed up it would create the error you posted too.
-
RE: Modifying Boot Menu
@mbarker Well I can say you jumped right into a complex issue where you don’t have access to the dhcp server and are trying proxy dhcp.
Just browsing through the dnsmasq log everything looks great. Default ipxe should be the product. The results should be the fog iPXE menu from this. The undionly.kpxe is the iPXE kernel that gets loaded onto the target computer. What you should see from there should be the fog ipxe menu.
-
RE: Modifying Boot Menu
@mbarker said in Modifying Boot Menu:
…this is an x64 system, but I can’t find in the menu setups where to change to init32.xz (if I remember the documentation correctly, that should be used on x64 systems)
Just for clarity the iPXE menu determines what kernel to send to the target computer. You can force a specific kernel if you manually register the host, but in general the iPXE kernel will decide what the target needs and send the right FOS Engine kernel/vhd pair to the target.
-
RE: Modifying Boot Menu
@mbarker OK so you are using FOG 1.3.0-RCx series and dnsmasq, what are you ending out for dhcp option 67? You have to remember that there are two different pxe boot kernels one for bios (legacy) and one for uefi. You need to ensure you send the right file to the target computer.
Your error almost sounds like you are either sending an old syslinux kernel or an old iPXE kernel to the target computer. You should NOT be sending pxelinux.0 to the target computer. Use undionly.kpxe or ipxe.efi
-
RE: DHCP Timeout after Linux begins to boot
@2cool4me4 put an unmanaged (dumb) switch between the building switch and the target computer.
-
RE: Modifying Boot Menu
@mbarker said in Modifying Boot Menu:
Are the phones and target systems in the same subnet? If they are on different subnets then you can just create different scopes for each subnet.
For your clients, what is their dhcp server? If its server 2012 there are a few more options you can use.
Lastly you can setup a usb boot option, but that adds an additional layer of complexity.
-
RE: DHCP Timeout after Linux begins to boot
You can have spanning tree enabled (and should), but you need to enable one of the fast stp protocols (port fast, fast stp, rstp, and a few others I can’t remember). Standard spanning tree takes 27 seconds to start to forward data while it listens for other infrastructure devices.
And yes (depending on what version of fog you’re running the boot process has changed greatly).
-
RE: Add Wifi Mac Adress to existing laptop
@adukes40 yes you can have more than one. Just keep the kernel parameters stuck together
pci=noacpi
and then a space between the kernel parameterspci=noacpi video=vga magic=tom
and so on. -
RE: Fog Config File
@jflanagin In your case since you have a 100MB pipe between the remote sites and your HQ and you only have a few hundred computers the best way to set this up is to use a full FOG server at HQ and then FOG Storage nodes at each location. Then within the FOG Master node (at HQ) you will install the location plugin. Then with the location plugin create 4 locations and assign a storage node to that location. Configure the dhcp server at each location to send dhcp 66 and 67 to the local storage node. Your images (that can only be captured on the FOG master node at HQ) will automatically replicate to each storage node. If you update an image at HQ it will automatically replicate to all storage nodes in the same storage group. You will probably want to change the fog client check in interval to be something like 15 minutes or more from the default 5 minute check in to reduce wan traffic. This way there is only one fog server and no need to mess with the FOG config file on the target computers.
-
RE: Add Wifi Mac Adress to existing laptop
I don’t have an immediate answer for you but a few comments.
-
It would be interesting to know if (now) you pxe boot one these systems and run through full registration, would it add the wifi mac address?
-
Its interesting that deploy a printer uses the mac address at all. I would expect it to use either the hostname or the hostid when deploying to the target computers.
-
As for the
pci=noacpi
if it was me (being the lazy person i am) I would have updated the global kernel arg setting with this value, then registered all of these systems with the normal process. Actually you can probably leave that setting in the global kernel boot settings for all systems. It shouldn’t (just guessing) have any impact on other models, since this kernel switch is disabling acpi that seems to be broken on this 40 dell laptops. I would test this, but it would probably be safe to leave it in, or leave it in while you are registering these systems then use the fog group function to deploy this settings to the specific hosts that require it. Then remove it from the global kernel args.
-
-
RE: LDAP Plugins in FOG 1.3.0 RC 8
I’ve started a feature request here to document the process of reviewing the current LDAP plugin.
https://forums.fogproject.org/topic/8575/extend-ldap-plugin-to-support-ad-authenticationAfter reviewing the current ldap plugin there are only about 30 lines of code that is used for authentication. I believe that if I can add a few database fields to remove some of the assumptions that the code CAN be converted to support AD authentication.
-
Extend LDAP plugin to support AD authentication
The current ldap plugin is missing the capability to authenticate via AD using LDAP. This request will document the changes needed to add this capability.
-
RE: Boot From USB
I agree, upgrade to the 1.3.0-RCx series then you have a few more options, the wiki you referenced will work or there is a way to use a grub boot usb drive that doesn’t use iPXE. But for you usb booting into the iPXE menu is a cleaner way to go about it.