Beiträge von michi

Was ging denn der Fehlermeldung voraus?
Also, passiert das immer?

Soo viel Speicher sollte das Script normal doch nicht benötigen. Evtl. mal beim Umgang mit großen Bitmaps. Oder bei einem fehlerhaften Script...

Wenn Du einen anderen cgi-bin Ordner verwendest, dann kannst Du den z.B. unter "eigene vhost einstellungen" in der jeweiligen Domain-Config von SysCp angeben.

z.B.
ScriptAlias /cgi-bin/ "/var/kunden/webs/meinkunde/anderedomain/cgi-bin/"

Ich nahm folgende Änderung in /etc/default/ssh vor:
Alt:

# OOM-killer adjustment for sshd (see
# linux/Documentation/filesystems/proc.txt; lower values reduce likelihood
# of being killed, while -17 means the OOM-killer will ignore sshd; set to
# the empty string to skip adjustment)
SSHD_OOM_ADJUST=
#SSHD_OOM_ADJUST=-17

Also SSHD_OOM_ADJUST auf <leer> gesetzt. Wenn ich richtig verstehe wird normalerweise mit der Wertanpassung vermieden, daß sshd bei geringem freien Speicher gelöscht wird. Eine Entfernung ist also m.E. nicht direkt ein Sicherheitsproblem.

Da war nichts zu bemerken Robert. Im Prinzip mag es einen gewissen Overhead geben. Aber bei den paar Daten...

Längere Tests habe ich natürlich nicht gefahren.

Die 127.0.0.1 war bei älteren vServern (zumindest früher mal) glaube ich nicht verfübar. Das wäre ein KO-Kriterium gewesen.

So inzwischen klappts auch wieder mit localhost und der von Dir beschriebenen (Rück-)änderung.

Man sollte eben keine Server updaten, bevor man kaffee gemacht hat...

Danke!
Das wird's sein.
Ich hatte gerade Erfolg mit dem Ändern von localhost nach 127.0.0.1 in den /etc/postfix/*.cf Dateien
eben aus den "chroot-gründen".

Ich hatte genau diese Datei (debian-start) überschreiben lassen (dachte, da war nix geändert).

Ich werde das nun wieder ändern.

Hallo allerseits. Ich habe gerade (endlich) auch von etch zu lenny aktualisiert. Hatte auch das klogd Problem. Derweil verwende ich aber wie beschrieben auch rsyslogd.

Das Problem:
Postfix will nicht mit mysql verbinden. Das ist in meiner config (syscp) aber essentiell wichtig.

Das sieht dann so aus:

Jan 29 10:20:52 v... postfix/trivial-rewrite[4001]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Jan 29 10:20:52 v... postfix/trivial-rewrite[4001]: fatal: mysql:/etc/postfix/mysql-virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem

Myql läuft. Auch auf diesem Socket. Ich habe mir die mysql-vritual_alias_maps.cf angeschaut. Ich kann vom shell manuell mit mysql mit genau jenen Angaben (user, password, db) connecten und auch den Inhalt der Tabelle anzeigen.

Nur postfix kannd das eben nicht. Grmbl..

Hat vielleicht jemand eine Idee?

Gegoogled habe ich natürlich schon. Hier auch gesucht. Nur noch nicht das richtige gefunden.

Eine Möglichkeit wäre, einen anderen FTP-Client zu verwenden.
Eine andere, tatsächlich die Dateien gepackt zu übertragen.

Du hast keine Angaben zu Deinem netcup-Paket gemacht. Daher gehe ich einfach mal davon aus, daß Du keinen SSH-Zugang hast. Sonst wäre das entpacken ja recht simpel.

Was Du (mit einem kleinen Beispiel beginnen) versuchen kannst, ist, das ZIP mit einen PHP-Script zu entpacken.

Siehe z.B. hier: (nicht getestet)
http://bjw.co.nz/developer/php…n-uploaded-file-using-php

Bei 13000 Dateien stößt man dabei evtl. an die zeitlichen Ausführungsgrenzen von PHP-Scripten. Wenn das so ist, dann wäre eine erstellung von separaten kleineren ZIPs notwendig.

Ich habe kein "managed" Paket bei netcup (sondern einen vServer). Daher weiß ich nicht, ob ZIP-Unterstützung im installierten PHP gegeben ist und wie lang ein Script maximal ausgeführt werden darf.

Im Zweifelsfall gilt: Versuch macht kluch.

Ich habe es beim letzten Dänemark-Urlaub auch erlebt.

Ich kenne nun die netcup-Pakete nicht im Detail. Sofern der Mailserver über eine zentrale netcup-Domain erreichbar ist, sollte auch Mail per SSL problemlos realisierbar sein und zum Standardangebot gehören.

Zitat von benny;12365

meine smtpd_client_restrictions sehen wie folgt aus:
(...)
Aber dienen die nicht eher dafür, wer über meinen Server mails versenden darf und nicht wessen mails angenommen werden?

Nö, die werden im "Kontext" des Verbindungsaufbaus eines beliebigen Clients angewendet. Auch von eigenen Usersn (sasl_authenticated).

Ich will mich bezüglich des idealen Anbringungsortes von client whitelists da aber auch nicht festnageln. Ich habe hier keine in Verwendung.

Zitat von benny;12365

Ah okay - das wußte ich noch nicht, da bei mir die Datei /etc/postgrey/whitelist_clients.local noch nicht exisitiert. Wo steht das? Weißt du das?

man postgrey
(ca. 2. Seite)

für postgrey kann man whitelists typischerweise in /etc/postgrey/whitelist_clients.local
ergänzen.

Leider kann es passieren, daß vereinzelte Server aufgrund schlechter/veralteter Mailsoftware nicht mit postgrey klarkommen.

Ist Deine client-whitelist nicht besser in den smtpd_client_restrictions aufgehoben? (Da habe ich zumindest meine client blacklist stehen)

Bist Du Dir denn sicher, daß der Absender der Mail kein Spam-Versender ist?

Ein Großteil dieser Meldungen wird von Spam-Versendern verursacht. Häufig ausgehend von infizierten PCs, die dann fast immer über dynamische Adressen versuchen mails zu versenden.

Es macht also absolut keinen Sinn möglichst viele Server in die whitelist zu setzen.

Daß der über das HELO identifizierte Absender über diesen Namen auch zur Absender-IP identifizierbar ist, ist meines Erachtens eine Grundbedingung, um mit seinem Server eine Mail versenden zu können. Deshalb sind auch alternative Mail-Server einer Domain immer noch mit einem eigenen Host-Namen (meist durchnumeriert) im DNS auflösbar.
(Steinigt mich einfach virtuell, wenn ich hier falsch liege)

Im Ausnahmefall kann es natürlich mal passieren, daß ein Server ein DNS-Problem hat und deshalb der Name beim Empfänger nicht aufgelöst werden kann und damit abgewiesen wird.

Ein Beispiel sind hier z.B. die standardmäßig von Netcup vorbesetzten Hostnamen v<Zahl>.yourvserver.net
Da gab es in der Vergangenheit öftermal DNS-Probleme. Wer diesen Hostnamen also in seiner Postfix-Konfiguration verwendet, hat dann ggf. auch mal Probleme seine Mails abzusetzen.

Wenn der v... Name nicht aufgelöst wird, dann kann das natürlich Konsequenzen haben.

Ich hatte diesen hostnamen in postfix (main.cf) noch als myhostname eingetragen.

Wenn sich der server zwecks versenden von Mails mit diesem Namen anderswo anmeldet und der im helo/ehlo angegebene Hostname nicht per DNS in die richtige IP aufgelöst werden kann, dann werden meist die Mails flugs abgewiesen.

Seit gerade eben steht daher bei mir mail.meinedomain.de sowohl in mydomain als auch in myhostname (mail. ist auch als adress-eintrag in der DNS-Config der domain definiert).

Und ich hoffe ich nichts übersehen habe...

Nachtrag:
Netcup bietet hier seine Dienste an. Das ist gar nicht so teuer (im Vergleich)

Evtl. läßt sich die Dienstleistung ja gleich mit einem Umzug auf einen passenden managed vServer kombinieren.

Putty ist ein SSH-Client für z.B. Windows.

Programm nehmen, starten. Zur Adresse von Deinem Server per SSH (nicht Telnet) verbinden.

Dein Kollege hat am SSH Zugang entweder nichts geändert, dann bekommst Du per Username "root" und Deinem root-Passwort zugang. Oder aber er hat dir hoffentlich den Usernamen+Passwort für SSH und den Port hinterlassen.

Tja und was machst Du dann?

Evtl. folgendes am Prompt eingeben:

top

Dann den Terminalinhalt mit Shift+Linker Maustaste markieren (sollte automatisch in der Zwischenablage landen). Und hier im Forum mal einfügen.

Danach das Programm mit "q" verlassen.
Und mal folgendes probieren:

htop

Sofern das installiert ist, gleiches Prozedere nochmal. Diesmal htop per "F10" beenden.

SSH/Putty kann dann ggf. beendet werden, du darfst am Prompt sonst auch "exit" tippen.

Edit:
Vielleicht findet sich hier im Forum ja tatsächlich einer, der das für Dich macht. Schnell günstiger und nervenschonender kommt da aber ein managed (v)Server in passender Größe bei netcup.

Tjo, allein über FTP wirst Du da nicht so viel erfahren.

Wie sieht der Traffic (z.B. bei Kontrolle in OpenVCP) denn konkret aus?
(in GB pro Tag/Monat)

Bei einem hohen Traffic wäre die Frage durch was der verursacht wurde. Wenn die Web-Statistik nicht grob mit der OpenVCP Statistik und ggf. der Statistik von SysCP bzw. anderen Management-Oberfläche deckt, dann wäre zu fragen, ob und wie der Traffic durch andere Dienste (FTP/SMTP) entsteht.

Der Support könnte Dir sagen, ob der Traffic evtl. so hoch war, daß Dein Server umgezogen wurde.

Ein weiterer erster Blick wäre über ssh auf top/htop, ob und wieso die CPU ausgelastet ist. Aber das würde Dich wohl bereits überfordern, so wie Du schreibst.

Ja die persistenten Verbindungen steigern natürlich die Performance etwas. Je nachdem wer sie nutzt. Evtl: z.B. prodftpd, postfix und natürlich die syscp-cronjobs.

Hallo Konni,

Also postfix meckert wieder, daß er keinen connect zu mysql bekommt? Oder von welchen Einträgen im Syslog sprichst Du?

Die Prozessliste in phpmyadmin war leer? Wenn nein, was stand drin? Die Spalte "SQL-Befehl" wäre z.B. interessant.

Ich habe momentan den Verdacht daß SysCP irgendwelche Tabellen sperrt und dann absemmelt und die locks stehen läßt. Wieso auch immer.

Eventuell könnte man mal zwecks Test die cron-jobs für SysCP disablen (in etc/cron.d/syscp ein # vor die Zeilen setzen). Die Cron-Jobs müßten eigentlich (abgesehen von Statistiken) nur dann benötigt werden, wenn etwas geändert wurde.

Die SysCP Cronjobs abzuschalten sollte natürlich kein Dauerzustand sein.

In PhpMyadmin die syscp Tabellen "Reparieren".

In /etc/php5/cli/conf.d evtl. mal die persistenten MySQL Verbindungen "disablen":
Also folgende Zeile ändern (On zu Off):
mysql.allow_persistent = Off

Bei mir stehen in der Prozessliste regelmäßig ein paar Connections für SysCP auf "Sleep" herum, ich denke das sind obige "persistent links", da bei mir die Einstellung auf "On" steht.

Bezüglich der "Remote Helping Hands" hatte der User Flo glaube ich mal was angeboten.

Klar geht das mit den Connections auch in phpmyadmin.
Auf der Startseite ist das der Link "Prozesse".

Bei Deiner Nutzung ist das in der Tat relativ unwahrscheinlich, daß die Max-Connections erreicht wurden.

Zu den Fehlermeldungen. Ich sehe, daß der mysqld Neustart ziemlich genau auf 9:50 lief. Da kann es sein, daß der SysCP Cronjob (läuft normal genau alle 5 minuten) dazwischengefunkt hat und tatsächlich zwischen mysqld start und dem check durch "debian-start" die entsprechenden Tabellen gerade abgefragt hat.

Das ist aber keine Antwort auf die andere Fehlermeldung. Dort wird ja ein Verbindungsfehler angezeigt. Selbst bei defekten Tabellen (mal abgesehen von den Tabellen in der mysql-db) wäre der Connect zunächst erfolgreich. Nur die Query würde dann mit entsprechender Fehlermeldung ggf. fehlschlagen.

Ein häufiger Fehler für sporadisch fehlgeschlagene Verbindungen ist, daß die maximale Anzahl der gleichzeitigen Connects überschritten wurde. Die ist ggf. in /etc/mysql/my.cnf mit "max_connections" definiert.

PhpMyAdmin gewährt dann ggf. noch den Zugriff, sofern man sich als ein User mit "SUPER privilege" anmeldet. Aber in der processlist sollten die Verbindungen evtl. noch zu sehen sein.

Eine Überwachung von Diensten (postfix, mysql & co) bietet z.B. das Tool monit. Interessant bezüglich der max_connections ist da z.B. dieses:
MySQL Event driven Process List