@george1421 @Junkhacker @Tom-Elliott I see what it does now. I actually tried that out. Basically, it copied the script from fog server and placed that into the target computer. Once the target computer powers up, it will run the script automatically. That actually helps. Thanks for your guys effort. I will close this issue then.

@Sebastian-Roth Thanks for the help! Sorry about the late response as well. I will be starting one soon, and we defiantly have a high-speed connection Internally. But we have multinational support and they have slow speeds. Even if it takes 7+ hours to re-image some of their machines, it would save a lot of time from shipping the devices.

I will do some research and document the process for Kubernetes, and possibly HELM support as well.

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

Moving this to feature requests section. Possibly something we can address when FOG 1.6 is out or if people join in to work on this.

As we have an issue report on this open on github we won’t keep track of this topic in this forum thread: https://github.com/FOGProject/fog-client/issues/7

Excellent George, I will give that a try. Thanks for the feedback!

@Daniel-Miller said in LDAP Bind during Login:

Now, if you happen to know what the DN suffix will be, an alternative to the search and bind method would be a direct bind where the required static information is added to the username to create the DN that is proffered to LDAP for the bind request.

Right, this is something like I was thinking about, especially on a domain-joined machine. I suppose I didn’t phrase it properly or concisely - that’s my bad.

No particular reason for this functionality; just didn’t know if it would be something worth adding in or how difficult it would be to code into the plugin. No worries!

Thanks for the quick reply!

I’ve added the adjustment to make an Orange Alert box in place of the versioning info on the storage node in the case the node is returning as offline.

Thank you,

I would have to agree.

Snapins, at least if I remember correctly, can now be applied individually regard less of if they’re actually associated with the host. I can make the text change. Ultimately, like what you did for the Image Resize, I’d like to use the ( i ) icon’s to be more indicative of the actions and helpfully make fog a bit more natural to understand, but this isn’t a “bug” persay, and non instrumental in the overall functionality of FOG.

I’m sure most understand, I tend to hate making text based changes. Not because they’re hard or unreasonable, but text - in my eyes - is not as important to the actual functionality. This can wait. We will work to fix this, but it certainly, in my eyes, does not have to be an immediate thing.

Technically you can probably capture and deploy it in a non-resizable fashion (it will be slow since it will do a RAW capture), though I’m not sure if this will work reliably with such a filesystem.

It’s closed source and only available on enterprise, so I don’t expect any open source solutions to arrive any time soon.

@p4cm4n said in Associate all new hosts with Snapin:

assign template host to template group, assign properties to template host.

No don’t do this because it will create a loop. The names have to be exactly the same that is all.

Every host added to the template group will cause the database trigger to fire copying the host template settings over to the host just added to the group.

nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host

Its possible that the settings are made in the database but because of database caching the FOG application may not see the changes until the cache is refreshed. So are you saying that the settings on the template host are not being copied over (like OU or some other parameter field) or is this a question about the snapins not installing?

@Sebastian-Roth

Sounds great! Like I said, let me know what you all are working on and I’ll do my best. I do have some background in programming but it’s been a bit. I am trying to pick up Python and do a little teaching here at our district.

I worked in UNIX for a couple years at one of my first computer jobs. They hired me because I liked tinkering in Linux. I’ve used Linux since the first iterations of Redhat. 🙂 The FOG project does draw you in. It’s a great thing. Some of us can’t afford to throw cash at it but certainly am willing to donate time.

So keep me posted! Thanks!

@Yanis-Sauve said:

I do the server updates, then a git pull each time.

May I ask which git branch you are on? Run cd .../fogproject ; git branch to find out.

For the database, do you think it would be possible to systematically display a page about the schema, update or not? I do get that sometimes the schema does not change, but each time I go through the fog install, I ask myself if everything is OK when no update page is displayed.

While I understand your situation I don’t think we’d want to display the schema update page even though there is no update.

If you are on dev-branch we might have an easier solution to this. We usually update the minor version number (1.5.7.x) every now and then - usually when bigger changes are pushed to the repo. I might just update this last digit of the version string ever time I push a change to the dev-branch. This way you see if it all worked by looking at the version number in the bottom right corner of the FOG web UI before and after updating.

@TheDiskDrive Versioning adds a huge amount of space and is quite complex to implement I reckon. While I don’t say it’s a bad idea to do I don’t think we’ll find the time to add this feature any time soon. Feel free to engage!

@Sebastian-Roth That’s true, though we could always just backup the current inits on the client side and add a “restore original inits” button.

While I can’t speak for the FOG Project developers, I would say that managing MS Windows updates is not something that the FOG Project wants to enter. FOG’s focus is cross platform image deployment. I feel that moving into the MS Windows (only) space would be moving in a direction away from The FOG Project’s original charter. Also there are currently free MS Windows patch management solutions like Microsoft’s WSUS. There are other like free solutions like WSUS Offline Updater already in this space. In the linux space there is puppet, chef, and ansible.

@LJay said in Client Inventory Option.:

A PXE pre-loaded troubleshooting/inventory environment seems like the perfect, OS agnostic answer to this.

I am not sure I get this right? Are you saying we should have inventory collection on PXE booting?

I just updated, and it was much easier than I originally anticipated. 🙂 Thanks again!

Thanks i will test this

@Sebastian-Roth we currently have 20 or 30 at a day, and this year we go to renovate a big percentage of the park.