PUSH I’ve could adjust LDAP login, and allow only admins, but I’ve some students who would also like to work with it. So I’m allowing admins (admin role) and students (mobile role) to access. But not all students should have full access. As I listened, there is a new idea with the new version 1.6 on this subject. Hopefully this will solve my problem.

i will be in holidays for the next two weeks. so this topic is not urgent at the moment. br lakk

@Seb77 this might be helpful. https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#Continue_pre-config The services are listed, and some UDP ports. This config does work.

@xburnerx00 Thanks for bringing this up. This time it’s not a database issue on your side I reckon. From what I have found so far this is an issue in the code. Will take a closer look the next days and fix this soon!

@george1421 I think I follow, I’ll give it a bash and let you know, thank you :).

@Chris-Whiteley Just updated the truth table with the link to a 1.5.7 init file with partclone 0.3.13.

@ckasdf Are you still onto this?

@jc35 Found some time to look into the client updater on Linux and seems like there are a few issues with that unfortunately. I was able to find and fix the first one but it still needs more work.

@robbit Are you still WFH?

@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.

@EduardoTSeoane Just wanted to see if you are still buried in work…

This is a work around, for a long term solution …ummm we must to think if this solution is for 1.5.X versions or get a final solution for 1.6.X and how can we do it XD Maybe the solution is create on fly the CSV file to export and import the data (I am thinking loud)

@george1421 i’m thinking we could have an “unregistered host” host and have it auto-register and auto-remove when the tasking was created/finished. that would also allow us to have a task to track in the gui.

@sgoodman Bump…

@sgoodman While this is a good point and I like the idea of a cleanup it’s not as easy as removing those options I am afraid. There is quite some code logic in the background that I would argue needs a cleanup together with this as well. Not sure if we should consider removing it all in a rush now. Sure we can just remove the UI part of it quickly. But all the rest would then stay in the code for way longer I suppose.

@Sebastian-Roth This is more by design. Typically snapins are one time run. If needed to rerun a while later, you can run it individually to the host needed, or you could task the host to run all snapins associated. Maybe something we can limit in the future, but I guess I need better understanding. Snapins run in queue. For example, if a host has 25 Snapins to install, it installs 1, 2, 3, etc… It will not install 25 at once. Now, based on the information, I believe the question here is about number of machines running snapins at once. Lets say you have 25 Machines to install Snapin 1, you want this to be limited? Right now the code doesn’t take into consideration the number of snapin tasks as a queued process. Hopefully this all makes sense. Thank you,

@markbam I started to implement that but need to push this further down the list. We need to focus on bugs of the core FOG code before that. Note to myself: I have saved a diff of the current work in my workspace.

@pa_fog_man I think we have a bit of confusion here (and the 390 is not helping with clarification). First let me say that the Dell’s will let you dynamically boot in the other mode without changing the firmware (where it gets its default value). You can do this dynamic switching from the F12 boot menu. The other issue with the 390s (I can’t speak for personal experience with the 390s, but we have 790s in our fleet) the 790s were the first generation to support UEFI mode. But as far as I know, the 790s don’t support pxe booting in uefi mode. The 7010s was the first generation to support pxe booting in uefi mode. To pxe boot on the 7010s you would have to enable the uefi network stack on the network adapter settings in the bios. Otherwise you would not get ipv4 and ipv6 entries under uefi on the F12 boot menu. Back on point. You MUST select the proper boot kernel for the target system bios mode (legacy/bios or UEFI). If you sent the wrong boot file to the system you will not see the FOG iPXE boot menu. for bios mode you can use ipxe.pxe or undionly.kpxe for uefi mode you can use ipxe.efi or snponly.efi The bold text above are the typical kernels to set for dhcp option 67. You can not mix the boot kernels. This isn’t a FOG issue, but rather a firmware one.

Couple of things to check: Is the original machine in BIOS or UEFI mode? Is the target machine in BIOS or UEFI mode? If both are in UEFI mode, you may have to manually add the boot option in the UEFI of the target machine.