Client 0.11.4 settings.json

  • According to @Wayne-Workman in my thread The tale of two client programs the server name is entirely irrelevant to the key data that is saved to the client, and the name is only used to direct the installer to where to fetch the key from.

    Then why do I see the file settings.json with the name of the fog server I used for the installer?

    If I:

    • use the same certificate on all my Fog servers.
    • install the new client onto an image by pointing the installer to serverA.
    • then deploy that image onto machineB registered on serverB, will machineB want to talk to serverA or will it happily show on serverB instead and only?

    In the legacy client, we script-edited the file config.ini to replace the value for ipaddress with the server IP of the site upon the client’s first bootup ; must I edit this .json file similarly?

  • @sudburr you can do all that with storage nodes. And how many servers to use is up to you. If you want portable virtual boxes, you can do that still.

  • I have access to everything.

    Routers and firewalls at every site. Multiple vlans at every site.

    This is why a storage node solution won’t work for us. That’s a lot of hardware overhead especially with 80+ sites.

    We do not want centralized management of the fog server/nodes. Physical boxes at high schools, and portable virtual boxes for smaller sites used by 8 + 5 field technicians to service their schools. Techs must have the ability to capture their own images as well. Many images are restricted to their sites.

  • @sudburr said in Client 0.11.4 settings.json:

    With a site like above, with 5 subnets, how many storage nodes would I need?

    Depends on your ability to configure your switches and routers. I have zero access to all switches and the one (yes one) router, so if something doesn’t work I’m SOL because it won’t get fixed.It just depends on how you want traffic to flow.

    Generally, people want storage nodes in order to reduce WAN traffic, and to centralize FOG, and not have to visit two dozen web interfaces just to push out a snapin to all computers.

    I’d recommend a storage node per physical site IF 1. there’s only one subnet there you need fog on. 2. The site has more than one subnet fog needs to work on, AND you have a router on-site so traffic doesn’t have to flow across some 10 mile fiber line to HQ just to traverse to another v-lan to come all the way back.

    If there’s no router per-site and each physical site has many subnets, then a server per site connected to each subnet would work, it would need multiple NICs, or a server per subnet.

    Keep in mind, when I say “server”, these are just storage nodes. If they fail it’s no real problem to just rebuild them (or image them with a storage node image via fog). They can be regular desktops with big drives put in them. The central controlling web server must be a fault tolerant and redundant setup - however you want to do that.

  • While I build out a new csv solution, we’re now looking at the site firewalls to see if we can create a static entry on each there instead.

  • With a site like above, with 5 subnets, how many storage nodes would I need?

  • @sudburr this is what storage nodes are for.

  • That would work great if I had only a single subnet at each site, just create a Host (A) record named fog-server, with the IP address of the server into the forward lookup zone, but I don’t.

    I have a minimum of 2 subnet/vlan/scopes at each site now and soon that will be 5 minimum per.

    VlanA = SubnetA > Contains clientsA, FogA, fog-server Host (A) for FogA
    VlanB = SubnetB > Contains clientsB
    VlanC = SubnetC > Contains clientsC
    VlanD = SubnetD > Contains clientsD
    VlanE = SubnetE > Contains clientsE

    A Host(A) record named fog-server for subnet A will not help clients in BCD or E.

    Now I’m not a DNS magician, but I don’t see a DNS option for my scenario. So I’m still left sniffing through a csv of the DHCP Scope dump at first boot.

  • I think I just answered my own question on a test box.

    The testbox is registered with fog1.

    I changed the “Server”: setting in testbox’s settings.json from “fog1” to “fog2” .

    I changed the name of the testbox in fog1, and nothing happened.

    In the testbox fog.log it clearly states that it cannot authenticate with “fog2”

    Fog1 and Fog2 have different certificates at this time.

Log in to reply