De- oder Zentralität?

[Alexander (HH)]

Moin Moin!

Aber, man braucht ja trotzdem Speicherplatz für bestimtme Sachen, die nicht so recht in eine DMS passen.

Richtig.

Wo würdest du die netzwerkfähigen (gemeinsam genutzten) Programme (Bsp. Groupware oder sonstige Software) installieren?

Unter Windows schmeißt man die Software typischerweise auf die lokale Platte, schlicht und ergreifend, weil sehr viel Software bei der Installation jede Menge Änderungen an der Registry vornimmt. Unixe können /usr und /opt von einem zentralen Server mounten, bei Bedarf sogar / (mit einigen Tricks beim Booten; Stichwort Initial RAMDisk). Konfiguriert wird meistens über Text- oder XML-Dateien an fest vereinbarten Stellen (/etc, /home/user/.foo).

Haken sind natürlich Updates. Bei Unixen sollte eine Runde rsync über /etc reichen, bei Registry-abhängigen Anwendungen artet das in Arbeit aus.

Alternativer Ansatz: Citrix, quasi ein aufgebohrter Remote Desktop Client, die eigentliche Anwendung läuft auf einem wahnsinnig fetten Server. Unixe erledigen ähnliches mit X11, das bereits "Out of the Box" netzwerkfähig ist (XDMCP, xhosts, ssh mit X11 forwarding).

Eher in einem gemeinsamen Bereich oder einfach dort, wo es während des Installations vorgeschlagen wird?

Wenn ich viel Software aus dem Netz laufen lassen würde, hätte ich für Programme eine eigene Freigabe, auf die Programm-Installateure (Admins) schreiben dürfen, normalsterbliche User aber nicht.

auf Fileserver platzieren [...] Bsp. mdb-Datei der Buchhaltungssoftware für Inventar

Warum hat die keinen "richtigen" Datenbank-Server? MDB-Dateien auf Fileservern sorgen für Dauerbespaßung bei den Admins und Supportern.

oder Allgemein die Dateien Buchhaltungssoftware,

s.o.

Video-Tutorials die sehr riesig sind (pdf-Tutorials würden bzgl. der Größe gut in die DMS passen),

Naja, vom Prinzip her gehören auch die Videos ins DMS. Da wäre halt die Frage, wie viele Tutorials Du als Video hast, und ob das DMS die Videos per HTTP streamen kann (à la Youtube).

Installationen/Images oder auch die Image eines VM's müssen ja irgenwo abgelegt werden, anstatt alles in den Pfaden des Programms zu lassen.

Richtig, das wäre ein sehr exklusiven Fileserver für die EDV. Dort lägen Installationsimages, sämtliche Installer, Treiber-CDs.

Wenn Du VMs zwischen verschiedenen Servern hin und her springen lassen willst, geht das natürlich auch über einen Fileserver (exklusiv für die VM-Server) oder ein SAN.

[...] Open Source DMS [...] Weboberfläche. [...] Datei herunterladen müsste, editieren und erneut hoch laden.) (Es gibt zwar gute DMS, in denen Office-Produkte eingebettet sind, trotzdem wäre MS Office/OpenOffice sicherlich nur ein Teil an Programmen, die man benutzt.

Richtig. Ein DMS mit eigenem "Office-Paket" halte ich für eine schlechte Idee, Du willst eigentlich die stinknormale Office-Software benutzen, die Du schon hast. Da wären Plugins für die Office-Software oder das Betriebssystem angebrachter.

Bsp. erzeugen von Angeboten und Rechnungen mit der Buchhaltungssoftware. Ich müsste die Rechnung erzeugen, an den Kunden schicken und falls ich es evtl. archivieren will, dann in die DMS hochladen.

Automatisierung heißt das Zauberwort. DMS und Buchhaltung sollten sich auf eine Schnittstelle einigen können, über die die jede verschickte Rechnung automatisch archiviert wird. Analog für Angebote.

Open Source hat da den großen Vorteil, dass man sich so eine Schnittstelle auch mal selbst bauen kann. Mit dem Risiko, dass man das System so massiv umbaut, dass ein Umstieg auf die Folgeversion fast unmöglich wird. Man sollte sich also genau überlegen, wie weit man das Customizing treibt. Bei Open Source kann man versuchen, die eigenen Anpassungen in das Projekt einfließen zu lassen, das nutzt nicht nur allen, sondern macht eine inkompatible Folgeversion auch etwas unwahrscheinlicher.

Vermutlich wirst Du früher oder später einen Transfer-Ordner/-Laufwerk einrichten, auf dem jeder schreiben darf [...]

Coole Idee, wenn man nicht so sensible Daten transferieren will, ansonsten würde man die Datei direkt per Email verschicken.

Denk auch mal über Ablagen für Teams und für Projekte nach. Das ist aber eher ein Fall für das DMS als für den Fileserver.

Ein Dokument würde man ja über die DMS machen mit den Rechten.

Genau. Das DMS bringt fast immer irgendetwas Workflow-artiges mit. Das muß natürlich zu eurer Arbeitsweise halbwegs passen. Anders herum bringt auch Workflow-Software meistens ein kleines DMS mit.

Ja, wenn man in Bugzilla bestimmte Anfragen (Idee oder Bug) an einen bestimmten Benutzerkreis senden/anzeigen kann und die Tickets evtl. im Nachhinein für andere Benutzerkreise sichtbar/verschieben kann, dann habe ich fast mein Produkt gefunden.

Bugzilla ist primär nach Produkten strukturiert, und normalerweise ist alles für alle sichtbar. Aber: Groups allow for separating bugs into logical divisions. Groups are typically used to isolate bugs that should only be seen by certain people.

Wenn dann noch die DMS schön strukturiert und mit Informationen gefüllt ist, bräuchte man fast keine CRM mehr. [...] Die Email-Konversationen müsste ich dann noch schauen, wie man dies managed bzw. handhabt, da es ja hier keine Zusätzlichen Meta-Informationen in der Groupware gibt.

Naja, ein paar Meta-Informationen gibt es schon, wenn Du gemeinsame Mail-Ordner benutzt, nämlich die Namen der Mail-Ordner selbst. Und natürlich die Standard-Meta-Daten aus den Mail-Headern. Externe Mail-Adressen (From bzw. To/CC) und Kunden bzw. Lieferanten sind nahezu deckungsgleich, die Verbindung zwischen Mail-Adressen, Telefonnummern und natürlich den Kundennummern steckt im zentralen Adressbuch (ein Fall für LDAP oder ein RDBMS).

Die Telefon-Popup-Fenster-Funktion kann natürlich auch gleich Hyperlinks zu Suchergebnis-Seiten im DMS und im Webmailer anbieten, nachdem sie aus der Telefonnummer mit Hilfe des Adressbuchs eine Hand voll Kundennummern gemacht hat. Richtig cool wäre natürlich eine Suchfunktion, die DMS und Mails parallel durchsuchen kann. Erster Ansatz: Ein relativ blödes CGI, das hintenrum parallel zwei Suchen startet und die eingesammelten Ergebnisse aus DMS und Mails einigermaßen aufgehübscht auf eine Ergebnisseite schreibt. "Nullter" Ansatz: Ein Frameset, dass seinen Query-String an die beiden Such-Funktionen weiterreicht.

Ich würde dann Bugzilla nicht nur für Fehler und Verbesserungen in Bezug auf Entwicklungsprojekte benutzen, sondern würde alles dann hier zusammenfliesen lassen, Bsp. wenn sich Kunden beschweren, weil sie über ein Webshop (in Zukunft), eine falsche Lieferung erhalten haben oder sonstiges.

Wenn Du den Bugzilla weit genug unterteilst, geht das. Aber ich glaube nicht, dass Deine Entwickler wissen wollen, dass Hein Meier statt einer Packung Kopierpapier eine Euro-Palette Kopierpapier bekommen hat. Und die Verkäufer dürften sich nicht die Bohne dafür interessieren, dass man mit int WinMain(HINSTANCE,HINSTANCE,LPSTR,int) unter Solaris nicht weit kommt.

Vielleicht teilst Du das tatsächlich auf zwei Instanzen auf, eine für Probleme mit der Software selbst (Entwicklung, Support, Administration) und eine für die Arbeit mit der Software (Verkauf, Versand, Reklamation, Retouren).

Die Fritzbox hat ab Werk einen VPN-Server. [...] Statt aber das VPN auf Router-Ebene, könnte man ja sicherlich eine VPN-Software im Server installieren: http://openvpn.net/index.php/open-source/documentation/howto.html

Ja, das geht auch. Aber dann mußt Du allen Rechnern oder wenigstens dem Router mitteilen, dass der Weg zu den VPN-CLients über den Server führt. VPN innerhalb des Routers macht das Leben einfacher, weil man dann überall mit der Default Route auskommt.

Ggf. kaufst Du einen etwas kräftigeren Router, wenn Du VPN sehr massiv einsetzt. Da gibt es etliche Appliances, die quasi ein Rundum-Sorglos-Paket bieten.

Da Du Dir zutraust, PCs selbst zusammen zu schrauben, solltest Du Dir auch mal den IPcop ansehen. Standard-PC (alt oder mit Stromspar-CPU) plus ein paar Netzwerk-Karten bringt eine richtig gute Firewall mit einmal Internet, DMZ, WLAN, LAN, VPN Host-to-Net (Road Warrior / Home Office) und Net-to-Net (Standort-Kopplung), per OpenVPN oder IPsec, HTTP Proxy, NTP-Server, usw.

[...] Installations-Images und [...] Software-Verteilung [...]

[...] Hier will ich mich nach dem Projekt auch etwas einlesen und lernen, da ich es sehr interessant finde und garkeine Ahnung habe, wie so etwas realisiert wird. Sprich, wie die Dateien zur Installation bereitgestellt werden,

Fileserver ;-) Oder ein eigenes File-Transfer-Protokoll innerhalb der Verteilungssoftware (HTTP, FTP, propritär).

wie die Verwaltung abläuft,

Im wesentlichen ein Lager voll vorbereiteter Software und eine Anbindung an die Benutzerverwaltung.

Die große Kunst ist, die Software so vorzubereiten, dass sie vollautomatisch installiert werden kann, ohne dass der User eingreifen muß oder eingreifen kann.

Es ist unglaublich, wie viele verschiedene Installer es gibt, und wie kaputt die Dinger manchmal sind. Manchmal gibt es einfach keinen anderen Weg, als eine große Warnung der Art "FINGER WEG" auf den Schirm zu bringen und dann den normalen Installer per AutoIt o.ä. automatisiert durchzuklicken.

um die Installationen/Pakete für bestimmte Workstations freizuschalten

DB-Eintrag, XML-Datei, INI-Datei ...

oder wie sich die Workstation dann die Installationen abholt und ausführt.

Login-Script für User (mit wenig Rechten), stubst einen priviligierten Service an, der die eigentliche Installation übernimmt. Danach wird das Login-Script fortgesetzt, ggf. wird noch mit User-Rechten ein Customizing vorgenommen (z.B. Mail-Adresse in den Mailer eintragen), bevor die Kontrolle an den Benutzer übergeben wird.

(Bei größeren Unternehmen darf man die Images ja auch nicht nur zentral vorhalten, denn bei Zugriff von vielen Workstations hätte man nen Flaschenhals im Netzwerk zum bereitstellenden Server)

Die Images für Workstations werden typischerweise zentral oder pro Standort vorgehalten. Eine WS installiert man ja eher selten neu. Für die Vorbereitung neuer Hardware kann man auch ein separates Labor-Netzwerk nutzen. Im Image ist das "nackte Windows" und der Client für die Software-Verteilung, optional auch schon eine Vorinstallation der "Software für alle" (Office, Browser, Mailer).

Die Images für Thin Clients sind eher klein, ein alter Igel kommt mit 16 oder 64 MByte aus; Thinstation braucht etwa 8 MByte, je nach gewählten Optionen.

Igel haben das Image auf einer lokalen CF-Karte oder einem Disk-On-Chip-IC. Nur wenn man ein Firmware Update macht, wird das Image auf die Igel übertragen. Thinstation kann per PXE oder von einem lokalen Medium (HDD, CF, USB) starten.

Schau Dir mal Unattended an. Das startet von Null, kommt aber ohne maschinenspezifisches Image aus.

(Eigentlich authentifiziert man sich ja bei RDP mit dem Benutzer-Account bei VNC mit einem neu angelegten, bsp. Support-Account. Bei einem parallelen Login in der Open Source Edition würde das dann vermutlich die Virtualisierungssoftware (Virtualbox) übernehmen.

Der Zugriff auf die Konsole läuft immer per Zugriff auf den Host, nicht auf den Guest. VirtualBox erlaubt "concurrent Sessions" per RDP, so kann man auch von 100 Rechnern auf die Konsole einer einzigen VM zugreifen. Siehe Kapitel 7.

Ich finde deinen restlichen Posting auch sehr interessant, was sehr von Erfahrung zeugt.

Naja, nach vier oder fünf Arbeitgebern und einer Weile als Selbständiger sieht man irgendwann, was funktioniert und was nicht.

Alexander

PS: Ja, ICH BIN GESCHWÄTZIG, liebe nörgelige Forumssoftware. grummel