Ankündigung

Einklappen
Keine Ankündigung bisher.

- √ - Autostart von EIBD mit Debian Squeeze

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    - √ - Autostart von EIBD mit Debian Squeeze

    Guten Abend

    Folgende Ausgangslage:
    ALIX1D mit Debian Lenny 5.0.8 und EIBD 0.0.5. Funktioniert wunderbar, inkl. Autostart. Ein kleiner Schönheitsfehler ist höchstens die Warnung beim Booten, EIBD solle nicht als root gestartet werden. Ist mir erstmal egal, funktioniert trotzdem.

    Jetzt selbe HW aber mit Debian Squeeze 6.0.1a und EIBD 0.0.5. Funktioniert auch alles wunderbar, nur der Autostart nicht. Das Startscript habe ich von der Lenny Installation. Manuell starten per init script klappt einwandfrei (abgesehen von der root Warnung), aber der EIBD will ums sterben nicht autostarten. Ich hab's mit allen mir bekannten Tricks versucht, z.B. per webmin, update-rc.d, insserv und noch ein paar Tools. Manuell habe ich die symbolischen Links in den rc*.d Ordnern auch mal gesetzt. Immer das gleiche Spiel.
    Ich habe das in letzter Zeit mal auf verschiedenen Plattformen und Linux Versionen versucht. Jedesmal war das ein Aufwand, den Autostart hinzubekommen. Bis auf einmal. Das war bei lenny. Da hat "update-rc.d eibd defaults" gereicht und alles war gut.
    Gibt es da kein Patentrezept, wie man das SICHER hinbekommt? Woran liegt das eigentlich genau, dass der EIBD beim Autostart häufig zickt?

    Ich habe beim Googeln einen Thread im Debianforum gefunden, der exakt das selbe Problem behandelt, aber im entscheidenden Moment kam dort kein Beitrag mehr.

    Kann mir da jemand helfen? Ich schick auch gerne kilobyteweise scripts, logs, etc.

    Danke, Martin

    #2
    Init-script sieht wie aus (oder ist es meins? )
    "update-rc.d eibd defaults" ist unverändert richtig, auch mit squeeze..

    Makki
    EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
    -> Bitte KEINE PNs!

    Kommentar


      #3
      Moin Moin

      Hier mal das Startscript:
      Code:
      #! /bin/sh
      ### BEGIN INIT INFO
      # Provides:          EIBD
      # Required-Start:    $remote_fs
      # Required-Stop:     $remote_fs
      # Default-Start:     2 3 4 5
      # Default-Stop:      0 1 6
      # Short-Description: Start EIB-Daemon
      # Description:       This file is used to start the EIB-Daemon during system startup.
      #                    It should be placed in /etc/init.d.
      ### END INIT INFO
      
      # Author:
      #
      # Please remove the "Author" lines above and replace them
      # with your own name if you copy and modify this script.
      
      # Do NOT "set -e"
      
      # PATH should only include /usr/* if it runs after the mountnfs.sh script
      PATH=/sbin:/usr/sbin:/bin:/usr/bin
      DESC="EIB/KNX network stack"
      NAME=eibd
      DAEMON=/usr/bin/$NAME
      DAEMON_ARGS="-D -T -S -d -i --pid-file=/var/run/eibd.pid ipt:192.168.178.39"
      PIDFILE=/var/run/$NAME.pid
      SCRIPTNAME=/etc/init.d/$NAME
      sleep 5
      # Exit if the package is not installed
      [ -x "$DAEMON" ] || exit 0
      
      # Read configuration variable file if it is present
      [ -r /etc/default/$NAME ] && . /etc/default/$NAME
      
      # Load the VERBOSE setting and other rcS variables
      . /lib/init/vars.sh
      
      # Define LSB log_* functions.
      # Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
      . /lib/lsb/init-functions
      
      #
      # Function that starts the daemon/service
      #
      do_start()
      {
          # Return
          #   0 if daemon has been started
          #   1 if daemon was already running
          #   2 if daemon could not be started
          start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
              || return 1
          start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
              $DAEMON_ARGS \
              || return 2
          # Add code here, if necessary, that waits for the process to be ready
          # to handle requests from services started subsequently which depend
          # on this one.  As a last resort, sleep for some time.
      }
      
      #
      # Function that stops the daemon/service
      #
      do_stop()
      {
          # Return
          #   0 if daemon has been stopped
          #   1 if daemon was already stopped
          #   2 if daemon could not be stopped
          #   other if a failure occurred
          start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
          RETVAL="$?"
          [ "$RETVAL" = 2 ] && return 2
          # Wait for children to finish too if this is a daemon that forks
          # and if the daemon is only ever run from this initscript.
          # If the above conditions are not satisfied then add some other code
          # that waits for the process to drop all resources that could be
          # needed by services started subsequently.  A last resort is to
          # sleep for some time.
          start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
          [ "$?" = 2 ] && return 2
          # Many daemons don't delete their pidfiles when they exit.
          rm -f $PIDFILE
          return "$RETVAL"
      }
      
      #
      # Function that sends a SIGHUP to the daemon/service
      #
      do_reload() {
          #
          # If the daemon can reload its configuration without
          # restarting (for example, when it is sent a SIGHUP),
          # then implement that here.
          #
          start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
          return 0
      }
      
      case "$1" in
        start)
          [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
          do_start
          case "$?" in
              0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
              2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
          esac
          ;;
        stop)
          [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
          do_stop
          case "$?" in
              0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
              2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
          esac
          ;;
        #reload|force-reload)
          #
          # If do_reload() is not implemented then leave this commented out
          # and leave 'force-reload' as an alias for 'restart'.
          #
          #log_daemon_msg "Reloading $DESC" "$NAME"
          #do_reload
          #log_end_msg $?
          #;;
        restart|force-reload)
          #
          # If the "reload" option is implemented then remove the
          # 'force-reload' alias
          #
          log_daemon_msg "Restarting $DESC" "$NAME"
          do_stop
          case "$?" in
            0|1)
              do_start
              case "$?" in
                  0) log_end_msg 0 ;;
                  1) log_end_msg 1 ;; # Old process is still running
                  *) log_end_msg 1 ;; # Failed to start
              esac
              ;;
            *)
                # Failed to stop
              log_end_msg 1
              ;;
          esac
          ;;
        *)
          #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
          echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
          exit 3
          ;;
      esac
      
      :
      Ich habe heute Nacht auch mal wieder eine Lösung gefunden. Steht im Script schon drin: sleep 5 gleich nach SCRIPTNAME=...
      Ich würde trotzdem gerne verstehen, worauf genau der EIBD warten muss, damit das sicher klappt. Die "Nicht als root starten" Warnung ist sogar recht nützlich, weil man daran sieht, dass der EIBD ohne das sleep Kommando sehr wohl startet, sich dann aber ohne jegliche weitere Meldung wieder beendet. Ich habe auch mal stdout und error vom EIBD in Dateien umgeleitet. stdout ist danach leer, error enthält genau die bekannte Warnung "W00000001: EIBD should not run as root". Hilft mir also auch nicht weiter. In /var/log/ habe ich auch nichts gefunden.
      Kann man beim EIBD Aufruf mit --error=<waskommtdarein?> und/oder --trace=<undhier?> oder sonstwie dafür sorgen, dass man mitbekommt WARUM er sich wieder beendet hat?

      Gruß, Martin

      Kommentar


        #4
        Hallo Martin,

        Zitat von Sipple Beitrag anzeigen
        Ich habe heute Nacht auch mal wieder eine Lösung gefunden. Steht im Script schon drin: sleep 5 gleich nach SCRIPTNAME=...
        Ich würde trotzdem gerne verstehen, worauf genau der EIBD warten muss, damit das sicher klappt.
        Bin bei Ubuntu 10.10 über ein ähnliches Problem gestolpert.
        Bei mir reichte ein sleep 1.
        Ich häng mit einer TPUART am Bus.
        Ist ein reines Bauchgefühl, aber ich glaub, dass die serielle Schnittstelle mit ihrer Initialisierung noch nicht fertig ist und man deshalb einen sleep braucht.
        Ciao
        Olaf
        Nichts ist so gerecht verteilt, wie der Verstand.
        Jeder meint, genug davon zu haben.

        Kommentar


          #5
          Zitat von dundee Beitrag anzeigen
          Ich häng mit einer TPUART am Bus.
          Ist ein reines Bauchgefühl, aber ich glaub, dass die serielle Schnittstelle mit ihrer Initialisierung noch nicht fertig ist und man deshalb einen sleep braucht.
          Glaube ich eher nicht.

          Das Skript hat kein Dependency zum Netzwerk deklariert - der KNXnet/IP Server braucht aber ein Netzwerk. Zur Eingrenzung würde ich es ohne aktivierten KNXnet/IP Server probieren.

          Für mehr Infos müßte man den eibd mit -t1023 starten.

          Kommentar


            #6
            Denke auch das es das ist, bei mir steht da:
            # Required-Start: $local_fs $remote_fs $network

            und danach update-rc.d ..

            Makki
            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
            -> Bitte KEINE PNs!

            Kommentar


              #7
              Danke Euch allen.
              Das kommt der Sache näher. Werde ich die Tage mal alles versuchen.
              Die Schnittstelle (IP Tunneling) kanns eigentlich nicht sein, dann müsste das ja auch passieren wenn ich später manuell starte.

              Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet? Ich habe mir meines dahingehend geändert, der EIBD startet auch mit der anderen userid, aber er wird anscheinend nicht in den Hintergrund geschoben. D.h., der Bootvorgang wird bei laufendem EIBD unterbrochen. Ich kann dann nur noch per Putty auf den Server, die Standardkonsole hängt bis ich dort CTRL-C drücke oder den Prozess über Putty kille. Dann fliegt der EIBD wieder raus und das Booten geht weiter. Ist bestimmt nur ne Winzigkeit. Dann könnte ich mal vergleichen.

              Gruß, Martin

              Kommentar


                #8
                Zitat von Sipple Beitrag anzeigen
                Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet? Ich habe mir meines dahingehend geändert, der EIBD startet auch mit der anderen userid, aber er wird anscheinend nicht in den Hintergrund geschoben. D.h., der Bootvorgang wird bei laufendem EIBD unterbrochen. Ich kann dann nur noch per Putty auf den Server, die Standardkonsole hängt bis ich dort CTRL-C drücke oder den Prozess über Putty kille. Dann fliegt der EIBD wieder raus und das Booten geht weiter. Ist bestimmt nur ne Winzigkeit. Dann könnte ich mal vergleichen.
                Dann wird die -d Option an den EIBD wahrscheinlich nicht übergeben.
                Ansich sollte es kein Problem sein - bei der Verwendung von start-stop-daemon (wie im oben angeführten Skript) müßte man einfach nur --chuid und --group angeben.

                Kommentar


                  #9
                  Zitat von Sipple Beitrag anzeigen
                  Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet?
                  Leider nein, ich bevorzuge ein "chmod a+rw /tmp/eib" nach dem starten im Init-script..
                  Ich bin security-freak aber sehe auch ehrlichgesagt wenig Sinn darin. KNX ist nunmal "by design" völlig Sicherheitsfrei (ob das nun so gut ist, stünde auf einem anderen Blatt..)

                  Hier ist IMHO nun nicht der Punkt, damit (security) anzufangen, um etwas sicherer zu machen als es jemals sein kann.
                  Indem man z.B. lokale unix-user aussperrt wo im Regelfall jeder im LAN sowieso Vollzugriff hat leuchtet mir wenig ein, das user/chmod-gefummel nervt IMHO nur

                  Makki
                  EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                  -> Bitte KEINE PNs!

                  Kommentar


                    #10
                    Wenn wir schon dabei sind: Hätte mal jemand ein funktionierendes Script zur Hand, was den EIBD nicht als root startet?
                    Ich hätte eins für Suse, aber eigentlich sollte es doch reichen im Skript bei start-stop-daemon den User mit dem Parameter -c anzugeben. Die user muß natürlich existieren und passende Rechte haben.

                    Den Sinn darin sehe ich auch nicht so sehr im Einschränken des Zugriffs auf den Eibd sondern mehr im Schutz des Rechners bei einer potentiellen Sicherheitslücke im eibd. Ob das zu Hause im privaten Netzwerk nötig ist, sei mal dahin gestellt.

                    Grundsätzlich gebe ich Makki aber recht, mich nervt es auch wenn SW meint mich in der Beziehung bevormunden zu müssen.

                    Kommentar


                      #11
                      Ich fühle mich gerade danach das als paranoider näher zu begründen aber wie soll ich es sagen (bei vielem anderen würde ich genau zum gegenteil votieren!)
                      Ich versuchs mal:

                      1) hat der eibd keine solch gravierenden Lücken, weil er sehr sauber gemacht ist
                      2) selbst wenn, ist es sehr unwahrscheinlich das man damit mehr als einen absturz desselben herbeiführen kann
                      3) diesen eibd (bzw. EIB/KNX im allgemeinen) so ins Internet oder andere öffentliche Netze "durchzuschalten" verbietet sich von alleine. Wer das macht ist - mit Verlaub - irre.. Hier ist ein VPN zwingend angesagt, das erzwingt aber nicht der eibd sondern schlicht EIB/KNX
                      4) wenn also jemand "böses" an den Rechner mit dem eibd überhaupt irgendwie per IP rankommt, hat man eh schon ein fettes Problem!
                      4a) und der soll dann mittels eines noch unbekannten exploits die root-Rechte des eibd ausnutzen ?
                      5) was kann der Angreifer mit dem root-exploit dann anfangen? die Familienfotos vom heimischen NAS lesen (wenn der eibd darauf läuft) - wiegesagt: sowas wie der KNX muss wegen dem fehlen jeglicher Sicherheitsgedanken eh komplett gekapselt/abgeschottet werden (Vlan, Firewall, VPN, whatever)

                      Natürlich ist aus hehren Security-Gedanken heraus besser, jeglichen Angriffspunkt zu vermeiden bevor er entsteht und es gleich richtig zu machen. Also, läuft nicht als root usw. In Anbetracht der Kernkompetenz des eibd stellen sich aber die Fragen 1-5
                      Also wenn jemand nur IP-mässig Zugriff auf den Rechner hat, auf dem der eibd läuft hat man ja eh schon verloren (falls der eib ohne -i -T.. läuft ist es auch egal)

                      An diesem Punkt bin ich jedenfalls der Meinung das man Anwender nicht mit security ärgern muss, wo eh keine ist. Viel wichtiger ist den Umstand zu beschreiben, warum das bei KNXnet/IP eben komplett flachfällt ("Ach es kennt doch keiner meine Dyndns-IP" )

                      Makki
                      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                      -> Bitte KEINE PNs!

                      Kommentar


                        #12
                        Zitat von makki Beitrag anzeigen
                        Leider nein, ich bevorzuge ein "chmod a+rw /tmp/eib" nach dem starten im Init-script..
                        EIBD beachtet die umask für alle im Dateisystem angelegten Objekte. Mit zB "umask 000" im Startskript kann man den Default (in den meisten Linux Distributionen, das nur der User schreiben darf) ändern.

                        Kommentar


                          #13
                          Zitat von makki Beitrag anzeigen
                          1) hat der eibd keine solch gravierenden Lücken, weil er sehr sauber gemacht ist
                          2) selbst wenn, ist es sehr unwahrscheinlich das man damit mehr als einen absturz desselben herbeiführen kann
                          Ich würde mich nicht trauen, solche Aussagen zu machen Von mir gibt es jedenfalls keine solche Garantie und ich zweifle, das jemand mit entsprechenden Wissen einen richtigen Code-Audit vom eibd gemacht hat.

                          Ich bin ein Verfechter von guten Sicherheitskonzepten, deshalb gilt:
                          EIBD sollte nicht als root laufen. Eine Verwendungs als root macht für mich nur Sinn für kurze Zeit zum Fehlersuchen, deshalb gibt es die Warnung in der 0.0.5er Version.

                          Kommentar


                            #14
                            Zitat von mkoegler Beitrag anzeigen
                            Ich würde mich nicht trauen, solche Aussagen zu machen
                            Ach doch, ich schon
                            Ich hab jetzt ein paar Tage IT-Erfahrung und der ganze EIB/KNX hat echt ganz andere Security-Probleme - die völlig ausserhalb der Sphäre des eibd liegen - als das man sich da im Detail jetzt einen Kopf um User-rechte machen müsste..
                            Irgendein schlauer Kopf hat mal gesagt "Man muss keine Eier legen können, um fähig zu sein faule zu erkennen" (o.ä.) Ich kann keine solchen Eier legen, aber der eibd ist kein faules, das kann ich erkennen

                            Ich bin ein Verfechter von guten Sicherheitskonzepten, deshalb gilt:
                            Grundsätzlich d'accord, man kann es auch gleich richtig machen anstatt auf das Problem zu warten.

                            In diesem Fall ist es nur so, das ich mal behaupte, das mind. 50% der eibd-Einsteiger Linux Neulinge sind und security eh keine Rolle (s.o.) spielt, es ärgert nur. Es gibt ja (von dem grottigen Falcon mal abgesehen) eh nichts anderes an Alternative.
                            Denen würde es glaube ich helfen, wenn es nach einem rudimentären Linux-Grundkurs, wget+ dpkg es nun einfach mal funktioniert, wenigstens auf einem Debian&Co. Also ein Init-Script sollte her.. (schreib ich gerne!)

                            Aber da würde ich halt chmod a+rw.. reinschreiben, Debians hehre security usw hin oder her, umask, ganz ehrlich, lese ich nach 15J Linux hier zum ersten mal bewusst!
                            Also wie soll das ein durchschnittlich begabter Quereinsteieger blicken, der gerade mal so ein Debian in der VM ans laufen bekommt?
                            Dem erklärt man dann, das der eibd erst in Gruppe X muss damit dann der Webserver Y und User Z - dieser hinzugefügt - damit er auch was damit anfangen kann?
                            Ehrlich: Keine Chance! Das muss wenn dann das .deb alleine machen, den user, die Gruppe anlegen und die Gruppe admin sowie www-data hinzufügen. Das interessiert keinen Anwender warum und wieso der daemon a in Gruppe b sein sollte (ich spiel jetzt mal den Anwender-Anwalt..)
                            Und das ist übrigens IMHO auch der Grund warum es ein Ubuntu binnen kürzerster Zeit zur erfolgreichsten Desktop-distro gebracht hat: weil es Anwender eben nicht mit so einem Käse wie unnötiger security nervt aber totzdem sicher bleibt

                            Ergo: Die Warnung "eibd should not..root" -> Ok. Aber dann muss das .deb dafür sorgen das es nicht so ist und trotzdem funktioniert

                            Makki

                            P.S.: Sorry, ja ich bin meist sehr direkt, bitte nicht persönlich nehmen..
                            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                            -> Bitte KEINE PNs!

                            Kommentar


                              #15
                              Ergo: Die Warnung "eibd should not..root" -> Ok. Aber dann muss das .deb dafür sorgen das es nicht so ist und trotzdem funktioniert
                              Möchte ich so mal deutlich unterstützen. Wir verkaufen das WG mit dem eibd und TPUART auch an gewerbliche Kunden weiter und da lebt es sich einfach ruhiger, wenn man weiß, anerkannte security Regeln werden eingehalten, auch wenn es im Einzelfall übertrieben erscheint. Trotz meiner eher bescheidenen LINUX-Kenntnisse möchte ich dem Kunden ein zuverlässsiges und sicheres Gerät verkaufen können.

                              Wie ist ist das nun beim originären WG mit dem root-user und dem eibd ?

                              Gruß Micha

                              Kommentar

                              Lädt...
                              X