Beiträge von WebOscar

Okay, dass ist nicht wirklich ein Problem mit bzw an LiveConfig. Da es aber grundsätlich nicht selten vorkommt, dass ZendGuardLoader nötig ist und ich gestern den ganzen Tag mit der Fehlersuche verbracht habe, möchte ich das hier einmal Posten.

Hat außer mir denn niemand den ZendGuardLoader mit PHP5.3 oder PHP5.4 auf LiveConfig-Servern laufen oder trifft es tatsächlich nur mich?

Das Problem habe ich hier im gSales-Forum beschrieben.

Könnt Ihr das bitte auch mal ausprobieren? So wie es für mich derzeit aussieht, kann man auf LiveConfig-Servern/Clients seinen Kunden kein ZendGuardLoader anbieten - das liegt aber definitiv NICHT an LiveConfig!

Schönes Wochenende,

Oskar

Hallo Eschy5,

eigentlich startet LiveConfig den Indianer "on Demand" durch. Ein Cronjob ist hier nicht nötig und die Counterscripts waren auch nicht "schön". viel Spaß mit LiveConfig.

So ein Ärger,

zum WHD wäre ich doch glatt gefahren um Sie einmal persönlich zu treffen. Aber ausgerechnet in den drei Tagen bin ich auf einem MS-Workshop in Belgien. Pendeln ist da leider nicht drin.

Ich hoffe, Sie kommen dann im nächsten Jahr wieder zum WHD.

Ach, zwischenzeitlich auch Post von KK!

Dankeschön. Hab's ja ähnlich probiert. Bei einer Neuinstallation des Servers ergab sich aber o. g. Problematik der verschobenen UIDs und GIDs.

Ich nehme - wie Sie auch vorschlagen - nun auch ein Backup des Grundsystems vor. Sollte eigentlich sowieso gesichert werden, war nur noch nicht eingerichtet (stand heute auf dem Plan) nachdem ich unsere VEs auf neue Systeme migriert hatte.

Der Teufel ist ein Eichhörnchen!

Vielen Dank für Ihre Antwort und noch einen schönen Sonntag mit Ihrem Nachwuchs,

Oskar Groh

Ich beantworte das mal selbst:

Zitat von WebOscar

Kann ich nun problemlos den LiveConfig-Server neu installieren, die Lizenzdaten einspielen und anschließend die LiveConfig-Datenbank gegen die aus der Sicherung ersetzen, die Daten aus /var/www zurückspielen, LiveConfig starten und gut ist?

Ja - fast!

Ganz toll wäre es gewesen, wenn LiveConfig die Nutzer wieder anlegt und auch gleich die Apache-Config neu schreibt. Tut's aber nicht. Auch nicht, nachdem etwas geändert wurde.

Ich musste:

• die Nutzer und Gruppen (jeweils von alt nach neu) aus /etc/passwd, /etc/shadow, /etc/group und /etc/gshadow kopieren
• Darauf achten, dass nach der neuinstallation die UID und GID von LiveConfig "verschoben" sein kann. Ggf chown auf div. Verzeichnisse
• die Dateien aus /etc/ssl/private kopieren und ggf der Gruppe ssl-cert zuordnen.
• das originale /etc/apache2-Verzeichnis zurückspielen.
• Zurückspielen der Nutzerdaten aus /var/www und wiederherstellen der MySQL-Datenbanken ist klar. Unter Debian noch die originale /etc/mysql/debian.conf holen, weil sonst der Server eine hässliche Fehlermeldung wirft.

Mehr fällt mir jetzt nicht ein. Musste schnell gehen, konnte nicht dokumentieren.

Schönen Sonntag noch!

Gestern Nacht ist aufgrund eines Plattencrashes unsere VE mit dem LiveConfig-Server so beschädigt worden, dass nichts mehr ging.

Auf dieser VE liefen außerdem ein Kundenweb und unsere eigenen Seiten. Alles andere läuft noch auf den Clients.

Wir und einer unserer Kunden sind jetzt also offline, zumindest mit dem Web-Teil.

Ich konnte zwar LiveConfig selbst wieder starten aber der Apache war nicht zu retten. Offensichtlich ist das System insgesamt stark beschädigt worden. Das ist insofern schlecht, weil LiveConfig auf 8443 lauscht, die Kunden aber einen Link über einen Proxy auf Port 443 nutzen, der nun nicht erreichbar ist.

Ich habe auf unserem Backup-System alle Daten aus /var/www, alle MySQL-Dumps vom letzten Backup sowie die LiveConfig-Datenbank.

Ich habe nun eine frische VE aufgesetzt und alle erforderlichen Pakete installiert. Jetzt wage ich mich nicht wirklich weiter.

Kann ich nun problemlos den LiveConfig-Server neu installieren, die Lizenzdaten einspielen und anschließend die LiveConfig-Datenbank gegen die aus der Sicherung ersetzen, die Daten aus /var/www zurückspielen, LiveConfig starten und gut ist?

Ist noch etwas besonderes zu beachten?

Vielen Dank vorab,

Oskar Groh

Na Hallo!

Dann moechte ich natuerlich auch noch Gratulieren. Herzlichen Glueckwunsch zum Nachwuchs!

Und allen Anderen auch von mir ein frohes, erfolgreiches und vor allem gesundes neues Jahr 2013!

Also bei mir ging es nicht nach einem Neustart - sowohl des LiveConfig-Servers als auch des betreffenden Clients. Auch nach mehr als 24 Stunden (jetzt gerade) ging es nicht.

Ich musste auf dem Client erst /var/cache/liveconfig/downloads leeren, dann ging's. Danke m_k fuer den Hinweis.

... aber schnell ging das diesmal nicht. Da sind wir bei solchen Dingen aber schnelleres vom LC-Team gewohnt. Aber es war ja Weihnachten und man muss Herrn Keppler und seinem Team auch mal ein paar besinnliche Tage goennen.

Edit: habe gerade vom Nachwuchs gelesen ... ich habe nichts gesagt!

Das war sicher die Antwort auf den Submission-Versuch. Hatte sich erledigt - siehe erster Eintrag auf dieser Seite. Augabe von netstat -ant ?

Ach verdammte Hacke. Da steht ja beim ABRUFEN kommt der Fehler. Dann vergiss Submission. Sorry, wer lesen kann ist klar im Vorteil.

Was sagt

netstat -ant

?

Okay nochmal ... Es geht jetzt erst mal nicht um die Konfiguration des Mailservers sondern darum, andere mögliche Fehlerquellen auszuschließen.

Hast Du versucht, eine Mail aus Deinem Outlook über eben diesen neuen eMail-Account über Port 587 zu verschicken?

Der Hinweis von aci kann trotzdem der Treffer sein. Port 25 ist ursprünglich gedacht, damit Mailserver untereinander kommunizieren. Immer mehr Provider sperren diesen Port. Versuche in Deinem eMail-Programm mal den für Clients gedachten Port 587 (Submission) für den Postausgangsserver.

Hallo,

bei dem Versuch über die Anwendungen Joomla! zu installieren passiert folgendes:

Nach der Abfrage aller Daten kommt das Fenster "Neue Web-Anwendung installieren" und für den Bruchteil einer Sekunde steht hinter dem Installations-Status: Lade Paket herunter: kurz ein grünes Häkchen.

Dann ändern sich alle drei Punkte auf Sanduren, werden ausgegraut und das war's.

Ruft man Anwendungen erneut auf, steht bei der betreffenden Installation:

Status: Fehler: failure while executing tar

Ich habe das dann auch in eigenen Accounts sowohl auf Clients, als auch auf dem LC-Server selbst repruduzieren können. Andere Anwendungen lassen sich problemlos installieren. Die fehlerhafte Installation lässt sich wieder entfernen.

In allen Logs - sowohl auf dem Server, als auch auf den Clients findet sich kein einziger, brauchbarer Hinweis.

LC-Server: 1.6.1-r2083
LC-Client: 1.6.1 (r2083)

Der Kunde, der das Problem gemeldet hat, konnte vor zwei Wochen noch problemlos Joomla! über die Anwendungen installieren.

P. S.: Kann das jemand bestätigen?

Vorweihnachtliche Grüße,

Oskar Groh

Was sagt denn das /var/log/mail.err und /var/log/mail.log?

Das hier hilft auch:

cat /var/log/syslog | grep dovecot

xcache will not run under FastCGI if mod_fcgid is used, which is - for any reason - almost the default. It will run well, if FastCGI is used with mod_fastcgi, as long mod_fastcgi has a proper setup! What mod you are using for FastCGI?

The most important setting for using an opcode cache under FastCGI is "maxClassProcesses" which has to be set within the apache configuration to "1". This is mendotary to allow php to handle its processes by itself and it will only work with mod_fastcgi, while it has an disastrous effect to mod_fcgid.

Of course, mod_php is the simple way. But I wouldn't accept the loss of security.

FastCGI is just the protocoll!!! mod_fcgid or mod_fastcgi are the implementations and they are not the same! They are independent developments, not a fork or a further develpment of each other. They both just using the FastCGI-Protokoll in some different ways.

See what I mean?

Zitat von webby

Code

==> /var/log/liveconfig/lcclient.log <==
[2012/12/07 16:41:44.402079] [477|813] Created database 'phpmadb' (user 'phpmauser')


==> /var/log/mysqld.log <==
121207 16:41:45 [Warning] IP address '111.222.111.222' could not be resolved: Name or service not known
121207 16:41:45 [Warning] Access denied for user 'phpmauser'@'111.222.111.222' (using password: YES)

...

Achja:
LiveConfig 1.6.0-r2052
CentOS 6.3 x64

Kommt mir bekannt vor: https://www.liveconfig.com/de/…-Web-Server-getrennt-sind

Bug behoben in 1.6.1

Viele Grüße,

Oskar Groh

Na dann warte ich doch besser noch, bis das geklärt ist. :confused:

Saugute Idee! +1 dafür!

Zitat von kk

However, using an opcode cache is always a good idea as long as you use mod_php or FastCGI.

Yes, But the question is, how FastCGI is used!

As I mentioned in another post, an opcode cache will only work correctly, if you use mod_fastcgi, NOT mod_fcgid! There is a huge difference between them and no - mod_fcgid is not a newer mod_fastcgi nor a further develpment of it!

Here you'll find more information: http://www.brandonturner.net/b…gi_with_php_opcode_cache/

And now I remember, what Feature-Request I want to ask for:

FeatureRequest: Autodetection if the WebServer runs with mod_fcgid or mod_fastcgi and set proper settings. That would be great!

Greetings,

Oskar Groh

Also ich erspare mir hier mal einen Kommentar auf diese ermüdenden und nervenden Glaubenskriege und komme zurück zum Thema:

Ich habe viele Jahre WebFakt genutzt. Vor allem, weil es (Para-)Schnittstellen zu verschiedenen Panels geboten hat. Leider haben sich in diesen Jahren immer mal wieder ganz gemeine und peinliche Fehler eingeschlichen. Und irgendwie haben wir immer irgendein Problem gehabt.

Nach diversen Tests haben wir vor etwa drei Jahren zu gSales gewechselt. Es ist zwar nicht wirklich optimal für unser Geschäft aber mit ein paar Kniffen und der Nutzung der API's aller eingesetzten Lösungen (Bestellsystem, LiveConfig, DNS-Server, DNS-Robot usw, usw) stellt sich gSales als absolut verlässliche Lösung zur Kundenverwaltung und Abrechnung dar. Letzteres war uns hier besonders wichtig.

Die Rundum-Glücklich-Lösung gibt es ohnehin in keinem Bereich - auch wenn sich LiveConfig gerade anschickt, eine solche Lösung in seiner Sparte zu werden.

Hilft das schon weiter?

Viele Grüße,

Oskar Groh