Samba upgrade installs xinted: no telnet nor SWAT after this

[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]
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 <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)]

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]

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]

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,

--- In nslu2-linux@..., "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 <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]

--- In nslu2-linux@..., "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]

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]

In nslu2-linux@..., "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)]

doll_oliver wrote:

> In nslu2-linux@..., "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 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@..., "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]

--- In nslu2-linux@..., 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]

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 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@..., "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 <g53kfk+ha55@...>, Brian Zhou <b88zhou@...>
writes

>--- In nslu2-linux@..., 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 t