KOPANO-VM als ZARAFA-Ersatz

[catweazle71]

Hallo zusammen,

nachdem ich gestern mit z4h 0.7.4 massive Probleme hatte, anders gesagt es lief einfach nix mehr, habe ich parallel auch mal UCS mit Kopano aufgesetzt. Ans Laufen habe ich es zwar auch nicht bekommen, aber ich bin ein wenig warm geworden und habe auch einige Fehler gemacht. So bin ich jetzt dabei, das Ganze einfach nochmal komplett von vorn aufzusetzen. Kopano lief zwar am Ende (gestern), aber ich habe weder den Relay Host noch fetchmail an den Start bekommen. Und ich habe versucht die Tipps aus dem Forum hier und auch das Wiki und andere Quellen zu beachten. Zu meinen Fragen:

fetchmail:
Das Paket war bereits installiert. Ich habe einen Benutzer mit der Rolle Kopano angelegt. Der Dienst lief jedoch nicht (Systemdienste) und lies sich auch nicht starten. Es gab eine Reihe an Fehlermeldungen, die mir alle nichts sagten. Jedenfalls konnte ich ihn nicht starten. Allerdings hatte ich auch während der UCS Installation fast alle zusätzlich Pakete installieren lassen. Darunter auch Mail und eben fetchmail. Ggf. wurde da ja was konfiguriert, was hinterher mit Kopano nicht zusammen passte. Ich musste ja das Mail Paket hinterher auch wieder deinstallieren, als ich Kopano installieren wollte. Das werde ich nun anders machen. Aber grundsätzlich bleibt hier die Frage, ob ihr das auch erlebt hattet und wie ich das ggf. lösen kann?

Relay-Host:
Das Relay hatte ich, wie im Handbuch beschrieben, in der "UCS Registrierung" in den Variablen (weiß die Namen nicht mehr genau) mail/relay=yes und mail/relayhost=mail.gmx.net:587 eingetragen. Dann habe ich die smtp_auth neu angelegt und dort den Host mail.gmx.net:587 und meinen Userasswort eingegeben. Danach noch postmap ausgeführt. Das hat aber alles nichts gebracht. Die Mails wurden aus der Webapp zwar angeblich versendet, landeten aber im Postausgangskorb und verblieben da dann auf ewig. Mache ich hier etwas falsch?

 

[catweazle71]

Ok also Kopano auf UCS läuft nun fast einwandfrei.

Den Relay-Host habe ich nun per Konsolenbefehle ucr set ... eingerichtet.
fetchmail ist bei meiner jetzigen Installationsmethode, erst Kopano installieren und danach fetchmail auch gestartet und läuft sauber.

Jetzt habe ich aktuell nur noch ein Problem. Da ich ja eine lokale Domain eingerichtet habe, bekomme ich beim Versenden von Mails über den Relay Fehlermeldungen.

Entweder: Ich versende mit meiner lokalen Mailadresse und der Relay meckert "sender domain not allowed" oder sowas in der Art
Oder: Ich versende als meine GMX Mailadresse (send as meine.adresse@gmxpro.de), dann meckert Kopano, dass der Sender nicht im LDAP gefunden werden konnte.

Wie kann man dieses letzte Problem lösen?

 

[catweazle71]

Nächster Fortschritt. Ganz nebenbei, schön wie man so seine Ostertage verbringen kann ;-) Ich hoffe das hilft vielleicht dem ein oder anderen hier mit derselben Problematik

Ich habe nun gmxpro.de einfach als Maildomain im UCS hinzugefügt. So "darf" ich also auch Adressen dieser Domain als primäre Mailadresse vergeben und Mails werden dann auch von dieser Adresse versendet.
Blöd an der Lösung ist, dass Mails an diese Domain dann natürlich direkt von Kopano verarbeitet werden. In meinem Fall ist das erstmal nicht so schlimm, da ich privater Nutzer bin und keinen anderen Adressaten mit dieser Domain habe. Aber wenn ich z.b. eine Mail an willi.wurz@gmxpro.de versenden wollte, dann bekomme ich garantiert einen Fehler, da der ja nicht in meinen Kopanobenutzern ist.

Also entweder gibt es noch eine Lösung, wie ich ohne diese zusätzliche Domain Mails mit meiner gmxpro Adresse versenden kann,
oder es gibt eine Lösung, wie ich quasi Kopano bzw. UCS beibringen kann, dass Mails an die Domain gmxpro.de nicht lokal verarbeitet werden sollen, sondern an den Relay gehen.

 

[FricklerAtHome]

Hallo catwealze71

im Forum gab es schon mal einen Thread zum user abhängigen "relaying", vielleicht kann dir da geholfen werden.
Dein Bedarf sieht wenn ich es richtig verstanden habe so aus: Mail für USER-A mit der Mail-Adress USER-A@gmxpro.de wird per fetchmail abgeholt und an den lokalen USER-A@deineDomäne.xy zugestellt. Wenn nun der lokale USER-A antwortet soll als Antwortadresse wieder USER-A@gmxpro.de genutzt werden. Das müsste mit der Einstellung eines SENDEN-ALS Alias gehen. Die Mail Domäne gmxpro.de zur lokalen Mail Domäne zu erklären ist wie du schon bemerkt hast, keine wirklich gute Idee.

Fetchmail beherrscht ein Umschreiben der Adresse: Das geht wie folgt => statt sinngemäß fetchmail mitzuteilen für welchen lokalen Nutzer es Post abholt ( geschieht mit poll ...... is USER-A here ), kannst du fetchmail auch sagen die abgeholte Mail wird mit einem neuen Benutzernamen an einen weiteren SMTP Server übergeben. Das sieht dann so aus => poll ..user 'USER-A@gmxpro.de' ...... is "USER-A@deineDomäne.xy" smtphost "IP-des SMTP-SERVERS/25".
Da du an den SMPT-Host des lokalen Kopano übergeben möchtest wäre die entsprechende IP = 127.0.0.1/25 (das /25 bezeichnet den PORT). Damit kommen die abgeholten Mails auch in der internen Domäne an. Was noch fehlt ist die Absende Adresse des loaklen Benutzer beim Versand wieder auf '@gmxpro.de' umzuschreiben. Das könnte in UCS über die alternativen E-MAIL Adressen in der Benutzerverwaltung gehen.

Ich personlich habe seit ewigen Zeiten "private" Mail-Domänen für die Familie etc. Die gibt es für wenig Geld (ca. 1,10 Euro / pro Monat mit 25 Adressen) bei den einschlägigen Providern. Hier habe ich auch eine private Domäne die ich als dynDns-Relay benutze und damit meinen Syno-Router unabhängig von DynDNS oder sonstigen Anbietern mit einem sprechenden Namen im Internet bekannt mache.

Beste Grüße
Der FricklerAtHome

 

[FricklerAtHome]

Als Ergänzung

es sollte auch mit: poll ...... is "USER-A@deineDomäne.xy here
gehen. Ich leite all meine Mail mit fetchmail zunächst an einen Trend-Micro AntiViren und Spam Filter. Der hat als Domänen-Namen "@antivir.local". Dieser übergibt dann alle MAIL's wieder automatisch an KOPANO (quasi ein internes RELAY) per smtp.
fetchmail sieht dann so aus:
poll pop.provider.de protocol pop3 port 995 user 'frickler@meineDomäne.de' pass 'sehr-geheim' is "frickler@antivir.local" smtphost "192.168.1.x/25" ssl fetchall

und in meinem postfix habe ich mittels virtual_aliases dann einen Eintrag:

frickler@antivir.local frickler@meineDomäne.de

Das funktioniert super stabil und reibungslos.

Beste Grüße
Der FrickleAtHome

 

[catweazle71]

Hi FricklerAtHome,

ehrlich gesagt würde mich der letzte Teil am meisten interessieren. Ich habe eine eigene Domain, die ist registriert bei meinem DynDNS Anbieter selfhost.de. Die Domain heißt im-ruhrpott.eu. Nun würde ich halt gern mit der auch Mails versenden können. Da die aber über den DynDNS Account gehen, werden die ja üblicherweise abgelehnt. Bisher dachte ich ich brqauche eine feste IP-Adresse, um Mails auch aus meiner eigenen Domain versenden zu können. Das was Du geschildert hast, hört sich aber so an, als ob es auch anders gehen könnte.
Oder liege ich da komplett falsch???

 

[FricklerAtHome]

Mit der im-ruhrpott.eu wirst du eventuell kurzfristig Mails versenden können, aber sie werden nicht lange ankommen.
Trotz der eigenen E-Mail Domänen versende ich alle Mails über die smtp-auth Funktion meines Providers.
Durch den berechigten Versand über den Provider landen meine Mailadressen nicht auf den Black / Spam-Listen der empfangenden Mail-Server.

Wir nutzen immer zwei Dinge: eine Mail-Domäne incl. echtem Mail-Server bei einem Provider und eine registrierte Domäne bei einem Provider bei der man den DNS-Record auf die eigene IP-Adresse umschreiben kann.
Ich sitze auch im-Ruhrpott und habe zum Glück eine "fast" feste IP4 Adresse bei einem Kabelprovider. Ich könnte also fast auf dynDNS verzichten.

Den Aufwand betreibe ich um Ausfälle an meiner häuslichen Infrastruktur begegnen zu können. Fällt bei mir zu Hause etwas aus, laufen alle Mails halt beim Provider trotzdem auf. Bei längeren Unterbrechenungen lesen wir halt per IMAP oder auf dessen Web-Mail-Client. Die "sprechende-Domäne" macht die Nutzung von Zertifikaten sehr viel einfacher.

Aber du hast Recht. So ein Samstag vor Ostern lädt einfach zum "frickeln" ein.

Beste Grüße
Der FricklerAtHome

 

[catweazle71]

Eigentlich ist bei mir alles sehr ähnlich, glaub ich.
Meine Domain ist bei meinem Provider selhost.de. Dort auch die DyDNS. Mein Relay (smtp_auth) ist ebenfalls selfhost. ich bin auch bei einem Kabelprovider mit fast fester IP. ABer eben nur fast.

Aber bei z4h war das so, wenn ich ein Mailaccount für meine im-ruhrpott.eu Domain angelegt habe und mit der dann Mail versendet habe, hat das nicht geklappt. Weil eben DynDNS. Ne feste IP will ich mir nicht leisten.

Mit Ach und Krach hab ich grad noch meine eigenen Zertifkate (selbst erstellt mit eigener kleiner CA) auf den UCS kopiert. Hab nichtmal einen Share für Windows Client hinbekommen, da ich ja nicht in einer Domäne mit dem Client bin.

Mein Hirn ist heute schon ziemlich weich...

 

[FricklerAtHome]

Dann wird es Zeit für ein gutes Bier, den gelb-schwarzen Schal und ein wenig Bundesliga-Abwechslung.
Ich sitze manchmal auch stundenlang an einer Frickelei und komme nicht weiter.

Eigendlich sollte alles mit deinem Selfhost Account funktionieren. Zumindest wenn du das Mail-Basic Paket hast. Der Rest ist im UCS bzw. Kopano einzustellen. Leider kann man dort nicht so einfach die Konfigurationsdateien bearbeiten. Sie sind häufig "zerrissen" damit die Paketabhängigkeiten funktionieren. Und dann kommt da noch diese Konfigurations-Center, in dem manche Ini-Einträge möglich sind, andere aber nicht.
Schreib mal auf was bereits alles funktioniert. Läuft die WebAPP? Sind deine Handy eingebunden? Funktionieren IMAP / ICAL. Wenn das intern läuft und du an einen weiteren Dummy-User Mails senden und von Ihm empfangen kannst, ist der wichtigste Erste Schritt getan. SMTP-AUTH per Relayserver und Fetchmail pro User lassen sich dann auch gerade ziehen.

Der FricklerAtHome

 

[catweazle71]

Folgendes läuft bei mir:
- WebApp läuft, nutze ich aber quasi nie (nur zum Testen)#
- Anbindung an Outlook via ActiveSync läuft (besser sogar als mit z4h)
- Anbindung an iPhone + iPad läuft via ActiveSync
- Ich kann mit meiner gmxpro.de Adresse versenden und empfangen (wie gesagt nur wenn ich gmxpro.de als Domain hinzugefügt habe im UCS)

Was nicht geht:
- Ich kann mit einer ruhrpott.eu Adresse zwar versenden, diese Mail kommt in der Regel aber nicht an (getestet mit Firmenaccount, landet dort im SPAM)
- Ich kann einen Mail von extern an die ruhrpott.eu Adresse nicht empfangen

Selfhost: Ich habe grad mal geschaut. Ist nicht so einfach durchzublicken. Aber ich scheine das Paket Domain dynamisch zu haben und kein Mailpaket.

Ist das etwa der Grund, warum Mails an meine dynIP / lokale domain nicht zugestellt bzw. versand werden können? Wenn ja, hast Du eine Ahnung, was ich machen kann/muss? Muss ich das Mailpaket basic bestellen?

 

[catweazle71]

Ok ich gebe wohl auf. Der eigene Mail-Server mit dynIP bzw. dynDNS funktioniert einfach nicht.

Ich habe bei selfhost.de ein bisschen rum experimentiert und ggf. was kaputt gemacht.
Hatte mal einen neuen MX-Record eingetragen, der direkt auf meinen Mail-Server zarafa.meine-domain.eu gezeigt hat.
Dann habe ich mal einen spf Eintrag in der DNS Konfig vorgenommen, da arcor.de eine Mail von mir abgelehnt hat mit dem Fehler "Remote host said: 550 5.7.1 spf policy (FAILED)".

Das hat alles nix gebracht, also habe ich die Einträge wieder gelöscht. Ich weiß nciht, ob durch diese Versuche was kaputt gegangen ist, jedenfalls landen alle meine Mails, egal von welcher Absender-Domain, im Spam-Ordner auf meinem Firmen-Account.

Es gibt da übrigens ein cooles Tool (wahrscheinlich jedem bekannt, nur mir bisher nicht), mit dem man so einige Analysen bzgl. der eigene Domain machen kann: https://mxtoolbox.com/SuperTool.aspx

Letzten Endes ist die Lösung im UCS mit dem Hinzufügen der Domain gmxpro.de in die lokale Domänenstruktur ja auch nicht das gelbe vom Ei.
UCS ist eben wohl eher eine Lösung für Firmen mit fester IP ;-)

 

[catweazle71]

Ich habe eines meiner Probleme nun gelöst. Hoffe ich zumindest. Die Lösung ist zwar unabhängig vom Einsatz UCS/Kopano oder z4h, aber ich poste das trotzdem mal hier rein. Und eigentlich ist die Lösung erschreckend einfach.

Mein dynDNS Anbieter ist ja selfhost.de. Bei denen habe ich das Paket Domain dynamisch. Ich kann dort neben der Domain auch beliebig viele Postfächer anlegen. Diese lassen sich a) als POP3 Konto verwalten und b) sind entsprechend Konten meiner loaklen Domain.
Bei selfhost lässt sich der Mail-Dienst nun auf verschiedene Weise konfigurieren. Bisher hatte ich immer Mail-Spool aktiviert. Dann wird halt ein MX-Record generiert, der auf meine dynIP zeigt. Der eigentlich Endpunkt ist dann also, nach meinem Verständnis, mein lokaler Mailserver z4h bzw. Kopano.
Es ist jedoch auch möglich, den Maildienst als Mail-Space zu konfigurieren. Dann wird der MX-Record auf meine dynIP gelöscht, und es gibt nur noch einen auf den Mail-Server von selfhost.de. Der Endpunkt müsste dann ja bei selfhost liegen und die haben eine feste IP.

Der Logik nach müssten dann Mails an alle meine lokalen Mailkonten bei selfhost landen. Das einzige was ich zusätzlich machen muss, ist die Mailadressen , die ich im Kopano anlege, auch noch bei selfhost anzulegen und die Mails dann mit POP ganz normal von fetchmail abholen zu lassen, genauso wie bei meinem GMX Konto. Daher eigentlich so einfach.

Das einzige, was jetzt noch ein wenig unschön ist, dass ich gmxpro.de immer noch als Domain im UCS eingetragen habe. Das musste man bei z4h ja nicht, da dort im Hintergrund keine ganze Domänenstruktur betrieben wird.
Also wäre ich eigentlich super erfreut, wenn es bei z4h weitergeht und ich würde auch dafür stimmen Richtigung Kopano4h zu gehen, auch wenn es noch eine Weile dauert.

 

[Online78]

Lieber FricklerAtHome

vielen Dank für Dein Beitrag #99. Du hast wohl ins schwarze getroffen. Ich habe mit tail -f /var/log/mail.log mal beobachtet was passiert. Fetchmail sieht tatsächlich die Nachrichten auf den Konten des Providers.

Ebenso bist du korrekt darin, dass es "Fehler" in der main.cf haben muss. Folgendes kann ich festhalten:
- kein Eintrag mydomain = provider.de sondern:
# some basic mail system settings
myhostname = XXXXXXXXXXXXXxxx
# mydomain is unset - The default is to use $myhostname minus the first component.
myorigin = XXXXXXXXXXXXXXXXXx
smtp_helo_name = XXXXXXXXXXXXXXXXXXXX

- ebenso habe ich kein Eintrag mit virtual_mailbox_domains gesehen, wenn ich in univention im Bereich Registry mail/postfix/virtual/enable auf false setze, wenn ich auf true setze sehe ich die Einträge, aber ohne Eintrag der virtuellen domains.Sie sehen so aus:

virtual_alias_domains =

virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.groups,
ldap:/etc/postfix/ldap.distlist,
ldap:/etc/postfix/ldap.virtual,
ldap:/etc/postfix/ldap.external_aliases,
ldap:/etc/postfix/ldap.sharedfolderremote,
ldap:/etc/postfix/ldap.sharedfolderlocal_aliases

wenn ich nun hinter virtual_alias_domains = die Domains händisch eintrage ändert sich nichts, by the way ich habe mit reload und restart postfix neu gestartet. Stimmt es, dass ich dies nach händischen änderungen tun soll?

zudem besteht die datei /etc/virtual_alias sowie /etc/postfix/virtual nicht.

--> wenn ich jedoch mail/postfix/virtual/enable auf true setze, werden die Mails nicht über den Relay versendet, sondern intern - was natürlich aufgrund des fehlenden Empfängers zu Fehler führt:

postfix/trivial-rewrite[3364]: warning: do not list domain YYYY in BOTH virtual_alias_domains and virtual_mailbox_domains
Apr 2 19:54:55 kopano postfix/trivial-rewrite[3364]: warning: do not list domain XXXX in BOTH virtual_alias_domains and virtual_mailbox_domains
Apr 2 19:54:55 kopano postfix/smtpd[3361]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <testmail1@XXXX.ch>: Recipient address rejected: User unknown in virtual alias table; from=<testmail2@YYYY.ch> to=<testmail1@XXXX.ch> proto=ESMTP helo=<kopano.local>
Apr 2 19:54:55 kopano postfix/trivial-rewrite[3364]: warning: do not list domain YYYY.ch in BOTH virtual_alias_domains and virtual_mailbox_domains
Apr 2 19:54:55 kopano postfix/smtpd[3361]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <testmail2@YYYY.ch>: Recipient address rejected: User unknown in virtual alias table; from=<testmail2@YYYY.ch> to=<testmail2@YYYY.ch> proto=ESMTP helo=<kopano.local>

testmail1@XXXX.ch --> auf einer Virtuellen Domäne in Kopano
testmail2@YYYY.ch --> auf einer Virtuellen Domäne in Kopano

das mal als kurze Rückmeldung, vielleicht hat jemand ein Inpuls?
Danke für Eure Hilfe,
Domi

 

[FricklerAtHome]

Hallo online78

komme gerade aus Ostern. Leider gibt es jetzt einige familiäre Pflichten. Ich schaue aber über's Wochenende mal über deine Rückmeldungen. Das Gleiche als Antwort auch an DIRK.

Gruss der FricklerAtHome

 

[catweazle71]

Das Gleiche als Antwort auch an DIRK.

Gruss der FricklerAtHome

Hi zusammen,

ich bin wieder komplett auf z4h umgestiegen. UCS war mal ne nette Abwechslung und sicher auch ganz hübsch, aber bestimmte Möglichkeiten wie Backup gibt es da nicht so unkompliziert wie bei z4h mit zarafa-backup. Außerdem stimmt es, was Andy+ im Parallel-Thread schreibt, dass es sich im Grunde nicht lohnt bzw. viel zu viele Ressourcen schluckt, eine VM nur für Kopano zu betreiben.

@Frickler: Meintest Du mit DIRK mich? Ich rätsel grad, woher Du dann meinen Vornamen kennst? Nicht dass ich das schlimm fände. Warum auch? Aber hat das einen besonderen Grund? Bin neugierig ...

 

[FricklerAtHome]

Für jeden der bei Z4H bleibt habe ich Verständnis. Das ist hier kein Glaubenskrieg, sondern eher die Frage: "was machen wir eigendlich, wenn wie damals nach dem Rückzug von Synology und Julian D., unsere liebste Group-Ware nicht mehr so funktioniert wie sie sollte, oder gar mit einem wichtigen und sicherheitsrelevanten UpDate des DMS oder weiterer Komponenten nicht mehr läuft.
Nun dieser Thread soll erste Hilfen leisten. Ich persönlich habe ihn ja auch bereits wieder verlassen. --- Nicht ganz: Kopano läuft nun auf meinen Syno's, als virtuelle Maschine mit Debian. Dafür aber Top-Aktuell mit integrierten Antivir und Spam-Schutz etc.
Da hat jeder seinen eigenen Geschmack. -- Ich frickel halt gerne und habe die VM so aufgesetzt und gesichert, das ich nun quasi für die betreute Nachbarschaft einen 3,2 GB großen Rohling dieser Installation habe (Export mittels .ova Datei). In der betreuten Nachbarschaft, oder bei einem total-Absturz meiner Infrastruktur, kann ich innerhalb von 3 Minuten wieder ein lauffähiges Kopano aktivieren. Funktionell ist das mehr als sehr nahe an einem nativen Syno -Paket und es funktioniert auch nach großen Updates des DSM (mit einer meiner Maschinen bin ich schon auf 6.2 beta --- läuft!!)
Resourcen? Ja, ich reserviere für die VM's mindesten einen Prozessor und in der Regel 3 GB RAM. Das RAM wird auch "verbraucht", aber mit den entsprechenden Guest-Tools in der VM benötige ich nicht mehr CPU-Resourcen als ein Docker-Container. Lediglich RAM und der genutzte Plattenplatz sind größer.
Die VM läuft bei mir auf einem BRTS Raid mit Snapshot-Backup. Das ist viel trivialer als zarafa-backup und in meinem Szenarien auch noch sicherer, ich spiegel meine VM's auf eine zweite SYNO (so gut wie gar keine Ausfallzeit, beworbenes Merkmal des DSM 6.1) oder in der betreuten Nachbarschaft sind neben den Snapshots der Syno noch 4 stündliche HardCopys der VM auf externen Laufwerken abgelegt.
Ausfallquote bisher 0%. Wiederherstellung nach totalem NAS Ausfall durch Rückspielen des letzten Backups ca 4 Minuten. Keinerlei erneute Frickelei auf Commandozeilen, Datenbanken, Dateisystemen. VM importieren, starten, fertig! Incl. aller Features etc.


--- Das Alles ist kein Argument gegen Z4H. Ich habe, und bin noch nicht fertig, einiges an Zeit (Resourcen) aufgewand. Aktuell beschränkt sich der Aufwand auf die wöchtliche Überprüfung der "Nightly Buildys" im Community-Zweig von Kopano. Alles Debian-Zeug erledige ich mittels Cron-Dämon. Ich bin aktueller als die lizensierten Kopano-Installationen und UCS / Kopano rufen nicht ständig zu Hause an. Das Vorgehen bei Total-Abstürzen (Hardware-Ausfall) ist erprobt und funktioniert. Jede Migration ist mit dem MAPI-basierten kopano-backup deutlich einfacher und besser als alles was Z4H anbietet.
--- Ich bin zwar kein Linux-Profi, aber mit den gemachten Erfahrungen und den bestehenden Vorkenntnissen, habe ich das Ding ans laufen bekommen. In der betreuten Nachbarschaft haben wir bis zum Frühjahr 2017 an DSM 5.2 festgehalten, weil Zarafa von Julian nicht auf DSM 6 läuft. -- Wir waren und sind auf der Suche nach einer Lösung, die uns deutlich unabhängiger von Distributoren oder Synology macht. Die nun generierten VM's bekommen wir zur Not auch auf andere NAS Systeme portiert. Unsere Synos sind uns auch heilig. -- Aber letzlich muss es funktionieren, aktuell und sicher sein.
Wir haben aus der Suche nach unseren Notwendigkeiten Erfahrungen gesammelt, Möglichkeiten erfahren, Entschlüsse gezogen und umgesetzt. Eine VM DEBIAN/KOPANO ist nicht besser oder schlechter als ein SPK Zarafa4Home. Entscheidend ist wie gut das Paket / der Eigenaufwand für den real Nutzenden ist. Vorteile für den Einen können Nachteile für den Anderen bedeuten.

@catweazel71
Wir kommen beide aus dem Pott, ich arbeite sogar in deiner Heimatstadt. Es gab aus deinen Beiträgen einige Hinweise, die mich letzlich auch zu deiner HP führten. Wir sollten jetzt nicht allen bestätigen das Catw--71 mit Vornamen D.. heist. ;-))

Gruss aus dem Sommer
Der FricklertAtHome

 

[catweazle71]

Wir kommen beide aus dem Pott, ich arbeite sogar in deiner Heimatstadt. Es gab aus deinen Beiträgen einige Hinweise, die mich letzlich auch zu deiner HP führten. Wir sollten jetzt nicht allen bestätigen das Catw--71 mit Vornamen D.. heist. ;-))

Um Gottes Willen, keiner darf wissen, dass ich ..rk heiße ;-)))

Ist ja witzig. Meine HP ist ziemlich alt und tatsächlich habe ich sie gestern mal vom Netz genommen (aber nicht wegen Deines Beitrags). Ich mache an der Seite nix mehr und habe nicht mehr die Zeit dafür. Das einzige was noch läuft ist eine DS Photostation. Die Heimatstadt auf der HP könnte somit veraltet sein, ich habe mal in Essen gewohnt, dann in Dortmund und jetzt in Ratingen. Aber das Wichtigste ist, ich bin ein Ruhrpott-Jung und da ist auch mein Herz und meine Seele. "Is doch jeder selbs in Schuld, wenn er das nich kapiert" ;-))) Und Arbeiten tue ich auch im Pott

 

[FricklerAtHome]

@catweazel71

Ich arbeite in DO und wohne in GE, komme aus WAT. Also ein Pendler im Pott. In der einen Sache wo die Ruhrie's keinen Spass kennen (dem Fussball) bin ich also Betroffener. Morgens darf ich nicht sagen wo ich hinfahr, auf der Arbeit nicht wo ich herkomme.
Ich pendel also zwischen Nirgendwo und Unbekannt. ;-))))

Mein jetziger Beitrag betrifft aber den Punkt "Resourcen Verbrauch virtueller Maschinen". Meine aktuelle "KOPANO-VM" läuft bei mir auf einem NAS mit dem Namen "DATEN". Zusätzlich betreibe ich noch ein baugleiches Syno-NAS mit dem Namen "HOME" (hier liegen alle Benutzerverzeichnisse und die Cloud-Server-Dienste. Ein drittes Syno-NAS (DS15j) dient als "last-line" Backup. Ansonsten sichern sich gegenseitig HOME vs. DATEN.

Mittels SNMP controlliere und protokoliere ich diese Synos. Wir sind ein 4 Personen Haushalt, verarbeiten ca 100 Mails pro Tag (natürlich tagsüber mehr als in der Nacht) Das beigefügte Bild zeigt den Verlauf der CPU Belastung aller Syno's aus 2 Stunden und das andere den aktuellen Stand meiner Kopano-Integration





So viel Resourcen wie angedeutet benötigt eine VM mit Linux nun wirklich nicht.


Schönen Abend
Der FricklerAtHome

 

[FricklerAtHome]

PS: ich habe noch nicht erwähnt, dass eine weitere VM (WIN10) auf der SYNO HOME den ganzen Syno-Kram mit Heim Automatisation, Systemübersicht steuert, kontrolliert, regelt, und am Laufen hält. Auf der Syno DATEN läuft zusätzlich eine virtuelle Syno für einen anders gearteten Viren und Spam-Schutz (war mal eine private Diskussion zwischen Tosoboso und mir).
Zusammen mit meinem Syno -Router und der dort laufenden Intrusion-Prevention-APP passe ich zumindest das bei mir auflaufenden "Eindringszenario" laufend an. Man veregssen nie: zwischen Z-PUSCH // SS(H-L) WEB-ZUGANG stehen nur der Benutzername und sein Password. Ich / Wir benutzen zusätzlich private Client-Zertifikate. In der VM geht das, aktuell bei Z4H nicht. -- Ob reverse proxy oder sonstige Lösung: zumindest der Zugriff über den Z-Push Port ist unsicherer als in der bei uns eingesetzen VM Lösung, die über die Cleint-Zertifikate quasi einen Radius-Server für Zugriffe aus dem Internet abbilden.

Die meisten wird das nicht belasten. Die von Euch die schon mal erlebt haben wie schnell Blacklist euren Mailversand unterbinden verstehen was ich meine. Als reale Erfahrung wird meine IP im Internet standig auf antwortendene Ports geprüft. Ist ein Port wie z.B. für Z4H offen, wird nur noch nach der Kombi User / Passwort gesucht. Ist dies nicht besser geschützt als erwartet, sind die BÖSEN im System. Ich / Wir machen es ihnen halt gern schwerer, da sie zuvor noch durch ein zertifikat auf ihrer Maschine beweisen müssen, das sie zu uns gehören. ---- Grundsätzlich sollte also jeder überlegen Was und Wie er Dinge aus seinem privaten Netz im Internet zugreifbar macht.

Ich bin nicht die Polizei, Heise security oder das BSI,
aber die Hürden "ich versteck mich in der Menge", "Wer hat schon Interessen an mir und meinen Daten", "Ich bin viel zu klein um gehackt zu werden" usw. sind wirklich auch kein eigenverantwortlicher Weg.
Mit der VM Lösung fühle ich mich besser. Ja, Synology muss den Weg zur / in die VM aktuell sicher halten, aber alles danach liegt in meiner Verantwortung.

Beste Grüße
Der FriklerAtHome

 

[Andy+]

..............Keinerlei erneute Frickelei auf Commandozeilen, Datenbanken, Dateisystemen. VM importieren, starten, fertig..........

Ich finde gut, was ihr, also Du und Deine Mitstreiter, macht. Es ist auch euer geistiges Eigentum und könnt damit anstellen, was ihr wollt.

Es sind zwei Dinge, die mich beschäftigen. Einerseits können längst nicht alle so mit PuTTY und WinSCP und ggf. weiteren Tools umgehen, sowas zu bewerkstelligen. Diese Art von Installation erfordert deren kompetenten Umgang, zudem erfahrenen Umgang mit Rechten. So gesehen ist eine Synology mit einer funktionierenden SPK daher genau das, was viele brauchen, dazu gibt es auch ein Wiki usw. Und da kommen wir zum andererseits, indem ich im Zusammenhang mit diesem Forum und dessen Philosophie, Deine Philosophie hinsichtlich Miteilsamkeit nicht verstehe. Einerseits schreibst Du gerne, möchtest aber für eine ordentliche Installation Dein Wissen nicht teilen, obwohl es hier jeder macht, was das Forum hier eigentlich auch ausmacht. Tosoboso macht im Grunde das, was Du machst und verhält sich da anders.

Denkst Du, Du hast dann noch mehr, als wie nun Deine betreute Nachbarschaft? In gewisser Weise vielleicht. Das möchte ich nur verstehen.