Beiträge von kk

Der cgi-bin-Ordner wird normalerweise komplett verschoben, außer eben es existiert bereits ein Verzeichnis mit dem Namen ~/htdocs/cgi-bin/.
Dann wird nichts gemacht, um nicht (unerwünscht) Dateien zu überschreiben.

Viele Grüße

-Klaus Keppler

Von einigen Nutzern kam eben der Wunsch, z.B. die Website unter http://www.example.org/ und gleichzeitig ein Blog unter http://www.example.org/blog/ zu betreiben. Der Grund dafür ist eigentlich zweitrangig - egal ob es nun um SEO oder SSL-Zertifikate geht.
Aktuell kann man das mit einer RewriteRule bereits erreichen (einfach in ~/htdocs/ eine .htaccess anlegen, die Zugriffe auf /blog/ umbiegt nach /var/www/web#/apps/<AppId>/).
Wir stellen uns das so vor, dass man bei der Installation einer App (und eventuell auch später bei bereits installierten Apps) neben der Auswahl der Subdomain auch den Pfad einstellen kann, über den die Anwendung erreichbar sein soll.

Hallo,

die Preview wurde eben noch mal aktualisiert (v1.5.2-r1890). Wir haben diese erfolgreich auf knapp einem Dutzend eigener Server produktiv in Betrieb; falls keine Probleme auftreten wird diese Version morgen (02.10.) produktiv freigegeben.

Die wichtigste Änderung ist das Verschieben von ~/cgi-bin/ nach ~/htdocs/cgi-bin/ (siehe Forum).

Viele Grüße

-Klaus Keppler

Zitat von prepaid

domain1.tld/webmail
domain1.tld/phpmyadmin

Steht bereits auf der Wunschliste
Ist (unverbindlich) für v1.6 eingeplant, etwa Anfang November.
Bis dahin müssten Apps jeweils in einer eigenen Subdomain konfiguriert werden.

Viele Grüße

-Klaus Keppler

Mit dem Update auf LiveConfig v1.5.2 (ab r1888) wird für alle Webspaces das Verzeichnis
~/cgi-bin/
automatisch verschoben nach
~/htdocs/cgi-bin/

Wir wissen, dass dies in bestehenden Setups vereinzelt Anpassungen erfordern kann und hätten das gerne vermieden - geht aber leider nicht anders.

Ablauf:
Beim Update auf 1.5.2-r1888 (und später) wird automatisch geprüft, ob diese Anpassung auf dem Webserver bereits durch LiveConfig vorgenommen wurde (ein Update ist also nach wie vor von jeder auf jede Version möglich). Ggf werden die notwendigen Rechteänderungen dann automatisch vorgenommen - darum kümmert sich das Script /usr/lib/liveconfig/lcservice.sh (Parameter "fix-permissions").
Alle vHost-Konfigurationen werden beim Start von LiveConfig ebenfalls automatisch aktualisiert (sowohl für Apache als auch für NGINX).
Betroffen ist übrigens ausschließlich Webspace, der Erlaubnis für CGI-Scripte besitzt; ohne CGI-Berechtigungen sorgt die neue Konfiguration dafür, dass Zugriffe auf die URL /cgi-bin/ nicht erlaubt sind (falls dort jemand sensible Dateien liegen hat werden diese also nicht versehentlich abrufbar gemacht). Für NGINX ist der Zugriff auf /cgi-bin/ komplett verboten.

Hilfs-Befehle:
Mit folgendem Befehl kann nach Verzeichnissen gesucht werden, die nicht automatisch verschoben wurden (das ist dann der Fall, wenn ~/htdocs/cgi-bin/ bereits existiert hat - so stellen wir sicher, dass nichts versehentlich überschrieben wird):

ls -ld /var/www/*/cgi-bin

Mit folgendem Befehl kann gesucht werden, ob in den erfolgreich verschobenen Verzeichnissen irgendwo die alten Verzeichnispfade hardcodiert enthalten waren:

find /var/www/*/htdocs/cgi-bin -type f -print0 | xargs -0 grep '/var/www/.*/cgi-bin'

Sollte sich da tatsächlich etwas finden, kann man das z.B. mit sed automatisch anpassen lassen (selbstverständlich stehen wir hierfür bei Fragen gerne zur Verfügung!)

Hintergrund:
Mit Version 1.5.2 werden die Web-Verzeichnisse noch besser geschützt - diese gehören dann root:root. Damit suexec aber Programme im cgi-bin-Verzeichnis ausführen kann, muss dieses dem Benutzer gehören (z.B. web1:web1). Damit der Apache-Webserver da aber auch lesend zugreifen kann (vor der Ausführung eines CGI-Scripts) müssten auch alle anderen Benutzer Leserechte dafür bekommen (0755) - was natürlich indiskutabel ist.
Daher wird /cgi-bin/ eben nach /htdocs/cgi-bin/ verschoben: das htdocs-Verzeichnis gehört zB. web1:www-data mit Modus 0750 - somit kann der Webserver zwar darin lesen, aber kein anderer Benutzer zugreifen.

Die einzige Alternative wäre gewesen, /cgi-bin/ mit ACLs zu schützen; das ist an sich einfach und sicher, nur müssen ACLs bei vielen Dateisystemen erst explizit aktiviert werden, die ACL-Tools sind standardmäßig oft nicht installiert, bei Backups werden ACLs häufig nicht berücksichtigt, und so weiter...
Ein "anderes" Controlpanel löst das /cgi-bin/-Rechteproblem übrigens so, indem es ein modifiziertes suexec-Binary ausliefert, das wiederum auch alternative Gruppen-Besitzer für /cgi-bin/ erlaubt. Das erfordert aber auch ein modifiziertes mod_suexec für Apache - somit würde also wieder viel zu tief in die von der Distribution bereitgestellten Pakete eingegriffen werden (was wir aus Prinzip nicht möchten).

Fazit:
Wir gehen davon aus, dass in den allermeisten Umgebungen praktisch niemand die Veränderung bemerken wird
Nur in den Fällen, in denen Benutzer CGI-Scripte mit hardcodierten Pfaden verwendet haben, ist eine Anpassung erforderlich - diese lassen sich aber mit o.g. find-Befehl schnell identifizieren.
Sollten Fragen oder Probleme auftauchen, stehen wir gerne zur Verfügung.

Das Update (v1.5.2-r1888+) wird in den nächsten Stunden noch mal als aktualisierte Preview bereitgestellt, derzeit testen wir den Updatevorgang auf knapp 10 produktiv betriebenen Servern durch, um Überraschungen zu vermeiden.

Der FastCGI-Starter (~/conf/php5/php-fcgi-starter) enthält ab Version 1.5.2-r1884 nun explizit ein "umask 0022" - damit wird eine eventuell im System restriktiver konfigurierte umask entsprechend korrigiert.

Und suhosin.session.encrypt wird ab 1.5.2-r1877 standardmäßig auf "off" gesetzt, da auch andere Anwendungen Probleme damit haben.

Viele Grüße

-Klaus Keppler

Zitat von prepaid

ERROR: Wrong 'suhosin.session.encrypt' option value. Read REQUIREMENTS section in INSTALL file or use Roundcube Installer, please!

Ab LiveConfig 1.5.2-r1877 wird suhosin.session.encrypt nun in den individuellen php.ini-Dateien automatisch auf off gesetzt (es gibt noch viele andere Anwendungen, die damit Probleme haben).
In Kürze ist die Oberfläche zur Verwaltung eigener php.ini-Einstellungen fertig, da kann man das dann auf Wunsch auch wieder auf "on" stellen.

Viele Grüße

-Klaus Keppler

Danke für den Hinweis - diese beiden neuen Map-Files sind neu (in Vorbereitung auf das Sperren von Kunden). Lua-Script wurde eben angepasst, ist im nächsten Update mit drin.
Vor der produktiven Freigabe richten wir für den Zugriff auf Postfächer auch noch automatisierte Tests ein

Viele Grüße

-Klaus Keppler

Zitat

Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write.

This is not correct. To change the permissions of a folder, you need write permission in its parent folder.
This is also the reason why the user must not have write permissions to his home folder - otherwise he could for example rename the "conf" folder to "conf.old" (no matter who actually owns this one!) and substitute it by a new conf folder.
Just try it out.

So you need to be really careful when planning write permissions to users.

Zitat

Ich habe die customerid definiert: 'customerid' => '3', Als ich Customeradd ausgeführt habe, erhielt ich den Rückgabewert 3. Tatsächlich hat er auch die ID: 3. Die API sagt jedoch: Error while calling Web Service: Invalid customer ID

customerid oder cid? Das spielt einen wichtigen Unterschied!
In der Funktion CustomerAdd geben Sie eine beliebige Zahl als Kundennummer an (z.B. 3). In der Antwort bekommen Sie zwei Felder zurück: id und cid. Das Feld id enthält eine Datensatz-ID (12 Zeichen lang), die Sie dann bei anderen Funktionen wie z.B. HostingSubscriptionAdd im Feld customerid übergeben müssen.

Zitat

Error while calling Web Service: Database Error: A transaction is already running (BEGIN)

Wenn dieser Fehler auftritt, müssen Sie LiveConfig am besten kurz neu starten (/etc/init.d/liveconfig restart). Wäre es Ihnen möglich, uns die Logdatei (/var/log/liveconfig/liveconfig.log) zu schicken, damit wir herausfinden können, wo/wie der Fehler aufgetreten ist? (entweder per Forum oder per Mail an info@liveconfig.com)

Besten Dank & viele Grüße

-Klaus Keppler

Zitat von WebOscar

nscd ist nicht installiert. Laut xferlog hat es nie einen Zugriff via FTP auf den Account gegeben.

Danke für die Info, dann werden wir mal weitersuchen.
In unserem Fall zeigt z.B. auch "lastlog" an, dass der betroffene Benutzer sich noch nicht angemeldet hatte, trotzdem wird er von userdel als "logged in" vermerkt...

Bitte installieren Sie folgendes Update: http://download.liveconfig.com…fig_1.5.2-r1857_amd64.deb

Anschließend öffnen Sie mit sqlite3 die Datenbank /var/lib/liveconfig/liveconfig.db und setzen mit folgendem Befehl den Lösch-Status des betroffenen Vertrags zurück:

UPDATE HOSTINGCONTRACTS SET HC_DELETED=0;

Danach sollten Sie den Vertrag erneut über die LiveConfig-Oberfläche löschen können.
Entschuldigen Sie bitte die Unannehmlichkeiten; ich versuche trotzdem noch herauszufinden woher das "user still logged in" kommt.

Viele Grüße

Klaus Keppler

Hallo Herr Groh,

wir können den Fehler inzwischen in einzelnen Fällen reproduzieren (Debian 6): wenn man einen Vertrag angelegt hat und sich mindestens ein mal per FTP (ProFTPd) angemeldet hat, dann kann der Account danach nicht direkt gelöscht werden.
Der Befehl "userdel" meldet den Fehler, dass der zu löschende Benutzer angeblich noch eingelogged sei (was allerdings nicht stimmt, es existieren auch keine Prozesse oder offenen Dateien mit dessen User-ID).
Ohne das im Detail untersucht zu haben tippe ich auf ein Problem irgendwo im Zusammenspiel zwischen ProFTPd/wtmp/PAM/nscd.
Haben Sie zufällig den "nscd" (name service caching daemon) installiert?

Wir haben jedenfalls auch schon eine Lösung: der Befehl "userdel" wird künftig mit dem Parameter "-f" (force) aufgerufen, außerdem werden explizit noch eventuelle Prozesse des betroffenen Benutzers gekilled.
Das Update sollte in ca. 3 Std fertig sein, eine Lösung zum manuellen Löschen des betroffenen Vertrags kommt noch dazu. Können Sie bitte zwischenzeitlich prüfen, ob der Account noch in /etc/passwd aufgeführt wird?

Viele Grüße

-Klaus Keppler

Zitat

ERROR: Wrong 'suhosin.session.encrypt' option value. Read REQUIREMENTS section in INSTALL file or use Roundcube Installer, please!

Das ist bei Debian in /etc/php5/conf.d/suhosin.ini konfiguriert. Stellen Sie dort die Option "suhosin.session.encrypt" entsprechend um:

suhosin.session.encrypt = off

Wir werden das noch in die FAQ aufnehmen, vielleicht auch irgendwie automatisieren - das ist aber noch nicht ganz ausdiskutiert, da diese .ini-Dateien meistens von Webserver-Betreibern individuell "getuned" werden.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben noch mal aktualisiert (v1.5.2-r1851). Es handelt sich hierbei um den "Release Candidate" für v1.5.2 - die Änderungen sind:

• weitere Anwendungen im AppInstaller:
  phpMyAdmin, Roundcube, Contao, Joomla!, Gallery, MediaWiki
• diverse Bugfixes und Verbesserungen in der Oberfläche

Einige Kleinigkeiten werden in den nächsten Tagen noch behoben (z.B. Löschen nicht erfolgreich installierter Anwendungen); die Freigabe ist für Freitag, 28.09.2012, ca. 10:00 geplant.
Im Laufe des Freitags wird auch die LiveConfig-Website an einigen Ecken erweitert und aktualisiert (u.a. Roadmap, Anleitungen, Handbuch, u.v.m.)

Viele Grüße

-Klaus Keppler

Zitat

bei der Übersicht der Datnebanken fände ich ein zusätzliches Freitextfeld ganz sinnvoll

Das gibt es intern bereits; wenn man Datenbanken aus Confixx migriert, wird dieses Feld auch entsprechen gefüttert. Die Anzeige fehlt jedoch noch sowie die Möglichkeit das zu bearbeiten.
Wenn man derzeit eine Datenbank anlegt/bearbeitet, kann nur das Passwort eingestellt werden. Diese Eingabemaske wird in Kürze komplett überarbeitet, so dass man dort u.a. auch eine Bemerkung erfassen kann, sowie einstellen kann ob die Datenbank auch "extern" erreichbar sein soll (wurde auch schon häufiger gewünscht).

Datenbanken, die von Apps installiert wurden, sollen in der Übersicht "read-only" sein - sowie mit einem automatischen Kommentar versehen werden.

Viele Grüße

-Klaus Keppler

Zitat

Derzeit arbeite ich in einem Virtuozzo-Container, falls das wichtig ist.

Äh, ja. http://kb.parallels.com/en/114093
Wie es aussieht, fehlt dort die Unterstützung für Pseudo-Terminals (was inzwischen zum POSIX-Standard gehört).

Zitat

This is because the needed file is absent from the debian-6.0-x86 template.

bzw.

Zitat

Another cause is absence of mounted devpts filesystem on the destination server[...]

Lösungshinweise sind auch in dem Artikel angegeben.
Ohne PTS werden auch viele andere Sachen nicht funktionieren (u.a. auch kein screen, kein expect, u.v.m.)

Nachtrag: falls udev nicht installiert ist - existiert bei Ihnen die Datei /dev/ptmx ?

Dieser Fehler deutet eher darauf hin, dass das /dev/-Filesystem nicht ordentlich gemounted ist.
Haben Sie das Paket "udev" installiert?

Wir werden wohl eine Prüfung auf Verfügbarkeit von Pseudo-Terminals (/dev/pts) einbauen - diese sind ziemlich elementar.

Viele Grüße

-Klaus Keppler

Danke für die Infos. Ich habe schon eine dunkle Vermutung, was das ausgelöst haben könnte (hat mit den Untiefen des MySQL-C-Clients zu tun).

Bis dahin: wenn Sie möchten, können Sie den Status der Datenbank in LiveConfig zurücksetzen und diese dann erneut löschen lassen. Sie brauchen dazu das Programm "sqlite3":

[B]sqlite3 /var/lib/liveconfig/liveconfig.db[/B]
sqlite> [B]UPDATE DBS SET DB_STATUS=1 WHERE DB_STATUS >=4 AND DB_NAME='phpmyadmin';[/B]
sqlite> [B].quit[/B]

Viele Grüße

-Klaus Keppler

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