Community Projekt: Teil 1 - Interesse an einem gemeinsamen größeren (Software)Projekt?

Ich hätte noch eine Idee :

einfaches AUDIO Routing,

es soll ermöglichen
Audioquellen (z.B. Mikrofone, Software-Synthesizer) mit Audiozielen (z.B. Lautsprecher, Aufnahme-Software) flexibel zu verknüpfen.
Es könnten Funktionen wie das Mischen von Audiosignalen und die Verwaltung von ASIO-Geräten bieten.

Hi SOLVE-SMART ,

liegt zur Zeit auf Eis.
Kann aber gerne reaktiviert werden als Community Version.
Ich hab nur rudimentäre Scripte zur RegEx Analyse der anbietenden Websites.

Hi Sven,
über den Crawler habe ich mir noch gar keine Gedanken gemacht, da ich das mit einem kleinen autoit-Script von meinem PC aus mache.
Aber so ein Runner auf GitHub liest sich interessant. Hab ich aber überhaupt keine Erfahrung mit.

Das ist auch nur ein Teil des Projekts.
Entstanden ist das Ganze aus der Not, dass ich in der Arbeit kein direktes Internet habe um Software zu aktualisieren.
Daher habe ich mir in Powershell (AutoIt dürfen wir nicht anwenden) eine Anwendung geschrieben, die das "Patch-Management" der Clients erledigt.
Die aktuellen Anwendungen dazu lade ich manuell über das Internet und stelle sie dem Patch-Management zur Verfügung
Diesen Prozess will ich zusätzlich automatisieren.

Dabei kam mir der Gedanke dass das andere doch auch interessieren könnte.
Online Updater gibt es ja einige. Aber offline wird das schon zur Herausforderung.
Da ich "push" lieber mag als "pull", wurde dabei die Idee geboren, die Information über eine neue Version einer Software als Email zur Verfügung zu stellen.

Da kommt der Crawler ins Spiel. Ich bin da nicht der Experte. Die Funktionalität wäre zu überdenken.
Dabei crawled der einfach als cronjob das Netz nach in seiner DB bekannten URLs nach neueren Versionen von angebotener Software und schickt eine Email an eingetragene User, die dann für den jeweiligen User interessante Software als Email eine Aktualisierung meldet.
Der User geht auf die Seite des Herstellers und lädt sich die Aktualisierung, da er ja grundsätzlich keine direkte I-Net Verbindung hat.
Diese Software überführt er dann in sein "offline-System.
Da kommt das "Patch-Management" ins Spiel.
Ich finde, dass es auf dem Markt nichts für mich überzeugendes gibt, dass offline auf einfache Art Software in einer Workgroup / Domain-Umgebung für kleines Geld oder sogar kostenfrei (wenn ich weiter denke sind das auch Treiber und BIOS Config / Update) patcht.

Das ist der eigentliche Case um den es in AutoIt geht.
Die Funktionalität meine Powershell Scriptes in AutoIt umzusetzen und der Welt anzubieten.
Das wäre dann vermutlich eine Client-Server Architektur, in der ein zentraler PC die Software vorhält und die Clients prüfen und Updaten.
Da kann man sicher drüber diskutieren, welche Strategie da am sinnvollsten ist.

ich möchte gern den Tellerrand für diese Geschichte deutlich erweitern.
Ich bin der Überzeugung, dass Deutschland (vorerst) deutlich mehr IT-Sicherheit benötigt angesichts der Entwicklungen.

Da ich selbst in einem sicherheitsrelevanten Bereich arbeite, sehe ich täglich wie kompliziert und aufwendig die Integration von Sicherheit in Unternehmen sein kann. Da ist der empfohlene BSI-Grundschutz nur die Basis des notwendigen.

Dieses Projekt sehe ich daher als eine vertrauenswürdige (da Quelloffen) und nutzbare Möglichkeit diverse Themen in der IT zu verbessern.
Gerade der kleinere Mittelstand und die vielen tausend Administratoren sind oft mit der Thematik überfordert und dann fällt es halt hinten runter.
CryptoLocker und Co. sind dann die Folge.

Da man irgendwo anfangen muss, habe ich als erstes Thema für mich die Aktualität von eingesetzter Software im Visier.
Weitere Themen sind mir aber schon im Sinn.
Eigentlich eine All-In-One Lösung als Community Version.
Das geht von 0-Click Installation (ja ich kenne OPSI und andere) über automatisierte Rollen Installationen und Sicherheitsvorschläge bis hin zum Patch-Management von Treibern, BIOS Firmware und Config.
Das Themenfeld ist da "fast" unendlich.

Ich möchte niemanden erschrecken, aber ich sehe da durchaus die Möglichkeit mal etwas größeres auf die Beine zu stellen, von dem ganz Deutschland provitiert. Synergien mit schon bestehenden Gruppen sind da ja nicht ausgeschlossen.

Zitat

Dabei crawled der einfach als cronjob das Netz nach in seiner DB bekannten URLs nach neueren Versionen von angebotener Software und schickt eine Email an eingetragene User, die dann für den jeweiligen User interessante Software als Email eine Aktualisierung meldet.
Der User geht auf die Seite des Herstellers und lädt sich die Aktualisierung, da er ja grundsätzlich keine direkte I-Net Verbindung hat.

Warum es nicht komplett "offline" machen?
Aus meiner Erfahrung ist selbst das "...Der User geht auf die Seite des Herstellers und lädt sich die Aktualisierung..." teilweise schon problematisch (holt der Nutzer sich die richtige Version (32- vs. 64-Bit,...), hakt er richtige Optionen an/ab,...).
Ich selber wäre da eher bei: Du/der Admin bekommt eine Mail und lädt die neue Version runter und legt diese auf einem lokalen Server ab (ggf. sogar die letzten X Versionen um ein Fallback zu haben).

Danach wird entweder
... der User informiert das dieser über eine eigene "Pull-" Software sich von dort die neue, explizit vom Admin bereitgestellte Version, vom Server holt und installiert (hier wäre dann ggf. auch die Möglichkeit Installationsparameter mit zu übergeben) oder
... der Admin diese zu den Usern im Hintergrund "Pusht" und eine beim Enduser laufende Software dann (unter bestimmten Bedingungen) das Update ausführt.

Ich hatte mir soetwas in der Art mal in Turbo Pascal gebaut aber da ich es nicht mehr brauchte, ist das auch nicht mehr vorhanden

In meiner aktuellen Idee der Umsetzung wird die Internetseite des Softwareherstellers nach der aktuellen Version durchforstet.

Diese wird mit folgenden Daten in der DB gespeichert:

Sinnvollerweise wird der Administrator selektiv über die Ihn interessierende Software informiert.
Dabei kann man sicher "alle" Versionen eines Herstellers integrieren. Von x86 x64 portabel usw. Von anderen Betriebssystemen wie Mac und Linux würde ich vorerst Abstand nehmen, die Datenspeicherung aber so anlegen, dass auch diese Versionen jederzeit implementiert werden können.
Gedacht war, dass der User für die von ihm gewählte Version direkt einen Downloadlink und/oder eine URL erhält, wo er sich diese Software in der aktuellen Version downloaden kann. Das dierekte Verteilen von Software an Administratoren sehe ich problematisch, da das Notwendige Vertrauen unsere exe auszuführen eigentlich gegen den Sinn der Sicherheit geht. Dem User muss ja die Möglichkeit gegeben werden, die Authenzität der gelieferten Software zu prüfen.

allein über die Architektur der Datenbank könnte ich stundenlang diskutieren,
um möglichst alle noch zu erwartenden Eventualitäten so umzusetzen, dass die DB jederzeit dafür erweiterbar wäre.

Ich denke auch, dass die Online/Offline Schnittstelle beim Enduser (Administrator) sein muss.
Ich würde nicht anfangen Software von Dritten zu hosten, versenden oder amderweitig anzubieten. Da überschreitet man in BRD schnell Gesetze.

Zitat von Schnuffel

Ich würde nicht anfangen Software von Dritten zu hosten, versenden oder amderweitig anzubieten.

Das war auch nicht gemeint

Was ich meinte, war (dies Software soll ja beim nutzenden Admin lokal laufen) das der Admin sich das für lokale Zwecke ablegt und seinen nutzern eben nur explizit diese Software/Version zur verfügung stellt, die er möchte. Die ggf. auch schon geprüft/getestet wurde.

Haben wir bei uns immer so gemacht, um zum Einen eine Fallback Installationsdatei zu haben und zum Anderen dem Benutzer nur vorher geprüfte Versionen zur Verfügung gestellt haben.
Aber ich wollte es halt nur einmal anmerken, bin ja mittlerweile nur noch im Mobility Bereich zuständig und da läuft das ganze leider nochmal wesentlich schlechter/anders.

Ahh okay, ich verstehe dich.

Der organisatorische Weg vom Download einer Software hinein in „unsere Verteil-Software“ ist aus meiner Sicht ja dem Admin überlassen. Es spricht auch nichts gegen die Nutzung von mind. 2 Versionen, für den Fallback. Aber das ist ja eine Detailbetrachtung der Patchfunktionalität.

Im Moment ist das Thema ja nur hypothetisch, solange sich niemand aktiv an der Konzeptentwicklung beteiligt.
Ich würde mich freuen, wenn du @Mombas dich an dem Thema beteiligst. Vielleicht unterstützt Sven auch.

Ich hätte gedacht erstmal einen groben Workflow der Patch Geschichte zu entwerfen. Wenn sich daraus Teile als „könnte man umsetzen“ erweisen, kann man das ganze Herüst in GIT anlegen und freiwillige Unterstützer suchen, die php, html können um den Webcrawler zu designen. Andere würden die Client-Serverstruktur in AutoIt basteln.

Ich weiß, dass das eigentlich mit einer Hochsprache programmiert werden sollte,

Aber warum soll man nicht mit AutoIt anfangen. Um das prinzipielle Vorgehen abzubilden reicht das voll und ganz. PhraseExpress hat auch in AutoIt angefangen und sich erst später portiert in eine Hochsprache. 😁

Grundsätzlich gerne, allerdings habe ich dafür privat zu wenig Zeit.
Ich habe ja Ende des letzten Jahres mein Smart Home erweitert und kämpfe da noch mit dem ein oder anderen Problem.

Hier ab und zu ein paar Zeilen zuschreiben geht noch aber halt sich ernsthaft zum programmieren hin zu setzen, schaffe ich aktuell nicht :(.

Zitat von Schnuffel

Ich hätte gedacht erstmal einen groben Workflow der Patch Geschichte zu entwerfen. Wenn sich daraus Teile als „könnte man umsetzen“ erweisen, kann man das ganze Herüst in GIT anlegen und freiwillige Unterstützer suchen, die php, html können um den Webcrawler zu designen. Andere würden die Client-Serverstruktur in AutoIt basteln.

Konzeptuell würde ich den crawler wahrscheinlich in Python schreiben. Ich hab das schonmal gemacht und dort kann man nicht nur den Quellcode holen, sondern auch recht einfach mit Selenium den browser automatisieren, jenachdem, wie komplex die Webseite des Softwareanbieters ist.

Python kann auch Objektorientiert arbeiten und da RegEx (wie du es in der Datenbank aktuell verwendest) recht fehleranfällig (gerade bei kleineren Änderungen) ist bräuchte man für die Zuverlässigkeit doch eher etwas komplexeres vmtl. mit XPath,...
Zumindest ist es das, womit ich dabei gearbeitet habe. Es kann dann für jede Webseite eine Klasse(/Objekt) erstellt werden, die generellere Helferklassen erweitert und sich dann nurnoch um die Details kümmert.

Außerdem wäre es relativ einfach eine kleine API sowie den Datenbankzugriff zu implementieren.

Es wäre zumindest auch eine Scriptsprache und es lässt sich auch gut erweitern. Man könnte das Grundgerüst bauen und muss dann nurnoch für jede Software eine Python-Script-Datei mit der Klasse für diese Software in eine Art "Extension" Folder geben, die dann automatisch geladen und ausgeführt werden.

+---main.py
+---api.py
+---database.py
+---scheduler.py
+---parser.py	=> helper for simple parsing with sourcecode/regexp/xpath
+---browser.py	=> helper for more complex websites using a browser
+--- ... whatever else is needed
+-+-software-extensions	=> dynamically loaded as extensions
  +---7-zip.py
  +---notepadpp.py
  +---pdf24creator.py
  +---...

Und die Datenbank würde ich so generisch wie möglich aufbauen. Mit den Daten aus deiner Tabelle als Beispiel:

Table Software
ID|Name|LastUpdate|LastCheck|DownloadLink
(DownloadLink is to the generell download website)

Table Versioning
SoftwareID|ID|Major|Minor|Patch|Revision|Type|ReleaseDate|FoundAt
(FoundAt to know, when the release was first seen)
(May need to be adapted to different version schemas, maybe even with different Tables, if they are completely incompatible)

Table Downloads
SoftwareID|VersionID|DownloadLink|DirectDownloadLink
(download link to specific versions, DirectDownloadLink to the specific file if possible)


Version-Examples:
1.2.0-a.1	1.2.0.1		1.1.90 => Major: 1, Minor: 2, Patch: 0, Revision: 1, Type: a (alpha)
1.2.0-b.2	1.2.1.2		1.1.93 => Major: 1, Minor: 2, Patch: 1, Revision: 2, Type: b (beta)
1.2.0-rc.3	1.2.2.3		1.1.97 => Major: 1, Minor: 2, Patch: 2, Revision: 3, Type: rc (release candidate)

Ich würde sagen die Spalten Url-Version, Url-Date, RegExVersion, RegExDate aus deiner Tabelle gehören gar nicht in die Datenbank, sondern in die Software-Extension für die Implementierung.

Bei dem system würde die main.py die API starten und auch eine Art scheduler, die dafür sorgt, dass die websites immer wieder gecrawled werden und die Änderungen in die Datenbank übernommen werden.
Dabei wird das ganze so designed, dass die Software-Extensions auch mit Fehlern crashen dürfen, das aber abgefangen wird, sodass der rest weiterläuft.
Die Extensions würden dabei auch nicht direkt auf die Datenbank zugreifen, sondern einfach nur crawlen und Funktionen haben um die gefundenen Daten abzuholen (durch implementieren eines Interfaces/...).
Das wäre dann für jede Extension gleich und kann vom Scheduler übernommen werden.

So, das wären meine 2-Cents