Posts made by Mentaloid

@fry_p sidenote: The only SB switches I had issues with were some of the <24 port switches - and this was a issue with the stupid security they had messing with UDP/NFS; this was fixed with a firmware upgrade.

@Tom-Elliott
Thanks Tom, whatever you changed seems to have fixed things right up!

Reboot after is now working without causing tasks to be re-created when next checkin occurs.

You guys are awesome - did I mention that before?

@Junkhacker

I had thought of the restart in the power shell script - but thats a problem as the next snapin starts executing while the host shuts down.

The snapin runs fine with a clean exit - and this did work before I upgraded from client9.X/trunk7224 to client10.6/trunk7591

Powershell with -File runs the script called in the current environment - not as a separate thread/subproccess - so it does wait for the script to completely finish before exiting.

reboot.ps1

Start-Transcript -path c:\SnapinLogs\Reboot.log
#restart-computer
echo "Fogservice will issue reboot, this is a dummy file"
Stop-Transcript

I’ve got tons of other powershell snapins that work fine (infact, snapin 1 and 2 are powershell), so it’s not powershell related. Simply unchecking “reboot after install” will break the loop, but is obviously not the desired operation.

I’ll see if I can pull an apache log to see if there is anything pertinent in there.

yes, I realize I could simply put the reboot after on the snapin prior - but some people I work with require a more visual aid to see whats going on, hence the snapin

I upgraded to 7591/client10.6 this morning - and since then I’ve got infinite boot loop happening when snapins are being deployed;

Snapin 1 (no reboot after) runs, installs, disappears from task list
snapin 2 (no reboot after) runs, installs, disappears from task list
snapin 3 (reboot after) runs, installs, disappears from task list
snapin 4 (no reboot after) - checked in
(client reboots)
next checkin, snapins 1,2,3 suddenly show up in the snapin task list, and the cycle restarts.

I can break the loop by unchecking reboot after install on snapin 3.

Any idea’s whats going on? this worked on 7224 (was using client 9.x (9.6?))

@Wayne-Workman

Yep - I ended up doing that as well, but things I noted:

Some stuff the AD join and hostname change should be completed first (wsus server and policies and proxy via AD and group policies) - and without the service running, that won’t be completed. Enabling the service at the send of the setupcomplete.cmd means the rename and join hasn’t been completed. Doing it at the beginning, and then running other tasks mean that it will reboot while completing the other tasks.

This is what I’ve done to get the best of both…

example sysprep.cmd

sc stop FOGService
sc config FOGService start=disabled
sc stop FOGService

copy \\fog\Deploy\W10\unattend.xml %systemroot%\System32\sysprep\unattend.xml
mkdir %systemroot%\setup\scripts
copy \\fog\Deploy\W10\setupcomplete.cmd %systemroot%\setup\scripts\setupcomplete.cmd

net use * /del
del c:\users\administrator\desktop\*.lnk
c:
cd \windows\system32\sysprep
c:\windows\System32\sysprep\sysprep.exe /quiet /oobe /generalize /shutdown /unattend:unattend.xml

and my setupcomplete.cmd

@echo off
del /Q /F c:\windows\system32\sysprep\unattend.xml
del /Q /F c:\windows\panther\unattend.xml
net user Administrator /active:yes
sc config FOGService start=auto
sc start FOGService
net use * /del
exit

Then the snapins run after fog service renames and joins the domain.

The reason I use snapins for everything else - because I like my setupcomplete to be simple and fast - anything I want beyond the basics, I can choose to implement or not without changing the setupcomplete; just add the snapins (which for @RLane, would be the windowsupdate snapin).

I used a snapin for tasks like this - because I found fog service was renaming and rebooting before any tasks that took more than a few seconds in my setupcomplete.bat. Any snapins are installed after domain join, at least by my testing.

Snapin Run With : %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
Snapin run with argument : -ExecutionPolicy Bypass -File
Snapin File : WindowsUpdate.ps1
Snapin Args: Y Y

Snapin Command should look like this:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File WindowsUpdate.ps1 Y Y

That should work fine - and it seems snapins are pushed in order now, so I have this snapin named as 005.wsus for example.

@george1421

Same dhcp server, same scope. The VPN is hardware tunnel, so any computers @ both sites act as if they are in the same physical network/scope.

@george1421
Thanks George - I had contemplated that, but I’d have to then have different pxe boot structures.

I have already written a bit of a bodge script that checks multicast tasks on my main FOG server, and starts the UDPCAST process on the storage server if the image is found locally (storage group and image = local). This seems to have worked for my purposes.

Thanks everyone for their input!

@Wayne-Workman
Yep - I had noticed. 170 gigs worth of images @ full speed of the VPN connection doesn’t outpace sneakernet in this case though!

wow… I haven’t referenced sneakernet in way to long a time

@Tom-Elliott

The image is only stored on the second server - hence the separate storage group. The reason for this is the middle is a VPN - FOG13 sits on one side, and acts as a storage server for systems on that side. The other storage server is on the other side of the VPN. Replication between the 2 should not happen as they are 2 different storage groups, and is undesired as the VPN is well… too slow

The trick is, I’d like to be able to multicast from either storage group, so I can essentially pick which server to use.

It won’t kill me, and I’ll probably bodge a script or plugin eventually. Unicast works fairly well in the mean time.

Thanks, good to know Wayne!

I’ve got several test images, and was about to delete multiple old images :
Image management > all > select 1 or more > delete selected images

I get a 500 ISE

[Wed Apr 20 20:04:15.872957 2016] [:error] [pid 45782] [client 10.1.0.130:62643] PHP Fatal error:  Call to a member function get() on null in /var/www/fog/lib/fog/fogpage.class.php on line 487, referer: http://fog13/fog/management/index.php?node=image&sub=list

Wow… that seems like a lot of bother, and possibly recipe for an “oops”!

It seems to me (OMG, I am so no volunteering to figure out how to do this out… yet), that there should be a way to have a storage server check in with the main server to see if it should be creating multicast host processes, and the main server to point the clients to the correct storage server.

Future Feature request? :):)

I have 2 fog systems:
FOG13 = main + default storage, only member of default
FOGStorage02 = storage only, group #2, only member of #2

Multicast works fine when using an image stored on FOG13, but fails with

[04-20-16 7:13:40 pm]  Task (3) Multi-Cast Task failed to execute, image file:/images/W10Audit_05 not found!

when attempting to start a multicast for an image on group#2

Is this not supported for images not on the default storage/group/main server?

@Tom-Elliott

FOG13.domain.local = FOG + storage node (Default, only member, replication enabled (to nowhere))
FOGStorage02.domain.local = storage only node (ID#2, only member, replication enabled (to nowhere))
Running Debian 8.4, PHP Version 5.6.19-0+deb8u1

Log is from main fog server (FOG13) running 7242 (updated now), FOGStorage02 also 7242.

I updated to 7196 yesterday to reconfirm another issue, and at that time journalctl entries changed to

Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3
Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3
Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 4
Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGService::getDateTime() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 92
Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 90

every 3 minutes. These entries persist to today, after updating to 7242.

I haven’t confirmed if the services are functional at this time.

@Tom-Elliott

Thanks Tom!
(wow, that was fast!)

Updated to 7218 (latest as of this post). Same issue - file uploads fine: Edit afterwards, and the file is truncated.

Sure:
So I have a snap in - in this case for example a snap in that installs chrome. The file was uploaded via the fog web interface originally.

I go to edit - eg add some description, anything really. The snap in file is instantly truncated to 0 length when the update button is pressed.

Before update: Notice the file size of googlechromestandaloneenterprise64.msi

After update: Notice the file size of googlechromestandaloneenterprise64.msi

Relevant apache log entry:

POST /fog/management/index.php?node=snapin&sub=edit&id=4&tab=snap-gen HTTP/1.1" 302 498 "http://fog13/fog/management/index.php?node=snapin&sub=edit&id=4" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"

I’m not sure if this is related or not - I’m using Debian 8.4, with fog trunk (git 7190).
The service master logs aren’t showing any issues, however if you check the output from the daemon itself

journalctl -u FOGImageReplicator.service

this shows up

Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Warning:  Error while sending QUERY packet. PID=11398 in /var/www/fog/lib/db/mysql.class.php on line 49
Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Fatal error:  Using $this when not in object context in /var/www/fog/lib/service/fogservice.class.php on line 77

This repeats every service loop (approx 3 minutes) . This isn’t restricted to ImageReplicator either, all FOGservices are affected

journalctl -u FOGMulticastManager.service
journalctl -u FOGPingHosts.service
journalctl -u FOGScheduler.service
journalctl -u FOGSnapinReplicator.service

My imagereplication, snapin replication, multicast, etc aren’t working either. I haven’t had time to delve into the why’s as this isn’t mission critical yet for me.