Posts made by Wayne Workman

@lee-rowlett said in Location Plugin - enhancement of behavior:

i’d recommend making sure we implement being able to add multiple CIDR addresses to a location.

Can you explain in more detail why a location would need multiple CIDRs?

This is a pretty simple fix, so I don’t see why not. If the debian team fixes it later, great. When they fix it, the sed command will stop matching. just my opinion. I think we should make the installer work on the mainstream distributions - even with their problems to an extent.

@sebastian-roth said in Cant PXE Boot = PXE-T01: File not Found:

Hmmmm, I am wondering how we are going to fix this.

Maybe a sed command that uses a variable. This would only match if it’s empty:

interface="ens3"
sed -i "s/INTERFACESv4=\"\"/INTERFACESv4=\"$interface\"/g" /etc/default/isc-dhcp-server

@404 Well, what I’d suggest for now is to run the fog installer as normal. After it fails, go edit that one file, delete the pid file, then re-run the installer again. It should succeed the second time. FOG has to carefully configure the dhcp server so that multiple architectures are supported. We’re going to write a patch here shortly to fix this in working branch.

Figured it out. In Debian 9, you have to put the interface name into this file:
/etc/default/isc-dhcp-server

When I looked at mine, it looked like this:

INTERFACESv4=""
INTERFACESv6=""

So I changed it to read like this:

INTERFACESv4="ens3"
INTERFACESv6=""

Then I had to remove the pid file:
rm -f /var/run/dhcpd.pid

Then, I could finally start the dhcp service:
systemctl start isc-dhcp-server

Moved this to bugs, because I confirmed the problem in master branch.

@Sebastian-Roth I just tried doing an install on Debian9 with 1.4.4. If you specify the installer to setup dhcp, it fails when trying to start the dhcp server. And because the /tftpboot directory is setup after dhcp is, that doesn’t get done.

I’ve been digging into the problem, it’s IPv6 related as far as I can see right now. Here’s the error:
Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed!

Snippet from journalctl -xe:

root@Debian9:/# journalctl -xe
Dec 30 14:14:34 Debian9 dhcpd[22356]: 
Dec 30 14:14:34 Debian9 dhcpd[22356]: 
Dec 30 14:14:34 Debian9 dhcpd[22356]: Not configured to listen on any interfaces!
Dec 30 14:14:34 Debian9 dhcpd[22356]: 
Dec 30 14:14:34 Debian9 dhcpd[22356]: If you think you have received this message due to a bug rather
Dec 30 14:14:34 Debian9 dhcpd[22356]: than a configuration issue please read the section on submitting
Dec 30 14:14:34 Debian9 dhcpd[22356]: bugs on either our web page at www.isc.org or in the README file
Dec 30 14:14:34 Debian9 dhcpd[22356]: before submitting a bug.  These pages explain the proper
Dec 30 14:14:34 Debian9 dhcpd[22356]: process and the information we find helpful for debugging..
Dec 30 14:14:34 Debian9 dhcpd[22356]: 
Dec 30 14:14:34 Debian9 dhcpd[22356]: exiting.
Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed!
Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]:  failed!
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Dec 30 14:14:36 Debian9 systemd[1]: Failed to start LSB: DHCP server.
-- Subject: Unit isc-dhcp-server.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit isc-dhcp-server.service has failed.
-- 
-- The result is failed.
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

This is systemctl status isc-dhcp-server:

root@Debian9:/etc/dhcp# systemctl status isc-dhcp-server
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2017-12-30 14:14:36 CST; 11min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 22339 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/isc-dhcp-server.service
           └─22351 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf

Dec 30 14:14:32 Debian9 dhcpd[22350]: Wrote 0 leases to leases file.
Dec 30 14:14:32 Debian9 dhcpd[22351]: Server starting service.
Dec 30 14:14:34 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv4 server: dhcpd.
Dec 30 14:14:34 Debian9 dhcpd[22356]: Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed!
Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]:  failed!
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Dec 30 14:14:36 Debian9 systemd[1]: Failed to start LSB: DHCP server.
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

Snippet from the bottom of my fog error log:

Dec 20 19:59:42 Debian9 systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Dec 20 19:59:42 Debian9 systemd[1]: Started The PHP 7.0 FastCGI Process Manager.
isc-dhcp-server.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable isc-dhcp-server
Job for isc-dhcp-server.service failed because the control process exited with error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details.
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-12-20 20:00:12 CST; 2s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 21889 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/isc-dhcp-server.service
           └─21901 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf

Dec 20 20:00:10 Debian9 dhcpd[21906]: than a configuration issue please read the section on submitting
Dec 20 20:00:10 Debian9 dhcpd[21906]: bugs on either our web page at www.isc.org or in the README file
Dec 20 20:00:10 Debian9 dhcpd[21906]: before submitting a bug.  These pages explain the proper
Dec 20 20:00:10 Debian9 dhcpd[21906]: process and the information we find helpful for debugging..
Dec 20 20:00:12 Debian9 isc-dhcp-server[21889]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed!
Dec 20 20:00:12 Debian9 isc-dhcp-server[21889]:  failed!
Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Dec 20 20:00:12 Debian9 systemd[1]: Failed to start LSB: DHCP server.
Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

Here’s the output of ip addr:

root@Debian9:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:67:a2:b4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.39/24 brd 10.0.0.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe67:a2b4/64 scope link 
       valid_lft forever preferred_lft forever

Output of ifconfig

root@Debian9:/# ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.39  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::5054:ff:fe67:a2b4  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:67:a2:b4  txqueuelen 1000  (Ethernet)
        RX packets 163559  bytes 232881890 (222.0 MiB)
        RX errors 0  dropped 231  overruns 0  frame 0
        TX packets 44237  bytes 4542466 (4.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 46  bytes 1794 (1.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 46  bytes 1794 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This is my dhcpd.conf file:

root@Debian9:/etc/dhcp# cat dhcpd.conf 
# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 10.0.0.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 10.0.0.10 10.0.0.254;
    default-lease-time 21600;
    max-lease-time 43200;
    option routers 10.0.0.1;
    option domain-name-servers 208.67.222.222;
    next-server 10.0.0.39;
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
    class "SURFACE-PRO-4" {
        match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
        filename "ipxe7156.efi";
    }
    class "Apple-Intel-Netboot" {
        match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
        option dhcp-parameter-request-list 1,3,17,43,60;
        if (option dhcp-message-type = 8) {
            option vendor-class-identifier "AAPLBSDPC";
            if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
                # BSDP List
                option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47;
                filename "ipxe.efi";
            }
        }
    }
}

@joe-schmitt said in Location Plugin Enhancement of behavior:

Though it would be best to have the CIDR conversion and mapping done entirely on the backend, and not in FOS.

All web frameworks I know of can easily get the requester’s IP address, so yeah I think it would be best done in the backend. I was just excited and not thinking when I suggested doing it in FOS.

After a Normal Fog install i should be able to get to the iPXE Boot Menu right out of the Box using the Legacy or UEFI PXE boot, right?

Not necessarily. If FOG is doing DHCP and there isn’t another dhcp server operating with the same broadcast domain, then yeah you can pxe boot out of the box once fog is installed. This is the only case where it works ‘out of box’. All other scenarios require additional configuration somewhere.

What is the tftpboot location on FOG 1.4.4, is it just /tftpboot beside the other folders such as /home, /etc, /bin…?

The iPXE binaries are placed into /tftpboot automatically by the installer.

Why does the DHCP not need the “filename:undipxe.k/pxelinux.0” Option?

No idea. the .0 thing was a bug in the old dnsmasq versions - which has since been fixed by dnsmasq’s maintainer Simon Kelly. It’s interesting that you even ask this, because this suggests you have DHCP running on another server somewhere besides the FOG server.

As for all the other stuff - just start over. I have no idea where you went wrong, and don’t want to waste time trying to figure out what went wrong. There’s nothing important in your broke VM, so just delete the VM and make a new one. Also, use git this time instead of sourceforge. Instructions here: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG
Here’s a full video showing a Debian 8 setup that will also work with Debian 9: https://wiki.fogproject.org/wiki/index.php?title=Debian_8

@lubo Using the FTP credentials, simply log in via actual FTP, and do an ls to see where you are. Wherever you ‘plop’ into, that’s your FTP root. Taking that into consideration, you need to adjust FOG’s FTP Path to start at the ftp root -> to the images directory. If that makes sense. Also, could be a simple permissions issue too.

The FTP Root is normally different than the NFS root on NAS and SAN devices. This is why we have two different fields for this: Image Path and FTP Path. Looks like you need to adjust the FTP Path to be correct. This is also documented in the wiki already: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP#FTP_Path

Two words:

IP ranges.

Here’s this idea:

Add another field to the locations table: CIDR. Values would be in CIDR format. Example:

• 10.0.0.0/8 This would represent 10.0.0.0 - 10.255.255.255
• 10.5.40.0/24 This would represent 10.5.40.0 - 10.5.40.255
• And so on

So, if a host does not have a location ID assigned to it, look at it’s IP address and see if it matches the CIDR of any location. If you find a match, choose that location and use one of that location’s storage nodes.

@developers @moderators @testers Thoughts? I will gladly write the necessary bash functions for FOS used to get a host’s CIDR.

@m-fitzgerald said in How do I change to order of the Location ID’s?:

Initially we did not need to do this step.

This is how the location plugin has always worked. If a host is not registered, FOG simply chooses whatever node that has the needed image and also has empty slots, location configuration is not taken into account because the unknown host has no location information.

@george1421 said in Unable to UEFI boot to Fog Server:

If Windows 2008 DHCP doesn’t support automatic uefi/bios (I know it doesn’t)

If it does, I cannot figure it out. I spent days trying. One would think it can given the available GUI options in 2008 DHCP, but configuration of it is just way too complicated. 2012 R1 and above handles it nicely though.

@m-fitzgerald said in How do I change to order of the Location ID’s?:

For some reason the PC will grab a storage node that is located at a different location from time to time.

Because they are not registered, therefore are not assigned a location. Because of that, FOG uses whatever node that has empty slots. Location Plugin restrictions can only apply to registered hosts that are assigned a location.

We can do it via registering first but it is a few extra key strokes

I want to point out that your entire problem is caused by not doing ‘a few extra key strokes’ to register the hosts and assign a location.

The overall issue I see here (not the location problem) is that you’re trying to use advanced imaging features that FOG has with a cloning mindset. FOG is not Ghost. FOG is an imaging solution, where imaging means intelligently applying an image and then configuring it. Ghost is a cloning solution, where it un-intelligently applies an image and does no configuration. Most of FOG’s intelligent imaging features require hosts to be registered, one of those intelligent imaging features is the use of locations.

@greventlv said in How do I FOG my FOG server?:

I know that’s something that I can do, but I have a bunch of other stuff on the server and during production breakdowns, it would be a lot faster to hit a few buttons and get everything back to the original state without having to deal with a new install, restore and etc.

Then really you should build a fog server in a VM and just snapshot it. That’s literally ‘a single button click’ to restore from a past state.

I’ve wrote a tool to renumber snapinIDs and imageIDs, location IDs is really just a couple tweaks to do. Do you want to take a shot at it? Just be sure to backup your fog database before mucking with things and all will be fine. You’d backup like this: Web GUI -> FOG Configuration -> Configuration Save -> Export Database -> Export

@greventlv Typically all you need to backup is your database and images. You can always rebuild the fog server if those two things are backed up. There’s no need for a full image.

@george1421 or @Sebastian-Roth can one of you confirm this issue? He’s saying once a new menu item is created, he can’t later edit it at all. It may be a normal bug, or it may be something with the strings he’s using (doubtful).

or a VM snapshot/checkpoint if it’s in a VM. I concur with what @george1421 said, clonezilla is the correct way to take an image of a fog server.

@stiger said in ipxe menu problem:

Now I want to edit / delete the two item which i added , but i don’t know how to do.

FOG web gui -> FOG Configuration -> iPXE Menu Item Settings -> Find your item