Posts made by Zer0Cool

@quazz To be honest, and likely completely due to my own ignorance, I am having trouble understanding what relation timezone could possibly have to downloading and installing these kernels.

Also, the kernel update page now seems to load fine for me, but still get the error trying to install. Is it possible this is an issue between FOG 1.5.3 and kernel 4.17.0?

I am a little reluctant to update FOG to 1.5.4 at this time as I just completed extensive testing and some customization and am not ready to redo at a minimum a couple of hours of work to get it back to that point post update. If, however, it was sure that it would fix the issue with the kernel then I would do the update.

@quazz

date
date/time support	enabled
"Olson" Timezone Database Version	0.system
Timezone Database	internal
Default timezone	UTC

date.timezone	no value	no value

Here is what I think you are looking for.

@quazz The Apache log just has a bunch of post and get’s, nothing seems abnormal there.

I was able to once again load the Kernel Update page, which is odd as I havent changed anything since the UTC updates. Still get the same error though when trying to install the kernel

@quazz

PHP-FPM error log (www-error.log)

[08-Jun-2018 13:40:33 UTC] PHP Warning: ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_put(): Could not create file. in /var/www/html/fog/lib/fog/fogftp.class.php on line 708
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_rename(): Rename failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 807
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492
[06-Jun-2018 16:46:21 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[06-Jun-2018 16:15:57 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:37:57 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:13:25 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:12:47 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 19:49:23 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112

The Apache log didnt seem to have anything that stood out, but its possible I over looked something so I will keep checking.

Actually now the Kernel Update page wont even load. I get the following:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

So now I do not even get the option to try and download a kernel. Again, just to point out, as far as I know the rest of the server (GUI and otherwise) is perfectly functional.

@quazz Interesting, as I had changed the server time to my timezone.

Tried changing back to UTC just via FOG GUI, still had issue

Changed in CentOS 7 using:

timedatectl set-timezone UTC

Still had the same issue.

I am going to do a reboot and see if it works post reboot.

EDIT: So far still have the issue after a reboot. FOG set to UTC, CentOS set to UTC.

Clicking the Kernel Update option in Settings takes about 1 minute to load (vs every other aspect of the web gui loading just as expected, basically instantly) and then trying to update give the error mentioned in OP.

FOG 1.5.3
CentOS 7.5

First noticed something odd in that when I click on the Kernel updates entry in the Settings its very slow to load (other aspects of the web GUI load just fine). Once loaded I noticed that 4.17 was available so I selected 4.17 x64 and clicked download, it starts then gives the following error:

Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 708, Message: ftp_put(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone., Host: 10.0.0.2, Username: fog

Seems like a programmatic issue but I am not certain, figured I’d check here.

Worth noting its the same issue with x86 version of the kernel too.

@flareimp Ok gotcha, hate when companies keep the old exe name

So do you know of any in depth documentation for the available commands for DCC? Maybe it has a command available to clear out the entries prior to setting them.

To be clear, as I understand it, these entries are what you would see in the “selecting boot device” from the BIOS boot options right, not remaining partitions that you do need? In other words its just the entries that remain in the BIOS boot devices and not partitions on disk for those bot entries that remain.

If DCC doesnt have a command/switch to do this, I wonder if there is another option (a batch file or script) you could run in Setup.cmd prior to cctk.exe that would effectively clear out the invalid entries.

In some quick google searching maybe something like (I have not tested any of these):
https://gallery.technet.microsoft.com/scriptcenter/Clear-Windows-Boot-Manager-7020323d
https://social.technet.microsoft.com/Forums/en-US/63773659-fc98-4b91-8081-1def38af4f9d/multiple-entries-of-quotwindows-boot-managerquot-in-uefi-on-surface-pro-3?forum=mdt (has a couple scripts listed)

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc721886(v=ws.10)

The last one has this entry:

How to delete a boot entry
At the command prompt, type:

bcdedit /delete ID [/f]
...

So maybe it can be done using bcdedit from a batch file or something if PowerShell isnt an option like in most of the scripts the other links provide.

If you find a solution I would be interested to know what it is. Hope this helps.

From a security standpoint I dont see using NFS for imaging as an issue. As mentioned you can set it to allow only from a specific IP range. That should be enough to prevent issues (if a adversary is already on that subnet you have bigger issues). Especially if you dont have sensitive data in the share and if your FOG server is behind a firewall.

Samba would have the ability to allow only connecting from approved users or groups, the problem with that is passing the credentials to connect.

In Clonezilla I used to capture and deploy via SSH, which I really liked, but havent had any issues with how FOG handles it via NFS.

Your first warning, as it seems you have figured out, is I think kind of a basic way NFS works. Client machines have to be able to see/query the server for the share to use it. The second warning is just an extension of that, whats the point in knowing the share is on the server if you cant mount and use it.

@flareimp Ok so it looks like you are actually using a Dell utility (cctk) to set boot order. From some quick Googling and not really knowing the tool 2 things stand out to me:

• Dell seems to potentially have replaced cctk with Dell Command and Configure (DCC), as noted here. May be worth seeing if moving to this tool works better for your needs.
• I was not able to find a complete listing of cctk commands. I think it was -h was to list all of its options on the command line. I would look to see if there is any option to remove specific boot entries or to clear the boot entries to a default setting, then set to your desired order.

When you say:

@flareimp said in Multiple Windows Boot Manager using UEFI:

but with multiple entries it screws up because of the false entries.

What do you mean specifically. Is there an error message, does it do something unexpected, do nothing, etc?

So it appears this is currently the issue, as @Tom-Elliott has made me aware. The PCI / FIPS Compliance is being pushed by Group Policy (as part of my AD), so once thats in place it basically renders the FOG client moot. Prior to this it works just fine, assigning the hostname, activating Windows and joining the domain, then running the snapin initially.

Since my snapin deleted the local admin account and reboots, there is no choice but to log in to an AD account for which this policy is enforced.

So under the local account the snapin runs because the FOG client is allowed to connect and authenticate.

What I have decided to do to address this is the following:

• Leave the FOG client in the image and let it change host name, activate Windows and domain join.
• Let the FOG client run my snapin/batch file to delete the local user, force gpupdate and uninstall FOG client, then reboot
• Login as a domain user and manually run a batch file that just deletes the remaining C:\users\username

The end result is the machine is ready to use, I get all the initial benefits of the FOG client but do not have it left on the machine when it cannot operate. Hopefully when the matter is resolved and it can run with this gpo setting I can leave the FOG client installed to make working with the machines easier long term.

I am currently testing my revised snapin to ensure it runs, uninstalling the FOG client and performing its other tasks properly. Looking at the newely booted images now and the snapin may not be 100% as it appears stuck on “please do not shut down until this is complete”.

EDIT: uninstall works, but the next line in the batch file (to reboot) doesnt execute. I think I can resolve this by adding a forced restart to the uninstall command.

@sherder For me I had similar troubles with Windows 7. I came to 2 conclusions. sysprep + unattend is very finicky. If things are not perfect you get all kinds of odd behavior. The other was that many parts of it seem to not function as they should, the computer name being one of them. The CD key is another, many sites/articles say to use 00000… or XXXXX… repeated, but mine would fail unless I put a valid key in (ended up using the Windows generic install key that MS provides on their site, doesnt activate just gets install done).

Are you making your unattend by hand or using a tool to generate it?

@sherder said in Windows 10 Unattend file issues:

It skips the setup but doesn’t implement the changes that I put in with sed

Not clear on the above, could you elaborate what you mean here?

When the syspreped image boots back up, are there some things that have been applied by unattend and some that have not, or does it appear to not have applied any changes specified?

@flareimp Can you share your Setup.cmd script? You may have to add some logic to it to delete these duplicate entries before setting order etc.

I think what you are seeing is pretty common, not even a Windows only issue really. In my testing I have entries in boot selection for Windows, Fedora and CentOS even though they arent installed (and would fail if selected to boot). I typically go and clean them out manually but if together we find a way to do it via Setup.cmd then I may add the logic to my own process.

@tom-elliott Ah interesting, I hadnt considered that. Ill start to comb through it.

I now have a feeling that disabling PCI compliance may not be an option in my environment however

I may have to, for the time being, consider alternatives to the FOG client for the post deployment then.

Ill check out my group policy and evaluate the options.

Thanks!

EDIT: Seems the GPO setting is likely “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” which is set to enabled for me and unfortunately its not an option for me to disable this.

@tom-elliott Hello Tom, thanks for the reply. I will look into this and see if I am able to disable the PCI Compliance.

I am a bit confused however why its not a problem until after the FOG client has changed the hostname, joined the domain, activated Windows and run my relatively basic batch file (seen below). Just a bit odd that it does work until after deployment is complete:

net user Temp /del
rmdir /S /Q C:\Users\Temp
CD C:\Windows\System32
echo y | gpupdate /force /wait:0
shutdown /r /t 00

I will remove my snapin from the host and re-image to see if the problem persists if I do not delete the local account as well as your advice.

Thanks

I re-deployed my image to the host so that I could see the log from deployment to when it stops working.

It appears as if the FOG client works just fine during hostname change, Windows activation, joins the domain/reboots and even runs my snapin assigned to the host which deletes the local user, does a gpupdate /force and reboots again. After that point I get the log posted above and it seems the FOG client cannot properly authenticate.

It appears as if it is able to reach the server as it gets the CA cert, but on the line Middleware::Communication POST URL: http://10.0.0.2/fog/management/index.php?sub=requestClientInfo&authorize&newService It then seems to fail with a message regarding being unable to decrypt AES.

I have tried multiple times doing the encryption reset option in the web gui for the host to no avail.

Not sure what I am missing here, any help would be great. Thanks

FOG 1.5.3
CentOS 7.5

Ok I have found this and am trying it, https://forums.fogproject.org/topic/11215/snapins-stuck-in-checked-in-and-auto-domain-join-won-t-work/4

Reset the encryption data and rebooted the host. Having checked the fog.log it does appear it could be the issue.

Hopefully this resolves it.

EDIT: Has not resolved it, still see errors being logged in the fog.log file on the host.

here is an excerpt from the log:

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 6/5/2018 10:22 AM Client-Info Version: 0.11.16
 6/5/2018 10:22 AM Client-Info OS:      Windows
 6/5/2018 10:22 AM Middleware::Authentication Waiting for authentication timeout to pass
 6/5/2018 10:24 AM Middleware::Communication Download: http://10.0.0.2/fog/management/other/ssl/srvpublic.crt
 6/5/2018 10:24 AM Data::RSA FOG Server CA cert found
 6/5/2018 10:24 AM Middleware::Authentication Cert OK
 6/5/2018 10:24 AM Middleware::Communication POST URL: http://10.0.0.2/fog/management/index.php?sub=requestClientInfo&authorize&newService
 6/5/2018 10:24 AM Data::AES ERROR: Could not decrypt AES
 6/5/2018 10:24 AM Data::AES ERROR: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
 6/5/2018 10:24 AM Middleware::Response ERROR: Could not parse data
 6/5/2018 10:24 AM Middleware::Response ERROR: Error reading JObject from JsonReader. Path '', line 0, position 0.
 6/5/2018 10:24 AM Middleware::Authentication Authenticated
 6/5/2018 10:24 AM Middleware::Authentication ERROR: Could not authenticate
 6/5/2018 10:24 AM Middleware::Authentication ERROR: Object reference not set to an instance of an object.

----Original Issue/symptom-----

I created a snapin which is a pretty simple batch file. The batch file runs on first login post deployment automatically and doesnt exhibit any issues then.

When I attempt to run it manually however (using single snapin option) it appears to never be run. It shows up under active tasks with a status of “checked in” but never moves beyond this. The other day I let it sit for ~30 minutes with no change before cancelling, rebooting the server and hosts and trying again with the same result.

Not really sure how to troubleshoot this issue, any help would be great. Thanks

@wayne-workman Ok cool, I will look into it, Thank you.

Ok things are starting to get more clear in terms of how snapins work. Anyone able to weigh in on the permissions FOG client/snapins have?