Beiträge von kk

Zitat von kwm

Code

2012/09/21 23:32:17.321238] [1083|1086] Created database 'phpmyadmin' (user 'phpmyadmin')
[2012/09/21 23:39:28.489678] [1078|1078] Client child process 1083 terminated; uncaught signal: 6 (Aborted)

Dieser Fehler deutet darauf hin, dass der in LiveConfig enthaltene MySQL-Client abgeschmiert ist. Um die Ursache einzugrenzen, könnten Sie mir bitte kurz noch folgende Fragen beantworten:
- welche MySQL-Version (exakt) setzen Sie ein?
- handelt es sich dabei um das Paket der Distribution (ggf. welche Distribution?), oder um ein selbst installiertes MySQL-Paket?
- haben Sie zwischen den beiden o.g. Log-Einträgen zufällig MySQL neu gestartet?
- bitte prüfen Sie, ob bei Ihnen eine MySQL-Errorlog-Datei existiert (bei Debian werden MySQL-Fehler i.d.R. in /var/log/syslog oder /var/log/messages eingetragen); steht dort evtl. noch eine Info?

Besten Dank & viele Grüße

-Klaus Keppler

Hallo,

nein - die Datenbank sollte eigentlich schon automatisch gelöscht werden. Dieses Verhalten deutet darauf hin, dass beim Löschen ein Problem aufgetreten ist. Bitte schauen Sie mal ins LiveConfig-Logfile (/var/log/liveconfig/liveconfig.log) - dort müsste eine Fehlermeldung auftauchen.
Bei einem Neustart von LiveConfig wird übrigens automatisch versucht, bislang erfolglos gelöschte Datenbanken erneut zu löschen.

Viele Grüße

-Klaus Keppler

Äh... darüber hinaus kann ownCloud ja auch mit SQLite (also ohne MySQL) laufen; hier findet derzeit eine Änderung im AppInstaller statt, die das berücksichtigt.
(mit einem LC-Update ist also in den nächsten Tagen zu rechnen)

Ja, ist das selbe Problem.
MySQL erlaubt nur Benutzernamen bis max. 16 Buchstaben. Für den automatischen Namen wird das DB-Präfix sowie die selbst gewählte App-ID aneinandergefügt - und das ist in diesen Beispielen >16 Zeichen lang.
Wir werden das so ändern, dass der AppID-Name entsprechend kurz sein muss, so dass max. 16 Zeichen für die Datenbank übrig bleiben.

Yes, this is a bug (or missing feature); we'll add this within the next days.

Best regards

-Klaus Keppler

I'm sorry, but it isn't that simple.
As soon as you use suPHP or suExec (which should be mandatory on shared hosting environments), the security layer checks that the requested resource (eg. a PHP script) is within the user's home directory.
So, when requesting for instance "/var/www/web1/htdocs/index.php", the user's home directory must be anything below /var/www/web1/htdocs.
Additionally, many configuration files are created where the user may not get any write permissions. So the home directory must remain read-only (to protect the other folders).

Alternatively, you may prepare the configuration folders for the desired applications manually, eg:

mkdir /var/www/web1/.ssh
chown web1:web1 /var/www/web1/.ssh

Would this be ok for you?

Which linux distribution do you use?
Most distributions already have a package called "scponly".
This has nothing to do with a chroot jail (this is another topic).

Maybe the subscription has'n been deleted successfully by LiveConfig. Once a subscription and all its users etc. are deleted, you can actually reuse its former ID.
Please have a look at /var/log/liveconfig/liveconfig.log if you see any error messages, and at /etc/passwd if the subscription ID is still listed there.

Hmm, the english message states that you'd have to delete all assigned contracts first.

We'll replace 'contracts' with 'subscriptions' to make it clearer.

However, currently you need to delete all subscriptions before you can delete the customer. We're planning to make this easier in future versions (so that you just get warned which subscriptions/domains/mailboxes/etc. will automatically be deleted if you continue deleting the customer...)

Best regards

-Klaus Keppler

Zitat

Dennoch stellt sich mir die Frage ob ich eine APP nicht auch über HTTPS veröffentlichen kann.

Hmm, offenbar fehlt die Möglichkeit, bei HTTPS/SSL auch eine WebApp als Ziel angeben zu können (bei HTTP klappt das ja). Handelt sich wohl um einen Fehler in der GUI, weil technisch nichts dagegen spricht. Ich schaue mal, dass wir das kurzfristig lösen.

Viele Grüße

-Klaus Keppler

Zitat

weiß Herr Keppler eventuell eine Antwort?

Für allgemeine Programmierfragen können wir leider keinen Support geben - hierfür gibt es unzählige PHP-Foren, wo sicher besser geholfen werden kann. Für die SOAP-API existiert eine ausführliche Dokumentation aller Funktionen, eine WSDL-Beschreibung aller Methoden sowie Beispielcode.

Oder geben Sie einfach bei Google mal den Suchbegriff "LiveConfig Couldn't bind to service" ein - schon der erste Treffer führt zur Lösung Ihres Problems.

Viele Grüße

-Klaus Keppler

Ja, natürlich.
Und für den Fall, dass z.B. suPHP deinstalliert ist, man aber versehentlich suPHP bei einem Vertrag auswählt, funktioniert die Apache-Konfiguration trotzdem noch (alle Konfigurationsanweisungen sind in entsprechende <IfModule>-Abschnitte gepackt)

Nein, sobald der Datenbankserver einmal zugewiesen wurde kann er (aktuell) nicht mehr geändert werden.
Wäre natürlich prinzipiell eine Idee, Änderungen zu ermöglichen (für neu anzulegende Datenbanken) - ich nehme das mal in die Wunschliste auf.

Wenn Sie in diesem Fall die Datenbank noch mal neu setzen möchten, müssen Sie per SQLite/MySQL in die LiveConfig-Datenbank eingreifen (wie immer: auf eigene Gefahr!):

UPDATE HOSTINGCONTRACTS SET HC_DBSERVERID=NULL WHERE HC_NAME="web123";

Viele Grüße

-Klaus Keppler

Zitat

Weiter wäre es toll wenn unter "Kunden" -> "Verträge" eine deutliche Kennzeichnung vorhanden wäre das hier abweichende Leistungen vorhanden sind.

Ist ab v1.5.2-r1843 enthalten.

Eine Liste der Verträge mit abweichenden Leistungen macht auch Sinn, folgt also noch irgendwann.

Ist inzwischen auch schon mit drin (ich glaube auch ab r1830).
Falls bestehende Kunden noch kein Log sehen können, müsste der betroffene Hostingvertrag einfach noch mal neu gespeichert werden, dann wird die Berechtigung gesetzt.
Mit Version 1.5.2-r1842 wird diese Berechtigung auch automatisch allen bestehenden Hostingverträgen hinzugefügt. In Kürze sind Vertragseigenschaften detaillierter bearbeitbar, da soll das als eigene Option verwaltbar sein.

Viele Grüße

-Klaus Keppler

Erledigt ab v1.5.2-r1841.

Die Meldung "Ungültiger Benutzername" erscheint, weil ein zu langer Name dann nicht mehr dem regulären Ausdruck entspricht, der beim betroffenen Eingabefeld hinterlegt ist; die Maximallänge wird nicht gesondert geprüft.
Nun wird aber die "maxlength"-Option im zugehörigen <input>-Feld korrekt gesetzt, so dass eine zu lange Eingabe nicht möglich ist.

Ist ab 1.5.2-r1830 enthalten (aktuell schon als Preview verfügbar). Kann pro Hosting-Angebot und pro -Vertrag eingestellt werden.
Wichtig ist, dass das Apache-Modul mod_fcgid installiert und aktiviert ist (erfolgt bei Installation mittels liveconfig-meta automatisch)

Viele Grüße

-Klaus Keppler

Welche Distribution nutzen Sie denn?
Auf den ersten Blick sollte das awstats_buildstaticpages.pl von Debian 7 diese Einstellung berücksichtigen.

Ah, ok - diese Statistik gibt's erst seit AWStats 7.0.
Nehmen Sie in die o.g. Liste bitte noch

ShowDownloadsStats=HB

mit auf.

Ja, diese Seiten wurden nicht generiert. Die AWStats-Konfiguration wurde nun entsprechend erweitert (ab LiveConfig r1835).
Um das zu korrigieren, löschen Sie dann einfach die Datei /etc/awstats/liveconfig/awstats.conf.liveconfig und speichern irgendeine Einstellung eines Webhosting-Kunden erneut ab, der AWStats nutzt (somit wird diese Konfigurationsdatei neu angelegt).

Alternativ fügen Sie folgende Befehle mit in die o.g. Datei ein:

ShowMenu=1
ShowSummary=UVPHB
ShowMonthStats=UVPHB
ShowDaysOfMonthStats=VPHB
ShowDaysOfWeekStats=PHB
ShowHoursStats=PHB
ShowDomainsStats=PHB
ShowHostsStats=PHBL
ShowAuthenticatedUsers=0
ShowRobotsStats=HBL
ShowWormsStats=0
ShowEMailSenders=0
ShowEMailReceivers=0
ShowSessionsStats=1
ShowPagesStats=PBEX
ShowFileTypesStats=HB
ShowFileSizesStats=0
ShowOSStats=1
ShowBrowsersStats=1
ShowScreenSizeStats=0
ShowOriginStats=PH
ShowKeyphrasesStats=1
ShowKeywordsStats=1
ShowMiscStats=a
ShowHTTPErrorsStats=1
ShowSMTPErrorsStats=0
ShowClusterStats=0
ShowFlagLinks=""
ShowLinksOnUrl=1