Beiträge von SSchaub

Hallo zusammen,

ich wollte eben auch einen Thread dazu erstellen, da die manuelle Arbeit ausufert.

Bei uns ist das Problem auch beim Update auf die 2.9.0 aufgetreten. Mein erster Workaround war, dass ich die Domains angepasst habe (um eine Änderung durchzuführen) und dann das Zertifikat gelöscht und neu angelegt habe. Einzige optische Änderung:
Im "defekten" Zustand ist das Zertifikat keinem Kunden zugeordnet. Die Spalte ist leer. Das neu beantrage ist es dann.

Unsere LC Installation ist bis auf hinzugefügte PHP Versionen und über LC angepasste open_basedir "Standard".

Ich habe nun auf allen Hosts die IP Gruppe von default auf default2 umbenannt. Daraufhin konnte ich die Zertifikate problemfrei erneuern.
Gehe jetzt die heute ablaufenden manuell durch und hoffe, dass der Rest sich automatisch fängt.

kk: Danke für den Hinweis mit der IP Gruppe

Bei uns läuft das unter CentOS 7 bzw. Ubuntu 16.04 (ob der Ubuntu dabei war kann ich nicht sagen)
Die Version, von der wir kamen hab ich auf Anhieb nicht gefunden
Als Anhaltspunkt hier aus dem Update:
Upgrading database schema (r5103 -> r5154)
Das ist die erste Zeile aus dem Log vom Update..

Hallo zusammen,

hier noch fyi meine Lösung, um die Änderungen nachzuziehen. Mit etwas Handarbeit verbunden, aber verkraftbar:

Mit folgendem Script die aktuellen Benutzer in eine Datei dumpen:
mysqlusrdump.sh:

#!/bin/bash
# adapted from (http://www.pyrosoft.co.uk/blog/2006/10/18/show-grants-for-all-users-on-mysql/)
(
 mysql --batch --skip-column-names -e "SELECT user, host FROM user" mysql
) | while read user host
do
  echo "# $user @ $host"
  mysql --batch --skip-column-names -e"SHOW GRANTS FOR '$user'@'$host'"
done

Ausführen per ./mysqlusrdump.sh >~/grants.dump

Die Ausgabe ist nicht direkt verwertbar. Diese muss nun etwas aufgewertet werden:
- Manuell alle Einträge für root entfernen
- Ich habe auch den liveconfig User entfernt
- Suchen & ersetzen: localhost durch die IP des zentralen phpmyadmin Servers
- Ans Ende jeder Zeile ein Semikolon setzen

Dann per root auf die Datenbank und einmal per copy'n'paste reinschieben oder per
mysql < grants_bearbeitet.dump

Ist pro DB Server etwa 10 Minuten Aufwand.

VG
Stefan

Gnampf! Ein Initialpasswort.
Danke... da wars wieder mit dem Wald und den Bäumen.
Gruß
Stefan

chroot würde ich ehrlich gesagt auch bevorzugen.
Aktuell kann sich ja jeder Kunde gemütlich im System umsehen. Er sieht, welche Kunden noch so auf dem System unterwegs sind, welche Benutzer angelegt sind und kann sich die Systemkonfigurationen anschauen.
Das finde ich für ein Shared Hosting System schon etwas freizügig.

Gruß
Stefan

Hallo,

folgendes Konstrukt:
Die Benutzer werden auf einem zentralen Server gepflegt (srv01) Dieser ist nur Mailserver.
Web & DB liegen auf einen anderen Server (srv03 bzw srv04).

Als ich eben den ftp Account eines Kunden nutzen wollte ist mir aufgefallen, dass dieser nicht funktioniert. Das gleiche Problem hatte ich bereits letzte Woche schon mal. Nach einigem Probieren ging es dann plötzlich.
Eben konnte ich das reproduzieren.

Kunde ist angelegt, in /etc/vsftpd/users ist auch eine Datei mit dem Vertragsnamen des Kunden angelegt. Das Änderungsdateum der /etc/vsftpd/passwd.db ist Älter, als das Datum, an dem der Kunde angelegt wurde.

1) vsftpd neu konfigurieren -> keine Änderung
2) Dem Kunden einen weiteren FTP User angelegt
-> passwd.db wird aktualisiert
-> sowohl neuer, als auch alter Nutzer funktionieren

Mir scheint, dass beim Anlegen des Kunden, zwar der User angelegt wird, die passwd.db jedoch nicht aktualisiert wird.

Ähnlich ist es bei SSH. In der /etc/shadow ist kein Passwort für den Nutzer hinterlegt.
Aktueller Workaround:
Nachdem der Kunde angelegt wurde über "Verbindung starten" in dessen Kontext wechseln, dann das FTP Passwort nochmal setzen
->SSH Login ist nun möglich (/etc/shadow wird gesetzt)
->Einen zusätzlichen FTP User anlegen (/etc/vsftpd/passwd.db wird mit beiden Nutzern aktualisiert)
-> Zusätzlichen FTP User wieder löschen (passwd.db wird wieder aktualisiert. Es bleiben immerhin keine Leichen zurück).

Ist leider ziemlich umständlich. Ist das ein allgemeiner Bug, oder hängt da nur bei uns was schief?
Haben das mit 2 Servern, auf denen der lcclient läuft getestet und konnten es reproduzieren.

Hallo zusammen,

ich muss für einen Kunden ein altes Archivsystem bereitstellen (nur noch lesend, per FastCGI). Dies setzt noch auf die Dateiendung .php3.
Diese wird in der vhost Config ja per

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
                SetHandler None
            </FilesMatch>

zur Textdatei degradiert.
Ist es möglich, das per custom.lua (idealerweise so, dass man es nur in dem Vertrag aktviert) zu ändern?
Meine aktuelle quick-n-dirty Lösung ist es in der apache.lua umzubiegen. Nicht so kritisch, da der Kunde ein eigenes System hat. Mittelfristig fände ich da aber eine „Lösung nach Lehrbuch“ schöner.

Anpassungen an der apache.lua:

elseif opts.hasPHP == 2 then
      fh:write("FastCGI\n")
      -- FastCGI configuration
      fh:write("    <IfModule mod_fcgid.c>\n")
      fh:write("        <IfModule mod_php5.c>\n")
      fh:write("            php_admin_flag engine off\n")
      fh:write("            <FilesMatch \"\\.ph(p3?|tml)$\">\n")
      fh:write("                SetHandler None\n")
      fh:write("            </FilesMatch>\n")
        -- FilesMatch for Debian 7:
        fh:write("            <FilesMatch \".+\\.ph(p[345]?|t|tml)$\">\n")
 [B][COLOR='#FF0000']       fh:write("            Options +ExecCGI\n")
        fh:write("                SetHandler fcgid-script\n")[/COLOR][/B]
        fh:write("            </FilesMatch>\n")
      fh:write("        </IfModule>\n")
      if LC.distribution.family == "SUSE"  then
        fh:write("            <FilesMatch \"\\.ph(p[345]?|tml)$\">\n")
        fh:write("                SetHandler None\n")
        fh:write("            </FilesMatch>\n")
      end
      if not opts.hasCGI then
        -- if not already defined, set suexecUserGroup here:
        fh:write("        <IfModule mod_suexec.c>\n")
        fh:write("            SuexecUserGroup ", opts.user, " ", opts.group, "\n")
        fh:write("        </IfModule>\n\n")
      end
      fh:write("        <FilesMatch \"\\.php5?$\">\n")
      fh:write("            Options +ExecCGI\n")
      fh:write("            SetHandler fcgid-script\n")
      fh:write("        </FilesMatch>\n")
      -- use another PHP version?
      if php ~= 'php5' then
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php\n")
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php5\n")
      else
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php\n")
 [B][COLOR='#FF0000']       fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php3\n")[/COLOR][/B]
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php5\n")
      end

Viele Grüße
Stefan

Hallo zusammen.
Bin gerade hier rüber gestolpert. Beim nachträglichen Aufbau eines zentralen phpmyadmins wollte ich den Zugriff von dem Server auf die Datenbanken zulassen. Das klappt bei neuen Datenbanken, jedoch werden die bestehenden Nutzer, wie vom Thread Starter beschrieben, nicht aktualisiert.
Habe auch den offenen Bug gefunden:
https://www.liveconfig.com/dev/issues/53

Würde mich über eine Umsetzung freuen. Grade wenn man mal bei gewachsenen Systemen dahingehend was ändert spart das viel Arbeit.

Grüße,
Stefan