Posts made by Tony Ayre

Ah, I was unaware of plugins!

Server

• FOG Version: 1.3.4
• OS: Ubuntu 16.04.1LTS

Description

I have now got my setup how I want it, as follows:

Master server at the central site (10.5.140.0/22 range), and a storage server (with TFTP also) at the other site (10.5.144.0/22 range).

We have just been imaging a number of machines and whilst the majority did what they should and grabbed the data from the second site, some of them didn’t. They grabbed the data from the central site. Not a huge problem as we have a relatively good connection between the sites, but it slows the process down significantly.

Can anyone advise how I can stop this happening?

@Jaymes-Driver

Absolutely. Our 2 servers are in different schools, with an IPSec VPN in between. I am currently building a new network consisting of a single domain across all schools, but have to maintain the existing multi-domain setup.

On my firewall, I hadn’t allowed each side to use the other side from my new IP address range. Allowing this on the firewall resolved the issue.

Simply put - the 2 servers were unable to route to each other - there was no route between them.

I would say a good solution might be for the replication services to give an error stating that the server can’t be contacted though.

Ah, figured it out. It was a routing issue between the 2 servers.

It may be worth providing a user friendly error in the log if the master can’t connect with the storage node.

Server

• FOG Version: 1.3.4
• OS: Ubuntu 16.04.1LTS

Description

I have installed a storage node following the instructions on the wiki. All looks fine as far as I can see, but no sync is happening. I am receiving the following error in both the Image Replicator and Snapin Replicator logs:

[02-07-17 10:49:37 am] * Type: 8, File: /var/www/html/fog/lib/fog/fogbase.class.php, Line: 841, Message: Undefined index: storagegroupID, Host: 10.5.147.249, Username: fog

I have double checked the storage node settings on the master server, including ensuring the password is correct. What am I missing?

@george1421 The original post was more to do with the fact that Apache, back when I last used Fog, simply couldn’t take an upload larger than 2GB, regardless of settings. This was even with 64bit at the time.

I’m still a little bewildered by the idea that 2+GB of data is large to be honest.

With 10/40Gbit core switches/server connectivity and gigabit to the desktop, 2GB of data is tiny, even if deploying to hundreds of machines. 2GB over a 1Gbit connection would take 17 seconds to copy (obviously, theoretical, as reality will change that dramatically depending on disk speeds, network congestion etc…).

Whichever way you do the install, that data is still going to go across the network - be it by running from a share or by copying and running it locally on the machine.

@fry_p Licensing depends on the software. However, all the education site licenses I’ve come across in the last 10 years have said the same thing - it applies to a single “site”. So, in our trust that’d be a single school.

@Tom-Elliott Licensing in schools is done by site license usually, meaning each school has its own key for things. There are then limits on how many installs of various packages can be performed. So, yes, licensing is a major reason why we can’t do this.

We also don’t really want to put everything on every computer that would be absurd, especially when we have plenty of computers with 128GB SSDs.

All of this is somewhat beside the point though - we want to do things in a certain way, so need snapins to be able to handle it.

Lets put it this way. I am now running IT for 6 schools and 3 nurseries. Each of those schools has a dozen PC types, with about 3 different roles for each. This number is likely to grow as more schools join our trust also.

So, to create a full image type for each machine with each role would be rather a lot of unnecessary work.

Instead, a single general image (containing the base level of software), combined with Snapins will reduce that work tremendously, along with the storage needs of images.

@Wayne-Workman Why is that? 2+GB files aren’t really that big.

Back in the day, it was the Adobe suite IIRC. Was a 3.5GB installer. There’s a few packages like it though now - SMART Notebook as an example.

Copying, then installing and deleting is more efficient in Windows - the installation happens faster, as the OS doesn’t have to check the installer over the network connection - it is checked locally.

You do give me an idea though - just host the file on a server, and have the snapin run a script to copy it to local Temp and run it instead.

Though, it complicates things of course.

Its been a number of years since I used FOG, and back then there was a limit on the size of Snapins (2GB). Has this changed now?

I’m using SCCM for OS deployment at the moment, and it is great when it works, but it has a habit of breaking and then I have to spend hours trawling through logs to fix! The only reason I stopped using FOG was the 2GB Snaping problem. Would love to start using it again.

It doesn’t look like this is possible at the moment, but would it be possible to use fog to upload/deploy a single partition on a disk?

Eg. Hard drive is partitioned with 100Mb win 7 partition, a drive and a d: drive. I’d want to image the 100Mb bit and the c drive, but leave the d drive in tact.

Any thoughts how I could go about creating this as a function?

At the moment - I’m pretty sure this is a no. As you say, it is delivered from Fog to the client not the other way round.

I’d assume this is by design too - as Fog is the ‘management’ interface then, and allows a central way of managing devices rather than machines being changed remotely ad-hoc.

We have our fog server running on a Celeron machine with 4GB RAM and a WD Caviar Black 7.2k SATA drive. It has a 1GB link to the network and all clients have a 100Mbps link.

We roll out 10 machines at a time, and did an 18GB image on Friday in 15 minutes for 10. So our room of 22 finished in about 40 minutes.

So your spec should be fine.

I’m not sure what the issue is? Does it matter that the partition is slightly differently sized?

Windows 7 should be captured using a multi-partition image type, not single partition - as it has multiple partitions. I believe the one that most use is “[FONT=Verdana][COLOR=#333333]Multiple Partition Image - Single Disk (Not resizable)”.[/COLOR][/FONT]

Problem with that is that in environments where devices are locked down, some admins wouldn’t want some users to be able to install software on machines. For example, I wouldn’t want a student to be able to install something on a teacher’s laptop even though they can log into it.

I’m working on this at the moment, but it’ll be an individual ‘site’ rather than a part of the Fog pages themselves.

I would like to propose a snapin user self service site addition to Fog, much like is possible in SCCM.

Basically, a user would be able to log in to it, and choose from a list of available software. Their choice would get added to their computer’s snapin list and it would install in the background for them - and if the machine were re-imaged, it would reinstall for them too.

It would need some form of ‘user to computer’ mapping mechanism, and integration with LDAP/Active Directory would be a must.

I’ve added a rudimentary version of this to my Fog server here already but a more functional version would be good.

Basically, as Apache2/PHP have a 2GB file size limit, even in 64bit, it would be good to allow fog users to upload snapins via FTP and then for them to be able to choose them via a form instead of having to upload via http only.

It would need some verification to ensure they don’t choose a file of the same name as another snapin (so they don’t end up with snapins left over should they then delete it and the file is then missing for the remaining one).