nicht angemeldet
Hi,
Zu teuer und nicht wirklich sinnvoll. SSDs sterben leise und überraschend, und das bißchen mehr Performance brauchst Du in aller Regel nicht. Beim Server ist es vollkommen egal, ob der in 30 Sekunden oder in fünf Minuten bootet, denn der Server läuft Tag und Nacht. Danach hilft Dir viel RAM wesentlich mehr als eine schnelle Platte, denn das kann das Betriebssystem nach aktuellem Bedarf zwischen Buffer Cache (sprich: Platten-Cache) und Anwendungen aufteilen. In der Regel wird fast das gesamte freie RAM als Buffer Cache benutzt.
Ja, habe ich leider etwas zu spät bemerkt, als ich mehr ältere Beiträge von dir gelesen hatte.
Warum willst Du interne Daten ins Internet stellen?
Gerade der (interne) Issue-Tracker gehört in ein geschützes Netz, und ehrlich gesagt möchte ich auch nicht meine Firmenmails irgendwo im Internet rumspuken sehen.
Bugzilla und Trac sind ziemlich blödensicher installierbar; oft bringen die Distributionen sogar schon fertige Pakete mit. Da gibt es also kaum einen Grund, einen gehosteten Server zu benutzen.
Für die Groupware sollte ähnliches gelten.
Für den Zugriff auf Groupware und Issue-Tracker hast Du das VPN; weltweit erreichbar, wo auch immer man sich per analoger Telefonleitung, ISDN, DSL, GPRS, EDGE, UMTS, LTE ins Internet einwählen kann.
Gehostet, weil das abrufen der Emails von außen auf einem betriebsinternen Server sicherlich langsam wäre. (DSL 16.000). Wobei bald auf 50.000 umgestiegen wird mit etwa 10Mbit Upstream. Wenn man jedoch bedenkt, dass ein Offline-Zugriff nicht so oft vorkommt, könnte man die Geschwindigkeit vernachlässigen und hätte bei weitem (richtig konfiguriert) einen höheren Sicherheitsaspekt.
Bei Bugzilla dachte ich, dass man dies evtl. auf die Firmenwebseite integriert (deshalb gehostet). Wo Kunden dann direkt die Fehler eintragen können. (Sonst müsste ich HTTP vom betriebsinternen Server freigeben oder die Kundenfehler kommen auf dem gehosteten Server auf die DB und ich muss von Betriebsintern irgendwie auf die Daten zugreifen). Ja, hier will ich noch nicht tief einsteigen, da ich noch nicht die Zeit gefunden hatte, mich in Bugzilla einzuarbeiten. Davor will ich mir noch VPN anschauen, wie die Applikation (Bsp. normale Software oder Webapps (192.168.1.0) dann von außen (wenn ich mit VPN das betriebsinterne Netz verbunden habe), aufzurufen ist. (Ist ja nicht wie ein Webserver)
Oder, es läuft auf einer VM, so dass ich die VM aufrufe. (Hinzu kommt dann noch, dass die Software(s) ja für mehrere Mitarbeiter (je nach Account) zugänglich sein muss)
. Hier muss ich nach den Anforderungen etwas tiefer einsteigen und mich einlesen.
VMs brauchen selbst kein RAID, das übernimmt das Betriebssystem des Hosts (VirtualBox, VMware Server) bzw. die Virtualisierungssoftware (VMware ESX). Bei VirtualBox und VMWare Server ist eine VM aus Sicht des RAIDs nur ein Verzeichnis mit einigen Dateien, ein oder zwei sehr großen für die virtuellen Platten, dazu ein paar Log- und Konfigurationsdateien.
Ja, ich hatte mich falsch ausgedrückt. Ich meinte damit, dass man einmal das Betriebssystem sichern könnte, einmal die Daten/Dokumente oder eine VM (wo dann die Daten und Dokumente drin sind). Die VM ist ja, wie du bereits erwähnt hast, wenige oder nur eine große Datei. Eigentlich sind die Daten und Dokumente eh betriebssystemunabhängig, aber innerhalb einer VM würde sich alles aber besser mit anderen Programmer besser portieren.
Für den Transport auf einen anderen Host friert man den aktuellen Zustand der VM ein, schafft die Dateien auf den anderen Host, und taut die VM dort wieder auf. ESX und VirtualBox haben die Funktion eingebaut, bei VMware Server geht das, so weit ich mich erinnere, nur manuell.
Privat nutze ich Virtualbox auf meinem Notebook. Erfahrungen damit, wie man die VM über ein Netzwerk aufruft habe ich nicht. Sollte aber weniger das Problem sein. Das Image/VDI liegt einfach nur entfernt, wenn man es im Virtualbox-Frontend einbindet.
*gg
Leider gar nicht lustig. Es kann extrem schwierig sein, Leuten Arbeitserleichterungen zu vermitteln. Je älter das Gehirn ist, desto mehr klammert es sich an alte, eingefahrene Verhaltensweisen.
Und noch schwieriger wird es, wenn die Arbeitserleichterung einmalig einen geringüfügig höheren Arbeitsaufwand erfordert. Zum Beispiel, dass man zu einem Dokument noch drei bis fünf Schlagworte zusätzlich erfassen muß, nach denen man später in Sekundenbruchteilen statt Stunden suchen kann. Das typische Argument ist dann, dass dieser zusätzliche Aufwand so viel mehr Arbeit macht, dass man gar nicht fertig werden kann. Die spätere Arbeitserleichterung wird komplett ausgeblendet. Man hat eigentlich nur eine Chance, wenn man genau die Arbeitserleichterung massiv bewirbt und den Extra-Aufwand schnell und heimlich unter den Teppich kehrt.
Wie wahr. Trotzdem sollte man seine Laune deswegen nicht verderben lassen oder das lächeln vergessen :-)
Nein, intern. Denn die Mails liegen auch alle auf dem internen Server. Wenn der Webmailer gehostet wäre, müßtest Du von der gehosteten Maschine einen Tunnel zu Deinem internen Mailserver öffnen. Ungeschickt und nur schwierig wirklich sicher einzurichten.
VPN starten, Browser starten, auf der Standard-Startseite auf "Webmail" klicken.
Ja, das schaue ich mir wie bereits erwähnt an, wie Applikationen oder Webappliaktionen aufzurufen sind. (Ist ja nicht so einfach wie Netzlaufwerk einbinden). Browsergeschichten dürften jedoch nicht schwer sein. Von außen die URL (Bsp. 192... oder deine erwähnten Kürzel go/webmailer) einfach über das VPN-Gateway nach intern umlenken.
Alternativ, mit einer extrem strengen Password Policy, könntest Du den Webmailer auch in eine DMZ stellen und von außen per HTTPS darauf zugreifen (ggf. mit DynDNS o.ä., um einen festen Namen à la mycompany.dyndns.org zu bekommen).
VPN verrammelt auch den Webmailer in einem Bereich, an den "kein Böser" (von Leuten, die das VPN knacken mal abgesehen) von außen herankommt. Wenn dann ein gedächtnisschwacher Kollege "123456" als Passwort hat, ist das kein so großer Beinbruch wie bei einem öffentlich erreichbaren Webmailer.
Das stimmt. Erst müsste das VPN geknackt werden + zusätzlich noch das Passwort für die Groupware. (Wobei es ja dort mehr zu sehen gibt, als nur die Groupware)
Richtig. Entweder diese eine Software in eine VM packen und den Zugriff zur VM herumreichen, oder besser eine netzwerkfähige Software beschaffen. Evtl. gibt es vom vorhandenen Anbieter ja auch eine "größere" Version, die an mehreren Arbeitsplätzen gleichzeitig eingesetzt werden kann; idealerweise ohne neue Schulung durch identische Programmoberfläche.
VM wäre bei unserer jetzigen Software die einzige Alternative. Ich habe an den Anbieter eine Email herausgeschickt, welche Möglichkeit man sonst hätte, wenn man auf ein anderer Paket umsteigt.
Ja, derzeit lastet alles auf mich. Ich werde aber nach der Ist-Erhebung um viel Zeit bitten und versuche auch meine Zeit sinnvoll einzuteilen, mit der Hoffnung, dass niemand meckert, warum das so langsam vorangeht :-)
Tip 1, noch aus Studentenzeiten: Sorge dafür, dass Du zu jeder Zeit irgendetwas präsentieren kannst. Bei Software-Entwicklung darf das, was Du zeigst, durchaus bei jedem dritten Klick abstürzen und rauchende Trümmerlandschaften hinterlassen, sofern man den Fortschritt zur Vorversion erkennen kann, die bei jedem zweiten Klick alles in Asche verwandelte. Idealerweise zeigst Du natürlich nur die Dinge, die keine Ruinen produzieren. Oder beim Debugging eine lange Liste von Dingen, die Du bereits ausgeschlossen hast.
Ja, bei mir wird am Anfang noch viel Einlesen/Einlernen und eher wenig Fortschritt zu erkennen sein. Wenn das ganze jedoch mal funktioniert, dann wird man sicherlich auch den Merhwert sehen. Und wenn das Ding mal läuft, kann ich mich fortlaufend immer tiefer einarbeiten und weiter lernen und verbessern.
Tip 2: Such Dir eine Hilfskraft. Nenn ihn/sie Praktikant, studentische Hilfskraft, wissenschaftlicher Mitarbeiter, wie auch immer. Viele Routine-Jobs kann man so auslagern. Zum Beispiel durchs Haus rennen, um PC-Marke, PC-Modell, Betriebssystem, RAM- und Plattenbestückung, Standard- und Spezial-Software erfassen. Zum Beispiel 1000 ausgefüllte Fragebögen einhacken. Oder, bei besonders fitten / motivierten Prakikanten: Test-Umgebung aufbauen. "Geh ins Lager, hol 10 brauchbare PCs, baue ein Imaging-System mit Software-Verteilung auf. Teste und bewerte freie Software für diesen Zweck." Das ist eine wunderschöne Diplomarbeit.
In deinen älteren Beiträgen fand ich den Ansatz interessant, wenn auf den Workstations das Image, bzw. den Account für das Betriebssystem auf einem zentralen Server hat.
Grüße