Beiträge von MAD M!NDWORX

Ich habe gerade einen neuen Server aufgesetzt und bin nach der pd-Admin Installation mit Standardumgebung so weiter vorgegangen:

• SSL Zertifikate ($hostname-key, $hostname-cert, $hostname-cacert) in /opt/pdadmin/sslcerts/ angelegt
• /opt/pdadmin/bin/httpd_vhosts.pl gestartet und schon lief die Administration über https
• nun hab ich mir ci-ssl-install.sh angeschaut und darauf aufbauend folgendes Script erstellt und gestartet:

#!/bin/bash
H=`/opt/pdadmin/bin/hostname.pl`


touch /usr/local/pd-admin2/share/imapd.pem
chown qmaild:nofiles /usr/local/pd-admin2/share/imapd.pem
chmod 440 /usr/local/pd-admin2/share/imapd.pem
cat /opt/pdadmin/sslcerts/$H-key /opt/pdadmin/sslcerts/$H-cert > /usr/local/pd-admin2/share/imapd.pem
cat /opt/pdadmin/sslcerts/$H-cacert > /usr/local/pd-admin2/share/imapd.cacert


grep "^ssl = yes" /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf > /dev/null || {
cat <<__ >> /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf
ssl = yes
ssl_key = </usr/local/pd-admin2/share/imapd.pem
ssl_cert = </usr/local/pd-admin2/share/imapd.pem
ssl_ca = </usr/local/pd-admin2/share/imapd.cacert
__
svc -du /service/dovecot22
}


grep TLSRSACertificateFile /usr/local/pd-admin2/etc/proftpd.conf > /dev/null || {
cat <<__ >> /usr/local/pd-admin2/etc/proftpd.conf
<IfModule mod_tls.c>
TLSEngine                  on
TLSProtocol SSLv3 TLSv1
TLSRSACertificateFile      /opt/pdadmin/sslcerts/$H-cert
TLSRSACertificateKeyFile   /opt/pdadmin/sslcerts/$H-key
TLSCACertificateFile       /opt/pdadmin/sslcerts/$H-cacert
TLSVerifyClient            off
TLSRequired                off
TLSRenegotiate none
</IfModule>
__
killall proftpd
}


cd /usr/src
wget http://download.pd-admin.de/runfiles-ssl.tar.gz
tar xzf runfiles-ssl.tar.gz  --wildcards --no-anchored 'qmail-*'
mv qmail-smtpSd  /service
rm -f runfiles-ssl.tar.gz
svc -u /service/qmail-smtpSd

Danach liefen auch Dovecot, ProFTPD und qmail SMTP mit SSL.

Benötigt der Seitenaufruf eventuell über 30 Sekunden? Dann wäre es ratsam, das fastcgi-Zeitlimit anzuheben.

Siehe: FastCgiConfig Werte (z.B. idle-timeout) verändern

- Welche Version von pd-admin wird eingesetzt? v4.24
- Welche Version der Serverumgebung wird eingesetzt? 3-0.257

Mir ist aufgefallen, dass Abfragen an die Tabelle vadmin.traffic_new bei relativ vielen Einträgen länger als notwendig brauchen. Das liegt daran, dass kein Index auf der Tabelle liegt.

Abfragen in ftp_log.pl und http_log.pl, wie z.B.

my $query  = "select id from traffic_new where id_user='$user' and date=now();";

müssen über alle Datensätze der Tabelle laufen.

Ebenso die Abfrage in msa_warning.pl:

my $query = "select sum(www), sum(ftp), sum(mail) from traffic_new ".
               "where date like '$this_month%' and id_user='$dbuid'";

und das für alle auf dem Server vorhandenen User in einer Schleife.

Damit die Datenbank nicht mehr alle Datensätze durchsuchen muss, habe ich der Tabelle einen Index hinzugefügt:

ALTER TABLE `vadmin`.`traffic_new` ADD INDEX `idx_id_user_date` (`id_user`, `date`);

Nun laufen die Abfragen schneller, da nicht mehr die komplette Tabelle auf Inhalte durchsucht werden muss.

Eventuell wäre es hilfreich, die Änderung in eine kommende pd-admin Version zu übernehmen?

Nebeneffekte sollte es eigentlich keine geben. Was meint ihr?

Grüße!

- Welche Version von pd-admin wird eingesetzt? v4.24
- Welche Version der Serverumgebung wird eingesetzt? 3-0.257

Ich habe in meiner my.cnf einen wait_timeout von 60s gesetzt, damit es nicht mehr so viele unnötig schlafende mySQL Abfragen gibt.

Das hatte allerdings zur Folge, dass die Shellscripte von pd-admin (z.B. backup.pl, httpd_log.pl) während ihrer Ausführung in einen mySQL Timeout liefen, da die Datenbankverbindung gleich beim Starten des Scriptes hergestellt - aber (z.B. beim Backup) erst nach anderen, manchmal zeitaufwendigen, Aufgaben verwendet wird. Dann wurde allerdings die Verbindung zur Datenbank schon wegen des wait_timeout beendet.

Aktuell habe ich mir damit Abhilfe geschaffen, dass ich in den Scripten nach dem

my $dbh = DBI->connect($dsn, $user, $password) or die "can't connect!";

immer noch ein

$dbh->do("SET SESSION wait_timeout=28800") or die "cannot set wait_timeout";

hinzufügte. Das ist natürlich nicht nicht Update-sicher.

Daher würde ich mir wünschen, dass die Anpassung des wait_timeout seitens Bradler & Krantz in die Shell Scripte aufgenommen wird.

Oder gibt es Alternativlösungen?

Beste Grüße!

Micromac: Schau mal, ob eventuell /etc/my.cnf existiert. Falls ja, dann umbenennen oder löschen und dann mySQL aus der Standardumgebung nochmal starten.

Dann bekommst Du nicht die Ausgabe der CRON Scripte.

Bearbeite mal die Crontab

crontab -e

und schreibe an den Anfang:

MAILTO="deine@mail.adresse"

(natürlich mit der richtigen Adresse in den Anführungsstrichen)

Dann speichern und fertig.

Die Beschreibung ist etwas schwer verständlich.

Einfacher wäre es sicherlich, wenn Du Beispiele für deine Daten nennst. Vorher -> Nachher.

Zitat

Original von tbc233
dass hier anscheinend noch irgendein Timeout zieht

Siehe: FastCgiConfig Werte (z.B. idle-timeout) verändern

Vielleicht hast Du mal

crontab -r

statt

crontab -e

aufgerufen?

Hallo.

Die selben Logeinträge habe ich auch. Es scheint daran zu liegen, dass der ZIELserver ein selbst-signiertes Zertifikat einsetzt und daher der Handshake nicht stattfindet, zumindest mit der von pd-admin eingesetzten openssl Version.

Änderungen an den tlsclientciphers haben bei mir keine Besserung gebracht.

Hier mal ein Verbindungsversuch über pd-admin openssl:

~# /usr/local/pd-admin2/bin/openssl s_client -starttls smtp -crlf -connect ZIELSERVER.IP:25
4156028556:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 258 bytes and written 342 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Mit dem systemeigenen openssl funktioniert der Handshake:

~# /usr/bin/openssl s_client -starttls smtp -crlf -connect ZIELSERVER.IP:25
CONNECTED(00000003)
depth=0 /CN=ZIELSERVER.CN
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=ZIELSERVER.CN
verify return:1
---
Certificate chain
 0 s:/CN=ZIELSERVER.CN
   i:/CN=ZIELSERVER.CN
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=ZIELSERVER.CN
issuer=/CN=ZIELSERVER.CN
---
No client certificate CA names sent
---
SSL handshake has read 909 bytes and written 346 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
...
Verify return code: 18 (self signed certificate)
---
250 HELP
quit
221 ZIELSERVER Service closing channel.
closed

Eine Stichprobe eines anderen Zielservers zeigte, dass openssl zwar dort hin eine Verbindung aufbauen konnte, aber das Zertifikat auch wieder selbst signiert war und "Verify return code: 21 (unable to verify the first certificate)" als Überprüfung zurückgab.

Vermutung: qmail sendet nicht an "potentiell unsichere Empfänger". Richtig?

Die Frage ist jetzt: Wie kann man die Mails trotzdem zustellen lassen?

Beste Grüße!

Indem der Inhaber des Mailaccounts das Passwort ändert oder direkt in der Datenbank unter vadmin.pop3 Feld "suspended"

Du gibst für den Reseller eine zweite (oder dritte, vierte... je nachdem) optionale IP an, z.B. 127.0.0.1

Das machst Du in der Administration unter Reseller -> Übersicht -> Aktionen -> IPs

Sodann kannst Du bei den Zertifikaten problemlos mehrere Zertifikate via SNI einrichten. Anschließend kannst Du die optionale IP auch wieder entfernen.

Viel Erfolg!

Vielen Dank, Herr Bradler.

Das funktioniert bestens! (hätte ich eigentlich auch selbst drauf kommen können)

Daumen Hoch für das Implementieren von SNI, dankeschön!

- Welche Version von pd-admin wird eingesetzt? 4.22

Auf meinem Testserver mit nur einer IP war schon ein Zertifikat in pd-admin 4.21 eingerichtet.

Nach dem Update auf 4.22 habe ich mittels "ändern" das Zertifikat von "Dedizierte IP-Adresse" auf "Server Name Identification (SNI)" umgestellt und gespeichert.

Wenn ich nun allerdings ein weiteres Zertifikat anlegen möchte, kommt die Meldung "Keine freien IP-Adressen verfügbar.".

Dabei sollte das doch gerade bei SNI doch möglich sein?

Muss das alte Zertifikat entfernt und neu angelegt werden?

Ich meinte eher den Aufwand für eine größere ANZAHL an Zeichen.

Rechnerisch: Ein Passwort der Buchstaben a,b,c mit EINER Stelle kann man mit max. 3 Versuchen rausbekommen. Wird jetzt noch ein Sonderzeichen erwartet, also ein Passwort mit den Buchstaben a,b,c oder $, dann braucht man max. 4 Versuche.

Erhöht man jedoch die Anzahl der Stellen, braucht man bei den Buchstaben a,b,c bei ZWEI Stellen schon maximal 3^2 = 9 Versuche.

Passwort mit abc$ und ZWEI Stellen braucht maximal 4^2 = 16 Versuche, Passwort mit abc und DREI Stellen maximal 3^3 = 27 Versuche.

Wie gesagt: Meiner Meinung nach sollte nicht der Zeichensatz vorgeschrieben werden, sondern die Mindestlänge.

Ein Passwort mit 8 Zeichen länge und dem Zeichensatz a-zA-Z0-9!"§$%& hat nicht so viele mögliche Kombinationen wie ein Passwort mit 12 Zeichen Länge und dem Zeichensatz a-zA-Z0-9. Da helfen bei einem Passwort mit 8 Zeichen Länge auch keine weiteren Sonderzeichen. Bei Brute Force Attacken hält das nicht wirklich auf.

Dass man keine Passwörter "aus dem Duden" nehmen sollte ist natürlich jedem klar, da muss man nicht drüber diskutieren

Etwas Realsatire: http://xkcd.com/936/

Nicht die Komplexität des Passworts, sondern die Mindestlänge sollte vorgeschrieben werden. 12 Zeichen Minimum. Ob dort nun Sonderzeichen drin sind oder nicht, ist doch einer Maschine bei BruteForce Attacken quasi egal. Der Aufwand zum Lösen steigt mit jedem zusätzlichen Zeichen exponentiell.

Der Nutzer hingegen muss sich kryptische Passwörter merken, bzw. meist irgendwo notieren und in der Nähe des Rechners lagern. Das ist dann zwar vor Cyber-Attacken sicher, aber Kollegen und Praktikanten sehen das am Monitor klebende Post-It mit dem Passwort im Vorbeigehen...

Lösungen wie Keepass, Roboform oder 1password sind bei vielen Nutzern noch nicht "angekommen" und in Firmennetzen aufgrund fehlender Rechte auch nicht verwendbar.

Antwort gibts im Thread über den FCGI-Timeout: FastCgiConfig Werte (z.B. idle-timeout) verändern

Diese Tabellen existieren offensichtlich bei Deiner Installation nicht.

Denk bitte dran, nach Updates auch für die Roundcube Tabellen Updates einzuspielen. Siehe RoundCubeMail Updates halbherzig?

Die in der Fehlermeldung ausgegebenen Tabellen gibt es seit Roundcube v0.7.

Eventuell wirst Du folgendes ausführen müssen:

-- Updates from version 0.6


/*!40014 SET FOREIGN_KEY_CHECKS=0 */;


ALTER TABLE `users` CHANGE `alias` `alias` varchar(128) BINARY NOT NULL;
ALTER TABLE `users` CHANGE `username` `username` varchar(128) BINARY NOT NULL;


CREATE TABLE `dictionary` (
  `user_id` int(10) UNSIGNED DEFAULT NULL,
  `language` varchar(5) NOT NULL,
  `data` longtext NOT NULL,
  CONSTRAINT `user_id_fk_dictionary` FOREIGN KEY (`user_id`)
    REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  UNIQUE `uniqueness` (`user_id`, `language`)
) /*!40000 ENGINE=INNODB */ /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;


CREATE TABLE `searches` (
  `search_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `user_id` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `type` int(3) NOT NULL DEFAULT '0',
  `name` varchar(128) NOT NULL,
  `data` text,
  PRIMARY KEY(`search_id`),
  CONSTRAINT `user_id_fk_searches` FOREIGN KEY (`user_id`)
    REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  UNIQUE `uniqueness` (`user_id`, `type`, `name`)
) /*!40000 ENGINE=INNODB */ /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;


DROP TABLE `messages`;


CREATE TABLE `cache_index` (
 `user_id` int(10) UNSIGNED NOT NULL DEFAULT '0',
 `mailbox` varchar(255) BINARY NOT NULL,
 `changed` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
 `valid` tinyint(1) NOT NULL DEFAULT '0',
 `data` longtext NOT NULL,
 CONSTRAINT `user_id_fk_cache_index` FOREIGN KEY (`user_id`)
   REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
 INDEX `changed_index` (`changed`),
 PRIMARY KEY (`user_id`, `mailbox`)
) /*!40000 ENGINE=INNODB */ /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;


CREATE TABLE `cache_thread` (
 `user_id` int(10) UNSIGNED NOT NULL DEFAULT '0',
 `mailbox` varchar(255) BINARY NOT NULL,
 `changed` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
 `data` longtext NOT NULL,
 CONSTRAINT `user_id_fk_cache_thread` FOREIGN KEY (`user_id`)
   REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
 INDEX `changed_index` (`changed`),
 PRIMARY KEY (`user_id`, `mailbox`)
) /*!40000 ENGINE=INNODB */ /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;


CREATE TABLE `cache_messages` (
 `user_id` int(10) UNSIGNED NOT NULL DEFAULT '0',
 `mailbox` varchar(255) BINARY NOT NULL,
 `uid` int(11) UNSIGNED NOT NULL DEFAULT '0',
 `changed` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
 `data` longtext NOT NULL,
 `flags` int(11) NOT NULL DEFAULT '0',
 CONSTRAINT `user_id_fk_cache_messages` FOREIGN KEY (`user_id`)
   REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
 INDEX `changed_index` (`changed`),
 PRIMARY KEY (`user_id`, `mailbox`, `uid`)
) /*!40000 ENGINE=INNODB */ /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;


/*!40014 SET FOREIGN_KEY_CHECKS=1 */;


-- Updates from version 0.7-beta


ALTER TABLE `session` CHANGE `sess_id` `sess_id` varchar(128) NOT NULL;


-- Updates from version 0.7


/*!40014 SET FOREIGN_KEY_CHECKS=0 */;


ALTER TABLE `contacts` DROP FOREIGN KEY `user_id_fk_contacts`;
ALTER TABLE `contacts` DROP INDEX `user_contacts_index`;
ALTER TABLE `contacts` MODIFY `email` text NOT NULL;
ALTER TABLE `contacts` ADD INDEX `user_contacts_index` (`user_id`,`del`);
ALTER TABLE `contacts` ADD CONSTRAINT `user_id_fk_contacts` FOREIGN KEY (`user_id`)
   REFERENCES `users`(`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;


ALTER TABLE `cache` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `cache_index` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `cache_thread` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `cache_messages` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `contacts` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `contactgroups` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `contactgroupmembers` ALTER `contact_id` DROP DEFAULT;
ALTER TABLE `identities` ALTER `user_id` DROP DEFAULT;
ALTER TABLE `searches` ALTER `user_id` DROP DEFAULT;


/*!40014 SET FOREIGN_KEY_CHECKS=1 */;

Die komplette Updatedatei findest Du z.B. hier: http://trac.roundcube.net/brow…thub/SQL/mysql.update.sql

Viel Erfolg!

Dies ist eine vorgefertigte Schablone, die bei der Formulierung von Problemen unterstützen soll. Bitte die folgenden Angaben möglichst vollständig ausfüllen.

- Welche Version von pd-admin wird eingesetzt? 4.16
- Welche Version der Serverumgebung wird eingesetzt? 204

Ich habe lange hier im Forum gesucht, aber nichts dergleichen gefunden.

Es geht darum, dass ich für einen Endkunden, der mehrere Domains inklusive Mailkonten eingerichtet hat, aufteilen möchte, dass jede Domain einem eigenen Endkunden gehört, also ein Hostingpaket mit mehreren Domains soll auf eigenständige Hostingpakete aufgeteilt werden.

Der Webspace ist überhaupt kein Problem, das kann man ja umkopieren (und ggf. Pfade anpassen). Allerdings weiss ich nicht, wie die eingerichteten Mailkonten ohne löschen/neu erstellen auf den neuen Endkunden übertragen werden können.

Reicht es nicht eigentlich aus, jeweils die neuen Endkunden zu erstellen und dann in der vadmin Datenbank in der Tabelle "domains" den neuen "owner" (ID des neuen Endkunden aus der Tabelle "users") zuzuweisen und die Pfade bei domains.vhostroot sowie vhosts.target, vhosts.accesslog, vhosts.errorlog anzupassen? Die Mailkonten sind ja in der Tabelle "pop3" den vhosts zugeordnet, nicht den domains oder usern.

Oder gibts es da noch anderen Abhängigkeiten irgendwo?

Danke schonmal!

Du könntest die Backups auf ein LoopDevice legen, welchem kein Quota zugewiesen wird.

Anleitung siehe:
PHP Funktion "move_upload_file" und die Rechte
(anderes Thema, aber selbe Problematik)