Great request. I think this can be done without too much difficulty. It would actually solve a lot of issues with locations.

I believe I can do this with PHP, and then Tom might take my example work and improve on it.

@Quazz said in Windows 10 Imaging, first images works great, then fails every other image:

Lenovo thingies?

Correction - Bloatware.

I’m confident the installer doesn’t touch iptables or firewalld. The plainrouter and router and other stuff in .fogsettings is only for configuring DHCP. I think that DHCP is messed up.

If you modify /opt/fog/.fogsettings and change these fields:

dodhcp='Y'
bldhcp='1'

To:

dodhcp='N'
bldhcp='0'

Then the FOG installer will never again touch the DHCP configuration or DHCP service. Then you can configure /etc/dhcp/dhcpd.conf the way it needs to be for your setup. Feel free to post this file to get help with configuring it if you need.

@fjarken said:

Ah yes I have STP setup on my network, I came back to this thread again, cause I found a conflicting IP with my fog server…which I think was the root cause. A switch on my network had been configured with the same IP.

I’ll be sure to start asking this… seems its a more common problem than what one would think.

Gotta love happy endings.

@Tom-Elliott said in Location plugin by subnet:

As if you’re on subnet 255.255.192.0 and you originally set the DB value up to 255.255.0.0, you’d be far and away off.

People should have their settings correct. This is another thing that can be corrected for at installation time for storage nodes.

@george1421 If you know the IP address of the host requesting imaging (which you can get via PHP), and you have an IP and subnet mask for all nodes in the DB, you can just calculate what one it should use. The individual host doesn’t need to pass a subnet mask.

This setup would require the least amount of change to FOS and/or client (none at all), and a subnet mask field for nodes would be needed.

@george1421 Completely agree. I’ve been meaning to collect all of our information and put it in one spot. I’ll start on it tonight at least, and at least get all the links together.

@dureal99d I’ve been on dnsmasq’s mailing list for about a year now. Simon Kelly - creator and maintainer of dnsmasq - sends out an email with answers to questions about every day or every other day. You can get on this mailing list, and you can email him questions like I have, and he’ll respond. As with anything, include as many details as possible. The link to the mailing list and such is below.

http://www.thekelleys.org.uk/dnsmasq/doc.html

@no1bossman said:

problem. Since this thread as suggested I created a new FOG Server instance on a CentOS platform. Unfortunately I had difficulty during the FOG Server installation; with the additional server components that the system require – specifically MySQL, and the outdated repository sources.
https://forums.fogproject.org/topic/5171/vmware-vsphere-ide-hdd-image-store

I conducted more research and have since decided to continue with Ubuntu, while utilising a Windows

FOG 1.2.0 would have difficulty installing on the latest CentOS, the latest Ubuntu, the latest Debian, etc.

MySQL has been depreciated in favor of MariaDB. If you were to install mariadb, mariadb-server before running the installation, it’s likely to succeed.

However, these issues are resolved in FOG Trunk.

If you have some time and are willing, I could try to help via Team Viewer, just chat me up.

Oh and you can find examples of NFS mounting here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS

I’d be against that.

The certificate is the central and single point of success or failure of security for the fog client. If an attacker could get it by any means at all, all security is compromised. Having an actual feature that allows it to be downloaded would increase the risk of compromise several times fold.

a local admin ought to be the only person that can touch it.

Although older, I can confirm the Dell Poweredge R410 runs CentOS 7 just fine. It runs VMs like a champ using the Linux kernel’s built-in virtualization capabilities.

@dureal99d Just found this in Simon’s archive:

https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg00895.html

Are the images partclone or partimage ? If they are old partimage images and not set as such, it wouldn’t work.

I think that credentials put into storage management for a node ought to be checked for validity. And if they are invalid, they shouldn’t be stored and a warning message displayed for why and what to do.

@george1421 Done. All the work in that thread you referenced needs to be moved over to the new documentation platform… I need to get going with that myself.

@george1421 said in Host Startup; Booting into LVM Disk Fails:

Sooo… as a test please edit this file /var/www/html/fog/lib/fog/bootmenu.class.php

Along the same lines, you will find this at line 142 concerning grub that is easy to snipe:

'rootnoverify (hd0);chainloader +1`

Maybe change hd0 to hd1 and switch the host to grub and see what happens.

I think you need just some switch / router configuration done.

It is possible to image across WANs and through routers and across subnets - not really advised - but it’s possible.

technicians at my organization are being confused.

If a host is already in tasking (imaging or snapins), when they try to image via the fog boot menu it just throws them back to the boot menu. They think their passwords are bad.

I think it’d be a good idea to say some sort of message here somehow, along the lines of “Host already in tasking”.

@x23piracy No, it’s not. It’s just the only one that works with Surface Pro 4s. We need to find out why, but the developers don’t have any Surface Pro device to test the code commits around that time with. Someone has to step up and send Tom or George or myself a Surface Pro to test with. That’s all we need to get this straightened out - it’s all we need to have real documentation.

You have to path to the executable or include PATH in the crontab itself.

so if you ran command -v grsync it would give you the full path, you’d use this full path instead of just grsync. Or you could just stick the path at the top of the crontab file. echo $PATH and then take the output and put it into line 1 of the crontab as a variable like PATH="put the path output here"

Read through this, they may make better sense than me. Plus I’m tired. http://stackoverflow.com/questions/2388087/how-to-get-cron-to-call-in-the-correct-paths

You might be interested in reading this: https://wiki.fogproject.org/wiki/index.php/FOG_security

It’s old… but it’s there.

also, this: https://wiki.fogproject.org/wiki/index.php/FOGUserGuide#Full_Listing_of_Ports_used_by_FOG_server_and_client

I would think you can’t really “make” fog use one port for the actual imaging process (via NFS) because it’s going to use open ports to separate traffic streams, esp. for multicasting.