Updatefehler

  • Ich hatte das selbe Problem mit Ubuntu 18.04.2 LTS.

    Code
    Can't locate DebianLinux.pm in @INC (you may need to install the DebianLinux module) (@INC contains: /usr/local/pd-admin2/lib/perl5/site_perl/5.22.1/x86_64-linux /usr/local/pd-admin2/lib/perl5/site_perl/5.22.1 /usr/local/pd-admin2/lib/perl5/5.22.1/x86_64-linux /usr/local/pd-admin2/lib/perl5/5.22.1 /usr/local/pd-admin2/lib/perl5/site_perl/5.22.1/x86_64-linux /usr/local/pd-admin2/lib/perl5/site_perl/5.22.1 /usr/local/pd-admin2/lib/perl5/site_perl .) at /usr/bin/linux-update-symlinks line 24.
    BEGIN failed--compilation aborted at /usr/bin/linux-update-symlinks line 24.


    Habe das Perl von pd-admin mit dem System Perl ersetzt.


    Code
    root@vienna:~# ls -la /usr/bin/perl
    lrwxrwxrwx 1 root root 29 Apr 24 10:52 /usr/bin/perl -> /usr/local/pd-admin2/bin/perl
    root@vienna:~# ls -la /usr/local/bin/perl
    lrwxrwxrwx 1 root root 29 Apr 24 10:52 /usr/local/bin/perl -> /usr/local/pd-admin2/bin/perl


    Jetzt geht es wieder...

  • ich hatte auch das Problem. Leider hat mir das zuvor nicht richtig weiter geholfen. Hier nochmal mein Lösungsversuch:


    Problem ist ja das DebianLinux.pm nicht gefunden wird.

    Bei mir liegt diese Datei in /usr/share/perl5/DebianLinux.pm und ist damit nicht im Perl aus der SE enthalten sondern nur im systemeigenen Perl. Dieses wurde durch die SE nach /usr/bin/perl__ verschoben und durch einen link auf /usr/bin/perl -> /usr/local/pd-admin2/bin/perl ersetzt.


    Meine Lösung:


    Code
    # Kopie von /usr/bin/perl anlegen (braucht man eigentlich nicht da es sowieso nur ein symlink ist): 
    mv /usr/bin/perl /usr/bin/perl.pd
    
    
    # neuen symlink auf das systemeigene perl setzen
    ln -l /usr/bin/perl__ /usr/bin/perl



    so kann man es jederzeit wieder rückgängig machen.

    ggf. zieckt SE oder PD mit diesem Perl rum

  • Das Problem ist doch bestimmt schon eine Dekade bekannt. Entweder kann oder will Herr Bradler das problem nicht beheben, ich vermute eher will, so wie andere seit Jahren bekannten Probleme …


    Herr Bradler, sie sollten entweder

    • wenn ihn die Zeit fehlt, das Produkt verkaufen, freigeben, einstampfen, …
    • sie das produkt weiterführen möchte, das Produkt jedoch nicht finanziert ist, eine neue Bezahlversion rausbringen
    • oder was weiß ich, die Ignoranz Fehler zu beheben nervt nur noch :rolleyes:
  • Das Problem ist doch bestimmt schon eine Dekade bekannt. Entweder kann oder will Herr Bradler das problem nicht beheben, ich vermute eher will, so wie andere seit Jahren bekannten Probleme …


    Herr Bradler, sie sollten entweder

    • wenn ihn die Zeit fehlt, das Produkt verkaufen, freigeben, einstampfen, …
    • sie das produkt weiterführen möchte, das Produkt jedoch nicht finanziert ist, eine neue Bezahlversion rausbringen
    • oder was weiß ich, die Ignoranz Fehler zu beheben nervt nur noch :rolleyes:

    Ich kann die Unmutsäußerung ja verstehen, aber sie ist nicht fair.

    Ich kenne kein anderes Unternehmen, das über Jahre regelmäßig Updates herausgebracht hat und Anregungen aus dem Forum (ob zeitnah oder nicht) berücksichtigt hat.


    Am Ende des Tages wird Herr Bradler und sein Team auch nicht mehr arbeiten können als Zeit da ist.

    Ich für meinen Teil führe am Ende eines jeden Updates der SE-Umgebung mein eigenes Bereinigungsskript aus, das gewisse Spezialitäten der jeweiligen Distribution wieder ausbügelt. So werden im Rahmen von Updates auf CentOS Systeme gerne noch mehr Dateien ausgetauscht oder erstellt.

    Beispielsweise prüft mein Bereinigungsskript neben dem Perl Link auch immer, ob Centos mal wieder eine my.cnf in /etc angelegt hat, was auch zu einem Nicht-Funktionieren der SE Umgebung führt, da MySql scheinbar immer zunächst dort nach einer Konfigurationsdatei sucht.

    Des Weiteren prüfe ich noch einige Sachen im /opt/pd-admin Verzeichnis.

    Damit und mit den regelmäßigen Updates de SE-Umgebung bin ich bis jetzt immer problemlos zurechtgekommen.

    • Offizieller Beitrag

    pd-admin ist spitze für mich. Bei anderen Hostingpanels wird mir schon schlecht wenn ich nur die Installationsanleitung lese, mir sind die viel zu aufgeblasen. Zudem ist der Preis sowas von fair, ich bin da sehr dankbar dafür. Außerdem gefällt mir, dass wir mit so einem weniger populären Produkt (wenn ich das mal so sagen darf) eher unterm Radar fliegen, ich möchte nicht wissen wie oft weiter verbreitete Systeme wie Plesk täglich angegriffen werden und wie es bei denen rund geht wenn mal ein Zeroday raus kommt.


    Natürlich gibt es manche Kinderkrankheiten, die wir schon sehr lange mitschleppen, aber bei welchem Produkt gibts die nicht.


    Zudem sollte man bei konkreten Vorwürfen in Richtung des Herstellers hier in diesem Forum auch immer bedenken dass dies kein offizielles Supportforum ist. Also Herr Bradler ist nicht verpflichtet uns hier Frage und Antwort zu stehen.

  • Code
    # neuen symlink auf das systemeigene perl setzen
    ln -l /usr/bin/perl__ /usr/bin/perl


    Vielen Dank!

    Wir hatten das Problem unter Debian 11 auch, /sr/bin/perl auf /usr/bin/perl__ zeigen zu lassen hat funktioniert.
    ln -l gibt's allerdings nicht, entweder meintest du ln -L, in unserem Fall hat aber ln -s auch gereicht.
    https://man7.org/linux/man-pages/man1/ln.1.html

    /usr/local/pd-admin2/bin/perl ist btw perl v5.22.1 und /usr/local/perl__ v5.32.1, sollte das mal jemandem beim Debuggen helfen.

  • Auch wenn der Thread schon recht alt ist die Frage:


    Was ist denn der Sinn, dass die SE /usr/local/bin/perl und /usr/bin/perl auf /usr/local/pd-admin2/bin/perl umbiegt?

    Und kann man _beide_ links wieder bedenkenlos auf das System Perl umbiegen?

    Konkret geht es bei mir hier um Munin, was diverse Module braucht, die im SE Perld nicht enthalten sind.