Loading ...
Sorry, an error occurred while loading the content.

Samba upgrade installs xinted: no telnet nor SWAT after this

Expand Messages
  • doll_oliver
    Version: V2.3R63-uNSLUng-6.8-beta USB Port 1: Ready, 729MB (52% Free) [1 GB USB-Stick] USB Port 2: Ready, 469220MB (1% Free) [500 GB Maxtor One-Touch]
    Message 1 of 30 , Jul 7, 2008
    • 0 Attachment
      Version: V2.3R63-uNSLUng-6.8-beta
      USB Port 1: Ready, 729MB (52% Free) [1 GB USB-Stick]
      USB Port 2: Ready, 469220MB (1% Free) [500 GB Maxtor One-Touch]
      uNSLUng status: Unslung to disk1, /dev/sdb1

      All,

      since a couple of week I run into the issue that after the upgrade of
      packages Samba was still working, but I could no longer log into my
      Slug with telnet nor was SWAT working any longer.

      In the meantime I think I traced it down by installing all packages
      individually but Samba.

      Though xinted isn't installed yet on my SLUG (should I - why?)

      # ipkg remove xinetd
      No packages removed.
      Nothing to be done

      the upgrade of Samba seems to trigger the installation of xinetd
      causing the trouble:

      # ipkg -test upgrade
      Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
      Downloading
      http://ipkg.nslu2-linux.org/feeds/optware/nslu2/cross/stable/samba_3.2.0-1_armeb.ipk
      Installing xinetd (2.3.14-7) to root...
      Downloading
      http://ipkg.nslu2-linux.org/feeds/optware/nslu2/cross/stable/xinetd_2.3.14-7_armeb.ipk
      Nothing to be done

      Any hint what may go wrong here?
      --
      tnx & cheers
      Oliver
    • Robert Hammond
      In message , doll_oliver writes ... Xinetd seems to be a perquisite for Samba 3, I think it is needed for
      Message 2 of 30 , Jul 7, 2008
      • 0 Attachment
        In message <g4tqek+81oe@...>, doll_oliver
        <doll_oliver@...> writes
        >Version: V2.3R63-uNSLUng-6.8-beta
        >USB Port 1: Ready, 729MB (52% Free) [1 GB USB-Stick]
        >USB Port 2: Ready, 469220MB (1% Free) [500 GB Maxtor One-Touch]
        >uNSLUng status: Unslung to disk1, /dev/sdb1
        >
        >All,
        >
        >since a couple of week I run into the issue that after the upgrade of
        >packages Samba was still working, but I could no longer log into my
        >Slug with telnet nor was SWAT working any longer.
        >
        >In the meantime I think I traced it down by installing all packages
        >individually but Samba.
        >
        >Though xinted isn't installed yet on my SLUG (should I - why?)
        >
        ># ipkg remove xinetd
        >No packages removed.
        >Nothing to be done
        >
        >the upgrade of Samba seems to trigger the installation of xinetd
        >causing the trouble:
        >
        ># ipkg -test upgrade
        >Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
        >Downloading
        >http://ipkg.nslu2-linux.org/feeds/optware/nslu2/cross/stable/samba_3.2.0
        >-1_armeb.ipk
        >Installing xinetd (2.3.14-7) to root...
        >Downloading
        >http://ipkg.nslu2-linux.org/feeds/optware/nslu2/cross/stable/xinetd_2.3.
        >14-7_armeb.ipk
        >Nothing to be done
        >
        >Any hint what may go wrong here?
        Xinetd seems to be a perquisite for Samba 3, I think it is needed for
        Swat. I also have mine configured to start nmbd and smbd when any
        network connection needs them (info on this in the Wiki some where).

        Telnet access is enabled by default when using Xinetd so must be
        something different with your set-up if Telnet does not work.

        Using a none standard subnet can cause this problem because Xinetd is
        pre configured to use the standard subnet. Suggest re-installing Xinetd
        and then checking the config file /opt/etc/xinetd.conf. I have changed
        mine as follows :-

        defaults
        {
        only_from = localhost 0.0.0.0/0
        instances = 60
        log_type = SYSLOG authpriv info
        log_on_success = HOST PID
        log_on_failure = HOST
        cps = 25 30
        }

        includedir /opt/etc/xinetd.d

        --
        Robert Hammond
        PGP:0x154144DA
      • Mike (mwester)
        ... You do have openssh installed, right? :) One of the big advantages of using openssh and an ssh client instead of telnet, besides the security, is that
        Message 3 of 30 , Jul 7, 2008
        • 0 Attachment
          doll_oliver wrote:
          > Version: V2.3R63-uNSLUng-6.8-beta
          > USB Port 1: Ready, 729MB (52% Free) [1 GB USB-Stick]
          > USB Port 2: Ready, 469220MB (1% Free) [500 GB Maxtor One-Touch]
          > uNSLUng status: Unslung to disk1, /dev/sdb1
          >
          > All,
          >
          > since a couple of week I run into the issue that after the upgrade of
          > packages Samba was still working, but I could no longer log into my
          > Slug with telnet nor was SWAT working any longer.

          You do have openssh installed, right? :) One of the big advantages of
          using openssh and an ssh client instead of telnet, besides the security,
          is that ssh is immune to the type of problems that you are describing --
          where something happens to pull in xinetd as a dependency, which
          inevitably results in telnetd not being able to be started, and the loss
          of connection to the Unslung NSLU2.

          Mike (mwester)
        • doll_oliver
          ... doll_oliver ... for Swat. hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and telnet) quite long time, now (Slug being my home s Windows DC)
          Message 4 of 30 , Jul 8, 2008
          • 0 Attachment
            On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
            >In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
            doll_oliver
            ><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
            >> [...]
            >># ipkg -test upgrade
            >>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
            >> [...]
            > Xinetd seems to be a perquisite for Samba 3, I think it is needed
            for Swat.

            hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
            telnet) quite long time, now (Slug being my home's Windows DC) IMO
            without xinet not having any issues!?

            >Telnet access is enabled by default when using Xinetd so must be
            >something different with your set-up if Telnet does not work.

            Indeed this is strange, esp as the output during the update tells the
            following about the xinetd config:

            "[...] to activate the samba version 3.
            Configuring xinetd
            Note that telnetd is enabled by default. Edit /opt/etc/xinetd.d/telnetd
            and set 'disable=yes' to disable telnet AFTER making sure that Dropbear
            or other means of logging onto your system are enabled and working.

            Note that only 192.168.1.0/24 has access in the default configuration"

            >Using a none standard subnet can cause this problem because Xinetd is
            >pre configured to use the standard subnet. Suggest re-installing Xinetd
            >and then checking the config file /opt/etc/xinetd.conf. I have changed
            >mine as follows :-
            >
            >defaults
            >{
            > only_from = localhost 0.0.0.0/0
            > instances = 60
            > log_type = SYSLOG authpriv info
            > log_on_success = HOST PID
            > log_on_failure = HOST
            > cps = 25 30
            >}
            >
            >includedir /opt/etc/xinetd.d

            that might be a good hint. I indeed have another public/non-RFC1918
            /24 IP range. I'll check this.

            But still the question is, why does this just pops up since a few month?
            --
            tnx & cheers
            Oliver
          • doll_oliver
            ... yes, I have, but I at least found that sometimes doing the upgrades via telnet (it s my home network ;) is more easy if an upgrade of ssh itself is in the
            Message 5 of 30 , Jul 8, 2008
            • 0 Attachment
              On Mon, 07 Jul 2008 15:22:04 -0500, "Mike (mwester)" wrote:
              > You do have openssh installed, right? :)

              yes, I have, but I at least found that sometimes doing the upgrades
              via telnet (it's my home network ;) is more easy if an upgrade of ssh
              itself is in the queue.

              > One of the big advantages of using openssh and an ssh client instead
              > of telnet, besides the security, is that ssh is immune to the type
              > of problems that you are describing

              I'm not so much abused having no telnet any longer, having no SWAT is
              what bothers me.

              > where something happens to pull in xinetd as a dependency, which
              > inevitably results in telnetd not being able to be started, and
              > the loss of connection to the Unslung NSLU2.

              And that's what I want to understand. Why and when has the xinetd
              dependency been introduced for Samba?
            • doll_oliver
              Hi Robert, ... thanks for the suggestion - I changed the IP range to all connections from everywhere as well (though localhost could be omitted then I guess as
              Message 6 of 30 , Jul 8, 2008
              • 0 Attachment
                Hi Robert,

                --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                > that might be a good hint. I indeed have another public/non-RFC1918
                > /24 IP range. I'll check this.

                thanks for the suggestion - I changed the IP range to all connections
                from everywhere as well (though localhost could be omitted then I
                guess as it's part of the 0.0.0.0/0?) and it works fine, now.

                I'm just bit concerned about the logging as I'm using an USB-Stick
                some time, now (over two years?). But ey, they are cheap these days
                and I normally have a quite up2date image of it ;-)
                --
                thx & cheers
                Oliver
              • Robert Hammond
                In message , doll_oliver writes ... Not too sure when Xinetd was added as a perquisite, perhaps from the
                Message 7 of 30 , Jul 8, 2008
                • 0 Attachment
                  In message <g4v6jm+nlo1@...>, doll_oliver
                  <doll_oliver@...> writes
                  >On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
                  >>In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
                  >doll_oliver
                  >><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
                  >>> [...]
                  >>># ipkg -test upgrade
                  >>>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                  >>> [...]
                  >> Xinetd seems to be a perquisite for Samba 3, I think it is needed
                  >for Swat.
                  >
                  >hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
                  >telnet) quite long time, now (Slug being my home's Windows DC) IMO
                  >without xinet not having any issues!?
                  >
                  >>Telnet access is enabled by default when using Xinetd so must be
                  >>something different with your set-up if Telnet does not work.
                  >
                  >Indeed this is strange, esp as the output during the update tells the
                  >following about the xinetd config:
                  >
                  >"[...] to activate the samba version 3.
                  >Configuring xinetd
                  >Note that telnetd is enabled by default. Edit /opt/etc/xinetd.d/telnetd
                  >and set 'disable=yes' to disable telnet AFTER making sure that Dropbear
                  >or other means of logging onto your system are enabled and working.
                  >
                  >Note that only 192.168.1.0/24 has access in the default configuration"
                  >
                  Not too sure when Xinetd was added as a perquisite, perhaps from the
                  latest 3.2.0 onwards??.

                  I suppose that there is a danger adding Xinetd as a perquisite to any
                  Optware package. If a user has changed from the default subnet and also
                  has no sshd installed they would effectively have no way of accessing
                  the slug if booted with the disk attached, (no doubt there are still
                  many users without the recommended sshd access). They would still be
                  able to recover by booting disk less but again users who have no sshd
                  tend to be inexperienced so recovering by booting disk less would be
                  difficult for them.

                  Perhaps the Optware Xinetd installer should be modified to either :-

                  1. Allow all subnets by setting 'only_from = localhost 0.0.0.0/0' in
                  xinetd.conf
                  or
                  2. Read the configured subnet from I think

                  /etc/sysconfig/network-scripts/ifcfg-ixp0

                  and then correct the relevant line in xinetd.conf

                  Option 1. is obviously quite easy, some users may consider allowing all
                  subnets a security problem.

                  Option 2. would involve writing a complex script perhaps using the sed
                  command plus other commands, could be quite a difficult task to write a
                  robust script that would work with all firmware versions etc.

                  My vote would be for Option 1. Regarding security, a paragraph could
                  be added to the Wiki to cover re-configuring to improve security.
                  --
                  Robert Hammond
                  PGP:0x154144DA
                • doll_oliver
                  ... I guess I shouldn t have counted my chickens before they hatched: Samba 3.2 worked fine since the upgrade, but after a reboot of the Slug it doesn t come
                  Message 8 of 30 , Jul 8, 2008
                  • 0 Attachment
                    --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                    > thanks for the suggestion - I changed the IP range to all connections
                    > from everywhere as well (though localhost could be omitted then I
                    > guess as it's part of the 0.0.0.0/0?) and it works fine, now.

                    I guess I shouldn't have counted my chickens before they hatched:

                    Samba 3.2 worked fine since the upgrade, but after a reboot of the
                    Slug it doesn't come up again

                    PID USER VSZ STAT COMMAND
                    1 root 1212 S /bin/init
                    2 root 0 SW [keventd]
                    3 root 0 RWN [ksoftirqd_CPU0]
                    4 root 0 SW [kswapd]
                    5 root 0 SW [bdflush]
                    6 root 0 SW [kupdated]
                    7 root 0 SW [mtdblockd]
                    8 root 0 SW [khubd]
                    9 root 0 SWN [jffs2_gcd_mtd4]
                    10 root 0 SW [usb-storage-0]
                    11 root 0 SW [scsi_eh_1]
                    18 root 0 SW [sd-mc-thread]
                    19 root 0 SW [usb-storage-1]
                    20 root 0 SW [scsi_eh_0]
                    30 root 0 SW [kjournald]
                    52 root 0 DW [ixp425_csr]
                    53 root 0 SW [ixp425 ixp0]
                    56 root 1916 S /bin/sh
                    57 root 1936 S /sbin/syslogd -n
                    58 root 1924 S /sbin/klogd -n
                    147 root 0 SW [kjournald]
                    161 root 0 SW [kjournald]
                    369 root 2132 S /usr/sbin/thttpd -C /etc/thttpd.conf
                    417 root 1952 S /usr/sbin/QuickSet
                    421 root 1904 S /usr/sbin/USB_Detect
                    424 root 1900 S /usr/sbin/USB_Detect
                    429 root 1884 S /usr/sbin/onetouch_detect
                    432 root 1884 S /usr/sbin/onetouch_detect
                    444 root 1296 S /usr/sbin/crond
                    450 root 1928 S /usr/sbin/CheckResetButton
                    452 root 1196 S /usr/sbin/CheckPowerButton
                    454 root 1196 S /usr/sbin/do_umount
                    517 root 6300 S /opt/sbin/nmbd -D
                    528 root 10000 S /opt/sbin/smbd -D
                    534 root 1320 S /opt/sbin/cron
                    541 root 2280 S /opt/sbin/xinetd
                    556 root 3264 S /opt/sbin/sshd
                    563 root 1552 S /opt/sbin/saslauthd -a getpwent -n 1
                    570 root 1620 S /opt/bin/rsync --daemon
                    576 root 9084 S /opt/libexec/slapd
                    583 root 9084 S /opt/libexec/slapd
                    584 root 9084 S /opt/libexec/slapd
                    596 nobody 3020 S /opt/sbin/stunnel
                    660 root 1256 S telnetd
                    661 root 1928 S -sh
                    662 root 2308 R ps

                    Also SWAT is telling me that's not running (waited all night to check
                    again this morning). So I'll switching back to my pre-xinetd backup
                    image of the stick for now :-(
                    --
                    thx & cheers
                    Oliver
                  • doll_oliver
                    ... as I come from 3.0.28a-1 without any problems without xinted it must have (obviously) happened between then (3.0.28a-1) and now (3.2.0-1) ;-) If I recall
                    Message 9 of 30 , Jul 9, 2008
                    • 0 Attachment
                      On Tue, 8 Jul 2008 21:44:57 +0100, Robert Hammond wrote:
                      > doll_oliver writes:
                      >> Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                      >
                      > Not too sure when Xinetd was added as a perquisite, perhaps from
                      > the latest 3.2.0 onwards??.

                      as I come from 3.0.28a-1 without any problems without xinted it must
                      have (obviously) happened between then (3.0.28a-1) and now (3.2.0-1) ;-)

                      If I recall correctly I think I already ran into the issue while
                      trying to update to the next release (3.0.28a-2? but I'm not sure).

                      As the reason of the misbehavior after the upgrade wasn't clear to me
                      from the beginning and as I thought it might get solved during another
                      update I delayed the troubleshooting before I had a more closely look
                      into it.

                      > I suppose that there is a danger adding Xinetd as a perquisite to
                      > any Optware package.

                      I know I keep repeating myself, but why has it been added as a
                      perquisite to Samba package as Samba version 3.0.28a-1 worked without
                      it being a perquisite!?!

                      And I know it maybe ugly: would I be able to upgrade Samba to the
                      recent version suppressing the installation of the xinetd package?
                      --
                      thx & cheers
                      Oliver
                    • doll_oliver
                      ... [...] ... I was a bit in a hurry this morning bringing back the setup into an operational state for the rest of the family before leaving home. Haven t had
                      Message 10 of 30 , Jul 9, 2008
                      • 0 Attachment
                        In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                        > Samba 3.2 worked fine since the upgrade, but after a reboot of the
                        > Slug it doesn't come up again
                        [...]
                        > So I'll switch back to my pre-xinetd backup image of the stick
                        > for now :-(

                        I was a bit in a hurry this morning bringing back the setup into an
                        operational state for the rest of the family before leaving home.

                        Haven't had time to further dig into the problem, but may I have to
                        use another start up/diversion script for Samba as xinted is a
                        prerequisite, now?
                        --
                        thx & cheers
                        Oliver
                      • Mike (mwester)
                        ... Firstly, let me just say that software pre-reqs change all the time - just watch what gets automatically added to satisfy dependencies when you do your
                        Message 11 of 30 , Jul 9, 2008
                        • 0 Attachment
                          doll_oliver wrote:
                          > In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                          >> Samba 3.2 worked fine since the upgrade, but after a reboot of the
                          >> Slug it doesn't come up again
                          > [...]
                          >> So I'll switch back to my pre-xinetd backup image of the stick
                          >> for now :-(
                          >
                          > I was a bit in a hurry this morning bringing back the setup into an
                          > operational state for the rest of the family before leaving home.
                          >
                          > Haven't had time to further dig into the problem, but may I have to
                          > use another start up/diversion script for Samba as xinted is a
                          > prerequisite, now?

                          Firstly, let me just say that software pre-reqs change all the time -
                          just watch what gets automatically added to satisfy dependencies when
                          you do your updates on your desktop Linux box. So while it probably
                          would have been nice for docs to exist on the wiki to outline this
                          change, since the wiki is a community resource I expect that nobody has
                          run into this yet, and thus it's not been documented. You'll be taking
                          care of that, right?

                          Regarding xinetd, most folks agree that's the correct way to run swat on
                          a low-memory device. If you prefer to run it as a daemon, there's no
                          reason that editing a few config files won't restore the original
                          behavior, and remove the dependency on xinetd. Some random thoughts on
                          this:

                          - if you know ahead of time that this will happen, you can do the
                          install of samba with a set of ipkg flags that will force it to skip
                          dependencies -- and thus you can avoid having the install mess up your
                          inetd on Unslung.

                          - if you have ssh, and you don't care about inetd, then you can easily
                          fix it up later. The end solution is the same for both, if it is your
                          intent to not use inetd, with the exception that if xinetd was pulled in
                          automagically, you'll want to disable starting it up by removing the
                          file in /opt/etc/init.d that starts it.

                          - the easiest way to figure out how to make the new samba work would be
                          to figure out how the original one started samba and swat -- sort
                          through those startup files and config files, install the new version,
                          and either put the original startup files in place if that's the right
                          way to do it, or fix up the new startup files to do what you want them
                          to do.

                          And finally, yes, I agree that updating your packages shouldn't break
                          things -- but it happens sometimes. I wish we had a magic "WARNING!"
                          box that ipkg could pop up for some packages, triggered by logic such as:

                          if (device_is_running_UNSLUNG) and
                          (package_or_any_dependencies matches "xinetd" or "samba"...)
                          the DISPLAY_WARNING_NOTICE

                          Until then, Unslung users will just have to note that because of
                          Unslung's unique characteristics, it is very sensitive to certain
                          packages which include samba and xinetd, and that changes that might be
                          minor on other platforms may in fact cause trouble for Unslung.

                          Mike (mwester)
                        • Brian Zhou
                          xinetd dependency was introduced between 3.0.28a-1 to 3.0.28a-2. I agree with that change. For a new user with the 192.168.1.0/24 default network, swat would
                          Message 12 of 30 , Jul 9, 2008
                          • 0 Attachment
                            xinetd dependency was introduced between 3.0.28a-1 to 3.0.28a-2.

                            I agree with that change. For a new user with the 192.168.1.0/24
                            default network, swat would just work. As Robert Hammond pointed out,
                            what needs to be improved is wiki page on xinetd, to change the
                            only_from field in /opt/etc/xinetd.conf accordingly if a subnet
                            different from 192.168.1.0/24 is used.

                            Based on nslu2-linux community rule #4 and #5, you're supposed to
                            update wiki page.

                            -Brian


                            --- In nslu2-linux@yahoogroups.com, "doll_oliver" <doll_oliver@...> wrote:
                            >
                            > On Mon, 07 Jul 2008 15:22:04 -0500, "Mike (mwester)" wrote:
                            > > You do have openssh installed, right? :)
                            >
                            > yes, I have, but I at least found that sometimes doing the upgrades
                            > via telnet (it's my home network ;) is more easy if an upgrade of ssh
                            > itself is in the queue.
                            >
                            > > One of the big advantages of using openssh and an ssh client instead
                            > > of telnet, besides the security, is that ssh is immune to the type
                            > > of problems that you are describing
                            >
                            > I'm not so much abused having no telnet any longer, having no SWAT is
                            > what bothers me.
                            >
                            > > where something happens to pull in xinetd as a dependency, which
                            > > inevitably results in telnetd not being able to be started, and
                            > > the loss of connection to the Unslung NSLU2.
                            >
                            > And that's what I want to understand. Why and when has the xinetd
                            > dependency been introduced for Samba?
                            >
                          • Brian Zhou
                            ... also ... write a ... For option 2, here is the script I come up with (tested with /bin/sh, no /opt/bin in PATH) network=`sed -n /^NETWORK/s/^.*=//p
                            Message 13 of 30 , Jul 9, 2008
                            • 0 Attachment
                              --- In nslu2-linux@yahoogroups.com, Robert Hammond <rob.hammond@...>
                              wrote:
                              >
                              > In message <g4v6jm+nlo1@...>, doll_oliver
                              > <doll_oliver@...> writes
                              > >On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
                              > >>In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
                              > >doll_oliver
                              > >><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
                              > >>> [...]
                              > >>># ipkg -test upgrade
                              > >>>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                              > >>> [...]
                              > >> Xinetd seems to be a perquisite for Samba 3, I think it is needed
                              > >for Swat.
                              > >
                              > >hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
                              > >telnet) quite long time, now (Slug being my home's Windows DC) IMO
                              > >without xinet not having any issues!?
                              > >
                              > >>Telnet access is enabled by default when using Xinetd so must be
                              > >>something different with your set-up if Telnet does not work.
                              > >
                              > >Indeed this is strange, esp as the output during the update tells the
                              > >following about the xinetd config:
                              > >
                              > >"[...] to activate the samba version 3.
                              > >Configuring xinetd
                              > >Note that telnetd is enabled by default. Edit /opt/etc/xinetd.d/telnetd
                              > >and set 'disable=yes' to disable telnet AFTER making sure that Dropbear
                              > >or other means of logging onto your system are enabled and working.
                              > >
                              > >Note that only 192.168.1.0/24 has access in the default configuration"
                              > >
                              > Not too sure when Xinetd was added as a perquisite, perhaps from the
                              > latest 3.2.0 onwards??.
                              >
                              > I suppose that there is a danger adding Xinetd as a perquisite to any
                              > Optware package. If a user has changed from the default subnet and
                              also
                              > has no sshd installed they would effectively have no way of accessing
                              > the slug if booted with the disk attached, (no doubt there are still
                              > many users without the recommended sshd access). They would still be
                              > able to recover by booting disk less but again users who have no sshd
                              > tend to be inexperienced so recovering by booting disk less would be
                              > difficult for them.
                              >
                              > Perhaps the Optware Xinetd installer should be modified to either :-
                              >
                              > 1. Allow all subnets by setting 'only_from = localhost 0.0.0.0/0' in
                              > xinetd.conf
                              > or
                              > 2. Read the configured subnet from I think
                              >
                              > /etc/sysconfig/network-scripts/ifcfg-ixp0
                              >
                              > and then correct the relevant line in xinetd.conf
                              >
                              > Option 1. is obviously quite easy, some users may consider allowing all
                              > subnets a security problem.
                              >
                              > Option 2. would involve writing a complex script perhaps using the sed
                              > command plus other commands, could be quite a difficult task to
                              write a
                              > robust script that would work with all firmware versions etc.
                              >
                              > My vote would be for Option 1. Regarding security, a paragraph could
                              > be added to the Wiki to cover re-configuring to improve security.
                              > --
                              > Robert Hammond
                              > PGP:0x154144DA
                              >

                              For option 2, here is the script I come up with (tested with /bin/sh,
                              no /opt/bin in PATH)

                              network=`sed -n '/^NETWORK/s/^.*=//p'
                              /etc/sysconfig/network-scripts/ifcfg-ixp0`
                              netmask=`sed -n '/^NETMASK/s/^.*=//p'
                              /etc/sysconfig/network-scripts/ifcfg-ixp0`

                              ones=''
                              for dec in `echo $netmask | sed 's/\./ /g'`; do
                              bin=0
                              while test $dec -gt 0; do
                              bin=`expr $bin \* 10`
                              bin=`expr $bin + $dec % 2`
                              dec=`expr $dec / 2`
                              done
                              ones="$ones`echo $bin | sed 's/0//g'`"
                              done
                              masklen=`echo $ones | awk "{print length()}"`

                              sed -i -e "/only_from/s|=.*|= localhost ${network}/${masklen}|"
                              /opt/etc/xinetd.conf


                              But the question is, should postinst be that smart?

                              -Brian
                            • doll_oliver
                              ... OK, so I remembered the release#s when I first ran into the issue correctly. ... I disagree with the introducion of a dependency with xinetd in Samba as
                              Message 14 of 30 , Jul 10, 2008
                              • 0 Attachment
                                On Wed, 09 Jul 2008 23:03:30 -0000, "Brian Zhou" wrote:
                                > xinetd dependency was introduced between 3.0.28a-1 to 3.0.28a-2.

                                OK, so I remembered the release#s when I first ran into the issue
                                correctly.

                                > I agree with that change.

                                I disagree with the introducion of a dependency with xinetd in Samba
                                as long as nobody can tell me a (good) reason for it.

                                [I'm just a simple guy using a Slug at home happy to know what an "ls"
                                does (OK maybe I know a bit more, but I'm far away being an Unix
                                expert [nor an native English speaker]). So don't be surprised when such
                                dependencies get introduced that guys like me fall into a trap without
                                knowing what's going on. But anyway:]

                                if the reason is that SWAT doesn't need so much resources if xinetd is
                                used I'd argue that once a package has been "released" with specific
                                dependencies those dependencies shouldn't be extended unless it's an
                                indispensable feature to ensure it's proper future functionality.

                                So anybody who want's to have services started by xinted is free to
                                add this feature at a later state. (And when sb does add xinetd I
                                think he should have enough background information why he does it,
                                what changes it might apply to his system and what needs to be tweaked).

                                > For a new user with the 192.168.1.0/24 default network, swat
                                > would just work. As Robert Hammond pointed out,
                                > what needs to be improved is wiki page on xinetd, to change the
                                > only_from field in /opt/etc/xinetd.conf accordingly if a subnet
                                > different from 192.168.1.0/24 is used.
                                >
                                > Based on nslu2-linux community rule #4 and #5, you're supposed to
                                > update wiki page.

                                [when talking about "you", shouldn't it have been Robert in the first
                                place adding this info. Though I'm a simple guy (as mentioned before)
                                I'm happy to add these info. But being curious and honestly I've been
                                looking for these rules: where can I find them (looked at the wiki but
                                also at the yahoo groups page)?

                                Which brings me to another thing: I at least found the rule for this
                                group:

                                "Posts deemed inappropriate: [...] End user questions about basic
                                NSLU2 settings or usage (this is not a help forum for the NSLU2 - Use
                                nslu2-general for this kind of discussion"

                                And this was the first group I tried to subscribe too but I was pushed
                                away to this group by the moderator :-P

                                "Hello, msg offtopic. Here is the correct group:
                                http://groups.yahoo.com/group/nslu2-linux/?yguid=184009766"

                                So please, since I learned that Samba comes with xinetd now (though
                                still waiting for good arguments;) and as Robert told what to change
                                in the xinted conf I'm happy to live with that change in the future.
                                But though I fixed the telnet and SWAT issue I now have the issue that
                                Samba does not start after rebooting my Slug. So I'm still lost at
                                some point.
                                --
                                tnx & cheers
                                Oliver

                                PS: while attempting to update the wiki I think it already covers the
                                topic:

                                "If after installing xinetd and rebooting you cannot telnet in to the
                                box anymore check the /opt/etc/xinetd.conf file. I discovered by
                                default the only_allow line has localhost and 192.168.1.0/24 listed.
                                Sadly my network uses IP addresses in the 192.168.0.1-255 range so
                                couldn't connect. Commenting out this line will allow connections from
                                any IP address. Alternatively change the only_allow to something that
                                suits your needs i.e. localhost 192.168.0.0/16 - Rufus"
                              • Brian Zhou
                                When xinetd was installed, ipkg prints the following: Note that only 192.168.1.0/24 has access in the default configuration As a user that changed the
                                Message 15 of 30 , Jul 10, 2008
                                • 0 Attachment
                                  When xinetd was installed, ipkg prints the following:

                                  "
                                  Note that only 192.168.1.0/24 has access in the default configuration
                                  "

                                  As a user that changed the default netmask to something else, you
                                  should pay attention to ipkg messages.

                                  The community rules are at http://www.nslu2-linux.org

                                  Robert is very constructive, he gave some very good suggestions on how
                                  to improve this. But so far no approach is perfect. I consider the
                                  existing approach not a bad one.

                                  -Brian

                                  --- In nslu2-linux@yahoogroups.com, "doll_oliver" <doll_oliver@...> wrote:
                                  >
                                  > On Wed, 09 Jul 2008 23:03:30 -0000, "Brian Zhou" wrote:
                                  > > xinetd dependency was introduced between 3.0.28a-1 to 3.0.28a-2.
                                  >
                                  > OK, so I remembered the release#s when I first ran into the issue
                                  > correctly.
                                  >
                                  > > I agree with that change.
                                  >
                                  > I disagree with the introducion of a dependency with xinetd in Samba
                                  > as long as nobody can tell me a (good) reason for it.
                                  >
                                  > [I'm just a simple guy using a Slug at home happy to know what an "ls"
                                  > does (OK maybe I know a bit more, but I'm far away being an Unix
                                  > expert [nor an native English speaker]). So don't be surprised when such
                                  > dependencies get introduced that guys like me fall into a trap without
                                  > knowing what's going on. But anyway:]
                                  >
                                  > if the reason is that SWAT doesn't need so much resources if xinetd is
                                  > used I'd argue that once a package has been "released" with specific
                                  > dependencies those dependencies shouldn't be extended unless it's an
                                  > indispensable feature to ensure it's proper future functionality.
                                  >
                                  > So anybody who want's to have services started by xinted is free to
                                  > add this feature at a later state. (And when sb does add xinetd I
                                  > think he should have enough background information why he does it,
                                  > what changes it might apply to his system and what needs to be tweaked).
                                  >
                                  > > For a new user with the 192.168.1.0/24 default network, swat
                                  > > would just work. As Robert Hammond pointed out,
                                  > > what needs to be improved is wiki page on xinetd, to change the
                                  > > only_from field in /opt/etc/xinetd.conf accordingly if a subnet
                                  > > different from 192.168.1.0/24 is used.
                                  > >
                                  > > Based on nslu2-linux community rule #4 and #5, you're supposed to
                                  > > update wiki page.
                                  >
                                  > [when talking about "you", shouldn't it have been Robert in the first
                                  > place adding this info. Though I'm a simple guy (as mentioned before)
                                  > I'm happy to add these info. But being curious and honestly I've been
                                  > looking for these rules: where can I find them (looked at the wiki but
                                  > also at the yahoo groups page)?
                                  >
                                  > Which brings me to another thing: I at least found the rule for this
                                  > group:
                                  >
                                  > "Posts deemed inappropriate: [...] End user questions about basic
                                  > NSLU2 settings or usage (this is not a help forum for the NSLU2 - Use
                                  > nslu2-general for this kind of discussion"
                                  >
                                  > And this was the first group I tried to subscribe too but I was pushed
                                  > away to this group by the moderator :-P
                                  >
                                  > "Hello, msg offtopic. Here is the correct group:
                                  > http://groups.yahoo.com/group/nslu2-linux/?yguid=184009766"
                                  >
                                  > So please, since I learned that Samba comes with xinetd now (though
                                  > still waiting for good arguments;) and as Robert told what to change
                                  > in the xinted conf I'm happy to live with that change in the future.
                                  > But though I fixed the telnet and SWAT issue I now have the issue that
                                  > Samba does not start after rebooting my Slug. So I'm still lost at
                                  > some point.
                                  > --
                                  > tnx & cheers
                                  > Oliver
                                  >
                                  > PS: while attempting to update the wiki I think it already covers the
                                  > topic:
                                  >
                                  > "If after installing xinetd and rebooting you cannot telnet in to the
                                  > box anymore check the /opt/etc/xinetd.conf file. I discovered by
                                  > default the only_allow line has localhost and 192.168.1.0/24 listed.
                                  > Sadly my network uses IP addresses in the 192.168.0.1-255 range so
                                  > couldn't connect. Commenting out this line will allow connections from
                                  > any IP address. Alternatively change the only_allow to something that
                                  > suits your needs i.e. localhost 192.168.0.0/16 - Rufus"
                                  >
                                • Robert Hammond
                                  In message , Brian Zhou writes ... My recommendation is the simple approach by allowing all subnets with a note
                                  Message 16 of 30 , Jul 10, 2008
                                  • 0 Attachment
                                    In message <g53kfk+ha55@...>, Brian Zhou <b88zhou@...>
                                    writes
                                    >--- In nslu2-linux@yahoogroups.com, Robert Hammond <rob.hammond@...>
                                    >wrote:
                                    >>
                                    >> In message <g4v6jm+nlo1@...>, doll_oliver
                                    >> <doll_oliver@...> writes
                                    >> >On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
                                    >> >>In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
                                    >> >doll_oliver
                                    >> >><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
                                    >> >>> [...]
                                    >> >>># ipkg -test upgrade
                                    >> >>>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                                    >> >>> [...]
                                    >> >> Xinetd seems to be a perquisite for Samba 3, I think it is needed
                                    >> >for Swat.
                                    >> >
                                    >> >hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
                                    >> >telnet) quite long time, now (Slug being my home's Windows DC) IMO
                                    >> >without xinet not having any issues!?
                                    >> >
                                    >> >>Telnet access is enabled by default when using Xinetd so must be
                                    >> >>something different with your set-up if Telnet does not work.
                                    >> >
                                    >> >Indeed this is strange, esp as the output during the update tells the
                                    >> >following about the xinetd config:
                                    >> >
                                    >> >"[...] to activate the samba version 3.
                                    >> >Configuring xinetd
                                    >> >Note that telnetd is enabled by default. Edit /opt/etc/xinetd.d/telnetd
                                    >> >and set 'disable=yes' to disable telnet AFTER making sure that Dropbear
                                    >> >or other means of logging onto your system are enabled and working.
                                    >> >
                                    >> >Note that only 192.168.1.0/24 has access in the default configuration"
                                    >> >
                                    >> Not too sure when Xinetd was added as a perquisite, perhaps from the
                                    >> latest 3.2.0 onwards??.
                                    >>
                                    >> I suppose that there is a danger adding Xinetd as a perquisite to any
                                    >> Optware package. If a user has changed from the default subnet and
                                    >also
                                    >> has no sshd installed they would effectively have no way of accessing
                                    >> the slug if booted with the disk attached, (no doubt there are still
                                    >> many users without the recommended sshd access). They would still be
                                    >> able to recover by booting disk less but again users who have no sshd
                                    >> tend to be inexperienced so recovering by booting disk less would be
                                    >> difficult for them.
                                    >>
                                    >> Perhaps the Optware Xinetd installer should be modified to either :-
                                    >>
                                    >> 1. Allow all subnets by setting 'only_from = localhost 0.0.0.0/0' in
                                    >> xinetd.conf
                                    >> or
                                    >> 2. Read the configured subnet from I think
                                    >>
                                    >> /etc/sysconfig/network-scripts/ifcfg-ixp0
                                    >>
                                    >> and then correct the relevant line in xinetd.conf
                                    >>
                                    >> Option 1. is obviously quite easy, some users may consider allowing all
                                    >> subnets a security problem.
                                    >>
                                    >> Option 2. would involve writing a complex script perhaps using the sed
                                    >> command plus other commands, could be quite a difficult task to
                                    >write a
                                    >> robust script that would work with all firmware versions etc.
                                    >>
                                    >> My vote would be for Option 1. Regarding security, a paragraph could
                                    >> be added to the Wiki to cover re-configuring to improve security.
                                    >> --
                                    >> Robert Hammond
                                    >> PGP:0x154144DA
                                    >>
                                    >
                                    >For option 2, here is the script I come up with (tested with /bin/sh,
                                    >no /opt/bin in PATH)
                                    >
                                    >network=`sed -n '/^NETWORK/s/^.*=//p'
                                    >/etc/sysconfig/network-scripts/ifcfg-ixp0`
                                    >netmask=`sed -n '/^NETMASK/s/^.*=//p'
                                    >/etc/sysconfig/network-scripts/ifcfg-ixp0`
                                    >
                                    >ones=''
                                    >for dec in `echo $netmask | sed 's/\./ /g'`; do
                                    > bin=0
                                    > while test $dec -gt 0; do
                                    > bin=`expr $bin \* 10`
                                    > bin=`expr $bin + $dec % 2`
                                    > dec=`expr $dec / 2`
                                    > done
                                    > ones="$ones`echo $bin | sed 's/0//g'`"
                                    >done
                                    >masklen=`echo $ones | awk "{print length()}"`
                                    >
                                    >sed -i -e "/only_from/s|=.*|= localhost ${network}/${masklen}|"
                                    >/opt/etc/xinetd.conf
                                    >
                                    >
                                    >But the question is, should postinst be that smart?
                                    >
                                    My recommendation is the simple approach by allowing all subnets with a
                                    note added to the config file and perhaps the Wiki regarding changing
                                    back to a more secure setting. Either way Xinetd is currently broken as
                                    an Optware package, installing should not in any way lock a user out
                                    just because of a config issue. I am sure some years back Xinetd was
                                    the preferred package over the built in equivalent, part of the road map
                                    for the NSLU2 so is probably still the preferred package of the two.

                                    --
                                    Robert Hammond
                                    PGP:0x154144DA
                                  • Robert Hammond
                                    In message , doll_oliver writes ... The Xinetd Wiki page does have a small section on re-configuring the
                                    Message 17 of 30 , Jul 10, 2008
                                    • 0 Attachment
                                      In message <g55f72+c7h1@...>, doll_oliver
                                      <doll_oliver@...> writes
                                      >On Wed, 09 Jul 2008 23:03:30 -0000, "Brian Zhou" wrote:
                                      >> xinetd dependency was introduced between 3.0.28a-1 to 3.0.28a-2.
                                      >
                                      >OK, so I remembered the release#s when I first ran into the issue
                                      >correctly.
                                      >
                                      >> I agree with that change.
                                      >
                                      >I disagree with the introducion of a dependency with xinetd in Samba
                                      >as long as nobody can tell me a (good) reason for it.
                                      >
                                      >[I'm just a simple guy using a Slug at home happy to know what an "ls"
                                      >does (OK maybe I know a bit more, but I'm far away being an Unix
                                      >expert [nor an native English speaker]). So don't be surprised when such
                                      >dependencies get introduced that guys like me fall into a trap without
                                      >knowing what's going on. But anyway:]
                                      >
                                      >if the reason is that SWAT doesn't need so much resources if xinetd is
                                      >used I'd argue that once a package has been "released" with specific
                                      >dependencies those dependencies shouldn't be extended unless it's an
                                      >indispensable feature to ensure it's proper future functionality.
                                      >
                                      >So anybody who want's to have services started by xinted is free to
                                      >add this feature at a later state. (And when sb does add xinetd I
                                      >think he should have enough background information why he does it,
                                      >what changes it might apply to his system and what needs to be tweaked).
                                      >
                                      >> For a new user with the 192.168.1.0/24 default network, swat
                                      >> would just work. As Robert Hammond pointed out,
                                      >> what needs to be improved is wiki page on xinetd, to change the
                                      >> only_from field in /opt/etc/xinetd.conf accordingly if a subnet
                                      >> different from 192.168.1.0/24 is used.
                                      >>
                                      >> Based on nslu2-linux community rule #4 and #5, you're supposed to
                                      >> update wiki page.
                                      >
                                      >[when talking about "you", shouldn't it have been Robert in the first
                                      >place adding this info. Though I'm a simple guy (as mentioned before)
                                      >I'm happy to add these info. But being curious and honestly I've been
                                      >looking for these rules: where can I find them (looked at the wiki but
                                      >also at the yahoo groups page)?
                                      >
                                      The Xinetd Wiki page does have a small section on re-configuring the
                                      'only_from' config line.

                                      I have just added into the Wiki page a section regarding security,
                                      currently only contains details of the default Telnet setting.

                                      <http://www.nslu2-linux.org/wiki/Optware/Xinetd>
                                      --
                                      Robert Hammond
                                      PGP:0x154144DA
                                    • Robert Hammond
                                      In message , Robert Hammond writes ... Just following up my own post. Many Xinetd web articles seem
                                      Message 18 of 30 , Jul 10, 2008
                                      • 0 Attachment
                                        In message <0u+sdLCJH9cIFwPG@...>, Robert Hammond
                                        <rob.hammond@...> writes
                                        >In message <g4v6jm+nlo1@...>, doll_oliver
                                        ><doll_oliver@...> writes
                                        >>On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
                                        >>>In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
                                        >>doll_oliver
                                        >>><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
                                        >>>> [...]
                                        >>>># ipkg -test upgrade
                                        >>>>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                                        >>>> [...]
                                        >>> Xinetd seems to be a perquisite for Samba 3, I think it is needed
                                        >>for Swat.
                                        >>
                                        >>hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
                                        >>telnet) quite long time, now (Slug being my home's Windows DC) IMO
                                        >>without xinet not having any issues!?
                                        >>
                                        >>>Telnet access is enabled by default when using Xinetd so must be
                                        >>>something different with your set-up if Telnet does not work.
                                        >>
                                        >>Indeed this is strange, esp as the output during the update tells the
                                        >>following about the xinetd config:
                                        >>
                                        >>"[...] to activate the samba version 3.
                                        >>Configuring xinetd
                                        >>Note that telnetd is enabled by default. Edit /opt/etc/xinetd.d/telnetd
                                        >>and set 'disable=yes' to disable telnet AFTER making sure that Dropbear
                                        >>or other means of logging onto your system are enabled and working.
                                        >>
                                        >>Note that only 192.168.1.0/24 has access in the default configuration"
                                        >>
                                        >Not too sure when Xinetd was added as a perquisite, perhaps from the
                                        >latest 3.2.0 onwards??.
                                        >
                                        >I suppose that there is a danger adding Xinetd as a perquisite to any
                                        >Optware package. If a user has changed from the default subnet and also
                                        >has no sshd installed they would effectively have no way of accessing
                                        >the slug if booted with the disk attached, (no doubt there are still
                                        >many users without the recommended sshd access). They would still be
                                        >able to recover by booting disk less but again users who have no sshd
                                        >tend to be inexperienced so recovering by booting disk less would be
                                        >difficult for them.
                                        >
                                        >Perhaps the Optware Xinetd installer should be modified to either :-
                                        >
                                        >1. Allow all subnets by setting 'only_from = localhost 0.0.0.0/0' in
                                        >xinetd.conf
                                        >or
                                        >2. Read the configured subnet from I think
                                        >
                                        >/etc/sysconfig/network-scripts/ifcfg-ixp0
                                        >
                                        >and then correct the relevant line in xinetd.conf
                                        >
                                        >Option 1. is obviously quite easy, some users may consider allowing all
                                        >subnets a security problem.
                                        >
                                        >Option 2. would involve writing a complex script perhaps using the sed
                                        >command plus other commands, could be quite a difficult task to write a
                                        >robust script that would work with all firmware versions etc.
                                        >
                                        >My vote would be for Option 1. Regarding security, a paragraph could
                                        >be added to the Wiki to cover re-configuring to improve security.
                                        Just following up my own post.

                                        Many Xinetd web articles seem to recommend not using
                                        'only_from = localhost 0.0.0.0/0'

                                        The apparently 0.0.0.0/0 can cause problems with certain configurations.

                                        Many articles recommend allowing complete private subnets.
                                        So a possible work around that covers all private Nats is:-

                                        only_from = localhost 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

                                        I have not tested this but I think should work. My latest
                                        recommendation (cancels any other in previous posts) is to change the
                                        Xinetd configuration to the above and place some notes in the Wiki
                                        regarding tightening security by restricting to a tighter private
                                        subnet.
                                        --
                                        Robert Hammond
                                        PGP:0x154144DA
                                      • Brian Zhou
                                        Excellent suggestion, I just committed the suggested change. The output from a test run: Configuring xinetd Warning: the current only_from configuration in
                                        Message 19 of 30 , Jul 10, 2008
                                        • 0 Attachment
                                          Excellent suggestion, I just committed the suggested change.

                                          The output from a test run:

                                          """
                                          Configuring xinetd
                                          Warning: the current only_from configuration in /opt/etc/xinetd.conf is
                                          only_from = localhost 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
                                          change to your subnet accordingly and tighten security!
                                          """

                                          It will always print out the current setting and remind user to change
                                          it. If the user takes the ipkg version of xinetd.conf, it will be all
                                          private subnets like above; if the user keeps his/her customized
                                          version, it will also be printed.

                                          Best regards,

                                          -Brian

                                          --- In nslu2-linux@yahoogroups.com, Robert Hammond <rob.hammond@...>
                                          wrote:
                                          >
                                          > In message <0u+sdLCJH9cIFwPG@...>, Robert Hammond
                                          > <rob.hammond@...> writes
                                          > >In message <g4v6jm+nlo1@...>, doll_oliver
                                          > ><doll_oliver@...> writes
                                          > >>On Mon, 7 Jul 2008 21:11:20 +0100, Robert Hammond wrote:
                                          > >>>In message <g4tqek+81oe-B11MqFFcr05BDgjK7y7TUQ@...>,
                                          > >>doll_oliver
                                          > >>><doll_oliver-/E1597aS9LQAvxtiuMwx3w@...> writes:
                                          > >>>> [...]
                                          > >>>># ipkg -test upgrade
                                          > >>>>Upgrading samba on root from 3.0.28a-1 to 3.2.0-1...
                                          > >>>> [...]
                                          > >>> Xinetd seems to be a perquisite for Samba 3, I think it is needed
                                          > >>for Swat.
                                          > >>
                                          > >>hmm, this sounds pretty odd to me as I use Samba 3.x, SWAT (and
                                          > >>telnet) quite long time, now (Slug being my home's Windows DC) IMO
                                          > >>without xinet not having any issues!?
                                          > >>
                                          > >>>Telnet access is enabled by default when using Xinetd so must be
                                          > >>>something different with your set-up if Telnet does not work.
                                          > >>
                                          > >>Indeed this is strange, esp as the output during the update tells the
                                          > >>following about the xinetd config:
                                          > >>
                                          > >>"[...] to activate the samba version 3.
                                          > >>Configuring xinetd
                                          > >>Note that telnetd is enabled by default. Edit
                                          /opt/etc/xinetd.d/telnetd
                                          > >>and set 'disable=yes' to disable telnet AFTER making sure that
                                          Dropbear
                                          > >>or other means of logging onto your system are enabled and working.
                                          > >>
                                          > >>Note that only 192.168.1.0/24 has access in the default configuration"
                                          > >>
                                          > >Not too sure when Xinetd was added as a perquisite, perhaps from the
                                          > >latest 3.2.0 onwards??.
                                          > >
                                          > >I suppose that there is a danger adding Xinetd as a perquisite to any
                                          > >Optware package. If a user has changed from the default subnet and
                                          also
                                          > >has no sshd installed they would effectively have no way of accessing
                                          > >the slug if booted with the disk attached, (no doubt there are still
                                          > >many users without the recommended sshd access). They would still be
                                          > >able to recover by booting disk less but again users who have no sshd
                                          > >tend to be inexperienced so recovering by booting disk less would be
                                          > >difficult for them.
                                          > >
                                          > >Perhaps the Optware Xinetd installer should be modified to either :-
                                          > >
                                          > >1. Allow all subnets by setting 'only_from = localhost 0.0.0.0/0' in
                                          > >xinetd.conf
                                          > >or
                                          > >2. Read the configured subnet from I think
                                          > >
                                          > >/etc/sysconfig/network-scripts/ifcfg-ixp0
                                          > >
                                          > >and then correct the relevant line in xinetd.conf
                                          > >
                                          > >Option 1. is obviously quite easy, some users may consider allowing all
                                          > >subnets a security problem.
                                          > >
                                          > >Option 2. would involve writing a complex script perhaps using the sed
                                          > >command plus other commands, could be quite a difficult task to
                                          write a
                                          > >robust script that would work with all firmware versions etc.
                                          > >
                                          > >My vote would be for Option 1. Regarding security, a paragraph could
                                          > >be added to the Wiki to cover re-configuring to improve security.
                                          > Just following up my own post.
                                          >
                                          > Many Xinetd web articles seem to recommend not using
                                          > 'only_from = localhost 0.0.0.0/0'
                                          >
                                          > The apparently 0.0.0.0/0 can cause problems with certain configurations.
                                          >
                                          > Many articles recommend allowing complete private subnets.
                                          > So a possible work around that covers all private Nats is:-
                                          >
                                          > only_from = localhost 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
                                          >
                                          > I have not tested this but I think should work. My latest
                                          > recommendation (cancels any other in previous posts) is to change the
                                          > Xinetd configuration to the above and place some notes in the Wiki
                                          > regarding tightening security by restricting to a tighter private
                                          > subnet.
                                          > --
                                          > Robert Hammond
                                          > PGP:0x154144DA
                                          >
                                        • Robert Hammond
                                          In message , Brian Zhou writes ... Wiki page updated to include basic instruction to restrict IP range.
                                          Message 20 of 30 , Jul 11, 2008
                                          • 0 Attachment
                                            In message <g565lq+vmqs@...>, Brian Zhou <b88zhou@...>
                                            writes
                                            >Excellent suggestion, I just committed the suggested change.
                                            >
                                            >The output from a test run:
                                            >
                                            >"""
                                            >Configuring xinetd
                                            >Warning: the current only_from configuration in /opt/etc/xinetd.conf is
                                            > only_from = localhost 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
                                            >change to your subnet accordingly and tighten security!
                                            >"""
                                            >
                                            >It will always print out the current setting and remind user to change
                                            >it. If the user takes the ipkg version of xinetd.conf, it will be all
                                            >private subnets like above; if the user keeps his/her customized
                                            >version, it will also be printed.
                                            >
                                            Wiki page updated to include basic instruction to restrict IP range.

                                            <http://www.nslu2-linux.org/wiki/Optware/Xinetd>

                                            --
                                            Robert Hammond
                                            PGP:0x154144DA
                                          • doll_oliver
                                            Hi Mike, Mike et al., On Wed, 09 Jul 2008 11:55:31 -0500 in news:4874ED83.8050408@dls.net, ... thanks for your suggestion, but my answer to this will be no :
                                            Message 21 of 30 , Jul 13, 2008
                                            • 0 Attachment
                                              Hi Mike,

                                              Mike et al.,

                                              On Wed, 09 Jul 2008 11:55:31 -0500 in news:4874ED83.8050408@...,
                                              "Mike (mwester)" wrote:
                                              >doll_oliver wrote:
                                              > [...] since the wiki is a community resource I expect that nobody
                                              > has run into this yet, and thus it's not been documented. You'll
                                              > be taking care of that, right?

                                              thanks for your suggestion, but my answer to this will be "no":
                                              I'm a bit hard headed onto this point. I'd be happy to update the doc,
                                              though doing this one for the xinetd stuff it would be contradictory
                                              to my stand-point as I still think somebody having introduced this
                                              dependencies out-of-the-blue isn't something what should have
                                              happened. So I shouldn't document what I think should be corrected,
                                              right? ;-) Otherwise I'd put a stake into the ground for what I don't
                                              like. [1]

                                              I installed samba with

                                              ipkg -nodeps upgrade samba

                                              and obviously samba and swat (mostly: see below) worked as before,
                                              because there is no hard dependency for xinted!

                                              Again: if people think it might be better to use xinted they are still
                                              free to do so without being "forced" into getting it installed by a
                                              dependency which hasn't been there before.

                                              > Regarding xinetd, most folks agree that's the correct way to run
                                              > swat on a low-memory device.

                                              Also here: if I remember right SWAT doesn't run out of the box - I
                                              think I had to do some tweaking to get it started. If someone
                                              considers to run swat there's still the option to switch to xinetd
                                              (worth a hint a the doc suggestion to use xinted when using swat? [1]).

                                              > - if you know ahead of time that this will happen, you can do the
                                              > install of samba with a set of ipkg flags that will force it to
                                              > skip dependencies -- and thus you can avoid having the install
                                              > mess up your inetd on Unslung.

                                              I'm not as familiar with the ipkg system, yet to tell if I have to use
                                              the -nodeps in all future upgrades for Samba or if I can flag Samba's
                                              xinted dependency to not be used without having to add the switch each
                                              time.

                                              > - the easiest way to figure out how to make the new samba work
                                              > would be to figure out how the original one started samba and
                                              > swat -- sort through those startup files and config files, install
                                              > the new version, and either put the original startup files in place
                                              > if that's the right way to do it, or fix up the new startup files
                                              > to do what you want them to do.

                                              While I now seem to understand the issue with xinted, which was a lack
                                              of knowledge to add my subnet to the xinetd.conf I also now understood
                                              why samba didn't start after the reboot as it also requires a change
                                              to it's config: namely the IP address in the smb.conf interfaces
                                              parameter (which was updated in the wiki [1] though, so me to blame
                                              not having looked there in the first place)

                                              But my latest status is:

                                              Either I upgrade to Samba 3.2 with or without using xinted making the
                                              changes mentioned above SWAT's status page lists

                                              smbd: inaktiv
                                              nmbd: inaktiv

                                              though samba is running and the pages lists open connections, shares
                                              and files.
                                              --
                                              tnx & cheers
                                              Oliver

                                              [1] PS: while spending my Sunday with this (no problem - I sometimes
                                              like to do those things ;) I saw that Robert already made further
                                              updates to the wiki - thx!
                                            • Brian Zhou
                                              The approach based on Robert s suggestion http://tech.groups.yahoo.com/group/nslu2-linux/message/21982 is already in the feed. I fail to see why you still need
                                              Message 22 of 30 , Jul 13, 2008
                                              • 0 Attachment
                                                The approach based on Robert's suggestion

                                                http://tech.groups.yahoo.com/group/nslu2-linux/message/21982

                                                is already in the feed.

                                                I fail to see why you still need to use "ipkg install -nodeps".

                                                If SWAT still is not working, you need to provide more information to
                                                help the troubleshooting.

                                                I guess you don't understand how this community works. You're not a
                                                paying customer to a commercial company. Developers pay attention to
                                                technical reasons, not to your demand of fixing something exactly your
                                                way. While we appreciate your report of the initial problem, your
                                                refusal to update wiki will not make you popular in this community.

                                                -Brian

                                                --- In nslu2-linux@yahoogroups.com, "doll_oliver" <doll_oliver@...> wrote:
                                                >
                                                > Hi Mike,
                                                >
                                                > Mike et al.,
                                                >
                                                > On Wed, 09 Jul 2008 11:55:31 -0500 in news:4874ED83.8050408@...,
                                                > "Mike (mwester)" wrote:
                                                > >doll_oliver wrote:
                                                > > [...] since the wiki is a community resource I expect that nobody
                                                > > has run into this yet, and thus it's not been documented. You'll
                                                > > be taking care of that, right?
                                                >
                                                > thanks for your suggestion, but my answer to this will be "no":
                                                > I'm a bit hard headed onto this point. I'd be happy to update the doc,
                                                > though doing this one for the xinetd stuff it would be contradictory
                                                > to my stand-point as I still think somebody having introduced this
                                                > dependencies out-of-the-blue isn't something what should have
                                                > happened. So I shouldn't document what I think should be corrected,
                                                > right? ;-) Otherwise I'd put a stake into the ground for what I don't
                                                > like. [1]
                                                >
                                                > I installed samba with
                                                >
                                                > ipkg -nodeps upgrade samba
                                                >
                                                > and obviously samba and swat (mostly: see below) worked as before,
                                                > because there is no hard dependency for xinted!
                                                >
                                                > Again: if people think it might be better to use xinted they are still
                                                > free to do so without being "forced" into getting it installed by a
                                                > dependency which hasn't been there before.
                                                >
                                                > > Regarding xinetd, most folks agree that's the correct way to run
                                                > > swat on a low-memory device.
                                                >
                                                > Also here: if I remember right SWAT doesn't run out of the box - I
                                                > think I had to do some tweaking to get it started. If someone
                                                > considers to run swat there's still the option to switch to xinetd
                                                > (worth a hint a the doc suggestion to use xinted when using swat? [1]).
                                                >
                                                > > - if you know ahead of time that this will happen, you can do the
                                                > > install of samba with a set of ipkg flags that will force it to
                                                > > skip dependencies -- and thus you can avoid having the install
                                                > > mess up your inetd on Unslung.
                                                >
                                                > I'm not as familiar with the ipkg system, yet to tell if I have to use
                                                > the -nodeps in all future upgrades for Samba or if I can flag Samba's
                                                > xinted dependency to not be used without having to add the switch each
                                                > time.
                                                >
                                                > > - the easiest way to figure out how to make the new samba work
                                                > > would be to figure out how the original one started samba and
                                                > > swat -- sort through those startup files and config files, install
                                                > > the new version, and either put the original startup files in place
                                                > > if that's the right way to do it, or fix up the new startup files
                                                > > to do what you want them to do.
                                                >
                                                > While I now seem to understand the issue with xinted, which was a lack
                                                > of knowledge to add my subnet to the xinetd.conf I also now understood
                                                > why samba didn't start after the reboot as it also requires a change
                                                > to it's config: namely the IP address in the smb.conf interfaces
                                                > parameter (which was updated in the wiki [1] though, so me to blame
                                                > not having looked there in the first place)
                                                >
                                                > But my latest status is:
                                                >
                                                > Either I upgrade to Samba 3.2 with or without using xinted making the
                                                > changes mentioned above SWAT's status page lists
                                                >
                                                > smbd: inaktiv
                                                > nmbd: inaktiv
                                                >
                                                > though samba is running and the pages lists open connections, shares
                                                > and files.
                                                > --
                                                > tnx & cheers
                                                > Oliver
                                                >
                                                > [1] PS: while spending my Sunday with this (no problem - I sometimes
                                                > like to do those things ;) I saw that Robert already made further
                                                > updates to the wiki - thx!
                                                >
                                              • doll_oliver
                                                Hi Brian et al., In news:g5dk1q+md6m@eGroups.com on Sun, 13 Jul 2008 19:11:54 -0000 ... yes, looks like I couldn t highlight in my replies that I found the
                                                Message 23 of 30 , Jul 14, 2008
                                                • 0 Attachment
                                                  Hi Brian et al.,

                                                  In news:g5dk1q+md6m@...> on Sun, 13 Jul 2008 19:11:54 -0000
                                                  "Brian Zhou" wrote:
                                                  > The approach based on Robert's suggestion
                                                  >
                                                  > http://tech.groups.yahoo.com/group/nslu2-linux/message/21982
                                                  >
                                                  > is already in the feed.

                                                  yes, looks like I couldn't highlight in my replies that I found the
                                                  following things mentionend by Mike and Robert (thx!) which need
                                                  ammended in some config files to get it working:

                                                  Not installing xinted:
                                                  just add your local IP address to the smb.conf for the interfaces
                                                  parameter.
                                                  Also installing xinetd:
                                                  also add ip range from whee you will allow connections to the xinted.conf

                                                  > I fail to see why you still need to use "ipkg install -nodeps".

                                                  because
                                                  i) I wanted to test both upgrade pathes and it's behaviours
                                                  ii) I may want to stay with an installion without being "forced" to
                                                  use xinted if I want to upgrade Samba

                                                  > If SWAT still is not working, you need to provide more information to
                                                  > help the troubleshooting.

                                                  I think in both scenarios (w/o xinted) Samba and SWAT work the same.
                                                  So I guess SWAT working but no longer showing that smbf & nmdb are
                                                  running (in fact telling me "not running") has something to do with a
                                                  change which comes with Samba?!

                                                  When checking the wiki [1] I spotted the following differences with my
                                                  smb.conf:

                                                  wiki:
                                                  lock directory = /var/samba3
                                                  pid directory = /var/samba3

                                                  mine:
                                                  lock directory = /opt/var/samba
                                                  pid directory = /opt/var/samba

                                                  which I guessed could have that impact (though haven't had time yet to
                                                  to test it).

                                                  > I guess you don't understand how this community works. You're not a
                                                  > paying customer to a commercial company. Developers pay attention to
                                                  > technical reasons, not to your demand of fixing something exactly your
                                                  > way.

                                                  Sorry, but your guess is wrong then ;-) I really appreciate all the
                                                  works of the community. I'm just expressing my opinion why I think it
                                                  was bad to make xinted a dependency of Samba. And I as still have this
                                                  opinion of course I would be happy if this behaviour would get
                                                  reverted. (don't be afraid: I already made points before and I'm not
                                                  going to repeat them a 3rd time ;)

                                                  If I would have spotted my issues while upgrading from 3.0.28a-1 to
                                                  3.0.28a-2 simply as the introduction of a dependency with xinted my
                                                  arguements may have found some more interest that time. (But looks
                                                  like we're too far down the road already with 3.2)

                                                  > While we appreciate your report of the initial problem, your
                                                  > refusal to update wiki will not make you popular in this community.

                                                  Just to correct this statement and to refer to what I said before: I'm
                                                  not generally refusing to update the wiki. I aldready tried to do so,
                                                  but first
                                                  I ran into an issue that I need some password
                                                  and second
                                                  I found that Robert already made the changes
                                                  so I didn't follow up on 1.

                                                  I just said, that I wouldn't make updates to the wiki (or any other
                                                  kind of documentation) if what gets documented conflicts with what I
                                                  think how it should work. And I think this is fair enough, right? ;-)
                                                  --
                                                  thx & cheers
                                                  Oliver

                                                  [1] http://www.nslu2-linux.org/wiki/Optware/Samba
                                                • Robert Hammond
                                                  In message , doll_oliver writes ... This is an unlikely cause of your problem. I suggest that you check if
                                                  Message 24 of 30 , Jul 14, 2008
                                                  • 0 Attachment
                                                    In message <g5fd12+e5pd@...>, doll_oliver
                                                    <doll_oliver@...> writes
                                                    >Hi Brian et al.,
                                                    >
                                                    >In news:g5dk1q+md6m@...> on Sun, 13 Jul 2008 19:11:54 -0000
                                                    >"Brian Zhou" wrote:
                                                    >> The approach based on Robert's suggestion
                                                    >>
                                                    >> http://tech.groups.yahoo.com/group/nslu2-linux/message/21982
                                                    >>
                                                    >> is already in the feed.
                                                    >
                                                    >yes, looks like I couldn't highlight in my replies that I found the
                                                    >following things mentionend by Mike and Robert (thx!) which need
                                                    >ammended in some config files to get it working:
                                                    >
                                                    >Not installing xinted:
                                                    > just add your local IP address to the smb.conf for the interfaces
                                                    >parameter.
                                                    >Also installing xinetd:
                                                    > also add ip range from whee you will allow connections to the xinted.conf
                                                    >
                                                    >> I fail to see why you still need to use "ipkg install -nodeps".
                                                    >
                                                    >because
                                                    >i) I wanted to test both upgrade pathes and it's behaviours
                                                    >ii) I may want to stay with an installion without being "forced" to
                                                    >use xinted if I want to upgrade Samba
                                                    >
                                                    >> If SWAT still is not working, you need to provide more information to
                                                    >> help the troubleshooting.
                                                    >
                                                    >I think in both scenarios (w/o xinted) Samba and SWAT work the same.
                                                    >So I guess SWAT working but no longer showing that smbf & nmdb are
                                                    >running (in fact telling me "not running") has something to do with a
                                                    >change which comes with Samba?!
                                                    >
                                                    >When checking the wiki [1] I spotted the following differences with my
                                                    >smb.conf:
                                                    >
                                                    >wiki:
                                                    > lock directory = /var/samba3
                                                    > pid directory = /var/samba3
                                                    >
                                                    >mine:
                                                    > lock directory = /opt/var/samba
                                                    > pid directory = /opt/var/samba
                                                    >
                                                    >which I guessed could have that impact (though haven't had time yet to
                                                    >to test it).
                                                    >
                                                    This is an unlikely cause of your problem. I suggest that you check if
                                                    the folder exists, if it does check the permissions to make sure it can
                                                    be written to. I think that you will find that the folder already
                                                    contains many Samba files. If so then you need to look elsewhere.

                                                    Regarding perquisites, as many have quoted, the need for these is
                                                    always changing.
                                                    Surely what is important here is not perquisites, but the need for
                                                    packages to have a seamless installation or upgrade, very difficult for
                                                    the package developers because of the many restrictions with the Unslung
                                                    firmware.

                                                    Xinetd is now fixed and should be a seamless installation or upgrade for
                                                    any future user.

                                                    Samba 3.2.0 is not currently a seamless installation or upgrade, a much
                                                    more complex program when compared to the simple Xinetd. As reported
                                                    there is already found the need to change the interfaces section, (I
                                                    think that the need for this is an unwanted software bug introduced with
                                                    Samba 3.2.0, reading through the change notes infers some changes made
                                                    to this section of software code.) Also there must be another unknown
                                                    problem because your server will not start up.

                                                    Regarding your server problem, could you check that the file
                                                    /opt/etc/printcap exists.
                                                    --
                                                    Robert Hammond
                                                    PGP:0x154144DA
                                                  • doll_oliver
                                                    Hi, I had my Slug running with Samba 3.2.0-1 for some time, now though SWAT no longer recognizes that the daemons smbd & nmbd are active. But when I returned
                                                    Message 25 of 30 , Jul 31, 2008
                                                    • 0 Attachment
                                                      Hi,

                                                      I had my Slug running with Samba 3.2.0-1 for some time, now though
                                                      SWAT no longer recognizes that the daemons smbd & nmbd are active.

                                                      But when I returned from vacation trying to copy some files to the
                                                      Slug I noticed two issues:

                                                      i) it was very slow and I found nmbd running wild so I restarted it
                                                      the services

                                                      ii) even more odd I found some files with strange file names in some
                                                      directories with creation dates even before my vacation which I
                                                      couldn't delete remotely (from my windows client). When I logged into
                                                      the Slug I found that when I copied a file with the file name - let's
                                                      say "myfile.txt" to my network share that not only that file got
                                                      created but also a second one with the file name
                                                      "myfile.txt:Zone.Identifier:$DATA"

                                                      So I decide to restore my backup before the upgrade and I returned to
                                                      3.0.28a-1 ...
                                                      --
                                                      tnx & cheers
                                                      Oliver
                                                    • doll_oliver
                                                      ... I tried to look for the reason why these files get created since I upgraded to samba 3.2. Searching the web I found the info [1] that one should add veto
                                                      Message 26 of 30 , Aug 5, 2008
                                                      • 0 Attachment
                                                        --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                                                        > When I logged into
                                                        > the Slug I found that when I copied a file with the file name - let's
                                                        > say "myfile.txt" to my network share that not only that file got
                                                        > created but also a second one with the file name
                                                        > "myfile.txt:Zone.Identifier:$DATA"
                                                        >
                                                        > So I decide to restore my backup before the upgrade and I returned to
                                                        > 3.0.28a-1 ...

                                                        I tried to look for the reason why these files get created since I
                                                        upgraded to samba 3.2. Searching the web I found the info [1] that one
                                                        should add

                                                        veto files = /*.Zone.Identifier:*/

                                                        to the GLOBAL section in samba config file, but frankly this looks
                                                        more like a workaround to me!?

                                                        When looking at the samba 3.2 release notes I guess this behavior had
                                                        been introced by one of the two features?

                                                        o Support for storing alternate data streams in xattrs.
                                                        o Encrypted SMB transport in client tools and libraries, and server.

                                                        Unfortunately the Search function is currently not working on the
                                                        samba.org site(s).
                                                        --
                                                        thx & cheers
                                                        Oliver

                                                        [1]
                                                        http://forums.opensuse.org/network-internet/387779-samba-file-transfer-creates-zone-identifier-files.html
                                                      • doll_oliver
                                                        ... think I found it as being caused a bug in the 3.2 release -- thx & cheers Oliver [1] http://www.mail-archive.com/samba@lists.samba.org/msg94691.html
                                                        Message 27 of 30 , Aug 5, 2008
                                                        • 0 Attachment
                                                          --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                                                          > Unfortunately the Search function is currently not working on the
                                                          > samba.org site(s).

                                                          think I found it as being caused a bug in the 3.2 release
                                                          --
                                                          thx & cheers
                                                          Oliver

                                                          [1] http://www.mail-archive.com/samba@.../msg94691.html
                                                        • Brian Zhou
                                                          Hi Oliver, Thanks for the problem report and investigation. Samba 3.2.1 has just been released and supposedly include this fix. I upgraded optware samba
                                                          Message 28 of 30 , Aug 5, 2008
                                                          • 0 Attachment
                                                            Hi Oliver,

                                                            Thanks for the problem report and investigation.

                                                            Samba 3.2.1 has just been released and supposedly include this fix. I
                                                            upgraded optware samba package to 3.2.1 after testing that I can
                                                            connect to a share on unslung. It probably would take a few hours
                                                            before the new ipk reach the feed.

                                                            Cheers,

                                                            -Brian

                                                            --- In nslu2-linux@yahoogroups.com, "doll_oliver" <doll_oliver@...> wrote:
                                                            >
                                                            > --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                                                            > > Unfortunately the Search function is currently not working on the
                                                            > > samba.org site(s).
                                                            >
                                                            > think I found it as being caused a bug in the 3.2 release
                                                            > --
                                                            > thx & cheers
                                                            > Oliver
                                                            >
                                                            > [1] http://www.mail-archive.com/samba@.../msg94691.html
                                                            >
                                                          • doll_oliver
                                                            ... np ... thx for this. I was able to update my Slug with your update this morning and everything looks fine, now. -- thx & cheers Oliver PS: the issue with
                                                            Message 29 of 30 , Aug 9, 2008
                                                            • 0 Attachment
                                                              --- In nslu2-linux@yahoogroups.com, "Brian Zhou" wrote:
                                                              > Thanks for the problem report and investigation.

                                                              np

                                                              > Samba 3.2.1 has just been released and supposedly include this fix. I
                                                              > upgraded optware samba package to 3.2.1 after testing that I can
                                                              > connect to a share on unslung. It probably would take a few hours
                                                              > before the new ipk reach the feed.

                                                              thx for this. I was able to update my Slug with your update this
                                                              morning and everything looks fine, now.
                                                              --
                                                              thx & cheers
                                                              Oliver

                                                              PS: the issue with SWAT persists: it still reports smbd and nmbd as
                                                              "not running" though it's properly listing the active connection &
                                                              shares and the open files.
                                                            • doll_oliver
                                                              ... I think I finally got SWAT working on the Unslung image, again: Beside the IP range of the local ethernet interface which needed to be added to the
                                                              Message 30 of 30 , Dec 21, 2008
                                                              • 0 Attachment
                                                                --- In nslu2-linux@yahoogroups.com, "doll_oliver" wrote:
                                                                > [...] But my latest status is:
                                                                >
                                                                > Either I upgrade to Samba 3.2 with or without using xinted
                                                                > making the changes mentioned above SWAT's status page lists
                                                                >
                                                                > smbd: not running
                                                                > nmbd: not running
                                                                >
                                                                > though samba is running and the pages lists open connections,
                                                                > shares and files. [...]

                                                                I think I finally got SWAT working on the Unslung image, again:
                                                                Beside the IP range of the local ethernet interface which needed to be
                                                                added to the smb.conf ("interfaces = <myEth-IP>, ipx0, lo") config I
                                                                also added 127.0.0.1/24.

                                                                Now, /opt/bin/nmblookup -A localhost.
                                                                Looking up status of 127.0.0.1
                                                                NLSU2 <00> - H <ACTIVE>
                                                                NSLU2 <03> - H <ACTIVE>
                                                                NSLU2 <20> - H <ACTIVE>
                                                                ..__MSBROWSE__. <01> - <GROUP> H <ACTIVE>
                                                                MY_DOMAIN <1d> - H <ACTIVE>
                                                                MY_DOMAIN <1b> - H <ACTIVE>
                                                                MY_DOMAIN <1c> - <GROUP> H <ACTIVE>
                                                                MY_DOMAIN <1e> - <GROUP> H <ACTIVE>
                                                                MY_DOMAIN <00> - <GROUP> H <ACTIVE>

                                                                MAC Address = 00-00-00-00-00-00

                                                                works again. I guess the translation of "ipx0" and "lo" got broken on
                                                                Unslung for samba 3.2+!?
                                                                --
                                                                thx & cheers
                                                                Oliver
                                                              Your message has been successfully submitted and would be delivered to recipients shortly.