Jump to content
Froxlor Forum

Netsurfer

Members
  • Content Count

    162
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Netsurfer

  1. So - Problem gelöst! Da mein Problem ja darin bestand, dass der Token (der in "/.well-known/acme-challenge/" abgelegt sein sollte) nie gefunden wurde bei der Überprüfung durch LE, ich aber den entsprechenden Alias gemäß des Konfig-Templates gesetzt hatte, habe ich dann mal kurz überlegt und bin der Ursache dann schnell auf den Grund gekommen. Bei mir (Wheezy + Apache 2.2.22) wird das Verzeichnis "conf-enabled", welches im Konfig-Template angegeben wird, in der apache2.conf gar nicht eingebunden! Beim 2er Apache ist es auch standardmäßig eher das Verzeichnis "conf.d". Also entweder die Datei "acme.conf" ins "conf.d" Verzeichnis stecken, ODER in der Datei "apache2.conf" das Verzeichnis "conf-enabled" mit einbinden (inkludieren). Dann klappt's auch mit Let's Encrypt. Gruß Gunther
  2. Ja, gemäß dem (passenden) Konfig-Template. Apache auch schon mehrfach neu gestartet.
  3. Hallo zusammen! Ich will keinen neuen Thread aufmachen, aber auch ich habe Probleme LE ans Laufen zu kriegen. Ich hatte zuvor bereits eine andere SSL Konfiguration (gekauftes Zertifikat) und 2 IPs für SSL, wobei eine meine Verwaltungsadresse ist. Es geht also (erstmal) nur um eine IP Adresse. Habe mir bereits alles was ich hier im Forum dazu finden konnte durchgelesen, war aber trotzdem nicht in der Lage mein Problem zu lösen. Verwende die aktuelle Froxlor Version ( 0.9.38.7-1) mit Wheezy und Apache/2.2.22 Den Ordner unter /var/www/froxlor/.well-known/acme-challenge hat er auch angelegt und Einträge in der DB (panel_customers) werden auch erzeugt. Aber immer wenn ich den Cron-Job (manuell) ausführe, erhalte ich einen 404er ala: http://example.com/.well-known/acme-challenge/hSg7MXFsjq-Ff8A8j4M12uO-OAzA25J5-rPdzVJ8h24 - token not available Daraus rsultierend dann auch: PHP error: {"type":2,"message":"file_get_contents(http:\/\/example.com\/.well-known\/acme-challenge\/hSg7MXFsjq-Ff8A8j4M12uO-OAzA25J5-rPdzVJ8h24): failed to open stream: HTTP request failed! HTTP\/1.1 404 Not Found\r\n","file":"\/var\/www\/froxlor\/lib\/classes\/ssl\/class.lescript.php","line":232 Könnte mir bitte jemand freundlicherweise helfen? Stehe echt auf'm Schlauch im Moment - danke! Gruß Gunther
  4. Hi Thilo! Ich hab' bei mir Dovecot im Einsatz. Aber vielleicht hilft dir bspw. diese Seite weiter - siehe: http://www.courier-mta.org/maildirquota.html Denke aber mal, dass d00p uns noch etwas Genaueres dazu sagen kann/ wird - mal abwarten. Gruß Gunther
  5. Hi Thilo! Lass dir mal deine gesetzen Quotas per repquota / anzeigen. Ich bin mir sicher, dass du nur die (User) Quotas für den Webspace angezeigt bekommst, sofern du welche (in Froxlor) gesetzt hast. Ansonsten kannst du das mal testen, indem du einem Kunden ein Webspace-Kontingent zuweist, dir dann die Ausgabe von repquota anguckst, anschließend demselben Kunden zusätzlich ein E-Mail-Kontingent zuweist und dir wieder die Ausagabe von repquota anguckst (und natürlich immer warten, bis der Cronjob auch gelaufen ist). Als Linux Noob weiß ich ehrlich gesagt auch gar nicht, ob man für einen User auf derselben Partition für unterschiedliche Verzeichnisse überhaupt unterschiedliche Quotas setzen kann? Insofern würde ich also aktuell behaupten: - Die User Quotas greifen ausschließlich für den Webspace - Die E-Mail-Kontingente sind rein zur Info für den Admin und Kunden in Froxlor Aber Genaueres könnte uns da bestimmt d00p zu sagen. Mal sehen, ob er hier mitliest und uns ggf. "aufklärt". Gruß Gunther
  6. Erledigt: https://redmine.froxlor.org/issues/1624
  7. Prompter Service - besten Dank!
  8. Hi, ich nochmal ...! Vermutlich habe ich das neue Feature noch nicht richtig verstanden, aber ist das so gewollt, dass die Sicherung/ das Backup jeweils nur einmal läuft, nachdem der Kunde es "angestoßen" hat? Übrigens ist es imho "gefährlich", dass der Kunde nachdem er eine Sicherung "beauftragt" hat, keinen Zugriff mehr auf die entsprechenden Einstellungen hat. Was wenn er "aus Versehen" ein falsches Verzeichnis angegeben hat?
  9. Hi! Ich habe mich zwar noch nicht bis ins Letzte mit OPcache auseinandergesetzt, aber momentan denke ich, dass insbesondere die Eigenschaften, die tatsächlich u.a. von der Größe (Anzahl Files) der jeweiligen Domain abhängen, besonders wünschenswert sind. Hier eine kurze Liste: opcache.revalidate_freq= opcache.validate_timestamps= opcache.max_accelerated_files= opcache.memory_consumption= opcache.interned_strings_buffer= opcache.fast_shutdown= Ach ja, und ob er überhaupt aktiviert sein soll oder nicht. Also auch noch: opcache.enable= Besten Dank! Wenn dir noch eine sinnvolle und hilfreiche Einstellung einfällt ...
  10. Nur zur Info - ich verwende durchaus "ordentliche" Backup-Software. Habe u.a. Backupninja im Einsatz und erstelle darüber inkrementelle Backups mit rdiff-backup von den Kunden-Verzeichnissen. Zusätzlich sichere ich die MySQL DBs per mysqldump und setze zur Versionsverwaltung bazaar ein. Aber ..., es ist halt ein grundlegender Unterschied zwischen dem, was ich als Admin quasi auf dem gesamten Server mache und dem, was jeder Kunde für sich machen kann. Meiner Erfahrung nach muss es für Kunden immer möglichst simpel und failsafe sein. Dazu gehört für mich eben bspw. auch, dass der Kunde das so einstellen/ konfigurieren kann, dass er sich nicht alle x Tage darum kümmern muss. Und genauso dass ein 'Feature' out of the box läuft und das möglichst (ab)gesichert. Das Ganze ließe sich ja auch so integrieren, dass es die Entscheidung eines jeden Admins ist, ob und wie er es auf seinem Server für seine Kunden anbietet/ einrichtet. So entscheidest du quasi für alle ...! :-P
  11. Ja, da hast du vollkommen recht. War auch nur für mich gedacht, damit ich nicht zusätzlich immer noch die Konsole öffnen muss. Am heimischen Rechner kein Problem, aber unterwegs übers Smartphone etwas umständlich. Nur von daher meine Frage (als Linux Noob).
  12. Nein, Missverständnis. Der Eintrag mit dem Docroot wird übernommen. Aber der andere (opcache.interned_strings_buffer = 16M) nicht.
  13. Hi, danke für die Antwort. Und es geht auch nicht, wenn ich bspw. den User froxlorlocal in der /etc/sudoers eintrage und dann z.B. per shell_exec ein (Bash) Skript aufrufe (welches dann wiederum die froxlor_master_cronjob.php aufruft)?
  14. Hallo werte Froxlor- und Linuxexperten! Ich hätte gerne gewußt, ob und wenn ja wie ich ggf. einen Link/ Button ins Admin Dashboard einbauen kann, um die Froxlor froxlor_master_cronjob.php (--force) direkt aus dem Dashboard heraus aufzurufen? Eins meiner "Probleme" ist u.a., dass das Panel unter dem Benutzer 'froxlorlocal' und über https läuft, und ich die Datei demnach quasi als root aufrufen/ ausführen muss. Mit PHP, HTML, JS und CSS kenne ich mich aus. Allerdings mit Linux eher nur rudimentär. Also wenn mir jemand einen Tipp geben kann, wie man so etwas unter (Debian) Linux "elegant" (und sicher) macht, dann wäre ich sehr dankbar dafür. Gruß Gunther
  15. Hallo zusammen! Bevor ich ggf. eine Bugmeldung verfasse, wollte ich erst mal nachhören, ob es sich wirklich um einen allgemeinen Bug handelt, oder ob nur bei mir etwas falsch läuft? Und zwar werden bei mir Einstellungen zum OPcache, die ich in den PHP-Konfigurationen vornehme, (teilweise) nicht übernommen. Ich habe installiert: Froxlor 0.9.36 (war auch vorher mit 0.9.35-1 schon so) FPM-FCGI PHP: 5.5.33-1~dotdeb+7.1 Auszug aus der PHP-Konfiguration: variables_order = "GPCS" opcache.interned_strings_buffer = 16M opcache.restrict_api = "{DOCUMENT_ROOT}" Auszug aus der betreffenden php.ini: php_admin_value[variables_order] = "GPCS" php_admin_value[opcache.restrict_api] = "/var/www/froxlor/" Gilt für alle PHP-Konfigurationen bei mir. Aktuell habe ich den Wert in der Master php.ini entsprechend gesetzt. Kann das jemand so nachvollziehen, oder habe ich bei mir einen "Fehler im System"? Gruß Gunther
  16. Hallo! @d00p: Erstmal vielen Dank, dass du dir die Mühe gemacht hast, und wieder eine Backup Lösung, die vom Kunden direkt genutzt werden kann, eingebaut hast. Ich habe heute auf die Version 0.9.36 upgedated und die Backup Funktion mal exemplarisch mit einem Kunden getestet. Jetzt habe ich ein paar Fragen und Vorschläge dazu ... Frage: Wie sieht es eigentlich mit der zeitlichen Steuerung und dem Ablauf der Backups aus? Wenn ich den Cronjob dafür auf '1 DAY' stelle, dann trägt er in die '/etc/cron.d/froxlor' immer 15:00 Uhr ein. Und wie sieht es aus, wenn ich bspw. 20 Kunden habe, für die ein Backup erstellt werden soll. Werden die dann alle quasi gleichzeitig abgearbeitet (also Start und dann ein Kunde nach dem anderen)? Vorschläge: Ich würde es für praktischer halten, wenn man als Admin 'global' ein Unterverzeichnis in den Kunden Docroots angeben könnte (bspw. /backups), wo die Backups abgelegt werden. Und dann könnte man die Verzeichnisse auch gleich pauschal schützen, bspw. mit demselben Passwort wie die /awstats Verzeichnisse (sofern genutzt). Und was die Anzahl an maximalen Backups anbelangt, so wäre es sicherlich auch von Vorteil, wenn man es eben nicht dem User überlassen würde dafür zu sorgen, dass sein Webspace nicht "überquillt". ;-) Auch hier wäre eine globale Admin-Einstellung, oder eine per User Einstellung für 'max Tage/ Anzahl Backups' sicherlich eine enorme Hilfe. Ich verstehe zwar nicht sehr viel davon, aber nachdem die Backup Dateien/ Archive ja das Datum im Dateinamen beinhalten, wäre es sicherlich kein großes Problem, wenn der Cronjob das Backupverzeichnis nach Dateien durchsucht, die entsprechend alt sind, und diese dann ggf. löscht. Somit hätte der Kunde immer ein Update der letzten X Tage, müsste sich aber nicht permanent darum kümmern, dass sein Space nicht überläuft. Denn lieber so eine Vorgabe, als als Admin hingehen (zu müssen) und in Kundenverzeichnissen irgendwelche Dateien zu löschen. Das ist ja ein No-Go. Also müsste man sich mit dem betreffenden Kunden in Verbindung setzen und ihn auffordern Platz zu schaffen, was wiederum viel zu umständlich ist. Ob sich das ganze ohne Weiteres so erweitern oder umbauen ließe, dass man bspw. per rdiff-backup auch inkrementelle Backups erstellen könnte, kann ich leider mangels Fachkenntnis nicht beurteilen. Wäre allerdings aus meiner Sicht noch eine weitere Verbesserung. Gruß Gunther
  17. So, ich habe es jetzt ans Laufen gebracht und möchte eventuellen zukünftigen Hilfesuchenden nicht vorenthalten wie. Und zwar habe ich über die Konsole repquota / eingegeben. Die Ausgabe fängt dann an mit *** Report for user quotas on device /dev/disk/by-uuid/06a6ce66-e8c9-4167-ade5-93bee20abf1a Block grace time: 7days; Inode grace time: 7days Und genau den Pfad (/dev/disk/by-uuid/06a6ce66-e8c9-4167-ade5-93bee20abf1a) habe ich jetzt in Froxlor unter Einstellungen -> Quota -> Einstellungen -> Partition, auf welcher die Kundendaten liegen eingegeben. Und siehe da, schon funktioniert es ohne Probleme. Warum es mit dem mount point '/' nicht funktioniert kann ich nur vermuten. Das liegt wahrscheinlich an dem Bug in der quotatool Version von Debian. Den richtigen Pfad findet man übrigens auch in der Datei '/etc/mtab'. Hoffe es hilft ggf. anderen zukünftig weiter. Gruß Gunther
  18. Hallo zusammen! Ich muss jetzt diesen schon etwas älteren Thread mal wieder hochholen, da ich aktuell dasselbe, bzw. ein ähnliches Problem habe. Und ja, ich weiß dass es kein Froxlor Problem ist, aber ich habe die Hoffnung, dass hier eventuell jemand einen Tipp oder soagr einen Lösungsvorschlag für mich hat. Denn aktuell dürften ja doch noch einige Debian Wheezy mit Froxlor zusammen produktiv im Einsatz haben. Quota und quotatool sind installiert, quota DB files für group und user sind vorhanden und quota ist aktiviert. Aber wenn ich per Froxlor Quotas setzen will, dann erhalte ich (per Mail) folgende Fehlermeldung: Dabei ist in Froxlor unter 'Partition, auf welcher die Kundendaten liegen' die Default-Einstellung '/var/customers' eingestellt. Ändere ich den Eintrag auf '/', erhalte ich die folgende Fehlermeldung: Frage: Hat jemand von euch Quota erfolgreich unter Debian 7 am Laufen? Und wenn ja, wie hast du das hinbekommen? Alle anderen hilfreichen Tipps werden natürlich auch gerne angenommen. Besten Dank im Voraus! Gruß Gunther
  19. Ah ... OK, das leuchtet mir jetzt auch ein. Habe einen Alias 'amavis:root' hinzugefügt (und auch newaliases ausgeführt ). Mal schauen, was das denn dann im Zweifel für Mails sind. Nun sei doch nicht gleich beleidigt. Das war weder ein persönlicher Angriff, noch sollte das die gute Arbeit in irgendeiner Weise schmälern. Aber ist doch normal, dass sich Ver-/ Anwender häufig Dinge wünschen, wo Entwickler sich eher die Haare raufen ... . Und wenn ich nicht glücklich und zufrieden mit Froxlor wäre, dann hätte ich mir sicherlich schon eine Alternative gesucht. Aufgrund mangelnder Fachkenntnisse kann ich außer Feedback eben leider wenig zur Verbesserung beitragen (lediglich beim Frontend). Danke, das wünsche ich dir auch. Und besten Dank nochmal für die Erklärung. Falls ich zu neuen Erkenntnissen gelange, die ggf. für andere auch von Interesse sein könnten, dann poste ich die hier noch. Gruß Gunther
  20. Sorry, verstehe ich so nicht. Meine "Basis Konfiguration" ist ja gemäß Froxlor Konfig (Mailserver (IMAP/POP3) » Dovecot with postfix). Wenn ich jetzt zusätzlich einen Viren- und Spamschutz/ -prüfung mit in die Kette einbaue, ändert sich doch nichts an der Art der generellen Zustellung!? Und insbesondere "irritiert" mich die erste (Zeile) Fehlermeldung. Denn es gibt nach wie vor keine Datei '/var/mail/amavis', und amavis gehört auch nicht der Gruppe 'mail' an und trotzdem läuft es ja (fehlerfrei). Soweit ich das "verstehe", entsteht in dem ganzen Ablauf dann ein "Problem", wenn der ermittelte Ordner für die Zustellung der betreffenden Mail nicht existiert/ beschrieben werden kann. Und das scheint dann wiederum zu den "wenig hilfreichen" Fehlermeldungen zu führen, abgesehen von "Mailbox doesn't exist!". Ich sehe aber nicht, wie ein Alias das Problem lösen sollte, bzw. was der überhaupt damit zu tun haben sollte? Es gehen ja keine Mails an den amavis user. Das ist jetzt aber eher eine "faule Ausrede" als ein trifftiger Grund . Klar gibt es zig verschiedene Varianten. Aber wem die vorgeschlagene dann nicht gefällt, der muss sie ja nicht nutzen und kann sich seine eigene Konfig basteln. Aber so ist quasi jeder gezwungen, sich seine eigene Variante zu basteln, was u.a. auch Hilfe & Support (hier im Forum) sehr erschweren. Selbiges gilt imho auch für die Backup Geschichte. Zumal bei der eine entsprechende Integration in das Kunden Panel ja äußerst wünschenswert wäre. Und wer das nicht nutzen will, der aktiviert die Option eben nicht - fertig. Aber quasi jeden dazu zu verdonnern, sich jeweils seine eigene Lösung zu stricken, ist jedenfalls aus meiner Sicht nicht das Gelbe vom Ei. Schließlich soll ein Server Verwaltungstool dem Admin die Arbeit ja erleichtern und ihn unterstützen. Ich kann aber durchaus auch die damit verbundenen Probleme verstehen. Für wünschenswert halte ich es trotzdem.
  21. Ich zietiere mich mal eben selber : Inzwischen läuft alles wieder zu 100%. Die Fehlermeldungen scheinen eher "irreführend" zu sein, und entstehen wohl dann, wenn ein entsprechendes (Mail) Verzeichnis nicht existiert. Ich habe genau wie früher KEINEN ALIAS hinzugefügt. Einzig habe ich jeweils die Benutzer clamav und amavis der Benutzergruppe des jeweils anderen hinzugefügt. @d00p: Wäre sicherlich für viele Hilfreich, wenn man die Geschichte mit Spam- und Virendetektion bei Mails mal mit in die Froxlor Konfiguration mit aufnehmen würde . Vielen Dank nochmal und Frohe Pfingsten! Gunther
  22. Hi! Ja, besten Dank! War inzwischen dann auch mal auf die Idee gekommen, einfach eine neue zusätzliche E-Mail-Adresse für einen Kunden anzulegen. Aber ich habe noch ein weiteres gravierendes Problem: Obwohl ich exakt die alten Konfigdateien wieder übernommen habe, läuft mein Mailsystem (Postfix, Dovecot, Clamav, Spamassassin, Amavis) nicht. Ich erhalte folgende Fehlermeldungen May 13 22:35:50 vs1 dovecot: lda(amavis): Error: open(/var/mail/amavis) failed: Permission denied (euid=112(amavis) egid=113(amavis) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775) May 13 22:35:50 vs1 dovecot: lda(amavis): Error: Opening INBOX failed: Mailbox doesn't exist: INBOX May 13 22:35:50 vs1 dovecot: lda(amavis): Error: BUG: Saving failed to unknown storage Was mich etwas "irritiert" ist, dass das Verzeichnis '/var/mail/' ja gar nicht genutzt wird. Es existiert und enthält die beiden Dateien 'mail' und 'root'. Irgendeinen Tipp? Habe mich schon durch Google und das Forum durchgesucht, aber aus einem wenig hilfreichen Thread nichts gefunden. An einem fehlenden Alias kann es eigentlich nicht liegen (hatte ich vorher auch nicht). Dank & Gruß Gunther
  23. Hallo zusammen! Nicht fragen - aber kann mir mal bitte jemand sagen, welche Eigentümer:Gruppe die jeweiligen Kundenverzeichnisse unter /var/customers/mail haben müssen? Aufgrund von Problemen muss ich die Verzeichnisse zurück kopieren auf den Server und habe aber nur eine lokale Sicherung (ohne die entsprechenden Eigenschaften und Rechte). Vielen Dank vorab. Und allen Frohe Pfingsten. Gruß Gunther
  24. Nein, nicht unbedingt. Zumal es eigentlich nur Vorteile bietet, wenn du FPM verwendest. Google kann dir da aber auch weiterhelfen. Hab' auf die Schnelle mal diesen Beitrag bei SO rausgepickt (auch die Kommentare lesen): http://stackoverflow.com/questions/4526242/what-is-the-difference-between-fastcgi-and-fpm
×
×
  • Create New...