Posts made by Kiweegie

@tom-elliott So to clarify that last point Tom, the SQL should reflect under ngName both the Storage group name AND the Storage node name? DCSTORAGE in this case is the name of the Storage node master server for the Storage Group 3 storage group.

I’ve compared to the other image(s) which are only hosted on (and are being replicated from) the Master node and they only reflect the main storage group under ngName.

I’ve made note of the replicator service restart command, cheers. I went a bit neanderthal and just rebooted all my servers just now to see if that kicked things into life.

Checking the Image Replicator logs under FOG Configuration > Log Viewer it only references DCMASTER and the 2 nodes in its storage group. Does replication from the Storage master of the other storage group show in these logs? Or do we need to check local log files on the server itself?

cheers Tom

@tom-elliott said in Replication oddity after moving Master node:

SELECT imageID,imageName,ngID,ngName
FROM imageGroupAssoc
LEFT OUTER JOIN images ON igaImageID = imageID
LEFT OUTER JOIN nfsGroups ON igaStorageGroupID = ngID
WHERE imageName = ‘nameofimage’;

Thanks for getting in touch Tom.

The whole both storage groups “can” apply to an image was throwing me I confess. I actually added a brand new storage group “Storage Group 3” for the sake of the earlier example and deleted Storage group 2.

I’ve set only Storage Group 3 on the image(s) I want to sync from the DCSTORAGE node and made sure it’s set as master

Output of SQL above is as follows:

Database changed
MariaDB [fog]> SELECT imageID,imageName,ngID,ngName
    -> FROM imageGroupAssoc
    -> LEFT OUTER JOIN images ON igaImageID = imageID
    -> LEFT OUTER JOIN nfsGroups ON igaStorageGroupID = ngID
    -> WHERE imageName = 'My_image';
+---------+------------+------+-----------------+
| imageID | imageName  | ngID | ngName          |
+---------+------------+------+-----------------+
|       9 | My_image   |    4 | Storage Group 3 |
+---------+------------+------+-----------------+
1 row in set (0.01 sec)

On the assumption this is correct (now) do I need to restart any services or servers themselves to have them pick up on this change and start syncing?

regards Tom

@kiweegie said in Replication oddity after moving Master node:

@Tom-Elliott @Sebastian-Roth

Morning gents, just revisting this as I have some more findings. The replication issue seems to be limited to the Master node not replicating images listed for Storage Group 2 for which a DCSTORAGE is the master.

Using the previously sent image of the setup, images capture to DCMASTER and it replicates fine to storage nodes with the same storage group set Storage Group 1

It is not being captured or replicating to DCSTORAGE however which is the master storage node for the second storage group.

I’ve checked the wiki re replication and it states there that:

Images always capture to the primary groups master storage node - so the image which is set as Storage Group 2 should capture to the master node for that storage group DCSTORAGE but is actually capturing to the Master Node DCMASTER.

So it would seem that that image is not seeing that DCSTORAGE is its master storage node even though the image(s) are defined as such.

I’ve confirmed also that DCSTORAGE is set as the Master node for Storage Group 2

Anything else I could me missing here?

regards Tom

Additional note - when image is captured (to Master node) it sets ownership as the local unix user:root not fogproject. Not sure if this has bearing on things?

@Tom-Elliott @Sebastian-Roth

Morning gents, just revisting this as I have some more findings. The replication issue seems to be limited to the Master node not replicating images listed for Storage Group 2 for which a DCSTORAGE is the master.

Using the previously sent image of the setup, images capture to DCMASTER and it replicates fine to storage nodes with the same storage group set Storage Group 1

It is not being captured or replicating to DCSTORAGE however which is the master storage node for the second storage group.

I’ve checked the wiki re replication and it states there that:

Images always capture to the primary groups master storage node - so the image which is set as Storage Group 2 should capture to the master node for that storage group DCSTORAGE but is actually capturing to the Master Node DCMASTER.

So it would seem that that image is not seeing that DCSTORAGE is its master storage node even though the image(s) are defined as such.

I’ve confirmed also that DCSTORAGE is set as the Master node for Storage Group 2

Anything else I could me missing here?

regards Tom

Just wanted to follow up on this for anyone else in same situation. Essentially the VtoV works just fine. As we had changed hostname and IP we only ended up having to reinstall the FOG client on the desktops for them to become in sync with the new FOG Master server. All other things just worked.

Cheers Tom

So I just added 2 more Storage nodes to the equation. On both replication didn’t kick in til I’d initiated a manual rsync from Master to storage node. After doing that (again for one image only) the other 3 images all synced OK.

Wondering if there needs to be some syncing of SSH keys or similar to pemit the servers to talk to each other and thats not being handled automatically? Just a theory…

regards Tom

After rsyncing one of the images from DCMASTER to DCSTORAGE both are now showing up on the storage node… and in turn seem to be in process of replicating to the other Storage nodes.

I’ll need to double check all of them once replication process finished to see if they have same file sizes etc.

regards Tom

@sebastian-roth You’re quite right, i’ve just re-read that myself and it’s confusing… I was using non-real names for reasons of privacy.

This image should hopefully help show the layout a little more clearly.

DCMASTER is set as Master node for Storage Group 1
DCSTORAGE is set as Master node for Storage Group 2

MAINSTORAGE is a storage node on Storage Group 1
All the SHOPSTORAGE nodes are storage nodes on Storage Group 2

Image capture to DCMASTER is working fine - I can see the mac address of the image machine hitting /mnt/images/dev as the image itself is uploading, that part seems fine.

Images in question have been assigned to both Storage Group 1 and Storage Group 2 with Storage Group 2 set as primary. The goal is to have DCMASTER host all images and sync all of them to all storage nodes via membership to both Storage groups.

2 issues being faced:

MAINSTORAGE is showing the PreSysprep and PostSysprep image folder structure before it’s fully uploaded and showing on DCMASTER

None of the SHOPSTORAGE nodes are getting the images replicated. I can try rsyncing the images over to DCSTORAGE manually so they sync in turn to the other storage nodes but was looking for this to happen automatically.

Am I correct in stating that if MAINSTORAGE is replicating from DCMASTER then the folder names and sizes should be identical? Should the structure show up on MAINSTORAGE before it appears on DCMASTER?

We’re using the location plugin in case that has any impact (plus LDAP, WOLBroadcast plugins).

If you need more information than above let me know

regards Tom

Added to above I’ve just checked DCStorage and all the ShopStorage nodes and that image is NOT replicating to those nodes.

Image has only Storage Group 2 set under Image Management

DCStorage is set as the Master for Storage Group 2. I’m guessing I may need to add that storage group to the image so it has both storage groups assigned?

That would perhaps explain why the replication is not happening to other nodes but I’m still baffled as to why the image is suddenly appearing out of nowhere on MainStorage

regards Tom

Hi all, I logged an issue on this link the other day re imaging failing after migrating our master server to a new location/IP via VMware VtoV.

Imaging is sorted now (thanks to @Sebastian-Roth for the assist on that) but am facing a more peculiar issue.

We have a multi office setup.

Data Center with Master (DCMaster) and Storage (DCStorage) nodes.
DCMaster is set to Storage group 1 to contain all images
DCStorage is set to Storage group 2 to contain only images to be replicated to shops which have less storage capacity.

We have a main office set with storage node (MainStorage) which is set to Storage group 1

And several small shops also with storage nodes (ShopStorage1, ShopStorage2 etc) - these all use Storage group 2

We have an odd issue where replication seems to overwriting existing images somehow. We’ve made changes to an image and captured it (which should go to DCMaster and be replicated out from there). But something is overwriting that image.

To test I’ve removed all reference to a particular pre-sysprep image. Initiated a capture again and can see the mac address for the capture hitting /mnt/images/dev on DCMaster

Before that image has completed capturing however an image with that name appears in /mnt/images on MainStorage…

I’ve double checked that MainStorage is set as a storage node (it is) and it’s set to look to DCMaster as it’s snmysqlhost entry from /opt/fog/,fogsettings

In the fogreplicator.log on MainStorage I’m seeing the following

[03-29-21 9:11:33 am]  *  | This is not the master node
[03-29-21 9:21:33 am]  *  | This is not the master node
[03-29-21 9:31:32 am]  *  * Image replication is globally disabled
[03-29-21 9:32:32 am] FOGService: ImageReplicator - Waiting for mysql to be available
last line repeated....

Is there anywhere else I can check to determine where this image is replicating from???

regards Tom

@sebastian-roth thanks for this, in testing removing and readding client worked so imaging in general looks to be ok now. I’ll also test with Reset Encryption Data when I get a chance and revert back.

I have an issue with replication but will log a separate post about that.

cheers Tom

Running Fog 1.59 with a Master and Storage node at one office which is in the process of being shut down so I’ve moved those two servers to one of our datacenters via VMware converter. I’ve re-IPd and renamed the machine and run the installer again.

We have a load of branch offices each with a storage node (using Location plugin) so again I’ve updated the SQL address in /opt/fog/.fogsettings to point to new IP of the Master and run installer again. Nodes all show up correctly in FOG Configuration and replication seems to be working ok.

Lastly edited FOG Configuration > FOG Settings > Webserver and FOG Configuration > FOG Settings > TFTP Server settings plus Storage Nodes within the FOG UI to point to the new IP. Communication between FOG servers seems ok but can’t seem to get it Master to talk to an existing client.

I’ve removed and reinstalled the FOG client and rebooted the client a number of times but keep getting error similar to that reported on this post:

I manually removed the existing FOG Server CA and ran client installer again which I think should pull CA from the new server. Given this is essentially a clone of the original server the existing SSL should be in place I’d have thought? I do still have the old server so I can copy the SSL folder if necessary tomorrow.

But wondering if the VtoV method used is OK or if we may introduce further complications with this approach?

regards Tom

@Sebastian-Roth Hey Sebastian (and all other FOG devs and users out there) hope you and yours are staying safe and sound with whats going on in the world.

I’d forgotten about this post myself I confess - I’ve been busy trying go setup our entire workforce across several sites to work from home.

I know our service desk team would find this feature of great benefit as keeping reliable track of who was given a loaner laptop and when can be difficult without the right tool to do it. Excel sheets or even the ticketing system don’t manage this very well.

But given whats going on just now for everyone its very much on the distant, nice to have when the worlds in a better place list.

Stay safe everyone.

Kiweegie.

Hi @rmishra1004

there are quite a few hits in the forum for this issue. I’d suggest searching there first as it seems to have happened to others and fixes suggested.

Start here or here.

regards Tom

Perhaps share how the custom task was created, what you’re trying to achieve etc so others can weigh in with suggestions? Above is not really much to go on.

regards Tom

Hi @TheBitFighter

can I just double check that the file extension in your code block above is a typo and should read .ps1 not .bs1?

And Chocolatey is installed already on the endpoint you’re trying to install vscode with (via Chocolatey)?

I’ve tested your snapin on a client here and provided Chocolatey is installed on the client vscode installs.

cheers Tom

I’ve addressed this on my FOG servers as follows:

First edit the FOG apache file at /etc/apache2/sites-available/001-fog.conf to enable htaccess to work

Add a new <Directory> stanza linked to the root of the site underneath the existing <Directory> stanza so it looks like this:

<Directory /var/www/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    <Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

Restart apache then create an htaccess file

sudo systemctl restart apache2
sudo vi /var/www/.htaccess

Add the following and save

Options -Indexes

Now navigating to the root of your FOG server will give you permission denied

@stuhad

We are running on the dev version here 1.5.7.109 and can confirm that LDAP plugin works on this version.

Re your FOG install showing 1.55 but earlier not I think you’re seeing the issue that @Tom-Elliott referred to below and has fixed.

As to why the LDAP plugin is not working it will be down to something in the LDAP config I suspect rather than anything linked to the FOG version. I’ve had LDAP plugin working on both 1.55 and 1.57.

Do you have anything in the following log file at all in reference to LDAP users?

/var/log/apaches/error.log

Looking through your LDAP config and comments from previous post

LDAP connection name: dc1
(fine as long as each connection name is unique)
LDAP Server Address: IP Address (is an IP ok?)
IP address OK, thats what I’ve used
LDAP Server Port: 389
OK
Use Group Matching: ticked
OK
Search Base DN: ou=fog users,dc=company,dc=com,dc=au
I’ve set my search base here to the root of the domain so try just dc=company,dc=com,dc=au
Group Search DN: ou=fog users,dc=company,dc=com,dc=au
Should be fine - spaces in OU names also OK.
Admin group: cn=fog admins,ou=fog users,dc=company,dc=com,dc=au
Try just using the group name here “fog admins” don’t need the cn entry. Also try removing space. Should be ok but something to rule out
Mobile group: cn=fog admins,ou=fog users,dc=company,dc=com,dc=au
As above
User Name Attribute: sAMAccountName
OK
Group Member Attribute: member
OK
Search Scope: Subtree and below
OK
Bind DN: cn=ldapadmin,ou=services,dc=company,dc=com,dc=au
This user should have delegated rights to add and delete computer objects. If unsure try adding as member of Domain Admins group to test
Bind password: added in plaintext
OK

Ninja Edit: With the password remember to ensure no special characters!!

Give the above a whirl and let us know how you get on.

regards Tom

@Sebastian-Roth @Tom-Elliott thanks both

We need the current live FOG install to JFDI at the moment so can’t play with the live environment but I’m putting together a virtual box lab to test version 1.6 with location plugin, LDAP etc.

Update once i get that up and running.

cheers Tom

@Tom-Elliott ok cool that makes sense ref the one UI being more responsive. If I check the UI on my phone (Samsung S10+ running Android 10) the UI is not as good as it could be. Not a criticism in any way but pointing it out. Its certainly usable but the display is a little “janky”

Same using Chrome (80.0.3987.87) or Firefox (68.5.0)

regards Tom