Topics created by Jim Graczyk

I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk

@Jim-Graczyk Sorry we’ve lost track of this. Are you still in need with this issue. We hardly have enough time to fix all the big and small issues and try to push the next release forward. So writing documentation about all the services is way beyond what we can do right now. I know this is sad. But hey, why not you join in, check out the stuff and write it all down?

@Jim-Graczyk Do you still need assistance on deleting that snapin from the DB? When editing the snapin in the web UI you can see it’s ID in the URL. Note that down and open a terminal on your FOG server:

shell> mysql -u root -p ... mysql> use fog; mysql> DELETE FROM snapinAssoc WHERE saSnapinID = x; mysql> DELETE FROM snapins WHERE sID = x; mysql> quit shell>

Replace “x” in ... = x; with the ID you noted down earlier.

@Jim-Graczyk All pages rely on “index.php”. The Default if node is not in the query string, or if node=home will direct to the dashboard. This is intentional as most people this shouldn’t impact too much. That said, this shouldn’t be a hard request to incorporate, but if you’re blocking the dashboard as being view-able, where should we redirect if a choice hasn’t been made?

I’m solving this topic for now. @Jim-Graczyk if you are still having the issue, mind creating a new one? I will work on this in the meantime, but I would much prefer a new bug report for the issue (after updating to latest rc of course) .

@tom-elliott

Tom,

Sorry about the delay, but I wanted to see more data before responding.

The time zone change resolved a big part of the problem. All the times are now making more sense. I’m guessing the log store UTC because after changing the timezone setting, all Snapin Histories are as they should be - no time shifts.

I can only suppose that to have the times appear as they did originally, the initial time stamps may have been coming from the client. I would suggest this isn’t a good idea since PCs are notoriously out of sync, but these days with SNTP, not so much. One would think it would be desirable to use all time stamps from the server.

So… Thanks very much for pointing that out to me. I once knew timezone was a setting but seem to have forgotten…

To be thorough, I do want to point out something, just to be sure that what I’m seeing is by design.

Attached is a screenshot of the snapin history after a deployment for a machine.

0_1507741140553_d0a33bc5-87b8-455b-bb7d-f18054867b0e-image.png

Please note that there are only 5 Start Times for all 17 Snapins. It seems that the start time is only recorded for the first Snapin in a series of snapins executed in one pass of the FOG Service. Given the current report, one can determine the actual start time of a particular Snapin by doing the math (Add the previous snapin’s duration to the posted start time for the task). One can also determine the duration of each individual snapin by subtracting the previous snapin’s duration from the posted snapin duration.

Personally, I’d like to see the snapin start time be the start time for each snapin, not the start time of a group of snapins that just happen to run sequentially. Simialrly, I’d also like to see the duration as the duration of a single snapin, not a group.

If the current approach is by design, then ok. I certainly can live with what we have.

Thanks,

Jim

@taspharel

I’ll look into this - thanks again…

Jim

@Tom-Elliott

I have been keeping an eye out on this issue with replication myself, im running V52 of working branch, should I wait until RC10 to come out to update? So far I think everything is functioning normally for replication but figured I could wait until RC10.

@wayne-workman Thanks for the help. Just wanted to post this as Solved. Checkboxes now work in the Web UI.

Jim

@tom-elliott

Thanks Tom. The two fixes worked, so the image protection and manual add of a host are working.

We still cannot delete any snapins associated with any host, so this isn’t Solved for us. Should I post this issue separately in a different section of the forum? Can you give us any idea what to look at?

Thanks for your help,

Jim

@wayne-workman

Agreed on all counts, plus I don’t have images that need deleting at present to test, nor time to create images just to test deletion (at this point). I’ll check this as the opportunity presents itself.

thanks to all.

Jim

For more information on some of the methods and class based variables please see:

fogdoc.mastacontrola.com

All fog installations, now, should have the folder: /var/www/fog/fogdoc available. It is possible to build local documentation of all classes using doxygen.

The command to build it would be:

cd /var/www/fog doxygen fogdoc/fogdoc

The fogdoc currently is designed to place the fogdoc in /var/www/fogdoc, so a link to your properly html root directory, or fog directory will probably yield in slightly better results for generating this documentation.

Fixed in working.

Fixed in working. Thanks for reporting.

Thanks

Jim

@themcv

OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.

I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.

Go Figure…

Thanks and sorry for the trouble…

Jim

Tom,

Thanks for the quick fix. Imaging is back working again.

Jim

@tom-elliott

Tom,

We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.
0_1502401559812_8e8425e1-fa40-46a0-a798-24addf32556d-image.png

I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.

The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.

2017-08-10 12:24:36 (2 snapins)

2017-08-10 12:25:28 (1 snapin)

2017-08-10 12:26:14 (6 snapins)

All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.

Jim

Sebastian,

Here’s d1.partitions:

label: gpt label-id: 6561AEE9-3184-4274-B8E2-359A32B76FD5 device: /dev/sda unit: sectors first-lba: 34 last-lba: 104857566 /dev/sda1 : start= 2048, size= 921600, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3E77A64A-2E46-40EC-93D0-03CFD0BDDDC9, name="Basic data partition", attrs="RequiredPartition GUID:63" /dev/sda2 : start= 923648, size= 202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2CF8BFD9-3B61-4FAD-A4DC-6FC2A1E6E134, name="EFI system partition", attrs="GUID:63" /dev/sda3 : start= 1126400, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=1222537C-11F5-4B9F-9FB2-68AE743C5D79, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda4 : start= 1159168, size= 103696384, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0C2EDC77-DB4B-45A1-BF2B-2BE3B844CF47, name="Basic data partition"

Here’s d1.fixed_size_partitions:

:2:3:1

Jim