Beiträge von kk

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 5.6.26, 7.0.11 und 7.1.0rc2 aktualisiert.

Viele Grüße

-Klaus Keppler

Zitat von Mercator1972

was spricht gegen 2048?

Manche externe Secondary-DNS (z.B. von Domainanbietern) haben eine Größenbeschränkung für TXT-Records. So lange alle DNS von LiveConfig verwaltet werden bzw. Größenbeschränkungen ausgeschlossen werden können, sollten 2048 Bit kein Problem sein.

SPF ist und bleibt "broken by design", SRS macht das ganze nur schlimmer.

Wenn Mails an Google trotz korrektem RDNS nicht durchkommen, prüfen Sie bitte, ob Sie diese eventuell per IPv6 zustellen. Das wird bei Google (nach meinem letzten Kenntnisstand) leider auch negativ bewertet.
Wir nutzen für ausgehende E-Mails ausschließlich IPv4 (kann man im LiveConfig einfach konfigurieren).

Viele Grüße

-Klaus Keppler

Danke für den Hinweis - der Fehler ist mit v2.2.3-r4323 behoben (wird heute Nachmittag als Preview bereitgestellt).

Zitat von BlueManOne

ich habe phpMyAdmin & roundcube auf einem in LiveConfig eingerichteten Webspace als App installiert und die SSL-URLs als eigene Menüpunkte in LiveConfig eingerichtet.

Kurze Antwort: klappt nicht.
Kurze Begründung: siehe Handbuch (bitte vollständig lesen).
Ausführliche Begründung: wie im Handbuch beschrieben werden die Inhalte in ein <IFRAME>-Element eingebettet. Desses Größe muss dynamisch durch JavaScript auf die "umgebende" Seite angepasst werden. Das klappt wiederum nur, wenn die nachgeladenen Inhalte eine bestimmte JavaScript-Funktion ausführen.

Die IFRAME-API (a.k.a. "eigene Links") ist ausdrücklich nicht für phpMyAdmin, RoundCube oder sonstige "Apps" gedacht und auch nicht für solche geeignet.
Einen Link auf phpMyAdmin können Sie unter "Serververwaltung" -> "Datenbanken" hinterlegen (wird dann den Endkunden in der Datenbank-Liste automatisch mit angezeigt). Links zu RoundCube werden voraussichtlich ab LiveConfig 2.3.0 auch möglich sein.
Last but not least macht es aus Sicht der Usability keinen Sinn, einen Verweis auf ein externes Ziel ins LiveConfig-Menü zu integrieren, genauso wie es keinen Sinn macht sich erst am LiveConfig anmelden zu müssen nur um von dort aus an phpMyAdmin oder Roundcube zu gelangen.

Viele Grüße

-Klaus Keppler

Der Kunde bleibt weiterhin Kunde vom Reseller.
Der Vertrag (=Webspace...) des Kunden (z.B. "web123") gehört dann aber z.B. dem admin, und nicht mehr dem Endkunden. Der Admin kann diesen Vertrag dann bei Bedarf irgendeinem anderen Kunden zuordnen.

Viele Grüße

-Klaus Keppler

Ab sofort steht LiveConfig in der Version 2.2.2 (r4304) zum Download bereit.

Die wichtigsten Änderungen sind:

• Verträgen aus beliebiger Tiefe können nun einem Administrator oder Reseller neu zugeordnet werden
• Status-Anzeige auf Kunden-Detail-Seite wenn Kunde gesperrt/deaktiviert ist
• Passwort von zusätzlichen (virtuellen) FTP-Accounts wurde zurückgesetzt wenn nur das Startverzeichnis geändert wurde
• Lua: Fehler in LC.timeout()-Funktion behoben, wodurch z.B. Dienste manchmal zu früh aktualisiert (reloaded) wurden
• SOAP API: Berechtigungen wurden nicht aktualisiert wenn das Angebot eines Vertrags via HostingSubscriptionEdit() geändert wurde

Ein Update der Preview-Version folgt in den nächsten Tagen (hier gab es größere Änderungen, insbes. um ausgehenden Spam zu vermeiden).

Viele Grüße

-Klaus Keppler

Ich sage jetzt mal lieber nicht wann mir so alles "der Hut fliegen geht".
Fakt ist: es nutzen z.B. deutlich mehr Anwender zusätzliche FTP-Accounts als es Reseller-Accounts in LiveConfig gibt. Bei aller Bescheidenheit möchte ich behaupten, dass wir durchaus einschätzen können welche Probleme wie kritisch sind.

Dieses Reseller-Thema fällt primär unter den Begriff "Overprovisioning". Ursprünglich war das durchaus so geplant (daher stammt diese Funktionalität). Es gibt bislang lediglich keine Option, um Overprovisioning hart oder weich zu deaktivieren.

"Wir sind dran" ist so zu verstehen: manche Dinger sind etwas komplexer, als es auf den ersten Blick erscheint. Es ist nicht so, dass da nur an einer Stelle im Code ein SQL angepasst werden müsste. Die Komplexität einer Kunden- und Rechteverwaltung mit beliebiger Hierarchie ist nicht ganz zu unterschätzen.
Wir haben diesen Punkt also auf der ToDo-Liste (ein Teilbereich davon wird bereits von einem Entwickler bearbeitet).

Mit freundlichen Grüßen

-Klaus Keppler

Zitat von drpmicha

Habe ich irgendwo eine Einstellung vergessen? Was kann ich tun, um den HTTPS-Webspace verwalten zu können?

Häufigste Fehlerquelle: in der IP-Gruppe (Serververwaltung -> Web) ist SSL nicht aktiviert.
Der Designer wird das in der GUI demnächst berücksichtigen, so dass da ein entsprechender Hinweis erscheint.

Viele Grüße

-Klaus Keppler

Zitat von ensky

Ich habe die Funktion bzw. den Aufruf nun mittels LC.execute in die users.lua geschrieben.

Das ist nicht so praktisch, da die users.lua mit jedem LiveConfig-Update überschrieben wird.
Die "custom.lua" wird nicht angefasst, daher ist das der bevorzugte Weg.

Demnächst wird es separate "Hooks" für eigene Aktionen geben, was das Umbiegen von Funktionen dann ersetzt.

Ah, die Funktion muss außerdem "LC.users.addUser" heißen, nicht "LC.addUser". Hatte die Klasse vergessen.

Handelt es sich um ein Einzel- oder Multi-Server-Setup?
Die "custom.lua" müssen Sie auf dem Server anlegen, auf dem auch die Webspaces liegen. Falls da ein LiveConfig-Client läuft, müssen Sie diesen neu starten damit das Script geladen wird.
lclua finden Sie unter /usr/lib/liveconfig/lclua

So etwas lässt sich über die Lua-API realisieren. Legen Sie eine Datei namens /usr/lib/liveconfig/lua/custom.lua mit etwa folgendem Inhalt an:

local orig_addUser = LC.users.addUser
function LC.users.addUser(user, group, home, shell)
  -- erst die Original-Funktion aufrufen (legt Benutzer an etc.:)
  local rc, status = orig_addUser(user, group, home, shell)


  if rc then
    -- wenn Account erfolgreich angelegt wurde, eigene Funktion ausführen:
    -- z.B.: os.execute("/pfad/zum/script " .. user .. " " .. home)
  end


  return rc, status
end

Danach LiveConfig neu starten (damit das Lua-Script geladen wird) und die /var/log/liveconfig/liveconfig.log auf eventuelle Fehlermeldungen prüfen.

Das o.g. Script ist "from scratch", keine Garantie auf syntaktische Korrektheit.

Hello,

the PHP packages for Debian have been updated to version 5.6.25, 7.0.10 and 7.1.0beta3.

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 5.6.25, 7.0.10 und 7.1.0beta3 aktualisiert.

Viele Grüße

-Klaus Keppler

Das sind Feature-Requests, und die sind auch aufgenommen.

Ich würde nur gerne zwischen "Support" (im Sinne von "Hilfe wenn was nicht klappt") und "Feature-Requests" (im Sinne von "ich hätte gerne die Funktion XYZ umgesetzt") unterscheiden.

Zitat von weltmeister

LiveConfig finde ich gut, schade ist jedoch, dass der Support in der Tat etwas schleppend ist.

Ich finde kein einziges offenes Ticket von Ihnen.

Zitat von leonex

wie können wir Systemweit Standardmäßig folgende Werte beim anlegen von Domains und E-Mail Postfächern für unsere Kunden aktivieren:

Das geht durch Anlegen bzw. Ändern der entsprechenden Werte in der LiveConfig-Tabelle LCDEFAULTS:
http://www.liveconfig.com/de/h…advanced.lcdefaults.xhtml

In diesem Fall: mail.autoconfig.default, mail.greylisting.enabled, mail.spam.enabled

Wir planen bereits, diese Einstellungen längerfristig auch über die Weboberfläche konfigurierbar zu machen.

Zitat von lebenszeit

Jedoch keine /etc/pam.d/vsftpd-lc vorhanden. Sollte die da sein?

Ja.
LiveConfig legt die automatisch an, wenn die Verwaltung des vsftpd über Serververwaltung -> FTP aktiviert wird.

#%PAM-1.0
#  _    _          ___           __ _     (R)
# | |  (_)_ _____ / __|___ _ _  / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
#                                    |___/
# Copyright (c) 2009-2016 Keppler IT GmbH.
# ----------------------------------------------------------------------------
# PAM configuration for vsftpd with virtual users
# Maintained by LiveConfig


# Virtual account is sufficient, try local account as fallback:
auth    required   pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth    sufficient pam_userdb.so db=/etc/vsftpd/passwd crypt=crypt
auth    required   pam_unix.so


# Local account is sufficient, permit any (virtual) account as fallback:
account sufficient pam_unix.so
account required pam_permit.so


# <EOF>-----------------------------------------------------------------------

Ich habe eben auf einem "frischen" Debian 8 eine Installation mit vsftpd getestet.
Es reicht, die Pakete "vsftpd" und "db-util" zu installieren (/usr/bin/db_load wird dabei automatisch als Symlink auf /usr/bin/db5.3_load eingerichtet). Bei einem Dist-Upgrade von Wheezy auf Jessie sollte eigentlich das db-Paket auch von 4.x auf 5.3 aktualisiert werden.

Allerdings ist mir eben aufgefallen, dass nach Änderungen am Startverzeichnis eines zusätzlichen (virtuellen) FTP-Accounts scheinbar das Passwort nicht mehr funktioniert. Wenn das Passwort neu gesetzt wird, klappt die Anmeldung damit einwandfrei. Ich werde das gleich mal im Detail prüfen...