OSDeploy / OSDSUS

WSUS Catalogs used by OSDBuilder and OSDUpdate
MIT License
38 stars 8 forks source link

Lastet Updates Cumulative 2024-08 ? #12

Open RuneNyhuus opened 2 months ago

RuneNyhuus commented 2 months ago

Hello

Is this project not updated anymore? https://raw.githubusercontent.com/OSDeploy/OSDSUS/master/UPDATES.md <- Also only shows 2024-07 as lastet.

MarkRouleau commented 2 months ago

Looks like the catalog has been updatedhttps://raw.githubusercontent.com/OSDeploy/OSDSUS/master/UPDATES.md, but the latest version of OSDSUS isn't seeing it. I don't have any insights, just a user of the product.

RuneNyhuus commented 2 months ago

Yeah list is updated with 08-2024 now. But still only update 07-2024 in the Media Updater.

But 09-2024 is also out now.

OSDeploy commented 2 months ago

I released an update this morning before I had to catch a flight, but the LCU’s weren’t in this mornings release. I’ll try to get them added in the next few days. Thx

freedbygrace commented 2 months ago

Would you be open to possibly discussing an alternative and automated way of approaching the updates to the catalogs? I would not need much of your time, but want to show you what I have written so far, and hopefully contribute in some way.

PZan commented 1 month ago

@freedbygrace, would you mind elaborating in this thread perhaps? I'm also very keen to get a more automated solution for this, as we are depending on OSDBuilder and OSDSUS to keep our images up to date.

freedbygrace commented 1 month ago

Yes! I was thinking about using WSUS and using an API gateway that allows for querying the database using HTTPs such as DreamFactory, NocoDB, or PostGrest. We can host these services on a VPS and figure out some way to pay the nominal fees required. We can then run this on a task, and then as WSUS updates, we can fetch and inject the new updates from WSUS into the database via API using Powershell. After that, we integrate the API calls into the module itself. And as long as the backend is updated, then the module does not need to be updated at all unless there is an actual code change and not new XMLs, CSVs, or JSONs containing the new updates. If Jason can share how he is currently scraping this information would be awesome.

WSUS is officially no longer being updated and requires maintenance. We could run it in a VPS and run a script to keep it clean on a schedule.

As far as I know, there is no other centralized database to query updates.

The other option would be to have each flavor of OS and build scan each month for what they need using PSWindowsUpdate, and sending the updates into the API for future queries, but it does not scale well because we would have to maintain VMS or something assigned to doing that task and keep them updated over time as new builds and flavors come out.

MS is not making this easy.

Any thoughts?

ReverendRhyme commented 6 days ago

Yes! I was thinking about using WSUS and using an API gateway that allows for querying the database using HTTPs such as DreamFactory, NocoDB, or PostGrest. We can host these services on a VPS and figure out some way to pay the nominal fees required. We can then run this on a task, and then as WSUS updates, we can fetch and inject the new updates from WSUS into the database via API using Powershell. After that, we integrate the API calls into the module itself. And as long as the backend is updated, then the module does not need to be updated at all unless there is an actual code change and not new XMLs, CSVs, or JSONs containing the new updates. If Jason can share how he is currently scraping this information would be awesome.

WSUS is officially no longer being updated and requires maintenance. We could run it in a VPS and run a script to keep it clean on a schedule.

As far as I know, there is no other centralized database to query updates.

The other option would be to have each flavor of OS and build scan each month for what they need using PSWindowsUpdate, and sending the updates into the API for future queries, but it does not scale well because we would have to maintain VMS or something assigned to doing that task and keep them updated over time as new builds and flavors come out.

MS is not making this easy.

Any thoughts?

I was just wondering if you've made any headway in automating this solution. Patch Tuesdays come and go, and OSDSUS seems to have unfortunately fallen to the wayside. Curious as to what you are doing now in lieu of this.

OSDeploy commented 4 days ago

Would you be open to possibly discussing an alternative and automated way of approaching the updates to the catalogs? I would not need much of your time, but want to show you what I have written so far, and hopefully contribute in some way.

Let's chat ... but to be honest I've already moved from WSUS to Microsoft Update Catalog. OSDBuilder already uses these in the OSD PowerShell Module. Is WimWitch the only tool that was using OSDSUS Catalogs? image

freedbygrace commented 3 days ago

Ok awesome! Can you pm me some kind of way so I can share my email address?

OSDeploy commented 3 days ago

david@segura.org