Posts made by salted_cashews

@Tom-Elliott So I would like to expand our total storage capacity for images, as our main server (and node) are close to max capacity. Would adding a storage node across the network work for this or would I physically need to add more drives? E.g. node 1 has images a-z, but I need more space for 1-9. If I add a separate physical node via the network (node 2), would I be able to keep a-z on node 1 and 1-9 on node 2 and still be able to capture/deploy as normal? I would just have to specify which node to capture/deploy from this point?

Being that I don’t think this warrants another topic thread, I was curious if I added another storage node and set the images to not replicate, if that would simply expand the size of my available storage? If a node isn’t master it can still see other images and I can still store images on that node to be used correct?

@Sebastian-Roth Sweet. Thanks!

@Tom-Elliott said in 2 questions regarding image capture/creation.:

1. Yes, it replicates the image to other storage nodes, if you have multiple.
2. Yes. It captures the image into /images/dev/<macofmachinecapturedfrom>. Once the image is captured and complete, it copies the image from /images/dev/<macofmachinecapturedfrom> to /images/<imagePathName>. If /images/<imagePathName> already exists, it will overwrite it.

If I only have one node does it just ignore the option even if checked then?

This is game changing, I no longer need to fret if I start a capture by mistake haha.

Thank you for such a quick and concise response, you guys are on top of it.

1. What is this replicate option? Does it duplicate the image for redundancy/backup? Essentially I want to know if it takes up storage space.

2. When capturing an image, I noticed FOG’s storage space would go down, but after completion it returned to it’s normal value (after recapturing the same image). Does FOG store a temporary file of the in-progress capture before overwriting the image on the server? I want to understand the process of capturing better, as I had always assumed if I captured over even a bit the image became corrupt even if cancelled before completion.

Thanks!

More specifically, the current resources at my disposal put me at some storage limitations. Now I would have no issue setting up FoG from scratch but the images, those are definitely needed. As such, I would like to back them up. Would this be as simple as copying from the /images directory? Does the MySQL database do anything with the images that would affect their integrity or ability to be identified (by human or computer)?

Thanks.

@george1421 Thank you sir!

Hello, our imaging log has grown quite large and it takes quite a bit for the page to load so I was curious, is it possible to delete imaging log entries or clear the log entirely?

Haha I know that’s why I’m completely dazed. I appreciate the help though, we’ve gained some insight as to how to build our images moving forward because of this.

@Sebastian-Roth said in Deployed CentOS image changes the MAC address?:

ethtool -e enp0s31f6 | head -3

Yeah that’s the weird bit, this is what I get from /etc/sysconfig/network-scripts/ifcfg-enp0s31f6

It doesn’t list a HWADDR or MACADDR which I found baffling. The deployed computer is a Dell PC, and the NIC came with it. The captured image PC is in fact using ASUS hardware under a company called “Ciara”. So that part makes sense.

I’m unable to take pictures on the moment due to the computers being in use but this is what I’ve got in my notes:

(Original build)
Machine 1>ifconfig
enp0s31f6 (only present physical interface)
60:45:cb:a2:86:bd

(Deployed)
Machine 2>ifconfig
enp0s31f6 (only present physical interface)
ether 60:45:cb:a2:86:b4
Actual MAC (and what fog reports on this host): b8:ac:6f:99:3e:b8

It’s only in the CentOS (after deployment) that it does this. On pxeboot it reports the real MAC.

Both machines only have one NIC, and I did some research and tried to remove the 70persistent file under udev and still nothing. I might rebuild the image for this hardware which would be a better idea anyway, I was just curious how it would turn out on a completely different system being built on another.

So we have statically assigned IPs in our dhcpd.conf file that finds the associated MAC and binds the IP. The mac address of the machine in question is not what shows up on the linux box, and is not what was present on the machine I captured from either. It’s a MAC that doesn’t exist in our building.

This does not happen with windows images. Windows images regardless of where they are captured from or deployed to - the physical NIC MAC is respective to the machine it is on/NIC it belongs to. Before, the machine in question had a windows image and it was reporting a different MAC, the correct one and the one that FOG has in it’s registration inventory.

Because “certain MAC” = “certain IP” the machine got a random dhcp IP address and I was unable to remote into it for a period of time until I went to the machine to figure out what was going on.

So on capturing an image with CentOS, and then deploying to a different machine (that is not identical hardware) I get a MAC that isn’t even listed in the fog server. It’s been captured as a “Linux” OS type and a “Multiple Partition Single Disk” image type. Why does this happen? What could I do to fix this?

Original MAC: 60:45:cb:a2:86:bd
New MAC: 60:45:cb:a2:86:b4

@tom-elliott It does, this was incredibly helpful thank you.

@tom-elliott Thank you sir, I just changed it through the fog management webpage. Do I need to change it within php.ini as well or does this overwrite that file?

@sebastian-roth Ah of course, Ubuntu Server 16. Thanks.

Ok so I checked the logs and it pointed me in 2 directions. These are the results of the error log and the lines following in the respective files:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/fog/lib/fog/fogbase.class.php on line 2320
line 2320 reads: foreach ((array)$other as $key => &$oth) {

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 125
line 125 reads: $this->databaseFields = array_unique($this->databaseFields);

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 860
line 860 reads: $methodCall = sprintf(‘load%s’, ucfirst($key));

Is there more to this than I’m seeing? It sounds like we need to be able to allocate more memory than is being allowed?