Jukka Marin | 1 Oct 2003 09:18
Picon

CODA any good?

Hi,

We have a VPN over DSL.  Using NFS is quite slow (the client side doesn't
buffer the data too well?).  Is CODA any good?  Is it stable and reliable?
Ready for production use?

Are there other alternatives?

Thanks,

  -jm

David Laight | 1 Oct 2003 10:46
Picon

Re: How to bind keys in .kshrc

On Tue, Sep 30, 2003 at 07:50:00PM +0200, Julien Gabel wrote:
> > The manpage for ksh(1) doesn't even mention $HOME/.kshrc. Isn't that
> > a bug? If I used ksh, I'd like to know whether it's used for any shell
> > or only a login shell and whether it's processed before or after
> > $HOME/.profile etc.
> 
> ${HOME}/.kshrc is normally sourced if the ${ENV} variable is exported, for
> example in the ${HOME}/.profile :
> 
>   ENV=${HOME}/.kshrc ; export ENV
> 
> This environmental script is read (sourced) each time a new sub-Korn Shell
> process is launched : the login process is one of them. ${HOME}/.kshrc is
> sourced *after* the ${HOME}/.profile in the login phase.

Ugggg - no wonder you have problems!
ENV is used by many shells, so you can't have ksh commands in it
(unless you detect the shell is ksh, [ "$RANDOM" != "$RANDOM" ] is a check
that will exclude sh)

	David

--

-- 
David Laight: david <at> l8s.co.uk

Sebastian Prause | 1 Oct 2003 11:34
Picon

apache doesn't start up

hi,
apache has been running for some month now and after i stopped it yesterday it doesn't start
up but gives me this error (in the log file):

[Wed Oct 01 11:05:58 2003] [notice] Digest: generating secret for digest authentication ...
[Wed Oct 01 11:05:58 2003] [notice] Digest: done
[Wed Oct 01 11:05:58 2003] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
[Wed Oct 01 11:05:59 2003] [emerg] (28)No space left on device: Couldn't create accept lock

my disk usage is as follows:

$ df -im
Filesystem  1M-blocks     Used     Avail Capacity iused   ifree  %iused  Mounted on
/dev/wd0a         992      485       457    51%   43833  210565    17%   /
/dev/wd0g        3385     2120      1096    65%  183996  687170    21%   /usr
/dev/wd0e         992       57       885     6%     445  253953     0%   /home
/dev/wd0f         387       33       333     9%     140   99698     0%   /tmp

i'm using NetBSD 1.6.1_STABLE on i386
so can anybody give me some hints on what might be wrong/missing/broken?

thanks in advance
sp

Sebastian Prause | 1 Oct 2003 11:42
Picon

Re: apache doesn't start up

wow, i actually found a solution (sorry for being too fast):

there were some dead semaphores around which i removed with ipcrm

Julien Gabel | 1 Oct 2003 12:10

Re: How to bind keys in .kshrc

>>> The manpage for ksh(1) doesn't even mention $HOME/.kshrc. Isn't that
>>> a bug? If I used ksh, I'd like to know whether it's used for any shell
>>> or only a login shell and whether it's processed before or after
>>> $HOME/.profile etc.

>> ${HOME}/.kshrc is normally sourced if the ${ENV} variable is exported,
>> for example in the ${HOME}/.profile :
>>   ENV=${HOME}/.kshrc ; export ENV
>> This environmental script is read (sourced) each time a new sub-Korn
>> Shell process is launched : the login process is one of them.
>> ${HOME}/.kshrc is sourced *after* the ${HOME}/.profile in the login
>> phase.

> Ugggg - no wonder you have problems!

I have no problem.

> ENV is used by many shells, so you can't have ksh commands in it
> (unless you detect the shell is ksh, [ "$RANDOM" != "$RANDOM" ] is a
> check that will exclude sh)

As I know, nor the csh(1) nor the tcsh(1) uses this variable which is
used by the sh(1) compatible shells. Note that this variable is set
from ${HOME}/.profile which is even not sourced by csh(1) or tcsh(1).

Because the content of this file is sh(1) compatible, you just need - in
the case of the user uses different shells at the same time - to write
some sh(1) strict declarations.
Example : LOCALVAR="somedefinition" ; export LOCALVAR
And not : export LOCALVAR="somedefinition" which is more specific to the
(Continue reading)

Bruce Martin | 1 Oct 2003 15:53
Picon

UDF filesystem creation in NetBSD?

I am planning to write some DVD's in NetBSD - I have been happily writing CDs for years with cdrecord, and have
managed to write an
ISO9660 filesystem to a DVD under NetBSD too. However, I now want to create a 4GB (or greater) filesystem
image, and write it to
DVD. I am pretty sure I cannot do this with ISO9660, and require a UDF filesystem for the DVD...

However, I have searched far and wide in the NetBSD world, and not been able to find any software or utility
that will create a UDF
filesystem - is there existent software? I see mkisofs now has a '-udf' flag, but the implementation looks
very limited. Has anyone
out there written large filesystems to DVDs under NetBSD? What about under Linux or other O/S's? Do such
tools exist?

Any pointers here would be greatly appreciated!

Regards
 Bruce Martin

Greg Troxel | 1 Oct 2003 16:08
Picon

Re: CODA any good?

  We have a VPN over DSL.  Using NFS is quite slow (the client side doesn't
  buffer the data too well?).

I have taken the liberty of adding white space to your text.

  Is CODA any good?

Yes.  I use it fairly regularly, but I don't put my homedir in it.

  Is it stable and reliable?

Almost.  The server is pretty stable, but the client occasionally gets
hosed.  If you are mostly conencted (read caching only), or mostly
'write-disconnected' (read caching and write-behind caching), then
this should just involve reinitializaing the client, since all the
state will be on the server.

Only consider coda 6.0.2 or more reccent.

  Ready for production use?

If there is fairly little disconnection, probably more or less, but
not quite.  But note that I run -current coda from cvs, and have found
problems.  I often go disconnected, and am behind a 28.8 dialup, so I
think I'm a particularly difficult case.

Coda security is sort of bogus, but compared to NFS it is fine.  I use
IPsec transport mode between clients and the server; if you have an
inside-the-firewall VPN mentality that is probably OK.  It has a
kerberos-like token mechanism, but due to the legacy of previous
(Continue reading)

Manuel Bouyer | 1 Oct 2003 22:05

Re: next stable release version number (was re: Semaphore p1003.1b)

On Tue, Sep 30, 2003 at 09:16:19AM -0700, netbsd99 <at> sudog.com wrote:
> I'm shocked. We're not going to go with version number 1.7?
> 
> I always like the fact that we were still at version 1.6 while the rest 
> of the world was moving on towards version 9.8 or 12.3 so it'd look 
> good to the unwashed masses.

The issue here is that with our current version numbering scheme: x.y.z,
y is bumped for major releases and z for minor, bug-fix release. So x is
never bumped, and will say at 1 forever. So just drop x, and
start using 2 digit version numbers :)

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--

Marc Tooley | 1 Oct 2003 23:48
Favicon

Re: next stable release version number (was re: Semaphore p1003.1b)

On Wednesday 01 October 2003 13:05, Manuel Bouyer wrote:
> On Tue, Sep 30, 2003 at 09:16:19AM -0700, netbsd99 <at> sudog.com wrote:
> > I'm shocked. We're not going to go with version number 1.7?
> >
> > I always like the fact that we were still at version 1.6 while the
> > rest of the world was moving on towards version 9.8 or 12.3 so it'd
> > look good to the unwashed masses.
>
> The issue here is that with our current version numbering scheme:
> x.y.z, y is bumped for major releases and z for minor, bug-fix
> release. So x is never bumped, and will say at 1 forever. So just
> drop x, and start using 2 digit version numbers :)

But, but.. I thought the fact we were still at 1.x.x was a simple 
against-the-grain statement making light of the fact that everyone and 
their dog bumps their major version numbers five or six times a year? I 
thought it was a great nose-thumbing, personally. Otherwise we'd be at 
6.2 or so right now. Just feels wrong.

I think if MP and SA can be forced into the stable (ha ha) that would 
justify the move to 2.x.x, but let's still have the three version 
numbers, I say. :)

If it's bound to be 2.x, near as I can tell the following major 
functionality has been added/modified:

1. Semi-functional MP
2. Mostly functional scheduler activations
3. Updated compiler

(Continue reading)

Steven M. Bellovin | 1 Oct 2003 23:57
Picon

Re: next stable release version number (was re: Semaphore p1003.1b)

In message <200310011448.00870.marc <at> perforce.com>, Marc Tooley writes:
>
>
>If it's bound to be 2.x, near as I can tell the following major 
>functionality has been added/modified:
>
>1. Semi-functional MP
>2. Mostly functional scheduler activations
>3. Updated compiler
>
>Any other major changes? Are #1 and #2 in a state to be released as 
>stable? I've been reading some messages suggesting that there are 
>certain hard problems that won't be solved anytime soon without 
>significant effort on the part of Some Brave Soul Out There.

From my perspective as a user of -current, #2 and #3 are in decent 
shape.  Note that I'm *not* a developer of these things, and I'm only 
using i386.  But I've had no scheduler activation problems for several 
weeks, and I used to have several a day, nor have I had any gcc 
problems.

		--Steve Bellovin, http://www.research.att.com/~smb


Gmane