Beiträge von WebService4U

    Zitat

    ... aber das Programm läuft natürlich noch, weil es ja lokal ist. Wäre es eine Cloud-Anwendung könnte man es von heute auf morgen nicht mehr benutzen....


    Das ist ein klarer Vorteil lokaler Software. Es gibt immer Vorteile und Nachteile. Spätestens, wenn Du ein Datenschutz-Audit hattest, wirst du verstehen, was die Nachteile lokaler Software sein können.

    Zitat
    .... Und was machst Du wenn Deine SAAS-Software nicht mehr läuft? ...

    Ich suche mir einen neuen Anbieter. Das dürfte nicht länger als 4 Wochen dauern und die stehe ich auch durch, ohne Rechnungen zu schreiben oder Lastschriften bei meinen Kunden zu ziehen.

    Zitat
    .... Klar, die Daten kann man exportieren - aber was damit dann machen? Hast Du ein zweites anderes Programm oder Dienstleister wo genau diese Daen wieder importierbar sind? Das kann ich mir kaum vorstellen.... Diese Daten in andere Programme zu übertragen wird auf eine einfache Weise kaum möglich sein.

    Also der Export, die Umstrukturierung/Anpassung an die Datenstruktur der neuen Software und der anschließende Import in eine neue Software sind ja nun wirklich kein Hexenwerk. Macht keinen Spaß, aber das ist mit wenig Aufwand leistbar. Den Aufwand hast du ja auch, wenn Deine lokale Software nicht mehr verfügbar ist und du das System wechseln mußt. Ist also hier weder von Vorteil noch Nachteil.

    Zitat

    Falls doch: Dann verrate uns mal Deinen Anbieter und die Software um die Du dann mit den Daten alternativ einsetzen kann.

    Mein Anbieter: siehe oben.


    Fazit: Beide Varianten haben Vor- und Nachteile. Deine absolute Aussage von oben ist und bleibt unbegründet und ist wohl nur eine persönliche Meinung. Meine Erfahrung sagt mir etwas anderes.

    Lieber flo4545, ich denke, wir missverstehen uns hier grundlegend. Ich bin seit 15 Jahren im Geschäft und ich bin mir durchaus der Zusammenhänge und Anforderungen bewusst, die ich an meine (Vor)Dienstleister stellen muss. Genau für die von Dir beschriebenen Fälle benötigst du einen Disaster-Recovery-Plan. Ich habe meine Buchhaltung seit Jahren in der Cloud und selbstverständlich habe ich im Rahmen meines DRP ein Backup-und-Restore-Konzept auch für diese Daten. Es spielt bei der Auswahl der Dienstleister durchaus eine Rolle, ob diese eine Möglichkeit bieten, die Daten zu exportieren und im Rahmen eines Backup-Konzepts an anderen Stellen vorzuhalten, exakt so, wie man es auch mit lokalen Daten oder Daten, die in Rechenzentren liegen, handhaben muß (Gehaltsabrechnung ist da auch ein schönes Beispiel, oder machst Du Deine Gehaltsabrechnungen für Deine Mitarbeiter selbst?). Insofern kann ich hier keinen Unterschied erkennen, ob Daten in einer Cloud liegen, durch Software im Rahmen von software as a service oder lokal bzw. im eigenen Netz gespeichert werden. Ich bleibe dabei: Die Aussage, dass Kundendaten nicht in die Cloud gehören, ist aus der Luft gegriffen.

    flo4545 Dass Kundendaten nicht in die Cloud gehören ist zunächst einmal eine sehr spanndende Behauptung. Den Nachweis, warum das sol sein soll, bleibst Du aber schuldig und meiner unwesentlichen Meinung nach, ist das auch frei erfunden. Das Argument vom toten Anbieter kann hier kaum greifen, denn das kann Dir auch lokal passieren, wenn Deine lokalen Speichermedien abrauchen. Für diese Fälle gibt es einen Disaster-Rcovery-Plan, und der schließt die Cloud-Daten hoffentlich mit ein.

    Wir arbeiten mit collmex. Collmex hat csv-Import- und Exportfunktionen, diese nutze ich dann über eigene kleine shell- oder php-scripte. Was ich an Collmex wirklich mag, ist die altmodische Oberfläche, die aber eben auch verdammt schnell ist. Das ganze hat aber seinen Preis. Vorher hatte ich Quickbooks (alles manuell gepflegt) und als das auf Grund der vielen Belege zu klein wurde, wollte ich auf Lexoffice umsteigen. Ist bei mir im test aber durchgefallen. Unübersichtlich, buggy, langsam. eigentlich totaler Schrott (just my 2 cents)

    Hallo Herr Keppler,


    werden in Ihrer Firma Support-Tickets Ihrer Kunden eigentlich auch bearbeitet oder ist die Bearbeitung durch die Eingangsbestätigung per Autoresponder schon als erledigt anzusehen?


    Das mag hier vielleicht nicht der richtige Ort sein, aber eine ähnliche Frage wurde ja schon mal gestellt und ich muß nun leider feststellen, dass sich an der Situation nichts verbessert hat. Konkret habe ich am 02.11.22 die Ticketnummer LC#2022090234000027 erhalten und seit dem - au0er der Eingangsbestätigung, die mir einen Bearbeitung oder zumindest Erstmeldung binnen 24 Stunden versprach - nichts mehr von Ihnen gehört, so dass das Problem auch für mich schon in Vergessenheit geriet. Daher habe ich dann (leider) am 02.11.22 ein neues Ticket geschrieben (LC#2022110234000031]). Auch hier wieder nur der nette Autoresponder.


    Wann darf ich mit Hilfe rechnen?

    LiveConfig-Version: 2.13.0 (release) (aktuell)
    Neueste Version: 2.13.0-release
    letzte Prüfung: 08.03.2022 08:42:51 CET
    Plugins: ssl-letsencrypt (2.13.0-release)
    Plattform: x86_64-unknown-linux-gnu
    Konfigurationsdatei: /etc/liveconfig/liveconfig.conf
    Datenbank: 10.3.31-MariaDB-0+deb10u1 (stmt_open=0, stmt_cached=251)
    Treiber: MySQL (MariaDB Connector/C 10.5.5)


    Ein Kunde hat mit dem Anwendungsinstaller Wordpress nach /apps/wp installiert und auf das Verzeichnis /apps/wp mit der LiveConffig-Funktion Passwort-geschützte Verzeichnisse einen Passwortschutz erstellt. Beim aufrufen der Domain greift dieser jedoch nicht.


    Testweise habe ich einen solchen Schutz auf den Ordner /htdocs (bei mir /html) gelegt - dort funktioniert er einwandfrei.

    Neben der Option, sich das Handbuch zu kopieren und selbst zu hosten/anzubieten, bestünde ja auch noch die Option, sich selbst die für die Endkunden relevante Dokumentation zu erstellen.


    Dann sind auch die Screenshots immer aktuell, oder zumindest kann man diese immer selbst aktualisieren.


    Also beim besten Willen, natürlich KANN man das machen. Man kann und muss aber wohl zuallererst vom Hersteller/Entwickler einer Software , die lange lange aus dem Pre-Release heraus ist, erwarten, dass diese versionsaktuell dokumentiert ist. In welcher Form das geschieht, darüber kann man trefflich streiten. Aber hier die Verantwortung auf den Kunden abzuwälzen - so wie von dir vorgeschlagen - ist definitiv nicht der richtige Ansatz.

    Guten Morgen Herr Keppler,


    erst einmal vielen Dank für die schnelle Nachricht.


    Objektiv war mein Ton schon, denn dass das Handbuch nicht mehr verfügbar ist - und da kann es zunächst mal dahingestellt bleiben, ob es sich um ein Endanwender- oder Adminhandbuch handelte - ist schon eine Tatsache. Dass dies ohne Vorwarnung passierte, auch und das ist in der Summe unprofessionell. Ich vermag den Zusammenhang zwischen dem Relaunch der Webseite, der Neukonzeption der Handbücher und der Umsatzsteueränderung auch nicht feststellen, denn eine halbfertige Webseite zu relaunchen ist - sagen wir mal - suboptimal. Wenn wesentliche Dinge dabei plötzlich entfallen - und das ist hier der Fall - dann schlägt dass unter Umständen nämlich auch bei uns Hostern durch. Auch wenn Sie diese deutlichen Worte als nicht objektiv empfinden mögen: ich stehe bei meinen Kunden nun auch als unprofessionell dar, denn natürlich kommuniziere ich meinen Kunden, wo sich das offizielle Handbuch von LiveConfig beim Herstelle befindet und muss mir dann von meinen Kunden sagen lassen, dass da nichts mehr ist. Auch wenn das alte Handbuch hier und da veraltet sein mag - es ist besser als die Situation die wir jetzt haben. Vielleicht sollten Sie Ihre Entscheidung dahingehend überdenken, und die alte Version wieder verlinken, bis das Neue dann in 2022 vielleicht fertig ist.


    Verstehen Sie mich nicht falsch: ich bin ein großer "Fan" Ihrer Software. Aber so etwas darf in meinen Augen nicht passieren und muß einfach auch kritisch kommunizierbar sein.


    Sehr gern nehme ich Ihr Angebot an, mir das alte Handbuch zur Verfügung zu stellen.

    Liebes Keppler-Team,


    DAS ist ja wohl nicht euer Ernst! Wo bitte ist das Benutzerhandbuch hin?? Die Inhalte auf hostinghandbuch.de haben damit ja wohl nichts zu tun. Das ist bereits seit Wochen so. Wie kann man auf so eine Idee kommen, ein halbwegs aktuelles Handbuch - das ja mal da war - offline zu nehmen und dafür so einen Schrott anzubieten. Ich habe wirklich SO EINEN HALS grad. Das ist unprofessionell.

    Sven_67 Solange, wie die Handbücher in einem derart erbärmlichen Zustand sind, kann man wohl schon erwarten, dass das Entwicklerteam fachliche Fragen in Bezug auf LiveConfig beantwortet - niemand erwartet dabei eine Grundlagenschulung. Dass das Kepplerteam nichts für Fehler der Kundensoftware kann, versteht sich wohl von selbst.


    Aber zurück zum Thema: ich stehe regelmässig vor demselben Problem. Vertrag versehentlich gelöscht und muss wiederhergestellt werden. Ein Backup habe ich, auch der LiveConfig-Datenbank. Doch wie bekomme ich nun die in der LiveConfig-Datenbanksicherung Daten dieses EINEN gelöschten Vertrages oder Kunden wieder in die Produktivdatenbank. Mein derzeitiges Vorgehen ist so: Sicherungsdatenbank in einem extra Liveconfig-Server einspielen, die Konfiguration dann händisch ansehen und alles manuell auf dem Produktionsserver anlegen. Mach Spaß, wenn der Kunde 500 Mailkonten hat. Wie geht das besser? Mir wäre da ja schon mit simplen SQL-Statements geholfen, die die Daten eines Vertrages aus der LC-Sicherung holen und in die ursprüngliche Datenbank wieder einfügen. Ich bin auch durchaus in der Lage, diese Statements selbst zu schreiben, nur habe ich kein Datenbankmodell. Kann so etwas nicht mal von LiveConfig bereit gestellt werden? Oder gleich eine Export-Import-Funktion für einzelne Verträge und oder Kunden direkt in LiveConfig? Vllt. über xml? Ich hatte erst kürzlich den Fall, einen einzelnen Vertrag auf einen eigenen Server bringen zu müssen.

    Debian Jessie
    LC 2.8.4-r5653


    Hallo liebe Wissende,


    folgendes Problem:


    DomainA mit PHP 7.1.33 liefert einen 500er und hat folgende .htaccess


    Ursache:

    Code
    [[core:alert] ...... /.htaccess: Invalid command
    'text/css', perhaps misspelled or defined by a module not
    included in the server configuration


    Kommentiert man 'text/css' aus, läuft die Seite.


    DomainB mit PHP 7.0.33 hat dieselbe .htaccess und erzeugt auch mit 'text/css' keinen 500er.


    Stellt man Domain B auf PHP 7.0.33 um, darf man auch 'text/css' benutzen.


    Ich nutze die PHP-Pakete von Keppler-IT.


    Kennt jemand die Ursache für dieses Verhalten?

    Guten Morgen,


    Debian Jessi
    LC-Version: 2.8.4-r5653


    Aktuell lassen sich in LC Weiterleitungziele an der Domain einstellen, die zu lang sind und beim Apache restart des Webservers verhindern.


    Beispiel aus der /etc/apache2/sites-available/schuldiger_kundenvertrag.conf:
    ProxyPass "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"
    ProxyPassReverse "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"


    (Über Sinn oder Unsinn dieser Proxy-Weiterleitung bitte nicht diskutieren, das hat ein Kunde so eingestellt.)


    Fehlermeldung:
    Nov 20 06:20:35 serverxyz apache2[10159]: AH00526: Syntax error on line 50 of /etc/apache2/sites-enabled/schuldiger_kundenvertrag.conf:
    Nov 20 06:20:35 serverxyz apache2[10159]: ProxyPass worker name (http://education.ti.com/XXXXXX…BF65E5A62E7F1/3136434A5B2...) too long
    Nov 20 06:20:35 serverxyz apache2[10159]: Action 'configtest' failed.


    LC sollte hier vielleicht DRINGEND die Stringlänge überprüfen im GUI und so etwas abfangen. Das bedeutet ja immer, manuell in die /etc/apache2/sites-available/schuldiger_kundenvertrag.conf eingreifen um den Quatsch händisch auskommentieren zu müssen und den Indianer neu zu starten. Solange warten alle Kunden auf dem Server brav, denn nichts geht mehr.

    Ich muss das Thema auch noch einmal hochholen. In Vorbereitung eines Betriebssystemupgrades habe ich alle Verträge von suphp auf fastcgi umgestellt:


    Dazu habe ich in der LC-Datenbank die entsprechenden Werte in HOSTINGPLANS und HOSTINGCONTRACTS geändert:
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGPLANS SET HP_PHP=2;"
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_PHP=2;"
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_REFRESHCFG=1;"
    Danach mit einem beherzten service liveconfig restart die Änderungen durchschreiben lassen und die vhosts neu erstellt.


    Danach hatte ich genau das beschriebene Problem, dass der Indianer bei einigen Kunden plötzlich 500er feuerte mit Log-Einträgen:
    (104)connection reset by peer: mod_fcgid: error reading data from fastcgi server
    Premature end of script headers ... index.php


    Die Ursache lage letztlich darin, dass die php-ini-Verzeichnisse unter /var/www/<vertrag>/conf falsche Rechte hatten. Das aber auch nicht durchgehend: einige hatten 0777er Rechte, andere die korrekten 0555er Rechte. Dazu kam, dass bei einigen dieser Verzeichnisse das immutable flag gesetzt war, bei anderen nicht. Alles sehr verworren, zumal ich dort händisch nie eingegriffen habe, sondern LiveConfig immer ganz normal upgegraded habe. Die Lösung war letztlich das immutable flag durchgehend zu entfernen und die Rechte neu zu setzen:


    chattr -i /var/www/*/conf/php5
    chattr -i /var/www/*/conf/php53
    chattr -i /var/www/*/conf/php55
    chattr -i /var/www/*/conf/php56
    chattr -i /var/www/*/conf/php70
    chattr -i /var/www/*/conf/php71
    chattr -i /var/www/*/conf/php72
    chmod 0555 /var/www/*/conf/php53
    chmod 0555 /var/www/*/conf/php55
    chmod 0555 /var/www/*/conf/php56
    chmod 0555 /var/www/*/conf/php70
    chmod 0555 /var/www/*/conf/php71
    chmod 0555 /var/www/*/conf/php72
    service liveconfig restart

    Bei der Installation von Owncloud 10.0.9 über den App-Installer erhält man eine Fehlermeldung:


    Error while downloading web application installer - please contact your administrator.


    LC-Version ist 2.6.3 auf Debian.


    Error while downloading web application installer - please contact your administrator.


    Es scheint, als ob die Datei
    /var/cache/liveconfig/installer/wai-owncloud-10.0.9-1.php
    fehlt.


    Erzeuge ich diese als Kopie von /var/cache/liveconfig/installer/wai-owncloud-10.0.7-1.php läuft die Installation durch.