Beiträge von aho546745

    In LC 2.0.1-r3988 auf Debian 7 64 Bit sehe ich diesen Fehler:


    "Database Error: Unknown column 'AC1.AC_ACCOUNTID' in 'on clause'"


    in der Zertifikatsverwaltung unter dem Untermenupunkt Zertifikatsverwaltung.


    Tritt nur auf, wenn im Suchfeld darunter etwas eingetragen ist.


    Log:



    Code
    [2015/12/21 14:16:26.082094] [15626|15632] Database Exception: Database Error: Unknown column 'AC1.AC_ACCOUNTID' in 'on clause' (SQL: SELECT DISTINCT AA_ID, AA_REGID, AA_STATUS, AA_CREATE_TS, AC2.AC_TYPE, AC2.AC_CONTACT, COUNT(AC_SSLID) AS SSLCOUNT FROM ACMECONTACTS AC1, ACMEACCOUNTS LEFT JOIN ACMECONTACTS AC2 ON (AA_ID=AC2.AC_ACCOUNTID) LEFT JOIN ACMECERTS ON (AA_ID=AC1.AC_ACCOUNTID) WHERE AA_CUSTOMERID=:1 AND AA_ID=AC1.AC_ACCOUNTID AND (AA_REGID LIKE :2 OR AC1.AC_CONTACT LIKE :2) GROUP BY AA_ID, AC1.AC_CONTACT ORDER BY AA_REGID LIMIT :3 OFFSET :4)

    Fehler ist gefunden: das Mailpasswort wird zwar korrekt im LiveConfig aktualisiert, diese Änderung wird in manchen Fällen aber nicht gleich an den Mailserver weitergegeben (dann erfolgt das erst nach beim nächsten Update-Intervall oder LiveConfig-Neustart).


    Wir haben das nun geändert, mit dem nächsten LC-Update (ab r3994) wird die Änderung dann immer gleich an den Mailserver durchgereicht.


    In meinem Fall wurde das Mail-PW durch LC Tage später durch einen manuellen LC-Restart neu gesetzt.

    In diesem Fall kam um 11:18:46 die Autorisierung für "andrehotzler.photography", für die http://www.-Subdomain aber erst über eine Minute später. LiveConfig wird wohl daher zuerst das Zertifikat nur für die Hauptdomain angefordert und erhalten haben.


    Löschen Sie das SSL-Zertifikat und fordern es erneut per ACME an (die Autorisierungen bleiben ja erhalten, daher erfolgt "nur" eine neue Ausstellung, und die wird dann beide Varianten beinhalten).


    Wir werden diesen Sonderfall (Authorisierung einer Subdomain vor einer anderen) im nächsten Update mit berücksichtigen.


    Hallo Herr Keppler,


    wann gibts hier ein Update?


    Ich muss das aktuell bei jedem Zertifikat machen (also das Löschen und nochmal anlegen), da das http://www.-Zertifikat oft ein paar Sekunden später kommt.

    Ich habe eben per App-Installer Roundcube neu installiert.


    Das Passwort-Plugin ist auch aktiv.


    Ich erhalte immer: "Neues Passwort nicht gespeichert Failed to save password in LiveConfig"


    Setze ich in der globalen Config von Roundcube:


    password_accept_liveconfig_selfsigned auf true (ich verwende ein gekauftes Comodo-Zertifikat), dann erhalte ich:


    "Neues Passwort nicht gespeichert Invalid e-mail address and/or password"


    Was nun?

    Verstehe ich das richtig?


    Manch einer will mehrere Apps in einem Webspace installieren und Pfade angeben?


    Ich persönlich installiere ja lieber jede App in ein extra Web: Eigene User, eigenes Backup und so weiter. Meine Erfahrung mit Kunden, die ich nach Hacks übernommen habe:


    Wird Dir in eine App in einem Webspace eingebrochen, dauerts nicht lange und der Angrifg greift auf den Rest über und wenn nur in Unterordnern irgendwelche PHP- oder Spam-Shells abgelegt werden.

    Das hat geklappt. Was mir allerdings nicht klar ist: Wie findet man heraus, ab wann das Zert benutzbar ist?


    Nach dem Speichern, auch wenn dort valid da steht, ist in der Übersicht der Zertifikate z.B. das Feld "Aussteller" leer. Solange das nichts drin steht, kann man es bei den Domains auch nicht zuweisen.


    Irgendwann erscheint dann der Eintrag und es geht, wie wird das getriggert?

    Ich habe per ACME ein Zert bei Letsencrypt angefordert, auch für www.


    In Liveconfig steht:


    Authorization Accepted Expires Typ Status
    andrehotzler.photography 07.12.2015 11:18:46 02.10.2016 12:18:11 http-01 valid
    http://www.andrehotzler.photography 07.12.2015 11:19:58 02.10.2016 12:22:11 http-01 valid


    Jetzt habe ich dieses Zertifikat beiden Domains zugewiesen, erhalte aber immer diese Meldung:


    Dieser Server konnte nicht beweisen, dass er http://www.andrehotzler.photography ist. Sein Sicherheitszertifikat stammt von andrehotzler.photography. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.


    Ohne www. klappts.


    Was mache ich falsch?

    Laut Firebug werden die Schriften bei mir geladen und auch gerendert und dennoch habe ich das Verschiebe-Problem in der LC-Demo.


    Schaue ich mir im Debugger das ganze Konstukt an, dann wird bei mir wenig sauber gerendert.


    Wir haben gerendert:


    • td Höhe 34px
    • -> a Höhe 14px (nach oben außerhalb des Elternobjekts verschoben, kommt vom negativen Margin-Top des Kindelemen)
    • -> div 12px hoch, 2px Border aber: -5px Margin-top (wozu?)
    • -> span 24 px hoch.


    Das das span ja das div überlagern soll, sollte es genauso hoch sein, wobei neben der Höhe auch die Line-Height korrekt sein MUSS, außer man zwingt dem Element einen anderen Typ mit der Anweisung "diplay" auf.


    Da beim Span die Line-height von 24,... Pixel fürs Rendering des Spans berechnet wird, liegt hier das Problem.


    Das Span ist über 24px hoch wegen der Line-Height. Innerhalb seiner Höhe wird die Schrift nach oben und unten gleich ausgerichtet.


    [Blockierte Grafik: https://blog.ah64.net/images/other/18.11.2015%2012.57.42%20LENOVO-E540W8%200000.png]


    Schaut man sich das umgebende Objekt an:


    [Blockierte Grafik: https://blog.ah64.net/images/other/18.11.2015%2013.01.20%20LENOVO-E540W8%200000.png]


    Dann wird klar, dass die ganze Diskussion über Schriftarten überflüssig ist, weil die Probleme an anderer Stelle liegen.


    Man kann das ganze auf verschiedene Arten lösen.


    Am besten wäre natürlich, das einfach mal sauber zu programmieren. Der hier verwendete Mischmasch von Positionierung, negativen Außenabständen (margins), Nichtberücksichtigen von Linien-Höhen macht es schwer, zu beurteilen, ob meine Vorschläge auf anderen Devices gut aussehen


    Hier denoch ein schneller Vorschlag:


    "line-height: 100%;" zum Span hinzufügen und das "top: -1px" auf 0px. Schon sitzt der Text mittig.


    Aber auch dann ist die Zeile ansich immer noch seltsam hoch.


    Das liegt daran, dass das span über dem Div mit dem Balken positioniert wird, es wird nach oben geschoben. bei der Gesamthöhe der tabellenzeile werden aber die Einzelhöhen beider Elemente addiert. Das ist ein Fehler, den unerfahrene Web-Programmierer oft machen, wenn sie Positionierung so verwenden, dass Elemente, die untereinander stehen, übereinander geschoben werden.


    Übergangslösung:


    Einem der Objekte ein "float" verpassen, beispielweise dem div.dFillBarContent


    Vorher:


    [Blockierte Grafik: https://blog.ah64.net/images/other/18.11.2015%2013.05.17%20LENOVO-E540W8%200000.png]


    Nachher:
    [Blockierte Grafik: https://blog.ah64.net/images/other/18.11.2015%2013.05.28%20LENOVO-E540W8%200000.png]

    LC 1.9.1-r3767 auf Debian 7.9


    Auf meiner Installation bleiben nach Entfernen des hakens "Mailbox anlegen" in der Emailverwaltung die zuvor mit der Mailbox verwendeten Login-Daten aktiv.


    Im konkreten Fall kam das Passwort des Kunden in Umlauf, der nahm dann den Haken "Mailbox" weg und leitete die Emailadressen nur noch weiter.


    Der Login per IMAP/SMTP blieb aber erhalten, so dass der Spamversand noch möglich war.
    Das kann man auch gut in den entsprechenden Files für Dovecot usw. nachvollziehen.


    Sollten in dem Fall nicht eigentlich die Login-Daten herausgenommen werden?

    Ist halt die Frage, inwieweit man es auf den Hoster schieben kann, wenn man selber so absolut gar keine Ahnung hat. Wenn ich sehe, wie hilflos die Anfragen hier geschrieben sind, dann ist die Frage, ob der Hoster mit der Anfrage was anfangen konnte.


    Ich finds auch falsch von der Community hier, so zu helfen. Das ehrt Euch zwar, trägt aber Schokolade zum Fettsüchtigen. Ich bin der Meinung, dass mit dem hier gezeigten, praktisch nicht vorhandenen, Fachwissen, kein Server direkt im Internet betrieben werden sollte. Ist doch nur eine Frage der zeit, bis aus der Kiste eine Spamschleuder geworden ist.