@JJ-Fullmer No, I’m not. I see the same as you, an nginx 403 page.
I think that for the domain fogproject.org a DNS CNAME record should be made:
docs.fogproject.org IN CNAME readthedocs.io

I have admin access to readthedocs and I have removed this domain temporary until the DNS is fixed. For now you can see the first results under https://fogproject.readthedocs.io

The initial structure is now in github and I think it is best if we spread the documentation across many files, as this decreases the chance of having merge conflicts when together working on the documentation.

@Sebastian-Roth : then don’t rush for me. What I can do for now is install the fog client and then copy the modules.dll that uses codepage 850. I have already created a script that does this. I will use this script to roll out the Fog client to all existing workplaces with psexec.

I will create these accounts and will let you know.

I have to dig some deeper into sphinx/readdthedocs, but I know many projects have documentation for different versions.

Take Ansible as example: https://docs.ansible.com/ansible/latest/index.html In the top left part you can choose a version. I think this would be handy for Fog as well. A new release: a new set of documentation where you can make the changes that are specific for that version.

I have played with sphinx/github and readthedocs.

I have created an account at github: jgoedbloed. The github account is also used for readthedocs.

If you look at my test project in github: https://github.com/jgoedbloed/docstest
then you’ll see the ‘docs’ folder that contains all documentation (for now this is just a skeleton, no useful information to be found here).

I have set up a readdthedocs account https://jgoedbloed-docstest.readthedocs.io/en/1.1/ and this compiles from the github project and creates the html documentation.

As @JJ-Fullmer states: the nice thing of keeping the docs inside the fogproject source tree is that you can use versions and that each version gets it’s own documentation in readthedocs. As soon as you tag a release in github you get a new version in readthedocs and the documentation for old versions will be left as is,

If you set up a webhook in readthedocs then the documentation automatically gets generated if you commit your work to github.

Agree that this is a good way to proceed?

@Sebastian-Roth if you think a separate repo is better, than that’s fine for me and it is good to keep it under the fogproject. We can place release tags in that project and achieve the same goal.

@Wayne-Workman yes let’s start small. From my experience with setting up Fog project as a sysadmin/network engineer I am interested in the following parts:

• How does Fog work? A small introduction and a description of components and how it fits in the network. The last part is important for network admins to understand and support a fog installation in their network
• Installation instructions on Debian and Redhat of a fog server and fog storage server
• Managing fog (the Web UI)
• Doing your first image capture/deployment
• Reference of all configuration options

Later we will have to discuss whether to include advanced options like exotic installs, FAQ, Troubleshooting although I think that the forums already play a great role in this and maybe also the wiki.

If you agree, then let me assemble the first pages. The wiki provides lots of information that is very usable, so that’s just copy/paste and reformat.

I am now working on the installation part of the manual.

Can we agree on the starting point that, when coping things from the wiki to the new documentation that we will only focus on the current (1.5.9) version? So all parts that refer to old versions will not be copied and that we will also use screenshots of the current version. I think this will help a lot in understanding and recognition for new Fog users.

I am now working on the installation part of the manual.

Can we agree on the starting point that, when coping things from the wiki to the new documentation that we will only focus on the current (1.5.9) version? So all parts that refer to old versions will not be copied and that we will also use screenshots of the current version. I think this will help a lot in understanding and recognition for new Fog users.

@JJ-Fullmer No, I’m not. I see the same as you, an nginx 403 page.
I think that for the domain fogproject.org a DNS CNAME record should be made:
docs.fogproject.org IN CNAME readthedocs.io

I have admin access to readthedocs and I have removed this domain temporary until the DNS is fixed. For now you can see the first results under https://fogproject.readthedocs.io

The initial structure is now in github and I think it is best if we spread the documentation across many files, as this decreases the chance of having merge conflicts when together working on the documentation.

@JJ-Fullmer I have set up the first documentation in sphinx now. I agree with you that it is more difficult than markdown. I have no development experience and needed to learn sphinx from scratch, but having read Sebastian’s comment, let’s start with sphinx. I think when the ‘skeleton’ is set up, it will be much easier to contribute as you have examples.

@Sebastian-Roth if you think a separate repo is better, than that’s fine for me and it is good to keep it under the fogproject. We can place release tags in that project and achieve the same goal.

@Wayne-Workman yes let’s start small. From my experience with setting up Fog project as a sysadmin/network engineer I am interested in the following parts:

• How does Fog work? A small introduction and a description of components and how it fits in the network. The last part is important for network admins to understand and support a fog installation in their network
• Installation instructions on Debian and Redhat of a fog server and fog storage server
• Managing fog (the Web UI)
• Doing your first image capture/deployment
• Reference of all configuration options

Later we will have to discuss whether to include advanced options like exotic installs, FAQ, Troubleshooting although I think that the forums already play a great role in this and maybe also the wiki.

If you agree, then let me assemble the first pages. The wiki provides lots of information that is very usable, so that’s just copy/paste and reformat.

I have played with sphinx/github and readthedocs.

I have created an account at github: jgoedbloed. The github account is also used for readthedocs.

If you look at my test project in github: https://github.com/jgoedbloed/docstest
then you’ll see the ‘docs’ folder that contains all documentation (for now this is just a skeleton, no useful information to be found here).

I have set up a readdthedocs account https://jgoedbloed-docstest.readthedocs.io/en/1.1/ and this compiles from the github project and creates the html documentation.

As @JJ-Fullmer states: the nice thing of keeping the docs inside the fogproject source tree is that you can use versions and that each version gets it’s own documentation in readthedocs. As soon as you tag a release in github you get a new version in readthedocs and the documentation for old versions will be left as is,

If you set up a webhook in readthedocs then the documentation automatically gets generated if you commit your work to github.

Agree that this is a good way to proceed?

I will create these accounts and will let you know.

I have to dig some deeper into sphinx/readdthedocs, but I know many projects have documentation for different versions.

Take Ansible as example: https://docs.ansible.com/ansible/latest/index.html In the top left part you can choose a version. I think this would be handy for Fog as well. A new release: a new set of documentation where you can make the changes that are specific for that version.

I have been an enthusiastic user of Fog for some time now and it has
saved me tons of time and also created much more quality in managing our
office clients.

Also your quick and friendly support to some issues I’ve had is wonderful.

I have read a lot of the contents in the fog wiki and, although it is
useful, things are not always in a logical place and some content applies
to older versions.

I would like to offer to make new documentation for the latest version
of Fog in such a way that it will be easier to keep up with newer
versions. I was thinking about using something like sphinx and publish it on
readdthedocs.io.

Documentation would then be part of the Fog package and checked in on Github.

Do you like the idea?

I hope that with this initiative I can give something back to the
community and I like documenting things. As this is not something I can do
the boss’ time, it would mean that I will work on it in my free time and I
expect that it will take some months before I can deliver something
decent.

Let me know.

I recently updated my Fog server from 11.6 to 12.0.

After the update, the fog client on all Windows machines does not want to update from 11.6 to 12.0.

This is what the log says:

------------------------------------------------------------------------------
---------------------------------ClientUpdater--------------------------------
------------------------------------------------------------------------------
01/10/2020 15:57 Client-Info Client Version: 0.11.16
01/10/2020 15:57 Client-Info Client OS:      Windows
01/10/2020 15:57 Client-Info Server Version: 1.5.9
01/10/2020 15:57 Middleware::Response Success
01/10/2020 15:57 Middleware::Communication Download: http://fog.domain.com/fog/client/SmartInstaller.exe
01/10/2020 15:57 ClientUpdater ERROR: Unable to parse versions
01/10/2020 15:57 ClientUpdater ERROR: Value cannot be null.
Parameter name: authority
------------------------------------------------------------------------------

the domain fog.domain.com is obfuscated for security reasons.
I see the smartinstaller.exe being downloaded in the /tmp folder.

All our clients are Windows 10, the machine on which I tested has all updates installed.
Windows Defender is turned on. I also tried it with Windows Defender turned off, but that gives the same result.

Where can I look for additional clues?

Thanks,
Jurgen.

I was able to deploy an image on the following hardware:

Dell XPS 13 7390 (via an TP-Link UE300 USB ethernet adapter)
Dell Latitude 5300
Dell Latitude E5570

All with the following settings:

• UEFI mode
• Secure Boot: Off (can be switched to ‘on’ after imaging)
• Fog 1.5.7
• ipxe.efi kernel
• Disk mode: AHCI

@Sebastian-Roth : then don’t rush for me. What I can do for now is install the fog client and then copy the modules.dll that uses codepage 850. I have already created a script that does this. I will use this script to roll out the Fog client to all existing workplaces with psexec.