Beiträge von Cerberus

  • seltsamer Support

    Eingie der Argumente kann ich durchaus verstehen.

    mal ein kleines Beispiel:

    Wir stellen für Behörden Webshops auf Magento-Basis bereit. Wir betreuen Sie auch.

    Nun haben wir den Fall, das ein Upgrade auf PHP7 ansteht (bei QNAP noch nicht mal in Sichtweite).

    Die eigendliche Shop-Migration (also den Core) haben wir per Vertrag bezahlt bekommen.

    Die Migration der fast 50 eigenen Module müssen wir selbst berwerkstelligen. Der Kunde erwartet gleiche Funktion und identisches Verhalten.

    Gleichzeitig hat der Hoster die Hardwarte umgestellt (MariaDB-Upgrade). Die ANpassung der Abfragen auf die vom Hoster bereitgestellte DB-Version ist unser Bier.

    Da gibt kein Ticket und keinen separates Budget. Einer der Shop-Betreiber hat über ein Community-Modul letzte Woche den produktiven Shop zerlegt.

    Obwohl er das wissendlich gemacht hat, war es meine Pflicht, die Kiste wieder online zu birgen. Ich kann mich da nicht rausreden: Selber schuld lieber Kunde!

    Er hat im Ticket lediglich eine Ermahnung vom obersten Boss erhalten -- das wars dann auch.


    eins könnt ihr mir glauben -- ich steh in BEIDEN Lagern -- Support UND Entwicklung!

    Ich weiß ganz genau, wovon ich rede. Wenn ich den reinen Support (vom Freitag) bewerten sollte -- 2/10 Punkten (2 gibts, weil er angerufen hat)

    An sonsten: versagen auf ganzer Linie


    Ich habe ein Ticket wergen eine RAM-Bug eröffnet. Was prüft der Support: HDD und INodes. Mehr hat er nämlich nicht gemacht -- in 30 Minunten.

    Der Rest war zielloses hin-und-hergeklicke und die Aussage: es ist schon viel zu spät.

    Crontab überprüft: Nein

    RAM-Auslastung überprüft: Nein

    CPU-Auslastung überprüft: Nein

    Prozess-Analyse: Nein


    Das wäre aber genau das gewesen, was er aufgrund des Tickets hätte machen müssen. die HDD hat 27TB Frei und rein garnichts mit nem vollgelaufenen RAM zu schaffen.


    Es geht mir hier ums Prinzip -- um die Grundsätzliche Qualität einer Analyse-Leistung -- und das ist leider 0/10


    Alles andere ist leider nur Wort-Klauberei -- ist meine Sicht auf die Dinge....

  • seltsamer Support

    Die Debatte hjier dreht sich ausschließlich um die Hardware ....

    Schauen wir mal auf die:

    Mainboard: FoxConn

    CPU: Intel (BulkWare - nix besonderes)

    RAM: ADATA

    Gehäuse: (da hab ich nix leserliches gefunden)

    Betriebssystem -- oh gott -- das kann ich nie im Leben alles aufzählen


    Die Fehler-Ursachen:

    Qsirch: QNAP

    Qifile: QNAP


    Wer ist jetzt für die Lösung des Problems zuständig??


    PS: Retest auf einer TS-439 PRO II+ (vanilla) -- nach 2h und 26 Minunten ist das NAS unbenutzbar -- nur ein Trennen vom Strom macht es wieder zugängig.


    Die Ursache ist (aus meiner Sicht) exakt eingegrenzt. Alles andere, was der Support nun vorbring sind -- aus meiner Sicht -- "faule" Ausreden.

    Ich werde alles noch mal sachlich zusammenfassen und im Ticket vermerken. Eine Reaktion erhoffe ich mir nicht mehr.

    Auch dieses Ticket wird geschlossen und der Bug bleibt bestehen ...


    PS: der aktuell genutzte Samba (4.4.16) in der aktuellen Firmware hat bei einem Test 21 CVE-Lücken vorzuweisen.....

  • seltsamer Support

    Ich finde leider, das der Support sich zu schnell aus der Verantwortung zieht.

    Es geht hier klar um einen Software-Bug.

    Den dann in seiner Ursache auf die Hardware zu schieben ist hier deutlich fehl am Platz.

  • seltsamer Support

    Legrain :: nenn es bequemlichkeit -- und vor allem Strombedarf ...

    außerdem kann nicht in allen Fällen ein "dicker Server" aufgestellt werden .. ist also "historisch" bedingt ...


    Robertson23 :: setze ich die Aussage des Supporters am Telefon an: JA -- kein Support weil Hardwareänderung

  • seltsamer Support

    guten morgen liebe gemeinde :)


    ich habe mir dann mal ein paar Strunden um die Ohren geschlagen und den BUG gefunden -- ich hab also mal die Hausaufgaben des Supports gemacht:


    1.) Screenshots analysiert

    2.) crontab angeschaut

    3.) Gehirn benutzt :)


    ZUr Ursache:

    Die Prozesse, die dort laufen gehören zum "Qsirch". Das ist eine Phyton-Scrip-Sammlung, welche nicht auf sich selbst reagiert. Da ich hier aber eine große Menge an Dateien habe, wird er über den crontab immer und immer wieder gestaretet. Das hat Zur Folge, das der Cron zur laufzeit mehr Speicher zur Verwaltung braucht und das Script systematzisch immer mehr RAM "auffrisst". Nun zu den JRE's -- diese sind auch ein Teil dieses Prozesses und gehören zum "Qifiling". Der ist leider so komisch gebaut, das er immer mehr Prozesse vom Phyton zugewiesen bekommt und damit ebenfalls übers Ziel hinaus schießt.

    QNAP-RAM-2019-02-13_2.png

    All diese Informationen waren dem Support bekannt. Leider beweißt auch QNAP -- Kommerzieller Support existiert nicht :(

    Spätestens, wenn der Supporter zu mir (recht deutlich) sagt: Wechseln Sie doch zu Synology -- läuft da was falsch!!!


    Es tut mir leid, das ich zum Gattung IT-Profi gehöre und mich seit fast 15 Jahren mit Linux-Servern beschäftige.

    Ich kann recht gut einschätzen, was auf den Dingern rund läuft und was nicht so optimal ist.


    All das, was der Support angeführt hat -- waren puhre ausreden -- nur um den Kunden zur Reinstallation zu bewegen.


    Aktuell ist die Lösung die: Qsirch und Qifiling in den Apps deaktiviert

    QNAP-RAM-2019-02-23.png


    Und jetzt ratet mal, was der Effekt ist ........


    Achso -- der Speicher läuft seit 2015 in dem NAS -- Fehlerfrei (TVS-671)


    Code
    LOG-Status:
Date/Time: 2019/02/23 07:01:46App Name: Hardware StatusCategory: KernelMessage: [Hardware Status] NAS out of memory. Started kill process: 25182 "python". Disable some applications to free up memory, or expand the system memory.
Date/Time: 2019/02/23 07:01:48
Message: [System Message] Qsirch has been automatically disabled by QTS to free up system memory.

  • seltsamer Support

    Das mit dem Org-RAM habe ich schon probiert ...

    Da dort aber nur 4GB drin warren, ist die Kiste nach 2h dicht -- unbenutzbar ....

    da geht weder Webinterface, noch ssh -- es stürzt alles ab ...


    per Default ist der RAM-Verbrauch der Apps stark angestiegen ...

    QSRICH: 2.7GB

    QSync: 1.4GB

    JRE (mit exorbitant langer Befehlszeile): 4,5GB

    ....

  • seltsamer Support

    Hallo alle miteinander


    Ich habe gerade eine TeamvViewer-Sitzung mit einem Supporter hinter mir. Diese war zu meinem bedauern weder erquicklich, noch wurde ein Ergebins zutage gefördert.

    Zum Hintergrund:

    Seit knapp 5-6 Monaten beobachte ich, wie der Systemprozsee "crond" immer mehr RAM "frisst" und damit den Speicher und die Auslagerungsdatei komplett ein nimmt.

    Da alle meine bisherigen Maßnahmen eher kruzwqeiliger Natur waren, wollte ich beim Support einmal Nachfragen, ob es eine Lösung dazu gibt.

    Der Mittarbeiter wollte die LOG-Files haben und eingie andere Informationen. Diese ließ ich ihm zukommen. Nach 2-3 Tagen meinte er kurz: Malware.

    Eine Erklärung und das WIE und Warum wurde nicht erläutert. Ich sollte das Passwort zum MySQL-Server ändern und das NAS neu starten. Da ich das PW schon beim Setup

    geändert hatte, dachte ich ok -- mach was er sagt -- Passwort geändert - NAS Rebootet .... und dann warten ...

    Nach ein paar Tagen -- das gleichew Bild -- 2x crond mit je 4GB Speicherverbrauch. Erneute Rückfrage beim Support -- die Antwort kahm - bitte neue Firmware installieren.

    Ich stiefel also auf die Webseite => Downloads => neue Firmware runtergeladen und installiert. Wieder ein paar Tage warten -- oh Wunder -- das gleiche Bild...


    Ich also wieder in das Ticket geschrieben und um Unterstützung gebeten -- die Antwort kahm -- bitte neu instzallieren ....

    WIe jetzt -- schon wieder ??? -- das hatte ich erst ein paar Wochen zuvor gemacht, als ich 8TB-Platten eingebaut habe -- und die INODES nicht ausgereicht haben...


    Ich habe diese Option abgewählt und um eine TeamViewer-Sitzung gebeten. Diese fand heute (vorhin statt) -- und wurde abgebrochen ...

    Was war passiert -- der Kollege versuicht vergeblich, ein Scann-Tool vom QNAP herunter zu laden.

    Die endete in der Meldung: chmod: cannot access './xxxxxxxxxx_x86_64': No such file or directory

    Ursache -- die Quell-Datei existierte garnicht. alles andere war eher unbedeutend und oberflächlich -- aber nicht dem Problem zugewand.


    Im Gespräch antwortete ich auch die Frage der Hardware: ja, ich habe den RAM erweitert.

    Daraufhin wurde der Support beendet -- da ich Änderungen am System vorgenommen habe und diese nicht supportet werden.

    Das NAS läuft seit 2015 in dieser Konfiguration - ich habe jetzt noch ein M.2 auf QNAP-Karte als Cache eingebaut (auch eine Änderung der Hardware)


    Das Ticket ist geschlossen -- der Kollege teilt mir mit, das ich keinen Support erhalte....


    Ich arbeite selbst in der IT als Andendungs- und Kunden-Betreuer -- aber das darf ich mir nicht rausnehmen.

    Der Kunde hat ein Problem -- ich muss es lösen -- dafür bin ich da ...


    Aktuell habe ich 6 Tickets bei QNAP aufgegeben -- kein einziges hat irgend eine noch so kleine Hilfe zur Folge.

    Alle wurden geschlossen und ich als Kunde stehe mit allem alleine da.


    Ich muss nun alle paar Tage meinen crind neu starten, damit er nicht volläuft -- aber auch dafür lasse ich mir was einfallen.


    Ob das hier eine Diskussion wird oder nicht -- weiß ich nicht -- der Umgang des "Supports" mit dem Kunden will mir nicht in den Kopf!!!

    Die NAS-Systeme sind soweit ok -- der Support (aus meiner Sicht) -- unterirdisch -- 2/10 Punkten

    Die 2 Punkte gibts, weil ich zumindest Antworten erhalten habe.


    Ich zerbreche mir jetzt den Kopf darüber, wie ich etwas suche was sich nicht finden lässt und etwas löse, dessen Ursache ich nicht verstehe.

  • [HowTo] Letsencrypt (+Plex)

    Hallo ...


    Ich hab mich heute mal hingesetzt und mir das Letsencrypt fürs QNAP angeschaut. Da ich nun (aus aktuellem Anlass) auch den Plex mit "extern" benutze, musste es hiermit mal sein :)


    In dem firschen App-Store gibts das packet zum Download (http://qnapclub.eu/index.php?act=detail&qpkg_id=309) => einfach installieren


    Dann gehts ans Zertifikate bauen :)
    Ich zeige hier gleich den Weg über ein Script, damit es nachher gleich der crontab erledigen kann (lästige Handarbeit)


    Wenn man danch gleich mit dem Zertifikat loslegen will, hat man ein "Problem" -- die landen nämlich in /etc.
    Das ist beim ersten Reboot "futsch" und der ganze Zinober geht von vorn los.
    Also habe ich den ganzen Rassel in "/share/MD0_DATA/homes/admin/letsencrypt" gelegt.
    Dann überlegen wir uns Domain-Namen (ich hab DynDNS genommen) -- auf Router-Config und deren Settings gehe ich aber hier nicht ein.
    Jetzt sollte jeder noch eine gültige eMail-Addy haben und dann kann es ans bauen gehen...
    Wir gehen ins Verzeichnis "/share/MD0_DATA/homes/admin" und erzeugen eine neue Datei (bei mir letsencrypt.sh)



    Als erstes der Shebang

    Bash
    #!/bin/sh


    dann der Variablenblock

    Bash
    DOMAIN1='www.domain.homeip.net'                    # FQDN mit www am AnfangDOMAIN2='domain.homeip.net'                        # FQDN ohne www am AnfangWEBDIR='/share/MD0_DATA/Web'                       # Pfad zum Web-Verzeichniss auf dem NASCERTS='/share/MD0_DATA/homes/admin/letsencrypt'    # Hier kommt das Zertifikat-Gedönekens reinCPATH=${CERTS}'/live/'${DOMAIN1}                   # Dort liegen die aktriven Zertifikate (Symlinks)HOST='plex-server'                                 # So hab ich das p12 für Plex genanntPASSW='DasIsEinSuperTollesGeheimesPasswort'        # Das kann sich jeder selber ausdenkenEMAIL='empfaenger@email.com'                       # eine gültige eMail-Addy für LetsEncrypt

    Dann mus der SuchPfad im System erweitert werden

    Bash
    export PATH=/opt/LetsEncrypt/bin:$PATH


    jetzt kommt der Befehl zum erzeugen des Zertifikates (danach den Webserver rebooten)

    Bash
    letsencrypt certonly --rsa-key-size 4096 --renew-by-default --webroot --webroot-path ${WEBDIR} -d ${DOMAIN1} -d ${DOMAIN2} -t --agree-tos --config-dir ${CERTS} --email ${EMAIL}/etc/init.d/Qthttpd.sh restart


    und das P12 für Plex erzeugen...

    Bash
    openssl pkcs12 -export -in ${CPATH}'/cert.pem' -inkey ${CPATH}'/privkey.pem' -out ${CPATH}'/'${HOST}'.p12' -name ${HOST} -CAfile ${CPATH}'/chain.pem' -caname root -password pass:${PASSW}


    Jetzt sTunnel und Plex stoppen


    Bash
    /etc/init.d/stunnel.sh stop/share/MD0_DATA/.qpkg/PlexMediaServer/plex.sh stop


    und den Schlüssel kopieren

    Code
    cat ${CPATH}'/privkey.pem' ${CPATH}'/cert.pem' > /etc/stunnel/stunnel.pemcp ${CPATH}'/chain.pem' /etc/stunnel/uca.pem


    Jetzt noch die Dienste wieder starten


    Bash
    /etc/init.d/stunnel.sh start/share/MD0_DATA/.qpkg/PlexMediaServer/plex.sh start


    und das Thema ist "gegessen" ...
    Ab jetzt könnt ihr auf euer NAS und auf Plex per HTTPS ohne Zertifikatswarnung zugreifen...


    Um das ganze abzurunden, pusten wir das Script noch in den Crontab (nur 1x !!!!)

    Bash
    echo "0 3 1 * * /share/MD0_DATA/homes/admin/letsencrypt.sh" >> /etc/config/crontabcrontab /etc/config/crontab


    Ab jetzt müssen wir uns nicht mehr um das ganze Zeugs kümmern -- alles per Automatik erledigt ...




    für alle noch mal das Script im Ganzen:



    Viel Spaß damit :)

  • DHCP Server Einstellungen

    hmm ...
    ich habe da so meine "Bedenken" ...
    Die Art und Weise, wie die Supporter die Tickets "behandeln" ...
    Abwürgen => schließen ....


    Ich glaube, diese "Einsicht" muß intern erfolgen ...
    Ich habe nicht das Gefühl, dort in Taiwan irgend jemand etwas auf das Wort der Benutzer gibt

  • MYSQL / PHPMYADMIN Zugangsdaten unter 4.2

    Wenn er den "hacken" raus nimmt, is der Server abgeschottet ...
    Kein Script (auch phpMyAdmin) kann sich dann mehr am Server anmelden!!


    Suche mal in den LOG nach "verdächtigen" Hinweisen ...
    eventuell mal auf der cmd den MySQL-Server neu starten ...
    wenn er "Probleme" hat, gibt es eine Ausgabe ...
    sonst sollte in der php_error.log ein Eintrag sein, wenn ein Fehler auftritt


    #2002 deutet auf einen Fehlstart hin. Leider zeigt das Webinterface solche Fehler nicht an.
    Da hilft es nur, mal einen Blick "unter die Haube" zu werfen

  • Ordner-Aggregation in Windows 10 fehlerhaft ?

    Die Ursache von vielen Problemen ist der grenzenlos veraltete Samba, welcher nach wie vor in der QTS drin steckt.
    Der Samba wird aktuell weder von Samba, noch von M$ supportet. Nur QNAP betreibt "Leichenfledderung".
    4.0 ist out of Support! - Nachweislich!!


    Qnap schafft es nicht, die aktuelle Version zu implementieren.
    Würden sie das machen, währen glaub ich nicht wenige Probleme vom Tisch ...
    aber so --- heißt es "weiter leiden"

  • MyQnapCloud Verbindung geht nicht

    Nein leider nicht ....
    Das hat den Grund, das diese Anwendungen an den internen Webserver gebunden sind.
    Das System sieht dafür leider keine getrennten Eigenschaften vor ...


    Ich würde aber dringend raten, auf SSL-Only umzustellen ...
    Warum das per Werks-Default nicht so ist, weiß ich nicht...


    Eventuell kann man ja die Verwaltung nur übers interne Netzwerk zugänglich machen und alle "externen" mit 404 beantworten ...
    getestet hab ich das aber noch nicht