• Announcements

    • d00p

      Major server crash   03/27/17

      Due to a major server crash, most of our services are currently not available. Sorry for any inconvenience. Sadly, the forums database could not be restored, so we are back to a database from mid-2016  Sorry

iam

Members
  • Content count

    13
  • Joined

  • Last visited

  • Days Won

    1

iam last won the day on September 9 2016

iam had the most liked content!

Community Reputation

1 Neutral

About iam

  • Rank
    Froxie
  1. Hey d00p, genau das habe ich mir auch gedacht. Im Upstart vom Debian sind die Links auch richtig gesetzt. rc 2,3,4,5 beinhalten im S03 den MySQL Dienst und im S04 den NSCD Dienst. Meine Theorie liegt darin, dass hier Systemd seine Finger im Spiel hat. In dem Journal geht dies aber nicht raus hervor. Das witzige ist ja, dass mir nach einen reboot das Journal diesen Fehler entgegenwirft, NSCD dennoch korrekt die Benutzer einstellungen aus dem MySQL ziehen kann. Nun bin ich aber kein Fan, von roten Zeilen im Journal und dachte, dass ich auf diesen Weg eventuell einen Tipp bekomme. Liebe Grüße IAM
  2. Sarius, möchtest du dir den Server nicht lieber von einem professionellem Administrator einrichten lassen? Klar kostet ein paar Euro's, aber die sind gut investiert. Also ich würde meine Website & Mails nicht bei dir speichern. Das System wird sicherlich offen wie ein Scheunentor sein, da es bei dir schon an sämtlichen Basics harpert. Nimm das nicht persönlich, aber auf weitere Spambomben / Spamschleudern im WWW, da hat keiner Interesse dran. Gruß IAM
  3. Guten Tag, ich habe Heute mal mein Journal von meinem Debian Jessie System gesichtet, dabei ist mir ein Fehler bei dem Paket libnss-mysql aufgefallen. dbus-daemon[623]: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) dbus[623]: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) mysqld[839]: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111 "Connection refused") Diese Fehler häufen sich immer wieder. Nach einem Neustart des NSCD Paketes ist der Fehler weg. Ich habe bereits in den insserv dem NSCD Paket angeordnet, dass er bitte mysql zu erst starten soll. Ebenso habe ich im libnss-mysql verushct verschiedene Host Adressen von dem MySQL Server anzugeben. Alles dies führt zu keiner Lösung. Andere Beiträge aus diesem Forum führten auch nicht zum Erfolg. Hat noch Jemand eine Lösung? Liebe Grüße IAM
  4. Halo d00p, wenn das Projekt dich nicht hätte! DANKE! [information] Updating Let's Encrypt certificates [debug] Updating dummy.com [debug] Adding SAN entry: dummy.com [information] letsencrypt Using 'https://acme-v01.api.letsencrypt.org' to generate certificate [information] letsencrypt Starting new account registration [information] letsencrypt Sending registration to letsencrypt server [information] letsencrypt Sending signed request to /acme/new-reg [information] letsencrypt Sending registration to letsencrypt server [information] letsencrypt Sending signed request to /acme/new-reg [information] letsencrypt New account certificate registered [information] letsencrypt Starting certificate generation process for domains [information] letsencrypt Requesting challenge for dummy.com [information] letsencrypt Sending signed request to /acme/new-authz [information] letsencrypt Got challenge token for dummy.com [information] letsencrypt Token for dummy.com saved at /var/www//.well-known/acme-challenge/*Token* and should be available at http://dummy.com/.well-known/acme-challenge/*Token* [information] letsencrypt Sending request to challenge [information] letsencrypt Sending signed request to https://acme-v01.api.letsencrypt.org/acme/challenge/*Token*/*Token* [information] letsencrypt Verification pending, sleeping 1s [information] letsencrypt Verification ended with status: valid [information] letsencrypt Sending signed request to /acme/new-cert [information] letsencrypt Got certificate! YAY! [information] letsencrypt Requesting chained cert at /acme/issuer-cert [information] letsencrypt Done, returning new certificates and key [information] Updated Let's Encrypt certificate dummy.com [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid LG
  5. Hallo, von welchem Quota sprechen wir hier? Das Debian Paket quota, greift nicht in dein Mailkontigent ein. Das Dovecot Paket hat eine eigene Quota, für deine Mail-Accounts, welche aus deiner DB ausgelesen werden. Das musst du dementsprechen konfigurieren. LG
  6. Hallo, nun melde ich mich auch mal mit einem "Let's Encrypt-Anliegen" zu Wort. Let's Encrypt hatte bisweil immer wunderbar funktioniert. Zum System: Debian 8.5 Apache 2.4.10 AWstats 7.2 Postfix 2.11 Dovecot 2.2 Proftpd 1.3.5 MariaDB 10.0.25 Quota Bind 9.9.5 (Nicht im Einsatz, Service deaktiviert) Als ich Heute aber das Froxlor-Update auf 0.9.37 eingespielt habe, funktioniert Let's Encrypt nicht mehr. Der Fehler [beim ersten cronjob (lepublickey & leprivatekey auf "NULL")]: [information] Updating Let's Encrypt certificates [debug] Updating dummy.com [debug] Adding SAN entry: dummy.com [information] letsencrypt Using 'https://acme-v01.api.letsencrypt.org' to generate certificate [information] letsencrypt Starting new account registration [information] letsencrypt Sending registration to letsencrypt server [information] letsencrypt Sending signed request to /acme/new-reg [error] Could not get Let's Encrypt certificate for dummy.com: Account not initialized, probably due to rate limiting. Whole response: Array [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid Der Fehler (beim erneuten cronjob): [information] Updating Let's Encrypt certificates [debug] Updating dummy.com [debug] Adding SAN entry: dummy.com [debug] Adding SAN entry: www.dummy.com [information] letsencrypt Using 'https://acme-v01.api.letsencrypt.org' to generate certificate [information] letsencrypt Account already registered. Continuing. [information] letsencrypt Starting certificate generation process for domains [information] letsencrypt Requesting challenge for mandalka.net [information] letsencrypt Sending signed request to /acme/new-authz [error] Could not get Let's Encrypt certificate for dummy.com: No challenges received for mandalka.net. Whole response: {"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403} [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid Ich habe bereits die lepublickey & leprivatekey aus der customerstabelle auf "NULL" gesetzt. Let's Encrypt einmal komplett deaktiviert und wieder aktiviert. Die Let's Encrypt-Umgebung auf "Testing" umgestellt. Den Let's Encrypt-Schlüssel lasse ich nicht wiederverwenden. Es soll immer ein neuer generiert werden. Alles ohne Erfolg... Meine ACME Konfigurationsdatei sieht wie folgt aus: ## Let's Encrypt # # Alias "/.well-known/acme-challenge" "/var/www/.well-known/acme-challenge/" <Directory "/var/www/.well-known/acme-challenge/"> Require all granted </Directory> Auch hier habe ich nichts geändert, da es zuvor ja einwandfrei funktionierte.
  7. Hallo d00p, danke für die Antwort. Ich werde mal nachschauen, wie sich das System verhält wenn ich diesen Parameter deaktiviere.
  8. Hallo, nun möchte ich zu meinem letzten Problem kommen. Vorweg zum System: Debian 8.5 Apache 2.4.10 AWstats 7.2 Postfix 2.11 Dovecot 2.2 Proftpd 1.3.5 MariaDB 10.0.25 Quota Bind 9.9.5 (Nicht im Einsatz, Service deaktiviert) Ich setze für mein System auf Apache + FCGID + MPM_Prefork. Das System läuft auch soweit stabil und erfüllt alle meine Vorraussetzungen. Starte ich den Apache2-Server 4x - 5x mit dem "restart" Befehl neu, so spuckt mir der Server auf Allen PHP-Sites nur noch einen "Internal Server Error 500" aus. Aus dem Serverlog (Loglevel Debug)und Google werde ich nicht schlau. Fatal Error Unable to create lock file: Bad file descriptor Hat jemand hier dasselbe Problem & weiß rat, wieso das System keine neuen Lock Files anlegen kann? Sollte dieser Fehler auftreten, so hilft nur noch ein Reboot des kompletten Linux Debian Systems. Meine bisherigen Unternehmungen: Das "Open File Limit" stark angehoben. Viele Grüße
  9. Hallo, ich habe das Problem behoben. Froxlor liest die Logfiles von dem Syslog-Daemon. Da ich meinen Syslog-Daemon angewiesen habe, nur Error's zu loggen, hat die Trafficerfassung nicht mehr geklappt. Nun habe ich den Loglevel auf Info gestellt und es läuft. Danke!
  10. Hallo d00p, vielen Danke für die Antwort. Ich würde sagen, dass wir uns zu Erst einmal an den FTP-Traffic halten. Ich habe gerade in die Tabelle ftp_users geschaut und kann bestätigen, dass die vier Spalten up & down gefüllt sind. Die Cronjobs laufen auch ohne fehler durch. Habe diese soeben händisch auf der Konsole ausgeführt. Dennoch ist der Traffic weiterhin bei 0. Hättest du noch Ideen, wür einen Workaround? Ok, ich habe die Jobs in falscher Reihenfolge ausgeführt. Die Tabellen schnellen soeben in die Höhe... Soweit so gut. Über bleibt der Mail-Traffic. Hier muss ich sagen, dass auch in eurer Konfiguration keine Parameter für Logfiles gesetzt sind und diese somit automatisch an den Syslog weitergeleitet werden.
  11. Hallo d00p, entschuldige bitte. Wenn wir aber von den Standard-Konfigurationsparametern des Postfix & Dovecot Daemons ausgehen, so loggen die beiden Dienste in den Syslog hinein. Den Syslog lasse ich nach mail.* filtern und schreibe diese Ausgaben in den og. Pfad/Datei. Diese Umgebung/Konfiguration scheint bei mir aber nicht zu funktionieren. Zum FTP: Könntest du mir sagen, in welche Tabelle die Querys geschrieben werden? In die ftp_quotalimits oder in die ftp_quotatallies? Die tabelle ftp_quotalimits ist bei mir nämlih leer und die ftp_quotatallies sieht folgendermaßen aus. Anhang:
  12. Hallo d00p, vielen Dank für deine Antwort & die Hilfsbereitschaft. Ich lasse Postfix und Dovecot über Rsyslog laufen. Genauer gesagt, nach der Einstellung. mail.err -/var/log/mail/mail.log Dein Ansatz leuchtet ein, dass dadurch die Analyse nicht korrekt läuft. Ich habe in euren Konfigurationsfiles keine korrekten Log-Einstellungen gefunden. Hättest du evtl. die korrekten Konfigurationsparameter zur Hand? Und welches Log-Level empfiehlst du für den MTA? Als FTP-Daemon benutze ich den Proftpd. Anhang:
  13. Hallo, vorweg, möchte ich mich für dieses Projekt und den dazu fleißigen Support bedanken. Ich selber musste in den 1-2 Monaten, wo ich mit diesem Produkt zusammen arbeite, zwar noch keinen Support in Anspruch nehmen, aber irgendwann ist immer das Erste mal. Leider hat mir Google und das durchstöbern hier im Forum nicht weitergeholfen. Wie das Topic hier im Thema bereits vermuten lässt, besteht das Problem bei der Traffic (Statistik) berechnung. Bei allen Kunden wird die HTTP-Traffic korrekt berechnet und auch dargelegt, doch leider ist die FTP-Traffic und die Mail-Traffic gleichbleibend bei 0. Meine Frage nun, woran könnte dies liegen & was für Log-Auszüge werden für ein ordentliches Debugging benötigt? Zum System: Debian 8.5 Apache 2.4.10 AWstats 7.2 Postfix 2.11 Dovecot 2.2 Proftpd 1.3.5 MariaDB 10.0.25 Quota Bind 9.9.5 (Nicht im Einsatz, Service deaktiviert) Wie gesagt, vielen Dank schon einmal für die Antwort! Viele Grüße IAM Anhang: