Auswirkung von IPKG, Optware, Init Tools usw. auf die Disk-Station

[primesyn]

Hallo zusammen,

mich juckt schon die ganze Zeit folgendes Thema. Auch ich möchte jetzt das Linux der Disk-Station für andere zusätzliche Aufgaben nutzen, weil der Server sowieso immer läuft. In der Vergangenheit habe ich mich aber von den Modifikationen und die dadurch entstehenden Probleme abschrecken lassen. Seit einigen Tagen lese ich mich immer mehr ein und ich möchte den Schritt jetzt wagen.

Nur zur Info: Am Ende soll mein OpenVPN auf der Box laufen. Mit OpenVPN habe ich viel Erfahrung unter Windows, kleinere Erfahrungen unter Linux aber noch keine Erfahrung auf einer Disk-Station.

Es ist nur so, dass ich die Disk-Station produktiv nutze und es nicht so einfach ist, im Problemfall wieder zurückzugehen. Auch ist es nicht ganz so trivial, nicht offiziell unterstütze Änderungen durchzuführen. Spätestens beim nächsten DSM Update, könnten Probleme auftreten.

Was ich aus den vielen Beiträgen nicht so leicht herausbekomme, ist eine Einschätzung, was passiert, wenn ich gewisse Pakte oder Mod's einspiele. Deswegen bitte ich die Profis um Hilfe bei meinen Verständnis-Fragen!

Installation IPKG:
Ich habe mir mal so ein .xsh Script zerlegt und die enthaltenen Binärdaten extrahiert. Verstanden habe ich, dass ein temporärer IPKG den finalen IPKG installiert, Startscripte und /opt usw. anlegt. Auch habe ich verstanden warum man noch Anpassungen machen muss, damit die Box sauber booten kann.

Benötige ich die Anpassung bereits nach der IPKG Bootstrap installation? Ist bei IPKG gleich Optware mit dabei, die beim runterfahren stress macht? Macht die Box also schon nach der reinen IPKG Insatallation Stress, wenn ich nichts anpasse?
Oder beginnen die Probleme erst mit dem ersten Paket, das auch Daemons und Startscripte enthält?

Optware:
Als Optware, so habe ich es verstanden, wird alles bezeichnet, was ich per IPKG installiere. Durch den speziell angepassten IPKG landen alle Teile in dem gelinkten /opt Zweig.
Bei jeder Optware ist zu prüfen, ob diese dann start und stop Scripte für Serverdienste enthält und ob diese dann auch sauber funktionieren.
Bei OpenVPN z.B. wird das der Fall sein und beim Midnight Commander sicher nicht?

Init Tools:
Im Wiki steht, dass per IPKG die module-init-tools zu installieren sind. Das habe ich gar nicht verstanden. Warum? Habe ich danach mehrere Runlevels auf der Station und vielleicht noch mehr Stress beim booten?

Und generell: Gibt es DSM originale Dateien, die ich vor der ganzen Aktion sichern muss, weil sie verändert werden? So wie ich das bis jetzt einschätze, kommen nur welche hinzu und der /opt Link.

Viele Grüße
Christian, der noch kleine Berührungsängste hat...

 

[Matthieu]

Puh, heikle Sache. Wenn du die DS schon produktiv nutzt, würde ich ein Backup machen und dann probieren, wenn sie gerade mal jemand für ein paar Stunden, besser Tage nicht so dringend benötigt. Da hättest du im Notfall wenigstens etwas Zeit. Wie sieht es mit deinen Linux-Kenntnissen aus?
Ich persönlich hatte auch mit den Startskripten keine Probleme, aber meine IPKG-Installationen sind auch schon wieder eine Weile her.

MfG Matthieu

 

[primesyn]

Ja heikel ist das wirklich. Deswegen gehe ich da auch Schritt für Schritt vor. Backup ist vorhanden. Meine Linux-Kenntnisse werden immer besser. Seit über einem Jahr verlasse ich regelmäßig auf dem Desktop die GUI's und fuchse mich in die Internas ein. Das Hauptproblem ist eher das allgemein tiefe IT Wissen (besonders Windows) auf Linux abzubilden. Gerade bei Linux gibt es x Varianten oder Lösungen für ein und das Selbe. Jeder kocht sein eigenes Süppchen, auch Syno und das muss man erst mal verstehen, um keine Probleme zu bekommen. Deswegen geht mir es ja um die Einschätzung der Tragweite jeglicher nicht offizieller Änderung.

Meine DS411+ DSM3.1 ist jetzt mit dem i686 IPKG Paket versorgt und die anschließenden Modifikationen habe ich auch durchgeführt. Der Filesystemvergleich vorher (DSM-Original) und nachher zeigte, dass nur die /etc/profile modifiziert wird. Da werden eigentlich nur die bin Verzeichnisse aus dem /opt Zweig im Pfad vorne angestellt. Der Rest kommt zusätzlich ins Dateisystem.

Dann habe ich noch herausgefunden, dass der IPKG selber ja eigentlich nur ein Monster-Script ist und die Pakete eigentlich tar.gz Container mit Software und Steuerscripten sind. Im Prinzip kann man sich das alles vorher entpacken, inspizieren und versuchen zu verstehen.

Bedingt durch die Pfadreihenfolge, dass Optware bevorzugt ausgeführt wird, könnten doch Probleme mit den Syno internen Funktionen auftreten? Ist da was bekannt? Die Syno internen Funktionen arbeiten ja normalerweise mit dem abgespeckten Umfang der BusyBox. Nicht das es auf einmal Probleme gibt, weil plötzlich die volle Version vorhanden ist.
Angeblich gibt's Probleme mit wget und DSM 3.1. Bei mir läuft aber alles und im i686 IPKG Bootstrap war auch opware wget dabei.

Aufpassen muss man auch mit den Paketabhängigkeiten. Da kommen schnell einige Pakete zusammen, die dann wiederum die Busybox-Varianten in den Hintergrund drücken.

Das mit den module-init-tools habe ich falsch interpretiert. Die enthalten die Befehle zur Kernelmodul-Administration.

Im Prinzip muss man jedes Paket vorher genau untersuchen. Dazu gehört noch viel Hintergrundwissen, wie das Linux von Syno und die ganzen DSM Funktionen arbeiten.

Fakt ist, dass eine reine IPKG Installation erst mal unproblematisch ist. Sie legt den ganzen /opt Zweig an, packt IPKG selbst dort hinein. Als Optware ist dann wget mit dabei, jedoch noch keine Startscripte unter /opt. Damit Startscripte, die sich unter /opt befinden, laufen können, werden bei der IPKG Installation zusätzlich /etc/rc.local und rc.optware eingefügt. Diese behandeln jedoch, wie so oft hier diskutiert, die evtl. später hinzukommenden optware rc Scripte ziemlich unprofessionell. Wenn man nach dem Wiki vorgeht, lässt sich das alles korrigieren. Das deutsche Wiki ist hier auch detaillierter als das englische.

Wer weiß noch was zu dem Thema, wo muss man noch aufpassen?

 

[jahlives]

Damit Startscripte, die sich unter /opt befinden, laufen können, werden bei der IPKG Installation zusätzlich /etc/rc.local und rc.optware eingefügt.

ist das so? Wäre mir noch nie aufgefallen. Diese Scripte liegen normalerweise alle in /opt/etc/init.d und ein Script in /etc ruft sie nacheinander auf.

 

[itari]

Also ich hab keine große Ahnung von der IPKG-Installation und von dem Aufbau der Pakete. Ich benutze das IPKG als Blackbox, welche mir irgendwas ins /opt installiert, was ich dann nutzen kann. Wenn ich so eine DS tatsächlich produktiv nutzen müsste, würde ich mir eine kleine DS zusätzlich zum Ausprobieren anschaffen, weil mir sonst der Stress zu groß wäre.

Itari

 

[goetz]

Hallo,
an einem Produktivsystem würde ich keinen VPN Server aufsetzen. Es gibt da andere Möglichkeiten
- Router mit integr. VPN Server, dann braucht man auch keine Weiterleitungen
- separate Hardware dafür, Shevaplug, Pogoplug, Dockstar, DS111j (kann dann auch zum Backup dienen) usw.

Gruß Götz

 

[primesyn]

ist das so? Wäre mir noch nie aufgefallen. Diese Scripte liegen normalerweise alle in /opt/etc/init.d und ein Script in /etc ruft sie nacheinander auf.

Ja das ist so. Die Optware rc Scripte liegen auch alle unter /opt/etc/init.d . Bei einem originalen DSM gibt es noch kein /etc/rc.local und rc.optware. Erst der IPKG Bootstarp legt die an. rc.local wird automatisch beim booten abgearbeitet, weil das im DSM enthaltene /etc/rc Script es am Ende aufruft, wenn es existiert. rc.local ruft übrigens nur das schlechte rc.optware auf. Im Wiki ist ja erklärt, dass man das auskommentieren soll. Stattdessen kommt das bessere optware.sh aus dem Wiki nach /usr/local... Die rc Scripte aus dem /usr/local Pfad werden übrigens auch von Haus aus vom DSM /etc/rc ausgeführt.
Vielleicht war das früher mal anders? Ich habe mit DSM 3.0 begonnen in bin seit letzter Woche auf 3.1.

@Götz: Ja Du hast Recht wegen OpenVPN. Es gibt viele Argumente, es anders zu tun. Vorerst soll es erst mal auf der DS laufen. In dem Thread geht es mir primär allgemein um die Modifikation der DS.

@Itari: Ne Testbox wäre schon ganz fein. Solange auch alles unter /opt landet, kann man es auch problemlos wieder löschen. Gefährlich werden können evtl. Pakete die sich auch außerhalb einnisten oder durch Abhängigkeiten weitere binaries mitbringen, die dann bevorzugt verwendet werden. Evtl. verhalten die sich anders? Allein schon, weil eine anderer Versionsstand existiert?

VG Christian

 

[itari]

Gefährlich werden können evtl. Pakete die sich auch außerhalb einnisten oder durch Abhängigkeiten weitere binaries mitbringen, die dann bevorzugt verwendet werden. Evtl. verhalten die sich anders? Allein schon, weil eine anderer Versionsstand existiert?

Davon hab ich noch nie etwas gelesen; scheint also alles sauber zu sein. Und Kernelmoduel musste eh manuell einbinden.

Itari