Posts made by quinniedid

Hi @Fernando-Gietz ,

All of these users are local. We did create a user called “optimus”

I created a new roll call Technician - Optimus.

These are the rules that I have created for the roll so far:

MAIN_MENU-about about main
MAIN_MENU-host host main
SUB_MENULINK-actice active menu task

I am thinking there is actually something wrong with maybe the database that contains the rules? When I go to the access control plugin I click on list all rules, the rules that show up in that list are not the same as the ones that are available to add to the role for rule association.

I would upload screenshot but for some reason I am not able to right now. I select the select the user to add but no action is taken it seems. I will have to try a different browser or computer.

FOG 1.5.5

I have created two technician roles. I have assigned only three rules to this particular role. When adding a FOG user to the membership for this role it is never added. The user still can see everything as if an admin in FOG.

Is this part of the plugins failing to work in FOG 1.5.5 or is this a separate issue?

I would admit you are absolutely correct. I should not have put the local admin into the group…

I was finally able to get back in. I appreciate all of your help!

Hi all,

I am in need of some desperate help. I installed the Access Control plugin and started poking around at how everything came together. I added the only admin account to the Administrators group, which apparently had no rules added to. I have no other user that can login to FOG. I have two other users but API (mobile only) is disabled and cannot correct the issue.

Is there a way to go through the database to enable API for one of these other users? Is there someway to disable the plugin for now? Anything I can do to get back into my server?

Any help would be greatly appreciated!

Thank you ahead of time!

@Jonathan-Cool Are both WIN7 and WIN10 machines joined to a domain? Is the server that your drivers are shared on joined to a domain?

@Dee If hard disk space is a concern I would highly recommend enabling compression on the image setup page. We have ours maxed out to 22. It takes more time to capture the image but it is huge savings for us.

Here is an example:

@Dee Remove the images that are no longer showing associated in the UI. When creating the images you have to specify the name of the image folder containing the image files. I would go to your image directory and remove images that are not associated. Just follow what Sebastian recommended.

@Dee Please run the commands that @Sebastian-Roth recommended. Also, please login to the web portal of FOG and taking a screen capture of all of your images so we can compare and see what we can remove to free up space.

@Dee Although you had those errors at the beginning it appears it found the disk to capture. Based on your most recent upload it might be that your server is out of disk space.

Would you please run this command on your server and report back?: df -h

@Dee Do you have an ability to capture a screenshot of when it is capturing? Do you see diskpart pulling the image? Is it failing to update the database which is one of the last steps? There should be a halt at the end if something failed and should wait 2 minutes before rebooting the machine. Do you see this at all?

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.

@Sebastian-Roth I have tried specifying that setting for the host in the kernel arguments and still continues to show the same message.

@george1421 I tried that kernel and it is doing the same thing. We are on Build 9433931. They have an update U1 out but our hardware vendor does not support it yet.

@george1421 @Sebastian-Roth I just wanted to see about tackling this issue again. Using the SATA controller for the VM hard disk is costing us a lot of time as it takes roughly 2 hours to capture an image. Where as the SCSI controller takes less then 20 minutes.

This is in reference to an issue I posted about 10 months ago: https://forums.fogproject.org/topic/11179/vmware-6-5-vm-not-able-to-capture-image-using-efi-uefi

FOG Version: 1.5.4
bzImage: 4.18.3

This is what I am seeing:

@Wayne-Workman
I will have to check out that link and video.

Answers to your questions as follows:

• The replication link is slower probably about 20 to 40 mbps
• We plan to capture the images from one location and use them at their specific locations. Some images will be for the other side and some will be for this site. We will have some images that are shared between the two sites
• We will definitely want to limit which images
• I have complete control of DHCP at both sites
• This is not absolutely necessary but it would be nice to have for sure

Also, what port/protocol is used for storage replication or needed in this scenario?

@george1421 Perfect! Exactly what I was after! Thanks again!

@george1421 Oh that is not bad at all than! We only update our images one every month or two, typically. We do override the same image as well.

With that being said would you have to export and import every time we change the image or would this be when we create a new image all together?

@george1421 I understand now. I thought the metadata stayed with the image and with that not being the case it would create a lot more work in this case.

I appreciate the clarification and I appreciate you taking the time to answer my questions.

Again Thank you!

@george1421 @Wayne-Workman

The images are stored directly on the primary FOG server. Basically what I am asking, is it possible to have multiple FOG servers connecting to the same storage node? Its fine for site2 to write images to the one storage node. It would just be nice to maintain the images from one site and it automatically replicate to the other sites.

To answer the question, these are running on a VM on our production blade center

I am trying to setup a potential use case for FOG. We already have a FOG server at the primary site with images on its storage node. I would like to have the ability to replicate to another storage node across a WAN link. On the second site that FOG server would only have access to the Read-Only Storage Node to server out images to its clients.

Is this idea or potential plan possible?

If so, what ports are needed to be opened across the Replication Link (WAN Link)