Beiträge von WebOscar

Hallo zusammen!

Über die Jahre besteht unsere kleine Farm aus mehreren LiveConfig-Servern mit einem Master und seinen Clients. Das Problem: Verschiedene Debian-Versionen, von 6 bis 8.9. Ich möchte nun alle auf den letzten Stand, auf Stretch bringen. Alle Server, mit einer Ausnahme, haben immer nur einen Dienst zu bedienen. Also entweder Web, Mail oder MySQL.

Der letzte Veruch ein Upgrade von 6 über 7 und 8 nach 9 auf dem klassichen, auf Debian dokumentiertem APT-Weg durzuführen, führte schon auf dem Weg nach 7 in eine Katastrophe, die nur durch ein Image-Rollback abgewendet werden konnte. Und da das nicht der erste Versuch war, kam mir der Gedanke, einen ganz frischen Server aufzusetzen und dann den Client nebst Nutzerdaten o. Datenbank o. Postfächern (je nach Server) zu migrieren.

Ich stelle mir das in etwa so vor:

• Neuen Server aufsetzen
• /etc/passwd und /etc/shadow übertragen (zusammenführen)
• RSync aller Nutzerdaten von alt zu neu.
• [INDENT]Falls der zu migrierende Client als Datenbankserver fungiert, Dumps der Nutzerdatenbanken erstellen, übertragen, einspielen.[/INDENT]
• Alten Server offline nehmen
• RSync-Update
• Alten Server abschalten
• neuen Server mit den IPs des alten Servers versehen.
• LiveConfig-Lizenz vom alten Server übernehmen
• Neuen Server durchstarten
• Irgendwo dazwischen: andere benötigte Dateien und/oder Konfigurationen übertragen

Ich habe dazu dieses - schon recht alte - Thema gefunden: Migration LiveConfig -> Liveconfig (2012er Version)

Ich entnehme der ursprünglichen Antwort von Herrn Keppler, dass mein Vorhaben grundsätlich so funktionieren müsste. Jetzt die Frage:

Hat das in letzter Zeit schon jemand so gemacht? Ist das aktuelle Vorgehen irgendwo beschrieben, wo ich es nicht gefunden habe? Kann vielleicht jemand aufzeigen, wie eine solche Migration ohne große Schmerzen durchzuführen ist oder was besonders zu beachten ist?

Ich freue mich über jeden hilfreichen Hinweis!

Ich wünsche eine schöne Vorweihnachtszeit,

Oskar

Öhm, jaaaaa. Ein klassischer Fall von selektiver Wahrnehmung. JETZT sehe ich das Tab auch.

Danke!

Hallo,

ich musste - nach Kundenbeschwerde - feststellen, dass Autodiscover seit den etwa letzten 10 Verträgen nicht mehr funktioniert. Eine Anfrage auf eine eingerichtete Adresse in neuen Verträgen wirft grundsätzlich einen 500er:

Error 500: Internal Server Error


An error occured while processing your request: Lookup failed


Created by LiveConfig®

Eine Anfrage auf eMail-Adressen in älteren Verträgen liefert allerdings die XML-Datei aus. Das gilt auch für eMail-Adressen, die in diesen Verträgen neu angelegt werden.

Ich habe keine Ahnung, wo ich hier ansetzen soll, den Fehler zu finden. Hat jemand eine Idee?

Noch technisches:

Ich verwende nicht die DNS-Funktionalität aus LiveConfig, sondern benutze eigene DNS-Server. Das DNS-Template für die Domänen in den betroffenen Verträgen hat sich nicht geändert und entspricht dem, der "alten" Domänen. Auch haben sich die Vertragsvorlagen in keiner Weise geändert.

Bin dankbar für jedes hilfreiche Feedback!

Zitat von antondollmaier

Ich bin mir sicher: wenn das Problem gelöst wäre, wäre kein (großer...) Bedarf für SNI gewesen.

Auch wenn das hier schon ein paar Tage her ist; Du hast natürlich Recht und ich hatte einen Knoten in meinem Denkprozess.

Mittlerweile hat sich das ursprüngliche Problem, nämlich das der WebDav-Client in Windows nicht auf SNI-SSL-Verbindungen eingeht, erledigt. Zumindest unter Win10 läuft das nun.

Sicher hätte sich das auch komplett in der custom.lua realisieren lassen. Aber da ich gestern zum ersten Mal damit gearbeitet habe und ich zügig zu einer Lösung kommen wollte, habe ich mich für ein Shell-Script entschieden. Mal sehen, wenn ich Zeit und Muße habe, mache ich das vielleicht nochmal komplett in der custom.lua.

Was passiert mit der custom.lua und dem Script?

Wenn man ein Konto anlegt, ändert oder löscht wird über die custom.lua das Skript aufgerufen. Bereits vorhandene Mailkonton können noch keine Ordner freigeben. Es genügt aber ein Konto aufzurufen, und z. B. im Alias ein Zeichen einzufügen und wieder zu löschen und dann auf speichern zu klicken, damit das Script angetriggert wird. Dabei werden noch nicht vorhandene Links gesetzt. Bei neuen Accounts funktioniert es sowieso, Änderungen werden ebenfalls richtig umgesetzt und nicht mehr vorhandene Links werden gelöscht, nachdem ein Konto gelöscht wurde.

Wie gibt man Ordner frei?

Ich habe es nur mit Thunderbird und Roundcube probiert

Für Thunderbird wird ein Plugin benötigt (die Anzeige von freigegebenen Ordnern funktioniert OOTB). Dazu verweise ich auf diesen Link: https://addons.mozilla.org/de/…addon/imap-acl-extension/

Roundcube kann ebenfalls Ordnerfreigaben verwalten und dabei die Rechte noch filigraner setzen, als es in Thunderbird geht. Dazu muss man allerdings sicherstellen, dass das ACL-Plugin geladen ist. Das kann man im Installationsverzeichnis von Roundcube in der Datei config/config.inc.php erledigen. Der entsprechende Eintrag 'acl' sieht bei mir so aus:

$config['plugins'] = array(
    'password',
    'archive',
    'zipdownload',
    'acl',
);

Setzt auf keinen Fall subscriptions = yes im shared namespace in der dovecot.local.conf! Das hat zur Folge, dass die abonnierten Ordner des Nutzers, der einen neue Freigabe erhält, auf die Freigaben reduziert werden! Und das passiert bei jeder neuen Freigabe für einen Nutzer. So kann er zwar den oder die neuen, freigegebenen Ordner sehen aber wenn er eine Reihe eigener, selbst erstellter Ordner hat, werden diese nicht mehr angezeigt. (Ich wäre daran beinahe verzweifelt.) Er muss seine Ordner dann erneut abonnieren.

Es ist wohl besser dem Nutzer Bescheid zu geben, er soll mal die neue Freigabe manuell abonnieren. Er kann sie in der entsprechenden Funktion des eMail-Client auf jeden Fall sehen, anklicken und abonnieren. Fertig.

Ich glaube, ich habe fertig! Fragen?

Viele Grüße und viel Spaß damit,

Oskar

Die hier vorgestellte Lösung wurde auf Debian Wheezy gebaut. Ggf. müssen Pfade in anderen Distris angepasst werden!

In der Datei dovecot.local.conf werden folgende Einträge benötigt:

mail_location = maildir:/var/mail/


# mail_debug=yes
# auth_debug=yes


mail_plugins = acl
protocol imap {
  mail_plugins = $mail_plugins acl imap_acl
}


protocol lda {
  mail_plugins = $mail_plugins acl
}


plugin {
  acl = vfile
  acl_shared_dict = file:/var/mail/shared-mailboxes.db
}


namespace {
  type = private
  separator = /
  prefix =
  #location defaults to mail_location.
  inbox = yes
}


namespace {
  type = shared
  separator = /
  prefix = shared/%%u/
  location = maildir:/var/mail/%%n@%%d/:INDEX=/var/mail/%n@%d/shared/%%u
  subscriptions = no
  inbox = no
  hidden = no
  list = children
}


service dict {
  unix_listener dict {
    mode = 0600
    user = mail
    group = mail
  }
}

... ob service dict wirklich benötigt wird, weiß ich gar nicht. Es fand Einzug während meiner Tests und ich habe nicht getestet, ob es auch ohne geht ...

Und nicht vergessen, LiveConfig die Server-Config neu schreiben zu lassen!

Als nächstes benötigen wir ein Script, das die Symlinks setzt. Das habe ich im Dafür habe ich mir dieses Verzeichnis angelegt: /usr/lib/liveconfig/custombin/

Darin erstellt Ihr updatemaildirlinks.sh mit folgendem Inhalt:

#!/bin/sh


# Parameter:    $1 = task (set to 'new', 'update' or 'delete'
#               $2 = Alias
#               $3 = Domain
#               $4 = Contract
#               $5 = Mailbox ID
#               $6 = old Target


maildir=/var/mail
domainlink=$maildir/$3
domaintarget=$maildir/$4
aliaslink=$domaintarget/$2
aliastarget=$domaintarget/$5
accountlink=$maildir/$2@$3
accounttarget=$maildir/$4/$5
oldlink=$maildir/$6


echo $1


# begin of mainscript
case $1 in


# begin of task 'delete'
delete)


    if [ -L $oldlink ]
      then
        rm $oldlink
    fi


;; # end of task 'delete'


# begin of task new
new)


    if [ ! -L $accountlink ]
      then
        ln -s $accounttarget $accountlink
      fi
;; # end of subtask 'new'


# begin of task 'update'
update)
    if [ -L $oldlink ]
      then
        mv $oldlink $accountlink
      else
        $0 new $2 $3 $4 $5 $6
    fi
  ;; # end of subtask 'update'


# begin of undefined subtask
  *)
    echo " is not a valid Task"
    exit 1
  ;; # end of undefined subtask


esac
# end of mainscript


echo " Done! "

Nicht vergessen hinterher ein chmod 755 auf diese Datei auszuführen.

Jetzt kommt noch ein bisschen Code in die custom.lua damit unser Script auch bei Bedarf ausgeführt wird. Falls die custom.lua noch nicht vorhanden ist, wird sie in /usr/lib/liveconfig/lua erstellt und bekommt diesen Inhalt:

orig_addMailbox = dovecot.addMailbox
orig_deleteMailbox = dovecot.deleteMailbox
createscript = "/usr/lib/liveconfig/custombin/updatemaildirlinks.sh"


function dovecot.addMailbox(cfg, opts, data)


        orig_return = orig_addMailbox(cfg, opts, data)


        linktask = "none"


        if data.old_addr == nil then
            linktask = "new"
            oldaddr = "FALSE"
        else
            linktask = "update"
            oldaddr = data.old_addr
        end


        local ex, stdout, stderr = LC.exec(createscript .. " " .. linktask .. " " .. data.name .. " " .. data.domain .. " " .. data.contract .. " " .. data.id .. " " .. oldaddr)


        return orig_return


end


function dovecot.deleteMailbox(cfg, opts, data)


        linktask = "delete"
        oldaddr = data.name .. "@" .. data.domain


        local ex, stdout, stderr = LC.exec(createscript .. " " .. linktask .. " " .. data.name .. " " .. data.domain .. " " .. data.contract .. " " .. data.id .. " " .. oldaddr)


        return orig_deleteMailbox


end

liveconfig oder lcclient neu starten und das Logfile beobachten. Mailclient öffnen und testen!

Im nächsten Post kommen noch Besonderheiten und Bemerkungen ...

Shared Folders mit Dovecot unter LiveConfigs Kontrolle (Teil 1 - Erläuterung)

Mein Ziel war es, Shared Folders zu ermöglichen und dabei LiveConfig so wenig wie möglich zu verbiegen, da ich bei kommenden Updates keine Lust habe die eigenen Anpassungen neu zu integrieren. Die in der offiziellen Dokumentation beschriebene Vorgehensweise funktioniert mit der von LiveConfig erstellten Konfiguration nicht. Ich habe mehrere Tage erfolglos mit allen möglichen Parametern und deren Kombinationen herumgespielt, bis ich mir die Idee zur Lösung kam.

Das Problem:

LiveConfig erstellt die Benutzerverzeichnisse nach dem Schema "vertrag/postfachnummer". Nimmt man die Konfigurationsbeispiele, die sich restlos alle um die Variablen %h, %%h, %u, %%u, %n, %%n, %d und %%d drehen und mit dem separator '/' arbeiten, funktioniert es nicht, weil aus irgendeinem Grund %h nicht zurückgegeben wird.

Nun werden die Folder eines Kontos in der LC-Konfiguration mit dem Schema (separator) '.' angelegt. Die Versuche damit scheitern, weil Dovecot bei der Anlage des Namespaces "shared" den Punkt im Benutzernamen dann offensichtlich auch als Separator erkennt, so dass aus dem Nutzer user@domain.tld user@domain wird. Somit ist dieses Verfahren von vornherein ausgeschlossen.

Mir kam die Idee, Dovecot - oder besser ACL vorzugaukeln, es würde sich um eine "Out of the Box-Config" handeln. Und das geht recht einfach mit Symlinks. Statt der Variablen %h und %%h kann man auf jeden Fall %u, %d und %n (auch als %%) verwenden.

Zunächst habe ich einen Symlink von /var/mail/domain.tld auf /var/mail/vertragX gesetzt. Dann einen weiteren Symlink von /var/mail/vertragx/alias auf /var/mail/vertragX/alias. Die Pfade im Namespace habe ich dann entsprechend auf /var/mail/%d/%n/ angepasst und die Freigabe-Tests gemacht. Diese waren dann endlich erfolgreich.

Diese Lösung ist aber nicht optimal, denn es kann zu kollisionen kommen. Angenommen vertragX hat die Domains doma.tld und domb.tld. Darin zwei Konten: info@doma.tld (vertragX/1) und info@domb.tld (vertragX/2). Da doma.tld und domb.tld symlinks auf den VertragX sind, kommt es zum Konflikt bei der Anlage des Symlinks vertragX/info.

Also eine andere Lösung:

Es ist auch möglich den Benutzernamen als Dateipfad zu setzen und innerhalb der Namespace-Config zu verwenden. Das ist problemlos möglich und führt keinesfalls zu einem Konflikt. So setzen wir /var/mail/%u/ oder /var/mail/%n@%d/ an den entsprechenden Stellen in der Dovecot-Config und schon funktioniert es.

Meine Lösung erlaubt das Teilen von Ordnern von und zu jedem Account eines Servers. Es ist auch möglich das Teilen auf Accounts innerhalb eines Vertrages oder noch restriktiver, innerhalb einer Domain zu beschränken. Dazu schreibe ich etwas im Nachtrag, nach dem folgenden Post mit der Copy & Paste-fähigen Lösung.

... to be continued ...

Okay. Bin noch dran. Create und Change/Update sind soweit abgefrühstückt. Muss noch ein Delete einbauen und dann fasse ich das hier zusammen! ... +123456789 habe ich auch noch nie bekommen.

Okay, got it!

Es liegt wahrscheinlich an dem fehlenden Rückgabewert.

Die Lösung ist denkbar einfach:

orig_return = orig_addMailbox(cfg, opts, data)
   ... some code ...
return orig_return

Um shared folders in den von LiveConfig erstellten IMAP-Konten zu verwenden, muss nach der anlage eines Mail-Kontos ein shellscript laufen. Ich bin unerfahren in der LUA und hänge zur Zeit hier fest:

orig_addMailbox = dovecot.addMailbox


function dovecot.addMailbox(cfg, opts, data)


        createscript = "/usr/lib/liveconfig/custombin/updatemaildirlinks.sh"


        orig_addMailbox(cfg, opts, data)


        linktask = "none"


        if data.old_addr == nil then
            linktask = "new"
            oldaddr = "FALSE"
        else
            linktask = "update"
            oldaddr = data.old_addr
        end


      local os_execute = os.execute(createscript .. " " .. linktask .. " " .. data.name .. " " .. data.domain .. " " .. data.contract .. " " .. data.id .. " " .. oldaddr)


end

Das IMAP-Postfach wird auch angelegt und das Script macht auch seine Arbeit. Aber dann knallt es im lcclient.log:

LC.popimap.addMailbox(alias@domain.tld) failed: unknown error

Das Konto wird im Panal dann mit der Uhr angezeigt, also als unfertig.

Jemand eine Idee?

Okay. Ich habe es geschafft! Teilen von Ordnern zwischen Nutzern auf dem selben Server - oder auch eingeschränkt, innerhalb einer Domain - Funktioniert einwandfrei über RoundCube, Thunderbird (auch die Rechteverwaltung) und wahrscheinlich auch in jedem anderen IMAP-Client. Ich muss das jetzt nur noch mit LiveConfig in Einklang bringen.

Ich teile hier gerne meine Lösung. Aber bevor ich mir jetzt die Finger wund schreibe, die Frage: Besteht hier überhaupt interesse?

Ich mache das, weil ich geteilte Ordner für unglaublich nützlich halte. Und da ich immer mal wieder die Frage erhalten habe, ob unsere Mailserver denn auch Exchange könnten, habe ich kürzlich endlich verstanden, was die Kunden denn überhaupt damit meinen. Geteilte Ordner! Das ist es, was gerade gerwerbliche Kunden schmerzlich vermissen.

Ich arbeite dann mal noch ein bisschen an der custom.lua!

Gut's Nächtle,

Oskar

Hallo,

ich habe heute erfolglos versucht, Dovcot-IMAP-Roundcube das Teilen von Ordnern beizubringen. Das war meine Vorlage: http://wiki1.dovecot.org/SharedMailboxes/Shared

Ich habe es auch geschafft, per Telnet und SETACL Freigaben zu setzen, ohne dass es eine Fehlermeldung gibt. Auch wird eine dovecot-acl im Ordner des Freigebenden angelegt.

Allerdings passiert nichts in Roundcube und so wie ich das aus der Doku von RoundCube verstanden habe, kann es das von Haus aus, wenn der IMAP-Server das anbietet.

Hat zufällig jemand SharedFolders im Einsatz? Und wenn ja, wo finde ich die Stelle an der ich weiterlesen muss?

Danke vorab,

Oskar

Schau mal hier: https://www.liveconfig.com/de/…ressen-funktioniert-nicht

Gruß,

Oskar

Moin,

antondollmaier: Hasse rääsch! Ich hatte mich mit der Problematik schon einmal befasst und erfolgreich verdrängt, dass der Host erst dann aufgelöst wird, wenn eine HTTPS-Verbindung hergestellt wurde. Bis dahin gibt es das Standard-SSL-Zertifikat und danach erst kann mit SNI das richtige, passende Zertifikat ausgeliefert werden. Mein Plan ist damit für die Tonne. Darum habe ich erstmal ein Wildcard-Zertifikat auf dem entsprechenden Server und wenn ein Kunde eine eigene Domain wünscht, dann muss er halt eine eigene IP bekommen und für das passende Zertifikat halt selbst bezahlen.

Mogwais: Danke für den Hinweis, aber wie Antondollmaier schon schreibt, der Handshake ist der Knackpunkt.

In meinem wirren Programmierer-Hirn habe ich eine unscharfe Idee, die ich aber aufgrund der Auftragslage in diesem Leben wohl nicht mehr umsetzen kann:

Ein Deamon, der HTTPS Anfragen entgegennimmt und cached. Anhand einer Liste interner IPs wird diese Anfrage nacheinander an alle internen IPs gesendet und der Handshake wird getestet. Passt das ausgelieferte Zertifikat, sorgt der Deamon fur ein Forwarding (via iptables oder so) des Clients zum richtigen Zielhost für die Dauer der Session...

Möglicherweise, aber auch dafür finde ich keine Lösung und auch nicht für SQUID. Aber zumindest mit dem Apache bin ich jetzt doch schon ein ganzes Stück weiter und habe eine SSL-Verbindung zustande gebracht. Bin aber noch nicht zufrieden, das ist alles noch sehr suboptimal. Ich bleibe dran ... falls es wen interessiert.

Hallo,

ich habe mal wieder eine ganz spezielle Frage, die - wenn gelöst - sicher in die Rubrik Tipps & Tricks passt:

SNI ist ja ganz nett, aber es gibt Fälle, da benötigt eine Domain eine exklusive IP. Und exklusive IPs werden langsam knapp. Um die mit Sicherheit aufkommende Rückfrage gleich zu beantworten, warum nicht nur SNI, hier ein ganz spezieller Fall: WebDAV! Der WebDAV-Client in Windows 7 (und folgende) kommt mit WebDAV-Verbindungen auf HTTPS auf SNI nicht zurecht. Der Rest darf ergoogled werden.

Ich habe mir nun folgendes überlegt, um Kunden exklusive SSL-Verbindungen zu ermöglichen und dabei die wertvollen IPs zu sparen. Ich bin mir aber nicht wirklich sicher, wie ich das umsetzen kann, noch ob es überhaupt einen Weg gibt. Nach mehreren Stunden Google-Verhör frage ich mal hier in die Runde, da ich mir vorstellen kann, dass die Kollegen und Mitbewerber ggf. ähnliche Ideen haben.

Meine Idee war nun, dass ich einen Proxy vorschalte und den DNS-Record der Domain auf eben diesen Proxy zeigen lasse. Der Proxy soll dann - abhängig vom angeforderten Hostnamen - in das interne Netz auf die entsprechende, private IP weiterleiten. Per HTTP funktioniert das auch ausgezeichnet. Ein Apache mit mod_proxy* nimmt die Anfragen an. Die .conf dazu sieht so aus:

(wir nehmen an, 12.34.56.78 ist die IP des Proxy und auch der SubDomain proxytest.test.xy. Die IP 10.1.1.8 ist die IP, die in LiveConfig dem Kunden und der Domain zugeordnet ist)

<VirtualHost 12.34.56.78:80>
	ServerName proxytest.test.xy
	ProxyPreserveHost On
	ProxyPass / http://10.1.1.8:80/
	ProxyPassReverse / http://10.1.1.8:80/
</VirtualHost>

Rufe ich jetzt also die Domain auf, bekomme ich die Seite angezeigt.

Aber via HTTPS bekomme ich das nicht hin. Ich habe es so verstanden, dass mod_proxy_connect genau dafür da ist, solche Verbindungen quasi zu tunneln und dem Client das vom Zielserver ausgelieferte Zertifikat zu servieren. Ich kann auch per netstat -ant sehen, das eine Verbindung auf Port 443 vom Browser zum Proxy aufgebaut wird, aber keine Verbindung vom Proxy zu 10.1.1.8. Nöscht! Null!

Die letzte Version meiner zahllosen Versuche und Variationen sieht so aus:

<VirtualHost 12.34.56.78:443>
	ServerName proxytest.test.xy
	SSLProxyEngine On
	ProxyRequests Off
	ProxyPreserveHost on
	<Proxy *>
		AddDefaultCharset off
		Order deny,allow
		Allow from all
		SSLRequireSSL
	</Proxy>
	ProxyPass / http://10.1.1.8:443/
	ProxyPassReverse / http://10.1.1.8:443/
</VirtualHost>

Hat vielleich jemand eine Idee?

Zitat von kk

Ich habe da noch eine Idee. Ungetestet, könnte aber klappen:
nach dem Upgrade von Debian 6 auf Debian 7 einfach das PHP 5.3 aus dem LiveConfig-PHP-Repo installieren. ...
Ist 'nen Versuch wert. Im "worst case" muss PHP 5.3 während dem Upgrade von Debian 7 auf 8 eben wieder entfernt werden.

Danke Herr Keppler. Ich hatte diese Idee auch im Hinterkopf aber mich nicht gewagt es auszusprechen. Also vielleicht lasse ich es auf einen Versuch ankommen!

Zitat von aziegler

WebOscar
Wir haben auch genug Kunden die noch 5.3 oder gar 5.2 ...
Ein 5.3 Build (oder gar 5.2) für Jessie ist keine Hexerei.

Ja ich denke, dass das gar nicht so ungewöhnlich ist. Man kann einen Kunden, der ggf. auch eigene Entwicklungen einsetzt, nicht in die neuen Versionen prügeln!
Dass es keine Hexerei ist, ist schonmal beruhigend!

Zitat von aho546745

Ich hab PHP5.2 kürzlich auch für einen Kunden auf nem Server mit Jessie und LC kompiliert, da musste ich ein paar Dateien patchen (findet man alles im Web) und SSL weglassen, ...

Gut zu wissen. Ich glaube, das wird bei den betreffenden Nutzern auf unseren Servern auch nicht benötigt.

Zitat von aziegler

stimmt, da hat der Kollege doch ein paar Patches, damit das geht.
Gibt's auf Anfrage per PN bei mir aber gerne!

Das ist ein Wort. Danke, sehr gerne! Ich melde mich dann in Kürze, wenn ich das Projekt "jessie" angehe.

Vielen Dank nochmal. Kann schon wieder viel besser schlafen!

Schönen Dank schonmal für die Antworten!

Dann gehe ich die Sache mal ganz gelassen an. Vorher werde ich dann einfach mal die LiveConfig-Datenbank zur verwendeten PHP-Version aller (Sub-)Domains befragen und die dann hinterher auf die richtige Zuordnung prüfen. Wer auf den Squeeze-Servern auf default stand und durch das Upgrade auf 5.4 katapultiert wird und dessen WebSeiten problemlos weiterlaufen, der bleibt dann halt auf 5.4 - bis zum Update auf Jessy. Da dann das gleiche Spiel! Mit etwas Glück brauche ich auf den Standard-Web-Servern dann überhaupt kein 5.3 mehr.

Bei dem einen, speziellen Server wird aber 5.3 ganz sicher benötigt. Da werde ich um das nachinstallieren, bzw kompilieren wohl nicht rumkommen. Es sei denn, der Kunde sieht endlich ein, dass... Aber das ist eine andere Geschichte.

Hallo Forum,

dem Titel kann man mein Vorhaben ja schon entnehmen. Dazu habe ein paar Fragen, die mir mit Eurer Hilfe vielleicht beantwortet werden können.

Ich habe aktuell sieben LC-Server laufen. Bis auf den jüngsten, der auf Wheezy läuft, sind alle noch auf Squeeze.

Hier im Forum habe ich bereits diverse Anleitungen und Erfolgsmeldungen zum Upgrade von Wheezy auf Jessy gelesen und das sollte das kleinere Problem sein.

Ich sehe die Schwierigkeit im Upgrade von Squeeze auf Wheezy aufgrund der nativen PHP 5.3 installation, die bei dem Upgrade ja wohl verloren geht. Daraus resultieren aus meiner Sicht zwei Probleme:

1. Die bisher über das LC-Repo zusätzlich installierten PHP-Versionen kollidieren - zumindest PHP 5.4 - mit der nativen PHP-Version von Wheezy. Hier Müsste also vor (während/nach) dem Upgrade mindestens 5.4 aus LC gelöscht werden, richtig?

2. eine Hand voll Nutzer benötigen weiterhin dringend PHP 5.3 (nicht fragen warum! Rheinische Begründung mit vier Buchstaben: Isso!) und in einer besonderen Ausnahme, auf einem eigenen LC-Server, PHP 5.3 in der suexec-Variante.

Also muss PHP 5.3 wohl von Hand kompiliert werden, da das LC-Repo diese Version nicht zur Verfügung stellt. Gibt es denn irgendwo eine passende config für den Selbstbau, damit sich dieser genauso in das System integrieren lässt, wie die aus dem Repo?

Hat wer zufällig Erfahrung mit diesem Szenario und ggf. gar Dokumentationen dazu?

Und natürlich muss PHP5.3 auch nach dem Upgrade auf Jessy zur Verfügung stehen.

Gibt es da irgendwelche bekannten Probleme?

Und schließlich, wie sieht es mit Nutzern aus, die auf Squeeze bereits höhere PHP-Versionen nutzen? Ist sichergestellt, dass nach dem Upgrade die vom Nutzer gewählte PHP-Version auch dann verwendet wird, wenn sie plötzlich Systemstandard (PHP5.4 auf Wheezy) ist oder nach dem Upgrade auf Jessy eben nicht mehr System-Standard ist?

Vielen Dank vorab für jeden hilfreichen Hinweis!

Nur weil ich neugierig bin...

Hat es wer ausprobiert und läuft es so? Bei uns gibt es jedenfalls keine Probleme.