Topics created by fry_p

Microsoft should consider doing this for FOG as a donation.. .

@sebastian-roth we may have found a workaround since we have a uefi/bios co-existence setup, we are trying to legacy boot to capture/deploy the uefi image. It appears to have worked. I am not sure I want to pursue this issue further since it is a very old model and a one off case.

I appreciate your help on the matter regardless, thank you.

@sebastian-roth @george1421 I may have posted this thread prematurely. I ended up having my colleague try a different type of Ethernet dongle (USB-C vs regular USB) and that did seem to fix the halting issue. I can verify tomorrow, but I think that message in the picture is still there, it just keeps imaging until complete now. I also found out a nice new BIOS came out for this model, so it is possible an update can fix the message. I can test the bios update with one at some point, but we are pretty busy with students returning next Tuesday in person.
I think we can mark as solved in the meantime.

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

My next article will be on load-balancing FOG’s web frontend and database backend… I’ve just not wrote it yet… Don’t wait on me, it might be a while.

@p4cm4n said in Associate all new hosts with Snapin:

assign template host to template group, assign properties to template host.

No don’t do this because it will create a loop. The names have to be exactly the same that is all.

Every host added to the template group will cause the database trigger to fire copying the host template settings over to the host just added to the group.

nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host

Its possible that the settings are made in the database but because of database caching the FOG application may not see the changes until the cache is refreshed. So are you saying that the settings on the template host are not being copied over (like OU or some other parameter field) or is this a question about the snapins not installing?

@george1421 I had to use *.pushbullet.com and *.api.pushbullet.com for web filtering url in Lightspeed setup

In addition to what @Shad0wguy posted, your golden image should be developed on an isolated network, or at least one that doesn’t have internet access for just that reason. You don’t want windows updates to help you “fix” your system while you are preparing for it. If you are doing this in audit mode, for sure disable the windows update service until just before sysprepping it. I myself use MDT to build the golden image so one of the task sequences is to update the windows updates from our WSUS server and not to use direct internet updates. That way the updates are applied and completed in a known state before MDT exits. We will typically sysprep and capture with FOG right after MDT finishes.

But its great you are documenting the problem here and the potential solution. Because if you have the issue there are 100 other folks that will have it in the future. So thank you for helping them out too.

the php dont request the needed memory, it request for the next block. So:
When i has 256M it request another ±20M.
Then I increase to 512M. Then the system claims for another 20M.
Then I increase to 1024M and then the system claims for another 20M

I repeat the actions to accure memory size to 1536M.

If it’s necesary to increase the memory a lot then maybe it’s necesary increase the TimeOut and ProxyTimeout httpd.conf paramenters.

@Tom-Elliott I am willing in a heartbeat. The problem right now may be my “history” of the old trunk builds causing some headaches in the past. I have some convincing to do for my boss, but having solid things that are fixed/improved helps the case. I am also probably going to need to take a medical leave soon and want to have FOG be stable while I’m gone. I will look at the features 1.6 and see if I can’t earn that tester badge again 😄

@fry_p Maybe too late, but in addition to complete a few:

You can configure the fog client to delayed-auto and to reboot the service on each error with the commands below recommended before start it:

sc.exe config FOGService start=delayed-auto sc.exe failure FOGService actions= restart/60000/restart/60000/restart/ reset= 120.

I can say that this idea it’s pretty good. I think in this way you could earn only advantages. It would be hard for me to think about such an idea. LOL. Also, I could advise you to try some team-building games at the conference. In this way, you could make the conference more interesting. On another hand, people will make new friends and will strengthen their communicating skills. We had a similar event in our company organized by team-building. In this way, I overcome my problem of speaking in front of people.

More info about this 🙂

Now we have configurated the client cheout time = 275 seconds. In September we had to increase it to 900, but after the changes we have setup it as I tell, 275 seconds.

This is a capture of goaccess tool:

0_1540379551079_goaccess_RHEL.png

The capture is after 6 minutes of activity, we can see that:
Total request: 8436 -> 23,5 req/sec
1378 visitors requested the /fog/service/getversion.php?NewServise&json page. This says that 1378 client are connected simultaneous.
1 visitor requested /fog/service/progress.php 114 times. This client is doing a download task.

Is necessary take in account that when a cleint is doing a dowload, capture or multicast task, this client asks or reports to the server his advance (yes is very pretty and cool see the progress bar) but this info has a price. The client reports his advance more or lees every three or four seconds, when you have one tasks is “pecata minuta”, but when you have 100 or more client doing download or cpature tasks is a problem, because the php server can not process all request simultaneous and is not only the php server, is the mysql server too.

For example in this capture of htop command (like atop or top):

0_1540380690148_Captura de pantalla de 2018-10-24 13-08-54.png

We can see that the vCores are busy, but not at 100%, the load is high, mysqld is using 221% of CPU. In this moment the server is proccessing only the FOG client requests of the computers, there is no any tasks (When the technicians send download, multicast or capture tasks, the server is burning … literally. I saw the load at 60 or more, the server could not attend the all request and refused them ), In this capture shows the activity of the two NUMA nodes clearly.

Node 0: 1, 2 ,3 and 4
Node 1: 5 ,6, 7 and 8

Where is working the mysqld proccess?

# ./numa-maps-summary.pl < /proc/1787/numa_maps N0 : 636053 ( 2.43 GB) N1 : 14336 ( 0.05 GB) active : 352378 ( 1.34 GB) anon : 649153 ( 2.48 GB) dirty : 649153 ( 2.48 GB) kernelpagesize_kB: 1016 ( 0.00 GB) mapmax : 480 ( 0.00 GB) mapped : 1276 ( 0.00 GB)

In the Node 0.

I downloaded a little script, i forgot from where, that shows the usage of RAM of each proccess:

# ./ps_mem.py Private + Shared = RAM used Program 4.0 KiB + 12.5 KiB = 16.5 KiB agetty 4.0 KiB + 15.0 KiB = 19.0 KiB mysqld_safe 4.0 KiB + 47.5 KiB = 51.5 KiB rpc.statd 4.0 KiB + 49.5 KiB = 53.5 KiB rpc.idmapd 4.0 KiB + 57.0 KiB = 61.0 KiB lvmetad 36.0 KiB + 31.0 KiB = 67.0 KiB atd 4.0 KiB + 73.5 KiB = 77.5 KiB VGAuthService 88.0 KiB + 32.0 KiB = 120.0 KiB rhsmcertd 92.0 KiB + 41.5 KiB = 133.5 KiB systemd-udevd 112.0 KiB + 22.5 KiB = 134.5 KiB sleep 88.0 KiB + 55.0 KiB = 143.0 KiB vsftpd 88.0 KiB + 65.0 KiB = 153.0 KiB gssproxy 148.0 KiB + 23.0 KiB = 171.0 KiB udp-sender 156.0 KiB + 30.0 KiB = 186.0 KiB crond 164.0 KiB + 30.0 KiB = 194.0 KiB in.tftpd 180.0 KiB + 20.0 KiB = 200.0 KiB numad 192.0 KiB + 16.0 KiB = 208.0 KiB rhnsd 128.0 KiB + 83.5 KiB = 211.5 KiB master 176.0 KiB + 35.5 KiB = 211.5 KiB xinetd 188.0 KiB + 54.5 KiB = 242.5 KiB auditd 232.0 KiB + 29.0 KiB = 261.0 KiB irqbalance 192.0 KiB + 88.5 KiB = 280.5 KiB qmgr 208.0 KiB + 87.0 KiB = 295.0 KiB sh 240.0 KiB + 109.5 KiB = 349.5 KiB rpcbind 588.0 KiB + 36.5 KiB = 624.5 KiB systemd-logind 668.0 KiB + 75.5 KiB = 743.5 KiB dbus-daemon 596.0 KiB + 311.5 KiB = 907.5 KiB polkitd 800.0 KiB + 175.5 KiB = 975.5 KiB vmtoolsd 916.0 KiB + 64.5 KiB = 980.5 KiB FOGpxe.sh 936.0 KiB + 135.0 KiB = 1.0 MiB dnsmasq 1.1 MiB + 386.0 KiB = 1.5 MiB NetworkManager 1.4 MiB + 413.5 KiB = 1.8 MiB pickup 2.0 MiB + 101.0 KiB = 2.1 MiB rpc.mountd 2.2 MiB + 67.5 KiB = 2.3 MiB systemd 2.6 MiB + 308.0 KiB = 2.9 MiB tuned 2.9 MiB + 355.5 KiB = 3.2 MiB mysql 2.7 MiB + 846.0 KiB = 3.5 MiB bash (6) 3.0 MiB + 822.5 KiB = 3.8 MiB FOGSnapinReplic (2) 3.1 MiB + 682.5 KiB = 3.8 MiB FOGImageReplica (2) 4.2 MiB + 80.0 KiB = 4.2 MiB nsrexecd 4.1 MiB + 718.5 KiB = 4.8 MiB FOGSnapinHash (2) 3.6 MiB + 1.3 MiB = 4.9 MiB sudo (3) 5.4 MiB + 1.0 MiB = 6.4 MiB FOGTaskSchedule (2) 7.5 MiB + 118.5 KiB = 7.6 MiB glusterfsd 1.9 MiB + 6.1 MiB = 8.0 MiB sshd (7) 2.5 MiB + 7.1 MiB = 9.5 MiB rsyslogd 10.3 MiB + 713.5 KiB = 11.0 MiB FOGImageSize (2) 7.0 MiB + 9.9 MiB = 16.9 MiB systemd-journald 21.5 MiB + 791.0 KiB = 22.2 MiB FOGPingHosts (2) 25.6 MiB + 1.0 MiB = 26.6 MiB FOGMulticastMan (2) 315.4 MiB + 14.6 MiB = 330.0 MiB php-fpm (51) 2.5 GiB + 289.0 KiB = 2.5 GiB mysqld 5.1 GiB + 14.9 MiB = 5.1 GiB httpd (12) --------------------------------- 8.0 GiB =================================

@fernando-gietz I feel foolish now. This taught me the lesson that I shouldn’t change multiple variables when trying to troubleshoot an issue.

Here is a screen shot of my working config:
0_1529084567169_fogworks.PNG

I think I had an incorrect group search DN set. When I put the correct DN I also messed around with the Group Member Attribute. I changed it back to sAMAccountName and presto! Thanks for everything boys!

@tom-elliott not sure how the fog version got mixed… I just ran the git pull and rerun the installfog.sh in command to update to latest in dev-branch.
maybe something in 1.5.0 rc10 that I had that screwed it up going to 1.5.4??
btw, I’ve been running 1.4.4 and been updating in command line ever since.

coming in this morning, the replicator is looking normal. the node usage pie chart is normal compare to the main server chart. before it would show 20-40% as it was constantly deleting and replicating. replicator logs are saying No need to sync which is good.

Interesting to see others in here experienced the same issue updating to 1.5.4

I appreciate the offer but I have to get these computer labs up and running soon. Love the support and fog has been a life saver. 😃

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.

@wayne-workman said in Surface pro 4 gets stuck on init.xz (still):

@fry_p What caused it to be unable to image a Surface Pro 4? Has it ever worked at your location? When did it last work? What’s changed since then?

Hey guys. I realize more info is needed. However we don’t have another surface to test with. I can tell you it has been a while since we have done a pro 4. We did do a pro 3 with the same conditions without issue last week. It has worked at our location before albeit very sporadically with no rhyme or reason it seems. I’d say it has been months since the last pro 4, so I have updated FOG since then. I’m sorry I don’t have more info. If we get another pro 4 any time soon and if I am back to work, we will test. I suppose we can file this away for now. Right now, we only get 4’s for warranty replacements as the new Surface Pro is out so they are few and far between.

@fry_p Any news on this? From your point of view, is there anything we can do right now?

@fry_p said in Failed to close inode:

My bad, is there a way to look at the previous git pulls?

Nut the pulls but the git checkouts you can. Just run this:

git checkout - Switched to branch '....'

You should see the name of the previous branch you were on. Just be careful to not run the installer again being on that “older” branch. Note it down/post here and then switch back to working:

git checkout working

@Sebastian-Roth yes sorry