Posts made by Jim Graczyk

Dev Branch, 1.5.0-RC-9, SVN 6080
Running on CEntOS 7

Description:

I scheduled a deployment for a Host that was also assigned Snapins. I decided I didn’t want one of the Snapins to run, so I canceled one Snapin under Task Management / Active Snapin Tasks . All Snapins were canceled (as I assume is by design since all went in at once they may be treated as one task), but the report doesn’t show them all canceled.

The image below shows the first deployed Snapin In-Progress when the set of Snapins were canceled. The next Snapin (AdminSet) is attributed the cancellation. The remainder show the state they were in when the cancellation occurred. I’m assuming this is in error and the History should show all as Cancelled.

First, is it expected that canceling one Snapin should cause all to be cancelled?

If so, then the history needs so show it.

Thanks,

Jim

@tom-elliott

I didn’t say I could do simple math, but I’m assuming it’s in 24 hr format the whole time and the Queue time is correct in local time. I create the Snapin task at 10:27 this morning, EDT (GMT-4). Add 4 hours to 10:30-ish and you get 14:30-ish times, GMT times. I’m still thinking the log shows local time when Queued, until the PC Checks in, then it switches to GMT for Checkin, InProgress and Complete times.

But I certainly differ to whatever you think the problem is.

Jim

Server: v1.5.0 RC9
OS: CentOS7

Client: 0.11.12
OS: Windows 7 Pro x64

Description:
When scheduling a Snapin, the local time is used to indicate when the Snapin was Scheduled (see last line in screenshot below).

Then, after the FOG Service on the PC communicates with the FOG Server, the times appear to change to GMT times (see last line in screenshot below).

Subsequent timestamps continue in GMT (again, last line below).

Jim

@taspharel

I’ll look into this - thanks again…

Jim

@taspharel

Thanks for the link and all the info. Postdownload scripts would be the ideal architecturally to place to make these changes. That would eliminate the manual work and allow for proper separation of content between FOG Server . My problems is ignorance of FOG coding and updating methodologies and future plans.

I have altered FOG for my own needs several times before - in the .32 era - only to find my changes overwritten at update. This became a maintenance issue at best and sometimes a total redo due to changes within FOG. Since I don’t know what the FOG Development team’s plans are, or how long-lived any time investment I make altering FOG would be, I decided long ago to minimize my changes to FOG. Also, for me, it’s far easier to debug changes to the Windows OS when they’re made in the Windows OS. To that end, my Snapins are only a 17K .exe that starts a Windows program I deploy to each PC, and all real installation content is accessed via SMB. This allows me to alter very large installations w/o re-uploading to FOG and requires much less work on the PC’s part installing content. So, as long as I have another option outside of FOG, changing the PostDownload process would be the riskier path.

Your post shows me there’s documentation available, but often it’s point in time - as in each post describes how do solve a problem at the time it was posted. It’s often unclear to which version of FOG the doc applies. It’s very hard for us to get a sense of stability and longevity from these posts.

The Project team is made up of fantastically hard working people, so it’s unreasonable to add to their burden by requesting architecture and development plan documentation. I prefer to expect that anything within FOG is subject to change as they see fit daily change to daily change. I’m thinking this has been essential to the team making FOG what it is today. Consequently, I try to put my hooks in after FOG.

Thanks very much for the help you and the rest of the team provided.

Jim

@sebastian-roth
@Taspharel
@george1421

All of the info provided lent itself to the ultimate solution…

For anyone who wants to create images on one fog server and have them used on a completely separate, unique and different FOG Server, here’s the process I used.

We’ll create an image that has the FOGService on it associated with the first FOG Server (FOGServer1) by running Sysprep with shutdown. We’ll install the second FOG Server (FOGServer2) and acquire the certs from it by installing the FOGService on a PC and associating it with FOGServer2. We’ll edit the uploaded disk by attaching it as a “D:” drive to a PC and create or add to the SetupComplete.cmd file to load the FOGServer2 certs after Sysprep completes.

Here are the steps:

• Build the image PC with OS, applications, etc. - whatever you want already installed. I subscribe to the notion that a windows image should contain the MS OS CD installed, FOGService Installed and then the rest of the content should come from Snapins. As little as possible should be done by hand because can seldom repeat the process if we have to. For this process, however, it doesn’t matter.

• Install the FOG Client Service and associate it with the first FOG Server (FOGServer1). As stated above, I use Snapins to deploy content the makes up my images.

• Run Sysprep with shutdown, then capture the image to the FOG server (FOGServer1).

• Install the FOG Client Service on a PC associated with the 2nd FOG server (FOGServer2), accepting all defaults.

• In the FOG folder (C:\Program Files\FOG or c:\Program Files (x86)\FOG) copy files ca.cert.der and fog.ca.cer to external storage

• Deploy the image from FOGServer1 to a disk (a virtual is vastly perferred) with Shutdown. Do not let the machine attached to the disk boot.

• Mount the disk to another computer as an additional disk (as in D Drive).

• Using this other computer, edit the contents of the sysprep’d drive (D Drive)

• Copy ca.cert.der and fog.ca.cer to the “D:\windows\setup\scripts” folder

• Create SetupComplete.CMD file in “D:\windows\setup\scripts”, or add to the existing file

• Add these lines for a 32 bit OS:
  copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles%\FOG\ca.cert.der”
  copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles%\FOG\fog.ca.cer”
  certutil -delstore Root “FOG Server CA”
  certutil -delstore Root “FOG Project”
  certutil -addstore Root “%programfiles%\FOG\ca.cert.der”
  certutil -addstore Root “%programfiles%\FOG\fog.ca.cer”

• Add these lines for a 64 bit OS:
  copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles(x86)%\FOG\ca.cert.der”
  copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles(x86)%\FOG\fog.ca.cer”
  certutil -delstore Root “FOG Server CA”
  certutil -delstore Root “FOG Project”
  certutil -addstore Root “%programfiles(x86)%\FOG\ca.cert.der”
  certutil -addstore Root “%programfiles(x86)%\FOG\fog.ca.cer”

• Dismount the additional disk, connect it to a machine associated with FOGServer2 as the system drive (C:), and capture the image to FOGServer2.

• When Deploying the image to additional machines from FOGServer2, the machine will associate with the FOG Server2 but will not join the domain or run Snapins until you Reset Encryption for the new host (button found at the top of the “General” tab for the host).

• One caveat - I use a DNS alias for all FOG Servers (creatively, I chose fogserver) so I don’t have to worry about FOG server name differences. If your FOGServer1 and FOGServer2 are in the same DNS zones, this won’t work, so if you have different FOG server names, you can save the setting,json file from the \program files\FOG folder from a PC associated FOGServer2 or just edit the one with the new FOG server name in it. When you’ve mount the imaged disk as an additional drive, copy the altered settings.json file to the \windows\setup\scripts folder (along with the certs) and add an additional ‘copy’ command to SetupComplete.cmd to get the file into the FOG folder (just like the certs). I haven’t tested this, so hopefully some who knows better will comment.

While the above process is a pain to execute for each image you create, each time you need to associate it with a new FOG Server, I find it far more cost effective than uninstalling the FOG Service and reinstalling it after imaging each PC.

• Please note that I had to place some very odd quotes around some paths because drive letters become emojis d: …

Jim Graczyk

@tom-elliott

Fantastic …

Updated the lab and replication is working to the Storage Nodes, Group to Group, as it should be AND the Replication Log UI is not only working but provides much more detail.

Please consider this issue Solved…

Just an FYI - since we have a script working in the new system, we may or may not move to it to the Working branch. It’ll depend on how much pain our script causes us as we add Locations and Storage Nodes v fear of instability this is part and parcel to using the Working branch. Our lab will stay up to date on the working branch. At this point, we think we can hold out for the Dev release of RC10.

Thanks very much.

Jim

@Sebastian-roth

Uninstalling and reinstalling the FOG Client resolved the issue but this an untenable solution. Can anyone tell me if there is anything short of this step I can try?

Ideally, I’d like deploy the image to a disk, mount the disk, then alter the disk content before booting the machine, then re-capture. I can even add a script to the SetupComplete.cmd file that’s post sysprep.

Any ideas?

Jim

@Sebastian-roth

I renamed token.dat in the FOG folder on the client, then rebooted. I’m still getting the same error and there is no new token.dat file.

Jim

@sebastian-roth

Sebastian,

Will do - but from what you say, this means images with the FOG client installed are married to the FOG server on which they’re created??? This seems unbelievable to me… Can we undo the certs altogether?? I need images that are portable between FOG servers w/o having to crack open the PC after each image. Even manually messing with images then reuploading at each FOG server is a difficult limitation to live with.

I get (maybe) marrying a machine to a fog server after it’s imaged. I’m very keen to know how we can prepare the image during sysprep so it’s read to go into any FOG installation.

Back with results in a sec. And what about the cert having the wrong name on it? Anyway to change it?

Jim

Updated host name. Now the hostname command returns the proper host name for the server.

Found FOG Wiki article
https://wiki.fogproject.org/wiki/index.php?title=Installation#Installer

Ran:
./installfog.sh -K

to recreate the keys

Still have the same name (localhost.localdomain) in the key. Process created new key (new timestamp).

What do we need to change within the system so the cert is recreated with the correct names included??

Jim

@tom-elliott

Updated Lab to v52. Can no longer check replications logs.

Fog Configuration / Log Viewer gives me a Files: pulldown that is now empty.

Jim

@tom-elliott

Tom,

I’m using the working branch on my lab set up. I’ll pull it there.

I’m also OK trying the working branch on my new installation, as long as I can switch back to the Dev branch after pulling the current Working version.

Is it just a matter of changing the git checkout back to dev branch?

FYI - My new installation is showing SVN 6079 while the lab is showing SVN 6080 - if that helps any.

thanks,

Jim

We’re changing the /etc/hostname to have the actual FQDN for the FOG server.

I just wanted to let the FOG team know that I have just completed the build of a new FOG server using v1.5.0 RC9, Dev Branch, with associated storage nodes. We created storage groups and storage nodes, after uploading images. Installed the Locations Plugin and set locations. We moved our images and snapins to the new FOG installation…

And we’ve reproduced the same problem we’ve had on FOG system on which this original posting was based. We have no replication of images or snapin, even though the storage nodes are working as expected.

We’ve written a bash script to replicate both snapins and images from the main fog server to the storage nodes, so our installation works, but based on my experience, it’s very easy to reproduce this replications problem - just do an installation on fresh servera and the problems ensue.

Thanks,

Jim

Server: V1.5.0 RC9
OS: CentOS 7

Client: 0.11.12
Client OS: Windows 10 B1703

Description:

Build all new FOG installation (Main and storage nodes). I have the location plugin installed (don’t think that matters). Moved images from a test/lab system to this new system. Images have FOGService installed from Lab system.

Deploying machines from the new FOG server, all machines boot up and work, but the fog.log file on each deployed machine has this text:

9/26/2017 1:09 PM Data::RSA FOG Server CA cert found
9/26/2017 1:09 PM Data::RSA ERROR: Certificate validation failed
9/26/2017 1:09 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid)
9/26/2017 1:09 PM Middleware::Authentication ERROR: Could not authenticate
9/26/2017 1:09 PM Middleware::Authentication ERROR: Certificate is not from FOG CA

Checking the certs on both of the FOG servers:
https://fogserver/fog/management/other/ssl/srvpublic.crt

I can tell that:

• The cert on the lab fog server has the DNS domain name in it from the lab.

• list itemThe cert on the new fog server has localhost.local domain in it.

I don’t have time to set the DNS name on the FOG server and reinstall FOG to generate the proper cert.

How do I make the correct cert now that FOG is already installed?
What LINUX values have to be set to properly create the cert in the future?

Thanks,
Jim

@sebastian-roth

I’m confused regarding what the author is attempting to do with FOG. I believe he’s trying to install XP from a Windows XP CD ISO file using FOG. He doesn’t appear to be uploading a hard drive to FOG from a PC on which XP was installed and Sysprep’d.

Once upon a time, before FOG, I used PXE to load an ISO into RAM that could be any ISO - like the Windows XP ISO file. I also used a customized BartPE image to copy / clone to the local HD a sysprep’d xp disk image of various sorts, using the Microsoft IP stack and SMB.

Looking at the root=/dev/ram0 parameter is very reminiscent of that approach, where the ISO is copied to RAM over TFTP or HTTP and then booted. If so, one would end up having to do a manual install, if the ISO is the Microsoft CD, or an unattended install if the ISO had been altered accordingly. I did this w/o FOG, using PXECLIENT, etc. and with FOG v.32 by editing the FOG Menu and adding the items to load the ISO. I was also able to compress the ISO using an SDI format that come from XPEmbedded.

With this approach, there would be no capture step, and FOG would just be used as a boot loader to get the ISO up and running.

Or am I missing something?

Jim

@tom-elliott

thanks Tom… we’ve tested FTP and found it working on all nodes…

Jim

@wayne-workman

I prefer to move forward rather than backward so I’ll choose Option B - manually replicate and test that it’s only a replication problem. We’re already working on that. This will work for a few days, but we’ll have problems as soon as we have to upload PCs before imaging.

I’ll post here if all images and snapins work to clients at each site.

Jim