Posts made by fogusnew

Solved. See here.
Basically I changed the php version to 7.3 (which took a lot of effort…)

… And it did!
Solved so far. Even the memory limit problem is gone.
Well, I keep this post in case anybody needs this information later.
@admin : You can decide otherwise and delete the entries.

@fogusnew said in Installation / php / mysql / apache2 - I messed it up:

• However, the install script of Fog does not take this password. “Failed” is the only answer it gives.

Hold your breath! I needed to upgrade the database tables. Now the the script has access to the database. So maybe the install script will cure the story…

Hi community!

Well, I think I really messed it up. Trying to get a memory limit error solved (probably) I created a lot of new problems.

Here is the situation:

• I had a debian 9 running with fog for about 1 year
• I updated Fog to 1.5.9-RC2 to get rid of a problem with snapins (could not upload any anymore)
• So I ran into the memory limit problem, but alt least Fog was running (I could deploy)
• To solve this I decided to upgrade the machine to debian 10 to get php7.3 (also maraDB was upgraded)
• This worked well on the first glance, Fog was running deployment was still possible, but apache was still using php7.0
• So I removed php completely and installed php7.3 “manually” (which is standard in Debian 10)
• This put Fog to death. The installation of php7.3 was no problem, but apache was not taking the new php version to action. Whatever I tried.
• As a last resort I tried to run the Fog Install script. This works until the script asks for the root mysql password. I know this password, I wrote it down, I am able to get root access to the database via sudo mysql_secure_installation, I can change it, etc.
• However, the install script of Fog does not take this password. “Failed” is the only answer it gives.

Anyone out there, who can help me sort this out? Any help is appreciated!
Thanks!
Chris

@george1421 said in Upgrade to 1.5.9-RC2 gone wrong:

@fogusnew said in Upgrade to 1.5.9-RC2 gone wrong:

I was looking for memory_limit values in the files I mentioned above.

If php-fpm is managing the php on your FOG server this should be the proper config file /etc/php/7.0/fpm/pool.d/www.conf

This is the proper value to change php_admin_value[memory_limit] Then restart pphp-fpm.

I did that.

How many computers (with fog client installed) are hitting this FOG server? If you have a master node and multiple storage nodes, I need to know all computers from all sites that have the fog client installed.

I run only one bar metal server with fog on it. We have ~60 PCs to manage. I did not hit the memory limit before I did the upgrade.
I’m off site again, but will be back next week. I’ll check everything once more and report back. Thanks, again!

@Sebastian-Roth I restarted the services and the system. I can see the the increasing memory in the log; but still “more” is requested.
@george1421 I was looking for memory_limit values in the files I mentioned above. I doubled them several times from 128M to 256M, and then step by step to 2048M. In all those files.

Still no change.

Thnaks a lot for your efforts

Increasing the memory limit in /etc/php/7.0/fpm/php.ini and /etc/php/7.0/apache2/php.ini and /etc/php/7.0/fpm/pool.d/www.conf does not help.

Well, sorry, that I bring up this issue after such a long time. But I’ve been off site for a while. Now I was able to look at the logs.
I get a white screen and a PHP error

[proxy_fcgi:error] [pid 9320] [client 172.28.171.4:53982] AH01071: Got error 'PHP message: PHP Fatal error:  Allowed memory size of 2097152 bytes exhausted (tried to allocate 16384 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 260\n', referer: http:// .... fog/management/index.php?node=home

when I try to access the “hosts list” page.

a similar one when I try to get to the fog settings:

[proxy_fcgi:error] [pid 9320] [client 172.28.171.4:55178] AH01071: Got error 'PHP message: PHP Fatal error:  Allowed memory size of 2097152 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/fog/lib/fog/fogbase.class.php on line 467\n', referer: .... /fog/management/index.php?node=about

No errors in the php7.0-fpm log
I searched the forum for similar topics, could find some, but can not make a solution out of them.

I had a 1.5.3 running
I upgraded according to the wiki to 1.5.9-RC2.
No errors in the script, so far. Everything went smoothly.

I can login to the WebGUI, but here some problems occur: Several link just show blank pages. Without any content:

• Hosts
• FOG Settings
• Tasks -> list hosts
• Tasks -> active snapins (no tasks are running)
• Several reports just generate blank pages, too.

Please, can anybody tell me how to track this down?

Thanks a lot!
Chris

Dear community!

I found descriptions of the very same problem on several threads here in the forum. See (as example) here.
It’s suggested to check the upload limit, but I already created snapins with several 100MB size and everything worked very well until now. Which means the limit is ok.
This time I wanted to create a simple snapin with ~100MB but FOG would not accept it throwing the error message regarding missing snapin name. Weird.
The only thing I did differently I can think of is this:
I can access Fog from outside my local network. When I do so obviously the bandwidth is far lower than being present. At some point I tried to create the snapin from outside over the internet, but I did not get any response from FOG for a longer time. So I canceled the process (I guess while the upload was still going on). I decided to wait until I was on site again. But since then I was not able to create any snapin whether on site nor over the remote connection.
Could there be a connection?
How do I investigate this?
Perhaps there is some temp file lying around that blocks further snaping creation?

My 1.5.4 Fog is running on CentOS

Thanks for any input on this.

Hi folks!
Thanks for taking time to look into this.
And yes, you’re right about the FOG client. It’s inside the image and the service is activated from the beginnen. While researching I came across the mentioned link after I experienced those problems.
It was just such a weird behavior I was unsure and did not try out the delayed strting of the service.
I’m going to modify my image in the next weeks. If the issue continues I’m going to open a new thread.
Thanks a lot!
Great help from a great community!

Chris
P.S. How to mark this issue as “solved”?

@george1421
yes, they are manageable, but I did not create any special setting. All standard, they just run as out of the box. As far as I remember (I’m not on site at the moment) - they have different ports, most 100Mb/s, but at least one 1GB/s port.each. So that is why the different speeds exist. But at the end the clients of both rooms are connected via 100Mb/s. Does it actually matter which speed is possible between the two switches?

My suspicion is different: After deploying, windows needs to restart at least two times (hardware, get into the domain, etc…) . Cloud it be that the FOG client forces Windows to restart too early, maybe before Windows got all the hardware drivers from online?

@george1421 said in windows 10: deployment in different parts of the network fails:

Also you might want to add some clarity to your original post. I think the 100Gb link is a type-o. Also which room is which in that is it the room with the 100Mb/s switch the failing room or the one with the… maybe 10Gb uplink?

Alright, sorry that was not clear.
Room 1 (the working one): Clients -> 100Mb/s -> Switch (Room1) -> 100Mb/S -> FOG Server
Room 2 (the failing one): Clients -> 100Mb/s -> Switch (Room2) -> 1GB/s Uplink -> Switch (Room1) -> 100Mb/s -> FOG Server

I know that is not an optimal setup… but funds are limited and the network is old

@george1421
First: Thanks for pickung up the topic!

To your questions:

• The machines of the “failing room” that failed to come to life via multicast also failed to come alive via single cast. Only if I moved them to the other room the windows config came to and end.
• I multicast only one room (the failing one). But 10 machines worked very well.

In fact, the deployment by fog seemed to work all the time. But the Windows config after the imaging process got stuck on several PCs.

Hi everyone,
I manage a small network with ~ 80 win PCs. Fog has been a real challenge and tremendous help (before and after it worked). However: I’m still learning.
So I came across a very weird behavious, and I’d like to have some inputs on this issue.

The schools network is basically devided in two big rooms. One (locally) very close to the physical fog server, connected with 100GBit, another - connected through an other single 1GBit / 100Mbit network switch - a bit further away.

I was able to successfully create multicast sessions in the second room, deploying a win 10 1909 image to 25 PCs, without any problems - until … Windows started to configure itself with several reboots. About 15 of he 25 machines got stuck with the message:

Windows setup could not configure to run on this computer’s hardware

The other 10 machines worked well. All the PCs have the same hardware (HP), and the testing of the imageing process worked well.
So I was desperate and tried to image some machines one by one: Unfortunately with the same result. After several hours of research for this kind of error message I decided to give up.
Well, one last try I was willing to make, to find the error. I took one machine to the other room and started the imaging process.
Guess what: It worked without any error. So the soultion was to move each single computer to the other room and do the imaging. Every single machine worked flawlessly.

So how crazy is that?

Any comments? I’d really like to hear your oppinions.

I’m sure it is a windows issue, but it may well be caused by the different network connection. So I don’t know where to put this question…

However: any ideas how to track this down and solve it? I’d like to do imaging without moving machines…

Thanks
Chris

@Sebastian-Roth
Ok, I see. Time is limited! I totally understand this. Well, I’d like to help but I’m have no developing skills at all. I’l try to further investigate the problem (saw some errors in the fog.log)
For the moment this issue can be closed.

@Sebastian-Roth Thanks for your help! I visited the site today only to discover that the webinterface was perfectly accessible. I’ve done nothing.
So that lets me think this was / is a performance issue. The machine the fog server is running on is not a big one, so it’s very likely that this computer performs bad.
However. I also discovered that the snapin was installed on a great number of machines, but unfortunately not on every box. And the GUI tells me that many snapin tasks are still “queued”, even though the software already works on some of the associated clients.

Might this all be related to this weak server machine? I would like to go into details for I really like the fog system and plan to implement it on at least two more sites I work at. Obviously I’d like it to be reliable.
I guess I should open another issue?

@Sebastian-Roth
Well, as you mentioned, it’s the whole installer. I deployed it successfully to ~5 PCs several weeks ago, so I did not think of the consequences when starting a deployment to 27 boxes.
I’m off site now but I will try to apply the suggested solution as soon as I’m at the place again.
I’ll report back then.
Thanks a lot so far!

Chris

what I found - and maybe it is helpful to know - is that apache runs on about 30 instances. systemctl status apache2 gives me two pages of pids. I restarted the server a couple of times - same picture. Is this “normal”?

Dear fog community,
until now everything worked really well for several months.
I’m running fog server 1.5.4 on a simple debian 9 32bit box (via .sh script install). Imaging Windows and also sending snapins worked most of the times.

Today I started the deployment of an office 2016 snapin to ~25 pcs (win10). Since this the web interface of the fog server went down and I can’t access it anymore (error 503). As far as I can see apache, php and mariadb is running.

The deployment did not finish yet (I guess), but - obviously - I can’t see the status… I just can’t access the interface.

Can anybody point me in the right direction to solve this issue?

Thanks so far.
Chris