Posts made by george1421

Just reading between the lines here…

Each client have its own key (Education version), Before, after deploiment, licence key was activated in system properties of each PC.
But, with deploiements done recently, not actually, windows appears not activated. Wrong key format ?

and

I keep windows 10 16 07 version

Gives me the impression that the OP has Windows Education OEM installed and trying to deploy 1703 to these systems and the systems are failing to reapply the OEM key. If this is correct there could be a EULA compliance issue since you need a VLK key to support imaging. If this was true then the OP should have a single VLK key for all computers and not individual.

Aside the legal question here, I have a question for the OP

@lebrun78

1. Once the images are deployed can you manually key in the license key and manually activate the system?
2. Just after imaging, does the target computer have direct access to the internet? (activation via fog still requires internet access to activate).

@anthony-delarosa Yes that is the right setting, default check in time is 5 minutes. But if you can hold off a day or so until we can test the php-fpm code. I want to see if it makes a difference on the default settings for FOG. In ‘theory’ it should make a dramatic difference in overall FOG performance.

@anthony-delarosa Excellent, thank you.

Here are my thoughts on how to set this up. I’m only posting below for my reference. I want to spin up a Cento 6.7 FOG server tomorrow and test the process out before you implement it. I also want to see if memcache will help with the process too. But I need to do a bit more research first.

# yum install php-fpm
# chkconfig --levels 235 php-fpm on

Edit /etc/php-fpm.d/www.conf to use sockets

# vi /etc/php-fpm.d/www.conf

;listen = 127.0.0.1:9000
listen = /tmp/php5-fpm.sock

listen.owner = apache
listen.group = apache

# service php-fpm start

Setting up Apache and mod_fastcgi

Install the RPMForge repo:

# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
# rpm -ivh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

Add some priorities which repo to use:

# yum install yum-priorities
 
# vi /etc/yum.repos.d/epel.repo 
... add the line priority=10 to the [epel] section

# yum install mod_fastcgi

Configure mod_fastcgi

If you have php enabled disable it

# mv /etc/httpd/conf.d/{php.conf,php.conf.disable}

# mkdir /usr/lib/cgi-bin/

# vi /etc/httpd/conf.d/mod_fastcgi.conf

LoadModule fastcgi_module modules/mod_fastcgi.so
 
<IfModule mod_fastcgi.c>
	DirectoryIndex index.php index.html index.shtml index.cgi
	AddHandler php5-fcgi .php
	Action php5-fcgi /php5-fcgi
	Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
	FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /tmp/php5-fpm.sock -pass-header Authorization
 
	# For monitoring status with e.g. Munin
	<LocationMatch "/(ping|status)">
		SetHandler php5-fcgi-virt
		Action php5-fcgi-virt /php5-fcgi virtual
	</LocationMatch>
</IfModule>

# service httpd restart

@thebrennan47 Sorry I had your post open from earlier and did not see your latest post.

Did I help you configure this setup? I know I helped someone in the last week or two with a similar setup where each storage node managed a single deployment bench. I only ask just to be sure I’m on the right track because I know it worked (routing) when I was done.

If I didn’t, to turn your storage node into a router, you need to enable the ip_forward kernel parameter, and then make it persistent with sysctl config file.

IN ADDITION, you have to remember that routing is a two way street. In your drawing you didn’t draw an ISP router at each location. If there is one there, you need to create a static route on your ISP router to describe the subnet that exists beyond your FOG-router. The default route for your FOG-router should be your ISP router. The default route for your target computers should be the deployment network interface on your fog server. This will give you the two way routing. At your HQ site, if your target computers need to communicate with the FOG Master node, you may need to create a static route on your ISP router to define each subnet at each remote location. This is a pure routing issue and not related to FOG imaging.

@thebrennan47 Well IMO, I wouldn’t do it the way you did it (yes circle talking at its best).

I would still leave the storage nodes setup exactly as they were. The only thing you was missing is the dhcp server service, which can be added manually.

What you have is a hybrid solution that is not supported directly by the FOG Project, but that doesn’t mean it won’t work.

A storage node can pxe boot target computers, no problem. NFS is setup because it can deploy images no problem. The issue you will have is capturing images, that can only be done by the master node (not a storage node), unless you know a trick. The only thing missing is isc-dhcp which can be added from your distro’s repository. If you view the fog wiki page you can find a great example of the config file needed: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

Now the only caveat with this setup is the caveat with any master node, storage node configuration. The storage nodes and the clients must be able to reach the FOG Master node or the storage node will become useless. The target computers only need to reach the master node if the FOG Client is installed. If the fog client isn’t installed in the reference image then only the storage nodes must be in contact with the master node.

Again, this setup configuration is not a supported configuration by the developers. But that doesn’t mean it won’t work as designed.

BTW: Your picture made it quite clear what you were doing, well done.

@anthony-delarosa In your case you can in crease the check-in delay to help with cpu usage on your fog server. You can do this with the understanding that it will also take longer for clients to see snapin deployments and other assigned tasks. It will not impact image deployment only fog client tasks. (but I’d like to see the results of the php-fpm test before you make this change if you agree).

@anthony-delarosa No the fog client works the other way around, the clients check into the master fog server for things to do. They also post inventory info and such.

Since you have a great performance data so far, I wonder if you would be willing to help the fog project by doing something I had on the back burner for a while.

The idea is simply to install php-fpm and have apache use that instead of its internal php engine. I’m interested to know how that impact:

1. Performance of the web gui
2. Impact on performance of the entire fog server CPU usage.

I see you are using an older OS, but the php-fpm package should still be available in epel or in the centos repository. If you have a little time to test this idea let me know and I will put together a tutorial on how to set this up. Reverting back to the default apache php can be done by just commenting out one line. I would do it on my production fog server, but I only have a small campus. I’ve been looking for someone who had around 1000 clients to see if the test was dramatic.

@anthony-delarosa How many client computers (with fog client installed) are on your network? With mysql at 27% it sounds like you have quite a few checking in.

Hi and welcome to the fog forums.

YES fog has changed many times over since FOG 0.3x.

If you feel you have a understanding of what has changed. I might suggest that you fork the FOG project from github, modify what is needed, and then push the changes back. The developers will look over the changes and potentially integrate the changes into the base code.

Right now I can tell you the developers are on an extended holiday and won’t be back for a little while, so if your change is urgent and you have the skills you might want to do as I outlined above.

The FOG 1.5.0 RC8 is the current rc release. The developers have been working hard on the new UI that is part of 1.5.0 and I think the RC8 is close to the last release before 1.5.0 (stable) is released. So now would be a good time if you need your changes in the code base soon.

[Moderator’s note] This thread is more of a feature request than a technical problem. I’m moving it to the Feature Request forum.

@aksl said in Imposible to boot from hard drive:

Dell Optiplex 3020M.

I think I asked this before, but is the 3020M configured in uefi mode? Its important to know because uefi systems need a different exit mode than bios (legacy) mode. For uefi mode systems you should use the exit mode of rEFInd, sanboot is for bios(legacy) mode systems.

@dew12 Now if after using my config file exactly we will use a different process to understand what is not working. This other process we will capture a pcap file of the data crossing your network. For this test we will need to have the fog server, dnsmasq, dhcp server and pxe booting client on the same subnet. This follow these instructions on how to capture the pcap.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to a google drive, dropbox or what ever file sharing site then either post the link here and we will take a look at it, or if you want you can IM me directly the link if you don’t want to post the link here. After we look at it you can remove the file from the google drive site.

@dew12 Is dnsmasq suppose to be providing the dhcp IP address to the target computers or is it only to supply the dhcp proxy information. The reason why I ask is because your very last line in the config file is wrong. Your ltsp.conf file should look like this:

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,10.0.2.15

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,10.0.2.15
dhcp-boot=net:UEFI,ipxe.efi,,10.0.2.15
dhcp-boot=net:UEFI64,ipxe.efi,,10.0.2.15

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=10.0.2.15,proxy

Now if the above file doesn’t work because of your network environment there is a modification that is required for the pxe-service lines. You need to append the fog server IP address to the end of the line. So this section

pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

would become

pxe-service=X86PC, "Boot to FOG", undionly.kpxe,10.0.2.15
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi,10.0.2.15
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi,10.0.2.15

@dew12 said in Problem with FOG UEFI on Dell Optiplex 3050:

understand that, only rename .efi file to .efi.0 will be solve this problem.

With dnsmasq version 2.76 you do not do this hack above. The .0 file names are no longer needed. So if you renamed this file please change it back since to remain consistent with FOG’s design.

I’m looking over your other data.

[Moderators note] Duplicate post to here: https://forums.fogproject.org/topic/10700/issues-after-kernel-update

Lets first talk about what is going on behind the screen here.

When you capture an image with FOG, it uploads the image to /images/dev/<mac_address>. Once the capture is complete the target computer logs into the FOG server over the FTP protocol and requests the /images/dev/<mac_address> directory to be moved to /images/<image_name> using the linux service account called fog This is the point at which your image capture is failing.

The linux user fog needs to have Read/Write/Execute permissions to the /images and /images/dev directories for this transfer to happen. So I would start there to ensure that the fog user can do what is needed.

First I should say, you re on FOG 1.2.0 you should upgrade to the latest version of fog which is 1.4.4. You will need to be on version 1.3.0 or newer if you need NVMe disk support, gpt format, uefi firmware, latest hardware, and/or native Win10 integration.

With fog 1.2.0, there wasn’t any concept of a 64 bit kernel. So in fog 1.2.0 bzImage is what is now bzImage32. In the current release of FOG bzImage might be called bzImage64 in FOG 1.2.0 terms. The devs have said (but not tested) you can take bzImage32 from the current release of FOG and copy it to FOG 1.2.0 as bzImage to get better hardware support. But IMO you would be better off all the way around to spin up a new FOG server (with a current LTS OS release) and then install FOG 1.4.4 on it. That way you get all of the benefits of the newer version of FOG without destroying your current working system.

@jim-holcomb said in FOG image deploy is failing due to looking in wrong folder?:

my “active tasks” screen only blinks the active task,

I would post that to the bugs forum so the developers can take a look at that issue once they return from their extended holiday. That sounds like a bug in the new web gui to me. If you post it there with any useful screen shots for the devs to review. That would be helpful.

@ashioni Thank you for providing input on this matter.

Also if you are still running FOG version before 1.4.1 then you will continue to have this issue. The problem should have been resolved in 1.4.4, so its recommended that you upgrade to the latest stable release of 1.4.4.

@jim-holcomb Did you have some kind of back channel communication with Tom. He should be on an extended holiday and not lurking around the forums.

In the case of your initial question. FOG uploads images to the /images/dev/<mac_address> directory that is by design. Then FOG will move the image to /images/<image_name> once the upload is complete.

If the images are getting stuck in /images/dev/<mac_address> that typically means you have an issue with the fog linux user user account.

@sgwk I forgot to post in the previous post, is the firmware updated on these target computers? You have multiple systems of the same model some work and some don’t. There has to be something unique about these to cause the variation. Firmware (bois) is one thing.