@sgtrice oh and also 1.2.0 was revision number 2094.

Current revision is 6,200+ somethin. If that tells you anything… LOT of improvements.

@Eldorado There are also more generic instructions in our Wiki here:
https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server

You can also configure the FOG server as a 100% mobile fog server using a project I threw together:
https://sourceforge.net/projects/fogupdateip/

This allows your FOG server to not use a set IP, and sets up dnsmasq for you. Every time the server’s IP changes, all IP settings in FOG and dnsmasq are automatically updated.

@george1421 @Wayne-Workman

Both nodes are back online now. I had a left over “-T” in /etc/default/nfs-kernel-server on the storage node from my attempts to disable NFSv4. What I was reading said NFSv3 doesn’t use TCP and is only UDP. Well, however fog connects it needs TCP with v3.

Here is where I ended, I don’t know if the RPCNFSCOUNT of 48 is needed to be increased from the default 8, but I read that this increases the threads for nfs workers.

/etc/default/nfs-kernel-server

# Number of servers to start up # To disable nfsv4 on the server, specify '--no-nfs-version 4' here RPCNFSDCOUNT='48 --no-nfs-version 4' # Runtime priority of server (see nice(1)) RPCNFSDPRIORITY=0 # Options for rpc.mountd. # If you have a port-based firewall, you might want to set up # a fixed port here using the --port option. For more information, # see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS # To disable NFSv4 on the server, specify '--no-nfs-version 4' here RPCMOUNTDOPTS='--manage-gids --no-nfs-version 4' # Do you want to start the svcgssd daemon? It is only required for Kerberos # exports. Valid alternatives are "yes" and "no"; the default is "no". NEED_SVCGSSD="no" # Options for rpc.svcgssd. RPCSVCGSSDOPTS="" # Options for rpc.nfsd. RPCNFSDOPTS=""

/etc/idmapd.conf

[General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname Domain = localdomain [Mapping] Nobody-User = nobody Nobody-Group = nogroup [Translation] Method = nsswitch

/etc/default/nfs-common

# If you do not set values for the NEED_ options, they will be attempted # autodetected; this should be sufficient for most people. Valid alternatives # for the NEED_ options are "yes" and "no". # Do you want to start the statd daemon? It is not needed for NFSv4. NEED_STATD= # Options for rpc.statd. # Should rpc.statd listen on a specific port? This is especially useful # when you have a port-based firewall. To use a fixed port, set this # this variable to a statd argument like: "--port 4000 --outgoing-port 4001". # For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS STATDOPTS= # Do you want to start the gssd daemon? It is required for Kerberos mounts. NEED_GSSD=

@MRCUR said:

KMS would be easiest for both Windows and Office.

If you have a KMS server setup for MS Office, and if you have the KMS version of Office installed on your image. 🙂

We use a Windows KMS here for MS Office.

@_mateo said:

Since I’ve taken so much of your time I’d like to contribute, if I can!

We always need people to answer basic questions here on the forums for newbies. We always need people to update the Wiki, add hardware reported to the hardware lists, to convert tutorials posted in the forums into polished Wiki articles. to add common problems to the wiki based on things posted in the forums. There are lots of ways to contribute.

The easiest way is to maybe once a day (mornings are best) just quickly browse through the recent threads and see if there are any you know the answers to. Probably 30% to 40% of things posted here are newbie questions.

@Wayne-Workman Yeah I ended up doing that, I guess as long as my p2ving is what made it angry then there’s nothing to worry about.

I did just setup something like this last friday. Its documented in the first link Wayne posted (it did take a bit of noodling to figure this one out). The key/trick is to use a bind-mount (like a super-duper symbolic link). You can’t use symbolic links because NFS can’t share them and/or NFS doesn’t have the concept of share aliases. The bind-mounts NFS can follow and share. If you use the bind mount then you don’t have to do anything FOG since fog still sees the /images folder, the OS redirects access to the mounted directory.

The only caveat I have to say about my setup is that I have not uploaded an image yet to this setup. I can affirm that the download works as advertised.

@glienhard Another option would be, when you see that error, to run:

git reset --hard

@Wayne-Workman
Yes, I tried both trunk and no trunk version.

The trunk version was more broken with my clients than the 1.2.0. Image upload would show the size of full disk (deploying to a disk with smaller total size would not work.). Normal deployment did not work at all either, it would only fail when starting.

@george1421 said:

There were a couple references to this “with a partition scheme suitable for EFI”. Which makes me wonder if there has to be something done special with the init fs to make it efi suitable??

Interesting. Haven’t thought about this before. Well we do have FOG (FOS) running on several different UEFI machines. So I am certain that it works with those inits Tom is building. AFAIK there is no partition scheme involved. initrd is just a compressed image file - no MBR, no partitions, no GPT …

OK with the linux comfort level much higher than the typical FOG admin has and your (eventual) intended scope I would say that FOG would work well for you (lin and win). The only concern I have right now is" Does the FOG OS (FOS) kernel support your server hardware. This support is required for imaging only. The issues I can see is support for the NIC(s) and any raid controllers used during the imaging process. The FOS image has support for the majority of the desktop hardware, servers tend to have specialized NIC and disk configurations. Once the OS is loaded then the client OS is your issue.

If you have locations/servers behind slow links (such as a site to site mpls/vpn) you may want to deploy storage nodes at those locations. Those storage nodes will contain the deployment image and the ipxe boot files for that location. The deployment is still managed from your master FOG server, but the deployment happens remotely. If you use the location plugin for FOG you can set up locations for each remote site, then assign storage nodes and client systems to those locations. This ensures a client will not try to image across your site to site vpn link.

So what to do next? I would spin up a test fog master server. The stable FOG release is about 2 years old. Newer hardware may not be supported with the stock kernels. I would update the kernels to the latest that are supported under 1.2.0 stable (I think they are 3.19.3) to ensure your hardware is supported. Ensure your proposed target hardware can pxe boot into the fog ipxe menu. Then run the compatibility test. This will tell you right away if FOG is a viable option.

If your target computers don’t boot well, I would then recommend you upgrade to the trunk release ( 1.3.0 beta). This image is still in beta state, and is a bit more like a 2.0 release than a minor upgrade. This environment has many more options than the 1.2.0 stable release. The developers are working hard to get the 1.3.0 solid. Right now they are working hard on EFI support which has delayed the stable release a bit.

So what is the actual error you see after this. From what I see on the picture everything seams fine. Don’t see an error here. We need the error to be able to help. Or a PCAP file! 😄

Also,

From the image page, you can go to the image you want, and go to membership. Select all the hosts you want in that image assignment and add those hosts. A host can only be assigned to one image at a time, so all will automatically be “mass changed” as you described it.

I think this might have something to do with it:
https://forums.fogproject.org/topic/6626/quick-image-accepts-blank-password-for-users-6207

@greenfog The image is not a resizable image type. If it was taken from a computer with a HDD capacity larger than 128GB (which it likely was), then that’s why the image download is failing.

@Tom-Elliott
Works perfectly now! Thank you very much!

@apathetic_admin https://forums.fogproject.org/topic/6603/opt-fog-snapins-disappearing/18#

I’ve added @Wayne-Workman’s code and actually (I think) improved upon the snapins creations/edits altogether. Hopefully this is properly solved. Thanks for the patience.

@Wayne-Workman

I think so, if any new info or issues related comes up I’ll post.

@Wayne-Workman The thing I noticed with the installer script is that it will skip over the database updates if there are already settings. That installer needs to replace the settings in the database as well as update the exports file.

Without configuring the p255p1 and em1 the network ainºt working.(as i have no connection to server)

It works like this :

auto em1 iface em1 inet manual bond-master bond0 bond-primary em1 auto p255p1 iface p255p1 inet manual bond-master bond0 auto bond0 iface bond0 inet static bond-slaves em1 p255p1 bond-mode 2 bond-miimon 100 address 192.168.137.51 netmask 255.255.255.0 gateway 192.168.137.1``` and this is what i get : ```root@fog1:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: p255p1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff 3: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000 link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether e8:39:35:63:fa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.137.51/24 brd 192.168.137.255 scope global bond0 valid_lft forever preferred_lft forever inet6 fe80::ea39:35ff:fe63:fabb/64 scope link tentative dadfailed valid_lft forever preferred_lft forever```