Simple.

You can not NFS share an NFS share.

What does this mean:

You have mounted the NFS Share to your FOG server. Then you’re trying to make that share be NFS shared from the FOG Server.

So you’re NFS sharing an NFS share. This is simply not allowed.

If you want the NFS share to work with minimal issue, you would need to setup a new Storage node, that just points to the relevant information for the NAS itself.

So, for example, you would create a new node within the group called:

NASNode
ipofnas
/volume1/images

etc…

There’s likely many posts with more direct implication of setting this kind of thing up.

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Essentially that will do what you’re looking for.

You do not install the fog software directly. You just need to configure the node to have FTP and NFS.

You will miss a few little details such as disk size and what not.

What version of FOG is installed?

Why not just rerun the installation script? This should recreate the missing dev folder and files as well as make sure they’re set to the proper permissions.

@Quazz is giving the right information, but If you’re using a fog version of 1.5.7 or earlier (I believe this was where we added fogproject as opposed to fog user) then the likely issue is here.

From what I can tell:

1.5.4 was missing the items for this accidentally.

Doing a compare from 1.5.4 to 1.5.9, I see that the config items have been added.

Maybe updating your instance will provide you with the missing items?

@george1421 I think the capture task could have a “allow bitlocker capture” or something similar, along the same lines as “Schedule as debug” task.

This could be interpretted as a kernel arg.

This would be extremely simple and require no Schema change at least.

Thanks for letting me think it through.

The only change is a minor GUI addition and a little change to the Init fsType script.

I don’t think we need to worry about bitlocker on a deploy task.

@george1421 the postinit could re source the funcs file at the end.

The “Unable to locate image store” message comes from not finding the image in the location it’s expected.

Meaning: The path you have set for the image is not the true path expected for the image.

Look at the host that’s giving this error, what image is associated. Look at that image, and find out the path it’s expected to exist at.

I have seen this with you setup in the past. I know you move images off and on from the datastore to a backup, and then put them back when needed. My guess is there’s a typo on the path that you restored.

@JDnoble18 download it to the fog server. Run it. That’s it.

How you run is up to you. But I’d say do sh ./renumberImageIDs.sh once it’s on the fog server.

@kenm FOG Client version went from 0.11.19 to 0.12.0 I believe.

The FOG Client does auto update when it can. I suspect this is part of the “chatter” you’re seeing. Though I’m more keen to know if the fog client is even running properly on the machines.

Understand, September was an expiration of a code signing certificate for 0.11.19 and a new one was created for 0.12.0, but we’ve seen some issues with the client auto updating. It appears like it cannot see the FOG Server CA, and seems to be fixed by uninstalling the client and reinstalling it.

Not sure how much more help can be gleaned from this though.

@lewis There is no “script” file that is used. This is stored in the database.

Specifically:

FOG Configuration Page -> iPXE Menu -> fog.deployimage

@tech04

I’d recommend looking at the configuration file for refind and seeing if making changes within the file helps out even with newer refind versions.

I think this only because I believe “new” versions of refind add functionality that did not exist with the older versions.

https://forums.fogproject.org/topic/11146/refind-initializing-after-disable-secure-boot/8

This post kind of describes what things to look for.

Particularly of interest, I believe you would want to change scanfor line from:
scanfor netboot,internal to possibly scanfor netboot,hdbios,internal.

The next change will likely be the scan_delay option. It currently defaults to 0. I would recommend adding a 5 second delay here as this is likely what’s hanging the initialization. 0 means don’t wait for any time to start looking for boot devices. So while it’s initializing, it’s also expecting to find the drives (which may not be ready yet).

I would recommend setting the timeout from -1 to 5 as well just so you can ensure all is working. If it works with either (or or and) scan_delay and scanfor, then reset the timeout to -1 to automatically and immediately boot to the first found item.

@sebastian-roth @Chris-Whiteley setting deploySnapins: -1 will tell the system to deploy all snapins associated with the host. If deploySnapins: true as well, it will set the value to -1 automatically. I forgot about that portion sorry.

@plegrand Groups do not track what snapins are associated to them. It’s just too complex to get right and extremely error prone. Even the things that do track it’s extremely tedious.

Why you ask?

Well, let’s just use some medium numbers to show what I mean.

Let’s say you have a group with 500 hosts in it.

You originally setup the group so all hosts had the same snapins. (Easy to do, just update the group accordingly.)

Now you go to one of the hosts directly, and you remove the snapin from that host. Now you go back to the group, and the group now doesn’t know anything about the snapin on all 500 hosts.

Remember, groups in FOG are not a persistent thing. This is because you can associate a host to multiple groups. Groups, in FOG case, is basically a mechanism to mass update hosts.

For example:

One group to set machines up for specific snapins, but another group that you want to set machines printers, (the machine sets are different, but you might want to cross machiens.)

@detoss so getting very much details.

-rwxrwxrwx is what you see files appear as. Similar for directory but the 1st dash will usually be a d, denoting directory.

Notice there are 3 groups of rwx.

r=read=4
w=write=2
x=execute=1

First grouping rwx (left to right) = owner
Second grouping rwx = group
Third grouping rwx = other/everyone

So to make owner group and other have max permissions

777

Does this make sense or at least start to help?

There are other pieces to this but this is most likely what most people want to understand.

The chmod command is short for change mode. Mode here basically means permissions.

@julio said in droit:

bonjour voici mon fichier /etc/exports. j’ai ajouter ces deux dernière lignes pour un test mais elle ne fonctionne pas toujours.

I’m not quite sure what you’re looking for.

First things first, the fsid elements must be unique.

Meaning these lines are good.:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

But the following 2 items are not good as they are overwriting the configuration for the first 2 items.

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Should more likely be:

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=2)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=3)

@devrick The funcs.sh script resides on the init folder, not on your local server.

@tomtom2770 Not exactly nicely.

While linux allows more than 15 character hostnames, windows does not. For this reason, the GUI was coded for Windows based machines. (Start with the most restrictive set)

https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L418 is the first part of the hostname limitation for creating new hosts.
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L1038 is the second part for editing hosts
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/fog/host.class.php#L638 is the third part for checking if the hostname is safe. Of note, the check is a regex, which can be changed for your needs. For the length specifically edit the 15 in the {1,15} portion.

You can change these however you like, but remember that changing this will not maintain these changes when you upgrade. Also, remember making the changes will allow you create hostnames on any entry longer than 15 characters and your environment may not like this.

Also, this only impacts the UI. There are some similar checks in the inits when you are trying to register hosts through the PXE menu item.

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L164 Is the file that truncates hostnames to 15 characters. You’d have to comment the whole if statement to allow registering hosts with different length names. Of course there’s not validity checking so that would be handled in the UI elements.

@sborgne I’d start by cancelling all existing tasks:

UPDATE tasks SET taskStateID='5' WHERE taskStateID IN ('0','1','2','3') AND taskTypeID IN ('12','13');

@katerkarlo99 when creating the host via api, you can associate snapins, printers, groups, and modules using the ids of the relevant item as an array using the respective key as the object identifier.

For example, creating a host with associating the client modules your data element would be:

{
  "macs" : [ "00:01:02:03:04:05" ],
  "name" : "hostname",
  "modules" : [ 1,2,3,4,5,6,7,8,9,10,11,12 ]
}

Or very similar.

The api call would be to /fog/host/create of POST request.

@johannesd How did this file get created?

It doesn’t seem to have the correct permissions. First, it’s blocked off as only owner can read and write to it. (-rw-------) and that means ONLY root can do such a thing.

While permissions directly shouldn’t be an issue, the owner most likely is as a web request is what’s providing information. So basically, your FOG Client is polling for the certificate and one cannot be read.

You can fix this a multitude of ways, though I would start with the most restrictive set first:

From the fog server, ssh
sudo chown fogproject:apache /opt/fog/snapins/ssl/.srvprivate.key (If using Ubuntu change apache to www-data)

If this still doesn’t work, I’d at least suggest rwxr-x— permissions:
sudo chmod 750 /opt/fog/snapins/ssl/.srvprivate.key

If neither of these seem to work then you can try ensuring configuration is set for the folder and rwxrwxrwx for all files in the folder with:
sudo chown -R fogproject:apache /opt/fogsnapins/ssl
sudo chmod -R 777 /opt/fog/snapins/ssl

(Again cahnge apache with www-data if running Ubuntu/Debian variant.