| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000101 | SKGB-intern | account | public | 2010-09-10 00:21 | 2014-07-20 20:51 | ||||
| Reporter | aj | ||||||||
| Assigned To | aj | ||||||||
| Priority | normal | Severity | feature | Reproducibility | N/A | ||||
| Status | resolved | Resolution | fixed | ||||||
| Projection | major rework | ETA | none | ||||||
| Product Version | 1.1.7 | Product Build | |||||||
| Target Version | 1.1.9 | Fixed in Version | 1.1.9 | ||||||
| Summary | 0000101: Vollautomatische Änderungen am Mailserver | ||||||||
| Description | Die Änderungen an E-Mail-Adressen sollte der Account-Manager vollständig alleine durchführen können, da SKGB-intern inzwischen auf demselben Host läuft wie der MTA. | ||||||||
| Steps To Reproduce | (1) Entweder virtual direkt bearbeiten oder indirekt über ein sed-Skript o.ä. (2) virtual.reload ausführen, um den Index neu aufzubauen und die MTA-Konfiguration neu zu laden. | ||||||||
| Additional Information | 0000076 sollte gefixt sein, bevor dieses Feature ins Live-System geht. Dieses Feature macht 0000044 überflüssig. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|||||||||||
|
|||||||||||
 Relationships |
| Notes |
|
|
aj (manager) 2010-09-10 00:27 |
Ein brauchbares sed-Skript wird ab sofort in SBsendChangeMail() generiert und als Anlage an die Änderungsnachricht an <postmaster> verschickt. Das ist schon mal ein guter Anfang. Dieses Skript dann auch automatisch auszuführen, ist mit PHP zwar etwas schwieriger als mit Perl, sollte aber kein großes Thema sein. 0000076 müsste vorher aber angegangen werden. |
|
aj (manager) 2010-09-25 21:16 |
Wobei: nach dem Host-Wechsel wird das Datenbank-Update ja dann plötzlich wieder nicht mehr auf demselben Host gemacht, auf dem der MTA läuft. Mögliche Lösungen: (1) Das sed-Skript per Mail verschicken und kryptographisch sichern. (2) Nur die eigentliche Datenbank auf den physikalisch sichern Host schieben; dann kann der Code virtual lokal ändern. |
|
aj (manager) 2010-12-07 21:19 |
Die kryptographische Sicherung erfolgt wohl am einfachsten durch Speicherung des Hashs des Skripts in der Datenbank auf Server G4 und anschließende Abfrage durch Tay bei Server G4, ob das Skript mit dem Hash XY ausgeführt werden darf. Es muss ja eh nicht bombensicher sein -- es geht ja nur um virtual, das von jedem mit physischem Zugriff auf Tay theoretisch ohnehin manipuliert werden könnte. Da können wir wenig bis nichts dran ändern. |
|
aj (manager) 2010-12-07 23:22 |
Besser als eine solche Frickellösung ist aber natürlich, einen besser geeigneten Tabellen-Typ als "hash" zu verwenden (siehe http://www.postfix.org/DATABASE_README.html#types ). LDAP wäre als Fernziel vllt. sinnvoll, vorerst ist aber MySQL praktischer. Dann können wir das zunächst zumindest bequem ohne Terminal pflegen und als Fernziel dann SKGB-intern daran anbinden (für die Selbständerung sollte allerdings eine Praralleldatenbank für die Authentifizierung der Adresse weitergeführt werden, schätze ich). |
|
aj (manager) 2011-09-28 22:39 |
fixed in revision 502 |
| Notes |