Posts made by Critchleyb

Solved:

Rebooted the server to get the Snapin Hash working

I migrated an old database of hosts onto this server and it seems the snapin service settings didnt come over with them. So all of the services were disabled.

Snapin Hash log on the server is also showing the following:

[03-27-19 12:46:59 pm] * Starting SnapinHash Service
[03-27-19 12:46:59 pm] * Checking for new items every 1800 seconds
[03-27-19 12:46:59 pm] * Starting service loop
[03-27-19 12:46:59 pm] * * Snapin hash is globally disabled

Hello,

OS: CentOS 7
Version: 1.5.5
Fog Client Ver: 0.11.16

I’m attempting to deploy snapins on a new server, I have a snapin queued in the web portal but its not deploying. The log file for the client has the following:

---

---------------------------------SnapinClient---------------------------------

01/04/2019 11:56 Client-Info Client Version: 0.11.16
01/04/2019 11:56 Client-Info Client OS: Windows
01/04/2019 11:56 Client-Info Server Version: 1.5.5
01/04/2019 11:56 Middleware::Response Module is disabled on the host

the last authentication log:

---

--------------------------------Authentication--------------------------------

01/04/2019 11:54 Client-Info Version: 0.11.16
01/04/2019 11:54 Client-Info OS: Windows
01/04/2019 11:54 Middleware::Authentication Waiting for authentication timeout to pass
01/04/2019 11:54 Middleware::Communication Download: http://10.7.10.2/fog/management/other/ssl/srvpublic.crt
01/04/2019 11:54 Data::RSA FOG Server CA cert found
01/04/2019 11:54 Middleware::Authentication Cert OK
01/04/2019 11:54 Middleware::Communication POST URL: http://10.7.10.2/fog/management/index.php?sub=requestClientInfo&authorize&newService
01/04/2019 11:54 Middleware::Response Success
01/04/2019 11:54 Middleware::Authentication Authenticated

01/04/2019 11:54 Middleware::Communication URL: http://10.7.10.2/fog/management/index.php?sub=requestClientInfo&configure&newService&json
01/04/2019 11:54 Middleware::Response Success
01/04/2019 11:54 Middleware::Communication URL: http://10.7.10.2/fog/management/index.php?sub=requestClientInfo&mac=4C:ED:FB:69:65:39&newService&json
01/04/2019 11:54 Middleware::Response Success
01/04/2019 11:54 Middleware::Communication URL: http://10.7.10.2/fog/service/getversion.php?clientver&newService&json
01/04/2019 11:54 Middleware::Communication URL: http://10.7.10.2/fog/service/getversion.php?newService&json

01/04/2019 11:54 Service Creating user agent cache
01/04/2019 11:54 Middleware::Response Module is disabled on the host
01/04/2019 11:54 Middleware::Response Module is disabled on the host
01/04/2019 11:54 Middleware::Response Module is disabled globally on the FOG server
01/04/2019 11:54 Service Initializing modules

@Tom-Elliott

Thanks,

I’m personally struggling, but I’ll throw it over to our web dev to take a look.

@Sebastian-Roth

Yeah I have taken a look in there. As i say i have limited knowledge on CSS so forgive me if i’m missing something obvious.

When i select the heading panel i can see it gets its values from “.panel-primary > .panel-heading”

Looking in the fog.css file in /var/www/fog/management/css/default I can’t seem to find any reference to .panel?

Hey,

Not so much of an issue as a nice to have, I know some basic CSS but not too much.

I’m just looking to change the color of the containers in fog from Blue to Purple as I now have two servers and want to easier identify them from each other.

Is there a line in the CSS files that I can change to accomplish this?

I’ve found the location of the CSS files, and tried changing bits but cant seem to find the right line to edit.

@Sebastian-Roth

Sorted!

As soon as i imported the hostMAC table they all appeared in the web portal.

For anybody reading in the future:

To Migrate just your Host list, you will need to export both the “hosts” and “hostMAC” tables from the old database using mysqldump, then import them both into the new database. Just doing the hosts table will not make them show in the web portal.

@Sebastian-Roth

Hello,

Seems like the data was imported. Count * shows 1193 entries in the table.

No data showing in the hosts list on the web portal however.

I also attempted to export the database following this guide but just for the hosts table:

https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

using

Old Server:

mysqldump fog hosts > hosts.sql

New Server:

mysql fog < hosts.sql

But no luck with that, it exported fine but when i tried to import no data showed in the web portal.

Thanks, I’ll try that when i’m back in the office tomorrow.

Thankfully I don’t need to transfer the images over, so its a little simpler.

The old server is in use by another team and still needs to carry on working. But hopefully i’ll be able to update it without issues.

Old version was 1.5.0-RC-2

Trying to import to 1.5.5.

I believe the export is what is causing the issue. Has this been tweaked in a later version?

Hi,

I’m trying to migrate my host list to a new server.

I’ve attempted to export the CSV from the old server, however it puts the CSV in a format that seems broken.

Some of the hosts, the MAC hasn’t exported at all, on the ones that it has, it hasn’t put in any semi colons, so FOG refuses to import them.

I have around 700 hosts and it’s not viable to manually enter the semi colons. I also want to avoid exporting the entire database as there are a lot of different configuration settings on my new server as its a different network environment.

Any advice appreciated.

@Sebastian-Roth Thanks for all the info. I’m going to try and get a test environment working as its difficult to test this without affecting a live environment and potentially breaking some of the devices they have booked out later in the day >.<

That way I’ll be able to get a whole lot more info without the threat of running out of time and affecting a live environment!

@Sebastian-Roth I’m not great with it, but could maybe get our network guy to take a look if i was able to replicate it within our office. Not an easy thing to replicate though with the equipment we have available.

They didn’t get dropped, they just fell a few blocks behind and slowed everything to a crawl. I eventually turned them off and the others returned to normal speed.

All the clients were exactly the same, they have Gigabyte GA-Z170M-D3H Motherboard with Intel l219-V Network Cards. I’ve never had this issue unicasting them for the past Couple of years from our main fog server however.

@Sebastian-Roth Hey Again,

Yeah I’ve done several runs. The Same Devices Dropped out which leads me to think those ones have hardware issues. Though before imaging they performed fine.

I only get around 5 - 6 hours in the Live environment to deploy, so couldn’t get extensive testing done. I’m getting the Site to send those devices to our main office where I am going to test deploy on our main fog server to see if it was just the laptop struggling to deploy to them.

I just can’t have such a high failure rate in my environment. Each time one fails and needs to have a unicast deployment to fix it adds 2 hours to the job. And the sites are quite far away and have led to me having some late nights trying to get them back up and running for the next day.

I also tried Half Duplex just to test and the results were the same. All devices were on the same switch & subnet / vlan.

Really stuck with what to do, the idea was to build a solution to re image devices across the country without having to send entire replacement PC’s. But without better hardware to support faster Unicasting i cant see it as a viable option using a portable server.

No luck with the changes I’ve made unfortunately.

I attempted to image 6 devices on the same switch yesterday, only 3 completed deployment.

One stopped at 47% where it fell behind on blocks, Another at 75% and another took too long Syncing between partitions and dropped out.

Not entirely sure what is causing this, but i think its a mix of sender and receiver. Its worth nothing that I am attempting to deploy 150GB on Partition 1, and 400GB on Partition 2 from a mid spec Laptop.

@Sebastian-Roth Thanks for that.

Just to list the Changes I have made to attempt to improve stability:

Within

/var/www/html/fog/service/multicasttask.class.php

Line 491

Added: ' --retries-until-drop 100',
Added: ' --max-bitrate 500m',

Line 641:
Changed Value: From 10 to 30

Ran the following commands

$ syctl -w net.core.rmem_max=26214400
$ syctl -w net.core.rmem_default=26214400

I’m also going to try to only deploy to devices on the same switch as to avoid traffic being passed through our router.

I’ve taken a look at hdparm, but don’t understand how to create postinitscripts or how to use hdparm currently so I’m not going to take a shot at that just yet.

I’m next able to test this out next Tues/Weds. So I will let you know how it goes.

@Sebastian-Roth

Did you actually see each and every client starting the transfer (partclone window filling up with more text and figures)? If not then I expect those clients to have been to slow to join

I didn’t see them fill up with text, the assumption was based on my logs showing “Starting Transfer” and then Timeout Messages coming afterwards for multiple clients.

I forgot to mention something very important. The MaxWait you set in the FOG settings is only used for the very first partitions. Partition two, three and so on have a timeout of 10!

That’s interesting, I did notice that on the partition switch some of the devices came up with a “Clearing NFTS flag” line underneath the Partclone Screen where as some went straight through to partition two. Though on the partition switch the hosts that carried on deploying did within seconds, so I don’t think it reached the Max Wait time of 10 Minutes (I’m assuming 10 means Mins and not Secs)

About the switch and multicast stuff… This is a huge and a bit complex topic. Can’t give you an appropriate answer to that just now. Most switches handle multicast fairly well without config adjustment. The more different components are involved the higher the chance you need to manually adjust configs to make it work properly.

Okay! I don’t entirely understand how it’s all working in depth, I think some of the hosts in my environment might be having issues if the data needs to bounce through the switch, so in the future i’ll image all the hosts on a single switch each time to keep things simple.

Be aware that network equipment or the receiver may be droppingpackets because of a bandwidth which is too high. Try limiting itusing “max-bitrate”.

The receiver may also be dropping packets because it cannot write the data to disk fast enough. Use hdparm to optimize disk access onthe receiver. Try playing with the settings in /proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max, i.e. setting them to a higher value.

I’ve taken a look at these files and they each contain a single value of “163840” without context. Not sure what this value relates to or what an acceptable value to change it to would be.

Could you link to the page you found this info at? I’m also not sure where the “Max-Bitrate” value is and if its on the page I don’t want to keep bothering you!

Really appreciate all the help you and the other devs / mods here take time to give. You lot do a great job, the best support with any piece of software I’ve ever had and its open source! haha.

@Sebastian-Roth Thanks, I’ll work through and see if I get any success. Unfortunately the site I was imaging at I wont be able to head back to, but I’m heading out to another site mid next week.

Interesting stuff about each partition being a single UDPcast session. That explains why some clients were dropping on partition changes, though it is interesting to me that the transfer begun so all of the clients checked in, but then instantly timed out on deploy.

As for network setup, I do have a question on that. As i understand it, Multicasting sends data to the switch, and then hosts request that data and it is pulled down.

Our setup sometimes involve Multiple Meraki 225 48 Port switches that all have an uplink going to a Cisco 4331 Router. The Fog server is plugged into one of the Meraki 225 ports on the same VLAN as the Hosts.

If I connect the FOG Server to Switch 1, and then try to multicast to two Hosts, one on Switch 1 & one on Switch 2, is this going to cause any issues?

I’ve had a look at the logs, It seems like the clients are being treated as timed out with the error:

Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000

I Understand UDPCast is no longer under active development, but is there anywhere in the code that i am able to increase the timeout duration whilst a task is in process?

The FOG setting MaxWait is set to 600, however as i understand it, this is the time it will wait to start the session and doesn’t affect the amount of time UDPCast will wait for a host during an active task.

I finished most of my deployment yesterday, but didn’t start a single multicast deployment where at least 2 clients didn’t drop out, and in my environment this causes some issues as im trying to fit reimaging in before bookings to use the devices and time frames can be tight